MobileLLM-Flash 深度解读：当 Meta 把手机放到架构搜索的中心

> 论文：MobileLLM-Flash: Latency-Guided On-Device LLM Design for Industry Scale Deployment > 作者：Hanxian Huang, Igor Fedorov, Andrey Gromov 等（Meta AI） > arXiv: 2603.15954，Accepted to ACL Industry Track 2026

---

一、从一个让人抓狂的十秒钟说起

你掏出手机，点开那个号称「本地运行」的 AI 助手，输入一句话，然后——等。

一秒。两秒。五秒。十秒。

屏幕上的光标在闪，但什么字都没蹦出来。你开始在脑子里算账：十秒钟，够我发三条微信、查一个快递、甚至泡一杯咖啡。而现在我就站在这里，对着一块黑屏干等。

这就是 TTFT，Time-To-First-Token，首字延迟。它是端侧 AI 的死穴。

有个叫 Nielsen 的人做过研究，说用户能容忍的响应时间上限大概是四秒。过了四秒，体验断崖式下跌。过了十秒？大多数人会开始怀疑设备是不是卡死了。

所以 Meta 这帮人在论文里说的第一句话我就很认同：端侧大模型的核心问题不是「能不能跑」，而是「能不能在四秒内给出第一个字」。

就这么简单。但你猜怎么着？整个行业在此之前，花了好几年时间，在优化一个和这个问题几乎无关的指标。

二、货物崇拜：当大家都在拜 FLOPs 的时候

我在巴西教过书，见过 cargo cult。

岛民们看见美军建了机场，飞机就来送物资。美军走后，他们也建「机场」——用竹子搭控制塔，用椰子壳做耳机，甚至找人站在「跑道」旁边挥旗子。一切看起来都对。但飞机不会来。

端侧 AI 圈子里也有 cargo cult。大家都在拜一个叫 FLOPs 的神。

论文里给了一组让我笑出声的数据：

指标	与真实 prefill 延迟的相关性（Kendall Tau）
参数量 vs. 延迟	0.40
FLOPs vs. 延迟	0.46（prefill）/ 0.55（decode）

知道 0.40 意味着什么吗？意味着「参数量」和「真实延迟」的关系，差不多和「你今天穿的袜子颜色」与「你考试成绩」的关系一样强。

整个行业设计轻量化模型的时候，想的是「把参数量砍到 1B 以下」「把 FLOPs 降到多少多少」。听起来很专业，对吧？问题是，手机上跑模型的瓶颈根本不是计算量，而是内存带宽和算子调度。

你的模型再「瘦」，如果每一层都要反复读写内存，CPU 的大部分时间其实在等数据。就像你请了一个数学天才来算账，但他每次算完一题都要走去隔壁房间拿纸——天才的脑子再快，也没用。

这就是 cargo cult。形式全对了，核心问题没解决。

Meta 做了一件我认为早该有人做的事：把手机放到架构搜索的正中央。不是拿 FLOPs 当代理指标去猜，而是直接在三星 Galaxy S25 上测了大约八百次真实延迟，然后用这些数据去训练一个高斯过程代理模型。

R² = 0.97。意思是这个代理模型几乎能完美预测任何候选架构的真实延迟。

然后他们用贝叶斯优化去搜索帕累托前沿——在「质量」和「延迟」这两个互相打架的目标之间，找到那些谁都无法再改进的平衡点。

这不是 cargo cult。这是把飞机叫来。

三、为什么「浅而宽」比「深而瘦」快？

好，现在我们来搞清楚这件事。

之前做端侧模型的思路，比如 MobileLLM-Pro，走的是「深而瘦」路线：30 层，每层 1280 维。听起来很合理——层数多，模型能学到更复杂的特征；每层窄一点，参数量可控。

但 Meta 的搜索结果发现，在帕累托最优曲线上，赢家是「浅而宽」——12 到 16 层，但每层更宽。

为什么？

忘掉那些层的抽象概念，想想手机 CPU 在干嘛。

手机芯片不是数据中心里那种有几百 GB/s 内存带宽的怪物。它的内存带宽有限，而且每次计算都要从内存里搬数据。一个「深而瘦」的模型就像一条长长的流水线：数据从第一层流进去，算完，写回内存，再读出来进第二层，再算，再写回……三十次。

每一次读写都是一次「内存旅行」。而手机 CPU 的大部分时间，不是在算，是在等。

「浅而宽」呢？层数少了（比如 12 层），但每次可以处理更多的信息（更宽的 hidden dimension）。数据读进一次，能算更多东西，再写回一次。内存带宽的利用率更高。

论文里有一句话我特别喜欢：在帕累托曲线上，30 层模型（黄色点）确实精度最高，但延迟也最慢；浅层架构（深蓝点）在精度和延迟之间找到了更好的平衡。

这不是直觉，这是数据。他们把候选架构一个一个在手机上演示，测了，记了，画成图。浅而宽在移动端赢，不是因为计算变少了，而是因为内存瓶颈被缓解了。

就这么回事。

四、Skip Attention：为什么不算比少算更好？

好，接下来这个问题更有意思。

大家都在找更高效的注意力机制。Mamba、Linear Attention、Gated DeltaNet……一堆新算子。Meta 说，等等，我们不玩这些。原因很朴素：它们没有成熟的端侧运行时支持。

你做了一个理论上很牛的注意力模块，但 ExecuTorch 不支持，那就是 zero。在工业部署里，「能跑」比「理论上好」重要一百倍。

所以 Meta 在他们的搜索空间里只放了三种 ExecuTorch 原生支持的操作： 1. Full attention（全局注意力） 2. SWA（Sliding Window Attention，滑动窗口注意力） 3. Skip attention（直接跳过 attention 计算）

然后搜索的结果让他们自己都惊讶了：Skip attention 比 SWA 更受青睐。

这什么意思？就是说，在某些层里，干脆不做 attention 了——直接跳过——居然比「做一部分 attention」效果更好。

我一开始也愣了一下。后来看论文的附录才搞清楚 SWA 为什么在 ExecuTorch 上这么尴尬。

事情是这样的：ExecuTorch 对 prefill chunk size 有个约束，SWA 的窗口大小必须 ≥ chunk size。而 Meta 发现最优的 chunk size 是 1024。所以 SWA 的窗口至少也得是 1024。那对于 2K 的 prefill，只有第二个 chunk 能享受到 SWA 的「省算力」好处。第一个 chunk 还是得做完整的 attention。

更糟的是，ExecuTorch 里 SWA 的 ring-buffer 实现需要计算完整的注意力矩阵，而不是像标准 attention 那样只算下三角。所以 SWA 在端侧不但没省多少，反而因为实现开销变慢了。

这就像你开车去邻市，走高速要收费但快，走国道免费但绕。结果你发现高速收费站排队排了半小时，走高速反而更慢。

Skip attention 不一样。它不做 attention，直接跳过。省了算力，省了内存带宽，而且不需要任何新算子——ExecuTorch 原生支持。

但这里有个陷阱，论文诚实地标出来了：不能连续跳过太多层。

模式	TQA	NQ	WinoG
有连续 3+ 层 skip	8.8%	2.5%	59.7%
无连续 3+ 层 skip	33.2%	10.0%	61.2%

看到没？连续跳过三层以上，TQA 从 33.2% 暴跌到 8.8%。模型直接失忆。

所以最优的模式是 交错的：一层 full attention，一层 skip，一层 full attention，再一层 skip……就像心跳一样，不能连续跳太久。

最搞笑的是，这个限制不是从什么理论推导出来的，是搜出来的。贝叶斯优化试了一大堆组合，发现「禁止连续跳过 3 层以上」这条规则能让帕累托曲线往上移。就这么简单粗暴。

五、两阶段搜索：先搞清延迟，再找最优解

让我用我能理解的方式解释他们的搜索流程。

第一阶段： latency 采样。

他们在搜索空间里用 Sobol 准随机采样（一种比纯随机更均匀地覆盖空间的方法），在手机上测了大约 800 个候选架构的真实延迟。然后用这些数据训练一个高斯过程代理模型——一种能给出预测值和不确定性的统计模型。

交叉验证 R² = 0.97。意思是如果模型预测某个架构的 TTFT 是 2.3 秒，实际测出来基本就是 2.3 秒。误差很小。

第二阶段：贝叶斯优化搜索。

现在他们有了一个又快又准的延迟预测器。真正费钱的是什么呢？是评估模型质量——每个候选要训 2.6B tokens 才能知道它的 loss 是多少。

所以搜索策略变成：先用代理模型快速筛选掉那些延迟明显太差的候选（连手机都跑不动的就别浪费 GPU 了），只在「延迟友好」的区域里投入昂贵的质量评估。

他们用 NEHVI（Noisy Expected Hypervolume Improvement）作为采集函数，参考点设为 loss=0.6、TTFT=4 秒。意思就是：我们只关心那些既比 baseline 快、loss 又不至于崩盘的架构。

跑了 200 次试验后，从帕累托最优的候选里挑了三个做最终训练：

Flash-350M
Flash-650M
Flash-1.4B

每个再训 500B tokens 做 CPT（继续预训练），然后再 800B tokens 做 IFT（指令微调）。

注意，整个搜索过程消耗了 200 × 2.6B = 520B tokens。但相比 MobileLLM-Pro 的 1.6T tokens 和 LFM2 的 10-12T tokens，这已经便宜太多了。原因是：不需要从零训练候选，而是从一个 1.8B 的预训练模型剪枝继承权重。

这就像你要造一百辆不同尺寸的车，但不需要每辆都从矿石炼钢开始。你先造一辆大的，然后切一切、拼一拼，继承大部分零件。省料，省时。

六、结果：Flash 到底有多快？

来看三星 S25（骁龙 8 Elite，4-bit 量化，4 CPU 线程）上的实测数据：

模型	TTFT 1K	TTFT 2K	Decode 1K tok/s
Flash-350M	0.91s	2.78s	165.56
Flash-650M	1.62s	3.34s	96.64
Flash-1.4B	3.40s	9.08s	60.52

对比 LFM2（之前最强的端侧模型）：

1.8x prefill 加速
1.6x decode 加速
精度更高或持平

Flash-350M 的 decode 速度达到 165 tok/s。什么概念？人阅读速度大概是 200-300 词每分钟，也就是 3-5 词每秒。Flash-350M 每秒生成 165 个 token，远快于人类阅读速度——这意味着用户体验上，输出几乎是「流式」的，没有等待感。

再看跨设备迁移性。在 S25 上搜出来的架构，放到 iPhone 17 上测，延迟排名保持一致。说明 架构层面的优化有跨平台可迁移性 ——虽然不同芯片上的绝对延迟不同，但相对优劣关系稳定。

这很重要。因为如果搜出来的最优架构只能在一个设备上跑得好，那这个方法论就没法工业化了。Meta 证明了它可以。

七、部署兼容性：为什么「不需要自定义内核」是核武器

论文里有一句话，做工程的人会特别敏感：

> "Our models use only standard operators natively supported by ExecuTorch and thus deploy on any compatible backend."

这什么意思？意思是：

不需要写 CUDA kernel
不需要等 vendor 优化某个新算子
不需要为每个平台单独适配

LFM2 用了 conv1d 算子做它的 gated short convolution attention。这个算子在端侧运行时里支持得不好——小 batch size 和小序列长度上性能很差。所以 LFM2 虽然理论上有创新，但部署时处处受限。

Flash 用的全是标准算子：矩阵乘法、LayerNorm、QK-Norm、Grouped Query Attention……ExecuTorch v1.1.0 原生支持。XNNPACK 后端一编译就能跑。

兼容 CoreML、兼容 Apple Neural Engine、兼容 CPU、兼容 GPU。

这就是「现实优先于叙事」（Reality must take precedence over public relations）。你可以发论文吹一个新算子多牛，但如果厂商的运行时不支持，那就是 zero。Meta 选择了一条看起来更保守、实际上更务实的路。

这也是为什么说他们的方法论是「硬件无关」的——你只需要换一台基准设备重新测延迟，搜索流程本身不需要改。

八、代价：1.1% 的精度换 1.2-1.3x 的加速

Flash-1.4B 和它的「母体」MobileLLM-Pro-Shallow-1.8B 比，平均精度差了 1.1%。

换来的呢？1.2x prefill 加速，1.3x decode 加速。

这个 trade-off 值不值？取决于你要什么。如果你想要最快的端侧响应，那这 1.1% 的精度损失是完全可以接受的。如果你要的是极限精度，那可能还是选更大的模型。

但关键是：这个 trade-off 是帕累托最优的 。意思是，在 Flash-1.4B 这个延迟水平下，你找不到另一个架构能在精度上超过它而不变得更慢。反之亦然。

这就是帕累托前沿的意义：它告诉你「可能的边界在哪里」，让你根据自己的需求选点，而不是在黑暗中瞎猜。

九、论文没说但我们应该想的

Meta 很诚实，在 Limitations 部分列了三条：

第一，没联合优化训练超参数。他们的搜索只搜了架构（层数、宽度、attention 模式），没搜学习率、优化器设置、训练 schedule。理论上，某些架构如果配上专属的超参数，可能还能再好一点。

第二，没探索 SSM 和线性注意力。Mamba2、Gated DeltaNet 这些新机制被排除在外，原因是「缺乏成熟的运行时支持」。但这是一个有意为之的限制——他们追求的是「现在就能部署」，不是「未来可能更好」。

第三，帕累托最优架构对 CPU 和 ANE 不同。在三星 S25 上搜出来的最优架构，放到 Apple Neural Engine 上可能不是最优的。虽然延迟排名能迁移，但绝对最优解是平台相关的。

这三条限制我觉得都不是真正的「缺陷」，而是 清醒的边界划定。做工程的人都知道，不画边界的东西永远做不完。Meta 画了一条清晰的线：我们只优化能现在部署的、只用标准算子的、只在 CPU 上测的。

线内做到极致。线外留给未来。

十、费曼会问的最后几个问题

让我用我自己的方式再审视一遍这项工作。

他们真的理解了吗？还是只记住了名字？

他们理解了。从 FLOPs 的 cargo cult 里走出来，直接用真实延迟当目标函数，这是理解的表现。他们知道手机上的瓶颈不是计算，是内存带宽和调度。

这个能解释给大一新生听吗？

能。核心思想就一句话：「别在纸上算 FLOPs 了，把手机拿出来，真的测一下。」

有没有更简单的方法能达到同样的效果？

这是个好问题。两阶段贝叶斯优化 + 800 次手机实测 + 200 次候选训练，听起来还是很重。有没有可能用更便宜的代理来减少手机实测次数？比如用指令级模拟器？Meta 没探索这个方向，但值得有人去做。

关键结论经得起检验吗？

浅而宽 > 深而瘦：有跨设备的迁移实验支持。 Skip attention > SWA：有 ExecuTorch 的具体限制解释。 FLOPs 是糟糕代理：有 100 个架构的 Kendall Tau 数据。

这些不是观点，是观测。经得起检验。

结语

Meta 的 MobileLLM-Flash 不是一个「更小的模型」。它是一个用真实硬件重新定义了「效率」的模型。

整个行业之前都在优化代理指标——参数量、FLOPs、理论计算量——就像 cargo cult 里用竹子搭控制塔。Meta 的做法是：把手机放到搜索的中心，让延迟和质量直接对话，然后让贝叶斯优化去找那个谁也打不过的平衡点。

结果出来的设计原则很简单：浅而宽，交错 skip attention，不要连续跳过三层以上，只用标准算子。

简单到让人怀疑是不是太简单了。但这就是我想说的——真正理解了的东西，说出来总是简单的。

那些需要十八个希腊字母、三段数学推导才能讲清楚的「效率」，大概率是没理解。

Meta 理解了吗？

我觉得他们理解了。至少，他们把手机从口袋里掏了出来。

---

#端侧AI #MobileLLM #MetaAI #小凯 #分析