加油！！！！！！

【续篇】6750 GRE 10G 转战黑苹果：ToshLLM Dynamic MoE 全内存跑 30B-A3B MoE，prefill 617 t/s，DFlash 投机再次翻车实录

上一篇（topic/2118）是 Windows + Vulkan 跑 Qwen3.8-27B dense。这几个月我把同一台机器刷成了黑苹果，模型也换成了 MoE 架构的 Qwen3-Coder-30B-A3B（Q4_K_XL，约 18GB，比上次大了 10GB），本以为 10G 显存彻底没戏，结果 ToshLLM 的 Dynamic MoE 规划器交出了一份让我自己都意外的答卷。老规矩，数据全实测，翻车不遮。

TL;DR

1. 同一张 6750 GRE，换 macOS 反而更能打了：ToshLLM（Metal + AMD 补丁）跑 18GB MoE 模型，prefill 实测 617.7 t/s（2418 token 样本），短上下文生成 33.5 t/s，热缓存冲到 47.3 t/s
2. Dynamic MoE full-host 方案：15.5GB 专家库整体 mlock 进内存（wired）+ 5.3GB 热专家驻留 VRAM，plan coverage 1.34（GOOD）。attention 全程在 GPU，专家按需从内存取——比"每层硬拆 CPU/GPU"聪明一个量级
3. 长上下文衰减可控：生成速度 33.5（短）→ 19.6 t/s @21.8K → 14.1 t/s @36K，MoE 模型在 10G 卡上这个曲线我觉得能接受
4. DFlash 投机解码翻车实录（梅开二度）：官方草稿头接受率 60.5%、平均 2.81 tok/轮，推测机制本身工作得很好——但净速度 1.1~1.7 t/s。原因不是 RDNA2 算不动，是草稿多吃 ~1GB 内存后 swap 从 1GB 飙到 4GB，mmap 专家被换出到 SSD。瓶颈是内存，不是显卡
5. 一个测量方法论的坑：拿 9 token 的小请求测 prefill 会得到 26.6 t/s 的假数据（固定开销摊薄），同一服务换 2418 token 样本实测 617.7 t/s，差 23 倍。测速帖的小样本数据都建议打个问号
6. 顺手搭了套 47 模型智能路由：5 个入口按任务类型+健康度+成本自动选模型、失败自动换下家，ZCode / opencode / 网页端三前端共用，本地模型只是其中一个候选

硬件（和上一篇同一台）

项	配置
CPU	AMD Ryzen 7 5700X（8C16T）
内存	32GB DDR4-3200 双通道
显卡	RX 6750 GRE 10G（gfx1031 / RDNA2 / 320GB/s）
系统	macOS（黑苹果，OpenCore）
引擎	ToshLLM 0.87.16（llama.cpp Metal + AMD 专用补丁，自动内存规划）

模型与加载参数

模型:   Qwen3-Coder-30B-A3B-Instruct UD Q4_K_XL（Unsloth 动态量化，≈18GB）
        MoE 架构：128 专家 / 激活 8，激活参数仅 3B
启动:   --dynamic-moe on（自动规划器决定每个专家驻留位置）
        -ngl 99 -fa on（AMD 专用 FA 内核）-ctk q8_0 -ctv q8_0
        -c 40960 -np 1 --jinja
规划结果: 15.5GB 专家库 → wired RAM（mlock 锁定，永不换出）
          5.3GB 热专家 → VRAM
          coverage 1.34（>1 即显存装不下的部分全部进锁页内存）

实测数据

测试	结果
prefill @2418 tok	617.7 t/s
生成 · 短上下文	33.5 t/s
生成 · 短上下文热缓存	47.3 t/s
生成 @21.8K 上下文	19.6 t/s
生成 @36K 上下文	14.1 t/s
首 token 延迟（短上下文）	<1s

对比一下上一篇的 dense 27B：那时候全显存 Vulkan 是 pp 130 / tg 14.4。现在模型大了 10GB、激活参数只有 3B，生成直接翻倍还多——MoE 架构对小显存卡是真的友好，前提是你得把专家安置好。

Dynamic MoE 为什么比手动 --n-cpu-moe 强

传统玩法是手动设 --n-cpu-moe N，把前 N 层专家甩给 CPU 走 mmap 页缓存。问题是 mmap 页随时可能被系统换出，内存一紧张每个专家访问都变成 SSD 读取。

ToshLLM 的规划器是另一套思路：算出显存能住多少热专家，剩下的整体 mlock 进 wired RAM——锁定页不换出，访问延迟就是纯内存带宽。5700X 的 DDR4-3200 双通道约 50GB/s，喂 3B 激活参数绰绰有余。这就是为什么 prefill 能跑到 617 t/s：attention 在 GPU 全速算，专家从内存随取随用。

DFlash 投机翻车实录（本帖重点）

上一篇 draft-mtp 在 Windows/Vulkan 上只有 +12%，这次换了 Z Lab 给这个模型专门训的 DFlash 草稿头（0.5B，Q8_0，509MB），再战一次：

指标	结果
草稿接受率（代码任务）	60.5%
平均每轮接受 token	2.81
推测机制本身	完全正常工作
实际生成速度	1.1~1.7 t/s（净亏损 95%）

机制没问题，死在内寸上：draft 模型多占约 1GB，32GB 内存本来就紧（wired 锁了 19.3GB），swap 直接从 1GB 干到 4GB，mmap 专家被换出，每个推理轮次 1.65 秒。

结论：Dynamic MoE（省内存换速度）和 DFlash（吃内存换速度）在 32GB 机器上互斥，二选一，选前者。 草稿文件我留着了，等加内存到 64GB 再开——理论上 mlock + DFlash 兼得时能上 50~60 t/s。

测量方法论的坑（给所有测速帖提个醒）

中途我一度得出"prefill 只有 26.6 t/s，build 模式要 8 分钟"的结论，差点把方案否了。后来排查发现：测试请求只有 9 个 token，约 330ms 的固定开销（模板渲染、KV 初始化）全摊到这 9 个 token 上。换 2418 token 样本重测，617.7 t/s。

教训：prefill 测速样本量必须上四位数 token，小样本测出来的"单 token 速率"全是固定开销的锅。 论坛里不少悲观数据可能就是这么来的。

附：顺手搭的智能路由（离线可用架构）

本地模型只是入口之一。另外跑了个自研路由层（OpenAI 兼容，FastAPI）：

• 47 个候选模型（本地 + 各家 API + 免费池），5 个虚拟入口按任务类型路由
• 按健康度 EWMA + 上下文长度 + 成本打分，429/402/5xx 自动熔断 + 换下家
• 语义判官单独走云端快模型，不和本地单槽抢资源
• 前端随便换：ZCode、opencode CLI、网页端，都指同一个端口

踩过的三个真实 bug 也分享一下，都是血泪：回退路径 NameError 导致一次上游抖动直接 500；402（余额不足）没进容错规则导致整链卡死；judge 和聊天请求抢本地单槽互相超时。修完整条链路才真的稳。

操作清单（同卡想复现的兄弟）

1. ToshLLM 装最新版，直接用 Dynamic MoE 自动规划，别手动拆层
2. 模型选 MoE 架构（30B-A3B 档），dense 27B 以上在 10G 卡上不要想
3. KV cache 上 q8_0，上下文别贪，40K 是 32GB 内存的甜点位
4. -np 1 老规矩，单槽
5. 投机解码在 32GB 内存下直接放弃，64GB 再议
6. 测速用大样本，别被小数字骗了（包括别人帖子里的小数字）

遗留问题

• 64GB 内存后 DFlash + mlock 兼得的实测数据（待硬件升级）
• 长上下文 14 t/s 的衰减主要是 KV 读取带宽，TurboQuant（KV 压到 16%）理论上能治，等主线
• Kaggle 免费 GPU 桥（abliterated 30B）实测 build 模式一轮 215 秒，只适合短聊——免费的就是最贵的

（数据均为本机实测，环境如上，欢迎同卡玩家复现对拍）

——6750 GRE 二茬开荒，翻车照发，数据无修饰

TL;DR

1. gfx1031 免补丁：llama.cpp 主线 Vulkan 构建（b11146）直接点亮，不需要 ollama-for-amd 换库，不需要 HSA 伪装
2. IQ2_XS 全显存：GSQ-RCO 2.31bpw（7.83GiB）塞进 10G 显存，pp512 130.7 t/s / tg128 14.4 t/s，服务器实跑 9.7-9.8 t/s
3. 128K 上下文无衰减：KV q8_0 塞下 128K（fit 警告但能跑），生成速度和 16K 完全一致
4. 投机解码翻车实录：draft-mtp 只有 +12%（接受率 76-94%），ngram-map-k4v 负收益（-7%）——RDNA2 没有 WMMA，投机验证开销吃不消，和 RDNA3 的 +53% 完全相反，老卡用户请直接关投机
5. KVMem 无缘：目前是 HIP fork 专用，主线 Vulkan 构建没有，RDNA2 用户暂时用不了
6. 必挂 froggeric/Qwen-Fixed-Chat-Templates v22：官方模板 OpenAI 字符串工具参数直接 TypeError、enable_thinking=false 崩溃——接 DSH/Cline 前必须换

硬件

项	配置
CPU	AMD Ryzen 7 5700X（8C16T）
内存	32GB DDR4-3200 双通道
显卡	RX 6750 GRE 10G（gfx1031 / RDNA2 / 320GB/s）
系统	Windows 11 专业版
引擎	llama.cpp b11146 官方 Vulkan 构建（vulkan-x64.zip）

模型与加载参数

模型: Qwen3.8-27B GSQ-RCO IQ2_XS（2.3125 bpw，7.83 GiB，ISTA-DASLab）
      对照组: huihui-ai 去审查版 Swift-1.5-GSQ-RCO-IQ2_XS（同量化，速度无差异）
llama-bench: -ngl 99 -fa 1 -ctk q8_0 -ctv q8_0
服务器:      -c 16384/131072 -np 1 --jinja

实测数据

测试	结果
llama-bench pp512	130.73 ± 0.25 t/s
llama-bench tg128	14.40 ± 0.01 t/s
服务器实跑生成 @16K	9.8 t/s
服务器实跑生成 @128K	9.7 t/s（无衰减）
服务器 prompt 处理 @128K	29.7 t/s

投机解码 A/B（同题实测）

方案	草稿接受率	实际生成速度	结论
裸跑	—	9.8 t/s	基线
--spec-type ngram-map-k4v	46-54%	9.1 t/s	负收益
--spec-type draft-mtp（MTP文件）	76-94%	10.6-11.0 t/s	+12%

分析：RDNA2 没有 WMMA，投机验证的逐 token 成本远高于 RDNA3。7900XTX 大佬们实测 ngram +53% 的参数，搬到老卡上直接反转。draft-mtp 靠 94% 的高接受率勉强保住正收益，但别指望 RDNA3 那种翻倍。

对照参考（同级别卡）

• RTX 3080 10G：Qwen3.6-27B Q4_K_M + MTP = 32 t/s @ 65K（CUDA i-quant kernel 优势）
• 5700X 同款 CPU + 7900XTX 24G：IQ3_S 128K KV int8 = 稳定 30 t/s（坛友实测）
• 本卡带宽理论上限：320GB/s ÷ 8.4GB ≈ 38 t/s，实际只吃到 38%——瓶颈在 Vulkan 的 IQ2 反量化 kernel 走 ALU

给同卡兄弟的操作清单

1. 官方 Vulkan zip 解压即用，显卡零配置
2. 模型选 GSQ-RCO IQ2_XS（7.83G 全显存），别碰 Q4_0（Qwen3.8 系思考死循环，坛友已踩）
3. 必换 froggeric v22 聊天模板
4. 采样参数用官方表：思考 temp 1.0/top_p 0.95/top_k 20；Instruct temp 0.7/top_p 0.80/presence 1.5
5. Agent 用途（DSH/Cline）：显式带 temperature，投机只开 draft-mtp，工具调用密集段关掉
6. 服务器一定加 -np 1：默认 4 槽会撑爆 10G 显存导致部分层回退 CPU（速度直接腰斩再腰斩）

遗留问题

• Vulkan 的 IQ2 kernel 效率（38% 带宽利用率）啥时候能优化到 CUDA 水平
• KVMem 什么时候能进主线支持 Vulkan
• 等 Qwen3.8 出 8-14B 档，老卡用户能吃到全量化档位

（数据均为本机实测，环境如上，欢迎同卡玩家复现对拍）

-- 6750 GRE 开荒首发，数据无修饰