如何衡量 LLM 服务器的真实吞吐量

如果你在现代服务器租用基础设施上运行推理工作负载，那么LLM服务器吞吐量这个词就不该只是供应商幻灯片上的说法，或实验室演示中的数字。真实容量取决于排队行为、token 流动、请求类型组合，以及系统在负载下的实际表现。对于在美国服务器环境中构建系统的技术团队来说，目标其实很直接：衡量这套技术栈在并发用户、长提示词和持续流量同时出现时，究竟能真正交付什么。

很多关于吞吐量的讨论之所以失真，是因为它们把语言模型服务当成普通 Web 流量来看待。这种简化很快就会失效。生成式工作负载至少包含两个不同阶段：提示词处理和 token 生成。官方基准测试资料通常将其称为 prefill 和 decode，而它们对延迟的影响方式完全不同。首 token 时间不仅包含排队、提示词处理，还包括网络开销；而输出 token 吞吐量则反映流式输出开始后系统持续生成的效率。与单纯的请求数相比，这些指标重要得多。

为什么“真实吞吐量”不同于理论吞吐量

理论性能总是很整齐，真实性能却往往充满噪声。某台服务器在纸面参数上可能相当漂亮，但当提示词长度增加、内存压力上升，或多个会话同时进入 prefill 阶段时，它的表现可能会完全不同。官方基准测试指南指出，更长的输入序列会提高 prefill 成本，并可能拉长首 token 时间；而更长的输出则会给 decode 和 token 间延迟带来更大压力。换句话说，一个基准数字根本无法概括整个 LLM 服务。

因此，工程师不该再问“吞吐量是多少”，而应该提出更有价值的问题：

• 在低、中、高并发下，token 速率分别是多少？
• 在排队压力下，首 token 时间的稳定性如何？
• 延迟从哪个点开始上升得比吞吐量更快？
• 提示词长度会如何改变整体曲线形态？
• 系统在持续负载下是否能够平滑退化，而不是突然失稳？

这些问题揭示的是实际运行状态，而不是宣传材料里的理想化算术。

你真正应该跟踪的核心指标

在写任何基准测试脚本之前，先把指标定义清楚。如果衡量吞吐量的语言本身是模糊的，那么最终结果也一定是模糊的。

1. 首 token 时间（TTFT, Time to First Token）：从发送请求到收到第一个生成 token 之间的延迟。这是交互式场景中最直观的响应指标。官方文档将其视为面向用户的响应性指标，并指出其中包含网络延迟、排队和提示词处理。
2. Token 间延迟（Inter-Token Latency）：流式输出开始后，相邻生成 token 之间的时间间隔。这个指标能够揭示 decode 阶段的表现，并帮助判断输出是顺滑还是卡顿。
3. 输出 token 吞吐量（Output Token Throughput）：整个系统每秒生成的 token 数量。这是衡量生成式服务吞吐能力最直接的指标。
4. 请求吞吐量（Request Throughput）：每秒完成的请求数。它当然有用，但只有在输入和输出长度被严格控制时才真正有参考意义。
5. 尾部延迟（Tail Latency）：p95 或 p99 往往比一个好看的平均值更重要，因为生产环境中的真实问题通常都出现在尾部。
6. 失败率（Failure Rate）：超时、空响应、重试以及与内存相关的崩溃，都应该被纳入最终报告。

对于技术读者来说，最关键的原则是：不要在没有延迟数据的情况下谈吞吐量，也不要在不说明负载形态的前提下谈延迟。

在开始测试之前，先理解 prefill 和 decode

大多数基准测试错误，根源都在于忽视了阶段行为。Prefill 是模型处理输入上下文的阶段，decode 则是模型逐步输出 token 的阶段。多份官方资料都强调，这两个阶段对系统的压力来源并不相同，而且 prefill 阶段的并发情况会显著影响排队深度与首 token 延迟。

这之所以重要，是因为“短提示词 + 长输出”和“长提示词 + 短输出”可能呈现完全不同的系统瓶颈。如果你的工作负载涉及检索、代码上下文或多轮记忆，那么 prefill 很可能主导用户体验；如果你的工作负载需要持续生成长文本，那么 decode 效率就可能成为真正的上限。

一个实用的思维模型可以这样理解：

• Prefill 主导型负载：对提示词长度、排队与准入控制更敏感
• Decode 主导型负载：对 token 调度、内存带宽和批处理效率更敏感
• 混合型负载：两者都敏感，而这其实才是很多生产系统的真实状态

如何设计一个贴近生产环境的基准测试

只有当基准测试接近你计划运行的真实服务时，它才有价值。这并不意味着要复制每一个边缘场景，而是要控制那些真正影响系统行为的关键变量。

1. 固定模型与运行路径。除非某项变更本身就是实验目标，否则不要在量化方式、调度参数或并行布局变化后横向比较结果。
2. 固定提示词与输出范围。没有 token 数量约束的吞吐量数据，几乎没有解释价值。
3. 先完成预热。首次运行的额外开销可能来自惰性初始化、图捕获或缓存填充，这会污染结果。
4. 将单用户测试和并发测试分开。前者用于观察基础响应，后者用于评估服务容量。
5. 测试时间要足够长。过短的突发测试会掩盖温度、排队或内存层面的问题。
6. 采集系统遥测数据。GPU 利用率、内存占用、CPU 压力和网络表现不是可有可无的附注，它们是解释结果的关键层。

官方的生成式系统基准测试工具通常支持合成输入或数据集驱动输入、基于并发的压测、基于请求速率的压测，以及导出日志供后续分析。这使得工程团队可以构建可重复的测试流程，而不是只截几张终端截图了事。

一套适合极客运维视角的实用测试矩阵

如果你的网站面向美国基础设施采购者，那么读者多半是在做架构选择，而不是阅读纯理论。因此，给他们一套能直接跑起来的测试矩阵，远比抽象解释更有价值。

• 场景 A：短提示词、短输出、低并发
• 场景 B：短提示词、长输出、中等并发
• 场景 C：长提示词、短输出、中等并发
• 场景 D：长提示词、长输出、逐级提升并发
• 场景 E：混合提示词长度，并叠加持续背景流量

然后以阶梯方式逐步提高并发，而不是一开始就把并发值拉到极限。这样做可以找出曲线的拐点，也就是输出 token 吞吐量不再足以抵消延迟代价的那个位置。官方的生成式服务基准测试建议也强调，应仔细扫描并发度以及输入输出长度，因为这些参数会直接决定测试结果是否有实际意义。

对很多团队而言，最有价值的图表并不是“最高吞吐量”，而是“服务从响应顺畅变得迟滞的转折点”。

测试过程中应该记录什么

单纯的基准测试输出永远不够。你需要把请求侧视角和系统侧视角配对起来看。

• 请求开始时间和完成时间
• 首 token 时间戳
• 输入 token 数和输出 token 数
• 每个请求的状态，包括失败条件
• 正在处理中的并发请求数
• GPU 利用率和显存占用
• 主机上的 CPU 与 RAM 压力
• 如果客户端位于远端，还要记录网络延迟

当数字看起来不对劲时，这些日志能帮助你判断问题究竟来自排队堆积、提示词膨胀、decode 变慢，还是主机层面的瓶颈。没有这些信息，工程师往往会把问题归因到错误的层。

那些会让结果失去意义的常见测试陷阱

在 LLM 吞吐量测试中，有一些错误几乎反复出现。

1. 只测一个并发值。这样根本看不到系统曲线的形状。
2. 忽视提示词长度。微小的合成提示词几乎无法代表检索型流量。
3. 只看平均延迟。用户真正会抱怨的是尾部延迟。
4. 把冷启动和热启动混在一起。初始化开销会污染样本。
5. 在不同 token 预算下比较请求吞吐量。这根本不是同一维度的对比。
6. 报告 tokens per second 时，不说明是系统总吞吐还是单用户吞吐。官方资料之所以区分这两种视角，是有充分原因的。
7. 让客户端先成为瓶颈。性能不足的压测端会伪造服务器上限。

还有一个容易被忽略的陷阱尤其值得单独提出：协调遗漏。关于 prefill 并发的官方文档提到，如果基准测试工具在等待空闲槽位时自动放慢节奏，那么整个测试可能会无意中把自身节流到与服务器容量一致。这会让延迟表现看起来比真实开放流量场景下更好。

如何像运维工程师一样解读结果

当测试结束后，不要急着把最大的数字当成赢家。真正有价值的解读，永远是在分析权衡关系。

• 如果 TTFT 一直较低，但 token 流变得断断续续，那么限制因素很可能出在 decode 阶段。
• 如果长提示词让 TTFT 急剧上升，那么问题可能来自 prefill 或排队准入。
• 如果吞吐量上升了，但 p99 延迟也暴涨，那么你很可能已经超出了可用运行区间。
• 如果结果很差时 GPU 利用率却并不高，那么瓶颈可能在调度、CPU 处理流程或客户端路径上。
• 如果失败只在持续负载下出现，那么你的栈更可能是稳定性出了问题，而不是算力本身不够。

优秀的运维人员关注的不是“最大数字”，而是“高效区间”。所谓高效区间，就是吞吐量足够强、延迟仍然可预测、尾部表现也仍然符合应用要求的那一段工作区间。

为什么这对美国服务器租用和服务器托管规划很重要

对于正在评估服务器租用还是服务器托管的团队来说，吞吐量测试绝不只是实验室里的练习。它会直接影响容量规划、资源密度设计和服务形态选择。一份扎实的基准报告能够告诉你，当前系统更适合围绕响应速度优化、围绕批量效率优化，还是围绕内存余量优化。它也能帮助你估算，在服务质量开始恶化之前，一套部署究竟能支撑多少会话。

这在美国服务器部署中尤其重要，因为这里对延迟的预期通常比较严格，而生产流量又可能随着地区、工作负载模式和业务时段发生变化。做聊天式交互的团队，也许更看重首 token 速度；运行后台批量生成的团队，则可能更关注总体输出 token 吞吐量。基准测试应该反映这种运营现实，而不是强行追求某个放之四海而皆准的单一目标。

一套可以反复复用的简单测试流程

1. 记录硬件和软件环境。
2. 用一组固定的小请求对服务进行预热。
3. 先跑基线单请求测试。
4. 逐步扫描并发度。
5. 用更长的提示词重复扫描。
6. 再用更长的输出重复一次。
7. 执行持续性测试，观察漂移和失败情况。
8. 将 TTFT、token 间延迟、尾部延迟和总体 token 吞吐量结合起来分析。
9. 标记出最符合目标应用的运行区间。

这套流程足够简单，便于重复执行；同时也足够严格，能够产出真正有工程价值的证据。

最后的思考

LLM 服务器吞吐量并不是一个营销数字，而是在明确工作负载下，prefill、decode、排队、并发和系统边界共同作用后的结果。只要你认真衡量这些动态因素，就能在架构、容量和美国服务器租用策略上做出更明智的决定。如果跳过这一步骤，基准测试就只剩下表演意义。对于技术团队来说，真正的目标不是追逐最响亮的数字，而是找到一个稳定运行点：在那里，延迟仍然合理，token 流保持顺滑，基础设施效率也足够高。