我在 iPhone 上运行了 35B 参数模型（本地 AI）

中文العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский

Computing/SoftwareConsumer ElectronicsCell Phones

Transcript

00:00:00这个拥有 350 亿参数的模型正直接在我的 iPhone 上运行，我每秒能生成 11 个 token

00:00:06通过一些巧妙的工程设计，实现了这个模型原本根本无法做到的事。在这期视频中，我

00:00:11将精确展示如何做到这一点。我这里运行的是一个混合专家（MoE）模型，它

00:00:21拥有 350 亿参数，作为普通的 4-bit 量化文件大约有 20GB，原本必须全部保存在内存中

00:00:28但通过一系列技术，比如根据需求从 SSD 流式传输专家模型，实际上

00:00:33需要驻留在内存中的权重降低到了只有 1.4GB。我会解释这一切是如何运作的，然后

00:00:39我们将一步步进行 iPhone 本身的配置。大多数模型都完整常驻在内存中，但混合专家

00:00:45模型的妙处在于，在任何时刻都只有一小部分处于激活状态。这意味着未激活的部分

00:00:51可以安心待在 SSD 上，等待轮到它们发挥作用。在有限内存下运行更大模型的技巧

00:00:56就是只在需要时才将这些专家加载到内存中。我们运行的是 Qwen

00:01:023.5 的 350 亿参数变体，结尾的 A3B 意味着对于任意单个 token，只有大约 30 亿参数

00:01:10处于激活状态。它包含 40 层，每层有 256 个小型专家，外加 1 个共享专家。路由

00:01:19会为每个 token 挑选其中的 8 个专家，因此单个 token 只需要运行总共 350 亿参数中的

00:01:26约 30 亿参数。现在，整个模型本身是被拆分的。通常它会全部保存在内存中，但这

00:01:32在 iPhone 上根本装不下。相反，每个 token 都需要的那些部分——也就是嵌入、注意力机制、路由

00:01:39以及共享专家——只需加载一次，并全程常驻在内存中。这大约占

00:01:441.4GB。而专家部分——40 个文件，每个约 300MB，总计 12GB——则存放在 SSD 上。因此对于每个 token

00:01:53注意力机制在 GPU 上运行，然后路由挑选 8 个专家，引擎将这 8 个专家直接从 SSD 读取

00:02:00到 GPU 内存中，并与共享专家一起运行。这发生在全部

00:02:0640 层中的每一层，因此每处理一个 token 就需要进行 320 次小型读取。如果你不太熟悉注意力机制

00:02:14它是模型中用来回顾截至目前对话内容的部分，并推算出

00:02:19前面哪些词对预测下一个词最重要。无论如何，注意力机制都会在每个 token 上运行

00:02:25所以它必须常驻内存。而专家部分则是在注意力机制推导出上下文之后

00:02:31对 token 进行实际思考的部分。但因为只用到了其中 8 个专家，我们完全可以把

00:02:36其余的留在磁盘上。应用内部根本没有专家缓存，每次读取都通过操作系统进行

00:02:42只要有空余内存，iOS 就会把最近使用过的专家保存在它自己的 Page Cache 中。作者们

00:02:49实际上曾经构建过他们自己的 9.8GB 缓存，但随后删除了它，这反而让速度提升了 38%，因为

00:02:55在 Mac 或 iPhone 上，应用占用的任何内存都是从 GPU 和 Page Cache 那里剥夺来的

00:03:03而在此处每秒 11 个 token 的速度下，那个缓存承担了大部分工作。如果每个专家都从闪存读取

00:03:09手机将需要超过每秒 5GB 的读取速度，而 iPhone 的闪存每秒只能达到约 1.6GB

00:03:15因此大部分专家都是从系统为我们管理的内存中读取的。下一个技巧是分层

00:03:22量化。量化会压缩模型的权重，使其占用更少空间，但它也会降低

00:03:29这些权重的精度，从而影响智能水平。不过在这个模型中，大约 25% 的

00:03:35专家处理了大约 80% 的工作。因此高频专家保持 4-bit，而低频专家则

00:03:41量化压缩到 2-bit，这使它们缩小了 44%。整个文件从大约 19GB 缩减了 34% 至

00:03:5013GB，这意味着更多内容可以放入 Page Cache。在我的 iPhone 17 上，模型在思考模式下

00:03:57能以每秒 11 个 token 的速度运行。不过我得说，手机变得非常烫，字面上讲光是说声 “hello”，我就能

00:04:03感觉到手机在手里升温，所以测试时尽量别把手机弄炸了。说实话，我甚至

00:04:08有点不敢输入太复杂的内容，因为这可能真的会烫穿我的手

00:04:14我们运行的这个特定引擎是来自 Dan Woods 的一个名为 Flash MoE 的项目。它是为

00:04:19MacBook 编写的，还有一个名为 Flash iOS 的小型 iOS 移植版，它将同一个引擎封装到了 iPhone 应用中

00:04:26这就是让我能在手机上运行整个模型的原因。起初我还遇到了一个 Bug，模型的

00:04:31思考陷入了死循环。刚开始还好好的，但在输出大约 10 个词后，它就会永远重复

00:04:35相同的两个 token。为了修复这个问题，我更新了一个名为 async pre-read weight 的函数，使其能够

00:04:41对照专家自身的大小来检查每次读取。低频专家是 2-bit，大小只有高频专家的一半

00:04:48因此在修复之前，每个低频专家都没能通过大小检查而被静默跳过。模型实际上

00:04:54只带着一半的专家在运行，所以就陷入了循环。大家如果喜欢这期内容，订阅

00:04:59本频道就是对我们最大的支持，这样我们就能继续每天制作免费内容。现在

00:05:05要在你的手机上完成配置，你需要克隆代码库，将我刚才提到的预读取修复应用到

00:05:11metal infer / infer.m，将 Xcode 项目指向你的团队和 Bundle ID。你需要一个付费的 Apple

00:05:18开发者账号来做这件事。构建一个 Release 版本并安装到你的 iPhone 上。下载预打包好的

00:05:24分层模型（大约 13GB），通过 USB 传输到应用中，在手机上这大概需要 7 分钟

00:05:30在手机上打开 Flash MoE 应用，点击模型，然后就可以开始聊天了。如果你想尝试

00:05:36在 Mac 上运行本地模型以获得更快的每秒 token 速度，请观看下一期视频。我是来自

00:05:43BetterStack 的 Warren，非常感谢大家的观看，我们下期视频再见！

Key Takeaway

利用 Flash MoE 引擎结合 SSD 流式传输、iOS 系统级 Page Cache 以及分层量化技术，可在内存受限的 iPhone 上以每秒 11 个 token 的速度本地运行 350 亿参数的大模型。

Highlights

通过从 SSD 流式传输混合专家（MoE）模型的专家参数，运行 350 亿参数的 Qwen 3.5 模型仅需 1.4GB 的驻留内存。
采用按需加载机制后，iPhone 17 上模型的推理速度可以达到每秒 11 个 token。
分层量化技术将高频专家保持为 4-bit，低频专家压缩至 2-bit，使总模型体积缩小 34% 至 13GB。
删除自定义的 9.8GB 缓存并完全依赖 iOS 系统 Page Cache 后，运行速度提升了 38%。
修复 async pre-read weight 函数中低频专家（2-bit）的大小检查 Bug，解决了模型在生成 10 个词后陷入无限重复循环的问题。

Timeline

MoE 架构与内存流式传输原理

Qwen 3.5 35B MoE 模型在单个 token 推理时仅有约 30 亿参数处于激活状态。
将常驻内存占用控制在 1.4GB 的关键是分离固定层与按需专家层。

通常 20GB 的 4-bit 量化模型无法直接完整放入手机内存。由于该模型拥有 40 层以及每层 256 个小型专家加 1 个共享专家，路由会为每个 token 仅挑选 8 个专家。因此只需将嵌入、注意力机制、路由和共享专家（约 1.4GB）常驻内存，剩余 12GB 的 40 个专家文件保存在 SSD 上，推理时由 GPU 直接从闪存读取。

iOS Page Cache 与分层量化优化

利用 iOS 自身的 Page Cache 替代应用内置缓存，使速度提升了 38%。
分层量化通过差异化压缩低频专家，将文件总体积减少了 34%。

模型中约 25% 的专家处理了 80% 的工作，因此将高频专家保持 4-bit，低频专家压缩至 2-bit（体积缩小 44%），使整体存储降至 13GB。在每秒 11 个 token 的生成速率下，闪存读取无法满足每秒超 5GB 的物理需求，系统管理的内存 Page Cache 承担了绝大部分读取开销。此前开发者尝试过自建 9.8GB 缓存，但直接依赖系统缓存反而避免了剥夺 GPU 内存。

Flash MoE 引擎漏洞修复与实机部署步骤

修正异步预读取的大小检查逻辑可解决推理死循环问题。
部署过程需要编译 Flash iOS 封装并使用 USB 传输 13GB 模型文件。

Flash MoE 项目在迁移至 Flash iOS 时存在逻辑漏洞：async pre-read weight 函数会按 4-bit 大小校验所有专家，导致体积减半的 2-bit 低频专家被静默跳过，模型在缺乏一半专家的情况下运行大约 10 个词就会陷入重复 token 循环。修改 metal infer/infer.m 文件修复校验后，只需在 Xcode 中使用付费 Apple 开发者账号打包 Release 版本，将 13GB 的分层模型经 USB 传入手机即可正常运行。

Community Posts

No posts yet. Be the first to write about this video!

Write about this video