一个开发者做了件挺唬人的事:把一个42GB的大模型,塞进4.3GB内存里跑起来,还让它第一次在iPhone上原生运行。这个项目叫Swiftlet,专门给苹果设备写了一套Swift+Metal推理引擎,目标是Qwen3-Next和Qwen3.5/3.6这几个MoE混合架构的模型。听起来像本地大模型部署的又一次突破,但把它的模型卡片、README和代码逐字看一遍,会发现至少有两个关键数字,经不起细究——不是造假,是没把测量方法讲清楚。
一张漂亮的表,压不住的疑问
先看数字本身。
| 模型 | 磁盘占用 | 峰值内存 | 解码速度 |
|---|---|---|---|
| Qwen3-Next-80B-A3B(4bit) | 42GB | 4.3GB | 4.5–5.3 tok/s |
| Qwen3.6-35B-A3B(4bit) | 18GB | 2.6GB | 7–11 tok/s |
| 35B跑在iPhone 17上 | — | 2.5GB | 约1 tok/s |
能做到这一步,靠的是MoE架构的一个特性:每个token只激活一小部分专家参数,80B模型每次真正参与计算的只有约3B。Swiftlet把常驻不变的dense核心(注意力、路由器、共享专家)一直留在内存里,剩下成千上万个专家权重打包成固定大小的模块,按需从硬盘一次性读取,不走mmap。这就是磁盘42GB但内存只要4.3GB的机制来源。
"4.3GB峰值内存",谁量的、怎么量的
这套机制本身没问题,MoE本来就该这么用。问题在数字的来路。
翻遍Swiftlet的命令行代码,它输出的统计只有解码吞吐量和专家缓存命中率,并没有"峰值内存"这一项。也就是说,README表格里那个最抓眼球的4.3GB/2.6GB,是通过什么工具测的、测的是进程RSS还是系统整体压力、用的哪台M5、哪版系统、跑了几次、有没有预热——这些统统没写。
耳听为虚,眼见为实。在独立复现出来之前,这个数字只能算开发者自述的初步测量,不是可以直接拿来横向比较的基准分。
iPhone上的1 tok/s,不是当初说的那个数
第二个疑点更具体。项目早期的手机文档曾基于NAND带宽理论估算,iPhone上能跑到3–5 tok/s。实测结果是约1 tok/s,首条回复大概要等半分钟。这不是造假,是纸上谈兵撞上了真实世界:调度开销、存储实际带宽、手机的温控降频,任何一个环节都会把理论值打回原形。
- 风险.把"理论上限"和"已验证结果"混着看,是这类工程新闻最容易踩的坑。
作者自己也承认,当前解码循环是"dispatch bound"而不是"IO bound",意思是瓶颈在调度而不是硬盘读取速度——这句话反过来说明,内核层面还有明显的优化空间,但也说明1 tok/s目前就是能拿到手的真实数字,不是暂时的短板。
专家流式加载不是新发明,新在哪
把Swiftlet放进整条技术谱系里看,会更清楚它到底做对了什么。llama.cpp靠mmap把模型映射进内存,理论上也能在有限RAM下跑,但它不感知MoE路由,内存不够时容易出现随机访问导致的页面抖动。AirLLM、PowerInfer此前已经验证过"存储换内存"这条路,但没人在苹果生态、尤其是手机端把MoE专家流式加载和缓存策略做成能落地的工程。
- 结论.Swiftlet真正的创新点是MoE路由感知的专家缓存,不是"流式加载"这个思路本身——这条思路早被验证过,它做的是把它工程化、跑通到手机上。
代价也要算清楚。80B模型每个token只激活约3B参数,这意味着它聊天写作的手感接近大模型,但记事实的能力更接近小模型。项目文档自己也承认了这一点。标题党最容易在这里制造误会,让人以为跑通了就等于跑了一个完整的80B大模型。
跑得动,不等于跑得好用。
对本地部署和隐私优先的开发者来说,Swiftlet提供了一条此前没有的路径:在内存受限的苹果设备上,把更大的MoE模型跑起来。但个位数的tok/s速度、未公开的内存测量方法、还没经过第三方复现的性能数字,决定了它现在更像一份漂亮的工程可行性证明,还不是一个能直接拿去做产品的成品。接下来最值得盯的,不是又一次"首次原生运行"的宣称,而是有没有人拿同一台设备、同一套模型,把这些数字重新跑一遍。