1.28GB 加速器，24GB 显卡为何用不起？
最近社区里冒出一批新词：DFlash2、MTP draft 词表特化、投机解码加速。听起来都很美好——一个只有 1GB 多的小模型，能让 27B 大模型跑得飞快，是不是白捡的便宜？带着这个问题，我翻了 SGLang 的源码，又在自己两台 RTX 3090 上做了实测。结论可能会让很多人意外：能力上框架完全支持，但在这张 24GB 的显卡上，这笔”买卖”亏大了。
一、先搞清楚：投机解码到底是什么
大模型生成是一个 token 一个 token 来的，每步都要等 GPU 算完。投机解码的思路是：用一个又小又快的小模型（draft 模型）先”猜”出后面几个 token，让大模型一次性验证——猜对了就白赚几步，猜错了回退重来。赌的就是”小模型猜得够准”。
这套机制要跑起来，通常有两条路：
一条是模型自带的 MTP 头。Qwen3.8-27B 这类新模型自带一个”多 token 预测”模块，不用额外加载模型，但需要推理框架支持才能用上它。
另一条是独立的 draft 模型，比如最近刷屏的 DFlash2。它是个专门训练的小模型，W4A16 量化后只有 1.28GB（还有个 MLP-only 变体 1.86GB）。小到什么程度？连大模型的一个零头都不到。
看到这个数字，很多人（包括我一开始）的第一反应是：才 1.28GB，挤一挤不就放下了？
二、查源码：SGLang 到底支持不支持
光靠印象说话不可靠，直接翻框架源码。我在这台 3090 上跑的 SGLang v0.5.17，源码里投机解码的算法列表写得明明白白：
EAGLE, EAGLE3, NEXTN, STANDALONE, NGRAM, DFLASH, DSPARK
DFLASH 是完整实现，不是画饼。dflash_worker_v2.py 一个文件就有七百多行：draft runner、block_size 配置、mask token 处理、验证逻辑一应俱全。启用方式也很简单，三个参数：
--speculative-algorithm DFLASH
--speculative-draft-model-path <DFlash2 路径>
--speculative-dflash-block-size N
再往下挖，还有几个有意思的发现：
NEXTN 不是独立算法，它是 EAGLE 的保留别名（源码里 _RESERVED_ALIASES 写死 NEXTN -> EAGLE）
Qwen3-MoE 的 MTP 头是被支持的（EAGLE worker 里有专门分支处理），DFLASH 流程里也会用 MTP 头做验证融合
没有任何 Ampere/Blackwell 架构限制——3090 理论上能跑
也就是说，框架这一层，门是敞开的。于是问题回到了最朴素的地方：显存够不够？
三、实测数据：这笔买卖的真实成本
先看收益。在我之前跑 llama.cpp 时，MTP 投机解码是实测过收益的：
速度从 40.7 t/s 提到 63.2 t/s，+55%
draft 接受率 76%，draft 长度 2
速度提升是实打实的，接近 1.6 倍，这对单流长输出场景非常诱人。
再看成本。同样是实测：在 SGLang 里给 27B 模型配 MTP draft worker，额外显存开销约 2.37GB。DFlash2 的 1.28GB 权重只是冰山一角——draft 模型自己的 KV 缓存、运行时中间状态、投机解码的额外缓冲，加起来远超模型文件本身。
我这两张 3090 现在的显存余量是多少？
GPU0（跑 born2bewild 激进量化，150K 上下文）：1.3GB
GPU1（专职 opencode 子代理，168K 上下文）：1.6GB
都不够 2.37GB。
四、更大的问题：它和我的策略方向完全相反
就算把余量挤出来，还有一盆冷水：投机解码是要用显存换速度，而我这两张卡走的是上下文优先路线。
为了让 24GB 卡跑得动长上下文，我做了激进量化——把语言模型的 embedding 层压到 INT8、lm_head 压到 INT4，净省 3.6GB 显存，全部变成 KV 缓存。结果就是上下文从 7 万顶到了 15 万/16.8 万 token。
现在如果引入投机解码，要做的恰恰相反：把上下文让出来给 draft 模型。算一笔账：2.37GB 的投机解码开销，按我们卡上的显存换 token 的速率，大约要牺牲 1.5~2 万 token 的上下文——150K 缩水到 135K 左右。
一个 agent 任务动辄吃几十万 token 上下文，和”生成快 55%”比起来，哪个更值钱？答案不言自明。而且我们的场景是 3 并发 agent 交互，不是单流长文本生成——SGLang 的 CUDA Graph 和连续 batching 已经把并发吞吐优化得很好了，投机解码那 55% 的提升对我们的交互延迟帮助有限。
五、顺带聊聊 MTP draft 词表特化
这几天 HF 上还出现了一批”draft 词表特化”模型，比如给 Qwen3.8-27B 重建 MTP draft 词表的变体——把一个英文语料统计的 draft 词表，改成俄语优先的 18195 个 id，声称”俄语场景恢复满血投机质量”。
这个思路本身没错：draft 词表确实影响特定语言的接受率。但对大多数中文/英文用户来说，这类”特化”要么是零增量，要么连英文覆盖率都要让一点给俄语。它是投机解码这个能力上的锦上添花——前提是你得先用得上投机解码。在 24GB 单卡上，我们连前面那关都过不去。
六、结论：什么时候才值得用
这次查证的收获，不是一个简单的”支持”或”不支持”，而是一个判断框架：
投机解码的本质，是用显存换速度。 所以在决定要不要用它之前，先问自己三个问题：
一、显存有富余吗？ draft 模型的真实开销不是模型文件大小，而是”权重 + draft KV + 运行时缓冲”的总和——我实测是 2.37GB。余量不够就免谈。
二、你的场景是速度敏感还是上下文敏感？ 单流长文本生成（比如批量写作）对速度敏感，值得；agent 长上下文任务对上下文敏感，不值得。
三、框架支持吗？ 这一点反而是最不用担心的——SGLang 的 EAGLE/DFLASH/DSPARK 全家桶都在，3090 也能跑。
对我的两台 3090 来说，结论是明确的：保持上下文优先，不引入投机解码。 如果未来升级到 32GB 显存，或者出现”给 24GB 卡专门优化的超轻量 draft”——那 DFLASH 一行参数就能启用，随时可以再战。
本文所有源码结论来自 SGLang v0.5.17 容器内实机源码核对，速度/显存数据为双 RTX 3090 实测。相关部署实践见公众号历史文章《24GB 显卡的极限压榨：用 SGLang 部署激进量化的 born2bewild-Qwen3.8-27B》。