(转)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 修复都在里面。

也就是说：

权重下下来 ≠ 你就能跑。…