度量大模型推理性能——解析 2026 年的 Token 生成效率
在生成式 AI 部署中，你通过一系列关键指标来衡量大模型推理性能。Time to first token（TTFT，首 Token 延迟）用于跟踪提示处理时延；time per output token（TPOT，单 Token 生成时间）和 inter-token latency（Token 间延迟）用于衡量输出生成速度；tokens per second（每秒 Token 数）反映系统吞吐量，而 Goodput 则统计在严格服务目标下成功完成的请求数。
在 2026 年的生产环境中，例如部署在日本独立服务器集群上的大规模系统，你通过硬件利用率对运营成本的压缩程度来定义 Token 生成效率。一条清晰的计算边界将大语言模型的执行划分为两个阶段：预填充（prefill）阶段并行处理输入 Token，形成以计算为主的瓶颈；解码（decode）阶段按顺序生成 Token，带来以内存带宽为主的限制。工程师利用这些性能指标，在大模型推理优化过程中定位系统极限。
关键要点概览
- 大模型处理包含两个阶段：预填充阶段快速处理提示词，解码阶段相对缓慢地产生文本。
- Goodput 通过只统计满足延迟目标的输出 Token，来衡量系统真实成功率。
- 连续批处理可以消除内存浪费，将系统速度提升至原来的 3 倍左右。
- 推测解码利用小模型加速词元生成，同时不牺牲输出质量。
- 现代图形芯片可以降低运营成本，并高效运行大语言模型。
大模型 Token 生成机制：预填充 vs 解码
你需要理解大语言模型在处理用户请求时的两个不同计算步骤：预填充阶段负责处理初始提示词，解码阶段负责生成响应文本。每个阶段在大模型执行期间都会带来独特的运行需求。
预填充阶段与算力瓶颈
在预填充阶段，模型会同时摄取全部输入 Token。你通过测量这一阶段来确定部署中的首 Token 延迟（TTFT）。当大模型收到一个提示词时，加速器会并行计算所有提示 Token 对之间的注意力得分。例如，对于 4096 个 Token 的输入提示，大约会产生 1680 万次注意力得分计算。
| 运行指标 | 预填充阶段 | 解码阶段 |
|---|---|---|
| 主要执行模式 | 并行批量处理 | 顺序 Token 生成 |
| 算术强度 | 200-400 ops/byte | 60-80 ops/byte |
| GPU 利用率 | 90-95% | 20-40% |
| 硬件约束 | Tensor Core（计算） | 内存总线（带宽） |
这种并行执行在硬件上实现了高度的数据复用。例如，在 70B FP16 模型上处理 1024 Token 的预填充时，其算术强度约为 1020 FLOP/byte，远高于 NVIDIA H100 SXM GPU 的 295 FLOP/byte“山脊点”（ridge point）。高算术强度会将 Tensor Core 利用率推高至 90–95%，使得计算吞吐成为主要瓶颈。
解码阶段与内存带宽限制
解码阶段按顺序逐个生成输出 Token。每个生成的 Token 都需要对整个网络进行一次独立的前向计算，导致在多步输出中形成较长的 Token 生成时间。例如，对于 1024 个输出 Token，你的系统必须执行 1024 个连续的步骤。
在每一次解码步骤中，硬件都需要从显存中读取完整的模型权重以及已缓存的 KV（键值）向量。以批大小为 1 的 70B FP16 模型为例，每生成一个 Token 大约需要读取 140 GB 的权重数据。这种持续的数据流会将算术强度拉低至 60–80 ops/byte，同时将 GPU 利用率降至 20–40%。
内存带宽会成为系统限制因素，因为 GPU 大部分周期都在等待权重传输。通过增大批大小，可以将这些权重读取开销摊薄到多个请求上，从而提升总吞吐。合理优化内存带宽可以稳定性能，并在生产工作负载下整体提升 Token 生成效率。有效管理这些硬件约束，可以在高并发推理任务中加速大模型推理流水线，同时降低整体硬件运营支出。
延迟与响应性的关键指标
在生产环境中，你通过跟踪各执行阶段的关键指标来评估用户体验。服务系统采用统一的公式计算端到端响应时长：Latency = TTFT + (TPOT * 输出 Token 数)。该公式将初始提示处理时间与累积 Token 生成时间相加，准确衡量整体系统响应性。
TTFT、TPOT 与 Token 间延迟
模型参数规模和部署硬件会直接决定服务速度。以 LLaMA-2 模型为例，在引擎版本 0.6.1、4 张 NVIDIA A100 GPU、25 个并发用户的条件下，基准测试凸显了这些关键运行权衡：
| 模型规模 | TTFT p50（秒） | TTFT p95（秒） | TTFT p99（秒） | TPOT p50（秒） | TPOT p95（秒） | TPOT p99（秒） |
|---|---|---|---|---|---|---|
| 7B 模型 | 0.24 | 0.89 | 1.42 | 0.019 | 0.037 | 0.056 |
| 13B 模型 | 0.31 | 1.12 | 1.78 | 0.033 | 0.067 | 0.096 |
| 70B 模型 | 0.87 | 2.34 | 3.67 | 0.122 | 0.231 | 0.343 |
在更低并发、基于 NVIDIA H100 GPU 的场景下，较小的模型变体（如 Llama 3.1 8B）可实现小于 80 ms 的首 Token 延迟，以及 11–21 ms 的 Token 间延迟。模型架构同样会影响推理执行时的 Token 延迟。Mixture-of-Experts（专家混合）架构每层只激活部分参数，相比稠密网络可将前馈网络通信开销降低约 50%；而更浅的网络层数则能减少顺序生成过程中的 Token 间延迟，从而提升整体大模型性能。
尾部延迟与分位数分布
企业环境会精细监控 Token 使用情况，以在不断扩大的上下文窗口中保持效率。系统提示在数百万次请求中重复，会产生巨大的指令开销；动态请求批处理可以将这类指令开销最多降低 96.5%，避免严重的计算和内存浪费。
现代连续批处理引擎会优先调度提示预填充，而非正在进行的解码步骤。这种调度策略会带来特定的运行瓶颈：
- 插入预填充任务时，会暂时中断正在进行的解码迭代。
- 在峰值负载下，这类执行停顿会让输出 Token 生成延迟数秒。
- 调度延迟会导致 P99 Token 间延迟指标出现严重尾部延迟尖峰。
工程师必须基于完整的统计分布来分析性能指标，而不能只依赖平均值。平均值会掩盖资源争用下的延迟尖峰。通过跟踪高分位数，可以看清队列瓶颈在高负载时如何影响真实终端用户。将整体 tokens per second 吞吐与严格的总延迟上限平衡起来，有助于维持服务质量。你需要通过调整引擎参数来稳定大模型推理流程中的排队延迟；对性能指标进行严密监控，可在请求量增长时保证高响应性。
度量大模型推理性能与吞吐量
你通过对比标准系统吞吐量与实际生成速度来评估服务能力。传统 API 工具在客户端侧通过每秒请求数（RPS）和每秒 Token 数（TPS）来报告吞吐。客户端工具 GenAI-Perf 通过向兼容 OpenAI 的服务端点发送工作负载流量，在在线压测中跟踪这些性能指标。
每秒请求数与并发扩展
你必须同时分析每秒请求数与每秒 Token 数，才能充分理解整体批处理效率。标准 API 端点通过已完成的客户端请求数来跟踪一般服务能力，而聊天服务则通过输出 Token 的每秒生成速度来监控实时性能。
- 客户端侧的 Token 生成吞吐反映了用户在流式会话中的主观传输速度。
- 服务端场景会在固定延迟目标下评估 TTFT 与 TPOT，例如 450 ms 的首 Token 延迟和 40 ms 的单 Token 生成时间。
- 离线场景则在完整数据集运行中，聚合每秒生成的总输出 Token 数。
针对批处理优化的基准测试往往通过固定长度提示、在预热完成的 GPU 上运行，以掩盖实际运行中的停顿。混合提示长度会在真实环境中导致 GPU 利用率下降和动态排队延迟。冷缓存未命中也会增加交互用户的总延迟。你应结合请求量与实际输出 Token 度量，来优化部署硬件的资源分配。
Goodput 与 SLO 达成率
原始吞吐数据并不能保证用户在企业使用场景中真正满意。你通过跟踪生产集群中的 Goodput 来度量有效服务成功率。Goodput 统计的是在单位时间内，完全在服务等级目标（SLO）内完成的成功请求 Token 数。
| 指标 | 定义 | 测量方法 |
|---|---|---|
| 服务等级目标达成率 | 在所有 Token 交付期限内完成的请求占比 | 只统计满足目标时间条件的完整请求 |
| Goodput | 满足服务等级目标的 Token 吞吐 | 用成功输出的 Token 数除以总服务时间 |
| 平滑 Goodput | 连续化的服务收益计算 | 通过惩罚延迟 Token 而非直接丢弃超时请求来计算 |
测量 Goodput 有助于将真正的运营交付速度与被浪费的计算步骤区分开来。高负载会增加排队延迟，从而削弱交互性能。现代推理工具通过扣减基于用户体验标定的延迟惩罚来计算平滑 Goodput，这一连续指标可以帮助你在真实流量高峰下评估大语言模型表现。你可以通过调优执行批处理方式，在保证所有节点满足严格延迟阈值的前提下，维持高大模型性能。对这些关键指标的标准化度量，有助于构建可扩展、具成本效益的大模型推理流水线；跟踪 Goodput 能确保推理平台在不浪费硬件算力的情况下，持续提供稳定响应。
优化大模型推理中的系统权衡
优化大模型推理需要在处理速度与硬件内存使用之间进行平衡。传统静态批处理会导致严重的服务器延迟，因为短输出必须等待长输出完成。现代服务框架通过连续批处理和高级内存管理来解决这一问题。
连续批处理与内存管理
连续批处理在迭代级别上运行，以高效处理动态工作负载。系统调度器会在每个迭代步骤后检查当前活动请求队列。
- 内存引擎将序列缓存数据划分为逻辑内存块。
- 运行时将这些逻辑块映射到物理显存块。
- 块表跟踪分散在物理内存中的所有逻辑映射。
- 服务引擎会随着序列生成 Token 动态分配新的内存块。
- 请求结束后，系统会立即释放对应的序列内存块。
- 引擎会将等待中的请求插入空闲批次槽位，而不会拖慢正在执行的序列。
这种动态方式消除了预分配内存的浪费。PagedAttention 在生产流量下可将内存浪费降低至约 4%。
| 工作负载类型 | 固定批处理（请求/分钟） | 连续批处理（请求/分钟） | 吞吐提升 |
|---|---|---|---|
| 混合响应长度（50–800 Token） | 25 | 85 | 3.4x |
| 交互式聊天（轮次可变） | 35 | 110 | 3.1x |
| 稳定短响应（<100 Token） | 60 | 95 | 1.6x |
| 长文本生成（平均 >500 Token） | 12 | 28 | 2.3x |
在多种响应长度下，你都能获得显著的吞吐提升。
- 连续批处理在已有请求释放显存后，立即接纳排队请求。
- 在顺序生成步骤中，GPU 批次始终保持高填充度。
- 短序列会提前结束，而剩余序列则在不增加额外延迟的情况下继续生成。
更高的并发会让 Token 生成步骤变慢，因此你必须将连续批处理与模型优化结合起来，才能在高用户量下保护系统效率。
推测解码与解耦式服务
推测解码通过在主模型旁边运行一个更小的草稿模型来加速推理。草稿模型可以快速生成候选 Token，而大型目标模型则以并行方式在一次前向计算中验证这些候选 Token。
| 加速效果 | 条件 |
|---|---|
| 最高 111% 吞吐提升 | 为 LLaMa-65B 设计的新草稿模型，相比既有草稿模型，在保持准确率的同时提升吞吐。 |
| 超过 60% 吞吐提升 | 在参数总量不变的前提下，用更深而更窄的新草稿模型替代既有模型。 |
| 97%–111% 吞吐提升 | 在温度采样对比实验中，NoFT-Wide-796M 草稿模型相对某已微调模型的表现。 |
这种执行方式在完全保持目标输出质量的前提下，显著降低生成延迟。你可以在无需重新训练大模型的情况下，获得更快的单 Token 生成速度。
多节点部署会将计算密集的预填充操作与内存密集的解码步骤拆分到不同的 GPU 集群上。
| 结论 | 发现 |
|---|---|
| 延迟改进 | PPD（预填充/解码解耦服务变体）在保持 TPOT 竞争力的同时，将第 2 轮及之后的 TTFT 降低约 68%。 |
| 吞吐与负载行为 | PPD 在高负载下缓解 KV 传输拥塞。 |
| 架构原理 | 将预填充与解码物理拆分到不同 GPU 资源池，可以消除相互干扰，使 P/D 资源独立扩缩并支持硬件多样化。 |
在异构部署中使用 A100 系统可以至少将单 Token 延迟降低 2 ms；而 25 Gbps 以太网下的跨节点数据传输，每个 Token 的额外开销最多约 0.21 ms。通过解耦节点，可以在分布式集群中优化大模型推理流水线；针对性硬件优化可以在生产规模下稳定响应延迟。
2026 年生产基线与决策框架
你必须设定清晰的基线目标，才能在真实生产环境中评估系统效率。生成式 AI 基础设施需要对延迟目标与算力上限进行严格监控，不同用户任务在实际部署中对应不同的性能目标。
按工作负载评估 Token 生成效率
交互式应用需要快速的首响应来保持用户参与度。GuideLLM 为企业级聊天部署给出了具体服务目标：
- 首 Token 延迟目标控制在 200 ms 以内；
- 这一响应目标需要在 99% 的总请求中达成。
你通过在延迟目标与系统硬件成本之间权衡，来衡量 Token 生成效率。实时聊天应用更看重低首延迟，而非最大批大小；长上下文摘要任务则更偏向输出吞吐，而对首响应速度要求较低。
工程师会分析性能指标，以评估高负载下的整体队列健康度。高用户流量会在服务节点间增加排队延迟。你可以通过让运行时配置适配实际工作负载，来保护大模型推理流水线；有效的模型优化可以在不触发内存溢出的前提下稳定处理速度。
成本效率与硬件选型策略
硬件选型直接决定整体资本开支与运行成本。对于小团队来说，在本地硬件上部署大语言模型，可以更好地控制内存。例如，一台搭载 M4 Ultra 的 Mac Studio 在 Q8 量化下运行 Llama 3 70B 时，可达到约 15–25 Token/秒的速度，而因存在卸载开销的 RTX 5090 则只有约 3–5 Token/秒。数据中心部署则需要专用加速硬件来承载企业级需求。
| 硬件平台 | 工作负载或基准场景 | 运营 CPM | 关键性能指标 |
|---|---|---|---|
| NVIDIA B200 | 企业级服务 | 约 $0.02 / 百万 Token | 约 60,000 Token/秒 / GPU |
| H100 SXM | Llama 4 Scout 17B 在 vLLM 上 | $0.19 / 百万 Token | 4,200 Token/秒 吞吐 |
| H100 SXM | 70B FP8，配合最优批处理 | $0.32–$0.54 / 百万 Token | 1,500–2,500 Token/秒 吞吐 |
| MI300X | Mixtral 8x7B，批大小为 1 | $22.22 / 百万 Token | 买断 vs 租用的盈亏平衡点约为 9,045 小时 |
选择现代数据中心芯片可以显著降低 Token 成本。Blackwell 架构相较 Hopper 芯片，Token 成本可最多降低 10 倍。
你可以通过将硬件平台与实际批大小分布相匹配来优化运营成本。MI300X GPU 在批大小大于 256 的情况下提供更低的 Token 成本；H100 GPU 在批大小 2–128 的中等批次下，具备更优的单位 Token 成本。优化大模型推理，需要将硬件内存带宽与预期批大小精准匹配；合理的推理架构设计既能提供强劲的大模型性能，又能控制硬件支出。通过精明的优化，你可以在高生产流量下保持企业部署的稳定性，同时提升整体大模型容量而不透支预算。
在推理过程中，你需要通过管理两个处理阶段来平衡大模型性能：以计算为主的预填充阶段需要强大的并行算力，而以内存为主的解码阶段则依赖高显存带宽。将这两个计算阶段隔离开来，可以提升整个集群的 Token 生成效率。
在大模型推理中，你只有将 Goodput 和服务等级目标（SLO）放在原始吞吐之上，才能获得高系统价值。最大化输出 Token 数并不等同于用户满意度。
你可以根据目标应用需求选择优化路径：
- 对于交互式聊天工作负载，可选择推测解码以降低单次响应延迟。
- 对于高并发企业级大模型推理应用，可部署解耦架构，将计算密集的预填充与受内存限制的解码工作负载拆分到不同 GPU 集群。
常见问答（FAQ）
如何计算推理中的端到端总延迟？
你可以通过将首 Token 延迟（TTFT）与单 Token 时间（TPOT）和输出 Token 数的乘积相加，来计算总延迟。该公式有助于评估交互式应用中的整体大模型响应性。
预填充与解码阶段在计算上最大的区别是什么？
预填充阶段会同时处理所有输入 Token，强烈依赖 GPU 计算能力；解码阶段则按顺序生成输出 Token，主要受限于内存带宽。
为什么企业团队应优先关注 Goodput，而不是原始吞吐？
原始吞吐只统计生成的 Token 数，而不区分是否超时；Goodput 只统计满足服务等级目标的成功 Token。因此，监控 Goodput 能在高流量下帮助你维护服务质量。
连续批处理如何提升生成效率？
连续批处理在每个迭代步骤上管理请求队列。该技术借助 PagedAttention 将内存浪费降低到约 4%，因此你可以用它来优化大语言模型的整体吞吐。
推测解码与解耦式服务如何降低延迟？
推测解码通过小型草稿模型加速输出生成；解耦式服务则将预填充与解码拆分到不同 GPU 集群。你可以根据目标大模型性能指标，在高峰需求场景下选择这些优化路径来稳定延迟。
