同一个大模型，在不同产品里响应速度差很多——原因未必是模型不同，很可能是背后的推理框架不同。模型训练完只是拿到了权重，要让它同时服务几百个用户还不乱套，中间必须过一层专门的基础设施：推理框架。它管并发、批处理和显存三件事，每一件都直接对应成本。
单条推理和几百个并发之间差着什么
直接跑单条推理，一次只服务一个人，GPU 大部分时间在等待，利用率低得没法看。推理框架要解决的是三个现实问题，下面这张表是它们的通用做法和你能感知到的变化。
熟悉 Web 开发的人容易套用老经验：并发不够就加机器。大模型推理的并发瓶颈比这硬得多——每一路对话都要占一块显存放 KV 缓存，显存是固定资源，加请求只会先撞显存上限，而不是先撞 CPU。所以推理框架的调度要在「显存够不够、这一批塞不塞得下」的约束下做排队和拼批，和 Web 服务简单的负载均衡并不等同，这也是为什么不同框架的吞吐差异可以差出几倍。
| 要解决的问题 | 通用做法 | 使用者能感知的变化 |
|---|---|---|
| 并发调度 | 多请求排队，按优先级和长度分批安排 | 高峰期等待时间可控 |
| 批处理 | 把不同用户的请求凑成一批一起算 | 单卡吞吐上去，单位成本下来 |
| 显存管理 | 缓存和权重按需分配，减少闲置 | 同样的卡能接更长的对话 |
| 算子优化 | 与编译器配合，把每批算得更快 | 每秒输出 token 更稳定 |
KV 缓存与分页管理
KV 缓存值得单独讲。模型每生成一个字，都要回头「看」之前的上下文；为了避免重复计算，看过部分的中间结果会被缓存下来，这就是 KV 缓存。麻烦在于缓存长度不固定：一段 16K 的长对话和一句十个字的提问，缓存大小差几百倍。按最大长度预分配显存，大部分都浪费了。
显存账可以粗算一下：缓存随上下文长度线性增长，长对话、多轮问答累积下来的缓存很容易赶上甚至超过模型权重本身。这也是为什么实际产品里「支持 32K 上下文」和「同时服务多少人」是一对相互牵制的指标——窗口开大，每个请求占的显存就多，能同时接待的人就少。推理框架的优化，就是在两边找平衡。
推理框架用分页的思路解决：把缓存切成小块按需分配，用多少拿多少——像操作系统管理内存那样管理显存。这一招对并发能力的提升以量级计，是近年推理框架里标志性的技术。
成本账：这一层优化为什么值钱
算力的账按卡算。一张卡一天的成本固定，框架优化得好，同样的卡一天能服务更多人，摊到每个请求上的成本就下来了。对做 AI 产品的团队，这一层的优化直接对应毛利；对普通用户，它解释了为什么同一模型在不同产品里快慢不同，也解释了额度背后的调度策略。速度的感受单位是每秒输出多少 token，生成速度与 token这篇有具体展开。
衡量这一层做得好不好，有两个常被放在一起说的指标：首字延迟和吞吐。首字延迟决定用户按下发送后多久看到开头几个字，吞吐决定同样的卡一天能处理多少请求。调度和批处理做得好，两个指标可以同时改善；做得糙，就会出现「等半天才蹦出字来」或者「一上量就排队」的现象。
它与 AI 编译器的分工
推理框架和 AI 编译器经常被混为一谈，分工其实清楚。编译器管「一个模型在芯片上怎么跑得快」：算子融合、精度选择、面向具体芯片的代码生成；推理框架管「很多请求怎么排得开、资源怎么分」：调度、批处理、显存。两者配合——框架把请求排好队，编译器让每一批都算得高效。模型侧还有一道配合：权重经过量化瘦身之后，同样的显存能塞下更长上下文和更多并发，原理见什么是模型量化。
它做不到什么
推理框架解决的是跑得开，解决不了答得对。模型本身的能力边界——幻觉、知识过时、推理错误——框架一概管不了。它也改变不了参数规模决定的显存下限：7B 和 70B 的模型对硬件的要求差一个量级，参数量与资源的关系见什么是模型参数量。想自己部署开源权重模型的团队，选框架是绕不开的一步，基础概念见什么是开源权重模型。
推理框架速查
- 训练管「学会」，推理框架管「跑得开」
- 三件事：并发调度、批处理、显存管理
- 分页 KV 缓存像操作系统管内存
- 同一模型不同产品的速度差异，可能来自框架
- 框架管快慢，不管对错，能力边界仍是模型的事
