最近一周我一直在折腾同一件事：把一份 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 是怎么算出来的

先回答问题：TOPS（Tera 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 芯片，重点看三项实测数据——

这三个数字对齐之后，才算是对一颗芯片端侧 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 速度；另一套是长 prompt（2048 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 提升确实解决了端侧落地的一个大痛点，但整个行业在算力表达上还有很长一段路要走。希望这篇文章能让你对“算力”这个词多一份理性的判断。