MLPerf 测量的每秒令牌数是多少以及它们如何在 LLM 中使用？

硬件指南 » 基准 » MLPerf 测量的每秒令牌数是多少以及它们如何在 LLM 中使用？

如果您使用语言模型，您一定听过“每秒令牌数”这个术语上千遍，但很少有人详细解释它在实际环境中的含义，以及最重要的是，MLPerf 如何测量它。在本文中，我们将清晰地解释什么是令牌，为什么每秒令牌数指标在推理中如此重要，以及像 Databricks 和 MLPerf 基准测试这样的平台如何使用它来进行规模确定、比较和扩展。 此外，我们还包括来自制造商的具体数据以及云到地面的性能预期。.

这个问题并不小：业界已经标准化了每秒令牌数来评估数据中心和边缘的 LLM 性能。 经过同行评审的 MLCommons 套件 MLPerf 已成为比较硬件和软件的基准。与此同时，像 Databricks 这样的运营商已经根据每秒令牌数范围直接配置其模型端点。让我们结合数据和用例来详细分析一下。

什么是令牌以及它为什么在 LLM 中很重要？

语言模型不会按原样处理单个字母或单词；它们与称为标记的单位一起工作。 一个标记通常长约 4 个字符，或平均 0,75 个单词。该比率根据语言和模型的标记器而变化，但它可以作为快速参考：10 个单词的文本移动大约 13-14 个标记。

确切的分割取决于模型： 每个 LLM 使用自己的标记器，并将单词划分为完整的标记或子词例如，在线工具可以让你查看 Llama 如何标记特定短语。这种变化看似很小，却会影响延迟和计算成本。

当谈到生成率时，通常以每秒的令牌数而不是每秒的字数来表示。 这使得不同语言、上下文长度和输出样式之间的度量标准变得同质化。，并可以准确计算推理成本和所需容量。

为什么以每秒令牌数而不是 RPS 来衡量性能？

传统的 API 服务关注的是 RPS（每秒请求数）。在 LLM 中，这种方法存在不足： 根据输入令牌和输出令牌的不同，两个请求可能需要的时间可能有很大差异也就是说，实际有效载荷来自令牌，而不是“调用次数”。

造成差异的关键因素有两个。首先，输入上下文的长度： 简短的提示可能只有几个标记，但摘要文档可能会激增至数百或数千个。另一方面，输出的长度：总结通常会产生较少的标记；生成长篇文章或描述会增加时间，因为输出解码是最昂贵的部分。

因此，为了实际扩展推理端点，从令牌的角度思考会很有帮助。 例如，Databricks 为其服务端点提供每秒一系列令牌，并根据扩展按小时计费。这样，您就可以将容量与实际负载对齐，而不会被无法说明全部情况的 RPS 所欺骗。

Databricks 和 MLPerf 如何测量每秒令牌数

Databricks 以 RAG 的代表性负载作为参考，并总结道： 2048 个输入令牌和 256 个输出令牌。它结合了两个阶段（预填充和解码），并且默认情况下优化了每个请求 1 个批次大小的吞吐量和延迟之间的平衡，模拟了多个并发请求。

根据该规则，数字如下所示：如果您以每秒 2304 个令牌（2048 + 256）配置端点， 具有这些大小的请求大约需要一秒钟如果将其设置为每秒 5600 个令牌，则相同的请求将下降到大约 0,5 秒，并且每秒可以处理两个类似的请求。

当您的工作负载发生变化时，延迟也会发生变化。 生成更多输出标记比增加输入标记受到的惩罚更严重。如果您正在进行批量推理，请计算数据集的输入和输出标记的平均数量，并将其与之前的基准进行比较以估算时间。

实际示例：有 1000 行，平均 3000 个输入令牌和 500 个输出令牌，预置吞吐量为每秒 3500 个令牌， 这将花费你超过 1000 秒的时间 因为你的平均值超过了参考值。如果你平均输入 1500 次，输出 100 次，每秒配置 1600 个令牌， 你将低于 1000 秒 总共 1000 行。

按需自动伸缩和实际伸缩计算

Databricks Model Serving 包括快速自动缩放功能 根据每秒对令牌的需求增加或减少资源系统以容量块为单位进行扩展，额外容量仅在使用时计费。在并行请求较多的测试中，预置吞吐量不断增加，直至资源饱和，稳定在每秒 8000 个令牌左右，这会增加排队延迟。

如果您发现每秒的令牌数少于您标记的令牌数，请检查两件事： 预配置并发反映了端点指标和最小带宽大小 配置。使用此数据，可以使用以下公式估算实际扩展：预配置并发数 × 最小带宽大小 / 4。

举个具体的例子：最大并发数为 8，最小条带大小为每秒 850 个令牌， 有效限制为每秒 1700 个令牌 （8 × 850 / 4）。了解此计算方法可避免出现意外，并帮助您根据延迟 SLO 微调设置。

MLPerf 推理：它是什么以及它目前测量什么

MLPerf 由 MLCommons 开发，是用于测量数据中心和边缘 AI 性能的开放标准化套件，涵盖从视觉到 LLM 的各个方面。 其目标是以公平、可重复的方式比较平台，以提高生态系统的效率。近年来，重点明显转向 GenAI 和大型 LLM。

在第五版中，Llama 2 70B 被巩固为明星基准，取代了 ResNet50，并且 在一年内，每秒令牌数指标在最佳情况下提高了 3,3 倍，得益于硬件和软件的优化，平均性能提高了 5 倍。英特尔至强 6 等 CPU 在官方结果中的出现也表明 在某些情况下，高效的通用解决方案仍有发展空间.

MLPerf Inference 5.1 版又迈出了一大步：它纳入了三个新的关键基准， 使用 DeepSeek-R1 进行推理，使用 Whisper Large v3 进行语音转文本，以及基于 Llama 3.1 8B 的小型 LLM总体而言，该联盟报告有 27 名参与者，达到了 90.000 个结果的里程碑，并缩小了交互场景中的延迟指标。

新基准中的指标和目标

DeepSeek-R1 的推理基准（MoE 为 671B 个参数）表明 这些模型在得出答案之前会进行长链推理。支持最多 20.000 个 token 的输出，数据集中每个输出平均有 3880 个 token，是迄今为止推理中最大的。

这些规则以严格的限制来衡量离线模式和服务器模式下的吞吐量： 在 p2 下，第一个令牌的时间为 80 秒，每个令牌的延迟为 99 毫秒其目的是在“思考”预算与部署该预算所需的响应能力之间取得平衡。

以 Llama 3.1-8B 为门槛的小型 LLM 基准测试取代了 GPT-J 6B 作为门槛。 支持最多 128.000 个令牌的上下文 并在 CNN-DailyMail 上评估了 778 个输入标记和 73 个输出标记的摘要效果。准确度通过 ROUGE 进行验证，在闭式除法中，需要达到高精度基准的 99%。

在延迟指标中，使用两个指标：TTFT（第一个令牌的时间）和TPOT（每个令牌输出的时间）。 在服务器上，记录了 2 秒的 TTFT 和 100 毫秒的 TPOT。 （约 480 ppm），而在新的交互场景中，对于聊天、编码或创意工具等情况，则分别压缩至 0,5 秒和 30 毫秒（约 1600 ppm）。

制造商和运营商的业绩亮点

• NVIDIA 再次领先，这次是 Blackwell Ultra 在 GB300 NVL72 系统上得分 DeepSeek-R45 的推理吞吐量比 GB1 NVL200 高出 72%，创下新高，离线时每 GPU 每秒可处理 5842 个令牌，服务器上每 GPU 每秒可处理 2907 个令牌，与未经验证的 Hopper 相比，性能提高了近 5 倍。
• 在新的交互式 Llama 3.1 405B 基准测试中，NVIDIA 应用了 Dynamo 的分解服务，在不同的 GPU 上分离上下文和生成并通过 NVLink 传输 KV Cache，在 Blackwell 上实现比传统服务每 GPU 多 1,5 倍的吞吐量，比使用 Hopper 的系统多 5 倍以上。
• 对于较小的型号，NVIDIA 报告 Llama 18.000 3.1B 离线模式下每 GPU 每秒处理超过 8 个令牌 Whisper 中每 GPU 每秒 5667 个令牌，在所有场景（离线、服务器和交互）中保持 GPU 领先地位。
• AMD 通过首批 Instinct MI355X GPU 扩大了其市场份额，目前该产品属于 2-70B 系列。 它展示了多节点扩展能力，并且每秒令牌数比 FP2,7 中的 MI325X 增加了 8 倍公开赛中，对 Llama 3.1-405B (FP4) 进行了结构化剪枝， 使用深度修剪 82% 的模型，吞吐量可提高 21%，使用精细调整 90% 的模型，吞吐量可提高 33%，保持精度。
• 它还首次推出了 Llama 2-70B Interactive、Mixtral-8×7B 和 Stable Diffusion XL 的出货量，并展示了混合 MI300X/MI325X 的结果： 当扩展到 4 个节点时，MI355X 的吞吐量比 MI3,4X 高出 300 倍，可扩展至8个节点，具有良好的可扩展性。
• HPE 联合 ProLiant 和 Cray 发布了 14 项第一名的成绩。DL1a Gen380 在 12-GPU PCIe 系统中的 DLRM 和 Llama 3.1-8B（服务器）测试中脱颖而出；DL8 Gen385 Whisper 中的 GPU 性能更佳 配备 H200 NVL；Cray XD670（8× H200）在 RetinaNet、Llama 3.1-8B、Mixtral 和 Whisper 中获得了六项第一，并在 DLRM 中凭借 RTX Pro 6000 Blackwell SE 和 GH200 NVL2 的成绩获得了第一。
• CoreWeave 是第一个使用 GB300 报告结果的云，交付 DeepSeek‑R6005 每 GPU 每秒 1 个令牌 离线并演示使用 Kubernetes 上的 Slurm 进行编排和扩展以及拓扑感知调度，以充分利用 NVLink。
• 戴尔共交付了 12 套配备 AMD 和 NVIDIA 加速器的系统，在 LLaMA 2 70B Interactive 中表现出色，搭载 PowerEdge XE9680L 和 B200， XE3.1L+B8 上的 LLaMA 9685-200B 服务器、XE9685L 上的 SDXL 和 XE9680L 上的 Whisper，通过 LLM 展示了从图像到语音的多功能性。
• 英特尔强调，它仍然 唯一一个使用服务器 CPU 发送结果的 并表明，搭载 P 核的至强 6 处理器在五项基准测试中比第五代至强处理器性能提升了 1,9 倍，巩固了其在通用推理领域的地位。此外，该公司还推出了搭载 5 个 Arc Pro B8 GPU 的工作站，配备 60GB VRAM，可为多用户提供 Llama192-2B 服务，并捆绑了驱动程序和框架，以简化多 GPU 部署。
• 在集成商和合作伙伴中，华硕 通过量化、内核和堆栈优化延迟和吞吐量；Broadcom 在多种工作负载（Whisper、SDXL、Llama 3.1-405B、Llama2-70B、RGAT、RetinaNet）上演示了 VCF 虚拟化与裸机相比最小的开销；思科使用 UCS C885A M8（8× H200 SXM）和 UCS C845A M8（8× H200 NVL 或 L40S）几乎线性扩展，并由 One G200 网络支持。
• KRAI 使用 OpenAI API 和实际开销，将 SGLang 和 vLLM 与 Llama3.1-70B 进行了比较： 使用 SGLang 31.391 离线每秒 0.4.9 个令牌 在配备 26.319x H0.9.2 的单台服务器上，使用 vLLM 8 时达到 200 个令牌；通过动态量化，使用 SGLang 时达到 27.697 个令牌，使用 vLLM 时达到 30.893 个令牌，在多节点上，它在三台服务器上扩展到每秒 87.334 个令牌。
• Lambda 配备 8x B200 180 GB SXM，吞吐量有所提升 SDXL 最高可达 7%，Llama 15-3.1B 最高可达 405% 与上一轮相比，并提供带有托管 Kubernetes 或 Slurm 的 16 到 1536 个 GPU 的集群。
• MiTAC 携其 G8825Z5 系列在 LLaMA 2 70B Interactive 上大放异彩 每秒 18.846,1 个令牌 并在 Server 和 Mixtral 中取得了良好的效果；Nebius 在 GB200 NVL72、HGX B200 和 HGX H200 中验证了其虚拟化性能几乎与裸机相当， 服务器上每秒 596,11 个令牌，Llama 855,82-3.1B 离线时每秒 405 个令牌 配备 4 GB200 GPU。
• Red Hat 在其 AI 推理服务器上演示了 vLLM 作为受支持的运行时， 适用于 FP8 和 FlashAttention‑3 的 CUTLASS 内核 加上改进的 vLLM v1 引擎，为 H3.1 和 L8S 中的 Llama-100-40B 提供动力，具有极高的性价比。
• Supermicro 发布了搭载 Intel 和 AMD CPU 的 HGX-B200 8-GPU（空气和液体）的领先成果，突出 Llama 3.1-8B 和 Llama 2-70B 在服务器/离线/交互和 Whisper 上；在合作中，它表现出与 32× H100-SXM 和 MI325X 替代品的出色扩展性。
• Vultr 首次搭载 Supermicro AS-8126GS-TNMR 和 8x MI325X，证明了其作为云 GPU 的竞争性能；GATEOverflow 通过 MLCFlow 提高可重复性 在 RTX 4090 和 AMD/Intel CPU 上；Giga Computing 推出了 8U 风冷 EPYC+MI325X 和 Xeon+HGX B200 系统；QCT 除 6× MI200X 系统外，还涵盖了配备 H4 NVL（8 个 GPU）和 200× H5 SXM8 平台（配备 NVLink 和 GPUDirect Storage）的 Xeon 325 配置。

学术界也迎来了属于自己的辉煌时刻。佛罗里达大学推出了集成 HiPerGator 的 DGX B200 SuperPOD， 是第一个提交推理结果的机构 在封闭分区下满足服务器延迟要求，使用无需 Docker/Sudo 的 Apptainer，并适应多用户 SLURM。在另一个极端，在 M1 MacBook Pro 上进行单次提交， 使用 GPU 和神经引擎上的 ONNX Runtime 和 CoreML，超越了边缘类别的目标准确度，并证明可以在消费硬件上评估质量推理。

用户感知的速度和实际限制

用户体验不仅通过基准来衡量；在日常生活中， 当你每秒超过一定数量的令牌时，就会产生流畅的感觉一位用户评论说，他们的对话限制是每秒 4 个令牌，而故事写作的限制是每秒大约 10 个令牌；低于这个速度，互动就会感觉很慢。

如果你尝试在本地运行 LLM，则有三种情况。在桌面 CPU 上， 每秒移动 1-2 个令牌是正常的，对于长答案来说不可行。使用高端游戏 GPU，每秒可以获取近 5 个令牌。使用 NVIDIA H100，是的，我们已经在谈论每秒 60 个令牌了。 但它是数据中心硬件，而不是桌面硬件.

云端发生了什么？最强大的提供商凭借专用硬件和优化的推理堆栈，正在超越这些数字。 据报告，ChatGPT-119 上平均每秒产生约 4 个令牌，而 Gemini 上平均每秒产生 168 个令牌。而像 DeepSeek 这样的热门开源模型则徘徊在每秒 21 个词条左右。如果将其转换为单词，每秒 119 个词条大约相当于每秒 90 个单词。

运营结论：对于大多数用户来说， 在计算机上运行人工智能是可能的，但由于速度慢而不切实际为了以舒适的速度和紧密的延迟工作，托管服务仍然是明智的选择。

如何根据 TPS 调整端点大小以及预期延迟

确定规模的实用步骤。首先，概述您的用例： 输入和输出令牌的平均数量、长度分布和预期并发度. 其次，使用代表性数据集运行负载测试，包括 TTFT 和每个请求每秒维持的令牌数。

接下来，将配置与您的模式对齐。如果您的工作负载类似于 Databricks 参考（2048 输入，256 输出）， 选择每秒令牌的范围，以使请求符合所需的延迟预算请记住，复制输出通常比复制输入花费更多，并且有效并发取决于实际的自动缩放。

监控并调整。密切关注指标 预配置并发、队列、TTFT 和 TPOT并将其与您的 SLO 进行比较。如果容量不足，请扩大范围；如果资源过剩，请降低范围并调整块以节省资源。真正的扩展公式将帮助您理解，如果端点没有创建足够的副本，为什么它的性能无法达到配置要求。

最后，要注意场景。在交互式聊天机器人模式下， 目标是每个令牌的 TTFT 为 0,5 秒和 30 毫秒 这将为您带来卓越的用户体验。在服务器模式下，每个令牌 2 秒和 100 毫秒是合理的指导原则；在离线模式下，它会在保持基准测试所需准确度的同时，追求最大吞吐量。

纵观 MLPerf 趋势，趋势很清晰： 更多上下文、更多标记和更好的效率技术 — 分解服务、FP4/FP8、结构化修剪、自定义内核、KV 缓存调度 — 正在推动每个芯片和每个系统的代币上限同比第二年上升。

Databricks 和 MLPerf 绘制的整体图景是一致的： 以每秒令牌数来思考是推断 LLM 中的成本、延迟和可扩展性的正确方法。通过良好的代表性基准、TTFT/TPOT 指标和经过良好校准的自动缩放，可以在不增加基础设施规模的情况下提供快速、稳定的响应。