一个 200 亿参数的推理模型，跑在 iPhone 上每秒生成 127 个 token，在 Mac mini M4 上达到 218 tok/s。DeepGrove 最新发布的 Maple-Preview——一个原生三值权重（ternary-weight）训练的 20B-A1B MoE 模型，完整权重只有 5.31 GB。
三值权重：把乘法变成加法
传统量化路线的逻辑是：先用全精度（FP16/BF16）训练一个模型，再用 PTQ（训练后量化）或 QAT（量化感知训练）把它压到 4-bit、2-bit。问题是，压缩后的模型性能总会打折——一个 BF16 下 85 分的模型，压到 2-bit 可能只剩 60 分。
Maple-Preview 走了一条不同的路：直接在 2-bit 三值精度下训练。每个权重只有三种取值：{-α, 0, +α}，其中 α 是每行独立学习的缩放因子。在这种精度下，矩阵乘法中的浮点乘运算可以被整数加法替代——权重是 +α 就加上输入向量，是 -α 就减去，是 0 就跳过。这把推理的算术负担降低了一个数量级。
DeepGrove 在 model card 中明确阐述了这一设计哲学：「模型运行的精度应当是它训练的精度」。他们认为，先训练再压缩的方法从根本上限制了性能上限和架构自由度——你不仅要承受精度损失，还要被迫适配全精度模型遗留的架构约束。
架构设计：为推理速度而生
Maple-Preview 的架构配置体现了明确的硬件感知设计：
| 参数 | 配置 |
|---|---|
| 总参数量 | 20.2B |
| 每次推理激活参数 | 1.49B |
| 层数 | 24 |
| 专家数 | 256 |
| Top-K 路由 | Top-8 |
| 注意力机制 | 混合滑动窗口 + 全局注意力 |
| 上下文长度 | 131,072 tokens |
| 权重精度 | 2-bit 三值（每行一个 α 缩放因子） |
| 检查点大小 | 5.31 GB |
几个关键设计决策值得展开：
24 层 + 256 专家（而非 30 层 + 224 专家）。DeepGrove 在开发过程中测试了多种配置，最终选择了更浅但更宽的架构。更少的层数意味着更少的顺序计算（推理时的主要瓶颈），更多的专家则通过稀疏激活保持模型容量。每次推理只激活 256 个专家中的 8 个，即 1.49B 参数参与计算。
混合滑动窗口注意力。每 4 层中有 3 层使用 512-token 的滑动窗口注意力，1 层使用全局注意力。这种设计在保持长距离建模能力的同时，将 KV-cache 的内存增长限制在线性范围内。在 131K token 的完整上下文下，Maple 的总内存占用约为 7.5 GB（模型权重 + KV-cache），远低于 16 GB 的 Mac mini 内存上限。
FlashHead 加速。这是 DeepGrove 在 mlx-lm fork 中实现的独特优化。标准语言模型在生成每个 token 时需要计算完整的 logits 向量（词表大小 × hidden dim），然后做 softmax 选出下一个 token。FlashHead 用 k-means 聚类将词表分为约 4748 个簇，推理时只对 top-512 个簇的中心做精确打分，再在候选簇内做精确搜索。这将输出头的计算量降低了约 80%，代价是约 2 分钟的一次性 k-means 预处理。
Benchmark：在同量级中领先
DeepGrove 公布的评测覆盖四个推理 benchmark：
| 模型 | LCBv6 | AIME 2026 | HMMT 2026 | GPQA-D | 平均 | 总参数 | 激活参数 |
|---|---|---|---|---|---|---|---|
| Maple-Preview | 75.1 | 87.5 | 78.8 | 73.5 | 78.7 | 20.2B | 1.49B |
| Maple-Preview (Flash) | 75.6 | 85.8 | 80.3 | 69.2 | 77.7 | 20.2B | 1.49B |
| Qwen3.5 35B-A3B | 74.6 | 91.1 | 81.8 | 84.2 | 82.9 | 35B | 3B |
| GLM 4.7 Flash | 64.0 | 89.2 | 81.1 | 75.2 | 77.4 | 30B | 3B |
| Ternary Bonsai 27B | 77.9 | 87.5 | 74.2 | 68.9 | 77.1 | 27.3B | – |
| Qwen3 30B-A3B | 66.0 | 88.3 | 78.8 | 73.4 | 76.6 | 30.5B | 3.3B |
| Qwen3.5 9B | 65.6 | 86.7 | 71.2 | 81.7 | 76.3 | 9B | – |
| GPT-OSS 20B | 74.6 | 90.0 | 68.9 | 71.5 | 76.3 | 20.9B | 3.6B |
| LFM2 24B-A2B | 21.9 | 23.2 | 17.4 | 47.0 | 27.4 | 24B | 2B |
Maple-Preview 以 78.7% 的平均分在同等参数规模（20B 级别）中领先。Qwen3.5 35B-A3B 以 82.9% 的平均分排在第一，但它的总参数量是 Maple 的 1.75 倍，激活参数是 2 倍，且需要 4-bit 量化才能在设备上运行。Maple-Preview 在原生三值精度下就达到了接近的水平。
在 AIME 2026（美国数学邀请赛）上，Maple-Preview 拿到 87.5 分，仅比参数量翻倍的 Qwen3.5 35B 低 3.6 分。DeepGrove 还演示了 Maple-Preview 在 MacBook Pro M5 Pro 上以 281.5 tok/s 的速度完整解答 IMO 2024 第一题（满分 7/7），整个推理过程不到 30 秒。
需要注意的局限：DeepGrove 自己承认这是一个专注于纯推理能力的预览版，在 agentic benchmark（工具调用、代码执行等任务）上表现不佳。他们计划在正式版中通过扩展训练来补齐。
iPhone 上的 127 tok/s 是怎么做到的
DeepGrove 在 iPhone 上对比了 Maple-Preview 和 Ternary Bonsai 27B（Qwen3.6 27B 的三值量化版）。同样是做一道胡萝卜蛋糕的食谱，Maple-Preview 在约 10 秒内完成回复（127 tok/s），Bonsai 27B 在 6 分钟后仍在生成（9.6 tok/s）——13 倍的差距。
造成差距的核心原因有三层：
第一层是激活参数量。Maple-Preview 每次推理激活 1.49B 参数，Bonsai 27B 虽然也是 MoE 架构但激活参数更多。在移动设备上，内存带宽是主要瓶颈，激活参数越少，需要从内存读取的数据越少。
第二层是层数。Maple 只有 24 层，更少的层意味着更短的顺序计算链。Transformer 推理时每生成一个 token 都要完整跑一遍所有层，层数直接影响延迟。
第三层是 FlashHead。标准输出头在词表很大时（Maple 的词表未公开，但通常在 10 万-25 万之间）会成为显著的开销。FlashHead 将这一步的计算量压缩到原来的 20% 左右。
在 Mac mini M4 上的实测数据（来自 GitHub README）：
| 芯片 | 输出头 | 解码速度 (tok/s) | Prefill 速度 (tok/s) | 峰值内存 |
|---|---|---|---|---|
| M4 | 标准 | 169 | 1075 | 6.51 GB |
| M4 | FlashHead | 218 | 1075 | 6.69 GB |
| M5 Pro | 标准 | 359 | 3773 | 6.73 GB |
| M5 Pro | FlashHead | 395 | 3857 | 6.92 GB |
本地运行指南
Maple-Preview 的权重已在 HuggingFace 上开源（deepgrove/maple-2bit-mlx），运行环境基于 Apple Silicon 的 MLX 框架。DeepGrove 提供了一个 mlx-lm 的 fork，包含 Maple 模型定义和 FlashHead 支持。
# 环境要求：Apple Silicon Mac + uv 包管理器
git clone https://github.com/deepgrove-ai/mlx-lm-deepgrove.git
cd mlx-lm-deepgrove
./setup.sh
source .venv/bin/activate
# 下载权重（约 5.3 GB）
hf download deepgrove/maple-2bit-mlx --local-dir maple-2bit-mlx
# 单次生成
python -m mlx_lm generate --model ./maple-2bit-mlx --trust-remote-code --flash-head \
--prompt "Write a haiku about a grove." --temp 1.0 --top-p 0.95 --top-k 20
# 交互式对话
python -m mlx_lm chat --model ./maple-2bit-mlx --trust-remote-code --max-tokens -1 \
--temp 1.0 --top-p 0.95 --flash-head--flash-head 参数启用 FlashHead 加速。需要注意的是，当前的 mlx-lm fork 使用的是 MLX 标准构建（为保证可移植性），DeepGrove 表示将在近期发布更快的自定义库。
权重转换工具也包含在内，支持将 BF16 的 Maple 权重流式转换为三值格式，过程中不需要将 38 GB 的源模型完整载入内存：
python -m mlx_lm.ternary /path/to/maple-bf16 -o maple-2bit-mlx --flash-head端侧自适应学习：一个有趣的方向
Maple-Preview 还展示了一个实验性功能：端侧权重自适应。在演示中，用户提到自己有素食饮食习惯后，模型在夜间自动生成训练数据并对自身权重做微调（约 10-20 分钟，峰值内存 5.9 GB）。第二天，当用户询问皮革包推荐时，模型给出了合成材料的替代建议。
作为对比，同样场景下的 Claude Sonnet 5（开启记忆功能）未能将素食偏好泛化到皮革制品的推理上。
这个功能目前还处于早期实验阶段，但它指向了一个有潜力的方向：当模型足够小、足够快时，个性化的权重级学习在消费设备上变得可行。DeepGrove 将这一机制称为「dreaming」——模型在空闲时根据用户交互自动生成数据并训练自身。
这意味着什么
Maple-Preview 的核心贡献在于证明了三值权重训练可以产出高质量的推理模型。在此之前，1-bit/2-bit 量化模型要么性能严重下降（如 LFM2 24B-A2B 在 benchmark 上平均只有 27.4%），要么需要大幅增加参数量来补偿精度损失。Maple-Preview 以 20B 的总参数量、1.49B 的激活参数，在推理 benchmark 上达到了 35B 模型的水平。
对于端侧 AI 部署而言，这意味着：
内存门槛大幅降低。5.31 GB 的检查点可以在 8 GB 内存的设备上运行（含操作系统开销），16 GB 设备可以同时处理 131K token 的长上下文。相比之下，同级别的 4-bit 量化模型通常需要 12-15 GB 的模型内存。
推理延迟接近实时。在 M4 Mac mini 上 218 tok/s 的速度意味着一个 500 token 的回复在 2.3 秒内生成完毕。在 iPhone 上的 127 tok/s 也远超人类阅读速度（约 5-8 tok/s）。
能耗优势。三值权重的加法运算比浮点乘法能耗低得多，这对电池供电的移动设备至关重要。DeepGrove 没有公布具体能耗数据，但算术运算量的减少直接转化为功耗的降低。
当然，Maple-Preview 还是一个预览版。它的 agentic 能力未经充分训练，通用对话质量可能不如经过大量 RLHF 的商业模型，推理能力也还有提升空间（GPQA-D 上 73.5% 的得分说明科学推理仍有短板）。但作为一个技术验证，它清晰地展示了三值权重训练路线的潜力：低精度不一定是性能的妥协，如果从一开始就将效率作为架构设计的第一原则。
来源：DeepGrove Maple-Preview Model Card · GitHub: deepgrove-ai/mlx-lm-deepgrove · Hacker News 讨论