我给Mference加上了Maple-Preview：Air M4上仅用500MB内存跑出40tps生成速度
我喜欢运行本地模型的想法，但不喜欢它们吃掉我所有内存。我一直认为，构建边缘模型的最佳方式是让模型足够聪明以对数据进行推理，但不需要拥有太多自身知识。当网络搜索和工具调用如此容易设置时，模型为什么要随身携带所有这些知识？我在AIRI的前同事也有类似想法，构建了Optimal Cognitive Core，我之前写过：这是Qwen3-0.6B和Qwen3-1.7B的微调推理版本，专门优化用于外部上下文和RAG。从硬件角度看，它们相当接近我想要的。权重在原生BF16下分别占用1.2GB和3.4GB，再加上大致相同数量的长上下文——因为这是带GQA的Qwen3，而非那些时髦的混合架构。所以，抱一点乐观态度的话，它们能装下。问题是这些模型对于通用任务来说实在太小了。它们仍然是600M和1.7B的稠密模型。在这个规模下，你通常得到的是有趣的鹦鹉，经过微调后可以改写文本或做简单分类任务，但仅此而已。
把模型塞进我的MacBook Air M4的下一个方法是量化。PrismML用Bonsai-27B做了一些有趣的事情，它是Qwen-3.6-27B的二元和三元量化。这个27B模型的三元版本在推理运行时只需7.2GB内存，而且确实能在Mac上运行。不幸的是，Qwen-3.6-27B是一个稠密模型，所以它在我机器上慢得令人痛苦。根据我在网上能找到的数字，生成速度大约13–14 tokens/s，提示处理100–150 tokens/s。它也是QAT——甚至可能是PTQ；目前没有太多细节——而且很可能该优化并非专门为保留模型的多语言能力而设计。因此，一旦超出校准集/QAT训练分布，我不会期待特别有趣的行为。
然后，几乎紧随Bonsai之后，Maple Preview出现了。它是一个20B A1B MoE，专门为Mac上高效本地推理而设计。更重要的是，他们从一开始就围绕这一目标设计架构，并以三元精度从头训练模型。这不是别人模型的量化版本。结果是一个5.31GB的模型，加上131K上下文约7.5GB——几乎比二元的Bonsai量化小1.5倍——据报道在M4 Mac Mini上生成速度达到218 tokens/s，在iPhone上为127 tokens/s（具体是哪款iPhone尚不清楚）。
除了英语之外，这个模型几乎不懂其他语言，其世界知识总体上也相当有限——例如，它会搞不清Psycho Mantis来自哪个游戏。但给它网络搜索，它能相当好地回答简单问题。DeepGrove不发布工具调用基准测试，原因也不难猜。我自己运行了Tau-2，使用Qwen3-235B-A22B-Instruct-2507作为用户模拟器。我得到：Airline 0.48；Retail 0.175；Telecom 0.427。它不是Sonnet，也绝对不是Qwen。但话说回来，它叫Maple Preview，作者也明确表示计划进一步训练它用于agentic工作负载。
然而，即使有量化的所有优势，7.5GB几乎是我可用内存的一半。所以还有第三种降低内存使用的方法：将所有权重放在SSD上，从磁盘流式传输MoE专家。已经有turbo-fieldfare，它在Mac上运行Gemma-4-26B，仅用约2GB内存；还有Mference，turbo-fieldfare的一个fork，增加了对Qwen-3.6-25B、DeepSeek V4 Flash和Inkling-Small 276B的支持。它确实使用很少内存，但代价是生成速度和提示处理速度都降至每秒几十个tokens。Apple似乎在其新Siri工作中做了类似的事情，尽管他们似乎为整个提示激活专家，而不是像这些框架那样逐token路由。
这就引出了一个有趣的想法：如果我们把Maple Preview——它极其高效、使用微型专家、并以三元精度从头训练——加入Mference会怎样？理论上，我们应该能进一步降低内存使用，同时保持相当好的生成速度，因为Maple的架构正是针对这类环境优化过的。于是我就这么做了。
多亏Codex和我200美元的订阅，在花费约20小时和30%的周限额之后，我在Edgar Allan Poe《乌鸦》上的teacher-forced top-10 token上达到了与官方实现相当的结果。根据上下文长度不同，模型现在使用500到1,200MB内存（！）。在我的MacBook Air M4上，它处理提示约40 tokens/s，生成约20 tokens/s。它能调用工具。它能生成文本。在这样的占用下，我真的不介意让它一直在后台运行。它几乎不消耗什么。它可以就待在那里，当我有需要时，我可以问它。我稍后会把集成提交到上游，但你现在已经可以从我的GitHub fork运行它了。
那么这实际上有什么用处？我认为对于这类模型有两种不同的操作模式。第一种是交互式聊天。在那种模式下，你想要快速响应和低延迟。第二种是后台模型，几乎不用内存，不碍事，同时持续做有用工作：分类消息、扩展知识图谱、过滤邮件、写摘要、在网络上慢慢研究东西，等等。在第二种模式下，延迟几乎无关紧要。对于这类工作负载，20 tokens/s完全够用。当你需要切换回交互模式时，只需将整个模型从SSD加载到RAM——只需几秒钟，所以它是无缝的。如果模型能使用工具——Maple Preview目前还不擅长，但再说一次，它是Preview——你可以构建没有硬延迟要求的agentic管道，同时让一个智能助手即使在旧手机上也能永久离线可用，我觉得这太棒了。
如果未来是本地化的，我会非常高兴。
代码：
[https://github.com/chameleon-lizard/Mference/tree/feature/maple-integration6
DeepGrove还有一篇超有趣的文章解释他们如何设计模型：
[https://deepgrove.ai/maple-inference7
—— 高票评论（帖子共5条讨论）——
[+2] u/netikas：免责声明：本帖由ChatGPT从俄语翻译而来。我不是英语母语者，但我检查过译文，似乎没问题。
[+1] u/Revolutionary_Key50：你在这类小型激活MoE中遇到的kernel-launch/TP同步瓶颈值得明确指出：一旦激活权重集变得足够小，解码就不再受带宽限制，而是受延迟限制——无论如何，每一步都在为kernel启动+同步开销付出代价，不管你实际移动了多少字节。纯roofline模型（时间=字节/带宽）在这种状态下会系统性高估吞吐量，因为它没有下限。Maple-Preview的20B-A1B形状正好处于这个区域。
另外，对于任何在其它统一内存设置上复现这一点的人，值得注意：LPDDR在实际中达到其额定峰值带宽的比例明显低于HBM/GDDR，所以天真地将规格表带宽数字代入粗略估算，在Mac/DGX-Spark级硬件上会比在独立GPU上更严重地高估实际吞吐量。
[+1] u/Aaaaaaaaaeeeee：这是一篇深思熟虑的好帖子！我想知道是否可能实现更强的提示处理？100 tokens/s是语音TTS流水线用例的理想速度，要达到这个速度才能感觉像实时。如果平均提示是50个token，那就是半秒。理想情况下，这种磁盘混合可以推动当前移动设备上甚至更大规模（100B+）的模型。只是还没有优化。也许我会拿DeepSeek Flash来玩玩，用lite-rt（用于Android GPU）运行Maple。