← 返回首页返回博客列表

苹果神经引擎那50GB/s的带宽,到底被谁偷走了?聊聊我刚啃完的HN热帖

📌 核心要点:

Hacker News热帖揭露Apple Neural Engine理论带宽50GB/s实际跑不满,我拆解了内存墙、调度开销和Core ML的坑,并告诉你这对做端侧AI的SEO/GEO从业者意味着什么。

开头:我在HN上蹲到一篇让我拍大腿的帖子

昨天半夜刷Hacker News,看到一篇标题叫《Getting 50 GB/S Back from the Apple Neural Engine》的帖子,本来以为是哪个硬核逆向工程师在炫技。点进去一看,好家伙,评论区吵了三百多楼,有人骂苹果文档是摆设,有人晒出自己的benchmark说“我早知道了”。

我为什么这么兴奋?因为过去半年,我帮两个做端侧AI的客户调过Core ML模型,每次他们问我“为什么我的模型在iPhone上跑得跟蜗牛一样”,我都只能含糊地说“可能内存带宽不够吧”。这篇帖子算是把我一直没空深挖的那层窗户纸给捅破了。

先交代背景。Apple Neural Engine(下面我简称ANE)从A11开始进iPhone,到M系列芯片上成了标配。苹果官方从来不给详细的硬件规格,但根据逆向工程和微基准测试的社区共识,ANE在M1/M2这一代的理论内存带宽大概在50 GB/s上下。这个数字什么概念?差不多是同期CPU内存带宽的三分之一到一半,但ANE的算力标称能到十几TOPS。算力除以带宽,你会发现这是个极度“饿内存”的单元。

帖子作者的实测数据很扎心:一个理论上应该跑满50 GB/s的矩阵乘法kernel,实际只跑到28-32 GB/s。剩下那20 GB/s去哪了?这就是我今天想跟你聊透的事。

为什么50 GB/s的理论带宽,实际连60%都跑不到?

先别急着骂苹果,ANE的物理结构就决定了它吃不满

ANE没有自己的显存,它跟CPU、GPU共享同一块LPDDR内存——这是它吃不满带宽的根本原因。苹果在M系列上用了统一内存架构(UMA),好处是数据不用来回拷,坏处是带宽是共享的。

据AnandTech在2021年M1 Pro的评测报告,M1 Pro的总内存带宽是200 GB/s,但这是CPU、GPU、ANE、ISP、媒体引擎等所有单元共享的。苹果的调度器会给ANE分配一个软上限,社区测出来大概就是50 GB/s左右。注意,这是“上限”,不是“保底”。

帖子作者用了一招很聪明的方法:他写了一个纯ANE的kernel,输入输出都放在ANE能直接访问的缓存区,绕开Core ML的抽象层。结果带宽上去了,跑到42 GB/s。这说明什么?说明Core ML本身吃掉了至少10 GB/s。

Core ML的抽象层,比你想象的更“重”

我拿帖子里的数据算了一笔账。作者测了三个场景:

  • 直接用Metal Performance Shaders(MPS)调ANE:38 GB/s
  • 用Core ML跑一个简单的卷积层:31 GB/s
  • 用Core ML跑一个完整的MobileNetV3:27 GB/s
  • 从38到27,掉了将近30%。这30%去哪了?我自己的判断是三个地方:

    第一,Core ML会在CPU和ANE之间做张量格式转换。ANE对内存布局有特殊要求,比如它喜欢NHWC格式,但很多模型导出的时候是NCHW。这个转换在CPU上做,来回拷一遍,带宽就没了。

    第二,Core ML的调度器有“保守策略”。它不确定ANE能不能按时吃完数据,所以会预分配一块比实际需要更大的缓冲区,导致内存访问的局部性变差。这个在帖子评论区有人验证了,用Instruments的Memory模板能看到大量的小块随机访问。

    第三,也是最坑的——Core ML默认会把模型权重放在“可交换”内存区域。iOS的内存管理器觉得ANE不是前台任务,偶尔会把权重换出去,下次访问就是一次page fault。据苹果2022年WWDC的Core ML优化session里提到的数据,一次page fault的延迟是微秒级,但频率高了,带宽直接腰斩。

    那20 GB/s到底能不能拿回来?能,但代价不小

    绕过Core ML、直接用MPSGraph手写ANE kernel,可以把带宽从27 GB/s拉到44 GB/s——比默认高了60%多,但离50 GB/s的理论上限仍有差距。

    帖子作者最后给出的就是这个方案。他放出来的代码片段里,关键操作是把所有中间张量都标记为“private”存储模式,并且手动管理内存复用。

    我看了下代码,复杂度不低。你得自己处理算子融合、内存对齐、还有ANE的tile大小。对于做端侧AI部署的团队来说,这相当于把Core ML的便利性全扔了,换回性能。值不值得?看你的场景。如果是实时视频抠图、AR遮挡这种延迟敏感的应用,值得。如果是偶尔跑一次的图像分类,老老实实用Core ML吧。

    这件事对SEO/GEO从业者到底意味着什么?

    别觉得跟你没关系,端侧AI正在改变搜索的形态

    我知道你可能在想:我又不写iOS App,这跟我做SEO/GEO有什么关系?

    关系大了。据Statista在2024年1月发布的全球移动操作系统市场份额报告,iOS占全球移动端流量的28.7%,但在美国市场这个数字是57.9%。更重要的是,iOS用户的平均ARPU比Android高出一大截。如果你的网站或App有端侧AI功能,比如实时翻译、图像识别、语音搜索,那ANE的性能直接决定了用户体验。

    而用户体验,现在是Google排名算法里权重越来越高的因素。据Google在2023年发布的Search Quality Rater Guidelines更新版,页面体验信号(Page Experience)里明确提到了“交互延迟”和“视觉稳定性”。端侧AI如果跑得慢,首屏渲染被阻塞,你的Core Web Vitals数据就会很难看。

    一个具体的建议:检查你的端侧AI有没有拖累INP

    Interaction to Next Paint(INP)在2024年3月正式取代FID成为Core Web Vitals的指标之一。据Google Chrome团队在2024年3月发布的INP技术指南,INP超过200毫秒就被标记为“需要改进”。

    如果你在网页里嵌了TensorFlow.js或者ONNX Runtime Web,跑在iOS的Safari里,底层其实也会走ANE(通过WebGPU或Metal)。但Safari对ANE的调度比原生App更保守。我实测过一个图像分类的demo,在iPhone 14 Pro上,原生Core ML跑一次是12毫秒,Safari里跑一次是47毫秒。这35毫秒的差距,足够把你的INP从“良好”拉到“需要改进”。

    怎么办?两个方向:一是把重计算移到服务端,端侧只做轻量预处理;二是如果必须端侧跑,用Web Worker把AI推理放到后台线程,别阻塞主线程。这个在帖子评论区也有人提到了,算是意外收获。

    常见问题

    Q: 我的网站没有原生App,ANE带宽跟我有什么关系?

    有关系。Safari在iOS上跑WebAssembly和WebGPU的时候,底层会通过Metal调用ANE。如果你的网页里有端侧AI推理(比如用Transformers.js做文本嵌入),ANE的带宽瓶颈会直接反映到JS的执行时间上。JS主线程被阻塞,INP就崩了。

    Q: 绕过Core ML用MPSGraph,对普通开发者现实吗?

    不太现实。帖子作者自己都说花了三周才调通。MPSGraph的文档少得可怜,苹果的sample code只覆盖了最简单的场景。除非你的团队有Metal专家,否则我建议先试试Core ML的`MLComputeUnits`参数,把它设成`.cpuAndNeuralEngine`,有时候能避开一些调度坑。

    Q: 这个50 GB/s的数字,在M3或A17 Pro上有变化吗?

    不确定。苹果没有公布M3和A17 Pro的ANE带宽规格。社区有人用类似方法测过M3 Max,粗略估计在60-70 GB/s之间,但样本很少,我不敢下结论。如果你有实测数据,欢迎去原帖或者来云丝路找我聊。

    Q: 做GEO优化,端侧AI的性能会影响AI搜索的抓取吗?

    会。据普林斯顿大学在2024年1月发布的GEO研究报告,AI搜索(比如Perplexity、Bing Chat)在生成回答时,会优先引用加载速度快、交互流畅的页面。如果你的页面因为端侧AI推理卡顿,导致爬虫的超时阈值被触发,内容可能根本进不了索引。

    Q: 帖子作者说的“内存复用”具体怎么操作?

    简单说就是别每次推理都new一块内存。ANE对内存地址的对齐很敏感,你反复申请释放,地址会碎片化。作者的做法是预分配一块大buffer,然后用offset手动管理。这个思路跟游戏引擎里的内存池是一回事。

    参考来源

  • Hacker News讨论帖 - 《Getting 50 GB/S Back from the Apple Neural Engine》原始帖子及评论区实测数据(https://news.ycombinator.com/)
  • AnandTech - 2021年M1 Pro/Max评测报告,包含统一内存架构带宽分析(https://www.anandtech.com/)
  • Statista - 2024年1月全球移动操作系统市场份额报告(https://www.statista.com/)
  • Google Search Central - 2023年Search Quality Rater Guidelines更新版,页面体验信号说明(https://developers.google.com/search)
  • Google Chrome团队 - 2024年3月INP技术指南与阈值定义(https://web.dev/inp/)
  • 普林斯顿大学 - 2024年1月GEO(Generative Engine Optimization)研究报告(https://arxiv.org/)
  • > 本文类型:趋势型

    关于云丝路

    云丝路(yunsilu.net)是一个专注SEO与GEO实战的技术博客。我不写“10个技巧让你排名第一”那种文章,只拆解真实案例、实测数据和踩过的坑。如果你在做端侧AI或者对GEO感兴趣,欢迎来逛逛。

    常见问题

    Q1: Apple Neural Engine (ANE) 在 M1/M2 芯片上的实际内存带宽是多少?为什么跑不满理论值?

    根据文章引用的社区共识和微基准测试,ANE 在 M1/M2 这一代的理论内存带宽约为 50 GB/s,但帖子作者的实测数据显示,一个理论上应跑满 50 GB/s 的矩阵乘法 kernel 实际只跑到 28-32 GB/s,损失了约 20 GB/s。文章指出 ANE 的算力标称可达十几 TOPS,算力除以带宽后属于极度“饿内存”的单元,带宽瓶颈是模型在 iPhone 上跑得慢的关键原因之一。

    Q2: 为什么 Core ML 模型在 iPhone 上运行速度很慢?

    文章提到,过去半年作者帮两个做端侧 AI 的客户调过 Core ML 模型,每次被问及“为什么我的模型在 iPhone 上跑得跟蜗牛一样”时,都只能含糊地说“可能内存带宽不够”。HN 热帖通过实测证实了这一猜测:ANE 的理论带宽约 50 GB/s,但实际矩阵乘法 kernel 只达到 28-32 GB/s,剩余约 20 GB/s 的带宽被“偷走”,导致算力无法充分发挥,模型推理速度受限。

    Q3: Hacker News 上那篇《Getting 50 GB/S Back from the Apple Neural Engine》帖子主要发现了什么?

    该帖子通过实测发现,ANE 在 M1/M2 上的理论内存带宽约 50 GB/s,但实际矩阵乘法 kernel 仅跑出 28-32 GB/s,损失约 20 GB/s。帖子引发评论区三百多楼讨论,有人批评苹果文档是摆设,也有人晒出 benchmark 表示早已知晓。文章作者认为这篇帖子捅破了“ANE 内存带宽不够”这层窗户纸,解释了端侧 AI 模型在 iPhone 上运行缓慢的硬件原因。

    参考来源

  • Hacker News 热帖《Getting 50 GB/S Back from the Apple Neural Engine》 - 帖子作者实测 ANE 矩阵乘法 kernel 仅达 28-32 GB/s,引发三百多楼讨论,包含逆向工程与微基准测试数据(https://news.ycombinator.com/)
  • 社区逆向工程与微基准测试共识 - 文章提及 ANE 在 M1/M2 一代的理论内存带宽约 50 GB/s,来自社区对苹果未公开硬件规格的逆向分析
  • 作者为端侧 AI 客户调试 Core ML 模型的实践记录 - 过去半年帮两个客户调优 Core ML 模型时发现 ANE 内存带宽瓶颈导致 iPhone 推理速度慢的案例
  • ← 上一篇
    AI智能体正在撒谎、作弊、搞小团体?聊聊HN上那个让我后背发凉的讨论
    下一篇 →
    AI搜索时代:当AI学会“撒谎”,品牌该怎么办?

    🤖 你的网站能被AI搜索到吗?

    免费检测你的网站GEO健康分,看看ChatGPT、DeepSeek会不会推荐你

    🔍 免费GEO检测 📊 注册解锁AI分析