AI 推理的含义：架构、性能与云部署指南

AI 推理是指将训练好的 AI 模型用于新的输入以产生输出：分类、预测、嵌入、图像、词元流或决策。训练会改变模型学习到的参数；推理则使用这些参数来完成有用的工作。对于 LLM，实际任务是快速、可靠地将提示词转换为生成的词元，并且成本要适合该工作负载。

这个定义很简单。在生产环境中运行推理并不简单。一个请求必须经过身份验证、路由、排队、词元化、硬件调度、模型运行、流式返回、度量，并在发生故障时恢复。本指南将从这一运营角度解释AI 推理的含义：应用请求与有用响应之间发生了什么、哪些指标真正重要，以及如何在云 GPU 上部署该工作负载，而不是将演示当作生产系统。

一句话说明 AI 推理的含义

AI 推理是机器学习的执行阶段：训练好的模型将学习到的参数应用于新数据并返回输出。 NVIDIA 将推理描述为训练好的模型根据新数据生成输出的阶段，而训练则是利用训练数据迭代调整模型权重的过程。NVIDIA 的 AI 推理概述是了解这一差异的有用一手参考资料。

如果你搜索的是AI 推理的含义，请记住这个心智模型：

训练教会模型。推理让训练好的模型开始工作。

对于聊天应用，这项工作是生成式的：处理提示词、一次预测一个下一个词元，并持续返回流，直到达到停止条件。对于分类器，它可能是一个单独的分数。对于嵌入模型，它可能是一个向量。核心概念不会改变：新输入进入；结果输出；对于该请求，学习到的权重保持不变。

AI 推理与训练、微调和服务的区别

这些术语彼此相关，但解决的是不同的任务。混淆它们会导致团队购买错误的基础设施，或衡量错误的指标。

换句话说，AI 推理的含义并不是“整个平台”。它是模型执行这一步。推理服务是围绕该步骤构建的生产系统，使其他软件能够使用它。

这一框架将AI 推理的含义从词汇问题转化为运营决策：先识别模型执行步骤，然后为使其可靠运行的一切事项分配职责。

LLM 的 AI 推理如何工作

不同模型系列的具体实现有所不同，但生产环境中的 LLM 请求通常遵循以下路径：

1. 应用发送请求。客户端提供消息或提示词、生成限制，以及身份或租户上下文。
2. 边缘层或 API 层对其进行验证和路由。身份验证、配额、模型选择、安全检查和请求日志通常都位于这里。
3. 服务器对输入进行词元化。文本会转换为模型可读取的词元 ID。图像、音频或结构化输入需要针对其模态进行预处理。
4. 预填充处理提示词。模型在一次较大的首次传递中计算提示词上下文。NVIDIA 的 LLM 推理概述将其与解码区分开来，并将两者都视为端到端请求延迟的一部分。查看预填充/解码说明。
5. 服务器保留可用的注意力状态。Transformer 服务系统通常会为活动序列保留键/值（KV）状态，以便每个下一个词元不必重新计算整个先前上下文。TensorRT 将 KV 缓存记录为由应用或框架管理的内存资源，而非事后考虑。阅读 TensorRT KV 缓存参考文档。
6. 解码逐词元生成输出。模型反复预测下一个词元、更新状态，并且要么流式传输部分响应，要么等待生成完成。
7. 平台对结果进行计量和观测。生产响应应留下足够的证据，以调查延迟、错误、饱和度和使用情况，同时不存储超出系统所需的客户内容。

这就是AI 推理的含义这一简短定义背后的架构。模型本身并不是低延迟服务；它需要一条涵盖请求、计算、状态和反馈的路径。

部署前应绘制的云推理架构

在选择 GPU 类型或服务引擎之前，先勾勒请求路径。以下参考架构适用于在云 GPU 上自托管的 LLM 或多模态模型端点。

客户端 / 应用程序
        │
        ▼
API 边缘层：身份验证 · 限制 · 请求 ID · 路由
        │
        ▼
队列 / 调度器 ──► 准入控制和超时
        │
        ▼
推理服务器：分词器 → 预填充 → KV 缓存 → 解码 / 流式传输
        │                         │
        ▼                         ▼
GPU 工作节点池              缓存容量信号
        │
        ▼
指标、追踪、日志、告警和部署控制

每一层都对应不同的故障模式：

• API 边缘层：无效凭据、配额耗尽、错误的模型参数、租户隔离和请求关联。
• 队列和准入层：背压、优先级决策、超时策略，以及防范过载级联。
• 推理服务器：模型加载、分词、批处理、内存分配、提示词执行、令牌生成和流式传输。
• GPU 工作节点池：硬件可用性、驱动程序/运行时兼容性、GPU 内存余量、网络拓扑和副本健康状态。
• 可观测性：缓慢请求是在等待、预填充、解码、重试，还是在到达 GPU 之前就已失败。

对于大规模部署，此结构可能会增加模型注册表、制品存储、独立的预填充层、独立的解码层或缓存感知路由器。不要从这些开始。先从一条可观测、可重复的路径开始，只有当测量结果表明较简单的拓扑无法达到其服务目标时，才引入拆分。

重要的四个性能维度

团队经常问：“模型有多快？”这对于指导推理部署而言过于模糊。一份有用的性能评审会将其分为四个维度。

当前 vLLM 文档通过其指标端点公开了排队时间、预填充时间、解码时间、TTFT、请求延迟和每个输出令牌时间的直方图。请将其生产指标列表用作具体的监测清单。

重要的关联在于：AI 推理的性能不是一个数字。部署可能产生令人印象深刻的总体每秒令牌数，但仍会给交互式用户带来糟糕的 TTFT。它也可能很快交付第一个令牌，却在长输出时严重变慢。在更换硬件或调整参数之前，应按阶段测量请求路径。

为什么批处理能提高吞吐量——却可能损害错误的延迟目标

云 GPU 在闲置时成本高昂，因此推理服务器通常会将兼容的请求分组成批。NVIDIA Triton 的动态批处理器会合并请求，并允许运维人员限制调度器为更大批次等待的时长。这使权衡变得明确：更长的等待窗口可能提升利用率和吞吐量，但会增加排队延迟。Triton 的批处理器文档解释了这些控制项。

对于 LLM，“连续”“飞行中”或“迭代级”批处理可以使这种调度更灵活。服务器无需等待旧批次中的每个序列完成，而可以在连续的生成步骤中，用新的或进行中的工作填充释放出的槽位。NVIDIA 将这种方法记录为一种在迭代处理中混合新请求和进行中请求的方式。请参阅 Triton 对连续批处理的说明。

不要将批处理视为一个勾选项。请根据书面的延迟预算对其进行测试：

• 交互式聊天和 IDE 辅助通常非常关注 TTFT 和输出节奏。
• 批量摘要、嵌入生成和离线增强可以接受更长的队列，以换取更高的已完成工作吞吐量。
• 长上下文工作会将更多压力转移到预填充和缓存容量上。
• 长输出工作会更长时间地占用解码资源，从而改变公平排队和取消行为。

这一权衡是实践中AI 推理含义的核心：服务必须决定如何共享有限的计算资源，而不仅仅是执行一次前向传播。

云 GPU 部署：托管 API 还是自托管推理？

不存在普遍“正确”的部署模型。应根据你的工作负载真正需要的控制面来选择。

大多数成熟系统都是混合型的。团队可能会自托管稳定的高流量模型，同时将托管 API 用于长尾模型、实验性模态、突发容量或备用路由。真正有用的问题不是“云 GPU 还是 API？”，而是“请求路径中的哪些部分必须由我们掌控？”

如需更深入的成本与运维决策框架，请参阅 GPU 云与模型 API。如果你选择自行管理服务端点，兼容 OpenAI 的推理服务器指南介绍了以 vLLM 为导向的实用实现路径。

面向生产环境的云 GPU 部署手册

对于部署团队而言，AI 推理的含义是一张责任地图：识别请求的每个阶段，定义其必须达成的目标，并使责任人和故障信号清晰可见。

1. 在资源置备前编写验收契约

以可测试的方式记录工作负载：

• 模型及版本，包括许可证和工件来源。
• 输入模态、提示词长度分布以及预期输出长度。
• 峰值和持续请求并发量。
• TTFT、TPOT、端到端延迟、错误率和可用性目标。
• 流式传输、取消、数据保留和区域要求。
• 用于评估输出质量的代表性评估集，而不只是负载生成器。

没有这份契约，“我们需要更快的 GPU”不是决策，而是猜测。

2. 建立单副本基线

在非生产环境中运行一个模型副本，并在具有代表性的短输入和长输入混合负载下收集阶段级指标。记录模型服务器版本、驱动程序/运行时版本、模型修订版本、分词器修订版本、批处理策略和并发量。可复现的基线使后续的容量分析和事件分析成为可能。

对于选择服务引擎的团队，vLLM 与 SGLang提供的是面向工作负载的比较，而不是笼统地宣称谁是赢家。

3. 将内存规划为权重加运行时状态，而不只是模型大小

GPU 内存必须容纳的不只是检查点。它还需要为运行时缓冲区和活动序列状态（例如 KV 缓存）预留空间。TensorRT 文档明确了分配边界：缓存容量在 Transformer 层本身之外进行管理。这意味着模型加载可能成功，而实际的并发流量仍会造成缓存压力。

使用包含实际上下文长度和输出限制的经验容量测试。跟踪缓存占用率、服务器提供此类指标时的抢占或驱逐情况，以及准入边界处的故障行为。有关 GPU 内存规划的相关框架，请阅读 LLM GPU 内存要求。

4. 明确 GPU 调度策略

Kubernetes 支持用于 GPU 的供应商设备插件，并将其公开为可调度资源。其 GPU 调度指南规定，自定义 GPU 资源应置于容器的 limits 中，而 requests 则应省略或与限制值相等。在调整以下清单前，请查阅 Kubernetes GPU 调度文档。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inference-server
  template:
    metadata:
      labels:
        app: inference-server
    spec:
      containers:
        - name: server
          image: registry.example.com/inference-server:immutable-tag
          resources:
            limits:
              nvidia.com/gpu: 1
              cpu: "4"
              memory: 32Gi

将 nvidia.com/gpu 视为 NVIDIA 设备插件安装的示例资源名称。部署前，请在自己的集群中确认资源名称、节点标签、运行时和放置策略。不要将此最小化清单用作完整的生产配置；它有意省略了密钥、探针、网络策略、存储、自动扩缩容和发布控制。

5. 根据 SLO 调优排队与批处理

从保守的队列限制和明确的超时设置开始。仅在相关百分位数保持在验收契约范围内时，才增加批处理大小或批处理延迟。请针对以下情况进行单独的负载测试：

• 小提示词和短输出。
• 长提示词和短输出。
• 短提示词和长输出。
• 具有不同优先级的混合租户。
• 停止读取流的慢速客户端。
• 取消、重试和工作节点故障路径。

如果某项更改改善了一个性能配置文件，却降低了另一个的表现，不要将它们简单平均处理。应拆分工作负载、修订准入策略，或如实说明服务层级。

6. 为各层进行监测，而不只是监测模型

至少应记录请求 ID、状态代码、模型/版本、排队时长、预填充时长、首个 token 时间、解码时长、每个输出 token 的时间、生成 token 数量、取消率以及 GPU/服务器健康状况。将客户端可见延迟与服务器阶段指标关联起来。这样，值班工程师就能回答一个基本但关键的问题：此请求是在等待、计算、失败，还是断开连接？

7. 逐步发布并演练故障

使用不可变构件、测试模型就绪状态的健康检查、金丝雀流量切片，以及便捷的回滚路径。然后测试那些你希望永远不会发生的故障：模型加载失败、GPU 工作节点不可用、队列饱和、依赖项超时、无效的模型配置，以及流式传输期间客户端断开连接。

如果单个模型无法独自满足工作负载的可靠性目标，请提前决定后备方案应是另一个自托管副本、不同的模型，还是托管 API 路径。这份模型回退策略指南可帮助你梳理这一决策。

团队首次部署 AI 推理时的常见错误

将成功的演示当作容量规划

单用户提示只能证明模型能够启动。它并不能证明该端点能够在生产并发、可变提示长度、流式客户端或工作节点故障的情况下达到其延迟目标。

在定义延迟承诺之前优化吞吐量

更大的批次可以提高硬件利用率，但交互式产品的评判标准是用户等待的时间。先定义百分位目标，再调优为其提供服务的系统。

只测量平均延迟

平均值会掩盖队列峰值、长尾提示、冷启动和租户间干扰。应使用百分位数和特定阶段指标。较快的均值并不能证明最慢的用户体验可以接受。

忽视 KV 缓存行为

Token 生成在一个序列中是有状态的。即使仅权重内存估算看起来比较宽裕，缓存占用率、上下文长度、并发性、复用策略和驱逐行为也可能决定实际负载能否成功运行。

将硬件作为首要决策

硬件很重要，但模型格式、服务引擎、请求分布、批处理策略、拓扑和可观测性都会改变结果。在宣布某个 GPU 配置“足够快”之前，先测量工作负载。

AI 推理常见问题

AI 推理与 AI 模型 API 相同吗？

不相同。AI 推理是模型针对新输入执行计算。AI 模型 API 是访问推理的一种方式。API 提供商可以为你运营服务基础设施，或者你也可以在 API 后面公开自己的推理服务器。

推理会改变模型吗？

常规推理不会更新模型权重。训练和微调会更新权重。系统可能会记录推理结果以供后续评估或训练，但这是一个独立的工作流，具有其自身的数据和治理选择。

为什么 LLM 推理分为预填充和解码？

预填充处理提示上下文，而解码按顺序生成输出 token。这两个阶段对服务系统施加的压力不同，因此应分别测量 TTFT 和输出 token 的生成节奏。

AI 推理需要云 GPU 吗？

并非总是如此。某些工作负载可在 CPU、边缘加速器或托管模型 API 上运行。当你的模型、延迟目标、吞吐量要求或服务配置需要 GPU 加速，且你希望运营该基础设施时，云 GPU 才具有相关性。

我首先应该监控什么？

从成功请求、错误、排队时间、TTFT、每个输出 token 的时间、端到端延迟、生成 token 数量以及 GPU/服务器健康状况开始。随着服务引擎提供这些指标，再添加特定于模型的缓存和调度器指标。

将定义付诸实践

AI 推理的实际含义很直接：训练好的模型针对新输入运行并产生输出。工程工作在于让该输出在真实流量下保持及时、可观测、经济且有韧性。

先写下请求配置文件和验收指标。当托管 API 能够提供工作负载所需的控制级别时，选择托管 API；当你有经过测量的理由来拥有服务路径时，选择云 GPU 推理。然后，在优化之前，让预填充、解码、排队、缓存状态和故障处理变得可见。

如果某些工作负载通过 API 而非自托管 GPU 能获得更好的服务，探索 Flatkey 的模型目录，或者在GPU 云与模型 API 指南中比较架构选项。

延伸阅读

• NVIDIA：什么是 AI 推理？
• NVIDIA Triton：批处理器
• vLLM：生产指标
• Kubernetes：调度 GPU
• NVIDIA TensorRT：KV 缓存