推理与部署：模型能力如何稳定跑起来？

上一篇讨论 RAG 和微调时，已经把一个关键问题拆清楚了：

知识放在哪里，
取决于它是否变化、是否需要追溯、是否要被模型内化成稳定行为。

但模型训练完、评估完、知识位置也想清楚以后，还有一个更现实的问题：

它怎么稳定地跑起来？

这一步很容易被低估。

因为在个人电脑上跑通一次模型，和让模型稳定服务用户，是两件完全不同的事。

前者像在厨房里试做一道菜。

后者像开一家餐厅：

• 食材要够
• 火候要稳
• 出餐要快
• 高峰期不能乱
• 客人不能等太久
• 后厨出错要能发现
• 成本不能比收入还高

模型部署也是这样。

训练得到的是能力。

推理和部署要解决的是：

怎样把这种能力，以稳定、可控、可负担的方式交给真实用户。

如果这一步没想清楚，模型再聪明，也可能停在“演示效果不错”的阶段。

---

1. 先把训练和推理分开

很多人第一次接触模型，会把训练成本和推理成本混在一起。

它们都消耗算力，都可能用显卡，都和 token 有关。

但它们的目标完全不同。

阶段	发生了什么	参数会不会变	主要关注
训练	模型根据答案修正参数	会	学得准不准、会不会过拟合、显存够不够
微调	在已有模型上继续塑形	会	新能力是否稳定、旧能力是否受损
推理	模型根据输入生成输出	不会	响应快不快、并发扛不扛、成本能不能接受

训练像学习。

推理像考试和上班。

学习时可以慢一点，可以反复改，可以一批数据一批数据地训练。

上班时不行。

用户问一句，系统就要回答一句。

用户不会关心模型曾经训练了多少轮。

用户只会感受到：

等了多久
答得准不准
会不会突然断
价格能不能接受
体验是不是稳定

所以推理不是训练的附属品。

它是模型进入真实世界的入口。

---

2. 一次模型回答，实际发生了什么

从用户视角看，模型回答很简单：

输入问题 → 得到答案

但系统视角里，中间要经过一条链路：

flowchart LR
  A["用户请求"] --> B["鉴权 / 限流"]
  B --> C["组装 Prompt"]
  C --> D["Tokenizer 切成 token"]
  D --> E["Prefill 读取上下文"]
  E --> F["Decode 逐 token 生成"]
  F --> G["安全检查 / 格式校验"]
  G --> H["流式输出 / 完整返回"]
  H --> I["日志 / 监控 / 计费"]

每一步都可能影响体验。

鉴权和限流决定接口会不会被刷。

Prompt 组装决定模型看到什么。

Tokenizer 决定输入到底变成多少 token。

Prefill 决定模型理解整段上下文需要多久。

Decode 决定答案一个字一个字吐出来的速度。

安全检查和格式校验决定输出能不能进入业务系统。

日志和监控决定出了问题以后能不能定位。

所以部署不是“把模型放到服务器上”这么简单。

更准确地说：

部署是把模型包进一套可服务、可观察、可控制的运行系统里。

---

3. 推理成本为什么和训练成本不是一回事

训练时，系统关心的是如何让参数变好。

推理时，参数已经固定。

这时系统关心的是如何更便宜、更稳定地使用这些参数。

可以用一个普通场景理解：

训练像建造一台机器。

推理像每天开这台机器生产产品。

造机器很贵，不代表每天开机器就便宜。

机器造好了，也不代表它能连续稳定生产。

推理成本主要来自几部分：

1. 模型权重占用的显存
2. 输入上下文带来的计算
3. 输出 token 一个个生成的时间
4. KV Cache 随对话长度增长占用的显存
5. 多用户并发带来的排队和调度
6. 日志、监控、安全校验、网络传输等系统开销

这也是为什么同一个模型，在不同使用方式下成本差异很大。

只问一句短问题，成本不高。

塞一大段文档，再让它输出长答案，成本就会上去。

一个人用，能跑就行。

一百个人同时用，就要考虑排队、超时、吞吐和降级。

推理的难点，不是模型能不能算出答案。

而是：

在可接受的时间内，
用可接受的成本，
稳定地算出足够好的答案。

---

4. 延迟、吞吐、并发：这三个词不要混

部署模型时，经常会看到三个词：

延迟
吞吐
并发

它们很容易被混用，但含义不一样。

指标	问的是什么	用户感受
延迟	单个请求等多久	“怎么还没回？”
吞吐	单位时间能处理多少 token / 请求	“系统整体能扛多少量？”
并发	同时有多少请求在跑	“多人同时用会不会堵？”

延迟关心单个用户。

吞吐关心系统总产能。

并发关心高峰期有多少任务同时挤进来。

这三者会互相拉扯。

为了提升吞吐，系统可能把多个请求合成一批处理。

这样显卡利用率更高。

但如果为了凑批次让某个用户多等了一会儿，单个用户的延迟就可能变差。

为了降低延迟，系统可以优先处理小请求。

但大请求可能被饿住。

为了支持更多并发，系统可以拉长队列。

但队列太长，用户看到的就是等待。

所以部署不是追求某一个指标最大。

而是在业务场景里找到平衡。

客服助手、代码补全、长文总结、批量离线分析，对这三个指标的要求完全不同。

---

5. TTFT：用户最先感受到的等待

推理体验里有一个很重要的指标：

TTFT = Time To First Token

意思是从请求发出，到模型吐出第一个 token，需要多久。

用户不一定知道这个词。

但用户能感受到它。

如果第一个字迟迟不出来，用户会觉得系统卡住了。

即使后面生成速度很快，第一下等待太久，体验也会变差。

一次回答的总时间，可以粗略拆成：

总等待时间 ≈ 排队时间 + 首 token 时间 + 输出 token 数 / 生成速度

这里有三个关键点：

1. 排队时间来自并发和调度
2. 首 token 时间受 prompt 长度、模型大小、硬件和缓存影响
3. 输出越长，总生成时间越长

这就是为什么同一个模型，有时回答很快，有时突然变慢。

不是模型“心情不好”。

可能只是：

• 这次 prompt 太长
• 当前队列太满
• 输出要求太长
• 上下文缓存没命中
• 显存接近上限
• 后处理规则太复杂

推理优化的很多工作，都是在控制这些变量。

---

6. Prefill 和 Decode：模型回答分两段

模型生成答案时，可以粗略分成两个阶段：

Prefill：先读完整个输入上下文
Decode：再一个 token 一个 token 往外生成

Prefill 像演员先读剧本。

Decode 像演员开始一句一句表演。

如果剧本很长，读剧本就慢。

如果台词很长，表演就慢。

这两个阶段消耗的资源不一样。

阶段	做什么	主要受什么影响
Prefill	处理输入 prompt	输入 token 数、上下文长度、模型大小
Decode	逐步生成输出	输出 token 数、KV Cache、批处理、采样设置

这就是为什么“上下文越长越好”不是免费的。

长 prompt 会让 Prefill 更慢。

长对话会让 KV Cache 更大。

长输出会让 Decode 持续更久。

RAG 也会受到这里影响。

检索到的资料越多，模型看到的上下文越长。

如果把所有资料一股脑塞进去，表面上是“知识更充分”，实际可能变成：

更慢
更贵
更容易被无关信息干扰

所以好的 RAG，不只是找资料。

还要控制放进上下文的材料质量和长度。

---

7. KV Cache：长对话为什么越来越吃显存

Attention 那一篇里讲过，模型在生成时需要看前文。

如果每生成一个 token，都从头重新计算一遍所有前文，代价会很高。

KV Cache 的作用，就是把已经算过的 Key 和 Value 存起来。

下一步生成时，可以复用。

可以把它想成演员演一场长剧时的场景笔记。

前面发生过什么，不需要每次都重新演一遍。

但笔记要一直放在桌上。

剧情越长，笔记越厚。

KV Cache 也是这样：

它节省重复计算，
但会占用显存。

一段对话越长，KV Cache 越大。

并发用户越多，需要同时保存的 KV Cache 越多。

这就是长上下文服务真正贵的地方之一。

它不只是模型权重本身大。

而是每个活跃请求都会带着自己的上下文状态。

可以用一张简化图看：

flowchart TB
  A["模型权重"] --> D["显存占用"]
  B["当前请求的 KV Cache"] --> D
  C["运行时缓冲与框架开销"] --> D
  E["并发请求 1"] --> B
  F["并发请求 2"] --> B
  G["并发请求 N"] --> B

所以部署时不能只问：

模型权重能不能塞进显存？

还要问：

带着上下文和并发以后，
还能不能稳定运行？

这就是很多本地演示和线上服务差距巨大的原因。

---

8. 量化到底省了什么

量化常被说成“把模型压小”。

这个说法大体没错，但不够精确。

更准确地说：

量化主要是在用更低精度表示模型权重，从而减少显存占用和内存带宽压力。

模型权重原本可能用 16 位浮点数表示。

量化以后，可能用 8 位、4 位，甚至更低精度表示。

像一本厚字典。

原来每个字都用很精细的墨水和纸张记录。

量化以后，用更紧凑的方式记录。

字典变薄了，搬运更轻了。

但如果压得太狠，有些字就可能糊掉。

方式	直觉	可能收益	可能代价
FP16 / BF16	比较常见的推理精度	质量稳，兼容好	显存占用较高
INT8	中等压缩	显存下降，速度可能改善	少数任务可能受影响
INT4	更激进压缩	更容易在小显存运行	质量波动风险更高

量化省下来的，主要是模型权重相关的显存和带宽。

但它不是万能钥匙。

它不能自动让模型更聪明。

也不一定让所有场景都更快。

更重要的是：

量化主要压的是模型权重，
长上下文和并发带来的 KV Cache 仍然要认真计算。

所以如果一个服务真正的瓶颈是长对话并发，单纯把权重量化，可能只能解决一部分问题。

这也是部署要做整体账本的原因。

---

9. 显存账本：不是只看模型大小

部署模型时，最常见的误区是只看模型文件大小。

比如看到一个模型文件 8GB，就以为 8GB 显存一定能跑。

这通常不可靠。

显存里不只放模型权重。

还要放：

• KV Cache
• 中间计算缓冲
• 推理框架自身开销
• batch 里的多个请求状态
• adapter 或额外模块
• 安全余量

可以把显存想成一个工作台。

模型权重是主机器。

KV Cache 是每个订单的半成品。

运行缓冲是工具和托盘。

并发请求越多，工作台上半成品越多。

工作台不是刚好能放下机器就够了。

还要留出操作空间。

一个更靠谱的估算方式是：

总显存 ≈ 模型权重 + KV Cache + 运行缓冲 + 并发余量

这只是直觉公式，不是精确计算。

但它能帮助避免一个危险判断：

模型能加载成功 = 服务一定稳定

加载成功，只说明第一关过了。

真正服务时，还要看上下文、并发、输出长度和峰值流量。

---

10. 小模型部署时，真正要取舍什么

小模型的价值，不只是“便宜”。

更重要的是它可能更容易控制。

模型小，通常意味着：

• 权重更小
• 延迟更低
• 部署门槛更低
• 私有化更容易
• 单次推理成本更可控

但模型小也意味着：

• 通用能力可能弱
• 复杂推理可能不稳
• 长上下文能力可能有限
• 对 prompt 和数据质量更敏感
• 需要更清楚的任务边界

所以小模型部署不是把大模型缩小就完事。

它更像选择一把合适的工具。

螺丝刀很好用，但不要拿它砍树。

小模型适合做边界清晰、流程明确、评估可控的任务。

比如：

• 分类
• 摘要
• 固定格式抽取
• 语气改写
• 客服意图识别
• 文档片段问答
• 简单工具调用前的参数整理
• 低风险场景的辅助生成

如果任务本身需要很强的世界知识、复杂推理、长期规划，或者高风险判断，小模型就应该被放在系统的一部分，而不是单独承担全部责任。

更成熟的做法往往是组合：

小模型 + RAG + 规则 + 工具 + 人工兜底 + 评估

这不是降低格局。

这是把系统做稳。

---

11. “能跑起来”和“能稳定服务用户”的差别

一个模型能在本地跑起来，通常只证明：

当前机器
当前配置
当前输入
当前时间
可以完成一次推理

但服务用户要面对更多不确定性：

本地跑通	稳定服务
一个人试	多人同时用
输入可控	输入不可控
出错可以重启	出错要自动恢复
等一会儿也行	用户会离开
只看答案	还要看日志、成本、风险
只跑一次	长期运行

所以部署系统至少要考虑几类保护：

1. 请求限流：防止接口被刷爆
2. 输入长度限制：防止超长 prompt 拖垮系统
3. 输出长度限制：防止无限生成
4. 超时控制：防止请求卡死
5. 队列管理：防止并发把显存挤爆
6. 错误兜底：失败时给出可理解反馈
7. 日志监控：知道系统为什么慢、为什么错
8. 版本回滚：新模型不稳时能退回去

这些东西看起来不如模型参数酷。

但它们决定系统能不能长期活着。

真正上线以后，很多问题不是“模型不会”。

而是：

系统没有限制输入
没有控制并发
没有记录失败
没有降级方案
没有回滚路径

模型能力只是一部分。

服务能力才是产品能力。

---

12. 流式输出为什么重要

很多 AI 产品会让答案一段一段出现。

这叫流式输出。

它不一定让模型总生成时间变短。

但它会让用户更早看到反馈。

如果不用流式输出，用户可能要等完整答案生成完，页面才突然出现一大段文字。

如果答案很长，中间等待会很难受。

流式输出的价值是：

让等待变得可感知
让用户知道系统还活着

这有点像餐厅开放式厨房。

菜还没端上来，但能看到后厨在动，焦虑会少很多。

不过流式输出也有代价。

它需要更细的连接管理。

如果中途失败，页面要能处理半截答案。

如果涉及安全检查，系统还要决定是边生成边检查，还是生成后再统一检查。

所以流式输出不是只改一个前端效果。

它会影响后端、网关、日志、安全和用户体验。

---

13. Prompt 长度也是成本

很多人在做模型应用时，会习惯性把更多内容塞进 prompt。

比如：

• 更长的系统提示词
• 更多示例
• 更多知识片段
• 更完整的历史对话
• 更复杂的格式要求

这些东西有时确实有用。

但每一段都会变成 token。

每一个 token 都要参与计算。

所以 prompt 不是免费的说明书。

它是每次请求都要带上的行李。

行李越多，车越重。

如果系统提示词很长，哪怕用户只问一句短问题，每次请求也都要背着那段长提示词出门。

如果历史对话无限保留，用户聊得越久，系统越慢。

如果 RAG 每次召回十几段文档，模型可能被资料淹没。

更好的做法是控制上下文：

1. 系统提示词保持清晰，不堆口号
2. 示例只保留真正稳定任务需要的
3. 历史对话做摘要或截断
4. RAG 只放高相关、高质量片段
5. 输出格式用校验和后处理兜底

不是 prompt 越长越专业。

真正专业的 prompt，应该像精简过的指挥台：

少而准
能执行
可维护
可评估

---

14. 部署架构可以先从小闭环开始

小团队或个人项目，不一定一开始就上复杂平台。

但一定要有闭环意识。

一个最小可控的模型服务，可以先长这样：

flowchart TB
  A["前端 / 调用方"] --> B["API 网关"]
  B --> C["鉴权与限流"]
  C --> D["任务队列"]
  D --> E["推理服务"]
  E --> F["模型与适配器"]
  E --> G["日志与指标"]
  G --> H["问题分析 / 评估集更新"]
  H --> D

这张图的重点不是组件多。

重点是每个环节都回答一个问题：

环节	解决什么
API 网关	谁能访问、从哪里访问
鉴权与限流	防刷、防误用、防流量尖峰
任务队列	请求多时先排队，不直接压垮模型
推理服务	真正加载模型并生成答案
日志与指标	记录慢、错、失败和成本
评估集更新	把真实问题变成下一轮改进材料

个人项目也可以很朴素。

但不要把模型接口裸露在外面。

不要让任意人无限调用。

不要把错误埋在日志都没有的地方。

安全和稳定性不是大公司才需要。

小站点、小服务、小模型同样需要。

尤其是算力和带宽有限时，更要让系统会保护自己。

---

15. 什么时候应该上 GPU，什么时候不急

很多人会默认：

部署模型 = 必须买 GPU 服务器

不一定。

要看任务。

如果只是低频、离线、实验性质，CPU 或本地偶尔跑可能够用。

如果是个人学习，先把流程跑通比追求性能更重要。

如果是实时聊天、多人访问、长上下文生成，GPU 才更可能变成必要条件。

如果只是做分类、路由、简单抽取，小模型甚至可以用更轻的方式部署。

更实际的判断表是：

场景	更重要的指标	倾向
学习实验	跑通链路	本地 / 低成本环境
离线批处理	总吞吐	可慢一点，重视成本
在线聊天	TTFT、流式、稳定性	更需要推理优化
客服辅助	准确率、延迟、兜底	小模型 + RAG + 规则
高并发服务	吞吐、队列、监控	专门推理服务
高风险决策	可控、审计、人工复核	不应只靠模型直接输出

不要为了“看起来专业”过早上复杂架构。

也不要因为本地能跑，就低估真实服务压力。

正确顺序通常是：

先明确任务
再估算流量
再测延迟和成本
再决定部署方式

---

16. 模型服务要看哪些指标

训练时看 loss。

推理上线后，要看另一组指标。

至少包括：

指标	说明
请求量	有多少人 / 系统在调用
成功率	请求是否正常完成
错误率	失败、超时、被拒绝的比例
TTFT	第一个 token 出来要多久
总延迟	完整回答要多久
tokens/s	生成速度
输入 token 数	prompt 和上下文是否过长
输出 token 数	回答是否过长、是否可控
队列长度	系统是否开始堵
显存占用	是否接近 OOM
p95 / p99 延迟	大多数用户之外的慢请求有多慢

平均值不够。

如果平均延迟 2 秒，但 p95 延迟 20 秒，说明有一部分用户体验很差。

真实系统里，尾部延迟非常重要。

因为用户通常记住的是最卡的那一次。

还要注意输入和输出 token。

如果某类请求特别慢，可能不是模型突然变笨，而是那类请求：

• prompt 太长
• RAG 片段太多
• 输出模板太复杂
• 用户输入异常
• 历史对话没有截断

没有指标，就只能靠感觉。

靠感觉调模型，很容易越调越乱。

---

17. 小模型上线前的检查清单

如果一个小模型准备上线，可以先过一遍这张清单。

不是所有项目都要做到很重。

但至少要知道哪些问题还没回答。

问题	为什么重要
单次请求最长允许多少 token	防止超长输入拖垮系统
输出最长允许多少 token	防止无限生成和成本失控
同时最多处理多少请求	防止并发 OOM
超时后怎么处理	防止用户一直等
模型失败时返回什么	防止产品体验断裂
是否记录输入输出摘要	便于定位问题，但要注意隐私
是否有评估集	防止改模型后不知道好坏
是否能回滚旧版本	新版本不稳时保命
是否限制外部访问	防刷、防滥用
是否有成本上限	防止流量异常烧钱

这张清单看起来像运维。

但它其实是产品体验的一部分。

用户不会说：

你的 KV Cache 策略不好。

用户只会说：

太慢了。
怎么失败了。
刚才还可以，现在不行了。

工程指标最后都会变成用户感受。

---

18. 一个更完整的判断流程

把前面的内容合起来，可以得到一个部署判断流程：

flowchart TD
  A["任务是否清晰"] -->|"不清晰"| B["先定义任务和评估标准"]
  A -->|"清晰"| C["估算输入 / 输出 token"]
  C --> D["判断实时性要求"]
  D -->|"不实时"| E["离线批处理 / 低成本方案"]
  D -->|"实时"| F["测试 TTFT 和总延迟"]
  F --> G["估算并发和队列"]
  G --> H["计算显存账本"]
  H --> I{"成本和稳定性可接受吗"}
  I -->|"可以"| J["小范围灰度"]
  I -->|"不可以"| K["缩短上下文 / 量化 / 换模型 / 限流"]
  J --> L["监控真实指标"]
  L --> M["更新评估集和部署策略"]

这条链路里的核心不是“选哪个模型最强”。

而是：

任务、成本、体验、稳定性是否能闭合。

模型能力如果无法稳定交付，就还不是产品能力。

模型能力如果成本不可控，也很难长期运营。

模型能力如果没有监控和评估，后续改进就会失去方向。

---

19. 常见误区

误区一：模型越大，部署效果越好

大模型通常能力更强。

但部署效果不只看能力。

还要看延迟、成本、稳定性、任务边界和用户场景。

一个小而稳定的模型，在明确任务里可能比大而慢的模型更适合产品。

---

误区二：量化只是无损压缩

量化不是普通压缩包。

它可能影响模型表现。

不同任务、不同模型、不同量化方式，效果都可能不同。

所以量化后要重新评估。

不能只看能不能加载。

---

误区三：上下文越长，系统越聪明

长上下文提供更多信息。

但更多信息也意味着更高成本、更大干扰、更慢响应。

真正重要的是把相关信息放进去。

不是把所有信息放进去。

---

误区四：本地能跑，就可以上线

本地跑通是第一步。

上线还要看并发、限流、超时、日志、监控、回滚和安全。

模型服务不是一次命令。

它是一套长期运行系统。

---

误区五：只要接入流式输出，体验就好了

流式输出能缓解等待感。

但如果首 token 很慢、生成速度不稳、经常中断，体验仍然不好。

流式输出是体验层优化，不是系统稳定性的替代品。

---

20. 这篇的核心结论

1. 训练解决模型如何获得能力，推理解决能力如何被使用
2. 推理成本不只来自模型权重，还来自上下文、输出、KV Cache、并发和系统开销
3. 延迟、吞吐、并发不是一个指标，部署时需要平衡
4. TTFT 决定用户最先感受到的等待
5. Prefill 处理输入，Decode 逐 token 生成，长输入和长输出都会变贵
6. KV Cache 用显存换速度，长对话和高并发都会放大它的成本
7. 量化主要节省权重显存和带宽，但不等于无损变聪明
8. 小模型适合边界清晰、流程明确、评估可控的任务
9. 能本地跑通，不等于能稳定服务用户
10. 真正上线需要限流、队列、超时、监控、评估和回滚

这一篇可以用一句话收束：

模型能力只有稳定、可控、可负担地跑起来，
才真正进入产品世界。

前面几篇讲的是模型怎么学、学什么、怎么评估、知识放在哪里。

这一篇补上了最后一块：

能力如何被交付。

很多 AI 项目不是死在模型不会。

而是死在模型无法稳定、便宜、可控地服务真实场景。

把部署想清楚，才算真正开始接近工程。

---

下一篇预告

《工具调用与 Agent：模型如何从会说话变成会做事？》

模型稳定跑起来以后，下一个问题会变得自然：

如果模型不只是回答文字，而是要查询数据库、调用接口、整理文件、触发工作流，它应该怎么做？

下一篇会拆开这些问题：

• 工具调用为什么不是简单“让模型执行代码”
• Function Calling 解决了什么
• Agent 为什么容易失控
• 工具参数为什么需要校验
• 什么时候应该让模型决定，什么时候应该让规则决定
• 为什么真正可用的 Agent，一定需要权限、日志、回滚和人工确认

核心观点是：模型从会说话到会做事，中间隔着一整套可控行动系统。

---

后续章节路线

这个系列会在第 14 篇完成第一轮收束，不无限拉长，也不突然停在某个技术点上。

顺序	章节方向	要解决的问题
第 11 篇	工具调用与 Agent：模型如何从会说话变成会做事？	Function Calling、工具参数、权限边界、日志与人工确认
第 12 篇	Memory 与工作流：模型如何承接长期任务？	对话记忆、任务状态、上下文压缩、恢复现场与流程编排
第 13 篇	行业模型与业务闭环：训练如何进入真实场景？	领域数据、流程反馈、人工审核、持续评估与灰度改进
第 14 篇	系列总结：从数据到 Agent 的小模型工程地图	把训练、微调、评估、RAG、部署和 Agent 串成完整路线

持续学习，持续记录，持续筛选

如果这篇对你有用，可以继续沿着主题读下去。

福星家和会长期记录 AI 技术、生活成长、真实好物与正向文化观察。产品体验、人物故事、教育内容、生活方式、文化作品和内容共创都欢迎邮件沟通，合作内容会清楚标注。

继续读本系列 合作与交流