llama.cpp的补丁集，让显存装不下的MoE都提速，最高3.3倍

大模型的参数摆在那儿，显存不够就是跑不动。MoE 模型更别扭：一次推理只走一部分专家，可这些专家得先在显存里待着。tandem.cpp 处理的就是这个矛盾。

它是 llama.cpp 的一个补丁集，不是另一套推理引擎。做法不复杂：调用最频繁的专家留在 GPU 上，用得少的交给 CPU。llama.cpp 支持的 MoE 模型都能套这套逻辑。项目自己写明了目标——单用户解码，一个人对着电脑聊天、写代码，不追多并发吞吐。

测试机是一台消费级配置：i5-12400F、64 GB DDR4、RTX 4090。Qwen3.8-Flash-Next 的 IQ3_S 量化版加 MTP，贪婪解码从 llama.cpp 的 29.8 tok/s 到 97.3 tok/s，3.3 倍。换成 Qwen 默认采样，29.4 到 96.1 tok/s，也是 3.3 倍。每秒接近 100 个 token。

gpt-oss-120b 的幅度小一截：贪婪解码 27.8 到 51.5 tok/s，1.85 倍；推荐采样参数下 27.7 到 48.0 tok/s，1.73 倍。

只有 Qwen3.8 做过调优。其他装不进显存的 MoE 也能拿到 1.4 到 2.1 倍，名单上有 gpt-oss-120b、GLM-4.5-Air、Qwen3.6-35B-A3B、DeepSeek-V4.1。64k 的长提示词，提示处理快 1.4 到 1.8 倍，读长文档时这段等待会短很多。

对照组是 Strata。精确模式下它把每个被路由到的专家都算一遍，口径跟 llama.cpp 一致，103.6 tok/s。默认模式跳过低排名专家，更快但是近似结果，127.1 tok/s。

评论区反复出现的一个问题：llama.cpp 自己不是已经有专家缓存了。有人指出原生 --moe-cache-mib 参数从 PR #29887 起就在，能把用得到的专家缓在显存里。tandem.cpp 跟它的差别在哪，没看到正面回答。这个空白不小——如果原生参数收益接近，多打一个补丁的意义就得重新算。

Strata 被反复提起。有评论说它存在更久，一直在修 bug，也有社区贡献，所以可能做得更好。还有人提到它有四千多个 fork。这些都是评论者的判断，不是跑分结论。也有人建议拿 ik_llama.cpp 横向比一次，同样没看到结果。

硬件问题问得很具体。有人只有 32 GB DDR5 加一张 4090，问能不能用；有人是 5090 配 32 GB；有人直接问 AMD RDNA3；还有人问只支持 CUDA 还是也有 ROCm、Vulkan。公开答复一条都没有。64 GB DDR4 的测试机说明内存在这套方案里不是配角——CPU 侧要放的东西不少，32 GB 撑不撑得住同样的模型，现在不知道。

项目公布了四台机器的完整结果，构建和运行命令都在 GitHub 上，但四台机器的具体配置没在摘要里列出来。

还有人问能不能接 LM Studio、unsloth desktop 这类前端。补丁集理论上顺着 llama.cpp 的接口走就行，项目本身没提集成方案。另有评论怀疑这套引擎的界面成熟度，觉得算不上经过充分测试的接口。

项目页写了一句：独立项目，与 ggml-org 无关。它也没走上游合并这条路。有评论依稀记得上游 llama.cpp 刚合过功能类似的 PR，置信度不高，也没人跟进确认。如果上游真做了同样的事，补丁集的维护成本会立刻变成实际问题。