双卡 3090 PCIe 跑 GLM-5.3-Flash：MoE 专家缓存 + DFlash2 草稿（decode ~19 tok/s）

[johnnybegood]

先说一句话总结

GLM-5.3-Flash（320B MoE，glm5next 架构）塞进 2 张 RTX 3090 PCIe + llamacpp 的 MoE 专家缓存引擎，默认配置下 decode 中位 19 tok/s（对话 19.04 / 代码 19.32）。比最开始的12 tok/s 速度快了不少。但有两件事：

1. ctx=262144 别用，cache 会崩，decode 直接到 12.x；
2. chat-template 一定要 patch，否则工具调用全 400，/props 报 supports_tools:false。
   下面分四个块讲：电脑配置 → 怎么配的 → 实测结果 → 注意事项

一、电脑配置

其实就是家用 PCIE 拓扑，没 NVLink，凑合用：

项	我的
GPU	2× NVIDIA RTX 3090（24 GB，Ampere SM 8.6），PCIe，无 NVLink，-ts 1,1 layer-split
CPU	32 cores 128G 3600 DDR4
HOST RAM	≥114 GB 起步，建议留到 120 GB+
锁功耗	不锁也行（卡默认 350W max）

单卡跑不动：GLM-5.3-Flash iQ3_XXS 单卡部署要约 113 GiB 权重 + 25 GiB 计算缓冲 + KV，24G 直接 OOM。双卡是硬门槛。

二、配置过程

前两天这个配置把 DeepSeek V4 Flash 跑到17tok/s ， 现在基本就是配置抄过来用，关键决策这么几条：

2.1 引擎锁 v1.6-rc0 digest，1.4 之前别用

GLM 是 glm5next 架构。之前版本根本不认这个 arch，装上直接 unknown arch glm5next，白装四十分钟。

ghcr.io/noonghunna/llamacpp-club3090@sha256:69b833eea9266707cd9853fc8041348a59e2403a1e763822db5c2a46484db72b

回滚 digest 是 sha256:1c228a52…（v1.5-rc0），降级之前 v1.6 还是 rc2 是 bf2776f7…——DFlash2 这个 drafter 在 rc2 上会炸

2.2 一条 -ot 把 routed 专家全推 CPU

-ot 'blk\.[0-9]+\.ffn_(gate|up|down)_exps\.weight=CPU'

但别推 shared expert 跟 router：*_shexp 每个 token 必打，扔 CPU 会把 decode 干到 8 tok/s。

2.3 DFlash2 草稿放到GPU

- -md '/models/glm-5.3-flash-gguf/dflash2/GLM-5.3-Flash-DFlash2-Q4_K_M.gguf'
- --spec-type draft-dflash
- --spec-draft-n-max 2
- -devd CUDA1

三档实测位置（同一台机器、同一个晚上测试）：

草稿位置	narrative	code
不开草稿	15.76	15.40
草稿 → host	13.99（−11.2%）	14.88（−3.4%）
草稿 → GPU1	15.45	18.23（+18.4%）

为啥 host 还不如不开？因为解码是 CPU-bound（host ~78% / GPU SM 10-18% idle / PCIe 8.7%），草稿命中的时候 CPU 不用算一次那批专家，草稿放 host 等于给 CPU 加负。
为啥不放 GPU0？GPU1 已经 23.85 GB 了，再加一张 OOM；GPU0 留 1,850 MB 余量。

2.4 SPEC_N 用 2 不是 3

SPEC_N=3  decode median 17.55
SPEC_N=2  decode median 19.04 / 19.32

为啥？GLM 的草稿去验 CPU-resident 专家的时候也要有开销，n 大了被拒。

顺便：n=5 给 16.61（−8.9%），n=7 给 11.10（−27.9%）。接受率从 n=3 的 53% 掉到 n=7 的 33%。

2.5 UBATCH 用 2048 不是 4096

UBATCH	decode (narr)	decode (code)	prefill @10K
4096	14.58	14.93	415.44 t/s
2048	18.12	18.47	340.03 t/s

️ 但是：UBATCH=2048 + 长预填 prompt（>7k tokens）会触发 CUDA "illegal memory access"（#28282），我跑的窗口短没炸，但做长文档摘要那种就 UBATCH=512。

2.6 mmproj 放 host 别放 GPU

mmproj-F16 是 1.13 GB。默认放 host：MMPROJ_DEVICE=none。

2.7 这一步一定要做：patch chat-template

minja 不认 x.0 这种数字点属性访问，但 GGUF 自带模板里有 4 处。带 tools 请求会 HTTP 400，/props 报 supports_tools:false——本地工具调用全废。
通过 --chat-template-file 注入。做不做这一步就是踩不踩坑的区别。

2.8 跑起来

加载 113 GiB 权重 --no-mmap，实测 ~4 分钟。

三、结果

（CTX = 204800）：

配置	decode narr	decode code	prefill
不开草稿（baseline）	15.76	15.40	—
草稿 GPU1，SPEC_N=3	15.45	18.23（+18%）	—
草稿 GPU1，SPEC_N=2	19.04	19.32	340 t/s @10K
同上但 UBATCH=4096	14.58	14.93	415 t/s @10K
ctx=262144（错误示范）	13.89 ↓	13.67 ↓	—

实测上下文服务长度：68,286 token prompt @ ctx=204800，87,401 token prompt @ ctx=262144——后者 boot OK，但decode 腰斩。

四、注意事项

按重要程度排：

• UBATCH=2048 + 长预填 prompt → CUDA illegal memory access（#28282，known unsolved）。短任务无所谓，长文档批量预填就 UBATCH=512。
• ctx=262144 别用。用是能用，decode 直接 13.x。
• ️ 必须设chat-template → 否则工具调用全 400。一忘就废。
• ️ DFlash2 必须在 GPU1。GPU0 看似装得下但实际有问题。
• ️ iQ3 权重 113 GiB，实测 IQ4 141.5 GiB就没法跑了。
• ️ CLEAR_THINKING=true 可以节省 prompt tokens：实测439 → 38 token，多轮更节约prompt，但程序推荐是 false（多轮推理连续性）。

五、感想

跑完这套的几个体感：

1. 架构和量化不是 1+1=2

glm5next 一个 kpool 稀疏索引器就让 UBATCH=2048 反超了 4096， 反观qwen3.8 Flash ，架构qwen4exp 没有 kpool，不能直接用 2048 ——这个设置在不同架构上是反的。每次换架构，默认值要重测。

2. MTP草稿不是免费午餐

对话没用上drafter草稿，这个发现挺颠覆我——以前总以为 MTP 的草稿对所有任务都能加速，实测代码类 +18% 。但写作是不行的，接收率很低。日常工作里如果用 GLM 写 summary、写邮件，就别开 DFlash2——纯浪费，预填还慢 5%。这不是 GLM 的特色，是结构化输出对草稿敏感这个普遍规律。

3. 能启动 = 能用？

ctx=262144 那组数据就是个例子：启动 没 OOM，但 decode 直接腰斩。任何"启动看着没事"的判断都要用 decode 验证过再下结论。

[Xiaote]

19 t/s 在 2×3090 PCIe、320B MoE、113 GiB 权重的前提下是合理值；你测到的 host ~78% / GPU SM 10–18% / PCIe 8.7% 也说明卡点在 CPU 算 routed experts，不在卡间带宽。补三条机制层：

1. ctx=262144 为什么「启动没事、decode 腰斩」
kpool 稀疏索引省的是 attention 的计算，KV 的读写量仍随 ctx 线性涨；48 G 显存被权重/计算缓冲占住后，长 ctx 的 KV 只能落 host，每 token 多一遍「读 KV + 过 PCIe」，而 decode 是逐 token 的，这笔固定成本直接把 19 拉到 13。验证口径：llama-bench 固定 -p 0 只跑 decode，扫 32K/64K/128K/200K/262K 画 tg 曲线，同时 --log-verbose 看 KV buffer 落在哪个 device；曲线出现台阶的 ctx 基本就是 KV 溢出的拐点——「能加载」不等于「能用」。

2. #28282
-ub 2048 + 长预填 的 illegal memory access 是 kernel 越界，不是显存不够。长文档建议 -ub 512 之外再把预填分块（-b ≤ ub，必要时 --no-context-shift），绕开那条越界路径。2048 对短窗口仍是 sweet spot；你两个 arch 的对比（kpool 有/无，2048 vs 4096 谁赢是反的）值得单独记一笔。

3. 草稿
代码 +18%、叙事不涨，符合 spec decoding 的账：收益 ≈ 接受率 × 省下的 target 调用 − 验证开销。自由文本接受率低、验证照跑就是纯亏；叙事任务直接关 DFlash2，或把 --spec-draft-n-max 压到 1。n=2 优于 n=3 也是同一件事——接受率随 n 衰减得比你验证省的多。

想确认一点：262144 那组的 KV 是显式 -ctk/-ctv 量化过、还是默认 f16 留 GPU？如果是 f16 留 GPU，那这组更像 KV 溢出到 host，而不是 kpool 本身退化——用上面的 tg 台阶就能分辨。

[terry]

别用-或者点开头。

[Xiaote]

版主审定：本帖设为精华，作者 +5 积分奖励，希望再接再厉！

奖励凭证：精华 +5 分 · 编号 f1929-363-1（系统自动发放，只发一次）