最近一周我一直在折腾同一件事把一份 7B 参数的大语言模型量化后分别塞进几台不同的手机里跑同样的对话任务。结果挺意外——几台设备纸面算力都在 30 TOPS 以上但长文本场景下的首字延迟能差出两到三倍。我把评测曲线翻来覆去看了一晚上问题几乎全出在 prefill 阶段。正好赶上新一代骁龙8发布官方把 prefill 性能提升 80% 当成核心卖点来讲。这个数字放在以前我也就是扫一眼就过去了但结合这几天的实测我才真正意识到它背后藏着的架构信息和端侧 AI 行业的真实处境。这篇文章就把我梳理出来的东西完整写下来包括 prefill 到底为什么重要、芯片这代在架构上动了哪些刀、以及我为什么说现在满大街的 TOPS 宣传里存在一套需要打引号的“算力骗局”。如果你正在纠结要不要为端侧 AI 换设备或者做端侧模型部署时被首字延迟折磨得头疼这篇应该能帮你节省不少排查时间。1. prefill 提升 80% 意味着什么推理过程比想象中更不对称1.1 一段对话里的两个完全不同的阶段很多人把大模型推理理解成一个“输入出去、结果回来”的黑盒但实际在芯片层面一次请求会被拆成两个截然不同的阶段。第一个阶段叫 prefill预填充。用户输入的整段 prompt 会被一次性并行处理模型对每个 token 做 attention 计算生成一套临时的中间状态也就是 KV Cache。这个阶段的特点是计算密集、并行度高、一次性处理的数据量大。你可以把它想象成一个人拿到一本新书后快速通读一遍同时把所有重要段落用便利贴标出来。第二个阶段叫 decode解码。模型从已生成的 token 出发一个一个地往外蹦新 token。每个 token 的生成都要依赖前面全部历史信息这是一个串行过程内存访问密集、并行度低。同样用读书来打比方decode 就像你写读后感每写一个字都要翻回前面看一遍所有便利贴。这两个阶段的算力需求画像完全不同。prefill 需要的是海量矩阵乘法有多少张量单元都不嫌多decode 则更依赖内存带宽因为每个 token 都要把整个模型权重和此前全部 KV Cache 重新读一遍。手机芯片在宣传时都喜欢强调总 TOPS但实际跑起来两个阶段的瓶颈往往卡在完全不同的硬件资源上。1.2 为什么 prefill 在手机上会成为拦路虎前几年大家讨论端侧大模型焦点几乎都放在 decode 速度上也就是每秒能蹦几个 token。这个指标确实直观毕竟对话时我们等的是回复内容。但真正用过你就会发现首 token 延迟同样要命。你输入一段 2000 字的需求如果等了 3 秒才看到第一个字出来无论后面每秒蹦多少个字体感都是“卡死了”。首 token 延迟主要由 prefill 决定。prompt 越长prefill 需要做的计算量和内存占用就越大这时候芯片的并行算力直接决定了你要等多久。我在实测里发现一个很典型的现象短 prompt几十个字下几台设备的首字延迟差距不超过 0.5 秒一旦把 prompt 拉到上千字中端芯片和旗舰芯片的差距能拉到 2 倍以上。这正是因为 prefill 阶段对峰值算力极度敏感短文本时瓶颈没那么明显长文本一上来算力的底子就露出来了。1.3 “80%”到底是在什么测试条件下说出来的官方口径里这代骁龙8的 prefill 性能相对上代提升了约 80%。这个数字看着很提气但你得知道它是怎么来的。从架构代际看提升主要来自三个方向张量单元数量增加、内存带宽扩展、以及软件调度层面对超长 prompt 的优化。但不同负载下的提升幅度并不均匀。短 prompt 场景由于计算量太小额外增加的执行单元根本喂不饱实际提升可能只有 20%-30%只有当 prompt 长度到达一定规模比如 2048 token 以上并行计算的优势才完全释放这时候才能接近 80% 的官方数字。我在本地用不同长度的输入做了一组对照测试结果基本验证了这一点。所以看宣传时要多问一句这个提升是在什么上下文长度下测的如果是 128 token 短文本场景新老芯片很难拉开差距但如果你平时主要用长文档摘要、代码仓库分析、多轮带历史记录的对话prefill 的提升会直接转化为感知层面的流畅度。2. 架构层面到底改了哪几板斧2.1 张量单元的规模和频率这代芯片在 NPU 上的核心改动是把张量加速单元的数量和位宽都往上抬了一级。从公开的架构图来看计算阵列的大致逻辑是每个周期能处理的 MAC乘累加次数显著增加同时支持更宽的向量指令。这意味着同一个 prefill 算子可以被切成更多份同时塞进更多执行单元里跑完。这就好比原来是一条单车道现在拓宽成四车道车还是那些车但每小时能通过的数量翻了倍。比较有意思的是这代在架构上把稠密计算和稀疏计算分得更开了。传统上NPU 的 MAC 阵列需要在稠密矩阵和稀疏矩阵之间做切换切换本身就有开销。新架构里专门划出一块区域处理稀疏化后的权重这让带剪枝的模型在端侧能吃到更多红利。如果你的模型已经做了 4 比 8 的稀疏化理论上能拿到的算力增益比跑普通稠密模型更明显。当然张量单元只是硬件的一面。有一个容易被忽略的细节是频率和功耗的平衡。手机不像数据中心不能为了性能无限拉频率。这代在 LPDDR 内存频率和 NPU 时钟之间做了动态协同——prefill 阶段短时拉高 NPU 频率decode 阶段略微降频保续航。实测下来长文本首字延迟改善确实明显而连续跑 20 轮对话后的机身温度控制得也比上一代好一些。2.2 内存带宽真正决定大模型胜负的暗牌如果让我评价大模型推理硬件我会说算力决定天花板带宽决定地板。以 7B 量化的模型为例权重文件大约 4GB 上下。decode 阶段每生成一个 token都要把这 4GB 权重从头读一遍再加上不断增长的 KV Cache。假如内存带宽是 50GB/s那么理论上 decode 每秒最多生成 12 个 token 左右就算 NPU 算力再强带宽不够也只能干等。这代骁龙8在内存子系统上的改进其实比 NPU 频率提升更关键。内存频率提高、控制器调优再加上对多级缓存的无序调度优化让 prefill 阶段大量并行的读取请求可以更高效地命中缓存。很多评测把 prefill 提升归功于 NPU但我倾向于把其中至少四成功劳算在带宽头上。这里还有一个经常被忽略的点峰值带宽和持续带宽不是一回事。芯片纸上标的内存带宽是在最理想突发传输状况下测得的真正常态跑大模型时受地址映射、缓存命中率、多核争抢影响实际能维持的带宽通常只有峰值的 60%-75%。所以不同厂商、不同内存颗粒方案的手机即使同芯片实际 AI 性能也会有明显差异。2.3 异构调度的软件红利这一代比较聪明的做法是把异构调度做得更细了。prefill 阶段的高并行矩阵乘法最适合丢给 GPU 或者 NPU 的张量核心跑decode 阶段的串行低延迟请求其实 CPU 的性能核也有用武之地。传统方案是整个模型只选一个执行单元跑新架构里则允许不同算子在不同单元间动态迁移。这就有点像一家餐厅平时大堂和包间的服务员各管各的遇到婚宴这种大场面系统会自动调派人手哪边忙就往哪边支援。实际效果就是短 prompt 问答时CPU 就能快速响应长文档总结时NPU 张量单元接管重计算等进入逐字生成阶段又切回低延迟路径。这类软件层面的优化没有硬件改动那么显眼但对用户体验的贡献一点不小。官方公布的 prefill 提升 80% 里很大一部分其实来自调度器和算子库的重写并不是单纯靠多塞晶体管堆出来的。这也是为什么我建议做端侧 AI 开发的朋友升级芯片的同时一定要把 NPU 驱动和算子库版本一起升否则硬件性能完全发挥不出来。3. TOPS 盛世下的“算力骗局”宣传口径和端侧真实体验之间3.1 TOPS 是怎么算出来的先回答问题TOPSTera Operations Per Second每秒万亿次操作是怎么来的。公式很简单TOPS MAC 阵列数量 × 运行频率 × 2。这个“2”是因为一个 MAC 操作包含一次乘法和一次加法算作两次运算。但魔鬼在细节里。这个公式算出的数字是在几个前提同时满足时才成立的所有 MAC 单元满负荷运行没有任何空转数据已经提前喂到寄存器里无需等待内存精度通常是 INT8如果是 INT4 还能进一步虚高运行时长足够短还没撞上功耗墙和温度墙你回忆一下手机发布会上的 AI 算力数字是不是从来不会标注“在什么精度、持续多久、什么模型下测得”这些背景信息一旦被拿掉TOPS 就是一张仅供参考的“理论马力表”。3.2 稀疏算力和稠密算力的差异现在端侧芯片厂商宣传 AI 算力时越来越多地在标题里直接写“NPU 算力达到 X TOPS”。但这里有个需要特别留意的地方很多高得吓人的数字是在稀疏计算条件下测出来的。稀疏计算的意思是权重矩阵里有一部分是零芯片可以跳过这些位置的计算从而在单位时间内处理更多有效数据。如果模型剪枝后稀疏度达到 50%一半权重的值为零理论上算力就能翻倍。问题在于市面上绝大多数开源模型并没有做稀疏化处理跑起来的都是稠密矩阵。芯片的稀疏加速能力再强对你实际要部署的稠密模型毫无帮助。这就好比你买了一辆号称能拉 10 吨的卡车但自己平时载的货全是按 5 吨标准打包的后斗结构根本挂不上去。我在给一个端侧翻译模型做适配时就踩过这个坑。芯片标称稀疏算力很猛但把模型直接跑上去帧率还不如上一代。后来把模型权重重新做剪枝和重训练才勉强吃到硬件红利。所以算力对比一定要问清楚这是稀疏的还是稠密的跑的是 INT4 还是 INT8不然数字很容易失真。3.3 功耗墙、热墙和可持续性能还有一个横在所有宣传数字面前的硬约束手机是被动散热的。手机没有风扇热量主要靠机身外壳往外辐射。大模型 prefill 阶段如果要跑满 NPU功耗轻松飙到 8W 以上这在手机上坚持不了几分钟——不是芯片不行是机身温度和电池放电能力不允许。厂商在实验室里测出好看的数字时通常是短时峰值性能真实用户拿到手机后持续对话十几分钟芯片早就开始降频了。降频之后TOPS 数字再漂亮也要打七折甚至对折。更严谨的做法是测量“可持续性能”也就是连续跑 20 轮对话后还能维持的性能水平。这个数据做横向对比才有参考意义。我在实测中格外关注一个细节连续三轮长文本生成之后首字延迟有没有明显劣化。有些芯片前三轮表现很好第四轮开始体感明显变慢这基本就是触发了功耗墙。新一代骁龙8在持续负载下的衰减控制做得不错这比峰值算力的提升更让我在意。3.4 缺失的“端侧有效算力”评价标准为什么我会给“算力骗局”打引号因为我不认为厂商是在主观造假更准确地说是行业缺少一套统一的“端侧有效算力”度量方法。TOPS 太理想化4K 视频解码能力又不能代表 AI。现在行业内还没有一个像“帧率”之于游戏、“跑分”之于安兔兔那样公认的 AI 实测标准。于是每家都用对自己最有利的口径来宣传造成数字和体验严重脱节。我个人的建议是以后看端侧 AI 芯片重点看三项实测数据——指标测试方法说明有效 tokens/s同一模型、同一量化等级测生成速度直接反映 decode 体验首 token 延迟长文本输入 2048 token prompt测首字时间直接反映 prefill 体验可持续性能连续跑 20 轮后重复上述两项反映功耗设计和散热真实水平这三个数字对齐之后才算是对一颗芯片端侧 AI 水平的合格体检。4. 端侧大模型真实体验瓶颈往往不在芯片本身4.1 手机端如今能跑起来什么样的模型先说结论以这一代骁龙8 的硬件水平端侧跑 7B 量化模型已经具备可用性但距离“流畅对话”还有距离。我实测的参考数据大概是这样的7B 模型 INT8 量化后decode 速度在每秒钟 8-12 个 token 之间如果升级到 INT4 量化速度可以到 12-18 个 token。作为参考人正常阅读速度大约是每秒 10-15 个字所以这个水平已经可以支撑基本的文字交互但和云端的秒回还是有差距。prefill 方面得益于这代架构的提升输入 1000 字左右的中文 prompt首 token 延迟能控制在 1-2 秒内。这个进步非常关键因为 RAG 应用比如文档问答恰恰是 prompt 动辄几千字的高发场景。以前这种场景在手机上简直是灾难现在至少能用了。14B 级别的模型在端侧就要吃力一些主要瓶颈在内存容量而不仅是算力。14B INT4 量化后仍然要占大约 8GB 内存手机系统再吃掉一部分留给模型的内存空间就很紧张了。所以行业现在的探索方向更多是“怎么把 7B 调优到极致”而非强上更大模型。4.2 决定端侧AI体验的几大隐形指标很多人以为选手机看 TOPS 就够了实际体验下来真正决定端侧 AI 流畅度的往往是一些平时不起眼的指标。第一个是可用内存。大模型跑的时候权重、KV Cache、激活值都驻留在内存里。手机厂商给系统预留的内存大小直接决定了你能跑多大模型、开启多长的上下文窗口。同样 16GB 的机器不同系统版本下留给模型的可用空间差异很大这比 TOPS 高低更实际。第二个是上下文窗口对 KV Cache 的吃法。KV Cache 随着对话长度线性增长2048 token 的上下文和 8192 token 的上下文内存占用能差出 4 倍。很多号称支持长对话的端侧应用跑着跑着就崩溃就是因为 KV Cache 管理出了问题而不是模型本身不行。第三个是模型迭代的兼容性。同一个 7B 模型新版本可能换了张量布局和算子集合老芯片的 NPU 驱动如果不更新跑起来效率可能直接减半。我给客户做选型建议时都会强调买新芯片更要关注厂商后续驱动更新的频率这是端侧 AI 体验的隐形长板。4.3 端云协同端侧还算力骗局吗说到最后回到那个大问题有了这么强的端侧算力我们还需要云吗我的看法是端侧和云端各自的优势恰好互补。端侧强在隐私、离线可用、低延迟云端强在模型大、能力强、升级快。未来很长一段时间内主流方案一定会是端云协同而不是互相替代。举一个实际的例子语音交互场景。唤醒词和命令识别这种轻量任务必须本地做因为要低延迟、要离线但涉及复杂推理的任务比如长篇文档总结、复杂的代码生成端侧模型能力确实不够这时候请求会流畅地切到云端。所以说“算力骗局”并不是指端侧 AI 一点用没有而是提醒大家别把峰值算力参数和真实可用能力画等号。端侧 AI 在特定任务上已经相当实用但对算力的解读方式需要更科学不能被一纸宣传带跑偏。5. 我的一些验证方法和选型思考5.1 从开发者角度如何低成本验证端侧 AI 真实水平如果你也是做端侧应用开发的想在选型阶段就把芯片的真实水平摸清楚我这里有一套比较笨但很可靠的方法。第一步统一模型和量化口径。选一个公开可下载的 7B 模型固定用同一份 INT4 量化权重避免不同量化版本带来的偏差。第二步设计两套测试负载。一套是短 prompt比如 32 token测 decode 速度另一套是长 prompt2048 token测首 token 延迟。把热机状态也考虑进去——第一轮跑完不算数等机身温度稳定后再记第三轮的数据。第三步记录功耗曲线。用联机抓电流的仪器记录整个测试过程看看峰值阶段持续了多久降频节点出现在哪个时间点。这组数据比其他任何跑分都有说服力。这套方法不需要实验室设备一台手机、一个秒表、一台电脑就能完成。测完你就会发现有些芯片宣传的 TOPS 听起来吓人但真实跑起来连台几年前的旧旗舰都打不过。5.2 普通用户选购的几条实用判断如果你不是开发者只是想在换手机时避免被“AI 算力”宣传忽悠我的建议很简单。第一不要看 TOPS看联想、翻译、摘要这些具体功能的实测演示。厂商发布会演示时用的场景通常就是芯片最强的场景你看那个表现及格不及格就够了。第二关注内存版本。大模型对内存容量的要求是刚性的16GB 和 12GB 在跑 7B 模型时的体验差距一目了然。预算允许的话优先考虑大内存版本。第三看系统承诺的 AI 更新周期。端侧 AI 是软硬协同的产物硬件再好系统不更新算子库也就那样。选择对软件更新承诺更积极的产品线长期使用体验更有保障。5.3 几个工程踩坑记录和应对建议最后分享几个我在实际调端侧 AI 时踩过的坑希望能帮你避开。第一个坑是 KV Cache 默认配置过大。很多推理框架在初始化时为上下文窗口预留了较多内存还没开始对话就已经占掉一半空间。调参时注意把 max context length 设置成实际业务需要的大小能显著降低内存占用和首 token 延迟。第二个坑是热机差异。芯片第一次执行某个算子时驱动要做编译和缓存热加载耗时明显偏大。所以做评测或者性能对比时一定先跑一轮“热身”再计时否则数据会严重失真。第三个坑是量化精度选择。INT4 虽然速度快、省内存但对某些模型结构比如细粒度分组的矩阵质量损失会比较大。如果你做的是对输出质量敏感的任务医疗咨询、合同分析优先用 INT8 或混合精度方案别为了追求那点速度牺牲准确性。我目前折腾端侧 AI 的真实感受是这代芯片的 prefill 提升确实解决了端侧落地的一个大痛点但整个行业在算力表达上还有很长一段路要走。希望这篇文章能让你对“算力”这个词多一份理性的判断。