一台 350 亿参数的大模型，在 iPhone 16 Pro 上跑了起来

一台 350 亿参数的大模型，在 iPhone 16 Pro 上跑了起来。 飞行模式，断开 Wi-Fi，关闭蜂窝网络。 没有云端接口，没有远程服务器，没有外接显卡。 88 个词输出完毕，生成速度稳定在每秒 16 个词。 整整一场对话下来，占用的内存峰值只有 1.7 到 1.8 GB。

跑过本地模型的人，第一反应都会觉得这不合常理。 一个 35B 参数的模型，哪怕压缩到 4 位量化，体积也在 23 GB 左右。 而一台 iPhone 16 Pro 的总物理内存只有 8 GB。 iOS 系统的保护机制出了名严格，任何单一应用只要吃掉超过 3 到 4 GB 内存，就会被立刻闪退杀掉。 把一个 23 GB 的庞然大物装进手机，占用的内存还不到 2 GB，系统到底是怎么运转的？

答案藏在半个世纪前的一条计算机底层规律里。 1968 年，计算机学者彼得·丹宁（Peter Denning）提出了一个改变操作系统的概念：工作集（Working Set）。 在计算机体系结构里，运行一个庞大程序，从来不需要把所有代码一口气堆进物理内存。 内存里永远只需要保留处理器当前那几毫秒真正要用到的活跃数据。 剩下的部分，留在慢速存储里。

可过去几年，大模型领域几乎形成了一种思维定势： 想要运行多大参数的模型，就必须买多大容量的物理显存。 因为传统的稠密模型，每生成一个词，都必须把全身所有参数从头到尾扫一遍。 它的工作集，等于它的全部体重。

打破这个死胡同的，是稀疏混合专家（Sparse MoE）架构。 开源框架 Edge0 所挂载的这个 35B 模型，虽然总参数量高达 350 亿，但每次处理一个词，系统只激活其中的 30 亿参数。 剩下的 320 亿参数，在这一瞬间全都在沉睡。 这意味着，模型在任何一个单步推理上的实际工作集，只有整机参数量的不到一成。

既然每次只有一小部分在工作，为什么要把 23 GB 始终扣在昂贵的内存里？ Edge0 把整个模型完整存放在手机的闪存（SSD）中。 物理内存里只保留当前步骤正在运转的那一层。 需要哪一组专家，就通过内存映射直接从闪存里调入。 运行时的峰值内存，直接被拉低到了 1.8 GB。

但这套逻辑里藏着一个致命的物理瓶颈：闪存读取延迟。 如果处理器每走一步，都要原地等待闪存把下一批专家数据搬进内存，芯片就会陷入漫长的停顿。 生成速度会跌到每秒一两个词，根本无法实际使用。

这台机器最精巧的齿轮，叫预测路由（Prerouter）。 系统训练了一个轻量级的预测头，专门提前预判下一步将要调用的专家网络。 当芯片还在计算当前层的数据时，闪存控制器已经在后台悄悄把下一层需要的专家参数预取到了内存中。 数据搬运与矩阵计算在时间上完全重叠。 等待的停顿被彻底抹平。 原本卡死吞吐量的读取断层消失了，生成速度提升了接近 60%，在手机上跑出了每秒 16 个词。 再加上针对 4 位量化进行蒸馏补偿的 Recover-LoRA，模型的推理质量几乎没有打折。

长久以来，硬件厂商把内存容量当成最暴利的价格阶梯，多给 8 GB 内存就要加价上千元。 云端巨头也用算力壁垒把用户牢牢绑在月付订阅里，声称端侧设备只能跑玩具。 当算法的工作集与硬件的物理内存彻底解耦，这套商业假设开始出现裂痕。 掌上设备的智能上限，不再被出厂时焊死的内存容量所锁死。 当计算与存储流转的齿轮咬合得足够严密，算力就真正回到了每个人的口袋里。