smolmaxxing 在 1GB 内存设备跑通 16B 模型：十倍提速背后的闪存账与词表裁剪

一台 2013 年发布的初代 iPad Air，搭载双核 Apple A7 处理器和 1GB 内存；一台不带 root 权限的小米电视盒子 S 三代，4 核 Cortex-A55 芯片配 1.9GB 内存，扣除系统占用后可用内存同样只有约 1GB。开源项目 smolmaxxing（作者 hyperionaidev）通过深度修改 llama.cpp，在这两台早已被主流大模型判处死刑的设备上，硬生生跑通了从 260K 到最高 16B 参数的语言模型。这不是单纯的底层算法奇迹，而是一场把内存压榨、闪存预取和模型结构裁剪推到极致的系统工程秀。

在越狱后的 iOS 12.5.7 初代 iPad Air 上，纯 CPU 运行的 1-bit 量化模型 Bonsai-1.7B 达到了 24-26 tok/s 的生成速度（长对话中为 18-22 tok/s），Bonsai-4B 约为 10 tok/s，8B 混合专家（MoE）模型 Moon-Beam-8B-A1B 跑出约 3.5 tok/s，16B 的 Ling-mini-2.0 也能维持在 2.6-4.5 tok/s。而在运行 Android 14 的小米电视盒子上，Qwen3.5-0.8B 达到 16.8 tok/s，Qwen3.5-2B 稳定在 7.7 tok/s，Moon-Beam-8B-A1B 跑出 7.2 tok/s，16B 的 Ling-mini-2.0 达到 5.1 tok/s。

278 MB/s 的闪存死刑与两条逃生通道

端侧跑大模型有两堵绕不开的物理墙，一是内存容量，二是存储带宽。以 llama.cpp 和微软 bitnet.cpp 为代表的开源框架普及了 CPU 低比特量化，但主流优化大多依赖现代 ARMv8.2-A 的 dotprod（整数点积）指令集和 4GB 以上的宽裕内存。当设备只剩约 1GB 可用内存时，稠密模型一旦装不进 RAM，就只能从 eMMC 或 NAND 闪存里实时流式读取权重。

物理定律在这里给出了冷酷的判决。小米电视盒子的 eMMC 闪存读取速度实测最高只有 278 MB/s，单次约 1MB 的随机读取就要耗时约 6 毫秒。如果每生成一个 token 需要从闪存流式读取 1GB 权重，理论生成速度上限就是 0.28 tok/s。这也是为什么电视盒子流式运行 9B 稠密模型 Qwen3.5-9B 时，即便加上多 token 预测（MTP）投机解码，速度也死死卡在 0.27 tok/s。闪存状态甚至会直接左右跑分，在 iPad Air 上，刚拷贝完大文件后立即运行基准测试，速度会比正常状态慢约 3 倍。

要在 278 MB/s 的带宽枷锁下跑出可用速度，smolmaxxing 证明只有两条路可走。

第一条路是把稠密模型压缩到 1-bit，再把系统内存榨干到最后一滴，实现全量驻留。电视盒子运行 1-bit 稠密模型 Bonsai-8B 时，早期把 839MB 放进内存、剩下 0.12GB 走闪存流式传输，真实聊天速度只有 1.21 tok/s。作者随后开启无头模式（headless mode），强制停止安卓桌面启动器与 Google 服务，把可用内存硬撑大，让 962MB 权重完全驻留 RAM 并配合位平面内核，速度立刻跳升至 3.63 tok/s；最后换用 1-bit 查表（LUT）内核与部署修复，才推高到 5.2 tok/s。

第二条路是利用 MoE 架构每次只激活小部分参数的特性，把闪存变成按需翻阅的字典。以 2.6GiB 的 Moon-Beam-8B-A1B 为例，每次生成仅触碰约 1B 权重。在 iPad Air 上，系统只需将 474MB 的非专家主干映射到内存中，其余专家权重放在闪存里按需分页读取（expert pager），并提前一层进行门控预取，将专家缓存未命中率从 13% 压到约 2%。

十倍提速不全靠汇编内核，还有内存腾挪

如果只看成绩单，iPad Air 运行 Bonsai-1.7B 从首次测试的 2.75 tok/s 飙升到 23.7-25.8 tok/s，足足翻了 8.6 倍；电视盒子运行 Qwen3.5-2B 从 0.1 tok/s 涨到 7.7 tok/s，账面增益高达 77 倍。但把功劳全归于底层汇编优化并不准确，这是一套内核重写与系统裁剪组合拳的结果。

针对十年前没有整数点积指令的 Apple A7 芯片，作者确实手写了免乘法和基于基础 NEON 指令的 1-bit 查表（LUT）内核。但这套内核移植到 iPad Air 后，只是把 Bonsai-1.7B 的速度从 2.75 tok/s 提升到了约 11 tok/s。真正把它推上 25 tok/s 的，是后续将语言模型输出头（output-head）放到快速内核上、按行顺序剪枝注意力机制，以及引入单遍采样器（one-pass sampler）。在电视盒子上，作者同样通过融合 Gated-DeltaNet 以及将输出头填充对齐到 65K 等手段，一点点抠出 7% 到 11% 的分段加速。

更严苛的限制在于内存红线。这台 2013 年的 iPad Air 实际可用内存上限只有约 700MB，一旦越界就会触发 iOS 强行重置。为了保住进程，运行较大模型时必须把上下文长度和批大小死死限制在极小的 -c 512 -b 64。在这个紧箍咒下，Bonsai-1.7B 的峰值内存占用（RSS）被控制在 605MB，Bonsai-4B 为 615-682MB，Moon-Beam-8B-A1B 约为 600-625MB，而 16.3B 的 Ling-mini-2.0 甚至被压到了 556-576MB。

跑分背后的手术刀：词表截肢与生成退化

如果把 smolmaxxing 当成可以直接搬进产品的无损加速方案，开发者很快就会踩坑。翻开该项目长达 160 次实验的记录文档，那些亮眼的 tok/s 数字背后，是一连串用模型智力换取速度的妥协。

极限端侧推理没有免费的午餐，每一点提速都在向模型质量收税。

最直接的一把手术刀砍向了输出词表。为了压缩内存占用并加快输出头计算，作者对电视盒子上的 Bonsai 等模型裁剪了输出词表（pruned LM head），例如将输出头砍到 60K 或 65K，部分基准测试还专门抽取常见 token ID 以减少冷嵌入读取。词表截肢带来了一个严重的评估盲区：因为模型根本无法输出被砍掉的词，作者的困惑度（perplexity）测试工具在遇到这些目标词时会直接跳过——在一次全文评估中就跳过了 42 个 token。这意味着账面上漂亮的 bits/byte 质量得分，只代表模型在保留词表上的表现。

在上下文与路由策略上的妥协同样显著。iPad Air 上的 Bonsai-4B 虽然每字节质量得分优于 1.7B 版本，但在 512 的短上下文限制下，每次运行都无法通过作者设定的三问召回测试，且作为后台服务运行时几分钟内就会被 iOS 重置。电视盒子上的 Bonsai-8B 一旦上下文拉长到约 900 tokens，生成速度就会从 5.2 tok/s 掉到 4.0 tok/s。

而在 MoE 模型上，为了少读闪存，作者引入了缓存感知路由（cache-aware routing），强行给已经在内存里的专家加偏置分数。在 iPad 上，把 Moon-Beam 每次激活的专家从 8 个砍半到 4 个，速度确实能涨到约 5 tok/s，但代价是困惑度暴涨 27%；在电视盒子上若进一步砍到 2 个专家，速度能冲上 10.4 tok/s，但生成的文本会彻底变成胡言乱语。更有警示意义的是，困惑度合格不代表模型能正常聊天：电视盒子上的一个 Moon-Beam 配置在困惑度完全可接受的情况下，13 次长文本回答中有 12 次出现退化死循环，最后只能靠在 256 个 token 窗口内强加 1.15 的重复惩罚才勉强压住。

• 风险.smolmaxxing 目前缺乏与微软 bitnet.cpp 在相同未裁剪权重下的严格控制变量对比，也尚未看到外部社区在标准长上下文下的独立复现；机顶盒、路由器等 IoT 硬件团队若想借此在不加 DRAM 的前提下塞入本地语音助手，必须先算清词表裁剪与 512 短上下文带来的指令遵循退化账。

对于开源推理生态而言，这个项目的真正遗产不在于证明 16B 模型能在老平板上日常使用——作者自己也承认，电视盒子上综合体验最好的是 2B 模型，iPad Air 上最实用的是 1.7B 模型，16B 的 Ling-mini-2.0 虽然参数翻倍，但每字节质量得分反而不如 8B 的 Moon-Beam。它真正值得 llama.cpp 等主线社区吸纳的，是那套针对无 dotprod 老旧 ARM 芯片的 1-bit 查表内核，以及把 MoE 模型的闪存 I/O 延迟藏在计算背后的专家分页预取器。