上一篇（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 / 网页端三前端共用，本地模型只是其中一个候选

硬件（和上一篇同一台）

模型与加载参数

模型:   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 即显存装不下的部分全部进锁页内存）

实测数据

对比一下上一篇的 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 二茬开荒，翻车照发，数据无修饰