导读
本文深入剖析了大语言模型（LLM）推理阶段的核心性能指标与优化策略。文章指出，随着具备复杂推理能力的模型兴起，"测试时计算"成为提升AI表现的关键，但也带来了更高的延迟成本。作者详细拆解了影响推理效率的三大核心指标：延迟（Latency）、吞吐量（Throughput）及首字延迟（TTFT），并揭示了Transformer架构中"预填充"与"解码"阶段的性能瓶颈差异。此外，文章对比了实时、批量及边缘推理等不同应用场景，系统梳理了量化、KV缓存、投机解码等主流加速技术，以及硬件加速的最新趋势。对于开发者而言，理解这些概念有助于在延迟、吞吐量和成本之间找到最佳平衡点，从而构建高效、低成本的AI服务系统。
TL;DR -- 大语言模型推理（LLM Inference） 是指训练好的模型处理新输入并生成输出的过程。其性能取决于延迟（Latency） 、吞吐量（Throughput） 、成本和硬件效率。量化（Quantization） 、KV缓存（KV Cache） 、批处理、投机解码（Speculative Decoding） 以及*硬件加速* 等技术能让推理更快、更便宜，尤其是随着具备复杂推理能力的模型对**测试时计算（Test-time Compute）**需求增加。
能够生成最终回复但耗时较长的强大推理模型仍是 AI 社区的主要关注点。它们利用测试时扩展（Test-time Scaling） 来实现最先进性能，往往以牺牲响应速度为代价。我们关于*测试时计算*的文章受到了读者的广泛关注，因此我们决定深入探讨一个密切相关的话题------推理。
所有的聊天机器人、图像生成器、语音助手和推荐系统都依赖于推理（LLM Inference）；这是用户实际与之交互的环节。因此，理解推理的核心方面不仅对开发者重要，对每个人都很重要。模型训练完成后，推理阶段是其展示所学知识的时刻。加速推理并让模型能够同时处理大量输入，是优化中最关键的挑战之一。今天，我们将探讨真正驱动推理延迟（Latency）和吞吐量（Throughput）的因素------即那些至关重要的指标、时间花在模型内部的何处、哪些杠杆能改变这些指标，以及当前的硬件和服务栈能提供什么性能。
本文并非旨在面面俱到，而是希望阐明为何推理在当今的 AI 中如此重要。
在训练阶段，模型会从数据中学习关键的模式。一旦模型经过充分训练，它便需要在现实任务中展示其习得的"知识"。从发出提示（prompting）开始，到模型生成对查询的回答为止的整个过程，被称为推理（LLM Inference）。换句话说，推理就是使用已训练好的模型进行预测或生成输出的过程。
IBM Research 指出，AI 模型在其生命周期中高达 90% 的时间可能都处于推理模式。这里指的是模型部署后的生命周期，而非计算资源在生命周期中的占比份额。但核心观点依然成立：一旦模型服务于大量用户，推理将成为其运营成本和碳足迹的主要来源。
得益于推理，我们甚至开始讨论新的扩展定律（Scaling Laws）。在一次演讲中，NVIDIA CEO 黄仁勋区分了塑造现代 AI 的三大扩展定律：
- 预训练扩展（Pre-training scaling）（在大型数据集上进行训练）
- 后训练扩展（Post-training scaling）（对模型进行微调）
- 测试时扩展（Test-time Scaling）（推理时的计算）
黄仁勋强调，推理扩展（Inference Scaling）正变得日益关键。如今的模型在推理阶段能够执行复杂的多步推理------这种方法被称为「测试时计算」（Test-time Compute）或「推理扩展」。通过大幅增加分配给该阶段的计算资源，AI 系统能够在需要深思熟虑或细微推理的挑战性应用中，实现更好的性能、准确性和可靠性。
要想深入理解 AI 推理（LLM Inference），我们需要掌握其核心方面，例如用于从不同角度衡量推理有效性的概念，以及推理过程在模型内部是如何运作的。让我们先从这些基本概念开始。
大语言模型推理的延迟、吞吐量与首字延迟：关键概念
推理的关键概念包括：
- **推理时间（Inference Time）**是衡量模型计算输出所需时长的原始指标。
- 总生成时间（Total Generation Time） 是指从输入提示词到生成完整回复的总耗时。它紧密关联着推理中最关键的方面之一：
- 延迟（Latency） ------与请求相关的延时。对于流式大语言模型（LLM），需区分首字延迟（Time to First Token, TTFT） （从请求发出到生成第一个令牌的时间）和单输出令牌耗时（Time Per Output Token, TPOT）（后续各令牌之间的平均延时），以及端到端延迟（从请求到完整回复的总时间）。对于 N 个输出令牌，总延迟近似为 TTFT + TPOT × (N−1)。非流式客户端仅看到最终完成的回复，但服务器仍可在内部测量 TTFT。
- 吞吐量（Throughput） ------系统每秒能完成的成功推理次数（或生成的令牌数）。它反映了系统的整体处理能力。吞吐量通常以每秒请求数（Requests Per Second, RPS） 或**每秒令牌数（Tokens Per Second, TPS）**来衡量。
然而，两者之间往往存在权衡：优化延迟可能会损害吞吐量，反之亦然。因此，开发者的关键任务是在两者间取得有效平衡，以实现最小化延迟和最大化吞吐量。这种权衡的两面性必须在真实流量中进行测量，而非仅靠估算：请参阅 如何监控大语言模型 以了解需要追踪的关键绩效指标（KPIs），以及 捕获每个请求的 TTFT 和 TPOT 的开源工具。
开发者同样关注的其他重要推理概念包括：
- 每次推理成本（Cost per inference） -- 这是推理效率的核心概念。它展示了运行单次推理所需的计算成本（通常也涉及美元成本）。大规模部署模型的公司在乎每个令牌/请求的成本。总体而言，每次推理成本会影响总定价、延迟和可扩展性。
- **可扩展性（Scalability）**是指随着推理负载增加而维持性能的能力。
- **准确性（Accuracy）**表示模型在接收输入时输出结果的正确性或有用程度。权重在训练后固定不变，但推理时的准确性仍取决于提示质量、上下文长度、量化以及解码设置，因此必须基于生产流量进行测量，而不能仅凭基准测试分数来假设。
- **输出令牌熵（Output-token entropy）**描述了模型在每个步骤中下一个令牌概率分布的离散程度。高熵意味着更多的随机性，低熵意味着更高的确定性。这属于解码和采样分析的范畴，而非核心服务仪表盘的一部分，但在调整温度（temperature）和 top-k 参数时非常有用。
这些是我们可以在模型外部观察到的、用于估算推理过程的信息。然而，我们旨在以更深的技术深度探索推理，因此 →
Transformer 中的推理工作原理
以下是大语言模型中完整推理过程的简化逐步流程：
- Tokenizing input（输入分词）： 首先，将查询中的原始文本转换为 token IDs（令牌 ID）------即模型能够理解的数值表示。这些数字对应于模型词汇表中的条目。
- Embedding the tokens（令牌嵌入）：每个令牌 ID 被映射到嵌入矩阵中的一个稠密向量。如果架构使用学习到的位置嵌入（learned positional embeddings），则在此处将其添加。RoPE（旋转位置编码）的工作方式不同：它在每个注意力层内旋转查询和键向量，在计算注意力的地方编码位置信息，而不是在嵌入查找阶段。
- Running the prefill phase（运行预填充阶段）：模型通过其 Transformer 层并行处理所有提示令牌，构建上下文表示并填充 KV 缓存。此阶段的注意力与 MLP 计算主要决定了首字延迟（TTFT）。如果模型使用 RoPE，则将其应用于每个注意力层内的查询和键向量。
- Generating logits（生成逻辑值）： 模型为其词汇表中每个可能的下一个令牌生成未归一化的预测分数，称为逻辑值（logits）。
- Decoding the next token（解码下一个令牌）： 根据逻辑值，使用不同的生成策略选择下一个令牌，例如采样、贪婪解码、top-k 或束搜索。
- Decoding token by token（逐令牌解码）：在第一个令牌之后，模型复用 KV 缓存并自回归地生成每个额外的令牌。这种顺序的解码阶段主要决定了单输出令牌耗时（TPOT）。该过程持续进行，直到模型发出停止令牌、达到输出限制或满足其他停止条件。
- Output generation（输出生成）： 最终的输出令牌被转换回人类可读的格式，供最终用户或系统使用。
这些步骤对用户而言是透明的，但每一步都会影响推理的速度、可靠性与经济性。预填充阶段（Prefill Phase）与解码阶段（Decode Phase）的划分尤为重要，因为它将用户感知的指标与 Serving 系统实际执行的操作联系了起来。
Diffusion Models 中的推理
在 diffusion models 中，推理过程有所不同。初始输入是随机噪声，提示词（Prompts）用于引导生成过程朝向期望的输出（如特定图像）。生成过程涉及迭代去噪步骤，模型逐渐将噪声转化为连贯的数据。去噪步骤的数量可能各不相同，例如从 25 到 1000 步不等，具体取决于采样策略以及质量与速度的权衡。DDPM、DDIM 或基于分数的采样（score-based sampling）等技术定义了噪声随时间移除的方式。由于需要大量的前向传播（forward passes），与更直接地生成输出的 Transformer 模型相比，Diffusion Models 的推理往往较慢。
推理类型
在此我们将探讨几种主要使用的推理类型。在实际应用中，它们通常根据系统目的组合使用。
实时推理
具备实时大语言模型推理（Real-time LLM Inference）能力的系统会根据需求，对实时数据或用户操作做出预测。它们能够提供低延迟的结果，这对于欺诈检测或医疗警报等时间敏感型任务至关重要。实时推理也应用于语音助手或自动驾驶汽车等场景，提供即时反馈和动态更新，但需要始终在线的基础设施、针对并发用户的精细扩展能力以及高系统可靠性。
批量推理（Batch Inference）
与实时大语言模型推理相反的是批量推理（Batch Inference），它将大量输入数据收集起来，通常按预定计划进行批量处理。这是一种用于处理数百万条记录等任务的离线推理类型。它最大化了吞吐量（Throughput）和效率，但无法立即处理查询请求。
云端推理
云端推理使用集中式服务器，将用户设备上的数据发送到云端进行处理。它利用高端 GPU 和 TPU 实现强大且可扩展的计算能力，非常适合大型或复杂模型。它提供了便捷的更新和高效的资源共享。然而，也存在一些缺点，例如网络延迟、高昂的成本以及数据离开设备后引发的隐私担忧。为了获得最佳性能，云端推理通常与边缘推理（Edge Inference）配合使用。
边缘推理（Edge Inference）
边缘推理（Edge Inference）直接在手机、物联网传感器或无人机等本地设备上运行 AI 模型，从而在数据源头实现实时处理，无需将数据发送至云端。这对于需要快速响应且注重隐私的 AI 决策至关重要。然而，边缘设备算力有限，若未经优化，很难在其上运行大型模型。此外，在多台设备上更新模型也颇具复杂性，而扩展规模则需要部署更多的硬件。
所有这些推理类型可以混合使用。例如，系统可以先在边缘端进行快速的初步推理，然后将数据发送至云端进行更深入的分析；或者通过在多个区域部署服务器，在云端执行实时推理。
从上述推理类型的示例中可以看出，推理过程面临着诸多局限。为此，各种优化技术被广泛应用于解决这些问题。
优化技术
以下是使推理更快、更高效的主要技术。连续批处理（Continuous Batching）是一种独立的服务端优化策略：当容量可用时，生产服务器会将新请求纳入正在进行的批处理中，这提高了硬件利用率和吞吐量，但可能会增加单个请求的延迟。它与下文介绍的技术相辅相成，而非相互替代。这种做法提高了硬件利用率和吞吐量，但更大或更激进的批处理规模可能会增加单个请求的延迟。
- 量化（Quantization）： 该技术通过降低模型权重和运算的数值精度来优化性能，例如将 32 位浮点数（float32）降低至 8 位整数或 float16 等更低精度。这能显著减小模型在内存中的体积，从而减少计算量并提升推理速度，且仅带来微小的精度损失。
- 模型蒸馏（Model distillation）： 通过训练一个较小的模型来模仿大模型的预测结果和行为模式，从而实现更高效的推理时间。
- 投机解码（Speculative Decoding）： 你可以利用一个小模型提前猜测多个令牌（token），随后再用大模型进行验证。通过在更少的步骤中验证多个令牌，投机解码能够加速生成过程，有时甚至能降低延迟。
- 剪枝（Pruning）： 该方法涉及移除模型中对预测不必要或冗余的部分，从而实现模型压缩并加快运行速度。
- 硬件加速（Hardware acceleration）： 使用合适的强大硬件，如图形处理单元（GPUs）、张量处理单元（TPUs），以及各种 AI 加速器和神经处理单元（NPUs），可以显著提升推理速度。
- KV 缓存（Key/Value cache）管理： 自回归解码器已经缓存了先前令牌的键（Keys）和值（Values），以避免重复计算。当前的挑战在于通过分页、驱逐、卸载和前缀复用等技术来管理这部分内存，从而使服务器能够处理更多的并发请求。
这些技术广泛应用于当前的 AI 系统中，甚至已成为实现更快速推理的传统方法。但 AI 推理领域的实际趋势究竟如何？
硬件领域的当前趋势
2026年更新：推理工作重心已从孤立的性能记录转向端到端的服务系统（End-to-End Serving Systems）。实际的收益现在来自于结合连续批处理（Continuous Batching）、KV缓存复用、量化、投机解码，以及在更大规模下将预填充阶段与解码阶段分离。由于性能取决于模型、硬件、精度、批大小、上下文长度和延迟目标，因此厂商提供的数据仅作为有用的快照------而非通用的排名。
推理模型的出现使得推理优化变得更加紧迫，而非缓和。更长的思维链增加了输出长度和测试时计算量（Test-time Compute），因此服务系统必须平衡交互延迟与整体吞吐量及成本。该领域的重心因此从"哪款芯片最快？"转向了软硬件协同设计：精度格式、内核、调度器、缓存管理、网络以及分离式服务（Disaggregated Serving）都至关重要。
Cerebras 从晶圆级（Wafer-scale）的角度也提出了同样的观点。2026年8月，Cerebras推出了基于WSE-3T的CS-4系统，并报告称在GPT-OSS-120B模型上实现了每位用户每秒超过4,400个令牌（tokens）的速度。这是一个针对特定模型和配置厂商基准测试，并非通用对比，但它展示了晶圆级硬件如何降低解码延迟（Decode Latency）。这种性能提升来自于硬件、编译器以及模型服务优化的共同作用，而非仅靠软件。
NVIDIA在2025年3月发布的DeepSeek-R1结果也需要类似的背景说明。广泛引用的36倍吞吐量提升和32倍单令牌成本降低，是在最大并发量下对比了H100 FP8、H200以及B200 FP4的配置序列；这是硬件与软件共同带来的增益，并非纯粹的Blackwell架构对Hopper架构的对比。在同一篇博文中，更具可比性的DGX B200 FP4结果在推理吞吐量上超过了DGX H200的3倍。NVIDIA还报告称，在一个拥有8块GPU的DGX B200系统上，当并发数为1（即低延迟配置，将整台系统的资源分配给单个请求）时，每位用户的速度超过每秒250个令牌。
"nvidia-blackwell-inference-speed-benchmark"
图片来源：NVIDIA Blackwell博客
在本故事中，NVIDIA Dynamo 是推理服务层（LLM Inference Serving Layer）。它将预填充阶段（Prefill Phase）与解码阶段（Decode Phase）分离到不同的 GPU 资源池中，将请求路由至可复用的 KV 缓存（KV Cache），并根据流量变化动态重新分配工作进程。NVIDIA 最初宣称的"最高提升 30 倍"性能，特指在 GB200 NVL72 硬件上部署 DeepSeek-R1 模型、输入长度为 32K 令牌且输出长度为 8K 令牌时的预期表现------并非适用于所有工作负载。到 2026 年发布的 Dynamo 1.0 版本，NVIDIA 报告称，在 GB200 NVL72 上将解耦式服务（Disaggregated Serving）与宽专家并行（Wide Expert Parallelism）结合使用后，DeepSeek-R1-0528 模型的请求吞吐量（Throughput）最高提升了 7 倍。
"llm-inference-prefill-decode-disaggregated-serving"
图片来源：NVIDIA Dynamo 博客
上述示例仅为快照，并非排名。纵观各类系统，持续的趋势在于协同设计（Co-design）：硬件速度固然重要，但推理服务层（Serving Stack）才是决定这些能力能否转化为更低延迟、更高吞吐量或更低成本的关键。
当前推理领域还有哪些新动态？
除了硬件的飞跃式进步外，一些最大的突破也发生在软件层面------这不仅改变了推理的速度上限，更让它变得更加智能。
以投机解码（Speculative Decoding）为例。一个较小的草稿模型会提出多个令牌，而目标模型则并行验证这些令牌。当草稿模型的预测表现良好时，系统可以在每次目标模型处理步骤中接受多个令牌，且不会改变输出的概率分布。加速效果取决于令牌的接受率、模型配对、序列长度以及硬件性能；它是一种技术手段，而非保证延迟一定能减半的绝对承诺。
另一个重要的开源进展是 vLLM。它于 2023 年在加州大学伯克利分校诞生，虽已不再新鲜，但如今已演变为一个成熟的推理引擎，其核心围绕分页注意力机制（PagedAttention）、连续批处理（continuous batching）、前缀缓存（prefix caching）、量化（Quantization）以及分布式执行构建。其原始论文曾报告称，相比未优化的 Hugging Face Transformers 基线，吞吐量最高提升了 24 倍，但这一历史数据不应被解读为与当前现代推理引擎的实时对比结果。
更快的推理速度也可以用于处理更多的工作，而不仅仅是缩短等待时间。系统可以采样多个候选解决方案、验证中间步骤，或者为推理过程分配更多的令牌。这虽然能提升答案质量，但前提是额外的搜索和评估设计得当；仅靠原始的令牌生成速度并不能让模型变得更具推理能力。
因此，尽管推理优化始终关乎速度，但新时代也意味着战略性深思。更快的系统能够兼顾两者：既响应更快，又思考更深。
结论
今天，我们深入探讨了一个至关重要的主题------它堪称所有 AI 系统的「门面」：大语言模型推理（LLM Inference）。这是每个人在与 AI 交互时都能直接感知的部分。模型在这一环节的运行表现，正驱动着硬件以及各类旨在提升推理效能的技术不断演进。
回顾全文，我们可以把推理优化的整体图景归纳为三个层次。第一层是指标层 ：延迟（Latency）、吞吐量（Throughput）、首字延迟（TTFT）与单输出令牌耗时（TPOT）共同刻画了用户体验与系统能力，而它们之间往往此消彼长，必须在真实流量中测量而非凭估算判断。第二层是机制层 ：Transformer 推理被划分为预填充阶段（Prefill Phase）与解码阶段（Decode Phase），前者以并行计算为主、决定首字延迟，后者以逐令牌自回归为主、决定单输出令牌耗时；正是这种阶段差异，才让分离式服务（Disaggregated Serving）、KV 缓存复用等工程手段有了用武之地。第三层是技术层：量化、蒸馏、剪枝、投机解码、连续批处理与硬件加速，分别从精度、模型规模、计算冗余和调度效率等不同角度切入，彼此互补而非相互替代。
当前，我们面临着双重挑战：以 DeepSeek R1 为代表的推理模型正在增加推理时间，更长的思维链意味着更多的输出令牌与更高的测试时计算（Test-time Compute）开销；而研究人员仍在这些日益增长的需求压力下，探索更先进的加速方法。这仿佛是一场永无止境的进步竞赛，因为我们始终需要构建尽可能快速的系统。
对开发者而言，务实的做法是先明确业务对延迟与吞吐量的真实要求，再据此选择技术组合：面向交互式场景时，优先压低首字延迟并保证流式输出的稳定性；面向离线批处理时，则可以放宽单请求延迟，换取更高的吞吐量与更低的单位成本。同时，任何优化都应建立在可观测性之上------持续采集 TTFT、TPOT、每秒令牌数与每次推理成本等指标，才能判断某项优化究竟带来了真实收益，还是仅仅把瓶颈转移到了别处。
可以预见，未来的推理优化将越来越少地依赖单一硬件的性能突破，而更多取决于软硬件协同设计（Co-design）：精度格式、内核实现、调度策略、缓存管理与网络传输需要作为一个整体来考量。理解了这一点，也就理解了为什么推理既是 AI 系统的「门面」，也是工程能力真正的试金石。
常见问题解答（FAQ）
什么是大语言模型中的延迟（Latency）？
大语言模型推理的延迟是指发送请求与收到模型输出之间的时间差。在流式传输应用中，通常使用首字延迟（Time to First Token, TTFT） 和**单输出令牌耗时（Time Per Output Token, TPOT）**来评估。模型大小、上下文长度、输出长度、硬件配置、批处理策略以及服务基础设施都会影响延迟表现。
如何应对大语言模型的延迟问题？
可以通过KV缓存（KV Cache）、量化（Quantization）、投机解码（Speculative Decoding）、模型蒸馏、优化硬件以及高效的请求调度来降低大语言模型的延迟。减少不必要的上下文信息并选择更小的模型也有助于提升响应速度。在实际生产环境中，开发者通常需要在延迟、吞吐量、成本和模型质量之间寻求平衡，而不是单纯地追求速度优化。
原文 ：LLM Inference Latency and Throughput: How to Optimize · 作者：Alyona Vert.