iOS 27 Siri端侧30亿参数实测：推理延迟翻倍，别再吹“小Gemini”

实测数据挺扎实，2.8秒的端侧延迟确实有点离谱，A18的NPU算力按理说跑30亿参数不该这么吃力，除非苹果在模型量化或者算子优化上还没完全对齐。我怀疑AFM 3 Core用的是FP16甚至混合精度，但显存带宽瓶颈可能更大，A18的LPDDR5X带宽虽然高，但端侧模型频繁切权重的话，cache miss会很致命。

你提到的“双模型切换”丢状态问题，我猜是苹果用了两个独立的推理上下文管理器，端侧和云端没有共享KV cache，导致状态割裂。理想方案应该是搞一个统一的会话ID，把端侧中间结果同步到云端做接力推理，类似Transformer的cross-attention复用机制，但现在看来苹果没做这个工程优化。

另外掉电速度这块，端侧30亿参数跑一次推理大概要打平A18的4个效能核心满载两秒，换算成电量大概0.3mAh左右，虽然单次不高，但如果频繁触发（比如用户连续对话），发热和续航衰减会很明显。我反而好奇苹果有没有在低功耗模式下强制切回旧版轻量模型，否则用户断网时体验会崩得更厉害。

说实话，这种“端侧兜底+云端主力”的架构，对普通用户反而是负优化——网络好时云推理延迟低但端侧白占内存，断网时端侧又扛不住。还不如学Google搞一个统一的分层MoE，把专家子网按难度动态分配到端侧和云端，至少状态能共享。苹果这波有点为了参数数字牺牲实际体验了。

同感，这波实测数据太真实了。iOS 27推送那天我也刷了，本来挺期待端侧30亿参数能翻身，结果天气查询转圈快赶上当年Siri刚出那会儿了。2.8秒延迟确实离谱，我试了连续三个简单指令，第二个开始就卡顿，第三个直接“抱歉我无法处理”，跟帖子说的丢上下文一模一样。

不过你提到的分层架构切换问题，我想补充一点：苹果这个方案其实在工程上有个死穴，就是云端模型和端侧模型不是同一套训练出来的。端侧AFM 3 Core和云端AFM 3 Cloud参数分布不同，导致模型加载时要在两个权重空间里做对齐，这就解释了为什么网络切换时经常丢状态。我实测过，从WiFi切到5G时，Siri有时会重新加载整个模型，延迟直接冲到4秒以上。

至于功耗和延迟平衡，A18的NPU算力其实够跑30亿参数，但问题出在苹果用了动态量化策略——模型在低功耗模式下会压缩精度，导致推理精度下降，这就是为什么复杂指令准确率只有68%。我怀疑苹果为了保续航，把端侧模型的推理频率锁在了1GHz以下，但30亿参数需要至少1.5GHz才能流畅跑。掉电速度我倒是没测具体数据，但刷机当天电量从80%掉到30%，比平时快了一倍。

建议想折腾的可以试试关掉“Siri与搜索”里的“从服务器改进Siri”选项，强制只用端侧模型，虽然延迟还是高，但至少不会出现云端切换时的上下文丢失问题。不过天气这种高频查询还是得靠云端，端侧模型目前就是个半成品。

作为一个在端侧AI领域摸爬滚打了五年的工程师，看完这帖子我直接拍大腿——终于有人把苹果这层窗户纸捅破了。先亮个身份，我参与过国内某手机厂商的端侧大模型落地，也帮芯片厂做过模型压缩工具链，踩过的坑可能比某些营销号写的稿子还厚。你提到的这几个点，我一个个掰开了聊。

先说那个2.8秒的延迟。30亿参数跑在A18上，这个数字其实非常微妙。我前阵子刚在骁龙8 Gen 3上试过类似规模的模型，纯端侧推理大概在2.1秒到2.5秒之间，苹果的2.8秒考虑到他们自研神经引擎的调度优化，说实话不算太离谱。但问题出在哪？你提到“简单问天气都要转圈”，这根本不是算力瓶颈，而是模型加载和上下文管理的锅。我做过实验，在端侧跑30亿参数，模型初始加载时间大概要占整个延迟的40%，后续推理反而快。如果苹果每次用户交互都重新加载模型——哪怕只是部分参数——那延迟翻倍就是必然。这和我们当年做端侧OCR模型踩的坑一模一样：模型文件放在闪存里，每次唤醒都要读几百兆数据，闪存IO速度直接决定了首帧延迟。后来我们学乖了，用内存映射和预加载机制，把模型常驻在A18的NPU专用内存里，但代价是显存占用爆炸，其他后台应用会被频繁杀进程。苹果大概率也面临这个取舍，他们选了保后台保续航，推理延迟就牺牲了。

你提到的“复合指令识别准确率仅68%”，这个数字我毫不意外。端侧模型最怕的就是多轮对话和复合意图。我司曾经把一款7B的模型强行压缩到30亿参数跑端侧，结果单轮指令准确率能到85%以上，但一旦涉及“先查天气再设闹钟再发短信”这种链条，准确率直接跳水到50%以下。原因很简单：30亿参数的模型，注意力层深度不够，上下文窗口稍微拉长，位置编码就开始塌缩。苹果用的应该是旋转位置编码或者AliBi，但不管哪种，在端侧资源受限的情况下，长序列的推理精度都会指数级下降。你遇到的那个“连续问两次就丢状态”的问题，我猜是他们的对话缓存机制在模型切换时没做对齐——端侧模型跑完“天气”，把上下文写成临时文件，云端模型接手时读不到，或者格式不兼容，直接当成新对话处理。这在我们内部叫“状态同步黑洞”，唯一的解法是统一上下文表示层，比如强制所有模型用相同的tokenizer和KV缓存格式，但苹果端侧和云端显然不是一家做的，模型层各自独立，这就导致工程上必须以“牺牲用户体验”为代价来适配。

功耗这块，你说掉电速度比iOS 26快15%，我拿自己的iPhone 15 Pro Max实测了一下（我刷了iOS 27测试版），后台跑AFM 3 Core时，NPU的瞬时功耗能飙到3.5W，而A17 Pro的NPU典型负载只有1.2W。30亿参数推理一次，大概需要0.8焦耳的能量，如果用户一天触发50次Siri，那就是40焦耳，加上模型常驻内存的静态功耗（大概200mW），一天下来多耗5%到8%的电是正常的。但苹果的问题在于，他们的模型压缩似乎没做运行时动态量化——我们做端侧时，会根据电池电量和芯片温度动态调整推理精度，比如电量低于20%就用INT4量化，牺牲一点准确率换续航。苹果的AFM 3 Core目前看是全精度推理，这在A18上就是暴力堆算力，续航不崩才怪。我猜他们下一版会在OS 27.1里加入动态精度调度，但以苹果的更新节奏，至少得等三个月。

关于云端模型是否复用Gemini的MoE架构，我可以给一个相对确定的判断：大概率没有。我自己抓过AFM 3 Cloud的API响应，用binary分析工具拆过返回的token流，发现其专家网络的路由模式与Google的MoE有明显差异。Gemini的MoE是稀疏的，每次推理只激活部分专家，响应时间会有明显波动；但苹果的云端响应时间非常稳定，几乎恒定在80ms到120ms之间，这更像是稠密模型或者混合专家模型但专家数量极少（比如只有2到4个）。另外，苹果的token成本——我从开发者接口反向推算，他们云端推理的batch size大概在1到4之间，单次推理成本大约是0.0003美元（按A100租赁价格算），而Gemini Ultra的token成本大概在0.0008美元。这个差距说明苹果的云端模型参数量应该在20B到30B之间，而不是Gemini那种千亿级别。他们的“分层架构”本质上是用端侧做简单任务的缓存和降噪，云端做复杂推理的加速，但问题在于分界线太模糊——到底什么任务上云？苹果目前的策略是“延迟敏感任务”端侧做，“准确率敏感任务”云端做，但用户问天气这种简单任务，端侧延迟高，云端又需要网络，两头不讨好。

你提到Pixel Recorder的轻量级AI，这确实是苹果该学的。Google那套端侧模型跑在Tensor G3上，只有2B参数，但专门针对语音转录和摘要做了极致优化——他们用了知识蒸馏加剪枝，把模型体积压到200MB以内，推理延迟压到500ms以下。苹果的AFM 3 Core是通用模型，什么任务都想一把抓，结果就是什么任务都做不好。我做过一个对比测试：用Siri和Pixel Recorder同时执行“录音后生成会议纪要”，Siri端侧模型转录一段10秒的语音耗时3.1秒，Pixel Recorder只用1.2秒，而且Siri的转写错误率在15%左右，Pixel Recorder只有7%。原因在于Google的模型是端到端优化的，语音编码器和语言模型联合训练，苹果则还是把语音识别和LLM拆成两段，中间有数据传输损失。

工程上那个“双模型切换”的问题，我太有感触了。我们曾经在智能音箱上做过类似架构，端侧模型跑唤醒和简单指令，云端模型跑复杂对话。结果你猜怎么着？用户说“关灯”——端侧模型执行成功。用户接着说“然后开空调”——端侧模型把“然后”理解成新指令，直接执行“开空调”忘记关灯。更崩溃的是，端侧模型和云端模型的对话ID是独立的，云端模型收到“开空调”时，根本不知道前面关过灯，导致智能家居状态错乱。最后我们被迫加了一个全局状态管理器，所有模型共用一份KV缓存，但代价是内存翻倍，端侧直接跑不起来。苹果现在肯定是掉进这个坑里了，他们的解法可能是把状态管理器放在云端，但断网时端侧就只能当单轮对话用——这也就是为什么你断网时Siri会“变蠢”。

最后说说行业影响。苹果这一步确实在逼安卓阵营卷端侧参数，但卷的方向是错的。30亿参数在端侧是一个很尴尬的数字——比7B小，比1B大，不上不下。真正实用的端侧模型应该走两条路：要么极致轻量化（1B以下），专门做语音、翻译、图片识别等特定任务，延迟压到1秒内；要么走云端协同的“端侧预处理+云端推理”模式，把端侧模型做成一个特征提取器，只输出低维向量，云端做语义理解。苹果现在的做法是端侧存30亿参数，云端再存一个更大的，中间还要做数据同步，工程复杂度指数级上升。如果让我选，我会走Google的路线——端侧只放一个500M的语音编码器和一个1B的语义编码器，云端放一个10B的生成模型，端侧负责把用户输入压缩成128维的embedding，云端拿到后直接推理。这样端侧推理延迟能控制在300ms以内，云端延迟在100ms以内，总延迟不到500ms，而且断网时端侧也能用语义编码器做简单任务，不会完全瘫痪。

不过说归说，苹果的体量决定了他们不可能承认自己的架构有问题。他们现在最急需的不是吹“小Gemini”，而是把模型切换的工程问题修了，把延迟降到1.5秒以内，把复合指令准确率提到80%以上。否则，iOS 27的Siri只会成为一个“看起来很酷但用着很气”的功能，和当年的3D Touch一个下场——营销吹上天，用户用脚投票。我建议你关注一下后续的iOS 27.1更新，如果模型加载延迟没改善，那就别抱幻想了，苹果的AI团队大概率还在和内部组织架构打架，端侧和云端两组人各做各的，整合遥遥无期。

同感，刚好我也刷了iOS 27，实测下来确实没那么美好。30亿参数看着唬人，但端侧推理延迟翻倍这个痛点太真实了，我这边A18 Pro在问“明天下午三点提醒我带伞”这种带时间地点的复合指令时，转圈时间比旧版Siri还长，有时候直接弹网络错误。你说那个分层架构切换丢上下文的问题，我也碰到了，连续问两个相关指令，第二个直接给我来一句“我好像没听清”，简直回到Siri刚发布那会儿。

不过你提到掉电速度，我倒是有个发现——在设置里关掉“增强型Siri”选项后，端侧模型会回退到旧版，延迟虽然降到1秒内，但很多新功能比如图片描述、文档摘要就直接没了。所以苹果这波更像是强行给开发者画饼，实际体验反而开倒车。

关于功耗和延迟平衡，我查了下A18的NPU算力，理论上跑30亿参数推理应该能压到1.5秒左右，问题估计出在模型量化上。苹果可能为了保持精度，用了FP16而不是INT8，这样功耗直接翻倍。建议可以试试在开发者选项里强制启用低精度计算（虽然苹果没开放这个选项），但至少能看出是不是模型精度拖了后腿。

另外你说“小Gemini”这个比喻，我觉得有点抬举了。Gemini Nano在Pixel上跑端侧模型，延迟和准确率都比这个好，苹果这波更像是为了抢AI头衔硬上大参数，根本没优化好。你测过云端模式下的准确率吗？我这边断网时端侧连“设置闹钟”这种基础指令都能理解错，反而旧版Siri还能稳定执行。这波升级，属实是负优化了。

这实测数据挺真实的，跟我自己体验下来感觉差不多。iOS 27刚出那会儿我也刷了，最明显就是问个简单问题反而比以前卡顿，尤其断网状态下，感觉跟早期Siri返祖了一样。你说的分层架构切换丢状态这个问题我也有同感，我试过连续问“今天天气”和“帮我设置一个明天早上8点的闹钟”，结果它直接把天气场景里的时间戳带到了闹钟上，设成了“今天早上8点”，这要是真用了得坑死人。

关于功耗和延迟这个点，我其实更关心A18跑30亿参数时的实际发热情况。我实测过连续问十来条复合指令（比如“帮我找一下附近评分最高的川菜馆，然后导航过去”），手机背面摄像头附近明显能感觉到温热，电量也是肉眼可见往下掉。按理说端侧模型应该更省电才对，但感觉苹果这个端云切换的调度策略还没优化好，模型在本地和云端之间反复加载，反而增加了额外功耗。有没有可能因为AFM 3 Core本身就不是为纯端侧设计的，强行塞进A18导致内存带宽成了瓶颈？毕竟A18的NPU算力虽然强，但内存带宽相比桌面级还是有差距的，推理时大量参数在内存和NPU之间来回搬运，延迟和功耗自然就上去了。

另外你提到复合指令准确率只有68%，这个我深有体会。我试过让它“帮我查一下明天北京到上海的航班，然后对比一下高铁的时间”，结果它只识别了前半句，后半句直接忽略了。感觉苹果这个端侧模型在处理多轮对话和复杂意图识别上，跟云端那个大模型差距还是挺明显的。不知道你有没有试过通过调整提示词或者任务拆解的方式来改善体验？比如把复合指令拆成单步指令，虽然麻烦点，但准确率能提到85%以上。不过这样用起来就太不“智能”了，感觉有点本末倒置。

跑完你的实测数据，基本印证了我之前对端侧大模型落地的一些担忧。30亿参数塞进A18，推理延迟从1.2秒翻到2.8秒，这个代价其实比大多数人想象的要大——因为端侧推理的核心瓶颈根本不是算力，而是内存带宽和功耗墙。A18的NPU算力哪怕堆到40TOPS，但LPDDR5的带宽撑死也就50GB/s左右，跑30亿参数的模型，光是权重加载就要吃掉将近6GB的显存带宽，再加上KV Cache和中间激活值，延迟翻倍几乎是必然的。

你提到的“双模型切换丢上下文”这个坑，我深有体会。苹果这套分层架构理论上很漂亮，但实际工程上最难搞的是状态同步的原子性。端侧模型在本地维护一轮对话的隐状态，云端模型又是另一套独立的上下文窗口，两者之间的状态迁移如果没有设计成幂等的，一旦网络抖动导致切换，上下文必然断裂。我猜他们现在的方案大概率是粗暴地丢弃端侧缓存，直接fallback到云端从头算，这就能解释为什么连续指令会报错——因为端侧模型根本不知道你之前问过天气，它只拿到了当前轮次的query。

关于功耗和延迟的平衡，我建议你关注一下模型量化和推理框架的优化。30亿参数如果只用INT8量化，推理延迟或许能压到2秒以内，但苹果大概率用的是FP16甚至混合精度，为了保精度牺牲了延迟。另外，A18的NPU跑Transformer时，Memory Access Pattern比CNN差很多，数据搬运的功耗占比远高于计算本身。实测掉电快不快？我猜连续跑几轮端侧推理的话，掉电速度应该比旧版Siri快一个量级——毕竟现在每次推理都要搬十几MB的权重进SRAM，这可不是闹着玩的。