Maple：20B端侧跑出120t/s

截至 2026 年 8 月 5 日，DeepGrove 公布了 Maple-Preview：一个采用三元权重、总参数量 200 亿的混合专家模型，并宣称其在 iPhone 上的生成速度可达 120 tok/s。这个数字已经不是“手机勉强能跑大模型”，而是接近云端流式服务的体感速度。

**Maple-Preview 是一个面向端侧推理的 20B 稀疏混合专家模型，其核心思路是用三元权重降低模型体积，再用 MoE 减少每个 token 实际参与计算的参数量。**这两个技术单独拿出来都不新，但把它们组合到 iPhone，并给出 120 tok/s 的演示结果，仍然值得关注。

不过，Maple-Preview 目前最准确的定位仍然是一次技术预览，而不是已经完成质量、兼容性和能耗验证的成熟模型产品。官方展示了一个很有冲击力的速度数字，但截至发稿，公开材料还不足以回答硬件型号、上下文长度、首 token 延迟、活跃参数量、持续功耗和模型跑分等关键问题。

120 tok/s 到底是什么水平

**Token 每秒（tok/s）是模型进入逐 token 解码阶段后，每秒生成多少个文本单元的指标。**英文中的一个 token 通常约为 0.75 个单词，中文则经常接近一个汉字，但具体比例会受到分词器影响，因此 tok/s 不能直接等同于“每秒生成多少字”。

**120 tok/s 已经明显超过普通用户阅读文本的速度。**即使按照中文一个 token 接近一个汉字粗略估算，模型每秒也可能输出上百个字符；在聊天界面里，用户通常不会等待文本逐字出现，前端反而可能需要主动限制渲染速度。

**Maple 的 120 tok/s 更可能代表解码吞吐，而不一定代表完整交互延迟。**一次真实请求至少包含提示词预填充、首 token 等待和后续解码三个阶段：长文总结可能卡在预填充，简单聊天更在意首 token 延迟，120 tok/s 只直接描述最后一个阶段。

这也是目前最需要补齐的测试口径。假如演示使用短上下文、单轮对话和较低温度，120 tok/s 很有说服力；但如果换成 8K、32K 甚至更长上下文，KV Cache 占用和内存带宽压力都会迅速上升，实际速度未必还能保持在同一水平。

三元权重先解决“装不下”

**三元权重是把模型权重限制在 -1、0、+1 三种取值附近的低比特表示方式。**从信息论角度看，三个状态最低只需要约 1.585 bit 表示，因此三元模型也经常被称为 1.58-bit 模型。

**三元化首先解决的是 20B 模型的存储问题。**一个 200 亿参数模型如果采用 FP16 权重，仅权重就需要约 40GB；即使压到常见的 4-bit，理论体积仍接近 10GB，这还没有算量化比例因子、模型结构、KV Cache、运行时缓冲区和操作系统占用。

按照 1.585 bit 粗略计算，200 亿个三元参数的原始信息量约为 3.96GB。实际文件通常还要保存分组尺度、元数据和非三元层，因此不能简单宣称模型一定只有 3.96GB，但它确实有机会进入现代高配 iPhone 的统一内存预算。

| 20B 模型权重形式 | 理论每参数位数 | 仅权重理论体积 | 在手机上的主要问题 | |---|---:|---:|---| | FP16 | 16 bit | 约 40GB | 基本无法常驻内存 | | INT8 | 8 bit | 约 20GB | 仍远超多数 iPhone 可用内存 | | 4-bit 量化 | 4 bit | 约 10GB | 还需为系统、KV Cache 和运行时留空间 | | 三元权重 | 约 1.585 bit | 约 3.96GB | 有机会装入内存，但依赖专用编码和算子 |

**三元模型真正难的部分不是把文件压小，而是让硬件高效执行。**现有移动 GPU、CPU 和神经网络加速器主要围绕 FP16、INT8、INT4 等规则数据类型设计，三元权重如果需要先解包、转换再计算，省下的内存流量可能会被额外指令开销吃掉。

Maple-Preview 能做到 120 tok/s，意味着其价值大概率不只在权重格式，还在于针对三元矩阵运算设计了足够高效的内核、权重布局和缓存策略。不过，公开预览尚未完整说明它主要使用 iPhone CPU、GPU 还是 Neural Engine，也没有披露三元权重是否会在计算阶段转换成其他格式，这些信息决定了结果能否被第三方复现。

MoE 再解决“算不动”

**混合专家模型（Mixture of Experts，MoE）是一种每次只激活部分专家网络、但保留较大总参数容量的稀疏架构。**20B MoE 的“20B”通常表示模型拥有约 200 亿总参数，并不意味着每生成一个 token 都要把 200 亿参数完整计算一遍。

**MoE 的路由器会根据当前 token 选择少数专家参与计算。**如果一个模型拥有多个前馈专家、每个 token 只选择其中一个或两个，那么它可以保留较高的总容量，同时把单 token 计算量压到远低于同规模稠密模型的水平。

这也是 Maple 宣称速度能够成立的第二个关键。三元权重把需要搬运的数据变少，稀疏 MoE 把需要参与计算的权重变少，两者同时降低端侧推理最敏感的内存带宽压力。

| 架构方案 | 总参数量 | 单 token 参与计算量 | 权重常驻压力 | 端侧推理特点 | |---|---:|---:|---:|---| | 20B FP16 稠密模型 | 20B | 接近 20B | 约 40GB | 装不下，计算量也过高 | | 20B 4-bit 稠密模型 | 20B | 接近 20B | 约 10GB | 体积下降，但每 token 仍需读取大量权重 | | 20B 三元稠密模型 | 20B | 接近 20B | 理论约 3.96GB | 能装下不等于能快速计算 | | Maple-Preview 三元 MoE | 20B 总参数 | 尚未公布 | 理论显著降低 | 同时利用低比特与稀疏激活 |

**Maple 当前最重要的缺失数据是每个 token 的活跃参数量。**一个总参数 20B、活跃参数 2B 的 MoE，与一个总参数 20B、活跃参数 8B 的 MoE，虽然都能写成“20B MoE”，实际计算成本却可能相差数倍。

MoE 也不是免费的午餐。路由分布不均会造成部分专家过载，专家之间频繁切换会破坏缓存局部性，而端侧设备又没有服务器集群常见的高带宽互联；如果模型为了速度只激活很少的专家，还可能牺牲复杂任务中的知识覆盖和推理稳定性。

手机推理的瓶颈往往不是算力

**端侧大模型的主要瓶颈通常是内存容量和内存带宽，而不是芯片标称算力。**自回归模型每生成一个 token，都要访问大量权重；当 batch size 为 1 时，很多计算单元没有足够数据可以并行，推理过程更像是在持续搬运权重，而不是进行高密度矩阵计算。

一个简化估算可以说明问题：如果某模型每个 token 实际需要读取 4GB 权重，而设备可持续提供 100GB/s 的有效带宽，那么仅权重读取的理论上限也只有约 25 tok/s。要达到 120 tok/s，就必须继续减少每 token 的权重读取量、提高缓存命中率，或者让部分权重以更紧凑的格式直接参与计算。

**三元 MoE 的组合正好针对内存墙下手。**三元权重减少每个参数占用的字节数，MoE 减少每个 token 必须访问的专家数量，这比单纯追求更高的 TOPS 数字更符合手机端单用户推理的真实负载。

作为参照，llama.cpp 已经证明量化、内存映射和针对 Metal 的算子优化，可以让大量语言模型在消费级设备上运行；苹果开源的 MLX 则展示了统一内存架构下延迟计算和设备协同的优势。Maple 如果能把三元稀疏算子进一步做到移动端可复现，它的意义会超过单个模型本身。

120 tok/s 还不能证明模型“好用”

**推理速度与模型能力是两条不同的坐标轴。**一个模型可以生成得很快，但在指令遵循、代码生成、数学推理、长上下文检索和事实准确性上表现一般；反过来，能力较强的模型也可能因为参数激活量更大而运行更慢。

Maple-Preview 目前没有在公开材料中给出足够完整的标准化能力评测。开发者至少需要看到 MMLU-Pro、GPQA、GSM8K 或 AIME、HumanEval 或 LiveCodeBench、IFEval，以及长上下文检索测试，才能判断它更接近“手机上的实用助手”，还是偏向展示底层推理技术的概念验证。

**三元训练还可能带来比普通后训练量化更复杂的质量问题。**如果模型从训练阶段就约束为三元权重，它有机会学习适配低比特表示；如果从高精度模型直接压缩，则可能在少见知识、长链推理和细粒度概率分布上出现更明显损失。

MoE 的质量同样取决于路由训练。一个稳定的 MoE 不只要让专家各有所长，还要避免大量 token 被错误路由到不合适的专家；在极低比特条件下，路由器和注意力层是否保留更高精度，也会直接影响最终表现。

对开发者真正有用的是什么

**Maple 最现实的价值是把 20B 级模型带进离线、低延迟和隐私敏感场景。**如果它最终能在手机上稳定运行，会议摘要、本地知识库检索、邮件改写、代码片段补全和个人数据分析都可以减少对网络连接的依赖。

端侧运行还意味着更可控的边际成本。云端推理需要持续支付算力费用，而手机模型的主要成本转化为一次下载、存储空间、电量和设备发热；对于高频、短文本、个人化任务，这种成本结构可能更合理。

**Maple 暂时还不适合被理解为旗舰云模型的直接替代品。**20B 总参数、低活跃参数和三元权重更像是在“容量、速度、内存”之间做激进取舍，它最有可能先替代小型端侧模型和部分云端轻任务，而不是直接挑战最强闭源推理模型。

开发者接下来应重点关注以下六项数据：

1. 具体硬件型号：是普通版 iPhone、Pro 版，还是拥有更大内存的新一代机型。
2. 活跃参数量：每个 token 实际调用多少专家、参与多少参数计算。
3. 上下文口径：120 tok/s 是在多长提示词、多少 KV Cache 占用下测得。
4. 首 token 延迟：模型加载、提示词预填充和首次生成分别需要多久。
5. 持续性能：连续运行 5 分钟或 10 分钟后，是否因温控而明显降频。
6. 模型质量：三元化和稀疏路由是否在标准基准与真实任务中保住能力。

Maple 的方向比数字更重要

**Maple-Preview 最值得记住的不是单独的 120 tok/s，而是端侧大模型优化正在从“把模型量化到 4-bit”转向“模型架构与硬件共同设计”。**当低比特训练、稀疏专家、专用内核和统一内存被一起考虑时，过去看似只能放在服务器上的参数规模，确实可能进入手机。

120 tok/s 是一个足够吸引眼球的起点，但它还不是完整结论。只有当 DeepGrove 公布可复现测试、模型能力跑分、设备功耗和持续性能后，Maple 才能证明自己不是一次精心挑选场景的演示，而是一套可以推广到真实应用的端侧推理方案。

如果后续结果站得住，Maple 的竞争对象甚至不只是其他 20B 模型。它真正挑战的是一个长期默认前提：高质量生成必须把用户数据发送到数据中心，而手机只能运行 1B 到 7B 的缩水模型。

参考来源

• llama.cpp GitHub 仓库：消费级硬件上的量化模型推理、Metal 加速与内存优化参考。
• Apple MLX GitHub 仓库：苹果统一内存架构上的机器学习框架与执行机制参考。
• Hugging Face：Mixture of Experts 介绍：MoE 路由、专家激活和稀疏计算原理说明。
• Hugging Face Transformers 量化文档：低比特权重与常见模型量化方案参考。