同一块H100，每百万Token成本为何差5.5倍？

同一块 H100、同一个小时、同样的租金——单请求跑出来的每百万 Token 成本，可能比批量并发高出近 5.5 倍。一位开发者用 vLLM 实测了这组数字，并把它开源了出来。

一组真实的 H100 成本对照实验

实验配置很干净：vast.ai 上一块 H100 SXM 80GB，每小时 2.689 美元，20 vCPU。推理框架用 vLLM 0.27.1 官方镜像，模型是 Qwen2.5-0.5B-Instruct（fp16），所有 prompt 都是唯一的，避免缓存干扰。数据来源不是客户端估算，而是 vLLM 自己的 /metrics 计数器，和客户端记录完全一致。

测试分两种负载，各跑三轮：

• 单请求串行：每个请求解码速度 648–649 tokens/s，整台服务器产出 589–593 tokens/s，折合 约 $1.26 / 百万输出 Token。
• 8 请求并发：每个请求降到 549–573 tokens/s，但整台服务器产出 3,194–3,348 tokens/s，折合 约 $0.22–0.23 / 百万输出 Token。

同一块卡、同一个小时、同一个价格，结果差约 5.5 倍。

vLLM 与连续批处理

vLLM 是当前主流的开源大模型推理引擎，核心创新是 PagedAttention——把 KV Cache 按块管理，像操作系统管理内存分页一样，从而大幅减少显存碎片、提高显存利用率。它另一个关键特性是连续批处理（continuous batching）：请求不必等到同一批次全部结束才一起释放，而是每生成一个 token 就动态地把新请求插入批次、把已完成的请求移出。这正是文中并发负载能显著提升整机吞吐的底层机制——GPU 的矩阵计算单元在被多个请求的序列共享时，利用率远高于只服务一个请求。文章提到的 /metrics 是 vLLM 暴露的 Prometheus 格式监控接口，其中的计数器记录了实际处理的 prompt token 数和生成 token 数，因此比客户端做时间戳估算更可靠。

常见的成本估算错在哪

很多成本估算的做法是：拿一个请求的推理速度，去除以每小时租金。按这个逻辑，8 并发时单请求约 549–573 tokens/s，算下来每小时是 $1.30–1.36 / 百万 Token。

但真实成本是 $0.22–0.23。每一轮里，服务器整体产出都是单请求视角的 5.65–5.84 倍。

也就是说，用单请求速度来推算成本，在这个负载下会高估约 5.7 倍。换一个负载，这个倍数又会不同——关键在于倍数本身不是一个常数，而是你实际负载的函数。

吞吐量、延迟与并发的关系

在推理系统中，单请求的 token 生成速度（延迟指标）和整台服务器所有请求合起来每秒产出的 token 数（吞吐指标）是两个不同的量。当并发升高时，GPU 需要在多个序列之间调度计算，每个请求的响应速度可能略微下降，但由于原本空闲的计算时间被填满，整机吞吐会成倍上升。文中的数字恰好体现了这一点：8 并发下单请求从约 648 降到约 550 tokens/s，而整机产出从约 590 跃升到超过 3,200 tokens/s。因此，用「单请求速度 ÷ 租金」求单位成本，等于忽略了 GPU 在真实高并发场景下被多个请求共享的事实，得到的自然是远高于实际的数字。

决定真实成本的三个变量

作者把影响成本的因素归纳为三点，每一点都容易被忽视：

1. 服务器真实并发数，而不是 benchmark 里跑出来的并发数。你的业务峰值和均值，才是定价依据。
2. 小时内的空闲时间。GPU 等待时照样计费，所以每 Token 成本应该是「小时租金 ÷ 这一小时服务器实际产出的全部内容」，包括空闲时段。
3. scale-to-zero 的冷启动开销。在同一块 H100 上，一次冷唤醒大约占用了 77.3 计费秒中的 75 秒，服务器才具备应答能力。这意味着弹性伸缩并非免费午餐。

scale-to-zero 与冷启动

scale-to-zero 指在无请求时把 GPU 实例缩容到零、停止计费，待有新流量时再重新拉起。听起来能消除空闲成本，但重新拉起过程包含容器镜像拉取、模型权重从磁盘或网络加载到显存、CUDA 上下文与推理引擎初始化等步骤，耗时可能从几十秒到数分钟。文中提到的例子是：77.3 个计费秒里有约 75 秒花在冷启动上，服务器才真正具备应答能力——也就是说这段时间你付了钱却没有产出任何 token。在按秒计费或按小时计费的 GPU 租赁模式下，频繁冷启动会把成本重新推高。因此是否采用 scale-to-zero，取决于你的流量是持续稳定还是低频突发，以及单次冷启动的开销相对单次业务量的比例。

小卡上比例依然成立

为了验证结论不是 H100 独有，作者在 T4 上用同一个模型和测试方法复现了一遍。8 并发时，单请求解码 122–124 tokens/s，整台服务器产出 701–708 tokens/s，同样是约 5.7 倍。

这说明并发摊薄成本的效应，并不依赖于某一代硬件。

作者明确划出的边界

作者自己也强调了几点限制：这是小模型（0.5B）、单卡、每种负载只跑了三轮。换成 7B 或 70B 模型、换一台服务器、或者更长的 prompt，数字都会变。

我不是在说你的成本就是 $0.22。我是在说，这个数字取决于你的负载，只有实测你自己的服务器才能知道。

方法、原始数据和开源工具已发布在 GitHub（qaisermehdi3-coder/qvunex），作者也公开征集其他人在不同负载下测得的每 Token 成本，希望做横向对照。

对自建推理成本核算的启发

这组数据的价值不在于 $0.22 这个具体数字，而在于它戳破了一个常见的假设：单位推理成本和硬件单价之间有稳定的换算关系。实际上，中间还隔着一层「利用率」。

对做私有部署或租用 GPU 跑推理的团队来说，与其纠结买哪块卡、哪家云更便宜，不如先回答两个问题：你的服务在真实流量下的并发曲线是什么样？空闲时段占比多少？这两个答案对成本的影响，可能比换个供应商大得多。

把 vLLM 的 /metrics 接口接进自己的监控，定期记录实际产出 Token 数与计费时长，是比任何 benchmark 都更接近真相的做法。