★ FEATURED ARTICLE 看到第六代骁龙8发布稿里那句大语言模型 prefill 速度提升 80%的时候我第一反应不是兴奋是警惕。做了这些年端侧 AI 落地我对厂商宣传里的百分比天然免疫——prefill 快 80%那 decode 呢端到端呢持续功耗下的真实吞吐呢如果只挑一个对硬件最有利的阶段来标榜性能那这个数字背后大概率藏着架构取舍的猫腻。所以这篇文章不打算复述发布会 PPT而是把prefill 80%这个结果拆开从大模型推理的计算特征到第六代骁龙8的 CPU、GPU、NPU、内存子系统各自做了什么再到端侧 AI 算力营销里那些看起来很美的 TOPS 数字到底怎么骗人。最后给出一套我自己在安卓设备上测端侧大模型性能的实操流程包括踩过的坑。适合正在做端侧 AI 部署、想搞清楚手机 NPU 真实水平、或者单纯想看懂厂商话术的开发者参考。1. 先搞清楚prefill 到底是什么为什么它成为发布会的新宠很多朋友一看到 prefill 这个词就头大觉得是什么高深的东西。其实它一点都不复杂就是大模型生成回复时的第一个阶段。要真正理解80%意味着什么得把大模型一次完整的推理过程拆开看。1.1 大模型推理的两段式prefill 负责读题decode 负责作答一次典型的大模型推理无论模型多大逻辑上都分成两个截然不同的阶段第一个阶段叫 prefill也叫预填充阶段。你把一段 prompt 输入给模型模型需要把这段文本里的所有 token 一次性并行处理计算出每个 token 对应的 hidden state同时生成 KV cache键值缓存供后续生成阶段使用。这个阶段的特点是计算量巨大、并行度极高可以把输入序列里所有 token 的计算同时塞进矩阵乘单元里执行。第二个阶段叫 decode也叫自回归生成阶段。模型开始一个个地预测下一个 token每次只生成一个 token然后把新 token 拼接到输入序列里再次走一遍前向计算。这个阶段的问题是每一步都依赖上一步的输出本质上是一个串行过程无法像 prefill 那样大规模并行。拿人来类比就是prefill 是老师拿到一张试卷快速扫一遍所有题目理解题目在问什么decode 是老师看完题目后口述答案一个字一个字往外蹦。前者是并行阅读后者是串行说话。两者的硬件需求也完全不同。prefill 是典型的计算密集型任务吃的是 MAC乘累加阵列规模、NPU 的并行计算能力、低比特矩阵乘效率decode 则是典型的访存密集型任务每一步都要从内存里把模型的所有权重读一遍再算那一点点乘法所以它真正卡的瓶颈是内存带宽算力再强也发挥不出来。1.2 为什么厂商偏偏挑 prefill 来宣传80%理清两阶段的差异后再看prefill 80%这个数字就能品出味道了。decode 阶段受内存带宽封顶上一代平台能跑多少 token/s下一代哪怕算力翻倍只要内存子系统没有同步升级decode 速度的涨幅也就那样。打个比方decode 就像一条单车道公路上的汽车瓶颈在路宽你把发动机从 1.5T 换成 5.0T车速也提不上去了。prefill 则不同它是多车道并行瓶颈在计算单元的规模和利用率。只要 NPU 的张量核心数量增加、支持更低精度的矩阵乘、片上缓存变大、算子融合做得更好prefill 的吞吐是可以实打实大幅提升的而且这个提升幅度很容易做到很亮眼。这就是为什么你会看到prefill 提升 80%这样极具冲击力的百分比。不是厂商不想宣传 decode 提速是 decode 提升幅度实在没有 prefill 这么好看。挑对自己最有利的指标来宣传是所有硬件厂商的常规操作。1.3 端侧大模型的第一瓶颈从来不是 TOPS而是内存带宽聊到这必须说一个很多新手容易忽略的事实在端侧跑大模型TOPS 那串数字远没有表面看起来那么重要内存带宽才是真正的第一瓶颈。为什么因为 decode 阶段每生成一个 token理论上需要把模型的全部权重从内存搬一遍。假设一个 70 亿参数的模型用 4bit 量化大小大约是 7B × 0.5 bytes ≈ 3.5GB。如果你的手机内存带宽是 85.6GB/s后面会细算这个数字怎么来的那么 decode 的理论极限速度就是 85.6 ÷ 3.5 ≈ 24.5 token/s。这个数字与 NPU 的 TOPS 完全无关。哪怕你的 NPU 宣称有 100 TOPS实际推理速度也突破不了这个带宽上限。所以你会发现一个诡异的现象手机 NPU 的 TOPS 每年都在涨但跑 7B 模型的 decode 速度涨幅却非常有限因为内存带宽的提升幅度远不如算力提升幅度。这就是我说算力骗局的起点——很多厂商喜欢用峰值算力来画饼但实际操作中决定端侧大模型体验的是带宽、显存容量、功耗三者共同围成的一个笼子。2. 第六代骁龙8的架构底牌不止是 NPU 那颗芯片要理解 prefill 80% 是怎么来的不能只盯着 NPU。一台手机端侧 AI 推理性能是 CPU、GPU、NPU、内存总线共同协作的结果。第六代骁龙8 这次明显是把整个计算平台当成一个整体来优化的。2.1 CPU自研 Oryon 架构介入 AI 任务的调度和 fallback很多人以为端侧 AI 推理全都在 NPU 上完成实际上没那么简单。模型在真正进入 NPU 之前要经过量化、图优化、算子切分有些算子 NPU 不支持或者支持得不好就要 fallback 到 CPU 上执行推理引擎的线程池调度、内存分配、KV cache 管理这些脏活累活全在 CPU 上。第六代骁龙8 全面采用自研 Oryon 架构 CPU把过去依赖 ARM Cortex 公版核的路线彻底扭转过来了。自研架构意味着在微架构层面可以做更有针对性的优化比如更大的乱序窗口、更宽的指令发射、更深的流水线这些对 AI 推理任务中的调度开销、算子 fallback 性能就是实打实的提升。有一个很容易被忽略的点模型在大规模 prefill 时数据会先从系统内存搬运到 NPU 的片上缓存再从缓存搬运到张量阵列计算。这个搬运过程涉及大量的 DMA 操作、同步开销如果 CPU 调度写得烂NPU 吃饱了等着数据算力再高也是白搭。Oryon 自研核在新一代平台上的多线程和 IO 吞吐能力增强对 prefill 流水线的喂料效率有不小的帮助。另外对于小 batch 的非标准算子或者动态 shape 流程NPU 不一定能发挥优势这时候 CPU 的 FP16/INT8 算力就是兜底方案。自研 CPU 架构带来的单核性能提升让那些无法卸载到 NPU 的部分也能跑得更快端到端延迟自然就下来了。2.2 GPUAdreno 的作用是被低估的备选执行单元Adreno GPU 在端侧 AI 里的存在感一直不如 NPU 强但这不代表它不重要。在很多场景下GPU 反而是最通用的并行计算单元。比如你要跑 Stable Diffusion 这类图像生成模型或者是一算子支持度不完整的新模型NPU 可能一堆算子不支持那 GPU 就得顶上。Adreno 在过去几代里持续强化了 FP16、INT8 的通用计算能力也能调用底层驱动做异构计算。第六代骁龙8 的 Adreno 8 系列 GPU 在能效比上做了优化当 NPU 因为发热被限制功耗时GPU 可以作为补充执行单元分担负载。不过在 LLM 纯文本推理的常规路径上GPU 确实不参与主流程因为 NPU 的能效比优势太明显了。我的理解是Adreno 在第六代骁龙8 中的定位更像是一个备胎和补充看似不起眼但一旦遇到算子兼容性问题它就是保证模型能跑起来的底牌。2.3 NPUHexagon 的迭代重点不是堆 TOPS而是利用率真正把 prefill 速度推上去的还是 NPU。从高通 Hexagon NPU 的演进路线来看我估计第六代骁龙8 的 NPU 做了这么几件事第一扩大了张量阵列的规模。prefill 是大矩阵的并行计算张量阵列多塞一组 MAC 单元峰值吞吐就线性涨一截。这部分是实打实的物理算力提升。第二强化了片上 SRAM。prefill 的中间结果如果频繁写回系统内存带宽撑不住。片上缓存做得越大数据留在片上反复计算的比例越高实际有效算力就越高。很多厂商提 TOPS 时根本不提这一项但恰恰是这玩意儿决定了 TOPS 能兑现几成。第三支持更好的低比特混合精度。现在的端侧模型几乎全是 INT4/FP8 混合量化。NPU 对低比特格式的硬件级支持意味着同一条流水线可以跑更少的位宽吞吐自然上去了。INT4 相比 INT8 的吞吐提升不是 2 倍就是接近 2 倍如果上一代平台跑 INT4 需要软件模拟那新一代硬件原生支持 INT4 带来的涨幅就非常可观。第四多核并行调度的改善。prefill 的长序列在数学上是可分的新一代 NPU 可以把序列切成多块、分配到不同核上并行 prefill最后合并 KV cache。多核并行度的提升是 prefill 吞吐增长的一个重要来源这也是为什么prefill 80%比 decode 涨幅更容易做出来。2.4 内存子系统LPDDR5X Ultra 才是被忽略的主角如果说 NPU 是 prefill 提速的发动机那内存子系统就是给发动机供油的油路。第六代骁龙8 这次搭载 LPDDR5X Ultra峰值速率达到 10.7Gbps。按移动端常见 64bit 总线宽度估算理论带宽大约在 85.6GB/s 左右相比上一代平台的 LPDDR5X9600Mbps约 76.8GB/s提升了大概 11%但相比更早的 LPDDR5-6400 时代带宽已经是翻倍不止了。带宽对 prefill 的影响容易被低估。虽然 prefill 是计算密集但它的计算过程需要反复读权重、读输入 token、写 KV cache。输入序列越长KV cache 就越大对系统内存的写入压力就越大。比如 8K 上下文的 KV cache在 7B 模型上可能有几 GB 的占用这些数据必须靠内存总线搬进搬出。内存带宽提升意味着 NPU 等待数据的时间变短张量阵列的利用率提高prefill 的吞吐自然跟着上去。大内存容量也是一个关键变量。这一代平台的旗舰机型普遍 16GB 起步、24GB 成为常态甚至有到 32GB 的。为什么要强调容量因为 7B 模型 4bit 量化后占 3.5GB14B 模型 4bit 量化后接近 7GB加上 KV cache 和系统占用的内存没有 16GB 以上根本跑不动。端侧跑大模型是从能不能跑到跑得快不快的前提条件。所以内存子系统是理解 prefill 80% 的一个隐藏主线算力提升只是一部分带宽和容量把算力兑现出来的条件也成熟了。3. prefill 80% 的架构真相一块一块拆开算这节落到核心问题上那80%到底从哪来我做端侧 AI 部署的经验是任何官方公布的性能提升 X%都不能直接当成硬件性能提升 X%来理解它往往是硬件架构、软件栈、内存子系统、甚至测试方法共同作用的结果。3.1 涨得不是算力是利用率最容易被忽略的一点是第六代骁龙8 的峰值 TOPS 未必翻了 80%但它在跑真实 LLM prefill 时的算力利用率很可能比上一代高了 80%。上一代平台的 NPU 峰值算力不低但实际跑 LLM 时存在两个问题一是权重需要频繁从系统内存读入带宽填不满计算单元导致大量 MAC 阵列空转二是算子图切分不够细NPU 和 CPU 之间来回同步流水线断断续续。新一代平台把片上缓存做大、数据复用做好之后张量阵列的空置率大幅降低。同样是标称 50 TOPS 的算力上一代实际利用率可能只有 20%优化之后跑到 36%。这带来的 prefill 吞吐提升在百分比上可以非常夸张而且是不需要堆更高的峰值 TOPS 就能实现的。这个逻辑解释了为什么很多评测里新平台的跑分提升不是特别惊人但实际 LLM 推理速度提升远超跑分涨幅——因为跑分测的是短时峰值算力而 LLM 推理测的是持续有效算力两者的优化维度完全不同。3.2 带宽带来的数学为什么 10.7Gbps 内存是关键变量咱们把 prefill 的吞吐模型拆开看。prefill 阶段处理一个长度为 L 的 prompt总计算量大约是 2 × L × N × d_model × n_layers 这个量级。以 7B 模型为例处理 2048 个 token 的 prompt粗略算下来需要的 FLOPs 大概是几十 GFLOPs。如果 NPU 的有效算力是 20 TOPSINT4 稠密峰值的一部分那么纯计算时间大概是几十 GFLOPs ÷ 20 TOPS ≈ 几毫秒。这是理想情况。但实际过程中这些计算需要从内存读取模型权重。7B 模型 4bit 量化有 3.5GB 权重哪怕 prefill 阶段权重只读一遍理想情况3.5GB ÷ 85.6GB/s ≈ 41ms。也就是说哪怕计算阵列一秒钟能算 20 万亿次操作受限于权重读取时间整个 prefill 至少要 40ms 起步。这组数据的含义很明确对 prefill 来说带宽不是唯一瓶颈但当带宽不够时它会直接压制算力利用率。上一代平台的带宽如果是 76.8GB/s读一遍 3.5GB 权重需要 45.6ms新一代 85.6GB/s 只要 40.9ms这部分提升虽然只有 11%但它叠加到整个流水线上配合其他优化最终体现在 80% 的 prefill 增速里就合理了。顺便说一句这个推理也点破了算力骗局的核心当你的模型权重读取时间已经占了大头堆再多 TOPS 都是浪费。3.3 算子融合与长序列优化软件侧的确定性优化大头其实在软件侧。这一代跟高通的合作生态明显更成熟了主流的端侧推理引擎llama.cpp、MLC LLM、ExecuTorch对新平台的适配度提升很快这带来的性能涨幅往往是决定性的。最典型的优化是算子融合。比如把 QKV 三个矩阵乘合并成一个 GEMM 执行把 LayerNorm 和激活函数融合到上一个算子内部减少中间结果的写回和读取。一次 prefill 计算中算子的数量可能减少 30%-50%每次减少都意味着少一批内存访问和同步开销。另一个是 KV cache 的量化压缩。prefill 阶段生成的 KV cache如果以 FP16 格式存在内存里容量和多轮对话的带宽压力都很大。新一代平台在软件栈层面支持 KV cache 的 INT8 甚至 INT4 量化写 KV cache 的数据量直接砍半甚至砍到四分之一。这意味着在长上下文场景下prefill 不只是计算速度快了写缓存的压力也小了。如果你的测试 prompt 是 8K 甚至 32K 的长序列软件栈在 KV cache 层面的优化贡献的涨幅会非常吓人。所以prefill 80%里面有很大一部分是上一代的短板被补齐了。上一代如果把注意力机制实现得不高效、KV cache 不压缩、INT4 算子没有完全走硬件加速那新一代只要把这些路都铺平提升幅度自然就爆炸。3.4 硬件和软件叠加80% 是系统工程不是单点突破综合来看我倾向于把 80% 的提升拆成三块硬件架构升级多核并行、张量阵列扩展、片上缓存增大贡献大概一半内存子系统升级带宽、容量贡献 15%-20%软件栈和算子优化融合、量化、引擎适配贡献剩下的三成。不同测试条件下这三块的占比会浮动但方向是明确的这不是某一个模块单点突破的结果而是整个计算平台朝 prefill 这个特定方向倾斜优化的结果。这恰恰是架构真相最值得玩味的地方。高通选择的优化路径是围绕当下最热的端侧 LLM 应用场景做整体调优而不是简单地把 NPU 峰值 TOPS 拉高。这种做法的好处是实际体验提升明显坏处是测试条件变一下比如换成短 prompt 或者大 batch 并发那个 80% 就不一定成立了。所以看发布会数据一定要问一句这个百分比是在什么模型、什么序列长度、什么温度条件下测出来的4. 端侧 AI 的算力骗局TOPS 是怎么骗人的如果说 prefill 的 80% 是真实的架构优化那算力骗局这个说法的存在是因为厂商在宣传端侧 AI 算力时惯用一套看起来很美的数字游戏。这几年我见过了太多被 TOPS 数字误导的产品决策这节把话术一层层剥开。4.1 峰值 TOPS、稀疏 TOPS、实际 TOPS口径比数字更值钱先做一个最容易踩的坑解读。厂商宣传端侧 AI 算力高达 XX TOPS时这个 XX 到底是什么口径的以典型的 NPU 宣传为例最大的几种口径差异包括稀疏 vs 稠密当前很多 NPU 支持 2:4 结构稀疏也就是每 4 个权重里允许有 2 个是零计算时可以跳过零直接加速所以稀疏算力可以达到稠密算力的两倍。但实际部署的 LLM 权重极少能保证 50% 的稀疏度模型剪枝后精度损失也要考虑这个稀疏 TOPS 几乎无法兑现。精度选择同一块 NPUINT8 算力是 X TOPSINT4 算力可能宣称 2X TOPS。但你真实部署时的量化精度由模型质量决定不是说降精度就一定行。单核 vs 多核有的厂商把多核 NPU 的算力全部加起来宣传但实际长任务会因为功耗、散热、核间同步等问题大幅打折。把这些口径排列组合同一块芯片可以包装出 4 倍以上的宣传算力差距。最典型的例子是我见过某平台宣传的60 TOPS实际上它的 INT8 稠密算力只有 30 TOPS 左右INT4 稠密算力 40 TOPS 上下稀疏模式才能到 60 TOPS。你用 INT4 稠密模式跑模型实际有效算力连宣传数字的三分之一都不到。4.2 带宽墙、功耗墙、内存墙真实性能的三座大山就算你拿到了真实的稠密 INT4 算力真实端侧 AI 表现还是会被三座大山限制带宽墙我们已经反复说过了。decode 阶段每生成一个 token 都要读一遍模型权重。带宽 85.6GB/s 时7B 4bit 模型的 decode 吞吐上限 24.5 token/s。这个数字与算力多么强无关它就是内存总线的物理上限。想更快只能减小模型体积量化得更狠或者提升带宽没有第三条路。功耗墙更是被严重低估。NPU 的峰值算力往往只能维持很短时间因为手机散热系统根本压不住持续高负载。在骁龙平台上做持续 AI 推理很多设备表面温度一上来就触发降频NPU 频率掉到峰值的一半甚至三分之一都是常态。你用跑分软件测的 10 秒峰值和实际连续对话 30 分钟的持续性能完全不是一回事。这也是为什么很多手机发布会上的 demo 看着飞快你拿到真机用起来就若有所思。内存墙是第三个限制。端侧设备的内存容量是固定的系统、后台应用、NPU 驱动都要占内存留给模型的物理空间是有限的。一个 14B 模型 4bit 量化后 7GB加上 KV cache 需要 1-2GB再加上系统缓冲16GB 内存的机器跑起来已经开始紧张了24GB 是大体面的选择。内存不够大模型干脆就部署不进去算力再高也白搭。4.3 为什么跑分和体验差那么多一个实测例子拿我最常跑的 7B 4bit 模型来举例。某平台的 NPU 标称 45-60 TOPS不同口径差异实际在端侧用 MLC LLM 跑 Llama 3.2 7B 的 INT4 量化版本128K 上下文配置下prefill 吞吐大概能做到几百 token/sdecode 吞吐实测大概在 17-25 token/s 之间。这个 decode 数字意味着什么可以反推一下每个 token 的有效算力需求7B 模型每个 token 需要大约 2 × 7B 14 GFLOPs 的计算量。20 token/s 对应的有效算力是 14 × 20 ≈ 280 GFLOPs ≈ 0.28 TOPS。0.28 TOPS你没看错在 60 TOPS 的平台上跑出 0.28 TOPS 的有效算力利用率不到 0.5%。这就是算力骗局最扎心的真相TOPS 数字是用来展示上限的而 LLM 的 decode 任务是访存密度极高的内存稠密型任务高算力根本喂不饱。当然 prefill 阶段的利用率高得多但那是因为长序列并行能把矩阵乘单元填满。可用户感知最强烈的生成速度逐字蹦恰恰是 decode 阶段这个阶段被带宽卡死后你拿着再漂亮的 TOPS 跑分实际对话体验也就那样。4.4 算力营销的常见话术拆解厂商的说辞其实就那几板斧拆穿后也就没那么神秘了话术一支持百亿参数大模型。这里的支持通常指的是能把模型塞进内存里量化、切片、换页都算支持。但实际速度如何、能不能连续多轮对话、会不会过几个回合就 OOM全都是另一回事。对端侧 AI 来说能部署和能用之间隔着天堑。话术二AI 算力达 XX TOPS。你只要问一句是稀疏还是稠密INT4 还是 INT8持续功耗下能保持多久大概率对方就含糊了。话术三prefill 提升 X%。这本身是真实的问题是它被拿来代表端侧 AI 能力提升。prefill 提速对首 token 延迟有直接帮助但如果是多轮对话场景总耗时的构成里 decode 占了大头prefill 提升的体感就没那么明显了。厂商选中了对自己最有利的指标不代表这个指标不重要而是你要知道它不能代表全局。话术四端侧 AI 硬件部署已就绪。就绪是就绪了就绪和好用之间还隔着散热、内存、电池、软件生态的漫长距离。硬件算力只是一个底座底座之上还有一堆工程问题要解决。所以我的结论很明确TOPS 不是没有意义它描述的是理论峰值是天花板但端侧 AI 的真实体验是地板决定的地板是持续功耗、带宽、内存容量。看任何芯片的 AI 性能先问带宽和功耗再问 TOPS。5. 自己动手端侧 AI 性能到底该怎么测才不被带偏既然厂商话术不可全信那我们就自己动手测。我在实践中摸索出一套相对靠谱的测试方法尽量把变量控制在单一维度得到的数据也能支撑真实的产品决策。5.1 看哪些指标prefill 吞吐、decode 速度、首 token 延迟一个都不能少端侧 AI 的体验由几个关键指标共同决定只看任何一个都有失偏颇prefill 吞吐tokens/s决定首 token 延迟也就是你提问后多久开始看到回复。decode 速度tokens/s决定后续每个字的间隔这是用户感知最明显的部分。首 token 延迟TTFTTime to First Token提问后到第一个 token 生成出来的时间由 prefill 调度开销共同决定。端到端吞吐整个对话过程的总 token 数除以总耗时综合反映性能。功耗瓦特 / 每 token 或每秒在移动设备上这决定你的设备能持续跑多久不降频。没有功耗数据的性能测试都是耍流氓。我也是被坑过才意识到很多人拿到一个跑分很高的端侧模型 demo实际上只跑了 prefill 阶段或者只测了短上下文下的速度。长上下文 多轮对话才是端侧 AI 的真实地狱模式。5.2 常用工具与测试方法MLC LLM、llama.cpp、AI Benchmark目前端侧测 LLM 性能我主推 MLC LLM它在安卓端的 NPU 加速适配做得相对成熟支持 Vulkan 后端和多种量化格式。llama.cpp 在 CPU 上的优化也很好可以作为基准参照。AI Benchmark 这类工具的好处是自动化程度高但坏处是它自己的算子实现未必最优测出的结果只能横向参考不能代表理论最优性能。如果只是图方便也可以直接用 MLC LLM 的 Android 预编译包加载一个固定的模型测 prefill 和 decode 分开的吞吐。测试时注意固定引擎版本因为同一个模型在不同引擎版本的实现差异可以带来两倍以上的性能差距。测试基线要统一同一个模型文件、同一个量化格式、同一个上下文长度、同一个 batch size。不要在 A 设备上用 4bit 模型、在 B 设备上用 8bit 模型来对比这个错误我见得太多了。5.3 实操示例设计一个不被营销的测试流程我自己的标准测试流程是这样的分享出来供参考第一步固定测试环境。手机充满电、开启飞行模式避免后台同步和数据传输干扰、关闭所有后台应用。有条件的话用外部工具监测 CPU/GPU/NPU 频率和温度比如高通平台的 Snapdragon Profiler 或者 perf 工具。第二步选择标准模型。我常用 Llama 3.2 3B 和 7B 的 INT4 量化版本因为这两货在端侧部署最普遍参数也够有代表性。3B 测的是普通场景上限7B 测的是主流大模型的实际表现。第三步固定输入和输出长度。用一段固定长度的系统提示词比如 500 token再拼接不同长度的用户输入500 / 1000 / 2000 / 4000 token 四档测量 prefill 阶段耗时。输出长度控制在 128 token 以内固定截断测 decode 速度。第四步记录多轮数据。每档跑 5 次取中位数而不是平均值——端侧设备受温度影响平均值容易被偶发的高温降频拉垮中位数更能反映典型体验。同时记录每轮的温度、功耗、是否触发降频。第五步单独做一轮长压力测试。连续对话 20 轮以上总上下文拉到 8K 以上观察最终 decode 速度相比初始下降了多少。这个数据最能反映真实使用体验也最能揭穿峰值性能的伪装。输出一个简单的测试记录表大概像这样测试项输入长度prefill 耗时prefill 吞吐decode 速度设备温度备注3B INT451212ms42.7 tok/s19.8 tok/s36°C首轮3B INT4409688ms46.5 tok/s18.9 tok/s42°C持续 5 轮7B INT451225ms20.5 tok/s11.2 tok/s38°C首轮7B INT44096195ms21.0 tok/s9.8 tok/s45°C持续 5 轮测完之后你基本就能形成一个判断这个平台能不能跑我要的模型、在什么上下文长度下体验可接受、持续负载下会不会崩。6. 踩坑记录与常见问题速查端侧 AI 实测路上的教训最后把我在端侧 AI 实测过程中踩过的坑和总结的排查经验整理出来。很多内容常规文档里不会写却是实际工程中最浪费时间的地方。6.1 我调端侧 AI 时踩过的四个坑第一个坑只看官方 TOPS 选型号实际算力利用率惨不忍睹。我之前评估一款设备时看到标称 50 TOPS 就觉得肯定能跑 14B 模型结果一测同样的 7B 模型 decode 还不到 15 token/s因为 NPU 驱动没适配好推理引擎走的几乎全是 CPU 路径。后来我养成了习惯任何设备到手先用同一个模型跑一遍 MLC LLM 和 llama.cpp 做交叉验证确认 NPU 加速真的生效再看其他。第二个坑跑性能基准时没锁性能核和 AC 供电。安卓设备的 CPU/GPU 频率调度非常激进而且很多设备的电源管理策略在电池模式和充电模式下完全不同。我第一次测的时候用电池模式结果跑分比插电时低了将近 30%后来才意识到是功耗限制在作祟。现在我的测试流程里所有跑分统一在充电状态、锁性能核、关闭自动亮度下进行。第三个坑不同推演引擎的结果差异巨大。同一个模型、同一个设备MLC LLM 跑出来的速度可能是 llama.cpp 的两倍如果再把引擎参数如 batch size、KV cache 量化开关调整一下还能再浮动 30%。这个教训教会我在做横向对比时必须统一引擎和参数不然所谓的对比测试没有意义。第四个坑把温度墙当突发情况忽略掉。真正让我意识到算力骗局严重性的是我第一次做 20 轮长对话压力测试。前 3 轮速度还行到第 8 轮开始明显变慢第 15 轮之后 decode 速度几乎腰斩体感就是手机烫得能煎鸡蛋。从那以后我所有测试都要求记录温度和持续时长只报峰值性能不报持续性能的测试一律不作数。6.2 端侧 AI 测试常见问题速查表现象可能的根因排查与建议官方 TOPS 很高但实测推理速度很差NPU 驱动未生效、算子未适配、推理引擎走了 CPU 路径换不同推理引擎交叉验证检查引擎日志确认 NPU 后端是否启用跑分成绩波动很大温度墙触发降频、后台进程抢占、电源策略变化统一充电环境、锁核、关闭后台应用、多轮取中位数相同模型、不同引擎结果差异大算子融合/量化策略不同、内存复用、KV cache 优化差异横向对比时固定引擎实际部署时选最优引擎长对话后速度骤降上下文变长导致 KV cache 占用暴涨、带宽压力加大、温度墙叠加开启 KV cache 量化、限制上下文长度、缩短单轮输出14B 模型可以加载但每 token 生成时间极长模型权重远大于带宽可承载范围decode 被带宽墙卡死换更激进的量化格式、考虑蒸馏小模型、降低上下文长度设备发热严重、性能快速下降NPU 持续高负载导致功耗超标、散热设计不足限制 NPU 频率、分片推理/交错执行、降低 batch size、外部散热辅助写在最后的一点个人体会做了这么多年端侧 AI 部署我最大的体会是芯片厂商没骗人骗人的是数字背后被隐藏的约束条件。prefill 80% 是真实存在的架构优化成果值得肯定但如果你误以为它代表端侧 AI 算力暴增 80%那就被带偏了。真实用户体验的决定因素永远是解码速度、持续功耗、运行温度、模型可部署性这些指标需要你亲自测出来而不是看发布会 PPT 就能得到的。我自己现在评估任何端侧 AI 平台第一眼看 LPDDR 带宽和持续功耗第二眼看软件生态适配第三眼看内存容量TOPS 反而是最后才看的参考项。这个习惯帮我避开了不少选型上的坑。如果你也要做端侧模型部署建议一开始就建立一套自己的基准测试流程别等到产品原型跑不动了才回头排查。毕竟算力天花板上限再高真正的功夫都在地板以下的细节里。
阅读完成 · 觉得有帮助？
