AI 推理的一次請求會發生甚麼？訓練後的生成流程與服務成本

简介： 本文深入解析AI模型推理本质：训练是“学参数”，推理是“用参数”——不更新、不反向、只前向。详解一次请求的六步流程、大模型逐字生成机制（prefill/decode）、推理与服务/部署的区别，并揭示延迟-吞吐-并发的三难平衡。强调：推理成本常超训练10倍，懂推理，才真正打通数学与基础设施。

摘要：前六天我们搞懂了模型怎么表示世界、怎么学习。但训练结束之后呢？当用户真正发来一条请求，模型内部到底发生了什么？为什么推理不需要损失函数和反向传播？为什么大语言模型要一个字一个字往外蹦？以及——为什么一个云平台工程师会说，"搞懂推理，才把数学和基础设施连了起来"。

一、一个云平台工程师的困惑

有个做了多年云基础设施的工程师，说了一句很实在的话。

他说：像推理端点（inference endpoint）、模型服务（model serving）、GPU 利用率这些词，我熟得不能再熟——我天天配的就是这些东西。但我一直没把它们和模型内部实际在发生什么连起来。

这个困惑特别典型。

我们这个行业里，有大量的人是"懂怎么跑模型，不懂模型在干什么"。反过来也一样：懂算法的人，常常搞不清为什么线上延迟突然飙了。

而"推理"，恰好是这两拨人的接缝处。

今天这篇，就把这条接缝拆开。

二、一句话讲清训练与推理的关系

先给全文的文眼，这句话值得背下来：

训练，是学出参数；推理，是使用参数——而且不改变它们。

就这么简单，也这么重要。

训练结束的那一刻，那几百亿个数字就冻住了。此后每一次用户请求，模型都是拿着这副固定的参数，把输入算一遍，给出输出。它不会因为你问了它一句，就变得更聪明一点。

（这也是为什么"AI 会从对话中学习"是个常见误解——至少在没有刻意设计的情况下，它不会。）

一句话区分了两个世界：训练是一次性的、昂贵的、改变模型的；推理是持续的、频繁的、不改变模型的。

后面所有的工程问题，都是从这句话长出来的。

三、一次推理，实际走六步

图里把这个过程拆成了六步，我们顺着走一遍。还是用那个外卖配送的小模型：它学出来的参数是——偏置 b = 5，距离权重 = 2，拥堵权重 = 10，快速通道权重 = −2。

第一步：新请求进来。 距离 3 公里，不拥堵（0），没有快速通道（0）。

这里有个极容易被忽略、但极其致命的提醒：

输入的处理方式，必须和训练时完全一样——同样的量纲、同样的格式、同样的归一化。

你在训练时用的是"公里"，上线时传进来的是"米"，模型就会给出一个荒谬的答案，而且不会报错。工程上这类事故有个专门的名字，叫训练/服务不一致（training-serving skew）。它是模型上线翻车最常见的原因之一，而且特别难查——因为模型本身没问题，是喂给它的东西变了。

第二步：加载训练好的模型。 把这些固定的参数读进内存/GPU。

图里那句气泡特别传神："加载一次，服务很多请求！"

第三步：只跑前向传播。 用学到的权重和偏置，把输入算一遍。注意是"只跑前向"——没有回头，没有比较，没有修正。

第四步：得到原始输出。

时间 = 5 +（2 × 3）+（10 × 0）+（−2 × 0）= 11 分钟

第五步：后处理，变成人话。 模型吐出来的是一个数字。你要把它变成用户能用的答案——取整、加单位、套上业务规则。最终呈现给用户的是："预计送达时间：11 分钟。"

第六步：返回。

六步，就这么朴素。你每次用 AI，背后都是这六步。

四、为什么推理不计算损失、不算梯度、不更新权重？

这是图里专门用一整个模块回答的问题，也是很多人卡住的地方。

答案有两层。

第一层：我们是在"用"模型，不是在"学"。 学习和使用的目标完全不同——学习是为了改参数，使用是为了要结果。

第二层更关键：推理的时候，我们往往还不知道正确答案。

你想想，用户问"帮我写一首关于春天的诗"——正确答案是什么？没有标准答案。你连"真实值"都没有，怎么算损失？没有损失，怎么算梯度？没有梯度，怎么更新？

所以推理时被划掉的是这一串：损失、梯度、优化器、权重更新——统统不需要。

一张对照表看清楚两个世界的差别：

|
环节
|
训练
|
推理

|
| --- | --- | --- |
|
前向传播
|
✅
|
✅
|
|
计算损失
|
✅
|
❌（通常不知道答案）
|
|
反向传播
|
✅
|
❌
|
|
更新权重
|
✅
|
❌（参数固定）
|
|
跑多少遍
|
成千上万次迭代
|
每个请求一次
|
|
主要成本
|
算力（长时间占用）
|
延迟与吞吐（每次都要快）
|

这也解释了另一个工程细节：推理时某些"训练专用"的机制要关掉——比如 dropout（训练时随机丢弃一部分神经元防过拟合，推理时必须全部保留，否则结果不稳定）。所以框架里都有个 model.eval() 的开关，切换到"评估/推理模式"。忘切这个开关，是新手很常见的 bug。

五、大模型不一样：它要一个字一个字往外蹦

上面的例子是一次算出一个数字。但大语言模型不一样——它要生成一整句话。

图里画得很清楚：

输入 "The cat sat on the" → 模型给下一个位置打分：mat 0.42、rug 0.18、floor 0.12、seat 0.08 → 选出 "mat" → 把 mat 追加进去，再重复一次 → 得到 "The cat sat on the mat …"

这个过程叫自回归生成（autoregressive generation）：每生成一个字，都要把它拼回输入，再跑一遍完整的前向传播，才能生成下一个字。

所以生成 100 个字，模型就要完整地跑 100 遍。

这就引出了推理领域最重要的一个区分——两个阶段：

Prefill（预填充）：把你输入的整个提示词并行处理一遍，把中间结果（KV cache）存好。这一步是计算密集的，输入越长越慢。它决定了首字延迟（TTFT）——你按下回车到屏幕上出现第一个字的时间。
Decode（解码）：一个 token 一个 token 往外生成，每一步都要把模型参数和 KV cache 读一遍。这一步是显存带宽密集的、串行的。它决定了每字间隔（TPOT / ITL）——也就是你感觉到的"打字速度"。

为什么每生成一个字都要把整个模型读一遍？这正是我们前面讲过的那件事：参数是存在显存里的，每步计算都必须把它们搬进计算单元。所以 decode 的瓶颈不是算力，而是"搬运"。懂了这一层，你就明白为什么"更大的模型"和"更长的上下文"会让推理变慢——要搬的东西变多了。

顺带一个数量级感受：KV cache 的占用可以按公式估——每 token 大约 2 × 层数 × KV 头数 × 头维度 × 每元素字节数。一个 36 层、8 个 KV 头、128 维、fp16 的模型，约 144 KiB/token；那么一个 128k 长度的上下文，单个会话就要约 18.9 GB，8 个这样的并发会话就是约 150 GB——不管模型权重本身有多小。这就是为什么长上下文这么贵。

六、三个词别混用：推理、模型服务、部署

这三个词天天被混着说，但它们说的是三件不同的事：

推理（Inference）：一次计算。把输入变成一个输出。
模型服务（Model Serving）：让模型持续可被调用的那套系统。它要接住很多请求、排队、批处理、把硬件用满。
部署（Deployment）：把这套东西放进生产环境、接进你的应用的整个过程——包括版本、灰度、监控、回滚。

打个比方：推理是"做一杯咖啡"，模型服务是"经营这家咖啡店"（排队、出品节拍、人手安排），部署是"把店开起来并接入商场"。

大部分线上问题，不出在"做一杯咖啡"上，而出在"经营这家店"上。

七、延迟、吞吐、并发：一个谁也逃不掉的三难

图里给了三个词的定义，值得背下来：

延迟（Latency）：多久能得到响应（比如 200 毫秒）
吞吐（Throughput）：单位时间能处理多少请求或 token（比如 100 req/s）
并发（Concurrency）：同时有多少用户在用

这三者的关系，是推理工程的核心难题。

批处理（Batching）是提升吞吐的主力手段。 直觉上，一次处理 64 个请求，总比一个个来划算。实际数据也确实漂亮：从 batch 1 提到 batch 64，吞吐能翻约 34 倍，而每个字的间隔（TPOT）只涨了大约一倍——因为不管批次多大，模型权重每一步都只需要读一遍，平摊下去极省。

但收益有尽头。 再往上堆，KV cache 的占用会迅速长大，逐步追平甚至超过权重的开销；此后每字间隔开始线性上升，而吞吐的增益越来越小。曲线上会出现一个"膝点"——那才是你真正该跑的地方。

然后是最重要的一条铁律，来自排队论：

当系统利用率逼近 100%，等待时间会无界地增长。

也就是说：把 GPU 跑满，不是效率最优，而是灾难的前兆。 你必须留余量。

（还有个常见的坑：冷启动。把模型权重加载进 GPU，可能要几十秒。所以生产环境要保持实例"热"着，否则第一个用户会等到怀疑人生。）

工程上为了在这三难里腾挪，这几年发展出一整套手法：连续批处理（continuous batching，请求按 token 粒度进出批次，不必等整批结束）、PagedAttention（把 KV cache 分页管理，减少碎片、提高并发）、前缀缓存（共享的系统提示词只算一次）、量化（把权重压成更低精度，省带宽）、投机解码（小模型先起草、大模型并行验证，常能快 1.5–2 倍）。

这些手法的本质，都是在"延迟、吞吐、成本"这个不可能三角里，选一个对你最重要的角去优化。

八、一个你可能没算过的账

这里有个数字，我觉得每个打算上 AI 的决策者都该知道：

在一个模型的整个生命周期里，花在推理上的算力，往往会超过训练算力的 10 倍以上。

原因很直白：训练是一次性（或周期性）的大额投入；而推理是每一次用户请求都在发生，日复一日、永不停止。

所以行业里有句话：训练决定模型能不能用，推理决定这个生意能不能成立。

很多团队做预算时，只算了"训练/采购"那笔一次性的钱，却没算"每天运行"的那笔持续的钱。等上线三个月发现账单，往往已经晚了。

这其实是个特别经典的商业结构：一次性投入换来的能力，其真实成本取决于你使用它的频率。

九、场景不同，该优化的指标完全不同

最后讲一个特别实用、也特别容易被搞错的判断。

聊天应用，该死磕首字延迟（TTFT）。

理由是生理性的：成人默读非虚构材料的速度大约是每分钟 238 个词，折合约每秒 5–6 个 token（Brysbaert 2019 的元分析）。所以只要输出能维持在 20 token/秒以上，就已经跑赢了几乎所有人的阅读速度——再往上压，用户根本感觉不到。

而用户唯一能明确感知的那段"空白"，是按下回车到第一个字出现之间的等待。Nielsen 的经典研究把"思路不被打断"的边界放在约 1 秒。

所以：聊天产品里，把 TTFT 从 800ms 压到 300ms，用户会说"快了好多"；把输出从 40 tok/s 提到 80 tok/s，用户毫无感觉。

但换成 AI 智能体（Agent），结论完全反过来。

Agent 不是边生成边读，它是每一步都阻塞着等完整的结果，拿到再往下走。在这种场景里，首字延迟几乎不重要，端到端的总延迟才是命门。

同样一项技术，在两种场景下的优化重点完全相反。

这提醒我们一件事：在选指标之前，先搞清楚你的用户到底在"等"什么。 拿单一 KPI 去衡量所有场景，是最常见的无效优化。

十、七条提醒，和四条可以带走的

图最后列了七条提醒，我挑最容易被忽视的几条，配上落地的建议：

第一，"加载一次，服务很多请求"——这就是规模效应的定义。

前期把参数学出来（固定成本），之后每一次服务只花边际成本。这门生意之所以成立，全靠这条。反过来说：如果你的模型用不了几次，那前期那笔训练投入就永远摊不平。 上 AI 之前，先估一下调用量。

第二，把账单算全：训练是一次性的，推理是永远的。

做预算时把生命周期内的推理成本单独列一行。那个数字很可能是训练投入的十倍以上。别在上线三个月后才发现。

第三，别把系统跑满——留余量不是浪费，是保险。

利用率逼近 100%，等待时间会无界增长。这条排队论的铁律，技术和管理上同样成立：一个排满 100% 的团队，不是效率最高的团队，而是一个没有能力应对任何意外的团队。 日程排满、产能拉满、人手用满，看起来很高效，一旦来了个突发事件，全线阻塞。

第四，先搞清楚用户在等什么，再决定优化什么。

聊天要快出第一个字；批处理要总吞吐；Agent 要端到端总时长。指标选错了，所有努力都是白费。

组织里也一样：你优化"响应速度"还是"一次做对"，取决于你服务的是什么场景。别拿一把尺子，量所有的事。

结语

回到开头那个工程师的困惑：熟悉推理端点、模型服务、GPU 利用率，却不知道模型里在发生什么。

现在这条线接上了：

推理时，参数固定不动——所以不需要损失、不需要梯度、不需要更新；它只跑一次前向；大模型还要一个字一个字往外蹦，每蹦一个字都要把全部参数读一遍；而把无数次这样的请求接住、排队、批处理、塞进硬件，就叫模型服务；决定这套系统好不好用的，是延迟、吞吐、并发这三个互相拉扯的量。

他说得对：理解"训练学参数、推理用参数"这个区分，就把 AI 的数学和跑它的基础设施连起来了。

而我想再补一句：

训练是一次性的英雄主义，推理是日复一日的经营。 真正决定一个 AI 产品能不能活下去的，从来不是它训练时有多惊艳，而是它每天被调用成千上万次时，是不是又快、又稳、又便宜。

互动话题：你有没有遇到过"系统跑得满满当当，结果一个突发就把全线堵死"的情况？技术上叫排队论，管理上叫什么？欢迎评论区聊聊你的故事。

免责说明：本文核心框架整理自社交平台「100 Days of AI Inference」系列 Day 7/100 公开信息图《Inference. Using What Was Learned》（图内仅标注系列名，未署个人作者，故不臆造出处）。图中示例与流程（参数 b=5、w₁=2、w₂=10、w₃=−2；Time = 5 + 2×3 = 11 分钟；"加载一次，服务很多请求"；划掉损失/梯度/优化器/更新；逐 token 采样 mat 0.42、rug 0.18、floor 0.12、seat 0.08；回归/分类/文本生成三类输出；CPU/GPU/加速器与云端或本地；延迟 200 ms、吞吐 100 req/s、并发定义及七条提醒）均以原图为准。补充的工程与学术细节经多源交叉核实：LLM 推理的 prefill（并行、计算密集、决定 TTFT） 与 decode（串行、显存带宽密集、决定 TPOT/ITL） 两阶段划分；KV cache 每 token 占用估算式 2 × 层数 × KV 头数 × 头维度 × 字节数，文中 36 层/8 KV 头/128 维/fp16 约 144 KiB/token、128k 上下文约 18.9 GB/序列为按该公式的示例性推算；continuous batching（Orca, OSDI 2022）、PagedAttention（SOSP 2023，vLLM）、前缀缓存、量化与投机解码等优化手段；batch 1→64 吞吐约 34 倍而 TPOT 约翻倍、越过膝点后收益递减，属特定模型与硬件下的经验量级，非普适常数；排队论结论：利用率逼近 100% 时等待时间无界增长；生命周期内推理算力常超训练算力 10 倍以上为行业经验口径；人类默读约 238 词/分钟、约合 5–6 token/秒（Brysbaert 2019 元分析）与 Nielsen 约 1 秒的响应阈值，用于说明"聊天场景优先压 TTFT、Agent 场景端到端延迟才是命门"的场景差异。本文与本项目第 28 篇（GPU 显存与搬运瓶颈）、第 34 篇（模型与参数）、第 37 篇（权重与偏置）、第 38 篇（训练闭环）相互呼应。本文为技术科普与思维类比，不构成容量规划或投资决策建议；实际性能请以你所用模型、硬件与负载的实测为准。