LLM inference 详解：大模型推理流程、延迟优化与部署选型

LLM inference（大模型推理）分为 2 个主要阶段：处理提示词，再生成回答。等了很久才开始输出，与很快开始输出却迟迟写不完，需要的解决办法不同。在换模型、购买更快的托管服务或租用 GPU 之前，先把这两段等待分别测清楚。

除非有明确理由自行运维推理服务，否则从托管 API 起步。 这样的理由可能是需要掌控部署环境、必须使用某个开放模型，或持续的流量足以支撑自建算力。仅仅觉得响应慢，还不足以做这个决定：先查清请求到底慢在哪一段。

下文涉及的文档与发布范围，已于 2026 年 10 月 21 日对照厂商的在线页面核实。文中的计算案例取自公开的 API 响应示例，并列出了计算过程。它不是实测基准，也不代表你的应用能达到相同速度。

LLM inference 是什么？先处理输入，再逐步生成

大模型推理，就是训练完成的大语言模型根据输入生成输出的过程。 对于典型的文本生成请求，这包括处理提示词、预测后续内容，再返回生成的文本。模型处理的基本单位是 token（词元），它可能是一个词、词的一部分，也可能是标点。参见 NVIDIA 对推理过程的说明。

可以把它想成先整理资料，再动笔回复。阅读并梳理收到的材料，是准备阶段；写出回复，是续写阶段。准备好的资料能省去重复整理的工作，但回复本身仍然要写。在实际实现中，系统保存的是数值状态，而不是可供阅读的笔记。

预填充（prefill）处理已知输入。 指令、检索到的文档、对话历史和工具返回结果，都会成为提示词 token。这些位置上的内容已经确定，因此系统可以在模型注意力规则允许的范围内，把相关计算一起处理。这一步会建立生成首个输出 token 所需的状态。

解码（decode）负责续写。 在通常的自回归生成过程中，每个新 token 都依赖此前已经选定的续写内容。运行时反复执行模型、选择下一个 token、更新状态，直到满足停止条件。NVIDIA 对这两个阶段都有说明。

客服助手即使只需给出很短的回答，也可能因为要处理一份庞大的政策文档，在准备阶段耗费大量时间。报告生成器则可能只收到不长的提示词，却让用户长时间等待模型写完。即使用的是同一个接口，这也是两种不同的工作负载。

大模型推理和训练有什么区别？

训练会改变模型学到的参数，推理则使用这些参数。 参数通常也称为权重，是模型在训练中学到的数值。在提示词里提供一份文档，是为当前请求补充上下文；这个动作本身不会重新训练模型权重。参见 IBM 对推理与训练的解释。

排查产品问题时，要把这几件事分开。如果回答忽略了某条政策，应改进提供的上下文，并评估模型的行为。如果回答正确却来得太慢，就该查看推理各阶段的耗时。训练、检索质量和推理服务性能，是不同的改进环节。

为什么输出 token 通常更贵？

与处理已经确定的提示词相比，生成后续内容通常能在单个请求内并行完成的工作更少。 批量较小时，解码可能把大量时间花在通过内存搬运模型权重和注意力状态上。把更多已知输入位置放在一起处理，则可以用不同的方式利用硬件。这有助于理解，为什么许多 API 对输出 token 收取更高的单价。参见 NVIDIA 对预填充与解码机制的说明。

具体的价格比例由厂商决定，并不是物理常数。缓存计费方式、模型选择和服务条款也会影响价格。不要以为缩短输入和缩短输出，对延迟或账单的影响都一样。

一个直接的做法是：如果功能只需要一个分类结果和一段简短说明，就只要求这些内容。强制模型写成长文，会增加生成工作；即使换成更快的托管服务，这些工作仍然要做。

首 token 延迟和每秒 token 数，要分开看

首 token 延迟反映响应开始前要等多久；生成速度反映开始输出后写得有多快。 测量两者时，要统一计时的起止边界。

• 首 token 延迟（TTFT）： 从发出模型请求，到收到首个非空输出 token 的时间。排队、提示词处理和网络传输都可能占用其中的一部分。
• token 间延迟： 开始生成后，相邻输出 token 之间的时间间隔。流式响应可能很快开始，但间隔过大，依然会让人觉得慢。
• 请求端到端延迟： 从发送请求，到收到最后一个输出 token 的时间。
• 系统吞吐量： 并发请求产生的有效输出总量。它可能在增加，而单个用户的体验却在变慢。

这些区分依据 NVIDIA 的指标定义。也正因如此，单凭一个每秒 token 数，无法回答所有性能问题。

比较每秒 token 数时，先看分母是什么。 服务商可能用输出 token 数除以生成时间，而客户端测量可能把开始输出前的等待也算进去。服务器的汇总结果还可能合并了许多用户的请求。这些数字描述的不是同一件事。

对于包含多个 token 的流式响应，平均 token 间隔可以按 (final-token time − first-token time) / (output-token count − 1) 计算。它排除了开始输出前的等待；分母减去一，是因为统计的是 token 之间的间隔。NVIDIA 的定义明确了这个计时边界。

应用层还应单独计时：从用户操作开始，到拿到可用结果为止。模型调用前的文档检索、外部工具调用，以及之后的校验，都应计入这段时间。更换推理服务商，无法消除等待自家数据库的耗时。

拆开一个请求，看延迟花在哪里

Groq 公开的响应示例说明，即使字段叫 total_time，也需要检查它究竟包含什么。 Groq 是一家托管推理服务商，会在 API 用量数据中返回耗时字段。其 Chat Completions API 参考文档给出了一个示例，包含 18 个提示词 token 和 556 个生成 token。

下表保留了示例公布的数值，并将秒换算为毫秒后四舍五入：

来源：Groq 的用量对象示例。这些是文档示例中的耗时，不是生产环境的预期延迟。

在这个示例中，返回的总耗时包含提示词处理和生成：

提示词处理 + 生成 = 0.000680594 + 0.463333333 = 0.464013927 秒。 这与返回的 total_time 完全一致。此示例的总耗时没有计入排队时间。

排队 + 提示词处理 + 生成 = 0.501507683 秒，约为 501.508 ms。 这是我们把已列明的服务端环节相加得到的小计。它仍然不能代表应用的完整等待时间，因为示例没有提供客户端网络耗时，也没有包含调用前后的应用处理。

将示例中的 556 个输出 token 除以 0.463333333 秒的生成时间，得到的结果约为每秒 1,200 个输出 token。这只是根据响应示例做的计算，既不是基准测试，也不是性能承诺。Groq 在推理指标说明中介绍了这种用 token 数除以生成时间的算法。

对自己的产品而言，有用的是这种拆分方法。排队时间长，就查看请求接入管理和容量；提示词处理占比大，就查看输入处理；生成时间长，就查看输出生成。如果客户端等待远长于服务端已报告的各段耗时之和，就沿着网络和应用调用链排查。

大模型推理优化：哪一段慢，就优化哪一段

只有改变了实际负载中占有分量的环节，优化才有意义。 同一个功能，对文档助手可能很有价值，对短小且互不相关的提示词却可能几乎没用。

这些机制可参见 NVIDIA 的说明及下文链接的运行时文档。做部署决策时，要守住最后一列列出的适用边界。

KV 缓存：保留已经算过的状态

键值缓存，也就是 KV 缓存，会保留此前 token 的注意力状态。 Transformer 通过注意力机制，将前文融入当前预测。保留之前的键和值，就不必在模型每前进一步时都重新计算。缓存如何增长、如何管理，取决于模型的注意力架构和推理服务策略。参见 NVIDIA 对 KV 缓存的解释。

这种复用要占用内存。模型权重能装进 GPU，不代表许多用户同时进行长对话时也能装得下。除了权重，还必须为活跃请求的状态和运行所需内存留出空间。

前缀缓存把复用扩展到了开头相同的多个请求之间。 如果助手反复收到相同的指令和参考文档，就可能复用已处理好的前缀。变化的后缀仍然需要处理，新的回答也仍然需要生成。

vLLM 是一个开源的推理与服务引擎。其文档明确指出，自动前缀缓存节省的是预填充计算，而不是解码计算。参见 vLLM 的缓存限制说明。

把有用的共享上下文放在请求开头，并检查服务返回的缓存用量。如果提示词之间没有多少共同内容，或者主要时间都花在生成长回答上，前缀复用就解决不了多少问题。KV 缓存指南进一步介绍了状态、保留策略以及不同服务商的复用方式。

批处理：让多个请求共享算力

连续批处理能让服务器更充分地保持忙碌。 其他序列还在生成时，已完成的序列可以退出，新请求可以加入。这样就不必让整组请求都等到其中最长的回答结束。参见 NVIDIA 对连续批处理的解释。

对于同时服务许多客户的运维方，这能提高容量利用率。对于等待单个回答的用户，总吞吐量提升却不一定意味着体验改善。测试响应时间分布时，应使用产品实际需要承受的并发流量。

不要把推理引擎内部的连续批处理，与异步批量 API 混为一谈。后者允许先提交任务、稍后完成，适合夜间批量分类等工作。它与高效调度实时聊天请求，是不同的产品选择。

分块预填充（chunked prefill）用于缓解新提示词对正在生成的回答的干扰。 它把较大的预填充任务拆成小块，与解码任务穿插调度。vLLM 的文档说明，调整调度时的 token 预算，会在首 token 延迟和 token 间延迟之间形成取舍。参见 vLLM 调优指南。

当其他客户正在聊天时，又有人上传了一份文档，这种取舍就很重要。目标是在接纳新任务的同时，让已有的流式响应保持流畅，而不是只优化空闲服务器上的单个请求。

量化：让每个数值占用更少空间

量化会降低表示数值所用的精度。 更小的数值表示可以减少内存需求，也可能改善受内存带宽限制的执行过程。权重量化和 KV 缓存量化影响的是不同部分的内存分配。参见 vLLM 量化文档。

关键是，在兼容的运行时和设备上，所选表示方式能否保留应用所需的行为。要评估与产品相关的文档提取、工具参数生成和长上下文任务。文件变小、模型成功加载，都不能证明输出已经合格。

不要仅凭格式名称就承诺加速。实际效果由支持的内核、硬件和负载共同决定。选择格式、判断究竟减少了哪一部分内存时，可以参考大模型量化指南。

推测解码：先起草，再验证

推测解码尝试让每轮验证接受更多续写内容。 成本较低的草稿机制先提出若干 token，再由目标模型验证。被接受的草稿可以省去一部分串行生成工作；被拒绝的草稿和验证本身仍然有成本。参见 vLLM 推测解码文档。

草稿可以来自另一个模型，也可以来自受支持的预测方法。收益取决于接受情况、目标模型、采样设置、硬件和流量。当瓶颈在生成阶段时，值得评估这项技术；它无法修复缓慢的文档检索，也不保证缩短开始处理前的排队时间。

标准拒绝采样方法力求在数值精度允许的范围内保持目标分布。但不能把这个保证套用到所有带有“推测”标签的功能上：在同一份文档中，vLLM 将标准方法的保证，与有意采用有损验证的方法作了区分。

大模型推理部署：先决定由谁运营服务

选硬件之前，先划清责任边界。 模型厂商 API、推理服务商，以及自行运行模型，都能把提示词变成回答；区别在于，有多少工作需要由你承担。

模型 API：直接调用厂商的模型

Anthropic 的 Claude API 提供以编程方式调用 Claude 模型的托管服务。 其 Messages API 接收请求并生成响应，厂商文档也介绍了流式输出和工具调用接口。参见 Claude API 概览。

如果首要任务是把所需的模型能力接入产品，这条路径很合适。你负责提示词、上下文、输出要求和应用层控制，厂商负责推理基础设施。

限制在于控制权。购买模型调用权限，不代表你能控制服务商的调度器，也不代表能把该模型部署到自己的基础设施里。当模型和服务合同能满足任务要求时，就可以选择这条路。不要因为 API 响应慢，就在还没测清等待发生在哪里之前启动 GPU 项目。

推理服务商：模型之外，再选择托管方

Groq 提供托管的聊天补全 API，并公布了模型目录。 模型页面分别列出各模型的能力和限制，因此需要核对准备使用的具体端点。参见 Groq 模型目录。

这让你可以为可用模型评估托管服务，而不必自己运维硬件。限制在于实际部署的组合：有哪些模型、请求限制是什么、支持哪些功能。别处出现了某个模型家族，并不能证明该服务商部署了你需要的具体检查点，或支持所有请求字段。

Cerebras 提供托管推理 API 和 SDK，支持流式生成。 快速入门文档展示了 API 密钥配置和请求流程。参见 Cerebras 推理快速入门。

把 Cerebras 作为候选服务，用实际提示词长度、输出要求和流量模式来评估。边界仍然是服务是否适配：确认提供的模型、必需功能以及容量条款。一个短示例的流式输出很快，还不足以证明它适合大量处理文档的生产功能。Cerebras 价格指南和 Groq 价格指南介绍了相关的商业选择。

托管价格示例： Groq 为 Alibaba 的 Qwen3.8-27B 标出的价格是每百万输入 token $0.80、每百万输出 token $4.00。将托管用量费用与自建所需的容量和运维投入作比较时，应以当前模型列表为准。

这个价格只对应上述模型。它不是前文耗时示例的报价，也不能用来给 Groq 与采用不同模型或部署方案的服务排名。

自建推理引擎：自行负责运行时和算力容量

vLLM 提供推理服务运行时，包含连续批处理、流式输出、前缀缓存和 API 服务器。 如果你的职责是提供并发推理服务，这些都是有用的基础能力。具体部署时，仍需核对支持的模型、硬件和优化方式。参见 vLLM 公布的功能。

难点在引擎之外的服务工作：准备容量、部署变更、管理请求接入、监控故障，并为高峰期保留余量。运行时可以在现有设备上调度任务，却不能替你决定应用的可靠性要求。

Ollama 是在本机或服务器上运行模型的运行时，提供 CPU 和 GPU 执行选项。 其常见问题文档介绍了并发处理、排队，以及并行请求带来的额外内存需求。参见 Ollama 并发说明。

对于本地开发或负载可控的内部场景，Ollama 是一个合理的起点。便捷接口背后，仍受内存和实际运维容量的限制。可参考 Ollama 与 vLLM 对比，决定使用它还是采用更侧重推理服务的部署方案；然后用并发请求验证，而不是以一次成功的聊天为依据。

DeepSeek 的 DeepInfer 是一个专用推理框架，其公开仓库始于 2026 年 10 月 20 日。 README 将此次开放版本描述为离线推理实现，包含面向大规模服务的组件，支持 DeepSeek-V4.1-Flash、NVIDIA SM100 GPUs 和 Huawei Ascend 950 NPUs。参见仓库历史及厂商 README。

此次发布并不是完整的推理服务。 DeepSeek 明确列出了必要但未包含在发布版本中的组件：KV 缓存系统、编码／预填充／解码分离，以及副本间的负载均衡。这里说的是服务层面缺失的配套机制，不应理解为推理引擎完全不缓存注意力状态。参见 DeepInfer 列出的未包含组件。

对于面向这些模型和硬件的基础设施团队，这份代码值得评估。但如果只是想在本周改善一个普通应用，它并不能让你绕过运营服务所需的工作。是否选择 DeepSeek V4 模型，与是否自建其推理基础设施，是两个需要分别判断的问题。

只有当自主掌控能解决明确需求，而且团队能承担相应职责时，才选择自托管。 持续需求可能足以支持评估这条路线；不规律的需求则可能让已付费的算力闲置。决策时，要纳入活跃上下文、并发、故障和高峰期。不存在一个普遍适用且站得住脚的流量门槛，超过它，自有 GPU 就必然更划算。

关于推理加速，哪些说法被夸大了？

只有让用户等待的结果更快可用，生成速度提升才有价值。 流式输出能更早展示进度，但不会让剩余的生成工作消失。如果工作流必须校验完整的结构化响应，依然可能要等到输出结束。

哪种大模型推理最快，要看实际负载

有意义的比较，必须交代模型行为、提示词长度、输出长度、缓存条件和并发情况。否则，结果更快可能只是请求更简单，或者计时的分母不同。服务商公布的总吞吐量，并不是对单个客户首 token 延迟的承诺。

评估优化宣传时也应遵循同样的原则。缓存命中省下的是符合条件的重复准备工作，并非任务的全部耗时。更小的数值表示，不能证明任务质量不变。开放一个推理框架，也不等于交付了一整套可运营的服务。

现在就开始测量，去掉不必要的工作；等数据指出明确理由，再迁移基础设施。 如果一个简短的 API 调用已经满足质量和延迟要求，新发布的推理引擎本身并不会给你增加一个待解决的问题。

大模型推理常见问题

机器学习中的推理是什么？

ML 指机器学习。推理就是将训练好的模型用于新输入，从而得到输出。大语言模型生成文本，是这个更广泛过程的一种应用。

AI 领域的 LLM 是什么意思？

LLM 是大语言模型的英文缩写。在本文讨论的文本生成场景中，它处理上下文，并通过预测 token 来形成后续内容。

“推理语言”是指某种编程语言吗？

在这里，这种说法通常指语言模型执行的推理，并不是某种必须使用的编程语言的名称。应用可以通过 API 或运行时调用模型。

机器学习中的推理和预测有什么区别？

推理是运行已训练模型的过程，预测则是这一过程产生的输出。在自回归语言生成中，对下一个 token 的反复预测逐步组成了回答。

常说的三种推理是什么？

在讨论思维推理时，通常指演绎、归纳和溯因。这些属于逻辑分类。模型厂商 API、托管推理服务商和自行管理的运行时，则属于部署选择，与这三种推理方法不是一回事。

能举出五个模型推理的例子吗？

语言模型可以执行的任务包括邮件分类、文档摘要、段落翻译、回复起草和代码生成。这些只是任务示例，不代表对某个具体模型性能的承诺。

能用一个具体场景说明推理吗？

客服应用将客户的问题及相关政策文本发送给训练好的模型，模型据此生成回复草稿。处理提供的上下文，以及生成回复，都属于推理工作。

怎样让大模型执行一次推理？

对于大模型应用，先选择训练好的模型，通过 API 或运行时提交相关提示词，再评估返回的输出。可以直接使用训练完成的模型，无需自己训练。

用通俗的话说，推理到底是什么？

就是让模型利用学到的东西，根据新输入产生输出。对于聊天机器人，它指的是从接收对话到生成下一条回复之间，模型完成的工作。

接下来一周，先做哪些改进？

开发者应补齐请求埋点，运维人员应在负载下测试，采购决策者则应比较由此明确的服务需求。 这些工作相互衔接，但不能互相替代。

1. 1

   记录完整调用链

   选取有代表性的任务，记录输入和输出 token 数、首个非空输出、最终输出，以及服务商提供的各项耗时字段。在模型计时之外，同时保留检索和工具调用的计时。对命中缓存和未命中缓存的请求分别标记。

2. 2

   先处理占时最多的环节

   如果重复处理提示词占了主要时间，就检查前缀复用和无关上下文。如果生成占了主要时间，就缩短不必要的输出，或评估合适的模型与解码配置。如果主要时间花在排队上，应先检查容量和请求接入管理，再考虑改写提示词。

3. 3

   按真实流量重放请求

   在预期的并发请求下比较任务质量和延迟，并纳入长输入和长输出。用这些证据决定继续使用当前 API、评估其他托管服务，还是自建算力。选择最后一条路之前，先明确故障由谁负责。

订阅通讯，了解 AI 产品背后系统的实用原理。