大模型推理优化：从“不算”到“破串行”的技术矩阵

面对大模型推理优化的各类技术，与其死记FlashAttention、量化、PagedAttention这些名词，不如先拆解一条请求的核心瓶颈所在。在H100显卡上运行batch=1的解码任务时，GPU算力利用率甚至不到1%。这并非配置错误：这款显卡每从显存搬运1字节数据，需要完成约300次浮点运算才能充分利用算力；而单条解码请求每搬运1字节，仅会执行约1次运算。绝大多数推理优化技术，都是在解决这个300:1的资源失衡问题，只是它们被包裹在令人眼花缭乱的技术名词背后。

FlashAttention、PagedAttention、Radix Cache、FP8、AWQ、MLA、continuous batching、CUDA Graph、投机解码……每个名字背后都对应一篇学术论文或一套工程实现。逐个学习这些技术后，很多人依然没有全局认知，因为这些技术看起来彼此独立。事实上，所有推理优化的核心目标只有两个：

• 降低单条请求的延迟，让用户更快得到生成结果；
• 提升单位硬件的吞吐能力，让系统在相同时间内生成更多token。

这两个目标往往存在冲突：合并更多请求到一批中计算可以提升总吞吐，但单条请求的等待时间会变长；投机解码可以降低单条延迟，但当系统满负载时，额外的草稿计算会抢夺正常请求的资源。因此，判断一项优化技术的价值，不能只看“能加速多少”，还要明确它解决了哪个瓶颈、消耗了哪些资源、在何种负载场景下最为划算。下面我们将用一套清晰的框架，将这些技术归类到它们真正解决的问题中。

一、用后厨场景类比GPU推理的四大约束

推理系统的瓶颈，和一家餐厅后厨能否高效运转是同一类问题：

炉灶和食材通道决定了每一轮操作的速度，操作台空间决定了可同时处理的订单数量，出菜顺序则决定了最少需要执行的操作轮数。我们将逐个分析这四个约束条件。

1.1 算力与带宽的失衡：解码阶段GPU为何利用率低下

GPU执行计算任务的耗时，由计算和数据搬运中更慢的那个环节决定：

计算时间 = 要做的计算量 ÷ 算力
搬运时间 = 要搬的数据量 ÷ 显存带宽
单步时间 ≈ max(计算时间, 搬运时间)

如果计算耗时更长，任务属于算力受限；如果数据搬运耗时更长，则属于带宽受限。硬件领域用屋顶线模型（Roofline Model）来描述这两种情况。

H100的BF16算力约1000 TFLOPS，显存带宽约3.35 TB/s，两者相除得到约300 FLOPs/字节的分界点：平均每搬运1字节数据，需要完成约300次浮点运算才能让算力充分利用。而batch=1的解码任务非常接近矩阵乘向量操作：每生成一个token都需要读取大量权重，但每个权重仅参与少量计算，平均每字节仅约1次运算。1比300的比例意味着，此时GPU不是不会计算，而是权重数据还在从显存搬运的路上，计算单元只能空等。

国内常见的H20显卡则不同：算力约148 TFLOPS，带宽却有4 TB/s，分界点仅约37。这类显卡算力较弱但带宽更强，天生更适合运行解码任务。同一套优化技术在不同显卡上的收益差异，根源就在于这个分界点的不同。

推理任务分为两个阶段，各自的瓶颈完全不同：

还有一个贯穿全文的核心杠杆：batch大小。将N条解码请求合并计算，权重仅需要读取一次却可以服务N个token，搬运成本被摊薄N倍。这几乎是所有吞吐优化的底层原理，但batch的最大规模受限于显存容量。

1.2 显存容量：不直接决定速度，但决定并发上限

显存中主要存储两类数据：加载后基本固定的模型权重，以及随请求并发数和上下文长度增长的KV Cache——保存历史token在注意力层的中间状态。

以Qwen3-32B模型为例，每个token的KV缓存大小为：

2(K和V)× 64层 × 8个KV头 × 128维 × 2字节 ≈ 256 KB/token

一条128K上下文的请求，仅KV缓存就需要约32GB空间。如果不使用GQA分组查询，64个头各自存储KV数据，每个token的KV缓存将达到2MB，是原来的8倍。

显存容量的微妙之处在于：它本身不直接缩短单次计算的时间，但通过两条路径提升整体性能：

• 可以承载更多并发请求，让batch更大，从而提升吞吐能力；
• 可以存储更多历史前缀，提升缓存命中率，让更多请求跳过重复的Prefill阶段。

因此显存就像后厨的操作台和冰箱：它不负责炒菜，但空间不足时，厨师无法同时开工，也无法存放备好的食材。带宽的优化影响每一轮的耗时，而容量的优化影响可同时处理的任务数量——这是两种不同的资源，很多文章将它们笼统归为“显存优化”，反而会混淆优化逻辑。

1.3 串行依赖：自回归生成的必然约束

生成第N个token必须先有第N-1个token，这是自回归大模型的核心定义。要生成100个token，就需要按顺序执行100轮计算。此前的计算优化、搬运优化都只能缩短单轮的耗时，无法减少串行执行的总轮数。只有投机解码、多token预测这类技术，才能直接攻击串行轮数这个瓶颈。

将四个约束结合起来，就得到了推理延迟的核心计算公式：

总时间 ≈ 串行轮数 × 每轮时间  // 由出菜顺序决定
每轮时间 ≈ max(计算量 ÷ 有效算力, 搬运量 ÷ 有效带宽)  // 由算力和带宽决定
有效算力/有效带宽 = 硬件峰值 × 硬件利用率
约束条件：权重 + 所有并发请求的KV缓存 ≤ 显存容量  // 由显存容量决定

后续的各类优化技术，本质上都是在修改这几个核心变量。

二、六大优化动词：拆解所有推理技术

要缩短总推理时间，从上面的公式来看，只有四条不重复的优化路径，我们可以将其拆分为六个具体的优化动作：

严格来说还有第五条路径：提升硬件峰值，比如更换更好的显卡或增加显卡数量。多卡并行TP/PP/EP本质上属于这一范畴，后续会在“打满”部分详细说明。

四条优化杠杆可以拆分为六个核心动作，我们按照优化优先级从高到低排序：越靠前的优化成本越低，省掉的计算永远比优化现有计算更划算。

动词一：不算——复用已有计算结果

最便宜的计算，就是完全不执行重复计算。

KV Cache：在同一条请求内复用历史计算结果。如果不存储KV缓存，生成第t个token需要重新前向传播前t个token的全部计算，总计算量是O(n²)级别；存储KV缓存后，每轮仅需要计算最新的token，将复杂度降到O(n)。

仍有部分计算无法被完全省略：注意力打分阶段每轮仍需要读取全部历史KV数据，序列越长读取的数据量越大。因此KV Cache并没有消除历史计算，而是将“反复重算历史”转换为“保存并读取历史”——用显存容量和带宽，交换大幅减少的重复计算。这是整个领域的基础优化，但绝非免费：后续几乎所有KV缓存优化，都是在解决这个基础方案带来的新问题。

Radix / Prefix Cache：跨请求复用公共前缀。很多请求的开头部分是相同的，比如系统提示词、少样本示例、多轮对话历史。可以用基数树索引这些公共前缀，新请求命中后直接复用已计算好的KV数据，跳过对应的Prefill阶段。

HiCache：将缓存池扩展到CPU和硬盘。公共前缀缓存的命中率受限于缓存池大小，但GPU显存需要和运行中的请求争夺空间。HiCache采用分层缓存设计：GPU显存存储热门缓存，CPU内存存储温数据，SSD存储冷数据，命中时将数据从低速存储搬回GPU。

表面上HiCache增加了数据搬运，但实际收益显著：以Qwen3-32B为例，重算一段4K token的提示词需要约2.6×10¹⁴次浮点运算，在H100上需要百毫秒到数秒；而这段KV缓存仅约1GB，从CPU内存搬回显存仅需几十毫秒。两者相差一到两个数量级——用搬运成本换取免计算，这笔交易是划算的。当然前提是搬运速度足够快，如果被小块传输或PCIe总线争抢拖慢，这笔交易就会由盈利变为亏损。因此HiCache的关键指标不仅是命中率，还要关注缓存层级、搬运耗时和最终节省的重算成本。

熬好的高汤别倒掉，下一锅接着用；灶边放不下就放冷藏库——取回来多花一点功夫，还是比从头熬快得多。

动词二：少算——减少实际执行的计算量

对于无法避免的计算，能否让每次计算的成本更低？这一优化的适用条件是：只有当算力成为瓶颈时（比如Prefill阶段、大batch场景），减少计算量才能真正缩短耗时。如果系统已经在等待数据搬运，减少计算量只会让空闲时间更长。

• FP8 / W8A8 计算量化：将权重和激活使用低精度格式参与矩阵乘法，直接使用吞吐率更高的低精度计算单元。这类优化同时也能减少数据搬运和显存占用，但在Prefill和大batch场景下，核心收益是“相同时间内完成更多计算”。
• 稀疏注意力：不让每个token查看全部历史数据，仅关注局部窗口或筛选出的重要位置，将注意力计算的复杂度从O(n²)降低。GLM-5.2的IndexShare更进一步：多层稀疏注意力共用一份“该查看哪些token”的筛选结果，连筛选本身的重复计算也一并节省——这类设计直接面向1M长度上下文的优化需求。
• MoE：结构化稀疏模型——模型包含多个专家模块，每个token仅激活少数几个专家。比如Qwen3-30B-A3B总参数30B，但每个token仅计算约3B参数；DeepSeek-V3总参数671B，但每个token仅激活约37B参数。这类模型可以拥有巨大的总参数规模，但每个token的计算量无需等比例增长。

MoE模型也能澄清一个常见误区：计算量少不等于部署更简单。所有专家的权重都需要存储在显存中，虽然每个token的计算量减少，但显存占用反而更高；当专家分布在多张显卡上时，token需要跨卡传输；如果路由不均匀，热门专家所在的显卡会成为性能瓶颈。节省的计算量，会以显存占用、通信开销和负载均衡问题的形式部分返还。

简化配方：少放几味不影响味道的料，备料和翻炒都省——但料的种类还得备齐，占的还是冰箱。

动词三：少搬——减少每轮读写的数据量

这是解码阶段的核心优化战场。当带宽成为瓶颈时，最有效的优化就是降低每轮需要搬运的字节数。每轮解码需要搬运两类数据：模型权重，以及当前批次所有请求的KV缓存。

少搬权重——Weight-only量化（AWQ / GPTQ）：仅将权重压缩到4bit，在计算时再解压回高精度格式。解压过程会增加额外计算，但在解码受带宽限制的场景下，反而能提升整体速度。这个反直觉的结论非常重要：有时多做一点计算反而能让整体更快，因为此时的瓶颈是数据搬运而非计算。

顺带澄清量化的两类场景：W8A8量化主要节省计算量，而Weight-only量化主要节省数据搬运——虽然都被称为量化，但属于两种完全不同的优化交易，适用场景也不同。

少搬KV缓存：对KV缓存进行量化（将BF16压缩为FP8/INT8，每轮读取一半的数据量）；GQA/MLA则从结构上缩小KV缓存的体积，这部分的优化会放在下一个动词中说明。

少搬中间结果：

• FlashAttention：普通注意力机制会生成一个巨大的中间矩阵，写入显存后再读取回来。FlashAttention通过分块计算+边计算边归一化，让中间结果保留在GPU片上高速缓存中，无需写入显存。数学结果完全一致，但数据搬运路径缩短了一个量级。该优化对Prefill和长序列场景尤其重要，此时中间矩阵的规模足够大。
• 算子融合（torch.compile / TensorRT）：原本多个独立的小算子各自读写一次显存，融合为一个大算子后，数据仅需要进出一次显存，中间计算在芯片内完成。（Kernel指的是在GPU上执行的一段计算程序。）

别在冰箱和灶台之间来回跑：一次拿齐，一气呵成，半成品别端来端去。

动词四：少占——减少显存浪费和状态体积

显存容量本身不直接缩短耗时，但它是提升并发和缓存命中率的基础。这一维度的优化收益，都通过1.2节提到的两条路径变现。

PagedAttention：最容易被错误归类的技术——名字中带有Attention，常被误认为计算优化，但实际上它既不减少计算量，也不减少必要的数据搬运，仅解决显存浪费问题。早期系统会为每个请求按照最大上下文长度预留整块显存，短请求会留下大量内存空洞，实际显存利用率仅20%~40%；PagedAttention借鉴操作系统内存分页的思路，将KV缓存切分为固定大小的块按需分配，将显存浪费降低到4%以下。同样的显存容量，可以支持数倍的并发请求，再通过“打满”优化将并发优势转化为吞吐提升。

MQA → GQA → MLA：注意力结构对KV缓存体积的三代压缩。MQA让所有查询头共享一份KV缓存（最节省空间但可能影响效果）；GQA采用分组共享（比如Qwen3-32B的64个查询头共享8个KV头，压缩比8倍）；MLA（DeepSeek提出）将所有头的KV数据压缩为一个小的低维向量，对比未压缩的MHA可以节省约93%的KV体积。这类结构修改会带来双重收益：每轮读取KV的数据量更少（对应少搬优化），同时同样的显存可以承载更多请求（对应打满优化）。一处结构改动，多处受益——这也是新模型纷纷向这个方向优化的核心原因。

KV驱逐 / 滑动窗口：直接丢弃远处的KV缓存，以“无法查看完整历史”为代价换取显存空间，是这一维度中最激进的优化手段。

HiCache的容量优化侧面：将KV缓存下沉到低速存储的同时，也为GPU显存腾出了空间，同时服务于“不算”和“少占”两个优化方向。

小份装盒、真空压缩：冰箱还是那个冰箱，能备的桌数翻倍。

动词五：打满——减少硬件空转和等待

前四个动词决定了“需要计算多少、搬运多少、存储多少”；这一维度解决的是：执行这些任务时，硬件是否处于空闲状态。空转的来源有多种，对应的解决方案也不同：

• Batch存在空位 → Continuous Batching：静态批处理需要等待最慢的请求完成后才能释放资源，先结束的请求会白白占用计算位置。连续批处理根据token生成进度动态调整批次：哪个请求完成就立即释放位置，新请求立刻补入。让batch始终保持满负荷，权重每次读取都能被最大化摊薄。
• Prefill和Decode互相阻塞 → Chunked Prefill / PD分离：Prefill受算力瓶颈，Decode受带宽瓶颈，两者混合运行会互相拖累——突然插入的长Prefill会让所有Decode请求长时间等待。单机场景下的解决方案是将长提示词切块，与Decode穿插运行；集群场景下则可以完全拆分，Prefill和Decode使用独立的实例和硬件配置，代价是KV缓存需要在两个实例之间传输。
• 多卡互相等待 → TP / PP / EP的工程优化：需要明确的是，单卡无法承载模型或单卡算力不足，是采用多卡并行的原因，但这本质是增加硬件资源，而非打满优化。真正属于打满优化的是，添加多卡后让每张卡都保持忙碌：TP需要将卡间通信隐藏在计算中，PP需要减少流水线空泡，EP需要让专家负载均匀。如果没有做好这些优化，多卡并行后的利用率反而会大幅下降——“购买显卡”和“用好显卡”是两件事，打满优化管的是后者。
• GPU等待CPU派发任务 → CUDA Graph：GPU上的每段计算都需要CPU发送一条启动指令，一轮解码需要发送成百上千条指令；在小batch场景下，CPU发送指令的速度无法跟上GPU的计算速度，GPU反而会等待CPU。CUDA Graph将固定的计算序列录制一次，之后用一次“回放”替代上千次指令发送，代价是灵活性下降：输入形状固定，需要为不同的batch大小预录多份图。
• 等待下一批调度 → Overlap Scheduler（SGLang的核心特性）：在GPU计算当前批次的同时，CPU同步处理上一轮的结果、准备下一批的数据，将调度时间隐藏在GPU的执行时间中。它和CUDA Graph解决的是两种不同的等待问题：前者解决指令开销，后者解决调度开销。

空出一个灶眼马上补单（连续批处理）；红案白案分开排班（PD分离）；固定的菜不用每次口头交代整套步骤（CUDA Graph）；炒这一单时，下一单的料已经在切（Overlap Scheduler）。

动词六：破串行——减少总执行轮数

前五个动词都在优化“单轮执行的耗时”，只有这个动作直接攻击“总串行轮数”。用通俗的话来说：通过额外的计算，一次性验证多个token，减少大模型需要串行执行的轮数。

投机解码：先用低成本的“草稿模型”（比如小模型、或挂载在大模型上的EAGLE、MTP预测头）猜测后续的多个token，再让大模型一次性并行验证这些猜测。验证方法在数学上有保证，最终的输出分布和逐个生成完全一致。如果猜对k个token，就可以一次前进k步，典型加速比为2~4倍。

为什么投机解码可行？回到1.1节的结论：解码阶段受带宽限制，验证5个token和验证1个token，权重都只需要搬运一次，额外的计算仅使用原本空闲的算力。因此破串行和连续批处理实际上使用的是同一类资源：连续批处理用空闲算力服务更多请求，投机解码用空闲算力提升单条请求的生成速度。

但投机解码并非免费午餐：草稿模型需要占用显存和计算资源；如果猜测错误，验证过程的计算完全浪费；在高负载大batch场景下，空闲算力已经被连续批处理耗尽，投机解码反而会和正常请求抢夺资源，收益会下降甚至为负。因此它是低延迟场景的利器，却是高吞吐场景的鸡肋——真正决定收益的是接受率：如果草稿猜测的大部分token在第一个就被拒绝，那么所有额外计算都是浪费。

MTP（多token预测）：将“草稿预测”直接内置到模型训练中——训练时就加入预测未来多个token的头。DeepSeek-V3和GLM-5.2都内置了该能力，GLM-5.2还专门优化了平均接受长度。这是模型厂商在训练阶段就为推理提速预埋的优化点。

猜熟客下一道要点什么，提前备着；猜对了直接上，猜错了损失一份备料。生意越忙，越没有闲手玩预判。

三、一条请求的完整生命周期

将六大优化动作放回时间线，我们可以看到一条请求从到达至退场的完整流程：

到达 ─▶ ①前缀匹配 ─▶ ②排队进批 ─▶ ③Prefill ─▶ ④写缓存 ─▶ ⑤Decode循环 ─▶ ⑥退场
        不算        打满/少占      少算        少占     少搬/打满/破串行     │
                     ▲                                                         
                     └──────────────────────────────────────────────────────────┘
                     KV留作后续请求的公共前缀

• 到达 · 前缀匹配（不算）：首先查询基数树，如果命中历史公共前缀，则跳过对应的Prefill阶段；如果GPU显存中没有，但CPU/SSD分层缓存中有，则将数据搬回GPU继续处理。
• 排队 · 进批（打满 + 少占）：调度器将请求加入当前批次；长提示词会被切块并与Decode请求混合批处理；KV缓存按页分配，不留下内存碎片。在集群部署场景下，请求可能先被路由到专属的Prefill实例。
• Prefill（少算主场）：数千个token并行前向传播，此时算力是瓶颈——低精度计算、稀疏注意力、MoE的优化收益在此阶段兑现。
• 写缓存（少占）：新生成的KV缓存写入分页池；如果模型采用MLA/GQA结构，KV缓存天生体积更小，再结合KV量化可以进一步减半。
• Decode循环（少搬 + 打满 + 破串行）：每轮读取权重和KV缓存——量化技术减少数据搬运量，CUDA Graph消除指令开销，Overlap Scheduler消除调度间隙；支持草稿解码的系统可以一次性验证多个token。循环执行直到生成结束。
• 退场（回到不算）：请求的KV缓存不一定会被丢弃，可以留在缓存树中作为公共前缀，等待下一条请求命中后回到第①步。

四、优化的分层视角

时间线回答了“优化在何时发生”，另一个维度是“优化在哪一层发生”。推理系统从外到内可以分为四层，每层可优化的内容各不相同：

请求进来
     │
┌──▼──────────────────────────────────────────┐
│ ④ 服务与集群层:请求调度、多卡与实例协作  │
│   Continuous Batching / Chunked Prefill  │
│   PD分离 / TP·PP·EP / Overlap Scheduler │
├──────────────────────────────────────────┤
│ ③ 缓存与运行时层:状态复用、KV存储位置   │
│   KV Cache / Radix Cache / PagedAttention │
│   KV量化 / HiCache                     │
├──────────────────────────────────────────┤
│ ② 算子执行层:前向传播的计算与搬运方式  │
│   FP8·AWQ / FlashAttention / 算子融合 │
│   CUDA Graph                           │
├──────────────────────────────────────────┤
│ ① 模型结构层:天生的计算量与KV体积      │
│   GQA·MLA / MoE / 稀疏注意力 / MTP     │
└──────────────────────────────────────────┘
     │
GPU算力、显存、卡间互联

四层结构的依赖关系非常清晰：模型结构层决定了每个token天生需要的计算量和KV缓存体积；算子执行层决定了这些计算在硬件上的实际执行方式；缓存层管理运行时产生的状态数据；服务层负责组织请求、多卡和多实例的调度。

最关键的分界点在第①层和其他三层之间：模型结构层是在训练阶段就确定的。推理工程师拿到模型后，无法将MHA结构修改为MLA，也无法凭空添加MTP预测头——只能通过适配来兑现结构带来的优化收益：只有当Kernel、缓存布局、调度逻辑都支持时，结构优化的效果才能真正发挥；否则只能停留在论文数字中。（量化校准虽然发生在部署前的离线阶段，但不修改模型结构，归为推理侧优化。）

这个视角最实用的地方是理解新模型的发布逻辑。比如DeepSeek-V3选择MLA + MoE + MTP，并非三个孤立的技术点：MLA负责减少数据搬运和显存占用，MoE负责控制计算量，MTP负责减少串行轮数——模型厂商在训练阶段就预埋了三个优化方向的钩子。同样，GLM-5.2的稀疏注意力 + IndexShare + 改进MTP，也是围绕1M长度上下文场景的组合优化。反过来，推理框架的很多迭代（比如MLA专用Kernel、MTP投机调度），本质上都是在兑现模型厂商预埋的优化承诺。

五、技术与优化动词的对应矩阵

时间线和分层结构解决了“何时”和“何处”的问题，矩阵则用于快速查账。将每个技术单独归类到一个格子中很容易产生误导，真实情况是：优秀的优化技术往往一石多鸟，而且几乎都需要付出相应的代价。

● 主要收益 ○ 次要收益 ✗ 付出的代价

行序按主收益动词从“不算”到“破串行”排列（即正文出现顺序）。“决策层”一列同时包含训练和推理优化，这是有意设计的：同一个优化动词，往往同时存在训练阶段的结构实现和推理阶段的系统实现：比如破串行 = MTP（训练）+ 投机解码（推理），少搬少占 = MLA（训练）+ KV量化（推理）。

（多卡并行的“增加显卡数量”属于提升硬件峰值，不进入该矩阵；矩阵中记录的是多卡并行的工程优化部分，即让多张显卡不会互相等待。）

有三个格子特别值得关注：

• KV Cache本身就带有两个代价——整个领域的第一个基础优化，就已经是“用显存和带宽交换免计算”的交易。显存容量问题并非后来才出现，而是从地基阶段就存在。
• AWQ量化的代价出现在“少算”列——通过增加少量解压计算换取大幅的数据搬运减少，最终仍能提升整体速度，这是“解码瓶颈在搬运而非计算”的最直接实证。
• 投机解码一行带有三个代价和一个主要收益——这是收益最显著的技术，但代价也最多，因此对场景的要求也最高。

六、面对新技术的四个判断问题

今后再遇到新的技术名词，可以按照以下顺序进行分析：

1. 它针对的瓶颈是什么？ 算力、带宽、容量、空转，还是串行轮数？
2. 它节省的是什么？ 对应六大优化动词中的哪一个？
3. 它付出的代价是什么？ 没有免费的优化：HiCache用搬运成本换取免计算，投机解码用算力和显存换取更少的串行轮数，量化用精度换取性能，PD分离用卡间传输换取阶段分离，CUDA Graph用灵活性换取指令开销。如果找不到代价，大概率是我们还没有完全理解这项技术。
4. 它服务的目标和场景是什么？ 是降低延迟还是提升吞吐？batch大小、上下文长度、系统负载如何？投机解码在低负载场景是利器，在高负载场景却是鸡肋；Chunked Prefill和PD分离是同一问题在单机和集群场景下的两种解决方案。没有普适最优的技术，只有适配特定场景的最优解。

通过这四个问题，一项技术的价值和边界基本就可以清晰判断。

结语

大模型推理优化并非一张需要死记硬背的名词列表，而是一系列资源交换的权衡：

• 用显存交换重复计算——KV Cache；
• 用少量解压计算交换一半的权重搬运——Weight-only量化；
• 用更复杂的内存管理交换显存利用率——PagedAttention；
• 用卡间传输交换两个阶段的独立稳定运行——PD分离；
• 用草稿计算和显存交换更少的串行轮数——投机解码。

国内的大模型厂商已经给出了很好的实践注脚：Qwen3使用GQA和MoE控制KV缓存和激活计算量，DeepSeek-V3使用MLA + MoE + MTP同时优化数据搬运、计算量和串行轮数，GLM-5.2则将稀疏注意力、IndexShare和改进的MTP组合应用到1M长度上下文场景。

技术会不断翻新，但灶火、食材输送、存储空间、出菜顺序这四个约束永远不会改变——它们是由硬件物理特性和自回归数学逻辑共同决定的。先找到核心瓶颈，再算清资源交换的账，任何新的推理优化技术都可以被归入我们熟悉的框架中。

如果你最近也遇到了新的推理优化技术（包括学术论文、框架新特性、新模型的结构选择等），欢迎在评论区交流，一起用四个判断问题进行分析。也欢迎指出无法归入这六个动词的技术案例——这说明我们的框架还有补充的空间，也是我最想了解的内容。

参考资料

[1] Qwen3 官方介绍 · Qwen3-32B 配置: https://huggingface.co/Qwen/Qwen3-32B/blob/main/config.json

[2] DeepSeek-V3 技术报告: https://github.com/deepseek-ai/DeepSeek-V3

[3] GLM-5.2 模型说明: https://huggingface.co/zai-org/GLM-5.2

[4] SGLang 文档 · vLLM PagedAttention 论文: https://arxiv.org/abs/2309.06180

[5] Roofline 模型(Williams et al.， 2009): https://dl.acm.org/doi/10.1145/1498765.1498785