简介这份《端侧AI深度跟踪报告2024·AI“下凡”》为浙商证券出品的行业研究报告面向关注AI产业链的投资者、行业分析师及技术从业者系统梳理端侧AI的技术演进与产业机遇。报告围绕软硬融合、龙头布局、渗透必然性、ChatGPT发展历程、混合AI路径、应用场景及投资建议等模块展开重点剖析NPU算力提升、模型量化剪枝蒸馏等轻量化技术以及手机、PC、XR、汽车、物联网等终端场景的落地逻辑并给出相关标的与风险提示。资源为1个PDF文件压缩包约3.09MB内容完整、目录清晰便于按章节检索研读。目前已有631人学习下载适合希望快速建立端侧AI认知框架、把握云边协同趋势与投资方向的读者参考。1. 端侧AI深度跟踪报告AI“下凡”到底在解决什么问题2024 年最值得工程师花时间研究的方向之一就是端侧 AI。所谓“下凡”说白了就是模型不再只跑在云端机房而是塞进手机、车机、摄像头、工控盒子这些算力和内存都紧巴巴的设备里。过去两年大家习惯了调 API 解决问题但一旦涉及隐私数据不出本地、断网可用、响应延迟压到几十毫秒云端方案立刻露怯。这份深度跟踪报告要回答的核心问题很具体端侧 AI 现在能跑多大的模型、用什么工具链落地、量化到什么程度还能用、以及哪些场景根本不值得往端侧搬。适合正在做智能硬件、边缘计算、移动端推理的从业者也适合想从纯云端开发转向端侧部署的工程师。读完你应该能判断自己的业务该不该上端侧以及第一步该动哪个参数。2. 端侧AI的算力账本为什么“下凡”不是简单搬家端侧 AI 和云端 AI 最大的区别不是模型大小而是资源约束的维度完全不同。云端你可以堆 A100端侧你面对的是 4GB 内存、没有独立显卡、功耗墙卡在 3W 的 SoC。这一章先把账算清楚再谈怎么选型。2.1 端侧推理的四个硬约束内存、算力、功耗、散热内存是第一道坎。一个 7B 参数的模型FP16 精度下光权重就占 14GB这还没算 KV Cache 和中间激活值。手机端目前主流旗舰机型可用内存也就 8-12GB系统还要占掉一半。所以端侧部署的第一件事永远是量化把 FP16 压到 INT8 甚至 INT4权重体积直接砍到 1/4 到 1/8。算力方面端侧芯片的 NPU 算力标称值往往很好看比如 10 TOPS、20 TOPS但实际能跑满的不到三成。原因是算子支持不全、内存带宽瓶颈、调度开销大。我一般会先跑一个矩阵乘 benchmark看实际有效算力是多少再决定模型规模。功耗和散热是连体婴。端侧设备没有风扇持续满载跑几分钟就会触发温控降频。所以端侧推理必须考虑占空比不能像云端那样 7x24 满负荷。常见做法是把推理拆成小批次中间插入空闲窗口让芯片降温。提示选型时不要只看 NPU 标称算力先确认你要用的算子比如 LayerNorm、RoPE、SiLU在目标芯片的 SDK 里有没有硬件加速实现没有的话会回落到 CPU性能直接掉一个数量级。2.2 量化精度怎么选INT8、INT4 与混合精度的取舍量化是端侧 AI 的命根子。INT8 是目前最成熟的方案精度损失通常在 1% 以内工具链支持也最全。INT4 能把模型再压一半但精度损失开始变得不可忽略尤其是小模型上更明显。混合精度是折中方案对精度敏感的层比如第一层和最后一层保留 INT8 或 FP16中间层用 INT4。这样能在体积和精度之间找到平衡点。具体怎么分层我一般用敏感度分析跑一遍看每层量化后对最终输出的影响。# 量化敏感度分析的核心逻辑伪代码示意 # 逐层替换为低精度观察输出误差 import numpy as np def layer_sensitivity(model, calib_data, target_bits4): baseline model(calib_data) # 原始输出 sensitivity {} for name, layer in model.named_layers(): original layer.weight.copy() # 模拟量化缩放-取整-反缩放 scale np.max(np.abs(original)) / (2**(target_bits-1) - 1) quantized np.round(original / scale) * scale layer.weight quantized output model(calib_data) # 用余弦相似度衡量误差 sensitivity[name] np.dot(baseline, output) / ( np.linalg.norm(baseline) * np.linalg.norm(output)) layer.weight original # 恢复 return sensitivity这段代码的逻辑是逐层模拟量化用余弦相似度衡量输出偏移。相似度越低的层说明对量化越敏感应该保留更高精度。参数target_bits控制模拟的量化位宽calib_data要用真实业务数据不能用随机噪声否则敏感度排序会失真。实际工程中INT8 适合大多数场景INT4 只在内存极度紧张且能接受一定精度下降时使用。混合精度需要工具链支持逐层配置目前主流推理框架都有相关接口。2.3 内存带宽才是隐形天花板很多人算端侧算力只算 TOPS忽略了内存带宽。大模型推理是典型的 memory-bound 任务每生成一个 token 都要把全部权重读一遍。如果内存带宽只有 50GB/s一个 4GB 的 INT4 模型跑一次就是 80ms这还没算计算时间。所以端侧模型选型时参数量的优先级往往高于算力。一个 3B 的模型在带宽受限设备上实际吞吐可能比 7B 模型快一倍以上。我一般会先算理论下限模型体积除以内存带宽得到单次推理的最短时间再对比实测值看差距在哪里。3. 从云端到端侧的落地路径工具链与部署流程算完账之后下一步是选工具链和跑通部署流程。端侧 AI 的工具链生态比云端碎片化得多不同芯片平台各有各的 SDK选错了后面全是坑。3.1 主流端侧推理框架对比ONNX Runtime、TFLite、NCNN、MNN选框架的第一原则是看目标硬件。如果跑在 Android 手机上MNN 和 TFLite 的生态最成熟如果是高通平台QNN SDK 能直接调用 Hexagon DSP如果是通用 ARM CPUNCNN 和 ONNX Runtime 都比较稳。框架优势平台量化支持算子覆盖上手难度ONNX Runtime跨平台INT8/INT4全低TFLiteAndroid/Edge TPUINT8中低NCNNARM CPUINT8中中MNNAndroid/iOSINT8/INT4全中我一般会先用 ONNX Runtime 在 PC 上验证模型正确性再转到目标平台的专用框架做性能优化。这样能把“模型本身有问题”和“部署环境有问题”分开排查省很多时间。3.2 模型转换与图优化把 PyTorch 模型变成端侧可执行文件从 PyTorch 到端侧可执行文件中间要过好几道转换。常见路径是 PyTorch → ONNX → 目标框架格式。每一步都可能丢算子或改语义所以每转一次都要做数值对齐。# 第一步PyTorch 导出 ONNX python export_onnx.py --model model.pth --output model.onnx --opset 17 # 第二步ONNX 简化去掉冗余算子 python -m onnxsim model.onnx model_sim.onnx # 第三步转目标框架格式以 MNN 为例 MNNConvert -f ONNX --modelFile model_sim.onnx --MNNModel model.mnn --bizCode biz导出 ONNX 时opset版本很关键太低会缺算子太高目标框架可能不支持。我一般用 17兼容性和算子覆盖比较平衡。onnxsim这步不能省它能消掉训练时留下的恒等算子减小模型体积。最后转 MNN 时--bizCode是业务标识不影响推理但影响日志追踪建议填上有意义的名字。转换完成后必须做数值对齐用同一组输入分别跑 PyTorch 和端侧模型逐层对比输出。误差超过 1e-3 就要查是哪一层出的问题常见原因是算子实现差异或量化引入的偏差。3.3 端侧部署的最小验证流程先跑通再优化我见过太多人一上来就追求极致性能结果连模型都跑不起来。正确的顺序是先跑通再优化。最小验证流程分四步第一步在 PC 上用目标框架的 Python 接口加载模型确认能推理出合理结果。第二步交叉编译到目标架构在设备上跑通单次推理。第三步接入真实输入数据验证端到端精度。第四步才开始做量化、算子融合、多线程这些优化。# 端侧推理最小验证脚本以 ONNX Runtime 为例 import onnxruntime as ort import numpy as np # 加载模型指定执行提供器 session ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) # 构造输入注意 shape 和 dtype 要和导出时一致 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # 跑推理 outputs session.run(None, {input: input_data}) print(输出形状:, outputs[0].shape) print(输出范围:, outputs[0].min(), outputs[0].max())这段脚本的关键是providers参数PC 上用 CPU 就行到设备上要换成对应的 NPU 或 GPU 提供器。输入数据的 shape 和 dtype 必须和导出时完全一致否则会报维度错误。输出范围可以用来快速判断模型有没有跑飞如果全是 NaN 或数值异常大说明转换过程出了问题。4. 端侧AI避坑指南五个血泪教训这一章记录我在端侧部署中踩过的坑每条都按现象、原因、解决来写希望能帮你省点时间。4.1 量化后精度暴跌先查校准集而不是换算法现象INT8 量化后模型精度从 95% 掉到 70%换了几种量化算法都没用。原因校准集用了随机噪声或和业务分布差异太大的数据。量化需要统计激活值的动态范围校准集不对缩放因子就是错的。解决校准集必须从真实业务数据里采样数量不用多几百条就够但分布要覆盖主要场景。我一般会从验证集里分层抽样确保每个类别都有代表。4.2 算子不支持导致回退 CPU用 profiling 定位现象模型在 NPU 上跑但速度比预期慢很多功耗也高。原因部分算子 NPU 不支持框架自动回退到 CPU 执行数据在 NPU 和 CPU 之间来回拷贝开销巨大。解决用框架自带的 profiling 工具看每个算子的执行设备。不支持的算子要么替换成等价的支持算子要么把这段逻辑挪到后处理里用 CPU 单独跑避免频繁拷贝。4.3 内存碎片导致长时运行崩溃预分配内存池现象短时间跑没问题连续跑几小时后进程被系统杀掉。原因推理过程中反复申请释放内存产生碎片最终无法分配连续大块内存。解决启动时预分配内存池推理过程中复用。主流推理框架都支持内存池配置把enable_memory_pool打开并设置合理的池大小。4.4 多线程反而变慢线程数和核心数要匹配现象开了 8 线程推理速度比单线程还慢。原因线程数超过物理核心数线程切换开销大于并行收益。端侧设备核心数通常不多还有大小核差异。解决线程数设成大核数量或者用框架的自动配置。我一般会跑一组不同线程数的 benchmark选吞吐最高的那个值。4.5 温控降频让性能断崖留出散热余量现象刚启动时推理 20ms跑五分钟后变成 80ms。原因芯片温度升高触发降频保护算力被限制。解决设计时按降频后的性能做预算不要按峰值算。如果业务允许插入空闲窗口让芯片降温。实在不行只能换更低功耗的模型或芯片。5. 端侧AI值不值得做一个判断框架和进阶技巧回到最初的问题你的业务该不该上端侧。我给一个简单的判断框架。如果业务满足以下任意两条端侧就值得投入数据隐私要求高、网络不稳定或断网可用、延迟要求低于 100ms、云端推理成本随调用量线性增长且已经很高。反过来如果模型很大且精度要求极高、业务场景对延迟不敏感、数据可以脱敏上云那端侧不是好选择。进阶技巧方面分享一个我常用的方法用投机采样加速端侧小模型。思路是用一个更小的草稿模型先生成候选 token再用目标模型并行验证能在一半算力下达到接近目标模型的输出质量。# 投机采样核心逻辑示意 def speculative_decode(draft_model, target_model, input_ids, k4): # 草稿模型连续生成 k 个候选 token draft_tokens [] current input_ids for _ in range(k): token draft_model.generate_one(current) draft_tokens.append(token) current np.append(current, token) # 目标模型并行验证这 k 个 token target_logits target_model.forward(current) # 逐个比对接受匹配的 token遇到不匹配就截断 accepted [] for i, token in enumerate(draft_tokens): if target_logits[i].argmax() token: accepted.append(token) else: accepted.append(target_logits[i].argmax()) break return accepted这段逻辑的关键参数是k即草稿模型一次生成多少候选。k太小加速不明显太大草稿模型容易跑偏导致接受率低。我一般从 4 开始调根据实际接受率动态调整。草稿模型和目标模型的分布越接近加速效果越好所以草稿模型通常用目标模型蒸馏得到。另一个技巧是 KV Cache 的量化。端侧内存紧张KV Cache 往往占掉很大一块。把 KV Cache 也做 INT8 量化能再省一半内存代价是长上下文时精度略有下降。这个取舍要看业务对上下文长度的要求。最后说个我自己的习惯每次端侧部署前先在一台性能最差的目標设备上跑通再往好的设备上迁。反过来做的话很容易在高端设备上调好了到低端设备上发现根本跑不起来返工成本很高。端侧 AI 这件事下限比上限重要。希望帮到你。本文还有配套的精品资源点击获取
