No.9 苹果怎么把 3GB 模型塞进手机，还让你感觉不到卡

早上七点半，闹钟刚响，你随手拿起枕边的 iPhone，按住侧边键，问了一句「今天通勤路上会下雨吗，要不要带伞」。两秒钟之后，Siri 的声音回来了——不仅告诉你今天几点开始下雨，还顺手提醒你下班时段风比较大。

整个交互顺得像呼吸。你没有等它「思考」，没有看到 Loading 转圈，没有感觉手机发烫，更没有意识到底发生了什么——你手机里驻着一个约 30 亿参数（业界推测）的大语言模型，它在那一瞬间完成了理解你的问题、检索天气数据、组织语言、生成回答这一整套动作，全程只用了你呼吸两口气的功夫。

如果你对此习以为常，那恰恰是苹果最想让你感受到的状态。

但这件事真的「正常」吗？我们把镜头拉近，看看这道题到底有多硬。

业界普遍推测，苹果 Apple Intelligence 背后的端侧基础模型（AFM，上一篇文章我们拆过它）大约是 30 亿参数的规模——简称 3B。一个 3B 模型，如果用业界最常见的 16 位浮点数（电脑存小数的标准方式，每个数占 2 字节）存储，光模型本身的权重就要占用约 6GB 内存。

那么 iPhone 15 Pro 最大内存多少？8GB。iOS 系统、后台 App、你正在刷的微信、正在播放的音乐、相机的缓存——这些加起来吃掉 4-5GB 是常态。也就是说，真正能给 AI 用的内存，可能也就 3GB 上下。

把一个 6GB 的模型塞进 3GB 的剩余内存？这道算术题怎么算都不对。而且就算塞进去了，模型每次回答你问题，都要把这几个 GB 的权重从头到尾读一遍——读取的数据量越大，回答越慢。塞得下不一定跑得动，跑得动不一定跑得流畅。

所以这里有个真问题——苹果到底是怎么做到让你感觉不到卡的？

上一篇我们拆了 MLX——苹果为自家硬件从零重写的机器学习框架。但 MLX 只是「工具」，工具能干活，可不等于活儿本身不脏。这一篇我们就来拆这道真正的硬工程——把一个 3GB 的大模型，塞进内存只有 8GB 的手机，还要让你用起来完全感觉不到卡顿。

这道题没有银弹。苹果的答案是一套组合拳，里面有四个关键招式——量化、拆分、KV 缓存、硬件协同。咱们一个个拆。

一、先算一笔账：3GB 模型 vs 8GB 内存的硬约束

我们把账先算清楚。

业界推测苹果端侧 AFM 模型大约 30 亿参数。业界习惯用 16 位浮点数来存模型权重——16 位浮点数就是用 16 个二进制位（也就是 2 个字节）来表达一个小数，精度足够高但占用空间也大。一个 3B 参数的模型，按 16 位浮点存：30 亿 × 2 字节 = 60 亿字节，大约 6GB。

iPhone 这边呢？iPhone 15 Pro 最大内存 8GB——这已经是截至 2026 年 iPhone 里最大的内存配置。iOS 系统本身要占 1-2GB，你日常用的微信、相册、音乐、地图这些 App 都在后台吃内存，相机缓存、键盘输入也要内存。把这些都算上，能给 AI 模型留的余量，业界工程估算大概也就 3GB 上下。

3GB 余量 vs 6GB 模型——明显的缺口。光这一道就塞不下。

但更致命的不是「装不下」，而是「跑不动」。这里要引入一个比「内存容量」更关键的词——内存带宽。

内存容量好理解，就是仓库有多大；内存带宽是仓库门口的马路口有多宽——你就算仓库装得下，如果每次取货都要从一个小胡同里一件一件往外搬，那效率低到发指。模型推理时，手机的 GPU 要不断从内存里读取模型权重做计算，每次回答你一句话，模型里的几百亿个参数可能都要被读一遍。模型越大，要搬运的数据越多，搬运次数越多，回答就越慢。

所以模型太大，不只是「装不下」，更是「搬不动」。即便你给 iPhone 塞进 16GB 内存，如果模型本身还是 6GB，每次回答你都要搬运 6GB 数据——那么用户的等待时间依然无法接受。

这就是为什么单纯加内存解决不了问题。必须从根上把模型变小——既变小体积，又变小搬运量。

这就引出了机器学习工程里一个核心话题——量化。

量化的目标就一句话：让模型占用的内存变小，让模型每次推理要搬运的数据变少。两个目标，一次达成。

那量化到底是怎么做的？为什么能让模型既变小又不至于变蠢？这件事值得专门拆。

二、量化：把高清照片压成 JPEG 的艺术

量化不是苹果的发明，它是整个 AI 行业解决「模型太大」的标准答案。但要真正理解它，我们得退一步，先讲清楚 AI 模型到底是什么东西、为什么它「大」。

一个 AI 大模型，本质上是两样东西的组合——一堆数字（权重）+ 一套怎么处理这些数字的流程（架构）。架构本身只是几十页纸的数学描述，真正占空间的是那一堆数字。一个 3B 模型之所以占 6GB，就是因为里面有 30 亿个数字，每个数字用 2 字节存。

那这些数字是什么？它们是模型在训练过程中，从海量数据里学出来的「记忆」——比如「猫这个字跟宠物这个概念有多近」「这张图片里第三个像素是红色的概率有多大」——全部都变成数字存在权重里。模型越大，存的「记忆」越多，回答问题时能调用的知识越丰富。

理解了这一点，量化的思路就很直觉了——把每个数字的存储精度降低，不就能让模型变小？

咱们用一个生活化的比喻。你拍了一张 4K 高清照片，每个像素用 16 位精度存，能呈现 65536 种颜色层次，画质极细腻，但文件可能要 20MB。如果你把它压成一张 JPEG——每个像素只用 8 位精度存，只能呈现 256 种层次，但文件大小直接缩到 2MB。你远看这张 JPEG，跟 4K 原图几乎看不出区别，只有在放大看细节时才会发现「哎，色彩过渡没原图那么柔和了」。

模型量化做的是一模一样的事。把每个权重从 16 位精度（FP16）降到 4 位精度（INT4），每个权重占的空间从 2 字节缩到 0.5 字节，模型体积直接缩小到原来的四分之一。代价是——精度损失，就像 JPEG 一样。

业界常见的量化精度档位，从轻到重排列：

• FP16（16 位浮点）：原始精度，精度最高，体积最大
• FP8（8 位浮点）：体积减半，精度损失很小
• INT8（8 位整数）：体积减半，精度略低于 FP8
• FP4（4 位浮点）：体积缩到 1/4，精度损失明显
• INT4（4 位整数）：体积缩到 1/4，精度损失最大但压缩最激进
• INT2（2 位整数）：体积缩到 1/8，极端压缩，仅用于特定场景

每降一档，体积小一半，精度损失也更明显。这是一场用精度换空间的交易。

SAM3 案例：3GB 压到 430MB 的教科书级实操

WWDC26 的一场 Core AI session 里，苹果工程师现场演示了一个量化案例——这个案例后来被业界反复引用，因为它把量化这件事的收益和代价，一次讲透了。

这个案例的主角是一个叫 SAM3（Segment Anything Model 3）的模型，业界某实验室开源的视觉分割模型——你给它一张图片，再加一句提示词（比如「flower」），它就能精准地把图片里所有花朵的区域圈出来。SAM3 在苹果工程师的手里，原始体积超过 3GB。

3GB 这个数字是不是很熟悉？正好是 iPhone 能给 AI 用的内存量级。所以 SAM3 是个特别合适的演示素材——把它塞进 iPhone 是一道真问题。

苹果工程师对 SAM3 做了 INT4 量化——把所有权重从 16 位精度砍到 4 位。结果非常漂亮：

3GB 压到 430MB，正好塞进 iPhone 的内存预算，而且每次推理搬运量也少了 7 倍，速度自然就上来了。看起来量化就是银弹，一行代码搞定一切。

踩坑：一刀切丢了「一朵花」

但事情没这么简单。苹果工程师用量化后的 SAM3 跑场景测试，发现一个微妙但致命的问题——量化前能检测到的所有花朵，量化后有一朵被遮挡的花不再被检测到了。

模型在绝大多数场景下表现得跟原来差不多，但就是这一朵特定的花，它「看不见」了。

这个问题是怎么发现的？不是靠自动化测试，也不是看精度指标——因为整体精度指标几乎没变。是工程师人工对比量化前后的输出结果，一朵一朵花核对，才发现这一朵漏了。

这个故事说明一个反常识的事——量化的代价不是均匀分布的。整体精度掉 1%，不代表每一个具体场景都掉 1%。可能 99% 的场景完全无感，但 1% 的关键场景会从「能用」变成「不能用」。

为什么这朵花会丢？工程师深挖 SAM3 的内部结构，找到了根因。

SAM3 不是铁板一块，它由三个子模块组成：

• 图像编码器（占模型参数约 48%）：负责把输入图片变成模型能理解的视觉特征
• 文本编码器（占模型参数约 48%）：负责把用户的提示词（比如「flower」）变成模型能理解的语义特征
• Detector 模块（占模型参数约 4%）：把图像特征和文本特征结合起来，做出最终的检测决策

前两个编码器加起来占 96% 的参数，压它们收益巨大——你压掉这 96%，整个模型体积就跟着大幅缩水。但 Detector 只占 4% 的参数，压它省不了多少空间，可它干的是什么活？它负责最后的决策——图像特征和文本特征都准备好之后，由它来判断「这一块区域到底是不是花」。

Detector 这个模块，就像是整张照片里最关键的那块对焦区域——它的精度决定了「能不能看见这一朵被遮挡的花」。你用 INT4 一刀切压它，等于在最关键的决策环节丢了最多的精度。整体精度掉得不多，但决策的边界能力直接崩了。

选择性量化：该压的压，不该压的留

苹果工程师的解决方案叫选择性量化——对不同模块采用不同的压缩策略。

• 图像编码器 + 文本编码器（共占 96%）：用 INT4 + 4 位调色板量化，大幅压缩
• Detector 模块（占 4%）：跳过压缩，保持原始 FP16 精度

修改后重新量化，所有花朵（包括那朵被遮挡的）都被正确检测，模型大小仍然大幅缩小——因为那 96% 的部分压了 4 倍，总体积依然接近 430MB。

这是一个特别漂亮的工程样本——量化不是一刀切的活，是绣花活。

业界还有一种跟 INT4 不同的量化路线，叫调色板量化（Palettization）。它的思路不是直接截断精度，而是用查找表的方式：把模型里大量相似的权重归为一组，用同一个代表值替代——就像画家调色板上的颜色，画面里有几百万个像素，但实际用到的颜色可能就 256 种，你只需要存「这 256 种颜色 + 每个像素用的是哪种」就行。调色板量化在移动端（尤其是 iOS）的低功耗场景下表现很好，所以 SAM3 的部分模块用的是调色板而不是 INT4。

Core AI Debugger：定位精度损失的「医生」

但这里还有个工程问题——你怎么知道该对哪个模块手下留情？SAM3 的内部结构是公开的，工程师一眼能看到「Detector 占 4% 但负责决策」。但如果是你自家训练的模型呢？

苹果在 WWDC26 发布了一个独立工具叫 Core AI Debugger。它的作用就是把模型内部打开，让你看见每一层的中间计算结果。

这里要插一个基础词——张量（Tensor）。你可以把它理解为一个多维数组——就像一张彩色照片是三维的（长 × 宽 × 颜色），模型里的张量是更高维的数据块，几维都可能，是模型内部传递和计算信息的基本容器。张量这个概念在后面会反复出现。

具体怎么用？你拿量化前的模型和量化后的模型跑同一组测试数据，Core AI Debugger 会把每一层中间张量的相似度算出来，按相似度从低到高排序。那些相似度特别低的层，就是被压缩得最狠、丢精度最多的地方——也就是你该「手下留情」的地方。

在 SAM3 这个案例里，Core AI Debugger 一排序就显示——几乎所有低相似度的操作都来自 Detector 模块。问题定位瞬间完成。

这件事跟苹果对开发者层面的黑盒哲学是反过来的——对终端用户，苹果把复杂性藏起来；对开发者，苹果要求复杂性必须自己掌控。量化不是点一下按钮就完事的魔法，是一道需要工程师深度参与的绣花活。

量化小结：模型变小了，但还不够好

到这一步，模型从 6GB 压到了 430MB 级别，看起来塞进 iPhone 是没问题的。但还有两个新问题冒出来——

第一，不同任务用到模型的不同部分，每次都全量加载太浪费。 第二，Transformer 这个架构本身有个老大难问题——越推理越慢。这里先解释一下 Transformer——它是当下所有主流大模型（包括苹果自家的 AFM、业界各家大模型）共同使用的那种架构，你可以把它理解为一种「设计图纸」，所有大模型都是按这张图纸盖的房子。下一篇我们会专门拆它，这一篇先把它当成「大模型的通用架构」即可。

这两个问题，量化解决不了，得靠另外两招——模型拆分 和 KV 缓存。

三、拆分：把一整块模型拆成可复用的零件

我们想象一段工程师内部讨论。

产品经理：「咱们这个 SAM3，现在塞进 iPhone 没问题了对吧？」 工程师：「体积上塞得下，但用起来还有点浪费。」 产品经理：「浪费什么？不是已经 430MB 了吗？」 工程师：「问题是用户用它的方式。你想想，用户先用『flower』这个提示词分割了一张图，然后他不满意，换了个提示词『butterfly』想分割同一张图。图片没变，提示词变了。但模型是一整块的——每次调用都要从头跑一遍，包括那个最耗时的图像编码器。」 产品经理：「那就是说，同一张图被处理了两次？」 工程师：「对，百分之百浪费。图像编码器算一次要几百毫秒，重复算完全没必要。」

这就是「一整块模型」的真正问题——它不灵活。哪怕你只想用其中一小部分，也得把整块都跑一遍。

苹果工程师的解决方案是——把 SAM3 拆成三个独立函数。

这三个函数各自干各自的活：

• image_encode：专门处理图像，输出图像特征（可以缓存起来反复用）
• text_encode：专门处理提示词，输出文本特征
• detect：结合图像特征和文本特征，输出最终的分割结果

拆完之后，前面那个「换提示词重新跑」的场景就完全变了——用户第一次问「flower」时，三个函数都跑一遍，图像特征和文本特征分别缓存。用户改问「butterfly」时，只需要重跑 text_encode 和 detect——因为图片没变，image_encode 的结果可以复用。

实测结果：第二次推理快了 76%。

76% 是什么概念？如果第一次要 1 秒，第二次只要 0.24 秒。用户从「哎怎么又要等一下」直接变成「哎怎么这么快」。这就是函数拆分的威力。

拆分的第二个红利：独立压缩

拆分还有一个连带好处——每个函数可以独立选择压缩策略。

回想我们前面讲过的「选择性量化」——图像编码器和文本编码器用 INT4 压缩，Detector 保持原始精度。这件事在「一整块模型」的状态下也能做，但工程上很别扭。拆成三个独立函数之后，每个函数就是一个独立的优化对象——你可以给图像编码器单独做调色板量化，给文本编码器单独做 INT4，给 Detector 做轻度的 FP8 量化，互不干扰，各自追求最优。

拆分的第三个红利：iOS 低功耗优化

苹果工程师还做了一层更深的优化——针对 iOS 的低功耗执行场景，把图像编码器和文本编码器里标准的某种底层结构（业界常见的神经网络基本层），替换成另一种等价但更适合移动硬件的计算形式（卷积投影）。具体名词不重要，你只需要知道——同样是分割一张图片，这种替换让 SAM3 在 iPhone 上跑的时候更省电，电池消耗能少一截。

Detector 模块比较小，重写它带来的收益有限，所以工程师基本保持原样——这也是工程判断：把优化精力花在收益最大的地方。

拆分小结：灵活了，但还有部署侧的硬题

到这一步，模型已经在「跑起来」这件事上做到了灵活——拆开、复用、独立优化。但还有一个问题没解决——模型怎么送到用户手机里。

你想啊，SAM3 加上其他配套模型，合计超过 1GB。如果把所有这些模型都打包进 App 安装包，会出现什么情况？

每个下载你 App 的用户，不管用不用 AI 功能，都得下载一个超过 1GB 的庞然大物。这对用户体验是灾难——存储空间被占、下载流量被烧、App Store 排名还会因为「包体过大」被惩罚。

而即便模型送到了用户手机，第一次加载还藏着一个叫专化的慢动作陷阱。这些都不是「跑起来」层面的问题，是「部署」层面的问题。我们单独拉一段拆。

四、部署侧：从下载到首次运行的无感闭环

我们先把镜头从「苹果工程师的实验室」切到「一个普通用户第一次点开 AI 功能的那一刻」。

用户视角里发生的事情很简单——他在 App 里点了「智能圈选图片」这个按钮，等了几秒，功能就能用了。他完全不知道，这几秒背后藏着三件事——模型从哪里来、怎么变小、等待藏在哪里。

Background Assets：不用的不下载

第一件事——模型从哪里来。

苹果给开发者提供了一套叫 Background Assets 的框架。它的逻辑是——模型不打包进 App，等用户真正用到 AI 功能的时候才在后台下载。

用户第一次点开「智能圈选图片」这种功能时，系统会在后台默默下载 SAM3 模型，下载完了再触发后续的「专化」流程。整个过程用户能看到一个进度条，但不会被打断当前的操作。

专化：模型第一次加载为什么慢

第二件事——下载完的模型为什么不能直接跑。

你打包进 App 或通过 Background Assets 下载到用户手机里的模型文件，是一个通用的 .aimodel 格式——它能在任何 Apple 设备上跑，但还没有针对任何具体设备优化。等它真正落到一台 iPhone 15 Pro 上时，系统会针对这台设备的 A 系列芯片架构、当前 iOS 版本，对这个模型做一次深度编译和优化——这件事就是专化（Specialization）。

专化分两步： 1. 核心编译：对计算流程做分段、规划、优化——最耗时 2. 生成可执行产物：为具体的计算单元（CPU / GPU / 神经引擎）生成专用代码

专化完成后，结果会被系统缓存——后续加载从缓存读取，速度很快。但第一次专化可能要等好几秒甚至更久，对大模型尤其明显。

如果用户第一次点开 AI 功能，就傻等几秒钟看着屏幕转圈——苹果绝对不能接受这种体验。

预编译 + 首次运行体验：把等待藏起来

苹果的两件武器——

预编译（Ahead-of-Time Compilation）——在开发者的 Mac 上，提前把大部分编译工作做掉。开发者用 coreai-build 这个命令行工具，可以为不同的设备架构（iPhone 的 A 系列、Mac 的 M 系列、iPad 的 M 系列）分别生成预编译版本。预编译后的模型在用户设备上还需要做最终的专化，但这时剩下的工作已经很少了，速度能快上一个数量级——原本要 8 秒的首次加载，压到 0.8 秒以内。

首次运行体验——光有预编译还不够。0.8 秒听起来已经很短了，但如果你把它放在用户点开 AI 功能的那一刻——一个心理预期是「立刻能用」的用户，对着一个转圈动画等 0.8 秒，他依然会觉得「这手机是不是卡了」。人对交互等待的感知远比想象的敏锐——只要等待出现在「我点击」和「我得到反馈」之间，再短也是瑕疵。

苹果还有最后一招——把等待藏进功能介绍页。

苹果工程师的建议原话是：永远不要在用户交互流程中触发模型专化。

什么意思？用户点开一个 AI 功能的瞬间，他的心理预期是「立刻能用」，不是「先等一下」。所以第一次专化不应该发生在用户点击的那一刻——而应该藏在一个专门的「首次运行体验」流程里，比如一个介绍这个 AI 功能能做什么的引导页。用户在阅读功能介绍、看几张示例图片的时候，模型在后台默默完成专化。等用户读完了，点「开始使用」，模型已经就位了。

部署侧小结：三件武器合起来让用户无感

这三件武器——预编译 + Background Assets + 首次运行体验——配合起来，让用户在「第一次用 AI 功能」这件事上完全无感。用户感知到的只是「打开就能用」，完全不知道背后有这么一套组合拳。

但到这一步，我们还只解决了「模型大小」和「加载时机」的问题。Transformer 这个架构本身还有一个老大难毛病没解决——越推理越慢。这就是我们要拆的下一招——而且这一招直接决定了苹果端侧推理能不能持续跑流畅。

五、KV 缓存：让 Transformer 不再越推理越慢

我们来想一个反常识的问题——为什么 Transformer 越推理越慢？

用户跟大模型对话的时候，都有过这种体验——刚开始聊的时候，模型回答飞快；聊得越久，模型回答越慢；等到对话历史攒到几千字之后，每等一个字都像在挤牙膏。

这种越用越慢的体验，在产品层面是不可接受的。但 Transformer 架构本身确实有这个毛病——不解决它，端侧大模型就没法用。

根因：Transformer 的二次方复杂度

我们得先搞清楚 Transformer 为什么会这样。

Transformer 就是前面讲过的那种「当下所有主流大模型共用的架构」。它有一个核心机制叫注意力计算（Attention）——模型在生成每一个词的时候，都要回头看一眼之前所有的词，判断哪个词跟当前要生成的词关系更紧密。比如用户问「今天北京天气怎么样」，模型生成「下雨」的时候，要回头看「今天」「北京」「天气」这几个词；如果对话继续到第 100 个词，模型生成第 100 个词的时候，要回头看前面 99 个词——这意味着计算量随对话长度呈二次方增长。

打个比方——你跟一个朋友聊天，他每说一句话，都要把你之前说过的所有话从头到尾再看一遍才能回你。刚开始聊没事，聊到第 100 句的时候，他每回你一句话都要把前 99 句重新读一遍——这速度能不慢吗？

苹果工程师在 WWDC26 现场 demo 了一个贪吃蛇游戏来演示这个问题——游戏刚开始 AI 玩得特别流畅，但随着游戏进行（贪吃蛇越吃越长，需要模型记忆的历史越来越长），AI 操作越来越慢，最后卡顿到没法玩。

KV 缓存：把历史计算结果存起来

这个问题的解决方案叫 KV 缓存（Key-Value Cache）。

KV 缓存的思路很直觉——既然模型每次生成新词都要「回头看历史」，那为什么不把历史计算的结果存起来，下次直接用？

在 Transformer 内部，注意力计算涉及两个东西——Key（每个历史词的「索引」）和 Value（每个历史词的「内容摘要」）。模型每生成一个新词，都要算出前面所有词的 Key 和 Value，然后根据这些 Key/Value 决定当前词该生成什么。

KV 缓存做的事就是——把已经算过的 Key 和 Value 存起来。下次再生成新词时，不用重新算历史的 Key/Value，直接从缓存里读，然后只算新词自己的 Key/Value 加进去。

效果是什么？原本每生成一个词的计算量跟对话长度呈二次方关系，加了 KV 缓存后变成线性关系——对话越长，省下的计算越多。贪吃蛇 demo 加了 KV 缓存之后，从头到尾保持流畅。

苹果的 Core AI 框架原生支持 KV 缓存——它把缓存作为模型的「状态」在推理之间传递和原地更新。对比之下，上一代的 Core ML 框架不支持状态管理，所以处理不了大语言模型这种「带记忆」的推理。

KV 缓存占内存：必须做权衡

但 KV 缓存自己也要占内存——对话越长，缓存越大。苹果在 Foundation Models 框架里提供了一个叫 contextSize 的属性，让 App 实时读到「已经用了多少 Token、还剩多少 Token」。

这也是为什么设备端模型的上下文窗口（一次能处理的最大 Token 数，Token 是模型处理文本的最小单位，一个汉字大约对应 1-2 个 Token）必须受限——更长的上下文意味着更大的 KV 缓存、更多的内存占用，会跟其他 App 抢资源。具体权衡多少，是产品思维的题——我们留到这一篇最后一节再拆。

到这一步，软件侧的优化——量化、拆分、部署、KV 缓存——已经把能做的基本做完了。但光有软件还不够。苹果还有一张底牌——硬件跟框架的同步进化。这就是最后一招。

六、硬件协同：M5 神经加速器与 Metal 量化张量

我们把镜头切到 2026 年 WWDC 现场。苹果全球开发者关系副总裁上台，背后大屏出现一句话——「M5 芯片的神经加速器，让大语言模型的提示处理速度比 M4 快近 4 倍」。

台下坐着的开发者们——尤其是做端侧大模型的——直接炸开了。4 倍加速这个数字，如果是 CPU 频率提升，得花两三代芯片迭代才能做到；苹果在一代芯片里就把它干上去了，靠的是什么？

神经加速器：藏在着色器核心里的专用硬件

这件事的底层是一件特别硬核的硬件设计——M5 芯片里引入了一个全新的硬件模块，叫神经加速器（Neural Accelerator）。

注意，这不是一个独立芯片——它甚至不是一个独立的硬件单元。它藏在 GPU 的每一个着色器核心里面。打个比方，传统 GPU 的着色器核心就像一支「多面手小工队」——什么活都能干，但每种活都得自己拼凑工具。神经加速器相当于在每个小工队里专门配了一个「AI 计算专员」——别的活它不管，专门干 AI 里最耗时的几种密集运算（比如大语言模型预填充阶段那种大批量的并行乘加运算）。

这里要补一个基础词——矩阵乘法。你可以把它理解为「一大批数字同时按规则做乘法和加法」的运算，是 AI 模型内部最常见、最耗算力的那种运算。工程上经常用「张量」这种多维数组来表达参与运算的数据。这两个词后面会再出现，你只要把它们当成「AI 计算里最基础、最耗算力的那种运算」就行。

「预填充」是什么？用户给大模型发一句话时，模型要先把这句话从头处理一遍——理解每一个词的含义、建立上下文关系——然后才能开始一个字一个字地生成回答。这个「处理输入」的阶段就叫预填充。预填充的速度决定了用户从「发送」到「看到第一个字」要等多久——这是端侧 AI 用户体感最敏感的指标。

M5 的神经加速器配合 MLX 框架里专门为它写的乘法和注意力内核，把预填充阶段的速度直接拉到 M4 的近 4 倍。

最关键的一点是——这件事不需要开发者改任何代码。MLX 框架会自动识别硬件，如果检测到是 M5，就启用专用的乘法和注意力内核；如果是 M4，就退回到 M5 之前的通用内核。开发者写的同一份代码，跑在不同代际的芯片上，会自动获得对应的硬件加速能力。

Metal 量化张量：硬件原生支持压缩格式

但光有神经加速器还不够。还记得前面讲的量化吗——把模型权重从 FP16 压到 INT4，体积缩到四分之一。但这里有个隐藏问题——压缩后的权重，在 GPU 里要怎么参与计算？

最直觉的做法是：GPU 算之前，先把 INT4 反量化回 FP16（恢复成高精度），然后再做乘法加法。但这等于在每次推理前都做一次「解压」——你量化省下来的速度，又被反量化这一步吃回去了。

苹果的解决方案是——让 GPU 硬件原生支持量化数据类型。WWDC26 之后，苹果的 Metal 图形 API 直接原生支持 INT4、INT8、FP4、FP8，以及一种叫 MX 的缩放格式。开发者可以把量化后的张量直接丢给一套叫 TensorOps 的 Metal 着色语言 API，GPU 内部自动完成「反量化 + 计算」一气呵成，无需中间步骤。

多平面张量：数据与缩放因子的合体

这里还有一个工程细节值得拆。前面讲量化时提到——量化后的值要配一个「缩放因子」才能恢复到原始范围。你可以把缩放因子理解为一把「尺子」——量化值是刻度，缩放因子告诉你每个刻度对应原始范围里的多少。

传统做法是——数据和缩放因子分开存，计算时要把它们拼起来用，这一步有额外开销。

苹果的设计叫多平面张量（Multi-plane Tensor）——一个张量对象里同时包含两个平面：数据平面（存量化后的权重）和缩放平面（存缩放因子）。两者被打包在同一个对象里，使用时无需额外处理，GPU 直接就能用。

这件事的优雅之处在于——它把「数据」和「解释这份数据的尺子」合二为一。就像你寄一份加密文件，同时把密钥贴在文件封面上——收件人打开就能直接读，不用再去找密钥。

FlashAttention：把三步融合成一步

最后一个硬核优化——FlashAttention。

Transformer 模型里最核心的运算叫注意力计算，标准的注意力计算分三步：

1. 算相关度——模型把自己「要找的东西」跟历史里每个词「比对一遍」，得出一个「哪个词最相关」的分数。
2. 归一化——把这些分数换算成百分比，让所有分数加起来等于 1。
3. 按权重取内容——按上一步的百分比，把历史每个词的内容混在一起，作为当前这个词的参考。

如果这三步分开执行——第一步算完写回内存，第二步读出来再算，第三步再读出来算——中间结果要在 GPU 和内存之间来回搬运好几次，性能开销巨大。

打个生活化的比喻——这就像三台分别处理原料的机器（一台算相关度、一台归一化、一台加权取内容），中间要用传送带把半成品送到仓库再取回来，下一台机器才能接着干。传送带一趟趟跑，慢得要命。

FlashAttention 算法把这三步融合成一个 GPU 内核——中间结果全部留在 GPU 的寄存器（离计算单元最近的极快存储）和线程组内存里，不经过主内存。这就像把三台机器合并成一台多功能料理机——原料进去、成品出来，中间不用经过仓库。这样做能让注意力计算的速度再上一个台阶，同时内存带宽的压力也大幅下降。

TensorOps 提供了构建 FlashAttention 所需的全部基础原语——协作张量、行归约、映射迭代器等——苹果工程师把这些底层工具全写好了，开发者拿来就能用。

软硬协同的真正壁垒

讲到这儿我们退一步看——为什么别人做不到？

业界任何一家做端侧 AI 的公司，理论上都能用量化、KV 缓存、FlashAttention 这些技术——它们都是公开的学术成果。但把这些技术真正压榨到位，需要一件事——硬件和框架的同步设计。

业界某家 GPU 巨头的 GPU 加上自家的软件生态做得很好，但它不做手机——它的 GPU 是给数据中心和高端工作站设计的，功耗和体积都装不进手机。

有些手机芯片厂商做手机芯片，但他们没有自己的框架——他们的 GPU 加速能力要靠业界通用的第三方框架去适配，适配的节奏永远比芯片发布慢半拍到一拍。

苹果的优势在于——芯片团队、框架团队、模型团队、产品团队，都在同一家公司里。M5 引入神经加速器的同时，MLX 框架就已经为它写好了专用内核；Metal API 升级支持量化张量的同时，Core AI 工具链就已经能用这些能力做模型压缩。软硬件的迭代是同步的，这是别人追不上的节奏。

七、产品思维的胜利：把所有复杂性吞进黑盒

我们回到开篇那个早上七点半的场景。

你按住手机侧边键，问了一句「今天通勤路上会下雨吗」。两秒后 Siri 回答。整件事对你来说就是这样——一句问、一句答。

可你这一句问、一句答的背后，是多少层工程嵌套？这就是我们这一篇整篇要回答的最后一个问题——用户为什么要知道这些。

一个普通的 iPhone 用户，他根本不知道什么是量化，不知道什么是 KV 缓存，不知道 M5 芯片里有神经加速器这种东西，更不知道 FlashAttention 是什么。他就知道一件事——Siri 回答得很快，而且不用联网。

这就是苹果产品思维最厉害的地方。

用户视角 vs 工程师视角

我们把同一个场景，从两个视角切一下。

用户视角：早上起床，按住手机侧边键，问「今天通勤会不会下雨」。两秒后 Siri 回答。完事。

工程师视角：用户按下侧边键的那一瞬间——

1. iPhone 识别出用户的语音，把它转成文字（这一步用了语音识别模型）
2. 文字被送进 AFM 端侧模型（一个约 30 亿参数的大语言模型，量化后约 430MB 大小）
3. AFM 模型开始预填充——理解这句话的含义、判断用户意图（这一步在 M5 芯片的神经加速器加持下，比 M4 快近 4 倍）
4. 模型识别出这是个天气查询，调用天气 App 的工具接口
5. 天气数据返回，AFM 模型开始生成回答——每生成一个字都要做一次注意力计算（FlashAttention 让这一步免受内存带宽拖累）
6. KV 缓存让对话上下文不用每次重算
7. 生成的文字被转成 Siri 的语音
8. 整个过程在两秒内完成，期间手机几乎不发热，电池消耗极低

这背后是多少层工程嵌套？量化、拆分、部署、KV 缓存、神经加速器、Metal 量化张量、FlashAttention、Background Assets、预编译、首次运行体验、Foundation Models 框架——至少十层。每一层都是巨大的工程投入，每一层都有专门的团队在迭代。

用户感知到的是什么？两秒钟，一个准确的回答。

用户感知不到的是什么？背后整整十层工程嵌套。

黑盒哲学的再次落地

这就是苹果从第一篇就在讲的黑盒哲学——真正的产品高级度，是让用户根本不需要关心技术是谁做的、怎么实现的、用了什么模型。

用户只需要关心一件事——这个产品能不能解决我的问题。

苹果把这道题里的所有复杂性——量化多激进、Detector 要不要压、KV 缓存怎么管、神经加速器怎么调、专化藏在哪里——全部吞进了自己肚子里。对外暴露的，只是一个干净的 API、一个流畅的交互、一个能用的产品。

这件事说起来简单，做起来极度困难。它要求一家公司同时具备——

1. 芯片设计能力（Apple Silicon + M5 神经加速器）
2. 底层图形 API 能力（Metal + TensorOps）
3. 框架设计能力（MLX + Core AI）
4. 模型训练能力（AFM 端侧版本）
5. 工具链能力（coreai-opt 量化工具 + Core AI Debugger + coreai-build 预编译）
6. 操作系统调度能力（iOS 内存管理 + Background Assets）
7. 产品集成能力（Apple Intelligence + Foundation Models 框架）

业界没有任何第二家公司同时具备这七层能力。你能找到芯片强的、框架强的、模型强的、产品强的——但你找不到一家把这七层全握在自己手里的。

端云协同：为什么 4K 就够了

讲到七层能力，还有一个特别能体现苹果产品思维的细节——端云路由。

你看，端侧 AFM 模型的上下文窗口是 4K Token（大约 3000-4000 字），而云端 PCC 模型的上下文窗口是 32K Token（能装下几万字）。不仅如此——PCC 还支持三档「让模型想一想再回答」的推理能力（light 简单查询 / moderate 中等推理 / deep 复杂多步推理），端侧不支持。

4K Token 对绝大多数日常场景足够了——你问 Siri 今天天气、帮我总结一封邮件、给这段文字润色，4K 都绰绰有余。但如果你要处理一份几万字的长报告、或者做多步推理（需要模型「想一想再回答」），4K 就不够了——这时候 Foundation Models 框架会自动把请求路由到云端 PCC 模型。

这件事告诉我们什么？端侧模型的上下文受限，不是技术上做不到更长，而是产品权衡——更长的上下文意味着更大的 KV 缓存、更多的内存占用、更长的等待时间，跟其他 App 抢资源。4K Token 是苹果权衡后的一个「甜点值」——能覆盖绝大多数日常场景，又不至于把内存吃光；真正需要大上下文、深度推理的场景，交给 PCC 云端处理。

这种「端云分工」的背后，是苹果对用户真实诉求的精准把握——绝大多数用户绝大多数时候，要的就是一个 2 秒内能回答的 Siri；极少数场景才需要云端那种「想一想再回答」的重火力。把这两类需求分清楚、用不同的工具服务——这就是产品思维。

这不是「塞进手机」，这是「吞进肚子」

回过头看这一篇的标题——苹果怎么把 3GB 模型塞进手机，还让你感觉不到卡。

现在你应该能看出这个标题的真正含义了。「塞进手机」听起来像是一个空间问题——找一个够大的盒子把东西装进去。但这道题真正的难度，不在于「装得下」，而在于「装下之后还能跑得流畅、跑得省电、跑得让用户无感」。

苹果的解法是——不是把模型塞进手机，而是把整套工程复杂性吞进自己肚子里。

• 量化的复杂性，吞进 Core AI 的工具链（coreai-opt + Core AI Debugger）
• 拆分的复杂性，吞进 Core AI 的多函数 API
• 部署的复杂性，吞进 Background Assets + 预编译 + 首次运行体验
• KV 缓存的复杂性，吞进 Foundation Models 框架的状态管理
• 硬件加速的复杂性，吞进 MLX + Metal + TensorOps + Neural Accelerator
• 端云路由的复杂性，吞进 Foundation Models 框架的 CombinedLanguageModel

开发者拿到的，是三行 Swift 代码：

let session = LanguageModelSession(model: SystemLanguageModel)
let response = session.respond(to: "今天会下雨吗")

用户拿到的，是一个能在两秒内回答问题的 Siri。

中间这十层工程嵌套，苹果一字未提。

延伸到「苹果式 AI」的整体逻辑

这件事跟整个 WWDC DeepDive 专栏一直在讲的核心论点是同一条线——苹果做 AI 的根本不同，是产品思维 vs 技术思维。

技术思维会问：我的模型参数有多大？我的精度是多少？我的 benchmark 跑分？

产品思维会问：用户拿这个功能做什么？他什么时候用？他能不能不学习就会用？他用了之后会不会觉得「这就是苹果该有的样子」？

这两种思维不是对立的——苹果也追求模型参数、也追求精度、也追求 benchmark 跑分。但苹果追求这些的方式，是把它们当成用户感知的支撑，而不是对外宣传的卖点。

一个 3GB 的模型塞进手机，业界任何一家公司都能做到——只要肯投入工程资源。但让用户完全感觉不到这是一个 3GB 模型在跑——这件事只有苹果做到了。因为只有苹果同时握着芯片、框架、模型、工具链、操作系统、产品这七层。

这就是为什么我们说——苹果的 AI 战略，不是做一个大模型，而是把整个工程链条垂直整合成一个用户无感的产品。

Key Findings

1. 3GB 模型 vs 8GB 内存的硬约束——业界推测苹果 AFM 端侧模型约 30 亿参数（3B），用 16 位浮点存储约 6GB。iPhone 15 Pro 最大内存 8GB，iOS + 后台 App 占掉 4-5GB，真正能给 AI 用的内存余量约 3GB。装不下，更跑不动——内存带宽是比内存容量更致命的瓶颈。
   
2. 量化是端侧大模型的必经之路——把模型权重从 FP16（16 位浮点，每权重 2 字节）压到 INT4（4 位整数，每权重 0.5 字节），体积缩到 1/4。苹果 SAM3 案例演示：3GB 模型量化后约 430MB，缩小约 7 倍，内存带宽需求也减少 7 倍。
   
3. 量化绝不能一刀切——SAM3 案例中，全局 INT4 量化导致模型漏检「一朵被遮挡的花」。根因：SAM3 的 Detector 模块只占 4% 参数但负责最终决策，对精度最敏感。解决方案是「选择性量化」——图像/文本编码器（占 96%）用 INT4 大幅压缩，Detector 保持 FP16 原始精度。Core AI Debugger 按相似度排序定位精度损失层。
   
4. 模型拆分带来三重红利——SAM3 拆成 image_encode / text_encode / detect 三个独立函数后：（一）换提示词时跳过 image_encode，第二次推理快 76%；（二）每个函数独立选择最优压缩策略；（三）针对 iOS 低功耗场景替换底层结构，更省电。
   
5. 部署侧三件武器化解「送到手机 + 首次加载」两大难题——Background Assets 让模型按需下载（不用的用户不下载）；专化是模型落到具体设备上的深度编译（第一次最慢）；预编译 + 首次运行体验把首次加载从 8 秒压到 0.8 秒、把等待藏进功能介绍页。
   
6. KV 缓存解决 Transformer 越推理越慢——根因是 Transformer 注意力计算相对序列长度是二次方复杂度。KV 缓存把已计算过的 Key/Value 存起来，下次直接复用，把复杂度从二次方降为线性。Core AI 原生支持 KV 缓存状态管理（Core ML 不支持）。
   
7. M5 神经加速器比 M4 快近 4 倍——藏在 GPU 每个着色器核心里的专用硬件模块，专门加速大语言模型预填充阶段的密集运算。配合 MLX 框架的专用乘法和注意力内核，不需要改任何代码自动启用。
   
8. Metal 原生支持量化张量——GPU 硬件直接处理 INT4/INT8/FP4/FP8 数据类型，无需在计算前反量化。多平面张量设计让数据平面和缩放平面合二为一。FlashAttention 把注意力计算三步（算相关度 → 归一化 → 按权重取内容）融合成一个内核，中间结果留在 GPU 寄存器不进主内存。
   
9. 软硬件同步迭代是苹果独有壁垒——M5 神经加速器发布时 MLX 已为它写好专用内核，Metal 升级时 Core AI 工具链已能用新能力压缩模型。业界其他玩家都不同时具备芯片+框架+模型+操作系统+产品的垂直整合能力。
   
10. 设备端 4K vs 云端 32K Token 是产品思维的体现——Foundation Models 框架的设备端模型上下文窗口 4K Token（约 3000-4000 字），PCC 云端模型 32K Token。这是苹果权衡内存占用和日常需求后的「甜点值」——能覆盖绝大多数日常场景，又不至于把内存吃光。需要长上下文或深度推理时自动路由到 PCC。
    
11. 苹果把复杂性吞进黑盒——量化/拆分/部署/KV 缓存/硬件加速等十层工程嵌套，全部吞进 Core AI 工具链、Foundation Models 框架、MLX、Metal、iOS 等基础设施。开发者拿到的只是三行 Swift 代码，用户拿到的只是两秒钟的 Siri 回答。这是苹果产品思维在端侧 AI 部署上的彻底落地。
    

下一篇预告

这一篇我们拆了「苹果怎么把 3GB 模型塞进手机，还让你感觉不到卡」——量化、拆分、部署、KV 缓存、硬件协同这一整套组合拳。

但这里还有个隐而未决的问题——苹果不让开发者只塞一个模型。

业界某主流云厂商前不久发布报告说，开发者平均要在 App 里集成 3-5 个不同任务的小模型——一个做摘要，一个做翻译，一个做图像理解，一个做代码生成……每个模型都要量化、都要加载、都要占内存。如果你是开发者，你怎么在 iPhone 里把这些模型管理好？什么时候用哪个？什么时候该卸载？

苹果的答案是一个系统级的服务——模型柜。它不是让你自由乱选，而是苹果帮你把模型按任务、按大小、按能耗分门别类，给开发者一个清晰的「点单菜单」。开发者不用关心底层有多少模型、每个模型量化到什么精度，他只需要说「我要做摘要」——苹果自动给你派一个最合适的模型。

下一篇我们专门拆——苹果的模型柜：它给你选，但不让你迷路。

本篇生词表

• 量化（Quantization）：把 AI 模型权重从高精度（如 16 位浮点）压到低精度（如 4 位整数）的过程，体积缩小 4-8 倍。代价是精度损失。比喻：把 4K 高清照片压成 JPEG——体积大幅缩小，远看几乎没区别，放大看细节才能感受到损失。
  
• 浮点数（Floating Point）：电脑存小数的标准方式。16 位浮点（FP16）每个数占 2 字节，精度高；4 位整数（INT4）每个数占 0.5 字节，精度低但体积小。
  
• INT4 / INT8 / FP4 / FP8：不同的量化精度档位。INT 代表整数存储，FP 代表浮点存储；数字代表位数。位数越低，体积越小，精度越差。
  
• 缩放因子（Scale Factor）：量化后用来恢复原始范围的「尺子」。量化值是刻度，缩放因子告诉你每个刻度对应原始范围里的多少。
  
• 调色板量化（Palettization）：一种不同于直接截断精度的量化方法。把相似的权重归为一组用同一个代表值替代——就像画家调色板上的颜色，画面里几百万个像素但实际用到的颜色可能就 256 种。在 iOS 低功耗场景下表现好。
  
• 选择性量化（Selective Quantization）：不对模型一刀切采用同一种压缩策略，而是对不同模块采用不同策略。SAM3 案例中，图像/文本编码器用 INT4 大幅压缩，Detector 保持原始精度。
  
• SAM3（Segment Anything Model 3）：业界某实验室开源的视觉分割模型，给一张图片加提示词就能精准圈出对应区域。原始体积 3GB+，是 WWDC26 Core AI session 现场演示量化的样本案例。
  
• Core AI Debugger：苹果 WWDC26 发布的独立工具，把模型内部打开让你看见每一层的中间计算结果。按相似度排序定位「哪个模块被压缩得最狠、丢了最多精度」。
  
• 张量（Tensor）：你可以把它理解为一个多维数组——就像一张彩色照片是三维的（长 × 宽 × 颜色），模型里的张量是更高维的数据块，几维都可能，是模型内部传递和计算信息的基本容器。
  
• 模型拆分（Function Decomposition）：把一个一整块的模型拆成多个独立函数，每个函数独立调用、独立压缩、独立优化。SAM3 拆成 image_encode / text_encode / detect 三函数后，换提示词时第二次推理快 76%。
  
• Background Assets：苹果提供的框架，让大模型不打包进 App 安装包，等用户首次使用 AI 功能时才在后台下载。避免所有用户都下载大包体。
  
• 专化（Specialization）：通用的 .aimodel 模型文件落到具体设备上后，针对该设备的芯片架构和系统版本做深度编译优化的流程。专化完成后结果被系统缓存，后续加载从缓存读取速度很快。第一次专化最耗时。
  
• 预编译（Ahead-of-Time Compilation）：用 coreai-build 命令在开发者的 Mac 上提前为不同设备架构生成预编译版本，把专化的大头工作做掉。用户设备上只剩最终专化，速度大幅加快。
  
• KV 缓存（Key-Value Cache）：Transformer 注意力计算的中间结果缓存。把已算过的 Key/Value 存起来，下次生成新词时直接复用，避免重算历史。让 Transformer 推理复杂度从二次方降为线性。
  
• Transformer：当下所有主流大模型（包括苹果自家的 AFM、业界各家大模型）共同使用的架构。核心机制是注意力计算——模型生成每个词时都要回头看历史所有词。
  
• 注意力计算（Attention）：Transformer 的核心运算。模型判断历史中哪个词跟当前要生成的词关系更紧密的算法。分三步：算相关度 → 归一化 → 按权重取内容。
  
• FlashAttention：把标准注意力计算的三步融合成一个 GPU 内核的算法。中间结果留在 GPU 寄存器和线程组内存里，不经过主内存，大幅减少内存搬运。比喻：三台分别处理原料的机器合并成一台多功能料理机。
  
• 神经加速器（Neural Accelerator）：M5 芯片引入的专用硬件模块，藏在 GPU 每个着色器核心里。专门加速大语言模型预填充阶段的密集运算。配合 MLX 专用内核，提示处理速度比 M4 快近 4 倍。
  
• 预填充（Prefill）：用户给大模型发一句话时，模型先把这句话从头处理一遍（理解每个词、建立上下文）的阶段。预填充速度决定了用户从「发送」到「看到第一个字」的等待时间。
  
• 矩阵乘法：AI 模型内部最常见、最耗算力的运算——一大批数字同时按规则做乘法和加法。工程上经常用「张量」这种多维数组来表达参与运算的数据。
  
• Metal：苹果的图形和计算 API（应用程序接口），开发者用它直接调用 GPU 算力。WWDC26 后 Metal 原生支持 INT4/INT8/FP4/FP8 量化数据类型。
  
• TensorOps：基于 Metal 着色语言的张量运算 API，提供矩阵乘法、卷积等核心操作。自动利用所有 Apple Silicon GPU 世代的硬件加速，包括 M5 神经加速器。
  
• 多平面张量（Multi-plane Tensor）：一个张量对象同时包含数据平面（存量化权重）和缩放平面（存缩放因子）的设计。两者打包在一起，使用时无需额外处理。
  
• Foundation Models 框架：WWDC26 之前已发布的面向 iOS/macOS 开发者的 AI 模型调用框架。让开发者几行 Swift 代码就能调用 AFM 端侧推理能力。提供 LanguageModelSession、respond、contextSize 等核心 API。
  
• 上下文窗口（Context Window）：模型一次能处理的最大 Token 数。设备端 AFM 是 4K Token，PCC 云端是 32K Token。Token 是模型处理文本的最小单位，一个汉字大约对应 1-2 个 Token。
  
• Reasoning（推理级别）：PCC 云端模型支持的三档「让模型想一想再回答」的能力——light（简单查询）/ moderate（中等推理）/ deep（复杂多步推理）。设备端模型不支持 Reasoning。
  
• Core AI：WWDC26 发布的苹果全新端侧 AI 推理框架，专为 Transformer 时代设计（对比 Core ML 是为传统静态模型设计）。提供转换、压缩、运行、部署全流程工具链。
  
• AFM（Apple Foundation Models）：苹果自研的基础模型，端侧版本业界推测约 3B 参数。是 Apple Intelligence 的核心底座。
  
• PCC（Private Cloud Compute）：苹果自建的专用云端 AI 计算服务，用于处理设备端跑不动的复杂任务（长上下文、深度推理）。强调隐私——苹果专用硬件 + 可验证审计。
  
• 垂直整合（Vertical Integration）：一家公司掌控从硬件到产品的多个层级。苹果是典型代表——同时握着芯片设计、Metal 图形 API、MLX 框架、Core AI 工具链、AFM 模型、iOS 操作系统、Apple Intelligence 产品这七层。业界唯一。