往下问：历史信息从哪来#

decode 每一步都要和历史所有位置做注意力。这段历史只有两个来源：每步重算一遍，或者第一次算完存起来。

TIP

先自己推十秒：重算的代价是什么 序列长 n，第 k 步要算 k 个位置，全程加起来是 n²/2。 生成 1000 个字的计算量是生成 100 个字的 100 倍，不是 10 倍。

所以 KV Cache 不是什么优化技巧，是被 O(n²) 逼出来的唯一出路。它就是”把每一步算出来的 K、V 存下来，下一步直接翻”。

代价是显存。每 token 成本 = 全注意力层数 × 2（K 和 V）× head 数 × head_dim × 2 字节（FP16）。Qwen3.5-9B 拿这个公式算出来跟实测的 32.3KB 对得上。

往下问：这十几个 GB 怎么分#

一开始的做法很朴素：请求来了就划一整块连续显存。问题是请求长短不一，跑完释放之后留下大小不等的空洞，卡上明明还剩 8GB，却因为不连续而分不出一个 2GB 的请求。

vLLM 的解法借了操作系统虚拟内存的思路，也就是 PagedAttention：把池子切成固定大小的块，请求看到的逻辑块通过块表映射到物理块，物理上可以不连续。

1
flowchart LR
2
    subgraph L["逻辑序列（请求看到的，连续）"]
3
        direction TB
4
        A1["块 A"] --> A2["块 B"] --> A3["块 C"]
5
    end
6
    T["块表<br/>A → 页 3<br/>B → 页 7<br/>C → 页 11"]
7
    subgraph P["物理 KV 池（实际位置，可以分散）"]
8
        direction TB
9
        P3["页 3 · 本请求"] --- PX["页 4-6 · 他请求"] --- P7["页 7 · 本请求"] --- PY["空闲页"] --- P11["页 11 · 本请求"]
10
    end
11
    L --> T --> P

三个名词新手最容易混，摆在一起看：

这么切顺带白捡两个好处。碎片没了，块可以东拼西凑。更重要的是多个请求能指向同一批物理块，相同前缀只存一份只算一次，这就是 prefix cache。

也有个限制：块只能整块复用，末尾不满一块的部分每次都得重算。30 个 token 的短 prompt 连半块都凑不满，prefix cache 对它完全无效。我第一次测的时候拿一句短话去试，看到缓存命中率是 0 还以为坏了，其实是块粒度的问题。

往下问：能不能少走几步#

一步出 100 个字就得走 100 步。既然每步的耗时压不下去，那就减少步数。

MTP 的思路是：模型自带一个又小又快的草稿头，先猜接下来 2 个 token，交回主模型验证。

1
flowchart TD
2
    A["草稿头快速猜 d1、d2<br/>各自带概率 p_draft"] --> B["主模型一次前向<br/>把 [上一步, d1, d2] 当 3 个位置一起算"]
3
    B --> C["逐位置比对<br/>接受概率 = min(1, p_target / p_draft)"]
4
    C --> D["接受连续前缀<br/>被拒处重采样，被拒之后的全部作废"]
5
    D --> E["末位白送 1 个 bonus token<br/>本机平均 2.39 个，上限 3"]

TIP

检验一下：验证 3 个位置，耗时大约是算 1 个的几倍 提示：想想 prefill 为什么能并行，验证这一步走的更像 prefill 还是 decode。 答案：接近 1 倍，不是 3 倍。验证的时候三个位置都是已知 token，不存在”等下一个字”这回事，所以走的是 prefill 那条路，能一次算完。用并行换串行，MTP 的收益全在这一句里。

判定接不接受，分两种情况。温度设 0（贪心）时，草稿 token 等于主模型 argmax 就接受。温度大于 0（采样）时用拒绝采样，接受概率是 min(1, p_target / p_draft)，被拒就从 (p_target − p_draft) 归一化后的分布重新采一个——这么设计是为了让最终输出分布跟直接用主模型采样在数学上等价，质量不打折。

另外只接受连续的前缀：第 i 个位置被拒，i 之后的全作废，因为它们都是基于被拒那个 token 才猜出来的。还有个白送的 bonus token：草稿全中时末位也算出了 logits，顺手再采样一个。所以 K=2 时上限是 3 个，本机实测平均 2.39，很接近天花板。

代价是验证工作区要吃显存，KV 池从 188,847 掉到 73,728，缩了六成。所以 MTP 和超长上下文天生打架，想要 262K 就别惦记 MTP。

开之前先确认两件事：模型 config 里有没有 mtp_num_hidden_layers，权重里草稿头在不在（社区量化经常直接砍掉）。

往下问：怎么少搬一点#

量化。权重从 16bit 压到 4bit，体积除以 4，每步要搬的数据也跟着除以 4。所以量化不只是省显存，它直接提速——这就是它成为单卡部署第一前提的原因。

AWQ 的思路是按激活值的重要性保护敏感权重，GPTQ 走误差重建（AutoRound 导出的就是 GPTQ 格式，加载时走 gptq_marlin 内核）。

往下问：除了搬数据，还有什么别的事#

有，调度。每步 CPU 都要安排一遍 GPU 内核怎么跑。序列短的时候，安排的时间甚至比算的时间还长。

CUDA Graph 的办法是把这套安排录一次，之后整图回放，省掉重复调度。本机 batch=1 下实测 +12.5%（41 → 46.1 tok/s）。代价是启动时捕获图要编译（这次 19.7 秒），图本身占 0.04 GiB。另外 v0.21 之后默认开了显存 profiling，标 0.80 实际等效无图时的 0.7979。

TIP

检验：并发从 1 提到 10，decode 每步耗时会变成几倍 提示：每步的瓶颈是搬权重，而这 10 个请求共用同一份权重。 答案：接近 1 倍。多出来的只有注意力和采样那点增量。所以并发是摊薄单步成本最有效的手段，这也是为什么服务端推理和本地一个用户玩，体感能差出一个数量级。

顺带说一句，本机所有测试都是 MAX_NUM_SEQS=1，调度器基本没存在感。把单轮 token 上限从 1024 加到 2048，速度纹丝不动，KV 池还少了 586 个 token。并发那部分我还没测，留着下次。