先决条件

推理工程通过优化生成式模型的生产服务，为人工智能产品提升速度和规模。优化意味着从一系列选项中找出最佳解决方案。在优化模型性能和构建稳健的基础设施之前，你需要明确“最佳”对于你的产品意味着什么——许多性能提升都来自于在延迟、吞吐量和质量之间进行权衡。在实践中，优化往往是为了找到合适的平衡点，而不是最大化单一因素。

NFL（美国国家橄榄球联盟）球员体型高大、速度快、力量强。但他们不像相扑选手那样体型庞大，不像奥运会短跑运动员那样速度飞快，也不像举重冠军那样力量惊人。他们的身体和技能经过优化，以满足在整个赛季中其所在位置的具体需求。

同样，推理系统也必须围绕模型、产品和流量的实际需求来优化。约束条件越明确，通常越容易得到更好的结果。您需要了解：

• 模型需求：您需要运行哪些模型来进行推理？
• 应用程序接口：输入将如何交付给模型，以及输出应采用何种格式？
• 延迟预算：端到端来看，您的产品需要多快响应用户操作？
• 单位经济效益：在每次请求、每个用户或每月的基础上，投入多少成本是合理的？
• 使用模式：您正在服务多少并发用户，他们的使用是否有规律（例如，工作时间活动更多）？

在 AI 产品的早期，这些问题的答案往往还不清楚。此时，通常应尽量使用现成 API，而不是过早投入专用推理基础设施。随着产品规模扩大、需求逐渐清晰，推理工程才会真正成为值得投入的工作。

1.1 规模与专业化

你可以通过两种方式将人工智能模型添加到你的产品中：

• 共享推理：将流量发送到给定模型的公共 API 端点，并按每百万 Token 或其他基于消费的指标付费。
• 专用部署：租用 GPU 并为你的应用程序专门设置推理服务，按 GPU 小时数付费（或在本地购买并安装 GPU）。

共享推理与专用部署，并不完全等同于闭源模型与开源模型之争。开放模型也有大量共享端点，许多模型实验室也会为大客户提供某种形式的专用部署。只是采用开放模型的一个关键动机，在于它解锁了不受限制的专用推理。

大多数 AI 产品起步时都会使用按 token 付费的 API，因为在寻找产品市场契合度或处于增长初期阶段时，这种权衡是合理的。随着时间的推移，出于以下三个原因，将 AI 产品迁移到专用部署至关重要：

• 规模：您处理的流量足够大，按 GPU 付费比按百万 token 付费更经济。
• 专业化：您正在运行自定义或微调后的模型，或者有特定的延迟或正常运行时间要求。
• 编排：您的产品依赖于多个模型和多步骤流水线，您需要最大限度地减少网络延迟和部署复杂性。

转向专用部署，意味着你要亲自负责推理工程。这样做会带来更高的灵活性和控制力，但也会扩大工程职责范围，并抬高每月推理支出的底线。只有在业务需求已经明确且足够迫切时，才值得切换。

1.2 关于您的应用程序

您所做的每一项推理工程决策都将取决于您的具体用例。想象一位在学校招募队员的体育教练：他会找哪些学生谈？答案完全取决于他执教的项目。篮球教练会寻找班里最高的学生，而体操教练则更可能挑选个子最矮的学生。

同样，你的推理系统的使用方式决定了你构建它的方式。推理工程师需要在最高通用性级别进行构建的情况有两种：

• 基础模型：你已经训练了自己的模型，并将通过公共共享推理 API 直接销售其使用权，因此需要支持多种使用模式。
• 推理平台：你正在构建一个推理平台（无论是内部使用还是作为产品），需要支持任何模型和任何用例。

但大多数 AI 原生应用都属于垂直场景，例如代码编辑器或客服代理，AI 在其中承担的是创造特定用户体验的角色。为这类垂直应用构建推理系统时，你应该尽可能把用例定义清楚，为系统增加更多有价值的约束。

1.2.1 AI 原生应用

生成式 AI 模型开启了跨行业和跨领域的新型应用。每一类应用都依赖于不同的模型和模态，并需要定制化的推理。

这只是今天 AI 原生应用的一小部分样例，但已经足以说明推理工程师需要面对的考量有多广。随着模型变得更快、更便宜、更智能，今天还难以想象的新用例还会继续出现。

1.2.2 在线与离线

推理工程中的核心权衡之一，是延迟与吞吐量。更低的延迟能让应用响应更快；更高的吞吐量则意味着在大规模场景下能以更低成本运行，因为你可以用更少的 GPU 服务同样多的用户。

大多数人工智能应用程序，例如代码补全、聊天和语音助手，都属于实时在线应用。每个 API 调用背后都有用户在等待，因此这类系统通常应优先为低延迟优化。

但也有一些应用存在离线批量推理需求。离线任务更适合高吞吐量部署：单个请求可能慢到不足以支撑良好用户体验，但整个系统每小时能够并行处理更多请求。一些离线工作负载的示例包括：

• 目录转录：转录过往的播客、采访或其他音频内容，以便进行搜索。
• 文档处理：定期对一组文档进行嵌入、转换或分析。
• 语料库准备：清洗、嵌入或以其他方式准备海量数据语料库，用于模型训练。

1.2.3 面向消费者与面向企业（B2B）

为消费者和企业构建的应用程序有着不同的推理需求。面向消费者的应用通常更受成本约束，使用模式也更难预测。许多消费级 AI 应用追求病毒式传播，一次发布或营销活动就可能让使用量在一夜之间暴涨。因此，这类应用的推理工程应优先考虑边际成本和灵活性，同时把延迟和可用性维持在合理水平。

企业对企业（B2B）产品通常利润率更高、流量更稳定，但也更强调高可用和持续的低延迟。处在业务主链路上的关键任务软件，对性能和可靠性要求极高。为企业构建应用的推理工程师，通常需要把延迟和可用性放在首位，同时兼顾成本和扩展规模。

在消费者和企业应用中，合规性都可能限制基础设施的选择，特别是在受监管的行业中。一些基本的考量因素包括：

• 数据主权：您的 GPU 是否位于允许您发送用户数据的地理区域？
• 用户隐私：您的模型的输入和输出是否保持私密和安全？
• 监管合规性：您和您的底层提供商是否符合所有相关法规？

推理工程师必须与安全和法律专家密切合作，以确保他们运营的基础设施合规。

1.3 模型选择

在其他条件（硬件、运行时、优化、架构）相同的情况下，参数较少的较小模型的推理速度更快、成本更低。这就是为什么模型性能优化中最关键的决定不是运行时引擎或推测算法，而是你最初选择使用哪个模型。

在产品早期，AI 工程师通常应直接使用现成的按 token 计费 API，例如 Kimi、DeepSeek，甚至 GPT、Gemini 这类闭源模型提供的服务。在真正达到 product-market fit 之前，为自建推理投入时间和成本往往并不划算。

但当产品进入扩张阶段，逻辑就会反过来。你需要寻找或训练一个既能完成任务、又尽可能小且易于运行的模型。在不少场景里，这仍可能意味着使用万亿参数级的前沿模型，但始终值得先确认：是否存在一个更小、更快、更便宜的替代方案。

你选择的模型，也会直接影响后续能用哪些推理优化手段。不同推理引擎对不同架构的支持深度并不相同，因此尽量坚持主流架构，通常能让你更容易吃到整个性能工具生态的红利。

1.3.1 模型评估

模型评估（evals）是对模型智能进行系统性衡量的实践。高置信度的模型评估是推理工程的前提。评估有助于推理工程师：

• 明智地分配时间：在投入资源提升模型速度之前，评估可确保模型是有用的。

• 建立基准：一些性能优化技术可能会降低模型质量，因此需要一个基准来进行比较。

与衡量模型在 MMLU 或 SWE-bench 等常见任务中能力的标准化智能基准不同，评估是针对特定产品、领域和任务量身定制的。智能基准在筛选模型时很有用，但如今已经趋于饱和，甚至会被刻意针对。古德哈特定律指出：“当一个指标变成目标，它就不再是一个好指标。”当前沿实验室在发布新模型时强烈追求刷新纪录式基准成绩时，这条规律尤为明显。

虽然还有一些更好的方法来衡量整体模型智能，例如通过与其他模型对战胜率得出的 Elo 评分，但没有什么能替代直接衡量模型在你的应用中的真实表现。

进行有效模型评估工作的一些建议：

• 查看您的数据：根据您对产品和问题领域的直觉来检查评估结果。
• 保持精确：清楚了解模型需要解决的最困难的问题，并将评估重点放在这些问题上。
• 使用工具：在人工智能工程的基本问题上，不要重复造轮子。

第 8 章包含了关于评估工具和进一步阅读的建议。

1.3.2 针对特定领域质量的微调

微调是指采用预训练的基础模型，并通过引入新数据使其适应特定用例的做法。

如果你能通过微调一个小模型来通过你的评估，那么你在实现推理延迟和成本目标时会轻松得多。微调有效的一个很好的领域是将英语翻译成 SQL，这是一种用于查询数据库的语言。

通用编码模型擅长编写 SQL，但这些模型往往拥有数千亿参数。SQL 又是一种相对受限的语言，因此对于只需要根据自然语言提示生成 SQL 查询的应用来说，一个只有几十亿参数的微调小模型，就有机会在这个特定任务上达到相近表现。

文本转 SQL 是一个比较极端的例子，并不是所有领域都允许如此大幅地缩小模型规模。但它很好地说明了：如果领域边界足够清晰，评估标准足够扎实，微调用数据也足够高质量，就有可能把大模型的能力压缩到更小、更易部署的模型上。

1.3.3 蒸馏

如果能以极小的规模保留大模型的大部分智能，会怎样？这就是蒸馏背后的理念。

蒸馏是利用大型“教师”模型来训练较小的“学生”模型，让后者去模仿前者行为的过程。与在合成数据上做微调不同，蒸馏向学生模型展示的是教师模型的实际概率分布，而不仅仅是最终答案。微调旨在教导模型在特定领域表现更好，而蒸馏则教导模型如何模拟大型模型的行为——无论是好是坏。蒸馏在现实世界中的使用远少于微调。

当前沿实验室发布一整个模型家族时，较小模型通常并不是由大模型蒸馏而来，而是独立训练的，以避免大模型的偏差人为限制小模型的能力。但如果实验室只训练了一个大型模型，蒸馏就能让它更容易被实际使用。2025 年 1 月，开源模型研究实验室 DeepSeek 发布了当时的旗舰推理模型 DeepSeek-R1。由于该模型规模极大，共有 6710 亿参数，他们还基于当时最流行的开源架构 Llama 3 和 Qwen 2.5 发布了蒸馏版本。

这些蒸馏模型表现出了与 DeepSeek-R1 主模型相似的推理行为。虽然它们在智能基准上的得分更低，但模型尺寸也小得多，而且可以直接受益于现有的 Llama 和 Qwen 架构优化工作。发布后一段时间里，这些 DeepSeek-R1 蒸馏模型一直是 Hugging Face 上最受欢迎的蒸馏模型之一，与 Whisper 的蒸馏版和一些图像生成模型并列。

1.4 测量延迟和吞吐量

大语言模型（LLM）最常用的两个性能指标，是首字延迟（TTFT，Time to First Token）和每秒令牌数（TPS，Tokens Per Second）。关于 LLM 之外的特定模态指标，请参阅第 6 章。

虽然 TTFT 的含义很明确，但 TPS 经常被混用。它既可以指延迟指标，也就是单个用户每秒看到多少 token；也可以指吞吐量指标，也就是整个推理服务每秒生成多少 token。

大多数人使用 TPS 来指代每个用户的延迟指标。在需要时，请使用更具体的术语：

• 感知 TPS (Perceived TPS)：第一个令牌生成后，用户观察到的每秒令牌数（延迟）。

• 总 TPS (Total TPS)：推理服务每秒生成的令牌总数（吞吐量）。

• 令牌间延迟 (ITL, Inter-token latency)：连续两个令牌之间的时间间隔。10 毫秒的 ITL 相当于每个用户每秒 100 个令牌。

TTFT 和 TPS 最常用于面向用户的 LLM 系统（如聊天机器人），因为这类系统的输出是流式传输给用户的。对于其他请求（例如智能体的工具调用），您则应将延迟衡量为总响应时间，因为这些 token 无法单独使用。

1.4.1 延迟百分位

在讨论和比较指标时，一个重要的区别是你所衡量的百分位。

一种简单的方法是直接查看平均（mean）TTFT 或 TPS。然而，这并不能说明全部情况。LLM 的总响应时间通常呈右偏分布，大部分时间集中在众数附近，但异常值可能需要更长的时间。这些异常值会极大地影响用户体验和对产品的信任。如果十分之一的交互需要几秒钟，那么即使大多数交互感觉很快也是不够的。

因此，推理工程师通常会用百分位数来衡量延迟：

• P50：中位数延迟，每 2 次请求中就有 1 次更慢。

• P90：第 90 百分位延迟，每 10 次请求中就有 1 次更慢。

• P95：第 95 百分位延迟，每 20 次请求中就有 1 次更慢。

• P99：第 99 百分位延迟，每 100 次请求中就有 1 次更慢。

虽然降低平均延迟很重要，但良好的性能优化工作也侧重于降低 P90/P99 延迟，以获得更可靠的用户体验。

1.4.2 端到端指标

另一个重要区别在于，你衡量的是纯推理时间，也就是生成 token 所需的 GPU 时间，还是包含网络延迟和排队时间在内的端到端结果。这两类指标都值得看。推理时间告诉你模型性能优化做得怎么样；端到端指标反映的则是用户对应用速度的真实感知。如果推理本身已经很快，而端到端仍然很慢，就该把注意力转向基础设施，而不是继续深挖模型内核。