端侧AI这三个字过去两年几乎被讲烂了。每次行业大会都有人端着手机说“我们已经在端侧跑起了大模型”但真正自己去趟一遍完整链路从选型、裁剪、量化到死磕算子和内存才会明白台上那一句“跑起来”背后有多少妥协和脏活。这篇文章是我自己一段完整工程复盘的记录围绕端侧大模型与端侧AI硬件部署的真实处境展开适合正在评估端侧方案、或者已经进场但被各种诡异性能问题折磨的团队参考。我不会只讲“能跑”我会把为什么能跑、为什么跑不快、为什么换一台设备又跑不起来统统拆开讲。1. 项目起源于三句话为什么非要把AI塞进设备里1.1 需求盘点云端方案在哪些地方卡了脖子这个项目的启动源于客户提出的三个非常具体的诉求。第一大部分使用场景在弱网甚至无网的园区和野外云端推理那条路从物理上就断了。第二业务数据涉及人员行为与操作流程合规要求数据不能离开设备本地。第三实时性要求高从采集到反馈的端到端时延必须控制在几百毫秒内云端往返压根做不到。这几条往桌上一摆端侧AI就不是“锦上添花”而是“唯一解”了。但需求定了挑战才刚刚开始。我最初接到这个任务时心里也打鼓团队里没人真正完成过端侧大模型的完整部署市面上可参考的成熟案例少得可怜大部分是“演示级”的成果——单张图片、固定场景、短对话还行一旦遇到真实业务里杂乱的输入立刻露馅。所以在立项阶段我和团队花了大量时间做了一个动作把“端侧AI”从一个模糊的愿景拆成可量化、可验证的工程指标。比如模型参数量上限、首token时延、生成速度、内存峰值占用、设备温升曲线、电池消耗速率每条都写死最低可接受值。这一步在后来的推进中无数次救了我们因为当合作伙伴和领导层提出各种拍脑袋需求时我们只要拿指标说话就行。1.2 场景边界界定什么事情端侧能做什么事情别硬碰端侧AI工程复盘里最有价值的结论之一就是学会了给场景划边界。不要指望在一台几瓦功耗的设备上复现云端百卡集群的能力这不现实。我们把业务场景分成三类然后只选了中间那类落地。第一类是“每时每刻都在跑”的基础能力比如唤醒词、手势识别、简单场景分类这类任务模型小、功耗低非常适合端侧常驻。第二类是“关键事件触发”的复杂推理比如特定的动作识别、语义理解、结构化信息抽取这类任务需要大模型参与但不需要连续运行通常是事件触发后启动推理然后快速休眠。第三类是“离线训练级”的重活比如全量日志分析、跨周趋势挖掘这类无论如何不该在设备上做属于云端或边缘服务器的范畴。选型逻辑很简单第一类我们顺手做掉第二类是这次项目的核心目标第三类直接砍掉不做端侧化。很多团队栽就栽在贪多上想把第三类也硬塞进端侧结果模型膨胀到跑不动性能指标全线崩盘。记住一个判断标准——如果这个功能需要“持续地”占用超过三分之一的可用算力就不适合放在端侧它更适合做成异步批处理的近端服务。2. 硬件选型的真实考量TOPS不是唯一答案2.1 先算算你需要的算力再去看芯片整个项目里最容易被外界误解的参数就是芯片的TOPS每秒万亿次操作算力。厂商发布会上动辄几十TOPS的数字确实好看但那是理论极限是特定稀疏度、特定数据类型、理想散热条件下的数值真实工况能用到五成就算不错了。所以我们的第一步不是看芯片参数而是估业务侧“真实需要的算力”。以一个关键的CV模型为例单帧前向计算量约7.5 GFLOPs业务要求峰值每秒处理20帧那么算力需求大约是7.5×20150 GFLOPs也就是0.15 TOPS。听起来很低但这只是模型本身还没算预处理缩放到模型输入尺寸、后处理的NMS非极大值抑制、以及多路并发时的争抢。按工程惯例至少留3倍余量也就是约0.5 TOPS的需求。可一旦换成1.5B参数的大语言模型情况完全不同每生成一个token前向传播计算量大约是两倍参数量即约3 GFLOPs同样按20 token/s的生成速度算力需求只有60 GFLOPs。这时你会发现真正卡住LLM的不是算力而是内存带宽。2.2 LPDDR5内存带宽端侧大模型真正的天花板LLM推理是典型的带宽密集型任务。模型参数必须全部从内存搬到计算单元每生成一个token就要搬一遍整个模型。1.5B参数的模型用INT4量化后大概是0.8GB大小市面上主流端侧平台的LPDDR5理论带宽是51.2GB/s实际单核或单NPU能拿到的带宽折扣后大约只有25到30GB/s。算一下30GB/s除以0.8GB理论上限约37 token/s。这是物理天花板和芯片TOPS再高也没关系。所以硬件选型时我们第一眼看的是内存类型和通道数而不是算力。LPDDR5和LPDDR4X的带宽差了一倍以上直接决定了端侧大模型是“能用”还是“没法用”。在移动平台这个约束下带宽32GB/s以上的设备才在备选范围内。顺带说一句这也是为什么很多端侧大模型方案都在宣传“4bit量化”而不是“8bit量化”——把0.8GB压到0.4GB带宽压力直接小一半代价是精度损失需要靠微调或更聪明的量化策略去补。2.3 是通吃还是分工NPU、GPU、CPU各干各的活确定平台后还有一个关键选择模型主体跑在哪。CPU通用性最好实现在任何芯片上都能跑但性能上限低。GPU性能上来了可对内存带宽的消耗比NPU还高能效比吃亏。NPU算力密度高性能上限高但算子覆盖不全。我们最终采用分工策略重计算量的卷积、矩阵乘放在NPU动态shape强、条件分支多的算子留在CPUGPU只兜底处理NPU覆盖不到的并行算子。调度层的开销换来了整体性能和稳定性的平衡。这种异构方案的工程复杂度确实高但从结果看是值得的。纯CPU跑1.5B模型勉强不到5 token/s体验很鸡肋切到NPU加速关键算子后飙升到15到20 token/s质变。GPU在这个方案里其实是“备胎”角色主要跑NPU还没有覆盖的GELU变体、特定attention算子等实测下来分担了约三成计算量效果很明显。3. 模型侧的妥协与坚持从3B砍到1.5B从FP32砍到INT43.1 参数量不是越大越好要看业务容错度最初技术方案里写的是3B模型理由是效果有保障。但把模型放到真实设备上一跑内存和时延双双崩了。3B模型即使量化到INT4也需要约1.6GB内存加上业务本身还需要常驻的CV模型和程序运行空间设备内存直接爆掉。不得已我们退回到1.5B这一档在开源基座里挑了一圈最后选了Qwen2.5-1.5B做底座。选1.5B这个档位并不是拍脑袋拍出来的。我们没有追求“模型全能”而是先把业务高频场景里的评测集做出来围绕真实业务数据去打分信息抽取的F1值、指令遵循的准确率、恶意输入拒答率。用这些指标在同一套评测集上对比多个候选模型后1.5B版本在“信息抽取F1”上比3B版本只掉了3个百分点内存占用却少了一半生成速度翻了近一倍。对于这个项目的业务容错度来说这点精度损失完全值得换来了明显的体感提升。3.2 量化方案的选择INT8稳但不够INT4快但要驯服量化是端侧部署里最考验功力的环节之一。很多人以为量化就是个转换命令跑一下就完事其实里面的坑比想象的多。我们第一版用INT8做PTQ训练后量化效果确实很稳任务指标几乎不掉但内存占用太高生成速度达不到预期。第二版强行上INT4结果特定领域的专业术语出现明显错乱比如把型号“A0-17X”识别成“AO-17X”这在业务里是不可接受的。最终我们采用了混合精度方案注意力机制的QKV投影用INT8保证核心语义不丢失FFN层结构相对不敏感用INT4大幅省内存。为了让这个策略落地需要自己写按tensor粒度指定量化位数的配置。用MNN框架的话量化配置大概长这样from MNN.tools import quantize config { format: INT8, layer_quant: { model.layers.0.self_attn.q_proj: INT8, model.layers.0.self_attn.k_proj: INT8, model.layers.0.self_attn.v_proj: INT8, model.layers.0.mlp.gate_proj: INT4, model.layers.0.mlp.up_proj: INT4, model.layers.0.mlp.down_proj: INT4, } }为了更精细我用一小段脚本扫描全部层名自动给所有attention类算子分配INT8、给MLP类算子分配INT4再手动把输出层、嵌入层排除在量化范围外。经验是嵌入表和最后的lm_head层尽量保持高精度它们对输出token质量影响最直接强行量化会明显拉低回答质量。3.3 让模型“够用”而不仅是“能跑”评测体系必须先行这里想多说一句端侧AI工程里模型评测不是最后一个环节而是第一个环节。我们犯过一个典型错误——SPA样机阶段只测了理想输入的效果结果上真机后被五花八门的真实输入打懵了。后来学乖了让业务方把三个月的脱敏日志全捞出来标注了一千多条测试样本覆盖正常case、模糊case、刁钻case。没有这套评测集后面的量化参数调优、模型裁剪评估全都无从谈起。评测集之外还需要一套可重复跑分的回归脚本。每次更新模型版本或量化配置后自动在统一数据集上跑出指标报告这样任何一次改动是好是坏一目了然而不是靠“我觉得效果好像变好了”这种玄学判断。工程上有个朴素的道理你敢说一个方案有效前提是你有可复现的证据来支撑它。4. 部署链路搭建推理框架选型与算子适配4.1 为什么绕过最火的llama.cpp选MNN做主力框架这个决定在团队里吵了很久。llama.cpp社区热、跑LLM方便、更新快舆论声量最大。但做端侧AI硬件部署有一个很现实的问题llama.cpp主打的是CPU和部分GPU场景在移动芯片NPU上几乎没有可用的后端。我们的项目既要跑1.5B大模型又必须同设备常驻一个CV模型、做异构调度最合理的技术路径是选用一个厂商中立、NPU后端相对清晰、算子覆盖广的框架。对比下来MNN在移动端算子覆盖和ARM/高通平台的优化上更贴合我们的长期需求。当然不是选了某个框架就被绑定死了。我们用OpenCL和Vulkan各写了一套高性能算子关键路径上直接绕过框架层根据自己的模型结构手写底层实现性能提升非常可观。这个魄力来自实测一个自定义的FlashAttention算子直接调用框架自带实现和手写实现端到端时延差了将近四倍。框架只是基础设施真正的性能还是要靠对底层硬件的理解。4.2 算子替换一个GELU激活函数引发的性能回退算子适配是端侧AI部署里“看不见的战场”。业务侧真正跑起来后我们发现有个模型层始终无法在NPU上加速定位后发现是GELU激活函数的高精度近似问题。NPU对近似GELU的实现细节、精度门槛有硬性约束不满足就直接拒绝加速。这个在工程上叫“算子落盘失败”模型从头到尾跑的是CPU兜底路径性能直接回退60%以上。解决方式是在保持数值近似的条件下把GELU替换成NPU友好的近似形式。典型做法是用一个二阶多项式拟合GELU在[-4, 4]区间的曲线误差控制在1e-4量级对最终任务指标影响可以忽略。替换时特别注意不仅要在训练框里去改算子定义还要在推理框架的图优化阶段同步替换。只改一端会造成训练和推理行为不一致导致线上精度崩坏而自己浑然不觉。这类算子替换的排查思路对端侧AI工程非常关键。每当一个模型层标记“can_offloadfalse”时不要只看它是什么函数还要看这个函数内部的数值逻辑和NPU硬件的匹配度。函数名一样、数值实现不同NPU的接受度天差地别。4.3 异构调度也要讲究策略常驻流水线的搭建模型本身部署好之后剩下的工作就是把流程串起来。我们要做的是一个事件驱动的推理流水线AI Camera完成采集和移动侦测CPU上常驻一个轻量的场景分类模型做帧级粗筛只有命中特定事件类型才激活大模型做深度分析大模型跑在NPU和CPU的混合调度上结果经过结构化后传出。伪代码大概长这样// 采集线程 cv::Mat frame capture.read(); if (motion_detector.detect(frame)) { scene_label classifier.run(frame); // CPU, ~5ms if (scene_label TARGET_SCENE) { // 因为有优先级所以用异步队列不阻塞采集 analysis_queue.push(frame); } } // 分析线程 while (true) { frame analysis_queue.pop(); npu_feature encoder.run(frame); // NPU, ~30ms text_prompt build_prompt(npu_feature); output llm.generate(text_prompt); // NPUCPU 混合, ~800ms save_result(output); }调度层面有个易踩的坑NPU任务和CPU任务如果调度得不对上下文切换和显存拷贝的开销会吃掉所有性能优势。所以我们在流水线上加了显存池复用机制输入数据不重新拷贝直接在原buffer上做推理同时给NPU任务设置了较高的线程优先级避免被各类后台任务抢占。这套组合下来流水线整体时延比各模块简单串起来的版本降了约45%。5. 踩坑实录与排查技巧那些文档里不会告诉你的问题5.1 内存泄漏进程看着正常推理时长却越来越长最诡异的问题是内存泄漏。现象很典型设备刚开机时推理一次只要600ms跑了两小时后单次推理涨到900ms以上重启后恢复。用内存监控工具一看NPU上下文和推理中间缓存在持续增长跑两小时吃掉近300MB内存。原因在于框架的NPU缓存池没有按预期回收某些中间tensor被反复分配但从未释放。后面在明确的op边界强制调用缓存回收接口同时给NPU上下文加上限设置问题才解决。5.2 首次推理特别慢一切问题都可能出在懒加载和预热上另一个坑是“首帧效应”。接口第一次被调用时耗时是后续调用的十倍以上一度以为框架初始化卡死。后来发现整个推理链路里包含模型加载、kernel编译缓存、内存池初始化三段都会在第一次运行时触发尤其kernel编译在目标芯片上耗时长达2到5秒。解法是在启动阶段主动执行一次少量字节的“热身推理”强制触发所有懒加载逻辑和kernel编译缓存写入。实测下来从冷启动到可稳定推理的时间从原先的8秒压到了2秒内。5.3 省略散热策略性能会随时间大幅缩水端侧设备和服务器最大的区别之一就是没有主动散热。高负载推理持续几分钟后设备表面温度迅速攀升到45℃以上芯片开始触发热降频性能肉眼可见地跳崖。一开始我们没把功耗当回事直到峰值测试时设备突然卡顿一看频率曲线果然被压到了最低档。解决方案分软硬两层硬件上我们加了石墨烯散热贴和均热板软件上做了推理频率切换策略——连续推理三分钟后根据温度传感器主动降一档频率等温度回落后再升回来保证平均吞吐量而不是瞬时峰值。5.4 排查三板斧分层计时、CPU基线、内存监控做端侧AI工程复盘之后我把调试方法论总结成三板斧。第一分层计时把耗时打点在采集、预处理、模型推理、后处理、输出五个阶段任何性能问题先用日志定位到具体层不凭感觉瞎猜。第二CPU基线当NPU/GPU推理结果不对时先用CPU跑一遍同一模型得到“标准输出”对比NPU输出定位差异层这个方法能快速区分是模型问题还是硬件算子问题。第三内存监控持续记录进程内存和芯片内部显存池占用观察曲线形态判断是否存在泄漏或不断增长的缓存。这三板斧对多数端侧AI调试场景都适用也是我给团队培训时反复强调的基本功。6. 复盘后的一些判断端侧AI适合什么不适合什么6.1 什么样的项目适合端侧AI三个必要条件做完这个项目后我对“什么项目适合端侧AI”有了更清晰的判断。第一业务的实时性要求确实高到云端方案无法满足或者网络条件差到云端方案不成立这时候再考虑端侧。第二业务数据量是有限且可裁剪的端侧模型的输入输出都是结构化程度较高的小数据不适合承载海量无界的信息流。第三团队里至少要有一个人能同时理解模型结构和底层硬件指令集如果完全没有这个能力端侧AI项目大概率会卡在性能优化阶段。6.2 哪些场景我不推荐端侧AI先泼个冷水单纯为了“去云端化”而端侧化趋势很热但场景不匹配这个理由我见过太多次基本都会后悔。复杂的多轮对话、大规模知识库检索、需要频繁更新知识的业务都不适合端侧。端侧模型更新一次要重新走镜像打包、灰度放量、真机验证的流程周期是云端微调的十倍不止。知识每两天就变一轮的业务放在端侧就是给自己挖坑。另外纯To C的通用助手类产品我也不建议贸然端侧化——用户对效果的要求远高于对隐私的在意程度云端大模型的智商优势会碾压端侧小模型这种产品拼的是模型能力上限不是隐私或离线能力。6.3 端侧AI这个方向之后还能怎么做未来可以拓展的方向抛开工期的角度看端侧AI很值得我们继续投入。在下一阶段我们打算做两件事一是针对业务场景做模型蒸馏加结构化推理把识别准确率做到跟更大模型接近二是利用端侧设备的空闲算力让模型在本地做异步的增量学习和个性化微调真正把死板的端侧模型变成越用越懂业务的贴身助手。以技术演进的速度端侧AI后劲不小但前提是选对场景、配好硬件、调稳链路。我个人的体会是不要被“端侧AI”这四个字制造的光环牵着走把工程链路里每一段都摸透了自然知道它能做什么、不能做什么。