AI推理指南

推理基础

提示词与响应之间究竟发生了什么：生成循环、主导延迟的两个阶段、承载计算的硬件，以及用来描述它们的指标。

训练和推理是两件不同的事

训练在大规模数据集上调整模型权重，通常只做一次，运行在大型加速器集群上。推理把冻结的权重持续应用到新输入上，为产品收到的每一个请求服务。训练成本基本是一次性投入；推理成本会随流量不断累积，因此服务效率决定了一款 AI 产品的经济性。

训练

通过对数据批次做反向传播来更新权重
在多节点集群上运行数小时到数周
使用 PyTorch、JAX、DeepSpeed、Megatron 等工具
只有在现有模型都不合适时，才值得自己训练

推理

权重保持不变；每个请求就是一次前向传播
延迟以毫秒到秒计，按单个请求衡量
使用 vLLM、SGLang、TensorRT-LLM、LMDeploy 等服务栈
成本随流量增长，并伴随产品的整个生命周期

还有一个相关区别：推理框架负责高效执行模型，而推理服务器在其外面包上批处理、排队、流式输出、健康检查、自动扩缩容以及 HTTP 或 gRPC API。生产系统两者都需要。

模型如何把提示词变成文本

1. 分词提示词被切分成 token，并映射到固定词表中的 ID。决定成本和上下文上限的是 token 数量，而不是字符数量。
2. 嵌入token ID 变成向量；位置信息（例如 rotary embeddings）告诉模型每个 token 在序列中的位置。
3. prefill整个提示词在一次并行前向过程中通过 Transformer 各层。自注意力把每个 token 与它之前的所有 token 比较；因果掩码让 token 看不到它后面的内容。这个阶段受算力限制，决定首个 token 的时间。
4. decodetoken 逐个生成。每一步都要读取模型权重和缓存的注意力状态，因此这个阶段受内存带宽限制，决定 token 之间的延迟。
5. KV 缓存先前 token 计算出的注意力 key 和 value 会被缓存，于是每个新 token 只需关注已存储的状态，而不必重算整个序列。缓存随上下文长度线性增长，并与权重争夺 GPU 显存。
6. 采样与流式输出从概率分布中选出下一个 token（greedy、temperature、top-k、top-p）并追加到序列，通常会持续流式发送给客户端，直到触发停止条件或达到 token 上限。

prefill 与 decode 的划分解释了服务端的大部分行为：长提示词拖慢首个 token 的时间，长输出拖慢总延迟，而服务优化页面上几乎每一项优化，针对的都是其中某一个阶段。逐 token 生成是主流范式，但不是唯一范式：基于扩散的语言模型改为通过迭代精化一次生成整段文本，这是一个活跃的研究方向，延迟表现也不同。

推理在哪里运行

CPU

通用、随处可得，但并行吞吐有限。适合小模型或高度量化的模型、原型验证，以及没有加速器的边缘设备。

GPU

LLM 服务的默认选择：数千个并行核心和高带宽内存（HBM），正好匹配主导该负载的矩阵乘法。生态包括 CUDA 和 ROCm。

TPU 及其他 ASIC

专门设计的张量加速器（例如搭配 XLA/JAX 的 TPU）在大规模场景下可以很高效，代价是软件生态更窄，并且与服务商绑定更深。

选型依据是模型规模、请求量、延迟目标、成本，以及你已经在运维的基础设施。浏览器、边缘和移动端的执行分别在Web 推理与边缘与移动端中讨论。

描述推理服务的指标

指标	含义	最重要的场景
TTFT	首个 token 的时间，主要由排队加 prefill 构成	聊天以及任何交互式界面
ITL / TPOT	token 之间的延迟；每个输出 token 的时间是它在整段响应上的平均值	用户感知的流式速度
E2EL	请求的端到端延迟；TPOT 约等于 (E2EL - TTFT) / (输出 token 数 - 1)	批处理环节和工具调用链
TPS / RPS	给定并发下的每秒输出 token 数和每秒请求数	容量与成本规划
Goodput	只统计达成了延迟目标的那部分请求	受 SLO 约束的生产服务

同时报告中位数和尾部（P95/P99）数值；平均值会掩盖那些让用户记忆深刻的慢请求。
延迟和吞吐量相互制衡，而批大小是两者之间的主要调节杠杆。
每个数字旁边都要写清模型、硬件、序列长度和并发；脱离工作负载的指标没有意义。

AI Inference Guide

AI推理指南

训练和推理是两件不同的事

训练

通过对数据批次做反向传播来更新权重
在多节点集群上运行数小时到数周
使用 PyTorch、JAX、DeepSpeed、Megatron 等工具
只有在现有模型都不合适时，才值得自己训练

推理

权重保持不变；每个请求就是一次前向传播
延迟以毫秒到秒计，按单个请求衡量
使用 vLLM、SGLang、TensorRT-LLM、LMDeploy 等服务栈
成本随流量增长，并伴随产品的整个生命周期

模型如何把提示词变成文本

1. 分词提示词被切分成 token，并映射到固定词表中的 ID。决定成本和上下文上限的是 token 数量，而不是字符数量。

2. 嵌入token ID 变成向量；位置信息（例如 rotary embeddings）告诉模型每个 token 在序列中的位置。

3. prefill整个提示词在一次并行前向过程中通过 Transformer 各层。自注意力把每个 token 与它之前的所有 token 比较；因果掩码让 token 看不到它后面的内容。这个阶段受算力限制，决定首个 token 的时间。

4. decodetoken 逐个生成。每一步都要读取模型权重和缓存的注意力状态，因此这个阶段受内存带宽限制，决定 token 之间的延迟。

5. KV 缓存先前 token 计算出的注意力 key 和 value 会被缓存，于是每个新 token 只需关注已存储的状态，而不必重算整个序列。缓存随上下文长度线性增长，并与权重争夺 GPU 显存。

6. 采样与流式输出从概率分布中选出下一个 token（greedy、temperature、top-k、top-p）并追加到序列，通常会持续流式发送给客户端，直到触发停止条件或达到 token 上限。

推理在哪里运行

CPU

通用、随处可得，但并行吞吐有限。适合小模型或高度量化的模型、原型验证，以及没有加速器的边缘设备。

GPU

LLM 服务的默认选择：数千个并行核心和高带宽内存（HBM），正好匹配主导该负载的矩阵乘法。生态包括 CUDA 和 ROCm。

TPU 及其他 ASIC

专门设计的张量加速器（例如搭配 XLA/JAX 的 TPU）在大规模场景下可以很高效，代价是软件生态更窄，并且与服务商绑定更深。

选型依据是模型规模、请求量、延迟目标、成本，以及你已经在运维的基础设施。浏览器、边缘和移动端的执行分别在Web 推理与边缘与移动端中讨论。

描述推理服务的指标

指标	含义	最重要的场景
TTFT	首个 token 的时间，主要由排队加 prefill 构成	聊天以及任何交互式界面
ITL / TPOT	token 之间的延迟；每个输出 token 的时间是它在整段响应上的平均值	用户感知的流式速度
E2EL	请求的端到端延迟；TPOT 约等于 (E2EL - TTFT) / (输出 token 数 - 1)	批处理环节和工具调用链
TPS / RPS	给定并发下的每秒输出 token 数和每秒请求数	容量与成本规划
Goodput	只统计达成了延迟目标的那部分请求	受 SLO 约束的生产服务

同时报告中位数和尾部（P95/P99）数值；平均值会掩盖那些让用户记忆深刻的慢请求。

延迟和吞吐量相互制衡，而批大小是两者之间的主要调节杠杆。

每个数字旁边都要写清模型、硬件、序列长度和并发；脱离工作负载的指标没有意义。