VLLM on Jiangwan's Blog

长上下文推理优化：Prefix Cache、调度与 MTP

Fri, 28 Aug 2026 14:00:00 +0800

📚 双 RTX 5060 Ti 部署 Qwen3.8 系列 · 6/6

💡 导读：

100K Context 能装下，不代表 100K Context 真正用起来就快。对长代码 Agent 来说，真正值得优先优化的是重复 Prefill、长 Prompt 对 Decode 的阻塞，以及多请求之间的 GPU 利用率；MTP 则属于更靠后的 Decode 优化。

前一篇最终把双 RTX 5060 Ti 的长上下文配置落在了：

2 × RTX 5060 Ti 16GB
Qwen3.8-27B NVFP4
TP2
FP8 KV
CUDA Graph ON
100K Context
Maximum Concurrency ≈ 1.07x

到这里，显存问题基本解决了。

但“能够容纳 100K Context”和“100K Context 真正用起来足够快”，其实是两个问题。

对于代码 Agent，一次请求经常包含：

System Prompt
Tool Definitions
项目规则
Repository Context
历史对话
Tool Result
当前用户输入

其中大量内容在连续几轮请求里几乎不会变化。

如果每一轮都重新 Prefill 几十 K、甚至接近 100K Token，那么即使 Decode 已经有 30 多 token/s，整体体验仍然可能很慢。

所以长 Context 解决容量以后，我真正开始关心的是另外三个问题：

重复内容能不能不重新计算？

超长 Prefill 会不会阻塞正在 Decode 的请求？

多个请求能不能更高效地共享 GPU？

它们分别对应：

Prefix Cache
Chunked Prefill
Continuous Batching

至于 MTP，它解决的是更后面的 Decode 串行问题。

这几个功能经常一起出现在“LLM 推理加速”列表里，但实际优化的是完全不同的阶段。

对于长代码 Agent，我现在的优先级非常明确：

Prefix Cache
↓
Chunked Prefill / Scheduler
↓
Continuous Batching
↓
最后才评估 MTP

1. Prefill 和 Decode 是两种完全不同的负载

一次 LLM 请求大致可以拆成：

Prompt
↓
Prefill
↓
第一个输出 Token
↓
Decode
↓
Decode
↓
...

Prefill 一次处理大量输入 Token。

如果 Prompt 是 100K，那么模型首先要把这 100K Token 处理一遍，建立 Attention KV、Linear Attention State 等运行状态。

这个阶段矩阵规模较大，通常更偏 Compute-heavy，也更容易把 Tensor Core 利用起来。

Decode 则不同。

每一步只新增一颗 Token，但它仍然要经过整个模型。

单流 Decode 更容易受到：

Weight Traffic
显存带宽
小 GEMM
Kernel Launch
TP Collective
Scheduler

影响。

所以：

Prefill 快，不代表 Decode 快；Decode 很快，也不能解决一个 100K Prompt 首次加载很慢的问题。

后面的优化，第一步就是先分清楚自己到底在优化哪一段。

2. Prefix Cache：先把重复 Prefill 消掉

假设第一次请求是：

内容	Token
System Prompt	5K
Tool Definitions	5K
Repository Context	80K
History	5K
User Prompt	5K
总计	100K

第一次没有办法，这 100K 基本都要经历 Prefill。

但 Agent 完成一次 Tool Call 后，第二轮请求很可能只是末尾发生变化：

System Prompt       5K   ← 不变
Tool Definitions    5K   ← 不变
Repository Context 80K   ← 大部分不变
History             8K
Tool Result          3K

如果没有 Prefix Cache，第二轮还是要从头处理整段 Prompt。

第三轮又重新来一次。

Prefix Cache 的思路是：

已经计算过、并且 Token Prefix 完全相同的部分，直接复用对应的 Cache Block / 状态。

例如：

100K Prompt

其中 90K Prefix 已命中
↓
真正重新 Prefill
≈ 10K

这带来的收益不是：

“把 100K Prefill 优化 20%。”

而更接近：

90K Token 这次根本不重新计算。

对于长 Context Agent，这通常比继续挤一点 Kernel 性能更有价值。

它改善的是 TTFT，不是 Decode TPS

假设当前单流 Decode 是：

≈ 33.5 token/s

打开 Prefix Cache 以后，即使命中了 90K Prefix，也不会因此让后面的 Decode 自动变成 60 token/s。

已经进入 Decode 阶段以后，每生成一颗 Token，该走的模型计算仍然要走。

Prefix Cache 节省的是进入 Decode 之前的重复 Prefill。

所以它最明显影响的是：

TTFT——Time To First Token。

测试 Prefix Cache 时，我更关心：

TTFT
Cached Tokens
实际重新 Prefill 的 Token 数
Prefix Cache Hit Rate

而不是只看 Decode token/s。

代码 Agent 天生适合 Prefix Cache，Prompt Layout 也会直接影响命中率

普通聊天历史会持续变化。

代码 Agent 则经常有一大段非常稳定的 Context：

System Prompt
Tool Schema
项目规则
AGENTS.md / CLAUDE.md 一类规则文件
Repository 文件
大量已经加载的代码
长时间不变的环境说明

真正经常变化的通常只是末尾：

当前 User Prompt
Tool Result
新生成的 Assistant 内容

这意味着代码 Agent 天然具有很高的 Prefix 重复率。

假设总 Prompt 是 100K，其中 80K～90K 能稳定命中，那么真正需要重新 Prefill 的可能只有最后一小段。

但 Prefix Cache 不是语义缓存。

两段 Prompt “意思一样”，不代表能够命中。它要求前面的 Token Prefix 真正一致。

例如：

当前时间：10:01
这里是 80K 项目代码……

下一轮变成：

当前时间：10:02
这里是同样的 80K 项目代码……

虽然后面的 Repository Context 完全没变，但 Prefix 在很靠前的位置已经不同。

因此我更倾向于让 Agent Prompt 按稳定程度排列：

最稳定
↓
System Prompt
↓
Tool Definitions
↓
固定规则
↓
Repository Context
↓
历史内容
↓
Tool Result
↓
当前 User Input
↓
最动态

而不是把当前时间、随机 ID、动态状态放在巨大固定 Context 的前面。

对于 100K 代码上下文：

Prompt Layout 已经不只是 Prompt Engineering，也属于 Serving Optimization。

一个小动态字段放错位置，可能直接让后面几十 K Token 的缓存价值消失。

不过对 Qwen3.8-27B 还要多加一个 Hybrid Model 的前提。

它不是纯 Full Attention，而是：

48 × Gated DeltaNet + 16 × Full Attention

因此 vLLM 做 Prefix Cache 时，不只是管理传统 Full-Attention KV Block，还要处理 Linear Attention 的 recurrent state / state checkpoint。

这意味着 Hybrid Model 的缓存命中粒度、State 保留位置和 Block 对齐，会比纯 Transformer 更复杂。

所以上面：

100K Prompt / 90K Prefix Hit

应该理解成一个便于建立直觉的例子，而不是“只要前 90K Token 相同，就一定能以任意粒度完整命中”。

真实部署里，我会直接看当前 vLLM 版本实际报告的：

Cached Tokens
Prefix Cache Hit Rate
TTFT

来判断 Hybrid Prefix Cache 到底复用了多少计算。

Prefix Cache 不是无限容量，多租户还要考虑隔离

Prefix Cache 最终仍然占用实际 Cache Pool。

假设当前同时存在：

Session A：80K Prefix
Session B：90K Prefix
Session C：70K Prefix
Session D：100K Prefix
...

消费级 GPU 不可能永久保留所有 Prefix。

当 Cache Pool 需要空间给新的请求时，旧 Block 最终会被淘汰和复用。

所以 Prefix Cache 的真实收益会受到：

Cache Capacity
活跃 Session 数量
Prefix 大小
请求是否集中在同一个项目
请求局部性

影响。

这也是为什么它特别适合我的这类 workload：

长时间围绕同一个 Repository 连续工作。

如果变成几百个用户，每个人都有完全不同的 100K Prefix，命中率自然会下降。

另外，如果是公网多租户 API，还要考虑 Cache 隔离和 Timing Side Channel。

vLLM 提供 cache_salt 一类机制，让不同租户可以控制 Prefix Cache 的共享边界。

个人 Coding Agent 不一定需要重点考虑这一点，但正式多租户服务不能完全忽略。

3. Chunked Prefill：Cache Miss 时别让长 Prompt 霸占 GPU

Prefix Cache 很强，但它解决不了第一次请求。

第一次打开一个大型 Repository：

100K New Prompt

没有旧 Prefix 可以复用，完整 Prefill 还是必须发生。

问题随之变成：

一个 100K Prefill 会不会长时间霸占 GPU？

假设：

Request A
已经进入 Decode，正在持续输出

Request B
突然进来一个 100K Prompt

如果 B 一次性把整个 Prefill 做完，再让 A 继续 Decode，那么 A 的 Inter-Token Latency 很可能突然升高。

用户看到的现象就是：本来流式输出很顺，突然卡了一段时间。

Chunked Prefill 会把一个很大的 Prefill 拆成多个 Chunk：

100K Prefill
↓
Chunk 1
Chunk 2
Chunk 3
Chunk 4
...

Scheduler 就有机会在这些 Chunk 之间继续安排其他 Decode 工作。

更接近：

Decode A
+
Prefill B 的一部分

↓

Decode A
+
Prefill B 的下一部分

而不是：

先让 B 完整 Prefill 100K
↓
A 一直等
↓
B 算完以后 A 再继续

vLLM V1 的调度思路本身就会优先照顾正在 Decode 的 Sequence，再把剩余 Token Budget 分给 Prefill；Prefill 太大时就拆 Chunk。

这对 Serving 很有价值，因为 Prefill 和 Decode 的资源特征并不完全相同：

Prefill
更偏大矩阵 / Compute-heavy

Decode
更偏 Weight Traffic / Memory-bound

把两种 workload 更合理地交错调度，有机会同时改善用户延迟和 GPU 利用率。

max_num_batched_tokens：本质上是 TTFT、ITL 和吞吐的交换

Chunked Prefill / Scheduler 有一个很重要的 Token Budget 概念：

max_num_batched_tokens

可以粗略理解成：

一次 Scheduler Iteration 最多允许处理多少 Token。

如果 Budget 较小，大型 Prefill 会被切成更多 Chunk。

优点是：

Decode 更容易持续插入
ITL 往往更友好
长 Prefill 不容易长时间阻塞其他请求

代价则是：

Prefill 被切得更碎
调度次数更多
单个大 Prompt 完成 Prefill 可能更慢

反过来，Budget 更大时，一轮可以吃下更多 Prefill Token，通常更有利于大 Prompt 吞吐和 TTFT，但也可能让其他 Decode 等得更久。

所以它不是“越大越好”，也不是“越小越低延迟就一定最好”。

它本质上是在三项指标之间做取舍：

TTFT
vs
ITL
vs
Aggregate Throughput

个人单用户 Agent 和高并发 API，最优值很可能不一样。

这类参数最终还是应该用真实 workload Benchmark，而不是只看一个离线吞吐数字。

4. Continuous Batching：把多个请求持续填进 GPU

假设同时有三个请求：

A：生成 100 Token
B：生成 500 Token
C：生成 50 Token

如果它们被绑定成一个传统静态 Batch，C 很快结束以后，它的位置可能空着；A 随后也结束，最后只剩 B 一直跑。

Batch 利用率会不断降低。

Continuous Batching 的思路是：

A B C

C 完成
↓
D 加入

A B D

A 完成
↓
E 加入

E B D

新的 Request 可以持续进入正在运行的 Batch，完成的 Request 及时退出。

它主要改善的是：

多请求 Aggregate Throughput 和 GPU 利用率。

所以和 Prefix Cache 一样，不能拿错指标。

打开 Continuous Batching 后，一条请求原来是 33.5 token/s，并不意味着它一定会突然变成 50、60 token/s。

真正应该看的，是多条请求同时存在时：

整张 GPU 每秒总共能够完成多少有效 Token，以及请求吞吐能不能持续保持。

Prefix Cache、Chunked Prefill 和 Continuous Batching 是一起工作的

真实 Agent Serving 很可能同时出现三种请求。

Request A

已有 90K Prefix Cache
只新增 5K

Request B

第一次进入系统
需要完整 Prefill 100K

Request C

已经完成 Prefill
正在 Decode

这时候三种机制刚好各自解决一个问题。

A：Prefix Cache

90K 不再重复计算。

B：Chunked Prefill

100K 不一次霸占整个调度周期。

C：Continuous Batching / Scheduler

继续参与 Decode，不需要等其他请求全部处理完。

所以我更喜欢把它们记成三句话：

Prefix Cache：重复的别再算。

Chunked Prefill：太长的别一次算完。

Continuous Batching：不同请求尽量一起算。

这三项放到一起，才真正体现出 Serving Runtime 和“单条请求模型推理程序”的区别。

5. MTP 用到 Speculative Decoding 里，才真正开始减少 Decode 串行性

前面的优化主要集中在：

Prefill
+
Scheduler
+
多请求利用率

MTP 则是另一条路线。

传统自回归 Decode：

Token N
↓
Forward
↓
Token N+1
↓
Forward
↓
Token N+2

一次 Target Forward 通常只让最终输出前进一颗 Token。

MTP 和 Speculative Decoding 其实不是同一个概念。

MTP 提供的是“预测后续多颗 Token”的能力；在推理阶段把 MTP Head 当成 Speculative Proposer，再由 Target Model 验证这些候选，才形成真正的 speculative decoding 路径：

MTP Proposal
↓
Target Verification
↓
接受若干 Token

如果一次能够稳定接受多颗 Token，就可能减少平均每颗最终 Token 所需要的串行 Decode Step。

所以它真正优化的是：

Decode 串行深度和 ITL。

但它不是一个：

ON = 固定 +30% TPS

的开关。

实际收益更接近：

节省的 Target Decode Step
-
Proposal 开销
-
Verification 开销
=
最终收益

最关键的运行指标包括：

Acceptance Rate
Mean Accepted Tokens / Step

而且 Serving 还要考虑：

Tool Calling
Structured Output
Sampling 配置
长 Context
Kernel / CUDA Graph 兼容性
当前模型与框架版本的稳定性

所以我没有把 MTP 放进这套部署的默认基础配置。

不是因为它理论上“用质量换速度”——标准 Speculative Decoding 本来就会让 Target Model 做验证。

而是因为它属于：

模型、Cache、TP、Kernel、CUDA Graph 和 Scheduler 都已经工作以后，再单独 A/B Benchmark 的高级优化。

对于我的长代码 Agent workload，前面几个问题的优先级明显更高。

尤其如果一次请求是：

Prompt：100K
Output：2K

MTP-based Speculative Decoding 能优化的是后面的 2K Decode。

如果下一轮有 90K 相同 Prefix，Prefix Cache 则可以直接让 90K 重复 Prefill 不再计算。

所以我的判断一直是：

先解决“不必要的计算”，再解决“剩下的计算怎么更快”。

6. 做到这一层以后，Benchmark 不能再只看 token/s

只记录：

token/s

已经明显不够了。

至少应该把性能拆成四类。

TTFT

Time To First Token

主要受：

Prefill
Prefix Cache
Scheduler

影响。

ITL

Inter-Token Latency

主要反映流式输出是否顺滑，会受到：

Decode
TP
Kernel
CUDA Graph
Scheduler
MTP

影响。

Aggregate Throughput

Total Output Tokens / Second

更适合观察：

Continuous Batching
Scheduler
并发
Batch 利用率

Prefix Cache Hit Rate / Cached Tokens

对长 Context Agent 来说，这甚至可能成为最值得长期记录的指标之一。

如果每轮都能稳定命中 80%、90% 甚至更高，那么系统真实成本和“每次完整 Prefill 100K”已经完全不是一回事。

7. 双 5060 Ti 的最终优化顺序

回到整个系列一直使用的这套部署：

2 × RTX 5060 Ti 16GB
Qwen3.8-27B NVFP4
TP2
FP8 KV
CUDA Graph ON
100K Context

前几篇已经分别解决了：

NVFP4
→ 让权重完整 GPU Resident

TP2
→ 聚合双卡计算与显存带宽

PCIe / P2P 分析
→ 判断 TP 的通信成本是否值得

Kernel / CUDA Graph
→ 降低模型执行开销

FP8 KV
→ 把 100K Context 放进显存

到了最后一层，我真正优先做的是：

Prefix Cache
→ 减少长代码重复 Prefill

Chunked Prefill
→ Cache Miss 时避免长 Prompt 阻塞 Decode

Continuous Batching
→ 多个 Agent / Session 共享 GPU 时提高总吞吐

MTP 则保留成可选项：

只有实际 A/B Benchmark 证明 Acceptance、稳定性和功能兼容性都足够好，才值得加入默认配置。

它不是这套部署架构成立的前提。

8. 结论

大模型推理不存在一个统一的“加速开关”。

不同优化对应不同阶段：

优化	主要解决的问题
Prefix Cache	避免重复 Prefill
Chunked Prefill	长 Prefill 不要一次阻塞整个调度
Continuous Batching	多请求持续填充 GPU
MTP-based Speculative Decoding	减少 Decode 串行 Step

对于长 Context 代码 Agent，我最终更认可这样的顺序：

先减少不必要的计算
↓
再改善 GPU 调度
↓
再提高多请求利用率
↓
最后再优化自回归 Decode

也就是：

Prefix Cache
>
Chunked Prefill / Scheduler
>
Continuous Batching
>
MTP

这个系列从最开始的问题：

“两张 5060 Ti 能不能跑 27B？”

一路走到了：

模型精度
↓
显存容量
↓
多卡并行
↓
跨卡通信
↓
Kernel / CUDA Graph
↓
长 Context Cache
↓
Prefix / Scheduler / Decode 优化

到最后，我觉得真正值得记住的已经不是某一个启动参数，而是一种部署思路：

在可接受的模型质量下，让有限的显存、显存带宽和计算能力尽可能花在真正需要重新计算的 Token 上。

这也是我这一周折腾双 RTX 5060 Ti + Qwen3.8-27B 以后，最终得到的最有价值的结论。

系列导航： ← 上一篇：200K Context 到底需要多少显存？从 KV Cache 算到 Qwen3.8 的真实部署

为什么生产推理我默认 vLLM：从 NVFP4、Kernel 到 CUDA Graph

Fri, 28 Aug 2026 10:00:00 +0800

📚 双 RTX 5060 Ti 部署 Qwen3.8 系列 · 4/6

💡 导读：

llama.cpp 和 vLLM 并不是简单的“谁更快”。前者把个人硬件能触碰到的模型规模往上推，后者则更适合在模型可以完整驻留 GPU 后继续追求 Serving 效率。这篇从 Qwen3.8-Flash-Next 的 CPU Offload 讲到 NVFP4、Kernel、Compile 和 CUDA Graph，也解释为什么我的 27B 生产部署默认从 vLLM 开始。

前面三篇已经解决了三个问题：

27B 怎么装进双 16GB
↓
两张 GPU 到底怎么并行
↓
TP2 为什么能加速、又为什么达不到理想 2×

到了真正部署服务时，我现在有一个比较明确的默认选择：

只要是 NVIDIA GPU、模型能够合理地完全驻留 GPU，并且目标是长期提供推理服务，我会优先从 vLLM 开始。

原因并不只是 PagedAttention，也不只是 KV Cache。

真正让我倾向 vLLM 的，是它把整个 GPU 推理执行链放在同一个系统里优化：

NVFP4 / FP8 等低精度格式
↓
Optimized GEMM / Attention Kernel
↓
torch.compile / Inductor
↓
CUDA Graph
↓
TP / PP
↓
Scheduler / Continuous Batching
↓
Cache / Prefix Cache

这些东西单独拿出来都只是一个优化点。

组合起来以后，才是一套真正面向 GPU Serving 的推理引擎。

不过在谈 vLLM 之前，先要把一个经常被混在一起的问题说清楚：

“模型能不能跑”和“这个模型适不适合做高性能 GPU Serving”，不是同一个问题。

Qwen3.8-Flash-Next 恰好是一个非常好的例子。

1. Qwen3.8-Flash-Next：CPU Offload 为什么依然有价值

写这组文章的时候，Qwen3.8-27B 才开放权重大约两周。

然后 2026 年 8 月 26 日，Qwen 又开放了 Qwen3.8-Flash-Next。

它的体量已经完全不是 27B 这一级别：

Language Model：125B 参数，约 6B activated
+
51B n-gram embedding
+
4B MTP

总体参数规模大约到了 180B 量级。

直接看权重文件更直观：

官方 BF16：约 360GB
官方 FP8：约 186GB
Unsloth UD-Q4_K_XL GGUF：约 111GB

这时“显存不够”已经不是双 16GB 能不能稍微规划一下的问题了。

甚至假设有：

8 × RTX 3090 24GB = 192GB VRAM

这种对个人用户已经非常夸张的配置，仅从总量上看，官方 FP8 的约 186GB 权重就已经快把聚合显存吃满了。

而真正运行模型显然还要给：

Runtime
Cache
Activation
Workspace
CUDA Graph
通信 Buffer

留下空间。

更不用说 8 张 3090 的拓扑、供电、散热和整机成本，本身就已经脱离绝大多数个人开发者的现实环境。

我当然也不会为了试一个刚发布的模型，先准备一台 8×3090 的机器。

这时候 llama.cpp 的另一种价值就非常明显了：

它可以把“GPU 显存不够”这个硬边界，扩展成“GPU VRAM + System RAM 能不能一起把模型跑起来”。

例如一个 100GB 级 GGUF，可以让一部分权重留在 GPU，一部分权重放在系统内存，通过 CPU + GPU 的混合路径运行。

原本的问题是：

模型 > 总 VRAM → 根本放不下

现在变成：

GPU VRAM
+
System RAM
→ 有机会真正运行起来

对于：

刚发布的超大模型
能力测试
本地研究
个人消费级硬件
显存容量不规则的机器

这种能力非常有价值。

所以我并不认同一种简单的判断：

“CPU Offload 很慢，所以没有意义。”

它当然有意义。

它改变的是：

“我能够接触和测试多大的模型”。

但另一方面，也不能把 RAM 当成“更便宜的显存”。

如果 Forward 需要频繁从系统内存取热点权重，那么整个性能模型就会受到：

CPU 内存带宽
+
CPU-GPU 数据路径
+
PCIe

限制。

GPU 本地 GDDR 能提供数百 GB/s 级带宽，而系统 RAM 与 CPU↔GPU 的 PCIe 路径在有效带宽、延迟和访问方式上都明显不同。

Offload 越重，Decode 越不可能维持纯 GPU Resident 模型的性能特征。

所以我现在更愿意这么定义它：

CPU / RAM Offload 很擅长扩大“能跑的模型范围”，但通常不是扩大“高性能生产 Serving 范围”的办法。

这也正好解释了 llama.cpp 和 vLLM 为什么不是简单的“谁替代谁”。

2. 对 27B 来说，我反而会优先追求 GPU Resident

Flash-Next 这种百 GB 级模型，RAM Offload 很合理。

但回到前面一直测试的 Qwen3.8-27B，情况完全不同。

它不是“无论如何都放不下”。

通过合适的量化，双 16GB 本来就有机会让权重完整驻留 GPU。

这时候我的优化顺序会变成：

选择质量可以接受的量化
↓
尽量让权重完整 GPU Resident
↓
给 Cache / Context 留空间
↓
选择 TP / PP
↓
再优化 Kernel、Compile、CUDA Graph 和调度

这也是为什么前面最终更倾向 NVFP4。

FP8 约 31GB：

32GB 总 VRAM
-
约 31GB 权重
≈
几乎没有运行余量

NVFP4 约 23GB：

32GB 总 VRAM
-
约 23GB 权重
≈
还有约 9GB 名义空间

第一篇主要解释的是 NVFP4 的容量价值。

但到了 vLLM 这一篇，NVFP4 还有另一半更重要的意义：

它不只是“存储格式”，还可以直接参与低精度计算。

3. NVFP4：容量只是第一层价值

如果一个 4bit 量化只解决存储，那么执行路径可能是：

4bit Weight
↓
读取 / 解码
↓
反量化到更高精度
↓
再执行通用 GEMM

这依然能节省：

权重显存
Weight Traffic

但真正更有意思的是硬件原生低精度路径：

NVFP4 Weight
+
低精度 Activation / Scale
↓
FP4 适配的 Tensor Core / MMA 路径
↓
NVFP4 GEMM

这时量化同时改变了两件事：

Memory Traffic ↓ + 低精度计算吞吐 ↑

NVIDIA 的 NVFP4 本身就是为 Blackwell 低精度计算设计的格式，而不是单纯“把 FP16 截成 4bit”。

所以：

NVFP4 在 Blackwell 上的价值，不能只用“省了多少 GB 显存”解释。

如果框架真的走到了合适的 FP4 Kernel，它还会改变 GEMM 本身的执行路径。

RTX 5060 Ti 属于 Blackwell，这件事对 NVFP4 很重要

RTX 5060 Ti 属于 Blackwell 消费级 GPU，CUDA Compute Capability 为 12.0，也就是常说的 SM120。

这意味着这张卡并不是“只能保存 NVFP4，然后全部转回旧精度算”。

在合适的软件栈下，它有对应的 Blackwell 低精度计算能力可以利用。

于是可以形成一条完整链路：

RTX 5060 Ti / SM120
↓
NVFP4 Checkpoint
↓
NVFP4-aware Kernel
↓
Blackwell 低精度 Tensor Core 路径

但这里有一个很重要的前提：

模型文件写着 NVFP4，不代表执行时一定走到了最优 NVFP4 Kernel。

这也是我开始真正关心 vLLM Kernel Dispatch 的原因。

“支持 NVFP4”和“NVFP4 跑得快”是两回事

假设两个框架都能成功加载：

Qwen3.8-27B NVFP4

这只能证明格式兼容。

真正执行时，可能存在完全不同的路径。

例如：

路径 A
NVFP4
↓
额外转换 / 反量化
↓
较通用的 GEMM

和：

路径 B
NVFP4
↓
专用 NVFP4 GEMM
↓
适合当前 Blackwell GPU 的 Kernel

模型格式一样，最终性能完全可能不同。

vLLM 当前的 NVFP4 执行路径会根据平台与可用组件选择对应 GEMM backend，例如 FlashInfer / CUTLASS 一类实现，并在不同硬件能力下选择合适的 fallback。

所以现在看量化模型，我会同时问两个问题：

这个框架能不能加载它？

以及：

加载以后，Linear 最终 Dispatch 到哪个 Kernel？

第二个问题对性能往往更重要。

4. 为什么 Kernel 对单流 Decode 特别重要？

一颗 token 的生成不是“一次巨大的 GPU 运算”。

更像是几十层不断重复：

Attention
↓
Linear
↓
Norm
↓
Linear
↓
Activation
↓
Linear
↓
下一层

前面 TP2 的单流实测大约是：

33.5 token/s

也就是一颗 token：

≈ 30ms

在这个时间尺度里，每层多一点：

量化转换
不合适的 GEMM Shape
Memory Access
Kernel Launch
同步

乘上几十层以后，就会变成很明显的最终差距。

所以现代 LLM 推理框架真正优化的不是某一个“神奇开关”。

而是：

大量重复的小执行路径能不能全部落到更合适的 Kernel 上。

这也是为什么“模型能加载”离“模型跑得好”还差很远。

5. CUDA Graph：Kernel 快了以后，还要减少 Launch

即使每个 CUDA Kernel 本身已经很快，单 token Decode 还有另一个问题。

普通执行更接近：

CPU → Launch Kernel A
CPU → Launch Kernel B
CPU → Launch Kernel C
CPU → Launch Kernel D
...

GPU 做完一个小任务，CPU 再继续提交后面的工作。

对于非常大的矩阵，这点 Launch Overhead 往往不突出。

但 Decode 每颗 token 都要重复大量小操作。

这时“启动 GPU 工作”本身也开始变得有成本。

CUDA Graph 的思路就是把一串 GPU 操作提前 Capture：

普通模式
CPU → A
CPU → B
CPU → C
CPU → D

变成：

CPU
↓
Replay Graph
↓
A → B → C → D

从而减少重复的 CPU 调度与 Kernel Launch 开销。

所以对单 token Decode 来说：

CUDA Graph 不是锦上添花的小功能，而是很自然的一层低延迟优化。

生产 Serving 的 CUDA Graph 不是简单的 ON / OFF

如果只是跑一个固定 Shape Benchmark，Capture 一张 Graph 很容易理解。

但真正 Serving 时，Batch 是动态的：

有时全是 Decode
有时有 Prefill
有时是 Prefill + Decode 混合
Batch Size 也一直变化

所以实际问题不是：

“支不支持 CUDA Graph？”

而是：

不同 Runtime Batch 到底应该走哪种 Graph 模式？

vLLM 当前把 CUDA Graph 分成多个运行模式，例如：

NONE
PIECEWISE
FULL
FULL_DECODE_ONLY
FULL_AND_PIECEWISE

其中在支持对应能力的 V1 配置里，纯 Decode 可以使用更完整的 Graph，而 Prefill / Mixed Batch 可以走 Piecewise 路径，再由 Runtime 根据当前 Batch 类型选择。

这件事对我来说很重要。

因为 CUDA Graph 已经不再只是：

Benchmark 时手动打开的优化开关

而开始变成：

Serving Runtime 自己的一部分执行策略。

CUDA Graph 上面还有 Compile / Inductor

再往上一层还有：

torch.compile / Inductor

vLLM V1 并不是简单把整个模型丢给一个默认 torch.compile(model) 就结束。

它会围绕自身 Serving 执行方式处理：

Graph capture / partition
Compilation cache
Shape specialization
Piecewise compilation
Inductor
自定义优化 pass

于是整个执行链可以粗略理解成：

Model
↓
Graph / Compile
↓
Inductor / Custom Pass
↓
Optimized Kernel
↓
CUDA Graph
↓
Runtime Replay

走到这一层以后，再把 vLLM 理解成“一个用了 PagedAttention 的 API Server”已经明显不够了。

它真正做的是：

把模型执行、Kernel、Graph 和 Serving Runtime 连在一起。

6. TP、NVFP4、Kernel、CUDA Graph 应该放在一条链里看

前面几篇是分开讲的：

NVFP4
→ 让权重更小

TP2
→ 两张 GPU 同时参与同一层

Kernel
→ 当前矩阵到底怎么执行

CUDA Graph
→ 减少 Launch / CPU 调度

但生产部署里它们其实是一条链。

以这次双 5060 Ti 为例：

Qwen3.8-27B NVFP4
↓
权重完整 GPU Resident
↓
TP2
↓
两卡同时处理权重分片
↓
NVFP4 / Attention Kernel
↓
Compile
↓
CUDA Graph

任何一层没有走到理想路径，最后的 token/s 都会受到影响。

所以我现在不太喜欢只问：

NVFP4 能快多少？
CUDA Graph 能快多少？
TP 能快多少？

更值得看的问题是：

这几个优化组合以后，整条执行链有没有真正工作。

7. vLLM 的优势最后还会延伸到 Serving 层

GPU 执行链做好以后，生产服务还有另一类问题：

请求 A：正在 Decode
请求 B：100K Prefill
请求 C：刚到达
请求 D：和上一轮共享大量 Prefix

这时单纯让一个 GEMM 再快一点已经不够。

还需要：

Scheduler
Continuous Batching
Chunked Prefill
Paged Cache / Block 管理
Prefix Cache

来决定：

GPU 当前这一轮到底应该算谁，以及哪些东西根本不用重新算。

这也是 vLLM 让我更愿意拿来做长期 Serving 的另一半原因。

但这部分我不会在这一篇展开。

因为第六篇会专门讨论：

100K Context 装得下以后，Prefix Cache、Chunked Prefill、Continuous Batching 和 MTP 到底分别解决什么问题。

这里先记住一点就够了：

vLLM 的优化不只发生在单颗 token 的 Kernel 内，也发生在请求之间。

8. 那 llama.cpp 呢？

这并不是说 llama.cpp 没有 GPU Kernel、Batching 或 CUDA Graph 一类优化。

它同样是一套非常成熟、而且极其重要的推理 Runtime。

我认为二者真正的区别，不应该写成：

llama.cpp 慢 / vLLM 快

这种过度简单的判断。

更准确的定位是：

llama.cpp 更擅长把“可部署硬件范围”做得非常宽

例如：

GGUF
大量量化格式
CPU-only
CPU + GPU
RAM Offload
异构 GPU
不同显存容量
本地桌面与个人设备

像 Flash-Next 这种模型，如果个人硬件根本不可能全 GPU Resident，那么 llama.cpp 的 CPU + GPU 路线反而可能是最现实的入口。

vLLM 更适合在“模型可以 GPU Resident”以后继续追求 Serving 效率

例如：

TP / PP
高性能量化 Kernel
Compile
CUDA Graph
Continuous Batching
Scheduler
Prefix Cache
高吞吐 API Serving

所以我更愿意用一句话概括两者：

llama.cpp 把个人硬件能触碰到的模型上限往上推；vLLM 则在模型能够 GPU Resident 以后，把 NVIDIA GPU Serving 的性能上限继续往上推。

这两个价值并不冲突。

9. 为什么我的 27B 生产部署默认选 vLLM？

回到这套实际硬件：

2 × RTX 5060 Ti 16GB + Qwen3.8-27B

我们已经找到一种方式，让模型能够：

NVFP4
+
完整 GPU Resident
+
给 Cache 留空间

这时候我就没有太强的理由主动把热点权重再搬回 CPU。

我的关注点已经从：

怎么把模型塞进去？

转向：

怎么让两张 GPU 同时工作？
怎么让 NVFP4 走正确 Kernel？
怎么减少 Kernel Launch？
怎么提高 Serving 吞吐？
怎么避免重复 Prefill？

而这些问题正好是 vLLM 的主场。

所以对这类场景，我现在的默认选择是：

先用 vLLM，把完整 GPU Serving 路线跑通。

如果模型大到根本做不到合理 GPU Resident，再回到 llama.cpp / GGUF / RAM Offload 的容量路线。

10. 我的生产推理优化顺序

现在让我重新部署一个 27B 服务，我大概会按这个顺序：

1. 选择模型与可接受的量化

2. 尽量让权重完整 GPU Resident

3. 确认量化格式真的有当前 GPU 的有效计算路径

4. 选择合适的 TP / PP

5. 确认 GEMM / Attention Kernel

6. Compile / CUDA Graph

7. Context / Cache 规划

8. Scheduler / Continuous Batching

9. Prefix Cache

10. 最后再评估 MTP-based Speculative Decoding

其中最重要的变化是：

我已经不把“模型成功启动”当成部署完成。

真正想要的是：

模型质量合理
权重尽量 GPU Resident
低精度硬件能力被正确利用
Kernel 走在合适路径
GPU 尽量少空转
重复计算尽量少做
多卡和多请求都能有效调度

这时候 NVFP4 就不只是“省了几 GB 显存”。

vLLM 也不只是“KV Cache 管得比较好”。

它们最终都属于同一件事：

把有限的 GPU 资源尽可能转化成真正可用的 Token。

接下来就进入剩余显存里最大的一块变量之一：长上下文 Cache。

《200K Context 到底需要多少显存？从 KV Cache 算到 Qwen3.8 的真实部署》

系列导航： ← 上一篇：两张 RTX 5060 Ti 为什么没有两倍推理速度？显存带宽、PCIe 与 P2P · 下一篇：200K Context 到底需要多少显存？从 KV Cache 算到 Qwen3.8 的真实部署 →