Qwen3.8-Flash-Next (95.5 GiB) 在 64GB Mac 上以约 27 tok/s 运行，检查点与叉版本

过去几周，我一直在将 Qwen3.8-Flash-Next 作为主要的本地编码模型运行。文件大小为 95.5 GiB，而我的 Mac 有 64 GB 内存。它能工作是因为路由的专家驻留在 SSD 上，只在令牌实际路由到它们时才被读取。终于清理到足够发布的程度：模型：https://huggingface.co/nitinpanj/qwen38-flash-next-v3。叉版本：https://github.com/npanj/llama.cpp 这不能在原版 llama.cpp 上运行。上游有架构但没有专家流式处理标志，因此它尝试加载全部 95.5 GiB 并崩溃。在我的 M5 Pro (64 GB) 上的速度：提示处理 u/4k 约 367 tok/s，生成速度，开启草稿头约 27.6 tok/s，关闭草稿头 18-18.6 tok/s 在 29k 上下文下，实际聊天使用约 20.6 tok/s。使预填充快速的原因：每层嵌入表为 26.8 GiB，行大小为 90 字节，在 mmap 下每次聚集都会产生页面错误。切换到直接文件读取（pwilkin 的 #29030，上游仍开放）将 512 令牌提示的速度从 181 提升到 401 tok/s，8k 提示从 274 提升到 451 tok/s。使解码快速的主要原因是草稿头。小模型猜测 3 个令牌，大模型一次验证它们。同一台机器，同一下午，速度从 18 提升到 27.58 tok/s。调优它几乎和拥有它一样重要：深度 3 且置信度下限为 0.3 在 22 种组合的扫描中比没有下限的深度 4 快 10%。深度 4 每次测量都失败，这让我惊讶，因为叉版本硬编码为 4。此外，基于聚集的稀疏注意力（#28213）在 62k 上下文下带来 +19% 的提升，在 130k 下 +50%，Metal MoE 融合（#28948）再带来 5-9%。检查点是 bartowski 的 Q4_0 带有 Q8_0 输出层，加上 unsloth 的 UD-IQ4_XS 被拼接到五个常驻的张量组中。配对的 40 块困惑度从 5.2777 降至 4.3148，在所有 40 块上都更好，磁盘上增加 1.69 GiB。设置是五个步骤，大约一小时，主要是下载。命令在仓库的 readme 中。有两件事花了我时间：保持专家缓存和 Metal 有线限制同步。在 64 GB 上，36 GiB 的缓存是实际的上限。我尝试了 38，解码速度下降到 3.7 tok/s，一旦服务器自己的堆开始交换。仅在 64GB Apple Silicon、内部 SSD 上测试。未尝试 CUDA 或 CPU。应得的功劳：专家流式处理是 mihailescu2m 的工作，正是它使整个方法成为可能。基础模型是 Qwen 的，量化来自 bartowski 和 unsloth。我携带的六个仍开放的 PR 在 readme 中列出了作者。