大模型推理框架选型：从调度到内核的原理剖析

一、原理概述：推理框架到底在解决什么问题

大模型推理框架，本质上是把“一次训练好的模型权重”转化为“可持续、可并发、可观测的在线生成服务”的系统软件。它要解决的核心问题可以归纳为一句话：在有限的计算资源与显存容量下，尽可能提高单位时间内被正确处理的 token 数量，同时把首 token 延迟和尾延迟控制在可接受范围。

围绕这个目标，推理框架需要在多个层级上做协同设计：请求接入与排队、批次组装与调度、显存与缓存管理、注意力计算内核、并行策略、量化与算子优化、以及监控与容错。理解这些层级各自的机制，是判断“某个框架为什么快”“某个框架为什么在某场景下反而慢”的前提。

本文不针对任何具体产品做评测，而是从通用原理出发，说明各类技术路线的设计取舍，帮助读者建立选型时的分析框架。

二、背景问题：为什么推理框架近两年才快速发展

在早期，模型规模相对可控，推理服务往往直接复用训练侧的张量框架，配合简单的请求队列即可上线。但随着模型参数量、上下文长度、并发请求量同时上升，三个矛盾变得突出：

1. 显存墙：权重本身已占据大量显存，而 KV Cache 随并发数与序列长度线性增长，显存成为第一约束；
2. 算力利用率低：单请求解码阶段每次只产生一个 token，矩阵运算规模小，GPU 计算单元大量空转；
3. 请求异质性：线上请求的输入长度、输出长度差异巨大，静态批处理会导致长请求拖住短请求，尾延迟不可控。

因此，现代推理框架的核心工作，就是围绕“显存如何分配、批次如何动态组装、注意力如何高效计算”这三件事不断迭代。这也是不同技术路线产生分歧的根源。

三、核心概念：理解选型前必须掌握的四个基础

1. 预填充与解码两阶段
预填充阶段一次性处理整段输入 prompt，计算量大但可高度并行，属于算力密集型；解码阶段逐 token 生成，每步只处理一个 token，属于访存密集型。两者的性能瓶颈完全不同，框架对它们的优化策略也往往分开设计。

2. KV Cache
自回归生成中，已生成 token 的 Key/Value 张量会被缓存复用，避免重复计算。KV Cache 的大小约为 2 × 层数 × 头数 × 头维度 × 序列长度 × 并发数 × 精度字节数，它是显存占用的主要变量，也是所有显存管理机制的焦点。

3. 连续批处理（Continuous Batching）
传统静态批处理要等一批请求全部结束才能释放资源；连续批处理以“迭代步”为粒度，每个解码步结束后立即把已完成的请求移出、把新到达的请求插入，使批次始终被填满，显著提升吞吐并降低排队延迟。

4. 分页式显存管理
借鉴操作系统虚拟内存思想，把 KV Cache 切分为固定大小的块，按需分配、非连续存放，通过块表映射逻辑序列与物理块。它能缓解显存碎片，并支撑前缀共享与请求抢占。

四、系统组成：推理框架的典型分层

一个完整的推理引擎通常可拆为如下层次：

层次	关键职责	典型机制
接入层	协议解析、鉴权、限流、路由	请求排队、优先级队列、超时控制
调度层	组批、抢占、资源分配	连续批处理、分页调度、公平调度
执行层	前向计算、并行切分	张量并行、流水并行、算子融合
内核层	注意力与矩阵运算加速	分页注意力内核、量化内核、融合算子
存储层	权重与缓存管理	显存池、块分配器、前缀缓存、卸载
观测层	指标采集与故障处理	时延分布、显存水位、重试与熔断

不同框架的差异，往往不在于“有没有这一层”，而在于各层之间耦合的紧密程度与调度策略的激进程度。例如，调度层与内核层是否联合设计，会直接决定分页机制能否真正落到注意力计算中而不产生额外拷贝开销。

五、工作流程：一次请求的完整链路

以一个在线生成请求为例，其状态变化大致如下：

1. 接入与排队：请求到达接入层，完成鉴权与限流判断，进入等待队列；调度器根据当前批次余量与显存水位决定是否接纳；
2. 预填充调度：调度器为请求分配初始 KV 块，将多个请求的 prompt 拼成一批送入预填充计算；
3. 进入解码循环：请求转为“运行态”，每个解码步由调度器决定哪些请求进入本步批次；
4. 块增长与映射：序列变长时，块分配器追加新块并更新块表；注意力内核依据块表做非连续读取；
5. 完成与回收：命中结束符或达到长度上限后，请求转为“完成态”，其 KV 块被释放回显存池；
6. 异常路径：超时、抢占或显存不足时，请求可能被换出（KV 卸载到主机内存）或重排，需要保证状态一致性。

这个流程里最关键的设计点是：调度决策与显存分配的耦合。若调度器在分配显存前就把请求纳入批次，一旦分配失败就必须回滚，带来复杂的状态处理；因此多数实现采用“先预留、后组批”或“按块预算准入”的策略。

六、关键机制深入剖析

6.1 调度机制：吞吐与延迟的权衡

连续批处理解决的是“批次填充率”问题，但填充率并非越高越好。批次越大，单步计算时间越长，短请求的尾延迟越大。因此调度策略通常引入最大批 token 数与最大并发序列数双重上限，并按“先来先服务 + 长度感知”做近似公平调度。

伪代码示意：

每一步:
  while 批次token预算未满 and 等待队列非空:
    取出队首请求
    if 显存块余量足够容纳其当前需要:
        加入本步批次, 扣减预算
    else:
        break  // 或触发抢占: 换出低优先级请求的KV
  执行本步前向计算
  移除已完成请求, 释放其KV块

取舍在于：抢占能提升整体吞吐，但换出再换入会产生拷贝开销；过于激进的抢占会让长请求反复被中断，尾延迟恶化。是否开启抢占、抢占阈值设为多少，是选型时必须结合业务延迟目标判断的参数。

6.2 显存管理：分页与共享

分页式管理的收益来自两点：一是消除因序列长度不一导致的碎片；二是允许不同请求共享相同前缀的物理块（前缀缓存），对多轮对话、系统提示词固定的场景收益明显。代价是注意力内核必须支持按块表寻址，非连续访存会略微降低访存效率，需要专门的内核实现来抵消。

6.3 注意力内核：为什么内核决定上限

解码阶段的注意力是访存密集型操作，其性能取决于 KV 读取是否高效、是否与分页布局匹配、是否做了融合。分页注意力内核把块表查询、掩码处理、softmax 与输出累加融合进单个内核，减少中间张量落盘；量化内核则通过低比特权重与激活降低访存压力。框架宣称的性能差异，很大一部分最终落在这一层。

6.4 并行策略：张量并行与流水并行

单卡放不下权重时，需引入并行。张量并行把单层矩阵切分到多卡，通信频繁但对延迟友好；流水并行按层切分，通信量小但存在流水气泡，适合吞吐优先场景。选型时要评估互联带宽：带宽不足时，张量并行的通信开销会吞噬收益。

6.5 稳定性机制

线上服务还需考虑：请求超时与取消、批次内单请求失败不影响整批、显存水位监控触发降级（如降低最大并发）、以及模型加载失败时的快速回滚。这些机制不直接提升峰值性能，但决定了系统能否长期稳定运行。

七、示例说明：两种典型路线的取舍

路线 A：调度与内核联合设计，强调分页与共享。 优点是显存利用率高、长上下文与高并发场景吞吐好；缺点是实现复杂，对新模型结构与新硬件的适配周期较长，调参门槛高。

路线 B：以静态或半静态批处理为主，强调简单与稳定。 优点是行为可预测、易于运维、适配成本低；缺点是在请求长度差异大的线上流量下，批次填充率低、尾延迟高。

两者没有绝对优劣，取决于流量形态：请求长度集中、并发稳定的场景，路线 B 的简单性可能是优势；请求高度异构、上下文长的场景，路线 A 的机制收益才显现。

八、技术优势与限制

上述机制带来的收益可归纳为：更高吞吐（连续批处理与分页共享）、更低尾延迟（动态调度与抢占）、更低单位成本（量化与内核融合）。但其边界同样明确：

• 分页与共享的收益依赖请求前缀的重复度，前缀差异大时收益有限；
• 量化会带来精度损失，需按任务做验证，长上下文任务对精度更敏感；
• 并行策略受互联带宽与拓扑约束，跨节点扩展的边际收益递减；
• 调度参数强依赖流量分布，离线压测结论不能直接搬到线上。

九、常见误区

1. 只看峰值吞吐：压测常用固定长度请求，与线上异构流量差异巨大，容易高估收益；
2. 认为批越大越好：批次增大会拉长单步时间，短请求尾延迟上升；
3. 忽视预热与冷启动：模型加载、内核编译、缓存预热都会影响首批请求时延；
4. 把框架当黑盒：不理解调度与显存机制，遇到 OOM 或延迟抖动时无法定位；
5. 忽略观测能力：没有细粒度时延与显存指标，选型结论无法在线上验证。

十、总结

大模型推理框架的选型，本质是对“调度策略、显存管理、注意力内核、并行方式”四组机制做匹配：先明确业务的延迟目标与流量形态，再判断哪组机制能真正作用在你的瓶颈上。框架本身仍在快速演进，今天的最优解可能随模型结构与硬件变化而改变，因此比“选哪个”更重要的是建立对底层机制的理解，从而在流量变化、模型升级时做出可解释的调整，并用观测数据持续验证。