Qwen3.8-Flash-Next 是个 180B 总参 / 6B 激活的多模态 MoE，官方放出了给 sushi（Apple Silicon 原生推理引擎）打包的几个量化版本。我在一台 96GB 的 Mac（Mac14,6） 上用 sushi 1.4.1 把两档都装齐并各跑了 release bench：Sushi-4bpw（EXL3 专家权重）和 Sushi-STQ-2.75bpw（自研 STQ / Sushi Trellis Quant，专家权重 2–4 bit 混编）。结论先放这里：2.75bpw 当日常主力，4bpw 留作重炮后备。

质量：KLD 与 Top-1 一致率

最可比的一组数字来自模型卡里同一套 harness 的八分类评测（code / math / reasoning / design / wikitext / multilingual / story / stem，各 2 条 × 512 token，对 BF16 原模型算 KL 散度，bf16 KV，--qwen-gdn 32；显存为评测期峰值 GPU memory）：

量化包	峰值显存	八分类 KLD	Top-1 一致率
Sushi-2bpw	37.4 GB	0.0673	—
Sushi-2.6bpw	47.0 GB	0.0342	—
Sushi-STQ-2.75bpw	49.6 GB	0.0295	94.73%
Sushi-4bpw	68.2 GB	0.0135	—
oMLX oQ4e（改包）	74.1 GB	0.0279	—
mlx-serve mixed 4-8bit	75.1 GB	0.0120	—

读法：2.75bpw 用 少 18.6 GB 显存换来 KLD 从 0.0135 升到 0.0295——仍然是很小的绝对误差，Top-1 词一致率 94.73%，即每 100 个位置里约 5 个和 BF16 想得不一样的词。而它比显存更多的 oQ4e（74 GB）质量还略好。参考项：LLMProbe Hard 50（MMLU-Pro / OlympiadBench / LiveBench / Juliet）上 4bpw 拿 90.0%，没测 2.75bpw 同项，仅作难度锚点。

性能：同一台机器的 release bench

协议：/v1/completions 上喂 token id，greedy + ignore_eos；code 组是固定的 TypeScript 语料、prose 组是《傲慢与偏见》；4k 起每档做 ladder + 3 次 4k→128k decode 采样，服务器默认开 MTP 投机解码。下表为 decode 中位数（tok/s）：

上下文档位	4bpw · code	2.75bpw · code	4bpw · prose	2.75bpw · prose
4k	24.9	58.2	28.1	30.1
8k	24.6	57.0	32.7	34.3
16k	16.3	48.1	29.4	36.9
32k	16.8	51.9	30.8	31.8
64k	42.6	55.6	31.7	39.0
128k	35.4	48.0	30.2	32.4

Prefill（code 组，窗口 tok/s）：4bpw 稳定在 276–302，2.75bpw 在 369–392，快约 30%。4k 冷启动 TTFT 是 16.4s vs 14.0s；到 128k 档每次追加请求的 TTFT 约 29s vs 22.5s。

几个值得展开的现象：

• 速度差几乎全部来自投机解码的接受率。4bpw 在 code 组 16k/32k 档掉到 16 tok/s（16k 档模式甚至降级成 mixed），但同机器 prose 组里两者只差 2–4 tok/s——prose 的 MTP 接受率天然低，把差距抹平了；code 组接受率高时，4bpw 内存压力导致的波动就全暴露出来。
• 2.75bpw 全程稳。我跑了它两轮独立 bench，六档 decode 中位数两轮差距都在 ±1 tok/s 内（58.2/57.0/48.1/51.9/55.6/48.0 vs 58.0/56.2/47.8/51.5/55.1/47.3），50 tok/s 上下是一条平线。
• 诚实声明：两轮都没装 powermetrics 监控（需要免密 sudo），理论上都可能吃到未标注的热降频；4bpw 那轮前缀缓存是热的（报告标了 -hot）。这两点对“谁比谁快多少”的绝对值有影响，对“2.75 明显更快且更稳”的结论没有。

磁盘与显存账

	4bpw	2.75bpw
专家权重	63.7 GiB（EXL3）	46.1 GiB（STQ 混编）
n-gram 表（PLE/Engram，只从 SSD 读，不进 GPU）	95.4 GiB bf16	29.8 GiB 4-bit
官方合计	~159 GiB	~76 GiB

那张 95 GiB 的 bf16 n-gram 表其实可以换成 4-bit 拷贝（4-bit group32，KLD 增幅 <0.007），我这台机器上就是这么干的，还用 APFS 硬链接让两个包共享同一份表文件——所以 4bpw 在我这里的实际占用约 94 GB，而 2.75bpw 官方发布时就只占 76 GB。GPU 侧差距（68 vs 50 GB 峰值）比磁盘侧更有意义：4bpw 在 64GB 机器上根本放不下，官方建议那档机器用 3bpw；2.75bpw 则是为 64GB 机器留的口子。

我的工作流

启动脚本做成菜单（run_qwen_flash.sh 支持 4bpw / 2.75bpw 及各自的 uncensored 控制向量变体）：

• 90% 时间：2.75bpw，日常开发、改 bug、长文摘要，50+ tok/s 的丝滑感是回不去的；
• 卡壳时：切 4bpw，同一个 bug 反复鬼打墙、或复杂类型推断/长思维链任务，用它 0.0135 的 KLD 做一次高精度攻坚。

5.3% 的 top-1 差异看着小，但它恰好集中在最刁钻的边缘场景里——这正是两个包互为备份的意义。

---

测量环境：macOS 26.x，sushi 1.4.1，服务参数含 --mtp --kv-quant 8 --ctx-size 500000 --prefix-cache-disk 20GB；bench 原始报告在 sushi bench --out 产物里，quality 数据引自 STQ-2.75bpw 与 4bpw 模型卡。