固定芯片上模型怎么变到最聪明这个问题我琢磨了很久。做过端侧AI的人都有同感云端可以堆卡堆显存模型大了就加GPU效果不好就上更大参数但到了嵌入式芯片上一切全都反过来——算力固定、内存固定、功耗固定你只能在有限的资源里“抠”效果。所谓“端侧Scaling Law”说白了就是在不可更换芯片的约束下找到“效果最优化”的路径它不是简单地堆规模而是要在固定天花板下重新定义“什么在增长”。这篇文章不聊虚的。我把这两年做端侧模型优化时踩过的坑、验证过的路子以及身边同行在不同芯片上RK3588、Jetson Orin Nano、STM32MP系列这类都算摸索出的经验系统拆一遍。适合三类人刚把模型跑上板子但效果不理想的开发者、做边缘计算产品选型的技术负责人以及想理解“端侧为什么不能直接套云端大模型”的研究者。读完你会清楚在固定芯片上让模型变聪明不是靠“换模型”那一锤子买卖而是一整套从结构、训练到推理侧的系统工程。1. 端侧Scaling Law与传统Scaling Law的本质差异1.1 传统Scaling Law建立在“可增长”的假设上传统Scaling Law是OpenAI那些人在2020年前后系统梳理出来的规律模型性能随着参数量、训练数据量、算力的增长呈现出可预测的对数或幂律关系。你增加一个数量级的参数配合相应增加的数据和算力模型在验证集上的损失大致会按照一个平滑曲线下降。这条规律支撑了后来GPT系列的疯狂扩展也支撑了“大力出奇迹”这条路线。但这条规律有个隐含前提硬件资源是可以同步增长的。训练时你可以加卡推理时你可以换更大的服务器。模型大了显存不够就上A100再不够就上H100吞吐不行就多机多卡。云端环境下Scaling Law的“三个变量”——参数、数据、算力——基本都能绕开物理限制去放大。到了端侧这个前提直接崩塌。芯片是焊接在板子上的出厂那一刻算力就定了你不能给RK3588再插一张显卡也不能给Jetson Orin Nano换更大的显存颗粒。更麻烦的是端侧还多了两个云端不敏感的新约束内存带宽和功耗墙。参数多了放得下但跑不动或者跑得动但发热降频效果一样拉垮。这就是为什么传统Scaling Law那一套“加参数”的玩法在端侧根本不成立。1.2 端侧Scaling Law真正要回答的问题固定芯片上的Scaling Law实质上是在给定硬件架构芯片算力、内存容量、带宽、缓存策略、功耗预算的前提下找出“什么样的模型结构和训练方式能让精度逼近理论上限”。它的核心变量不再是参数量而是**“有效计算利用率”和“信息密度”**。我习惯用一个公式化的理解端侧效果E 芯片硬件能力H × 模型算法适配度A × 工程落地完整度P。芯片H是固定的你能动的只有A和P。A指的是模型结构、算子在芯片上的映射效率、量化策略等算法层面的适配P指的是推理引擎的调度、内存复用、算子融合、线程优化等工程层面的适配。两个都要做到极致这个乘积才会大。换句话说端侧Scaling Law研究的是“在固定芯片上通过提升每瓦性能、每毫秒性能来换取更大的有效模型容量”。举个例子同样是4TOPS算力的NPUA模型直接跑标准的MobileNetV3B模型用NAS搜出来的定制结构、再做了INT8量化感知训练两者的推理延迟可能一样但B的精度可以明显高出一截。这就是在固定芯片上“变聪明”的本质——不是模型变大了而是每一份算力都被榨得更干净了。2. 固定芯片上让模型变聪明的三条主路径2.1 路径一模型结构侧——用NAS和高效算子“量身定做”很多人一上来就换大模型比如从MobileNetV2换成MobileNetV3或者从Swin-Tiny换成Swin-Small觉得参数多点效果自然好。但结果往往是芯片算力撑不住要么掉帧要么内存溢出。真正常用的方法是用神经架构搜索NAS在目标芯片上直接搜索最优结构。NAS听起来玄乎实际落地时也不要求自己从零写搜索流程。像Google的NASNet、MobileNetV3的NAS搜出的结构都是很好的基础。但针对性不够强——它们是拿GPU或TPU搜的搜出来的算子组合在你的NPU上不一定高效。我见过一个案例同样的ECC图像分割任务在Jetson Orin Nano上跑一个搜索时考虑了内存访问模式的定制结构比直接移植NNI搜出的MobileNetV3结构在相同延迟下mIoU高了2.3个点。原因是定制结构减少了跨内存访问的张量搬移次数把NPU的内部SRAM利用率从40%提到了70%以上。如果暂时不想上NAS也有更朴素的替代手动替换低效算子。比如把常规的Conv3x3替换成可分离卷积把LayerNorm替换成RMSNorm或在线归一化把多头注意力替换成窗口注意力或线性注意力。这些改动不改变整体参数量级但能显著降低芯片上的实际计算时间。再配合通道剪枝Channel Pruning和结构化稀疏把不重要的通道直接减掉精度损失可以控制在1%以内但推理速度能翻倍。关键原则是不要让模型结构去适配芯片而是让芯片的算子库反过来约束模型结构搜索空间。2.2 路径二训练侧——蒸馏、量化感知训练、重参数化三件套结构定好了接下来是训练。在固定芯片上我最推荐的是“大模型蒸馏小模型”路线。大模型在云端训练好把它的logits输出作为软标签去监督小模型学习小模型能学到比硬标签更多的一起语义信息。这比直接用小模型在数据集上从头训通常能带来3~8%的相对精度提升。蒸馏时要注意温度系数的选取我常用的区间是3~10太低了软标签接近硬标签没意义太高了软标签趋于均匀模型学不到区分度。还得兼顾软硬标签损失的比例一般软标签损失权重可以取0.5~0.7需要根据任务类别数调节。训练侧还有一个绕不开的环节量化感知训练QAT。很多人是训练完模型直接用工具转INT8发现精度掉了一大截于是反过来在模型后面加微调。正确的做法是训练时就把整数化伪操作fake quant插到模型里模拟量化误差让模型自己去适应低比特表示。我们用QAT训练好一个INT8模型后在RK3588上几乎没有掉点而训练后量化PTQ掉点经常超过2%。QAT的代价是训练时间变长好在现在很多框架PyTorch、TensorRT、ONNX Runtime都支持自动插入量化节点不需要手写。重参数化RepVGG那种思路也是端侧利器训练时使用多分支结构提升表达能力推理前把分支合并成单路卷积减少计算开销。这个技巧配合剪枝、蒸馏可以在相同芯片上白捡5~10%的推理加速而不掉点。我习惯把重参数化看成“训练时开挂、推理时卸载”它让模型结构在训练和推理阶段解耦训练模型可以更复杂推理模型必须更简单。2.3 路径三推理侧——内存调度、算子融合和缓存布局很多人在模型上花了大力气却忽略了推理引擎的优化空间。固定芯片上数据搬运比计算更贵。我做过一个实测在某个NPU上跑YOLOv5s纯计算时间只占整个推理的40%剩下的时间都在等内存分配、张量copy和算子切换。这就意味着即便你模型计算量减半如果内存布局不优化实际提速可能只有20%。算子融合是解决数据搬运的经典手段。把连续的ConvBNReLU融合成一个算子把LayerNorm的mean和var计算融合进前向过程把相邻的split和concat都合并都能减少中间张量的落内存次数。框架方面TensorRT的图优化、OpenVINO的Plugin、ONNX Runtime的Execution Provider都在做这类事情但针对特定芯片往往还需要手动写一些融合规则。内存池复用也很关键把中间层张量池化分配而不是每个算子都malloc/free能极大减少分配开销。我见过有人通过预分配一块统一的内存池把推理端到端延迟降低了30%。缓存布局这个点容易被忽略但在有复杂缓存层级的多核芯片上影响很大。比如Jetson Orin Nano的GPU L2缓存有限如果你把特征图排成通道数连续的数据格式NHWC可能比NCHW格式缓冲区命中率高不少。芯片不同最优布局也不同没有放之四海皆准的答案一定要在目标板子上做A/B测试。3. 实操复盘在RK3588和Jetson Orin Nano上让模型变聪明3.1 第一步先做硬件瓶颈画像拿到一个项目别急着选模型先把芯片的“脾气”摸清楚。需要收集的指标包括峰值算力TOPS、内存带宽GB/s、可用内存/显存、NPU/GPU的算子支持列表、以及实测的功耗曲线。RK3588有6 TOPS NPU内存带宽取决于所配的LPDDR4/5支持常见卷积/池化/激活算子但对某些大矩阵乘法和动态形状的算子支持不好。Jetson Orin Nano的GPU算力虽然不高但支持TensorRT全集算子内存带宽相对充裕。我的方法是写一个“硬件探测工具”用目标芯片依次跑一遍标准化的算子测试集比如不同尺寸的卷积、不同头数的注意力、不同batch的矩阵乘法记录每个算子的延迟和内存占用。这样你就知道自己的算法规划里哪些算子会拖后腿。比如有个项目想在Jetson上跑LLM量化版结果发现7B模型即使INT4也得近4GBOrin Nano 8G版勉强跑但生成速度极慢于是果断换了更小的3B模型再加4-bit量化速度提升了4倍多。这个决策不是靠感觉而是先看懂了硬件的“账本”。3.2 第二步基于瓶颈选基座和替代架构在固定芯片上做模型选型不能只看Paper指标得结合你的硬件画像来筛选。我给一个常用的判断思路先画一条“延迟-精度帕累托曲线”把候选模型在你的芯片上实际跑出来每个模型在相同输入分辨率下测延迟和精度把点画在图上只保留前沿点。比如目标延迟是30ms你把MobileNetV3、EfficientNet-Lite、RepVGG-B0、RegNet-Y-800MF都跑一遍看看30ms这根竖线上面谁精度最高那就是基座。接下来再考虑任务特殊性。如果是检测任务你可能需要比分类模型多了检测头这时要用更深的骨干轻量检测头组合如果是分割任务编码器-解码器结构里解码器的上采样方式对内存带宽影响很大可以考虑用轻量ASPP或FPN替代大Feature Pyramid。如果是Transformer类任务尽量选线性注意力变体或Swin这类窗口注意力因为全局注意力的复杂度随分辨率平方增长固定算力下撑不住。这里要多说一句不要迷信开源项目的“推荐配置”。很多开源repo默认参数量和FLOPs标称值是在没有考虑硬件算子支持的理想情况下算出来的你在芯片上跑起来会完全不一样。我就遇到过EfficientNet-Lite标称FLOPs只有400M但在某NPU上因为SQ-CAL算子的支持很差实际延迟比MobileNetV3还高30%。所以务必实测。3.3 第三步量化、蒸馏、调优逐步逼近精度上限选定基座后我建议的顺序是先做PTQ快速验证精度底线如果掉点可接受就继续做推理优化如果掉点太多就升级为QAT。同时配合知识蒸馏在训练阶段拉高上限。具体操作可以参照这样一个流水线加载预训练模型ImageNet或大规模数据集上训练过的权重在目标任务的数据集上做迁移训练finetune得到一个高精度的浮点模型。用这个浮点模型作为Teacher训练一个结构相同但替换了部分低效算子或者做了通道剪枝的Student模型用蒸馏损失约束。在Student训练中开启QAT插入fake quant节点把量化误差纳入训练。训练结束后导出ONNX或TensorRT引擎在目标芯片上验证精度和延迟。如果精度还不够回到步骤2调整蒸馏温度、损失权重、剪枝比例。我在RK3588上做过一个实例目标是一个工地安全帽检测模型原方案是YOLOv5sPTQ实测mAP 50只有78.2%延迟45ms。后来改成YOLOv5s结构、但用YOLOv7-tiny做Teacher蒸馏训练时做通道剪枝保留70%通道和QAT。最终mAP 50提升到84.6%延迟降到31ms。整个过程三天搞定没有任何特殊的魔法就是按这条流水线走。3.4 第四步推理引擎层面的挤压与验证模型训练完了部署时选推理引擎也很有讲究。RK3588可以用RKNN ToolkitJetson用TensorRTSTM32MP系列用X-Linux或ONNX RuntimeESP32这类MCU往往得手动做C代码移植。每个引擎都有自己的图优化规则但需要你去配合它。以TensorRT为例建议先把模型转成ONNX用TensorRT的Polygraphy工具查看每一层被替换成了什么plugin有没有走低效的实现。比如有些模型里的Softmax算子TensorRT可能用通用cbr实现如果你换成一个在channel维度上做max difference的算子可能延迟更低。这种细节需要用profile工具测出来才能发现。同样在RKNN上我遇到过模型里的Split操作导致NPU算子切换频率过高手动把Split替换成多个不同slice的拼接后延迟降了20%。最后还要做整链路验证不只测模型推理延迟还要测前后处理图像的resize、归一化、后处理的NMS在CPU和硬件加速单元之间搬运数据的开销。很多端侧项目最终延迟比预期高根本不是模型问题而是前处理拷贝和归一化的格式问题。比如输入图片是BGR但模型需要RGB你在CPU上先转再拷贝到NPU如果直接通过硬件缩放器如RK3588的RGA去转格式和缩放这个开销几乎可以忽略。4. 常见问题与排查技巧实录4.1 精度掉点严重PTQ和QAT的现场检查我见过太多人一上来就跑PTQ掉点超过3%就开始怀疑芯片不行。实际上PTQ掉点大部分原因是激活值分布不均匀尤其是有残差结构、注意力模块的网络。排查时可以输出每一层的激活分布直方图看看是不是极端值拉宽了量化范围。解决办法也很机械先试着只量化权重保留浮点激活看看掉点来源如果确认是激活分布问题一种方案是改用逐通道量化还有一种方案是“分布校正”比如用少量校准数据调整量化阈值。如果都试了还是不行就直接上QAT一般都能救回来。4.2 算子不支持导致转换失败老牌芯片的算子支持列表就那么长新模型里的算子层出不穷。转换时频繁报“Unsupported operator”。不要急着换模型先试试算子重写。比如Transformer里的GELU可以用近似多项式替换LayerNorm可以用RMSNorm替代Multi-head Attention用手动reshape和matmul组合替代Hard-Swish可以用ReLU6的组合近似。这些都是我在部署Transformer类模型时经常动刀的地方。如果重写太麻烦也可以把包含不支持算子的小支路拆出来跑CPU用GPU/NPU跑主体。但这种异构调度会增加内存拷贝非必要不用。4.3 内存溢出或推理时程序被杀固定芯片上内存溢出常出现在两种场景一是模型太大二是推理引擎为每个中间张量都分配了独立缓冲。第二种情况完全可控打开推理引擎的内存池复用选项或者手写一个内存分配器按生命周期复用张量存储。另外要注意多线程与多进程的显式内存分配端侧很多芯片的NPU驱动默认会保留一块内存给自己的context你不去复用就会造成碎片。4.4 表格端侧模型优化问题速查问题现象可能原因排查/解决思路INT8量化后精度掉2%以上激活分布不均、有离群值改用逐通道量化、设置合适的量化阈值、尝试QAT推理延迟高但FLOPs很低算子不匹配、数据搬运频繁用profile工具看算子延迟排序替换低效算子做算子融合转换时提示算子不支持模型结构里有芯片未实现的算子算子重写、用等价结构替代、必要时拆到CPU执行内存占用比估算高很多推理引擎为每层开辟独立缓冲开启内存池复用、统一中间张量存储管理多线程并发时性能下降内存带宽竞争、缓存冲突错峰调度、减少并发、绑定CPU亲和性模型在GPU/PC上效果好但板子差分辨率或预处理方式不同在板子上用同一预处理重新测试确认是模型还是环境导致4.5 避坑技巧不要忽略功耗与降频最后这点特别想强调固定芯片上散热和功耗往往是隐性天花板。哪怕算力标称6 TOPS如果板子被动散热跑满3秒就降频实际持续算力可能只有3.5 TOPS。我在RK3588上调模型时一开始用NPU跑高密度的YOLOv7性能看起来很猛但持久化测试发现功耗高得离谱NPU温度飙到85度后开始降频性能衰减一半。后来改成两个小模型分时调度反而总吞吐更高且稳定。所以优化流程里一定要加入“长稳测试”满载跑至少30分钟记录每秒推理帧数和温度曲线看有没有明显掉帧。芯片厂商给的TOPS是峰值万万不可当成持续性能。5. 端侧Scaling Law的边界与我自己的几点体会5.1 它不是万能的感知端侧智能的天花板端侧Scaling Law能帮你把固定芯片的潜力榨到九成以上但改变不了物理极限。如果你在2 TOPS的芯片上非想跑7B语言模型哪怕量化到2-bit、蒸馏到极致结果也不是“变聪明”而是“变智障”。所以做端侧AI产品前一定要先明确场景的精度底线和时延上限反向推导需要的算力再筛选芯片。端侧Scaling Law本质上是在“限定芯片”这个前提下寻求最优解但前提如果定错了后面所有优化都白搭。现在一些新趋势也在扩展端侧Scaling Law的边界比如端云协同把模型的一部分层放云端一部分放端侧通过分片推理来突破端侧算力限制但这又引入了网络带宽与隐私问题。还有动态推理根据输入难度动态选择不同深度的子网络简单图片走浅层网络复杂图片走深层网络用任务难度换取平均算力的更优分配。这些方向都在尝试把“固定芯片”的天花板再用算法顶高一点但本质还是离不开对硬件特性的精细理解。5.2 我的个人体会做了这么久端侧模型优化我个人最大的体会就是别把Scaling Law当物理定律它更像是“资源配置策略”。在云端你通过堆资源换能力在端侧你通过设计换能力。两者的目标函数完全不同。每次拿到一块新芯片我都习惯先花半天时间做硬件探测再花一天时间画延迟-精度曲线然后才是训练和部署。这个前期准备看着浪费时间却往往能省下后面好几天的返工。另外我也越来越觉得“在固定芯片上变聪明”不只是算法工程师的事它需要硬件、编译器、算法三个角色并肩作战。模型结构设计师要懂芯片的内存层次推理引擎工程师要懂模型的稀疏度分布两者碰在一起才能真正做到把每一毫秒、每一毫瓦都花在刀刃上。总的来说端侧Scaling Law没有统一公式但有一套可靠的方法论吃透硬件画像在结构、训练、推理三条路径上反复迭代用系统化的实验数据驱动每一步决策。听上去不酷但这正是能让模型在固定芯片上“变到最聪明”的踏实路径。
端侧Scaling Law实战：在固定芯片上让模型更聪明的系统方法
固定芯片上模型怎么变到最聪明这个问题我琢磨了很久。做过端侧AI的人都有同感云端可以堆卡堆显存模型大了就加GPU效果不好就上更大参数但到了嵌入式芯片上一切全都反过来——算力固定、内存固定、功耗固定你只能在有限的资源里“抠”效果。所谓“端侧Scaling Law”说白了就是在不可更换芯片的约束下找到“效果最优化”的路径它不是简单地堆规模而是要在固定天花板下重新定义“什么在增长”。这篇文章不聊虚的。我把这两年做端侧模型优化时踩过的坑、验证过的路子以及身边同行在不同芯片上RK3588、Jetson Orin Nano、STM32MP系列这类都算摸索出的经验系统拆一遍。适合三类人刚把模型跑上板子但效果不理想的开发者、做边缘计算产品选型的技术负责人以及想理解“端侧为什么不能直接套云端大模型”的研究者。读完你会清楚在固定芯片上让模型变聪明不是靠“换模型”那一锤子买卖而是一整套从结构、训练到推理侧的系统工程。1. 端侧Scaling Law与传统Scaling Law的本质差异1.1 传统Scaling Law建立在“可增长”的假设上传统Scaling Law是OpenAI那些人在2020年前后系统梳理出来的规律模型性能随着参数量、训练数据量、算力的增长呈现出可预测的对数或幂律关系。你增加一个数量级的参数配合相应增加的数据和算力模型在验证集上的损失大致会按照一个平滑曲线下降。这条规律支撑了后来GPT系列的疯狂扩展也支撑了“大力出奇迹”这条路线。但这条规律有个隐含前提硬件资源是可以同步增长的。训练时你可以加卡推理时你可以换更大的服务器。模型大了显存不够就上A100再不够就上H100吞吐不行就多机多卡。云端环境下Scaling Law的“三个变量”——参数、数据、算力——基本都能绕开物理限制去放大。到了端侧这个前提直接崩塌。芯片是焊接在板子上的出厂那一刻算力就定了你不能给RK3588再插一张显卡也不能给Jetson Orin Nano换更大的显存颗粒。更麻烦的是端侧还多了两个云端不敏感的新约束内存带宽和功耗墙。参数多了放得下但跑不动或者跑得动但发热降频效果一样拉垮。这就是为什么传统Scaling Law那一套“加参数”的玩法在端侧根本不成立。1.2 端侧Scaling Law真正要回答的问题固定芯片上的Scaling Law实质上是在给定硬件架构芯片算力、内存容量、带宽、缓存策略、功耗预算的前提下找出“什么样的模型结构和训练方式能让精度逼近理论上限”。它的核心变量不再是参数量而是**“有效计算利用率”和“信息密度”**。我习惯用一个公式化的理解端侧效果E 芯片硬件能力H × 模型算法适配度A × 工程落地完整度P。芯片H是固定的你能动的只有A和P。A指的是模型结构、算子在芯片上的映射效率、量化策略等算法层面的适配P指的是推理引擎的调度、内存复用、算子融合、线程优化等工程层面的适配。两个都要做到极致这个乘积才会大。换句话说端侧Scaling Law研究的是“在固定芯片上通过提升每瓦性能、每毫秒性能来换取更大的有效模型容量”。举个例子同样是4TOPS算力的NPUA模型直接跑标准的MobileNetV3B模型用NAS搜出来的定制结构、再做了INT8量化感知训练两者的推理延迟可能一样但B的精度可以明显高出一截。这就是在固定芯片上“变聪明”的本质——不是模型变大了而是每一份算力都被榨得更干净了。2. 固定芯片上让模型变聪明的三条主路径2.1 路径一模型结构侧——用NAS和高效算子“量身定做”很多人一上来就换大模型比如从MobileNetV2换成MobileNetV3或者从Swin-Tiny换成Swin-Small觉得参数多点效果自然好。但结果往往是芯片算力撑不住要么掉帧要么内存溢出。真正常用的方法是用神经架构搜索NAS在目标芯片上直接搜索最优结构。NAS听起来玄乎实际落地时也不要求自己从零写搜索流程。像Google的NASNet、MobileNetV3的NAS搜出的结构都是很好的基础。但针对性不够强——它们是拿GPU或TPU搜的搜出来的算子组合在你的NPU上不一定高效。我见过一个案例同样的ECC图像分割任务在Jetson Orin Nano上跑一个搜索时考虑了内存访问模式的定制结构比直接移植NNI搜出的MobileNetV3结构在相同延迟下mIoU高了2.3个点。原因是定制结构减少了跨内存访问的张量搬移次数把NPU的内部SRAM利用率从40%提到了70%以上。如果暂时不想上NAS也有更朴素的替代手动替换低效算子。比如把常规的Conv3x3替换成可分离卷积把LayerNorm替换成RMSNorm或在线归一化把多头注意力替换成窗口注意力或线性注意力。这些改动不改变整体参数量级但能显著降低芯片上的实际计算时间。再配合通道剪枝Channel Pruning和结构化稀疏把不重要的通道直接减掉精度损失可以控制在1%以内但推理速度能翻倍。关键原则是不要让模型结构去适配芯片而是让芯片的算子库反过来约束模型结构搜索空间。2.2 路径二训练侧——蒸馏、量化感知训练、重参数化三件套结构定好了接下来是训练。在固定芯片上我最推荐的是“大模型蒸馏小模型”路线。大模型在云端训练好把它的logits输出作为软标签去监督小模型学习小模型能学到比硬标签更多的一起语义信息。这比直接用小模型在数据集上从头训通常能带来3~8%的相对精度提升。蒸馏时要注意温度系数的选取我常用的区间是3~10太低了软标签接近硬标签没意义太高了软标签趋于均匀模型学不到区分度。还得兼顾软硬标签损失的比例一般软标签损失权重可以取0.5~0.7需要根据任务类别数调节。训练侧还有一个绕不开的环节量化感知训练QAT。很多人是训练完模型直接用工具转INT8发现精度掉了一大截于是反过来在模型后面加微调。正确的做法是训练时就把整数化伪操作fake quant插到模型里模拟量化误差让模型自己去适应低比特表示。我们用QAT训练好一个INT8模型后在RK3588上几乎没有掉点而训练后量化PTQ掉点经常超过2%。QAT的代价是训练时间变长好在现在很多框架PyTorch、TensorRT、ONNX Runtime都支持自动插入量化节点不需要手写。重参数化RepVGG那种思路也是端侧利器训练时使用多分支结构提升表达能力推理前把分支合并成单路卷积减少计算开销。这个技巧配合剪枝、蒸馏可以在相同芯片上白捡5~10%的推理加速而不掉点。我习惯把重参数化看成“训练时开挂、推理时卸载”它让模型结构在训练和推理阶段解耦训练模型可以更复杂推理模型必须更简单。2.3 路径三推理侧——内存调度、算子融合和缓存布局很多人在模型上花了大力气却忽略了推理引擎的优化空间。固定芯片上数据搬运比计算更贵。我做过一个实测在某个NPU上跑YOLOv5s纯计算时间只占整个推理的40%剩下的时间都在等内存分配、张量copy和算子切换。这就意味着即便你模型计算量减半如果内存布局不优化实际提速可能只有20%。算子融合是解决数据搬运的经典手段。把连续的ConvBNReLU融合成一个算子把LayerNorm的mean和var计算融合进前向过程把相邻的split和concat都合并都能减少中间张量的落内存次数。框架方面TensorRT的图优化、OpenVINO的Plugin、ONNX Runtime的Execution Provider都在做这类事情但针对特定芯片往往还需要手动写一些融合规则。内存池复用也很关键把中间层张量池化分配而不是每个算子都malloc/free能极大减少分配开销。我见过有人通过预分配一块统一的内存池把推理端到端延迟降低了30%。缓存布局这个点容易被忽略但在有复杂缓存层级的多核芯片上影响很大。比如Jetson Orin Nano的GPU L2缓存有限如果你把特征图排成通道数连续的数据格式NHWC可能比NCHW格式缓冲区命中率高不少。芯片不同最优布局也不同没有放之四海皆准的答案一定要在目标板子上做A/B测试。3. 实操复盘在RK3588和Jetson Orin Nano上让模型变聪明3.1 第一步先做硬件瓶颈画像拿到一个项目别急着选模型先把芯片的“脾气”摸清楚。需要收集的指标包括峰值算力TOPS、内存带宽GB/s、可用内存/显存、NPU/GPU的算子支持列表、以及实测的功耗曲线。RK3588有6 TOPS NPU内存带宽取决于所配的LPDDR4/5支持常见卷积/池化/激活算子但对某些大矩阵乘法和动态形状的算子支持不好。Jetson Orin Nano的GPU算力虽然不高但支持TensorRT全集算子内存带宽相对充裕。我的方法是写一个“硬件探测工具”用目标芯片依次跑一遍标准化的算子测试集比如不同尺寸的卷积、不同头数的注意力、不同batch的矩阵乘法记录每个算子的延迟和内存占用。这样你就知道自己的算法规划里哪些算子会拖后腿。比如有个项目想在Jetson上跑LLM量化版结果发现7B模型即使INT4也得近4GBOrin Nano 8G版勉强跑但生成速度极慢于是果断换了更小的3B模型再加4-bit量化速度提升了4倍多。这个决策不是靠感觉而是先看懂了硬件的“账本”。3.2 第二步基于瓶颈选基座和替代架构在固定芯片上做模型选型不能只看Paper指标得结合你的硬件画像来筛选。我给一个常用的判断思路先画一条“延迟-精度帕累托曲线”把候选模型在你的芯片上实际跑出来每个模型在相同输入分辨率下测延迟和精度把点画在图上只保留前沿点。比如目标延迟是30ms你把MobileNetV3、EfficientNet-Lite、RepVGG-B0、RegNet-Y-800MF都跑一遍看看30ms这根竖线上面谁精度最高那就是基座。接下来再考虑任务特殊性。如果是检测任务你可能需要比分类模型多了检测头这时要用更深的骨干轻量检测头组合如果是分割任务编码器-解码器结构里解码器的上采样方式对内存带宽影响很大可以考虑用轻量ASPP或FPN替代大Feature Pyramid。如果是Transformer类任务尽量选线性注意力变体或Swin这类窗口注意力因为全局注意力的复杂度随分辨率平方增长固定算力下撑不住。这里要多说一句不要迷信开源项目的“推荐配置”。很多开源repo默认参数量和FLOPs标称值是在没有考虑硬件算子支持的理想情况下算出来的你在芯片上跑起来会完全不一样。我就遇到过EfficientNet-Lite标称FLOPs只有400M但在某NPU上因为SQ-CAL算子的支持很差实际延迟比MobileNetV3还高30%。所以务必实测。3.3 第三步量化、蒸馏、调优逐步逼近精度上限选定基座后我建议的顺序是先做PTQ快速验证精度底线如果掉点可接受就继续做推理优化如果掉点太多就升级为QAT。同时配合知识蒸馏在训练阶段拉高上限。具体操作可以参照这样一个流水线加载预训练模型ImageNet或大规模数据集上训练过的权重在目标任务的数据集上做迁移训练finetune得到一个高精度的浮点模型。用这个浮点模型作为Teacher训练一个结构相同但替换了部分低效算子或者做了通道剪枝的Student模型用蒸馏损失约束。在Student训练中开启QAT插入fake quant节点把量化误差纳入训练。训练结束后导出ONNX或TensorRT引擎在目标芯片上验证精度和延迟。如果精度还不够回到步骤2调整蒸馏温度、损失权重、剪枝比例。我在RK3588上做过一个实例目标是一个工地安全帽检测模型原方案是YOLOv5sPTQ实测mAP 50只有78.2%延迟45ms。后来改成YOLOv5s结构、但用YOLOv7-tiny做Teacher蒸馏训练时做通道剪枝保留70%通道和QAT。最终mAP 50提升到84.6%延迟降到31ms。整个过程三天搞定没有任何特殊的魔法就是按这条流水线走。3.4 第四步推理引擎层面的挤压与验证模型训练完了部署时选推理引擎也很有讲究。RK3588可以用RKNN ToolkitJetson用TensorRTSTM32MP系列用X-Linux或ONNX RuntimeESP32这类MCU往往得手动做C代码移植。每个引擎都有自己的图优化规则但需要你去配合它。以TensorRT为例建议先把模型转成ONNX用TensorRT的Polygraphy工具查看每一层被替换成了什么plugin有没有走低效的实现。比如有些模型里的Softmax算子TensorRT可能用通用cbr实现如果你换成一个在channel维度上做max difference的算子可能延迟更低。这种细节需要用profile工具测出来才能发现。同样在RKNN上我遇到过模型里的Split操作导致NPU算子切换频率过高手动把Split替换成多个不同slice的拼接后延迟降了20%。最后还要做整链路验证不只测模型推理延迟还要测前后处理图像的resize、归一化、后处理的NMS在CPU和硬件加速单元之间搬运数据的开销。很多端侧项目最终延迟比预期高根本不是模型问题而是前处理拷贝和归一化的格式问题。比如输入图片是BGR但模型需要RGB你在CPU上先转再拷贝到NPU如果直接通过硬件缩放器如RK3588的RGA去转格式和缩放这个开销几乎可以忽略。4. 常见问题与排查技巧实录4.1 精度掉点严重PTQ和QAT的现场检查我见过太多人一上来就跑PTQ掉点超过3%就开始怀疑芯片不行。实际上PTQ掉点大部分原因是激活值分布不均匀尤其是有残差结构、注意力模块的网络。排查时可以输出每一层的激活分布直方图看看是不是极端值拉宽了量化范围。解决办法也很机械先试着只量化权重保留浮点激活看看掉点来源如果确认是激活分布问题一种方案是改用逐通道量化还有一种方案是“分布校正”比如用少量校准数据调整量化阈值。如果都试了还是不行就直接上QAT一般都能救回来。4.2 算子不支持导致转换失败老牌芯片的算子支持列表就那么长新模型里的算子层出不穷。转换时频繁报“Unsupported operator”。不要急着换模型先试试算子重写。比如Transformer里的GELU可以用近似多项式替换LayerNorm可以用RMSNorm替代Multi-head Attention用手动reshape和matmul组合替代Hard-Swish可以用ReLU6的组合近似。这些都是我在部署Transformer类模型时经常动刀的地方。如果重写太麻烦也可以把包含不支持算子的小支路拆出来跑CPU用GPU/NPU跑主体。但这种异构调度会增加内存拷贝非必要不用。4.3 内存溢出或推理时程序被杀固定芯片上内存溢出常出现在两种场景一是模型太大二是推理引擎为每个中间张量都分配了独立缓冲。第二种情况完全可控打开推理引擎的内存池复用选项或者手写一个内存分配器按生命周期复用张量存储。另外要注意多线程与多进程的显式内存分配端侧很多芯片的NPU驱动默认会保留一块内存给自己的context你不去复用就会造成碎片。4.4 表格端侧模型优化问题速查问题现象可能原因排查/解决思路INT8量化后精度掉2%以上激活分布不均、有离群值改用逐通道量化、设置合适的量化阈值、尝试QAT推理延迟高但FLOPs很低算子不匹配、数据搬运频繁用profile工具看算子延迟排序替换低效算子做算子融合转换时提示算子不支持模型结构里有芯片未实现的算子算子重写、用等价结构替代、必要时拆到CPU执行内存占用比估算高很多推理引擎为每层开辟独立缓冲开启内存池复用、统一中间张量存储管理多线程并发时性能下降内存带宽竞争、缓存冲突错峰调度、减少并发、绑定CPU亲和性模型在GPU/PC上效果好但板子差分辨率或预处理方式不同在板子上用同一预处理重新测试确认是模型还是环境导致4.5 避坑技巧不要忽略功耗与降频最后这点特别想强调固定芯片上散热和功耗往往是隐性天花板。哪怕算力标称6 TOPS如果板子被动散热跑满3秒就降频实际持续算力可能只有3.5 TOPS。我在RK3588上调模型时一开始用NPU跑高密度的YOLOv7性能看起来很猛但持久化测试发现功耗高得离谱NPU温度飙到85度后开始降频性能衰减一半。后来改成两个小模型分时调度反而总吞吐更高且稳定。所以优化流程里一定要加入“长稳测试”满载跑至少30分钟记录每秒推理帧数和温度曲线看有没有明显掉帧。芯片厂商给的TOPS是峰值万万不可当成持续性能。5. 端侧Scaling Law的边界与我自己的几点体会5.1 它不是万能的感知端侧智能的天花板端侧Scaling Law能帮你把固定芯片的潜力榨到九成以上但改变不了物理极限。如果你在2 TOPS的芯片上非想跑7B语言模型哪怕量化到2-bit、蒸馏到极致结果也不是“变聪明”而是“变智障”。所以做端侧AI产品前一定要先明确场景的精度底线和时延上限反向推导需要的算力再筛选芯片。端侧Scaling Law本质上是在“限定芯片”这个前提下寻求最优解但前提如果定错了后面所有优化都白搭。现在一些新趋势也在扩展端侧Scaling Law的边界比如端云协同把模型的一部分层放云端一部分放端侧通过分片推理来突破端侧算力限制但这又引入了网络带宽与隐私问题。还有动态推理根据输入难度动态选择不同深度的子网络简单图片走浅层网络复杂图片走深层网络用任务难度换取平均算力的更优分配。这些方向都在尝试把“固定芯片”的天花板再用算法顶高一点但本质还是离不开对硬件特性的精细理解。5.2 我的个人体会做了这么久端侧模型优化我个人最大的体会就是别把Scaling Law当物理定律它更像是“资源配置策略”。在云端你通过堆资源换能力在端侧你通过设计换能力。两者的目标函数完全不同。每次拿到一块新芯片我都习惯先花半天时间做硬件探测再花一天时间画延迟-精度曲线然后才是训练和部署。这个前期准备看着浪费时间却往往能省下后面好几天的返工。另外我也越来越觉得“在固定芯片上变聪明”不只是算法工程师的事它需要硬件、编译器、算法三个角色并肩作战。模型结构设计师要懂芯片的内存层次推理引擎工程师要懂模型的稀疏度分布两者碰在一起才能真正做到把每一毫秒、每一毫瓦都花在刀刃上。总的来说端侧Scaling Law没有统一公式但有一套可靠的方法论吃透硬件画像在结构、训练、推理三条路径上反复迭代用系统化的实验数据驱动每一步决策。听上去不酷但这正是能让模型在固定芯片上“变到最聪明”的踏实路径。
