AI 推理平台选型：延迟、吞吐与成本验证

建立统一测试流程，分别记录首 token 延迟、输出 token 延迟、请求与 token 吞吐，再按实际资源账单核算单位请求成本，让平台选型有可复核、可追溯的依据。

大模型部署平台选型不要只看一次峰值：先锁定模型、请求分布和输出长度，再分别验证首 token 延迟、后续 token 延迟、请求吞吐和输出 token 吞吐，最后把同口径结果换算成单位成本。只有测试配置、原始结果与资源账单能够互相对应，候选平台之间才可比较。

大模型部署的选型口径：先固定系统边界

按 MLPerf Inference Rules，system under test 是接受性能测量的软硬件资源集合；所有提交都要使用 LoadGen 按场景生成查询、跟踪延迟、验证准确性并计算最终指标。即使只做内部选型，也应固定模型与权重、推理服务及版本、GPU 型号和数量、容器镜像、endpoint、客户端、输入输出分布、并发与缓存状态。

每轮保存完整命令、配置和原始报告，一次只改变待比较项。否则，模型差异、客户端位置或缓存状态都可能混入平台差异。

延迟：统一 TTFT、ITL 与 TPOT 的含义

在 vLLM Benchmark CLI 文档中，TTFT 是客户端从发出请求到收到首个 streamed output 的时间；ITL 是相邻 streamed output 的间隔；TPOT 每请求计算一次，并排除首 token。启用 speculative decoding 后，一个 streamed output 可能包含多个 token，ITL 与 TPOT 因而不能互换。

同一报告还列出 request throughput、output-token throughput 和 total-token throughput。选型时应把用户等待首响应与持续生成阶段拆开，并在相同输出长度、成功请求口径下比较。

吞吐：先确认场景，再比较指标

MLPerf Inference Rules对不同场景采用不同负载和指标：

Server 按 Poisson distribution 发送查询，使用场景特定的延迟约束，指标是系统支持的最大 Poisson 吞吐。
Offline 在开始时用一个 query 发送全部样本，没有延迟约束，指标是 measured throughput。
Single stream 在前一请求完成后发送下一请求，指标是第 90 百分位提前停止延迟估计。

不要把 Server 的最大吞吐与 Offline 的 measured throughput 直接排列。候选平台必须在相同场景、到达方式、延迟约束和请求分布下比较。

可复现测试：固定数据、负载与命令

按 vLLM 的 Benchmark CLI 文档，vllm bench 用于功能评估和回归测试，生产服务器基准则指向 GuideLLM。ShareGPT 支持在线和离线基准，可按文档提供的地址下载：

wget https://huggingface.co/datasets/anon8231489123/ShareGPT_Vicuna_unfiltered/resolve/main/ShareGPT_V3_unfiltered_cleaned_split.json

对已经运行的 vLLM 服务，先执行文档中的在线命令：

vllm bench serve \
  --backend vllm \
  --model NousResearch/Hermes-3-Llama-3.1-8B \
  --endpoint /v1/completions \
  --dataset-name sharegpt

需要模拟受控负载时，可填写自己的请求速率和并发上限：

vllm bench serve \
  --backend vllm \
  --model NousResearch/Hermes-3-Llama-3.1-8B \
  --endpoint /v1/completions \
  --dataset-name sharegpt \
  --request-rate YOUR_VALUE \
  --max-concurrency YOUR_VALUE \
  --burstiness 1.0 \
  --ramp-up-strategy linear

--request-rate 控制每秒目标请求数，默认值 inf 表示最大吞吐并立即发送全部请求；--max-concurrency 限制未完成请求数，不设置时并发不限；--burstiness 1.0 表示 Poisson 流量。使用自有数据时，文件应为 JSONL，每条包含 prompt 字段，并选择 --dataset-name custom。

重复对同一服务器运行 vllm bench serve 可能复用 prefix cache 并抬高吞吐，因此重复结果不能直接当作独立验证。

API 中间层：确认流式与进程模型

如果请求经过 FastAPI，应确认接口使用 response_class=StreamingResponse。根据 FastAPI 的流式响应文档，路径函数可以通过 yield 逐块发送数据；使用 StreamingResponse 时，应用负责生成并编码要发送的字节。流式行为不一致，会使首 token 延迟缺少可比性。

FastAPI 的容器部署文档建议在 Kubernetes 由集群负责复制时，每个容器运行一个 Uvicorn 进程，而不是增加 --workers。Dockerfile 的 CMD 应使用 exec form，官方示例为：

CMD [ "fastapi", "run", "app/main.py", "--port", "80" ]

比较候选方案时，应把 worker、container 和 replica 数量一并固定。

成本验证：用同一测试窗口核算

成本不能只从吞吐报告反推。登录每个候选提供方的当前定价页、报价页或账单，逐项确认其实际列出的 GPU、CPU、存储、网络、平台服务及其他费用；同时查清计费单位、最低计费量、空闲资源、启停和自动扩缩容规则。若页面没有明确说明，应向提供商确认，不能自行补值。

把测试期间的每项费用关联到资源标识和起止时间，再用自己的账单数值填写：

YOUR_TOTAL_COST = YOUR_GPU_COST + YOUR_CPU_COST + YOUR_STORAGE_COST + YOUR_NETWORK_COST + YOUR_PLATFORM_COST + YOUR_OTHER_LISTED_COST

cost_per_successful_request = YOUR_TOTAL_COST / YOUR_SUCCESSFUL_REQUESTS
cost_per_output_token = YOUR_TOTAL_COST / YOUR_OUTPUT_TOKENS

官方材料没有提供适用于所有平台的统一成本表，实际结果取决于提供商和项目的当前文档。只有模型、负载、延迟约束、吞吐口径和测试窗口一致时，单位成本才适合横向比较。

常见出错点与验收

验收材料至少应包含系统配置清单、数据版本或哈希、完整命令、工具版本、指标定义、原始结果、失败请求记录和账单映射。常见错误是混用 TTFT、TPOT 与 ITL，改变并发或缓存状态后继续比较，以及把测试窗口外的资源费用计入成本。

NVIDIA 在 GenAI-Perf README中说明，该工具不再积极开发新功能，新的性能基准工作应转向 AIPerf；迁移时不要直接沿用旧命令和参数。

本文只依据正文所链接的官方文档整理，未运行或测量任何平台；使用前应按当前版本复核命令、配置和指标定义。