Serverless GPU 冷启动测试与结果记录方法

测试 Serverless GPU 冷启动时，先确认没有可复用的就绪容器，再从客户端发出请求前开始计时，并记录平台可观测的等待、初始化、首个响应和最终响应。Modal 对冷启动的说明把延迟来源分为等待 warm container，以及新容器首次处理输入时的 initialization。比较不同 GPU服务器租用配置时，要同时保存响应数据与平台账单中的完整资源区间；单个慢请求不能证明发生了冷启动。

测试 GPU服务器租用配置时先固定变量

先按所选平台的当前 endpoint 文档完成部署，并保存原始部署命令，不要把其他平台的鉴权参数或 endpoint 路径直接套用。固定模型及权重版本、请求内容、生成参数、并发、镜像、runtime、GPU 型号和配置版本，每轮只改变一个待比较变量。

测试机还要能够读取单调时钟、保存原始请求与响应，并在平台提供状态或日志时记录容器、worker 的变化。run_id、请求编号、工具版本和配置版本都应进入记录，避免后续把不同版本的结果混在一起。

冷启动样本的触发与计时步骤

1. 若当前官方文档提供容器或 worker 状态、日志，先确认没有就绪实例，再发送固定请求。没有可核对的状态记录时，将样本标为 unknown，不要仅凭响应慢标为冷启动。
2. 使用同一单调时钟，在 dispatch 前记录 t_send_ms，首个 token 到达时记录 t_first_token_ms，最终响应到达时记录 t_final_ms。平台若能提供 queue 或 initialization 边界，再分别记录；否则留空。
3. 平台确认已有可复用容器后，以相同并发、请求和生成参数记录 warm 样本。超时、错误与重试也应保留，不能只留下成功请求。

MLPerf Inference Rules把延迟起点定义为 LoadGen 被调度向 SUT 传递查询的时刻，终点为收到回复；其 LLM 指标还包括 TTFT 和 TPOT。Serverless 测试可按下式统一口径：

ttft_ms = t_first_token_ms - t_send_ms
request_latency_ms = t_final_ms - t_send_ms

若还要用 NVIDIA 工具检查 streaming 指标，GenAI-Perf README给出的命令形式是：

genai-perf profile \
  -m gpt2 \
  --backend tensorrtllm \
  --streaming

同一说明表示 GenAI-Perf 已不再积极开发新功能，并将新的性能基准需求指向 AIPerf。因此，这条命令只用于核对现有文档形式，新测试应先核对 AIPerf 的当前说明。冷启动状态仍应由平台状态记录和客户端时间戳确认，不能从工具汇总值反推。

冷启动结果记录表要保存什么

每次调用记录一行，配置另建汇总表：

字段	填写内容
run_id、request_id	YOUR_VALUE
configuration	provider、endpoint、worker 模式、模型、镜像、GPU 与配置版本
state_before	cold、warm 或 unknown，并保存对应状态记录
timestamps	t_send_ms、t_first_token_ms、t_final_ms
response_metrics	ttft_ms、request_latency_ms、tpot_ms、output_tokens、状态码
phase_timing	平台可观测的 queue、initialization；不可见时为 unknown
billing	worker 起止时间、billed_seconds、费用及当前费率来源
raw_result	原始请求、原始响应和错误日志的 YOUR_VALUE

只有状态记录能够确认“没有就绪实例，并启动了新实例”时，才能填写 cold_start_observed=yes。响应慢、TTFT 高或首次输出停顿都不能单独作为判定依据。

不同配置怎样公平比较响应与费用

RunPod 的Serverless worker 文档说明，Flex workers 会在闲置时缩到零，扩容时产生冷启动，未使用时不计费用；Active workers 保持可用状态，可消除冷启动，但包括闲置期间都会持续计费。测试时应把 Flex 的 scale-up 请求与 Active 的已保温请求分组，不能直接混成一个平均值。

Modal 的冷启动文档说明，默认最大闲置时间为 60 秒，scaledown_window 可设置为 2 秒至 20 分钟；延长它会降低后续请求遇到冷启动的机会，但闲置期间占用的资源仍会计费。min_containers 提供容器数量下限，buffer_containers 为活跃 Function 预留额外容器。记录配置时保留这些键的原名：

scaledown_window
min_containers
buffer_containers

RunPod 的Serverless 计费说明规定，计费从 worker 启动持续到完全停止，并向上取整到下一秒。可计费阶段包括容器初始化与模型加载、请求执行，以及请求完成后的 idle timeout；后者默认 5 秒。时间使用同一单位时，可按账单或报价中的费率计算：

billable_second_rate = YOUR_VALUE
billed_seconds = CEILING(worker_stop_time - worker_start_time)
worker_cost = billed_seconds × billable_second_rate
cost_per_completed_request = worker_cost / completed_requests

Modal 的比较表还应单列闲置 GPU reservation 或 residual memory 占用产生的费用。不要自行补写费率；应从当前报价或账单填写 YOUR_VALUE。

如何验证并避开常见错误

只有请求内容、模型、runtime、GPU、并发、生成参数和配置版本一致的记录才能横向比较。汇总时分别计算冷、暖样本，不用总体均值掩盖状态差异：

cold_minus_warm_median_ms =
  MEDIAN(cold_request_latency_ms) - MEDIAN(warm_request_latency_ms)

常见错误包括：在平台已接受请求后才开始计时，漏掉等待时间；没有状态记录却把慢请求归为冷启动；比较不同的输出长度或并发；删除失败请求；以及在最终响应到达时立即结束 RunPod 计费区间，漏掉后续 idle timeout。MLPerf 还要求被测系统不按 query index 缓存信息，因此重复请求也不能依靠序号命中专属缓存。

本文步骤依据正文链接的官方文档整理，未运行或测量；使用前应按当前版本复核。