我把 antirez 的 ds4 削减成只跑 Metal 上 Qwen3.8 Flash Next 的精简版，移植了一大批改进，速度快了约 10%，且输出逐位一致

我曾有一个 pull request 被合入 ds4（DwarfStar），只有一个很小的。队列里还有几个在等着。我没什么可抱怨的。antirez 在 README 里说得清楚：有了编码 agent，任何人都可以为自己的硬件和模型调优这个引擎，而他无法逐一审查所有内容。这让我想到：如果计划是大家通过 agent 来应用自己的补丁，那么一个补丁真正的成本不只是代码改动本身，还包括 agent 在知道它到底在改什么之前必须读掉多少 token。ds4 的代码库在 Metal、CUDA 和 ROCm 上跑 DeepSeek、GLM 和 Qwen——全部塞在一个 8.5 万行的文件里。我在一台 128GB 内存的 M5 Max 上跑 Qwen3.8 Flash Next。那个文件里的其他所有内容对我和我的 agent 来说都是噪音。每次 agent 运行，都得把全部内容重新读一遍。所以我把它们全删了。不只是用 ifdef 包起来，而是直接删除。ds4.c 文件从 8.5 万行降到了 4.5 万行。现在整个代码树都能装进一个上下文窗口。Metal 成了生产后端，CPU 路径保留作为测试参照。我的假设是：代码库更小会让优化更便宜也更安全。结果如下： Q2：解码速度提升 9–13%，prefill 在 64k 上下文以内也有提升，MTP 从 75.8 提升到 86.7 tok/s Q4：prefill 提升 2–11%，MTP 从 77.8 提升到 85.9 tok/s 与原版 ds4 相比，每一步的输出都保持逐位一致（bit-exact）。没有 KV cache 量化，没有近似 kernel。每一项改动都必须通过 parity check——同一个 GGUF、贪心解码产出完全相同的 token——再加上与上一版构建的交错式 A/B 基准测试。 更小的代码库还让我得以把 ds4 里的 PR 全部过了一遍。我用我的模型版本逐个测试，把有效的移植过来。采纳了二十个 commit，放弃的大约三十个。结果都在仓库里。 我还为专家（experts）加了 SSD 流式加载，输出与常驻内存运行逐 token 一致。在一台模拟的 48GB 机器上，Q2 能跑到 27 tok/s，开启 MTP 后达到约 35 tok/s。 这个 fork 仍然能跟上上游。它会执行 `git merge upstream/main`（配合 rerere）加上 parity check，所以 antirez 的修复会持续流入。 整个流程——删什么、留什么、如何同步——都记录在一个叫 StarForge 的仓库里。我有四个这样的“子项目”，每个对应一个模型。StarForge 里没有任何东西依赖 Qwen 或 Metal。如果你想拿到一个针对你的模型或 CUDA 定制的精简版 ds4，只要克隆它，然后用你的 agent 跑一遍检查清单就行。 仓库：sf-q3-8flash，README 里有详细表格。 这套配置只涉及一台机器、一个模型。如果你用的是 Apple Silicon，我很想看看你的数据，最好是和原版 ds4 并排对比。