Serverless GPU 选型验证：启动与成本权衡

用统一任务记录拆分冷启动、排队、首响应与失败情况，再按 RunPod、Modal、Replicate 的官方计费边界计算总费用，形成可复用的 Serverless GPU 选型结论。

Serverless GPU 选型不能只看单价：应在同一负载下同时记录冷启动、首响应、完整请求耗时、失败情况和费用。做算力租赁选型时，先建立统一任务记录，再按平台当前文档拆开启动、空闲与计费边界，最后用自己的账单或报价形成结论；本文不对平台排名，也不把客户端观察时间当成平台定义的冷启动。

Serverless GPU 选型验证：先固定比较条件

每次运行应固定模型及权重版本、请求模板、输入输出长度、并发和冷、热状态，并记录容器与推理服务版本。每条请求记录提交、首个响应、最终响应和成功或失败；每次运行还要记录 worker 或 container 数量、启动与停止事件，以及实际账单行项目。

客户端侧可以统一计算：

OBSERVED_FIRST_RESPONSE = YOUR_VALUE_FIRST_RESPONSE_TIME - YOUR_VALUE_SUBMIT_TIME
OBSERVED_REQUEST_DURATION = YOUR_VALUE_FINAL_RESPONSE_TIME - YOUR_VALUE_SUBMIT_TIME

这两项只是客户端观察值。只有符合平台定义且能由对应事件确认的区间，才能记作平台冷启动；排队、模型加载和首次调用初始化不要合并成一个数字。

启动验证：把等待、预热和执行分开

启动变慢时，先定位延迟发生在哪一段，不要直接归因于模型或 GPU。

RunPod：区分 cold start 与计费生命周期

按照 RunPod 的 Serverless 概览，cold start 是 endpoint 没有运行中的 worker 接到请求，到 worker 完成预热并可处理请求之间的区间。

另按 RunPod 的 Serverless 定价说明，从 worker 启动到完全停止的时间按秒计费，并向上取整到下一秒；容器初始化、模型加载、执行和 idle-timeout 都属于 worker 生命周期。验证时应分别记录请求前等待、worker ready、执行和请求结束后的空闲时间。

Modal：定位排队与首次调用初始化

Modal 的冷启动说明规定，已有可运行 container 时会复用；没有时，Modal 会启动新 container，这就是 cold start。文档把延迟来源分为等待 warm container，以及新 container 首次调用时的初始化。

全局作用域中的导入和 modal.enter 必须完成后，container 才能接收输入。模型权重可以提前下载。需要核对的参数名称为：

scaledown_window
min_containers
buffer_containers

延长 scaledown_window 可以降低后续请求遇到 cold start 的机会，但空闲资源仍会计费；min_containers 设置 container 数量下限；buffer_containers 在 Function 活跃时保留额外 container。把工作移入 modal.enter 并不会消除延迟，只会把它移到预热阶段。

Replicate：把共享队列与模型启动分开

根据 Replicate 的计费说明，public model 只对处理请求的 active processing time 收费，setup 和 idle time 不收费。默认使用与其他客户共享的硬件池和队列，因此可能出现排队、cold boot 或扩缩容限制；请求出现间隔后，实例会先空闲几分钟，再缩到配置的最小实例数，默认值为零。

多数 private model 使用独立硬件，不与其他客户共享队列，但快速启动的 fine-tune 是文档列出的例外。验证时应把 queue wait 与 setup time 分开记录。

性能验证：让结果来自同一测试场景

MLPerf：不要跨场景直接比较

若使用 MLPerf Inference 做规则化对照，MLCommons 的 MLPerf Inference Rules要求所有 submission 使用 LoadGen，由它按场景生成请求、跟踪延迟、检查准确性并计算最终指标。

Server 场景按 Poisson distribution 发送请求，并采用该 benchmark 指定的延迟约束；Offline 场景在开始时发送全部样本，不设置延迟约束；Single stream 则等待上一请求完成后再发送下一请求。LLM benchmark 还记录首 token 延迟 TTFT，以及生成 token 的平均间隔 TPOT。不同场景的结果不能直接横向比较。

GenAI-Perf 与 AIPerf：保留工具和指标定义

NVIDIA 的 GenAI-Perf README说明该工具不再主动开发新功能，并让新的性能验证需求转向 AIPerf。新建测试应按 AIPerf 当前文档选择命令，不要拼接未经核实的参数。

若只是复核已有 GenAI-Perf 流程，README 给出的 streaming 示例为：

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

该文档中的 TTFT 是请求发送至首个响应，Request Latency 是请求发送至最终响应，Output Token Throughput 是输出 token 总数除以 benchmark duration。采样窗口参数的准确名称为：

--measurement-interval

其单位为毫秒；采用默认 stability 设置时，benchmark 持续时间为该 interval 的三倍。

算力租赁成本：按账单口径完成比较

不要先填一个假定单价。只从自己的账单或报价复制真实行项目，再使用以下公式：

RUNPOD_TOTAL = Σ(YOUR_VALUE_BILLABLE_SECONDS × YOUR_VALUE_QUOTED_RATE)
MODAL_TOTAL = YOUR_VALUE_ACTIVE_AMOUNT + YOUR_VALUE_IDLE_AMOUNT + YOUR_VALUE_OTHER_AMOUNT
REPLICATE_PUBLIC_TOTAL = YOUR_VALUE_ACTIVE_PROCESSING_AMOUNT
COST_PER_SUCCESS = YOUR_VALUE_TOTAL_AMOUNT / YOUR_VALUE_SUCCESS_COUNT

RunPod 的秒数应按 worker 分别填写，并使用已经包含向上取整规则的计费秒数；存在不同 worker 类型或报价时，分别计算后加入总额。Modal 只相加账单或报价中真实存在的 active、idle 和其他应计项目。Replicate public model 使用 active processing amount；现有说明没有给出 private model 的统一计算公式，应直接按自己的报价或账单处理。

先设置自己的延迟和失败门槛，淘汰未通过项，再比较通过项的总费用、每次成功请求费用和失败数量。这样得到的是基于自身负载的选型结论，不是平台排名。

完成验证的检查清单

模型、请求、并发及冷热状态保持一致，冷启动与热运行结果分开。
排队、container 或 worker ready、初始化和实际执行分别记录。
性能工具、场景及 TTFT、TPOT、Request Latency 等指标定义保持一致。
费用能够对应到自己的账单或报价，失败请求和额外空闲时间没有被遗漏。
每次结论都附模型版本、环境配置、原始记录和文档版本。

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