111GB通义千问模型在双4090 96G成功跑通速度达66token/s

Qwen3.8-Flash-Next 的 GGUF，111GB 模型在双 4090 96G 竟然跑通了。 这模型是真的邪门。

我这台机器是： 2× RTX 4090 48G = 96GB 显存 62GB 内存 跑的是 Unsloth 的 UD-Q4_K_XL。 没开 MTP 下，最后实测生成速度稳定在： 66 tokens/s。 而且不是 1bit 那种“能跑就行”的版本，是 103.7 GiB 的 Q4，高质量档。

1. 先说 Q4：111GB 的模型，96GB 显存居然装下了 Q4_K_XL 的 GGUF 总共大概 111.3 GB。 正常看，这东西根本塞不进 96GB 显存。 但这个模型有一个很特殊的东西： PLE / N-gram Embedding。 单独一个 tensor： per_layer_token_embd.weight 就占了： 28.8 GB。

所以账其实是这么算的： 111.3 GB 总权重 28.8 GB PLE ≈ 82.5 GB 真正需要长期放 GPU 的权重 这一下，双 4090 就能装了。 而且这个 Q4 也不是简单粗暴全部 4bit。 Unsloth Dynamic 里面还有 125 个 tensor 保留成 Q8_0，主要是部分 ffn_down_exps。 它本质上还是一套“不均匀量化”。 该省的地方省，该保智商的地方继续给高 bit。

最后 wikitext-2 PPL： 3.9419 对比 IQ1_S 的： 4.6171 差距已经很明显。 试了 IQ1_S 做长代码生成直接会陷入 reasoning 死循环，降智严重。

🔥 显存最后占了多少？ Q4_K_XL + PLE offload 之后： GPU 0： 41,308 MiB GPU 1： 39,020 MiB 合计： 80,328 MiB，也就是大约 80.3 GB。 96GB 显存还剩下差不多： 16GB。 这 16GB 还能继续留给 KV Cache。 而这个模型 KV 又特别省。

🔥这他娘的是个天才 48 层里面只有 12 层是 full attention，其他 36 层是 Gated DeltaNet。 所以 32K context 的 KV 大约才： 0.8 GB 128K 也才大概： 3.1 GB。 这也是为什么这玩意特别适合这种“显存装权重、内存放大查表”的玩法。

🔥最骚的是 PLE：28.8GB 直接扔进 CPU 内存 一开始我也担心： 卧槽，28GB 权重放内存，通过 PCIe 查，不得慢死？ 结果恰恰相反。 IQ1_S 做 A/B： 全部进 GPU： 61.47 t/s PLE 放 CPU： 73.53 t/s 不但没掉，反而更快。

原因也比较好理解。 这个 28.8GB 并不是普通 Transformer 每个 token 都遍历 GEMM 的权重。 它本质上是一个巨大的随机查表结构。 每个 token 真正取的数据非常少。 所以你根本没必要为了这 28.8GB 的“大仓库”，给它长期占着 28.8GB 显存。 仓库放系统内存，需要什么拿什么。

这可能才是 Qwen3.8-Flash-Next 这个架构最有意思的地方之一。 以后这种超大 N-gram / embedding / retrieval 型参数越来越多以后： 总参数量 ≠ 显存需求。 这个概念会越来越重要。

🔥最后能跑的命令配方： llama-server \ -m /path/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \ -ngl 99 \ -fa on \ -ot 'per_layer_token_embd\.weight=CPU' \ -c 32768 \ --jinja \ --host 0.0.0.0 \ --port 8080

但是注意： 现在不能直接拿 llama.cpp master 来跑。 这个模型的 architecture 是： qwen4exp 而 llama.cpp 主线目前只有 qwen3next，还没有完整支持这个架构。 我最后用的是 Unsloth 自己的 PR 分支： unslothai:qwen4exp/qwen3.8-flash-next PR #27742。 里面不只是加了 converter。 text graph、稀疏 attention、vision，还有几处 quantizer 修复都在里面。 也就是说： 权重下下来 ≠ 你就能跑。 Runtime 也必须跟上。