端侧 AI 这两年从“概念演示”快速滑向“真能落地”最大的推手不是模型变小了而是算力供给的结构变了。过去我们谈推理默认背后有一张卡、一台服务器、一个机房现在越来越多的需求要求数据不出设备、响应延迟压到毫秒级、断网也得能用。手机相册的本地语义搜索、会议录音的实时转写、工业相机的缺陷检测、车载座舱的语音唤醒这些场景的共同点是把智能塞进设备本地而不是把数据送到远端。端侧 AI 算力方案推荐这件事本质上是在一堆互相牵制的约束里做取舍——算力、功耗、内存带宽、成本、开发周期没有一项能单独拉满。这篇内容面向正在选型或准备把模型往设备上搬的工程师也面向想搞清楚“端侧到底能跑什么”的产品和技术决策者我会把 SoC、NPU、Transformer 部署、AI-ISP 这几条线串起来讲给出可对照的选型逻辑和实操细节。1. 端侧 AI 算力方案的核心矛盾不是算力不够是供给错配很多人第一次做端侧部署脑子里想的是“找个算力大的芯片就行”。真上手之后会发现算力数字只是入场券真正卡住项目的是算力供给和模型需求之间的错配。这个错配体现在三个层面理解它们比记住任何一张天梯图都重要。1.1 算力峰值与有效算力的差距芯片规格书上的 TOPS每秒万亿次操作是理论峰值通常标注的是 INT8 稠密算力而且是在理想频率、理想数据复用条件下测出来的。实际能跑出多少取决于模型算子是否被 NPU 原生支持、内存带宽是否喂得饱、调度是否连续。我见过不少方案标称 8 TOPS实测一个中等规模的视觉模型只能跑到 1.5 TOPS 等效原因就是算子回退到 CPU、数据搬运成了瓶颈。有效算力的经验估算可以这样看先确认模型里有多少比例的算子能落到 NPU 上假设是 80%再乘一个内存带宽约束系数通常 0.5 到 0.8最后乘理论峰值。一个标称 8 TOPS 的 NPU如果算子覆盖率 80%、带宽系数 0.6有效算力大概在 3.8 TOPS 左右。这个数字才是你做延迟预算时该用的。1.2 内存带宽往往比算力更早成为瓶颈Transformer 类模型对带宽极其敏感。自注意力机制每一步都要读写大量的 Key/Value 缓存参数量大、访存密集。很多 NPU 算力看着够但 LPDDR 带宽只有几十 GB/s跑 Transformer 时算力单元大量时间在等数据。这就是为什么有些芯片跑 CNN 很猛一上 Transformer 就拉胯。判断带宽是否够用有个粗略方法看模型的算术强度每读一字节数据能做多少次运算。CNN 的算术强度通常较高Transformer 偏低。算术强度低的模型带宽就是硬约束。选型时如果目标模型是 Transformer 系带宽指标的权重应该高于纯算力指标。1.3 功耗墙决定了持续性能端侧设备大多没有主动散热手机、摄像头、可穿戴设备都靠被动散热。芯片短时间能冲高频但持续跑几分钟就会因为温度触发降频。所以看端侧方案不能只看瞬时性能要看持续性能sustained performance。一个标称 10 TOPS 但持续只能维持 3 TOPS 的方案在需要长时间推理的场景里实际体验可能不如一个标称 6 TOPS 但能稳定跑 5 TOPS 的方案。提示做端侧选型时务必向芯片原厂或方案商索要持续性能数据而不是只看峰值。如果拿不到就自己搭一个连续推理 10 分钟以上的测试记录帧率或延迟随时间的变化曲线。2. SoC 与 NPU 的搭配逻辑别被天梯图带偏网上流传的各种 SoC 天梯图、手机 SoC 排名对端侧 AI 选型有参考价值但直接拿来用很容易踩坑。天梯图通常按综合性能或游戏性能排序而端侧 AI 关心的是 NPU 算力、内存带宽、算子生态、工具链成熟度这几个维度排序结果可能完全不同。2.1 从需求反推 SoC 档位选 SoC 的第一步不是看芯片是看你的模型和场景。我习惯先问四个问题模型是什么类型CNN、Transformer、混合、模型多大参数量和计算量、延迟要求多少、功耗预算多少。这四个问题基本能框定 SoC 的档位。举个例子如果是一个 5M 参数以内的轻量 CNN 分类模型延迟要求 50ms 以内功耗预算 2W 以内那么一颗带 1 到 2 TOPS NPU 的中低端 SoC 就够用没必要上旗舰。反过来如果要跑一个 100M 参数以上的视觉 Transformer还要实时那就必须选 NPU 算力 10 TOPS 以上、带宽 50 GB/s 以上的方案同时得确认工具链对 Transformer 算子的支持程度。2.2 NPU 的三种典型架构与适用场景端侧 NPU 目前大致分三类架构各有取舍。第一类是专用 MAC 阵列型以大量乘加单元堆算力适合 CNN 这类规整计算。优点是 CNN 效率高、功耗可控缺点是灵活性差遇到非标准算子容易回退。第二类是可重构数据流型根据算子动态配置数据通路对 Transformer 的矩阵运算和注意力机制支持更好。这类架构在跑 Transformer 时效率明显优于第一类但工具链复杂度更高。第三类是DSP 增强型在传统 DSP 上扩展向量指令来加速 AI 运算。算力通常不高但灵活、功耗低适合 always-on 的语音唤醒、关键词检测这类小模型常驻场景。选型时把目标模型和这三类架构对号入座比单纯比 TOPS 数字靠谱得多。2.3 工具链成熟度是被低估的选型维度我踩过最深的坑是选了一颗算力漂亮但工具链拉胯的芯片。模型转换各种报错算子不支持量化掉点严重文档稀烂社区没人。最后项目延期两个月算力优势一点没发挥出来。工具链成熟度可以从几个信号判断是否支持主流训练框架PyTorch、TensorFlow的一键转换量化工具是否完善PTQ 和 QAT 都支持算子覆盖列表是否公开且更新频繁是否有活跃的开发者社区或原厂 FAE 支持。这些信号比算力数字更能决定项目成败。选型维度权重建议判断方法NPU 有效算力高实测目标模型不看峰值内存带宽高Transformer 场景极高查规格 实测延迟算子覆盖高查算子列表跑目标模型验证工具链成熟度高试转换、查社区、问 FAE持续性能中高连续推理测试功耗中看场景常驻场景权重高成本中含开发成本不只芯片价3. Transformer 上端侧为什么难怎么破Transformer 从云端走向端侧是这两年最明显的一个趋势也是端侧部署里最棘手的一类。视觉 Transformer、时序 Transformer、语音 Transformer 都在往设备上搬但直接搬往往跑不动。理解难点在哪才知道优化从哪下手。3.1 Transformer 端侧部署的三个硬骨头第一个硬骨头是注意力机制的计算和访存模式。自注意力要计算 Q 乘 K 的转置得到注意力矩阵再乘 V。这个过程中间结果大、访存密集和 NPU 擅长的规整卷积计算模式差异很大。很多早期 NPU 对这类算子支持不好只能回退 CPU速度直接掉一个数量级。第二个硬骨头是动态形状。Transformer 处理变长序列时序列长度是动态的而很多 NPU 编译器要求静态形状或者对动态形状支持有限。这会导致要么填充到固定长度浪费算力要么频繁重编译。第三个硬骨头是量化敏感。Transformer 里的 LayerNorm、Softmax、GELU 这些算子对量化误差敏感粗暴地做 INT8 量化容易掉点。需要针对性地做混合精度或者对这些算子做特殊处理。3.2 轻量 Transformer 的改造思路面对这些难点业界主流做法是对 Transformer 做轻量化改造而不是硬扛原始结构。几个常见方向降低注意力复杂度用线性注意力、稀疏注意力、局部窗口注意力替代全局注意力。Swin Transformer 的窗口机制就是典型代表把全局注意力限制在局部窗口内计算量大幅下降同时保留建模能力。减少层数和维度轻量模型往往把层数压到 4 到 12 层嵌入维度压到 128 到 384注意力头数减少。MobileViT、EfficientFormer 这类模型都是这个思路。算子替换把对量化敏感的算子换成端侧友好的替代品比如用近似 GELU 或者 ReLU 变体用更稳定的归一化方式。这些改造会损失一些精度但换来的是端侧可跑。实际项目里精度损失 1 到 2 个点通常可以接受前提是延迟和功耗达标。3.3 部署时的实操要点模型改造完部署还有一堆细节。首先是输入形状固定化尽量把序列长度固定避免动态形状带来的编译和调度开销。如果业务上确实需要变长可以考虑分档处理比如准备 128、256、512 三档按需选择。其次是KV 缓存管理。自回归生成类任务比如端侧文本生成需要缓存 Key/Value缓存占用的内存会随序列增长。端侧内存紧张需要设置合理的缓存上限或者用滑动窗口只保留最近若干 token 的缓存。第三是算子融合。把 LayerNorm 和相邻的线性层融合、把注意力里的多个小算子融合成一个大算子能显著减少访存和调度开销。这一步依赖工具链的融合能力选型时要重点验证。注意Transformer 端侧部署的调优是迭代过程不要指望一次转换就达标。建议先跑通功能再逐步做量化、融合、形状固定每一步都记录精度和延迟变化找到平衡点。4. AI-ISP被忽视的端侧算力大户聊端侧 AI 算力大多数人盯着 NPU却忽略了 ISP图像信号处理器这条线。在摄像头类设备上AI-ISP 正在成为算力消耗和体验差异的关键。所谓 AI-ISP就是把 AI 能力引入传统 ISP 流水线用神经网络替代或增强部分图像处理环节。4.1 AI-ISP 到底在做什么传统 ISP 流水线包括去马赛克、白平衡、降噪、锐化、色调映射等环节很多环节依赖手工设计的算法和参数。AI-ISP 用轻量神经网络来做这些事典型应用包括AI 降噪用网络替代传统降噪在暗光下效果提升明显。AI 高动态范围多帧合成时用网络做对齐和融合减少鬼影。AI 超分低分辨率传感器通过 AI 放大到高分辨率输出。AI 语义增强识别人脸、天空、文字等区域分区做针对性增强。这些任务的特点是数据量大每帧图像都是百万像素级、实时性要求高至少 30fps、功耗敏感摄像头常开。所以 AI-ISP 对算力的需求非常可观而且和主 NPU 的负载会互相竞争。4.2 AI-ISP 与主 NPU 的资源分配一个常见的架构问题是AI-ISP 的推理跑在哪里有两种做法。一种是 ISP 内部集成专用的 AI 加速单元独立于主 NPU好处是互不干扰、延迟可控坏处是算力固定、灵活性差。另一种是共用主 NPU好处是算力可动态分配坏处是 ISP 任务和业务 AI 任务会抢资源需要精细调度。选型时要搞清楚目标 SoC 用的是哪种架构。如果是共用 NPU就要评估业务 AI 和 ISP AI 的算力总和是否够用以及调度策略是否合理。我见过一些方案单独跑业务 AI 很流畅一开 AI-ISP 就掉帧就是资源竞争没处理好。4.3 摄像头端侧方案的算力预算示例假设一个智能摄像头方案需要 1080p 30fps 的 AI-ISP 处理同时跑一个人形检测模型。粗略算一下算力预算AI-ISP 部分假设每帧需要 0.5 TOPS 等效算力30fps 就是 15 TOPS 的瞬时需求但实际是流水线处理按帧摊薄后持续需求约 0.5 TOPS。人形检测假设模型 0.3 TOPS每秒处理 5 帧持续需求约 0.15 TOPS。合计持续需求约 0.65 TOPS但峰值可能到 1 TOPS 以上。这个预算下选一颗 NPU 算力 2 TOPS 以上、且 ISP 有独立 AI 单元的 SoC 会比较稳妥。如果 ISP 和 NPU 共用则 NPU 算力建议 3 TOPS 以上留余量。5. 从模型到芯片一套可复用的选型流程前面讲了原理和难点这一节给一套可以直接照着走的选型流程。这套流程我在几个项目里用过能有效减少返工。5.1 第一步明确模型画像在碰任何芯片之前先把模型画像做出来。需要的信息包括模型类型CNN/Transformer/混合、参数量、计算量MACs 或 FLOPs、输入输出形状、算子清单、量化敏感层。这些信息从训练框架里都能导出PyTorch 可以用 torchsummary 或 fvcore 统计ONNX 模型可以用 netron 可视化。算子清单尤其重要要列出模型用到的所有算子类型然后去对照候选芯片的算子支持列表。不支持的算子要么改模型要么接受回退 CPU 的性能损失。5.2 第二步算延迟和功耗预算根据业务需求算延迟预算。比如实时视频 30fps每帧预算 33ms扣掉前后处理留给模型推理的可能只有 20ms。再根据设备形态算功耗预算电池设备通常 1 到 3W插电设备可以放宽。有了延迟和功耗预算就能反推需要的有效算力。用前面说的公式有效算力 模型计算量 / 延迟预算。比如模型 0.4 TOPS 计算量延迟预算 20ms那有效算力需求就是 20 TOPS不对这里单位要统一。0.4 TOPS 是每秒 0.4 万亿次操作20ms 内完成需要 0.4 / 0.02 20 TOPS 的瞬时算力。这个数字看着吓人但注意这是瞬时需求实际芯片可以流水线处理持续算力需求会低很多。关键是看芯片能否在 20ms 内完成单次推理。5.3 第三步筛选候选芯片并实测根据模型画像和预算筛出 3 到 5 颗候选芯片。然后做实测实测是选型里最不能省的一步。实测内容包括模型转换是否顺利、量化后精度掉多少、单次推理延迟、连续推理的持续性能、功耗实测。实测时要注意测试条件的一致性同样的模型、同样的输入、同样的环境温度。最好能借到开发板自己测而不是只看原厂给的数据。原厂数据往往是在最优条件下测的和实际有差距。5.4 第四步评估工具链和生态实测通过后评估工具链和生态。这一步决定的是开发效率和长期维护成本。重点看文档是否完整、示例是否丰富、量化工具是否好用、是否支持模型热更新、社区是否活跃、原厂支持响应速度。我个人的经验是工具链的权重应该和算力相当。一颗算力稍弱但工具链顺手的芯片项目总成本往往低于一颗算力强但工具链难用的芯片。6. 实操中的坑与经验这一节分享几个我在端侧 AI 部署里真实踩过的坑以及后来总结的应对方法。这些内容在官方文档里基本看不到但实际项目里经常遇到。6.1 量化掉点比预期严重第一次做 INT8 量化时我以为精度掉个 1 个点顶天了结果某些模型掉了 5 个点以上。排查后发现是几个敏感层的问题LayerNorm 后的激活值分布范围大INT8 表示不下Softmax 的指数运算对量化误差放大明显。应对方法是做混合精度量化对这些敏感层保留 FP16其余层用 INT8。主流工具链一般支持按层配置精度。另一个方法是量化感知训练QAT在训练阶段就模拟量化误差让模型适应掉点能控制在 1 个点以内。QAT 成本高一些但对精度要求严的场景值得做。6.2 内存不够导致的隐性失败有一次模型转换和推理都正常但跑一段时间就崩。查了半天发现是内存泄漏KV 缓存没有正确释放。端侧内存本来就紧张这类问题很容易触发 OOM。经验是部署前先算清楚内存占用包括模型权重、激活值、缓存、中间缓冲区。留至少 20% 余量。运行时监控内存曲线发现持续增长就要查缓存管理逻辑。6.3 温度导致的性能波动前面提过持续性能这里说个具体案例。一个车载方案实验室测延迟 25ms装车后夏天暴晒下延迟涨到 60ms 以上。原因是芯片温度升高触发降频。后来调整了散热设计并在软件上做了温度感知的调度高温时降低推理频率保证稳定性。端侧设备的工作环境往往比实验室恶劣选型和调优时要把温度因素考虑进去。有条件的话做高低温测试没条件至少留足性能余量。6.4 算子回退的隐蔽性有些工具链在算子不支持时会静默回退到 CPU不报错只是慢。如果不做性能剖析很难发现。建议部署后用 profiling 工具看每个算子的执行时间和执行单元确认关键算子都跑在 NPU 上。发现回退的算子要么改模型结构要么找替代实现。7. 不同场景的算力方案建议最后按几个典型场景给一些方案建议。这些建议是基于常见实践的合理推断具体选型还要结合项目实际。7.1 手机端影像与语音手机端侧 AI 主要跑影像增强、语音助手、相册搜索等。这类场景对功耗和发热极敏感算力需求中等。建议选择 NPU 算力 5 TOPS 以上、支持 Transformer 加速、ISP 有独立 AI 单元的旗舰或次旗舰 SoC。工具链方面优先选生态成熟的平台减少适配成本。7.2 智能摄像头与安防摄像头场景常开、算力需求集中在视觉AI-ISP 和检测模型是主力。建议 NPU 算力 2 到 5 TOPS重点看 ISP 的 AI 能力和多路视频处理能力。功耗可以放宽到 3 到 5W因为有稳定供电。工具链要支持多模型并行和动态加载。7.3 工业与车载工业和车载场景对可靠性和持续性能要求高环境温度范围宽。建议选工业级或车规级芯片NPU 算力按业务峰值留 50% 以上余量。重点关注持续性能、温度范围和长期供货。工具链要支持功能安全相关的认证需求如果业务需要。7.4 可穿戴与 IoT可穿戴和 IoT 设备算力需求低但功耗要求极苛刻通常靠纽扣电池或小电池供电。建议选带低功耗 always-on NPU 或 DSP 的方案算力 0.1 到 1 TOPS 即可重点是待机功耗和唤醒延迟。模型要用极轻量的关键词检测、简单分类这类任务为主。场景NPU 算力建议功耗预算关键关注点手机影像语音5 TOPS1-3W功耗、Transformer 支持、ISP智能摄像头2-5 TOPS3-5WAI-ISP、多路处理工业车载按峰值留 50% 余量5W持续性能、温度、供货可穿戴 IoT0.1-1 TOPSmW 级待机功耗、唤醒延迟端侧 AI 算力方案这件事没有万能答案只有适合当前约束的取舍。我个人的体会是把模型画像做扎实、把有效算力和带宽算清楚、把工具链权重提上来选型就不会偏太远。实测永远比规格书可靠持续性能永远比峰值重要。项目推进过程中早做 profiling、早发现算子回退和内存问题能省下大量后期返工的时间。