当你在RK3588、Jetson Orin Nano或者一块老旧的STM32F4上部署模型时大概率会有一种感受模型从云端迁到端侧不像是搬家更像是带着镣铐跳舞。你的显存、算力、功耗被芯片死死焊住能用的模型参数量被压到几十M甚至几K——这时候一个反直觉的问题就冒出来了在硬件锁死的前提下模型怎么才能“变到最聪明”这两年业内喜欢把大模型的“大力出奇迹”往端侧搬张口闭口Scaling Law仿佛只要把参数堆上去模型就能开窍。但我在实际部署中体会到的真相是端侧的Scaling Law不是“参数规模曲线”而是“硬件红线内的智能收益曲线”。芯片不会越用越聪明但你在固定算力、固定内存、固定功耗下确实存在一条让模型“逼近硬件上限智能”的最优路径——沿这条路走下去模型的目标函数损失能持续下降对外表现的智能水平能肉眼可见地提升直到触碰到芯片物理极限的那堵墙。这篇文章不是复述论文里的公式而是把我过去在多个端侧项目里反复试错总结的经验摊开来讲固定芯片上模型的智能增量从哪里来哪些操作是真正踩在Scaling Law关键路径上的哪些做法只是自我感动。全文会围绕芯片资源约束、模型结构改造、量化与蒸馏、推理时策略这几个维度展开最后给出一套能在真机上复现的调优流程。1. 固定芯片上为什么模型不是“越大越聪明”先说一个我在项目里反复见过的现象很多人拿到一块芯片第一反应是去找“这块板子能跑到多大的模型”。跑不动就换NPU再跑不动就上云仿佛模型参数量是智能的唯一开关。这种思路放在云端数据中心里没有大问题因为那里算力和显存是弹性资源。但端侧完全不同——芯片的MACs乘累加运算量是固定值内存带宽是固定值SRAM/DRAM容量是固定值甚至散热限制下的持续功耗也是固定值。你可以把一套更大的模型硬塞进去但换来的往往是两件事要么推理时延超过产品红线要么模型被量化到精度崩坏智能水平反而倒退。1.1 “能跑起来”和“跑得好”是两个世界给芯片选模型时我习惯先算一个账MACs预算。假设一块芯片的NPU算力是2 TOPS每秒2万亿次整数运算你要求推理时延不超过150ms那么单次前向能消耗的MACs上限大约是可用MACs 算力 × 时延 2 × 10^12 × 0.15 3 × 10^11也就是3000亿次乘累加。一个MobileNetV3-Large输入224×224大概需要2.2亿MACs而一个ResNet-50大约要41亿MACs至于一个轻量级ViT-Small224×224可能就得跑到85亿MACs以上。光看这个数字感觉ResNet-50也很轻松。但别忽略第二个预算内存带宽。1.2 推理时真正卡脖子的是数据搬运端侧芯片的算力往往不是瓶颈带宽才是。你可以把算力理解成厨师的刀工而内存带宽是给厨师递菜的小工。小工递菜的速度上不去厨师的刀再快也只能空转。每次模型推理要读入权重、读出中间激活值这部分数据从DRAM搬运到SRAM和计算单元的时间通常是算力时间的数倍。一个典型例子在一块内存带宽只有25.6GB/s的芯片上跑一个85亿MACs的ViT-Small光是权重和数据搬运就可能耗尽所有时延预算NPU有70%以上的时间在等数据。这也解释了为什么在端侧小模型高吞吐往往比大模型低吞吐更“聪明”——因为同样的时延预算下小模型可以跑更高分辨率、更多帧率或者把空间留给更复杂的后处理逻辑。我做过一个检测项目用MobileNetV4比用轻量ViT在实际任务得分上高出4个点原因很简单MobileNetV4在相同时延下能把输入分辨率从160提到224小目标召回率一下就上来了。模型参数量缩了任务效果反而涨了这就是端侧Scaling Law的第一步认知不是让模型适应芯片而是在芯片约束内重定义“大”的含义。1.3 芯片的“聪明上限”由内存容量画死除了算力和带宽第三个隐形天花板是内存容量。人脑大概有860亿神经元但端侧芯片连一个2B参数的模型都未必装得下权重。以4-bit量化后的2B模型为例仅权重就需要约1GB存储空间再加上激活值、运行时缓存推理时对内存的需求轻松超过2GB。而一颗典型的边缘芯片如瑞芯微RK3588的8GB版本虽然内存看起来够用但实际能分给NPU的连续内存块往往受限系统可用内存还要被操作系统、摄像头、编码器瓜分。我踩过的一个坑在一块4GB内存的板子上部署量化后的1.8B模型权重只占800MB但跑起来直接OOM。排查后发现问题出在自回归生成时KV Cache的峰值占用——生成长上下文时KV Cache增长是瞬时的如果不对序列长度和batch做限制内存直接爆炸。后来我把输入token上限砍到1024、batch设为1并把KV Cache做了量化才把这颗模型塞进去。所以固定芯片上Scaling Law的第一层真实含义是模型的有效智能上限是被“计算预算-带宽预算-内存预算”三条红线同时框定的缺任何一个维度参数量再大都是假的。2. 算力、带宽、内存的三角硬约束与“MLPerf式”预算拆解既然三条红线共同决定模型能做到多聪明那么在动模型之前就得先精确度量你的芯片到底有多少“预算余量”。这一步做扎实了后面所有模型结构改动、量化策略才能有的放矢。2.1 三条红线的实测方法论不要只看芯片厂商的Datasheet务必在自己板子上实测。算力实测可以用一个经典的卷积算子基准如GEMM跑10万次测出实际TOPS。大多数芯片实测性能只有理论峰值的60%~80%我的经验是取70%作为规划值比较稳妥。带宽实测用连续的纯拷贝测试比如读取200MB数据做memcpy计算实际GB/s。这个数值对后续判断“模型是否带宽饱和”至关重要。内存实测用摄像头跑一轮记录系统空闲内存再用独占方式申请连续内存块看能申请多大。很多端侧芯片的NPU要求输入/输出内存物理连续这意味着常规malloc碎片化后大块内存根本申请不下来只能求助ION/DMA-BUF池。实测结果出来之后就可以做三线预算拆解。拿一个典型的RK3588项目举例硬件资源理论值实测规划值NPU算力6 TOPS4.2 TOPS按70%内存带宽约51.2GB/s约36GB/s按70%可分配连续内存8GB总内存约1.5GB余量保守估计2.2 用“三层漏斗”判断模型改哪里预算数字到手后我会对每个候选模型做一个推理成本拆解分成三个漏斗层计算层模型的理论MACs。如果这一层超了预算就是参数或结构选大了需要换结构或剪枝。搬运层权重内存读取量 激活值回写量。如果这一层超了说明模型是带宽饱和型优先做权重压缩、激活值精简。驻留层峰值内存占用。如果超了优先减batch、减序列长度、做算子间内存复用。一个很常见的判断结果很多轻量模型算力上明明满足但实际跑起来还是慢就是因为第二层“搬运层”超了——模型大量使用了对带宽不友好的算子比如逐元素的Silu、GELU、LayerNorm这些算子MACs不高但每次都要把整张特征图搬进搬出。我在部署Transformer类模型时尤其会关注LayerNorm的搬运开销因为它涉及均值/方差两次全图扫描在长序列场景下会吞掉大量带宽。这里给一个实操技巧跑一版ONNX Runtime的profiling日志看算子级耗时占比。如果发现Reshape、Transpose、LayerNorm这类“非计算算子”占了总时延30%以上那么这个模型在固定芯片上的优化重点就不该是减MACs而是融合算子、精简数据搬运逻辑。2.3 一张“芯片-模型预算表”的用法我会把候选模型逐个填入这张表模型MobileNetV4-Small 输入224×224×3 MACs1.1G 权重大小7.4MBFP16 激活值峰值约12MB单张 估算时延1.1G / 4.2TOPS ≈ 0.26ms纯算力 带宽消耗权重7.4MB×2 激活往返约24MB ≈ 38.4MB 估算搬运时延38.4MB / 36GB/s ≈ 1.07ms 实际预期时延max(计算时延, 搬运时延) 系统开销 ≈ 1.5ms~3ms这张表最大的作用是帮你提前发现瓶颈在哪个维度。如果计算时延和搬运时延差一个数量级就说明模型结构选得不对路——你要么选择一个计算密集但数据搬运少的结构要么直接用算子融合把搬运量压下来。总之端侧模型的Scaling Law是预算先行结构随后绝不能反过来。3. 模型侧能拉动的真正杠杆结构重设计、蒸馏与量化硬件预算摸清了接下来才是重头戏在固定芯片上怎么把模型的智能水平往上推。这是我和很多同行反复讨论最多的地方也最容易出现“玄学调参”。我总结下来真正稳定有效的杠杆只有四类结构重设计、蒸馏、量化与压缩、推理时策略优化。它们各自占的权重不同见效节奏也完全不同。下面逐个拆开说。3.1 结构重设计为了适配芯片形状甚至可以“反着”设计模型结构重设计是收益最大、但成本也最高的一步。很多团队的做法是拿现有模型库里的模型直接部署完全放弃为芯片定制结构这是比较浪费的行为。为什么需要结构重设计因为端侧推理引擎尤其是NPU对算子的支持程度和图连接形态有极强的偏好。同样是3×3卷积在高通Hexagon、瑞芯微NPU、海思NNIE上可能分别被映射成完全不同的微内核。一个在GPU上表现优异的ConvNeXt结构到了NPU上可能因为密集的Depthwise卷积逐元素乘而严重带宽饱和。比较典型的端侧友好设计包括避免过大特征图把下采样尽早做掉让卷积在低分辨率特征图上进行能大幅节省计算量。比如MobileNetV3的硬编码下采样策略就比ViT早期Patchify的策略对端侧友好得多。减少逐元素算子把GELU换成ReLU或者HardSwish把残差连接融合进卷积偏置这些都是为了减少特征图搬运次数。通道数对齐硬件加速单元很多NPU的MAC阵列宽度是8或16的倍数通道数非对齐会导致填充计算浪费算力。我在RK3588上实测过把模型最后一个阶段的通道数从96改成128对齐64的倍数推理速度反而提升了18%因为填充开销没了。我在一个工业检测项目里做过一次完整的结构重设计基线模型是一个MobileNetV2为基础的分割网络量化后mIoU只有0.62。后来改成EfficientNet-Lite的骨架更浅的ASPP头整体参数量少了40%mIoU却提到了0.71。原因是EfficientNet-Lite的SE模块在NPU上能被折叠进卷积融合相当于把注意力机制“免费”跑了一部分。3.2 蒸馏用小模型把“大模型的智能”榨出来在固定芯片上你永远不可能直接跑一个7B模型。但你可以让7B模型的智能通过蒸馏进入一个小模型这正是端侧Scaling Law最神奇的地方——“智能”不完全由参数量决定而是可以通过监督信号迁移的。蒸馏的关键点在于选对“教师信号”和“蒸馏温度”。课堂式蒸馏用大模型的Logits作为软标签。常见做法是用温度T4的softmax把教师的概率分布压平让学生模型去拟合这个分布。相比硬标签软标签包含类间相似性信息学生模型学到的不只是“正确答案”还有“错误分布”这对小模型的泛化提升非常明显。特征蒸馏不只对齐输出层还对齐教师模型的中间特征。做法是让学生模型的中间特征图和教师对应层特征图做L2 loss不过要注意分辨率匹配以及通道数对齐。我在做语义分割时发现特征蒸馏比输出层蒸馏带来的mIoU提升高出约1.5倍因为它约束了小模型在每个空间尺度上的表征能力。对比蒸馏部分场景如人脸识别、检索下用对比学习把教师模型的embedding空间结构迁移给学生效果也很好。具体做法是构造正负样本对让学生模型的相似度矩阵靠近教师的相似度矩阵。实操中一个容易被忽略的细节教师模型不一定是云端大模型也可以是同一个芯片上能跑的更重模型比如FP32版本。我在做端侧人脸识别时最有效的教师恰恰是跑在同一个芯片上的FP32 MobileFaceNet——蒸馏后再量化到INT8比直接从FP32量化到INT8准确率高不少。这个小技巧很适合没有云端大模型资源的团队。3.3 量化与压缩让权重体积换回智能密度量化是端侧部署绕不开的环节但很多人的量化只是“从FP32转到INT8就算完事”。实际上量化的粒度、校准策略、量化算子敏感度都会直接决定模型最终的“聪明程度”。常见量化层级效果对比量化方案模型体积变化精度损失适用场景FP16缩小50%几乎为零支持FP16的NPU/DSP动态量化INT8缩小75%轻度兼容性要求高感知量化QAT缩小75%极小关键任务、精度敏感混合精度量化缩小50%~85%可控部分算子对量化高度敏感我的一个核心建议是优先用QAT量化感知训练而不是后训练量化PTQ。PTQ虽然方便但遇到敏感算子比如带有大动态范围的Softmax、LayerNorm时精度下降非常剧烈。QAT在训练阶段就让模型适应量化噪声收敛后的模型对INT8的鲁棒性远好于PTQ。这里分享一个避坑点量化过程中要单独统计每个通道的绝对值最大值用于确定scale。如果做的是per-channel量化且某个通道值域特别稀疏会拉低整个张量的精度。一个常见修复做法是给敏感通道单独留一个浮点分支混合精度方案中的极简实现或者用范围裁剪clip去掉长尾离群值。压完权重之后也可以考虑权重共享、剪枝与低秩分解。但在实际部署中我建议优先做结构重设计与蒸馏剪枝放到最后——因为剪枝后的模型在NPU上不一定能获得理论上的加速很多NPU对稀疏性支持有限如果微内核没有针对稀疏做优化剪枝只省存储不省算力。3.4 推理时策略把“pading算法”改成“路径选择算法”固定芯片上不仅模型本身可以被优化推理时的策略同样重要。打个比方模型是大脑推理策略是大脑调用知识的方式。同一个大模型如果每次只让被调用的部分参与计算动态路由芯片同样能享受到“模型结构变小”的红利。动态深度与动态宽度类似早期的BranchyNet或MSDNet思路给模型增加早退出口——输入简单时从浅层出口直接出结果输入难时才跑到深层。这个在端侧很有价值因为很多场景下输入样本难度分布极度不均衡。我在停车场车牌识别项目里加了两个早退出口平均推理时延下降了41%而准确率只下降了0.8%。上下文剪枝与KV Cache量化对LLM类模型来说推理时每条输入有自己的最佳上下文长度。我试过在Jetson Orin Nano上部署一个1.5B模型输入token长度从2048砍到512时延直接减半而任务关键指标只下降了大约3%。KV Cache做INT8量化又省了一截带宽。Cache与异步流水如果产品是持续视频流分析可以用双缓冲机制把帧采集和模型推理流水线化让芯片在采帧间隙就开跑下一帧的推理。这个不改变模型结构但实际能提升2倍以上的处理帧率。我常被问到“帧率上不去怎么办”很多情况下不是模型慢而是同步调用把NPU的空档期全浪费了。4. 端侧Scaling Law的实操方法论从调优到验证的一条龙流程前面说的都是原理和单项技术。这一节我给出一个可以直接抄作业的实操流程是我在多个端侧项目里固定下来的一套打法简称“六步调优法”。每步都对应上面的杠杆原理顺序很关键不要跳步。4.1 第一步预算测量与瓶颈定位约半天到一天用第2节的实测方法拿到芯片三个资源线的实际值然后对候选模型做profiling日志分析定位当前版本的“最短木板”到底是计算型、带宽型还是内存型。输出物一张芯片预算表、一份模型算子耗时分解表。判断词如果耗时集中在Conv/GEMM是计算瓶颈如果集中在Transpose/LayerNorm/Reshape等搬运操作是带宽瓶颈如果出现OOM或内存分配失败是驻留瓶颈。4.2 第二步对症的结构手术一到两周计算瓶颈 → 换计算更密集的结构或者降低输入分辨率。带宽瓶颈 → 算子融合、减少逐元素算子、把LayerNorm折叠到前层。内存瓶颈 → 减序列长度/batch、做算子间内存复用、激活值检查点。到了这一步很多人会发现原本选定的模型已经被改得面目全非。没关系要记住你追求的不是“模型原样部署”而是“模型在芯片上达到最聪明状态”。4.3 第三步用蒸馏把手术损失补回来数天到两周结构重设计之后通常会有少量精度损失用蒸馏来弥补。教师用FP32的大模型或云端模型学生用结构重设计后的小模型。几个实操参数供参考温度T设在4~6之间。输出层蒸馏loss权重为0.5特征层loss权重为0.5。学习率建议使用余弦衰减从1e-4左右开始。用Teacher的软标签做辅助训练不要只靠硬标签。4.4 第四步量化感知训练巩固精度三到五天把蒸馏后的小模型用QAT方式训练若干epoch模拟INT8推理时的量化噪声。两个关键点第一QAT训练时要冻结BN层的统计量或直接移除BN否则量化误差会因BN统计波动变大第二校准集要覆盖真实推理时的数据分布不要只用训练集。我在跑QAT时常用的训练策略是先用FP32 蒸馏fine-tune 3个epoch然后开启量化模拟继续训练3个epoch最后把量化模拟关闭再继续fine-tune半个epoch收尾。4.5 第五步推理引擎适配与算子替换两天到一周结构设计和压缩都做好了最后一步是把计算图映射到具体芯片的推理库上。根据不同芯片选择不同的引擎芯片类型推荐推理引擎高通芯片QNN / SNPE瑞芯微RK系列RKNN Toolkit英伟达Jetson系列TensorRT / TensorRT-LLM通用CPUONNX Runtime XNNPACK轻量MCUTFLite Micro / CMSIS-NN这个阶段最常遇到的问题就是算子不支持或被替换成低效实现。我的经验是先跑一遍引擎的算子支持列表再对照模型结构提前替换比如把HardSwish换成ReLU6把Softmax换成近似实现等。在这里分享一个我很常用的判断准则如果一个算子占用5%以上推理时间就不要让它在CPU上兜底执行。端侧引擎往往会有“算子分派”选项指定某些算子走CPU或不支持的NPU会严重拖慢时延。4.6 第六步端到端验证与指标回归不要只看模型精度指标一定要看真机上的端到端体验指标。推理时延、内存峰值、功耗、温度、帧率稳定性都要测。这一步的产出是一张最终性能基线表精度、时延、内存、功耗以及“模型-芯片”匹配度的结论。如果你发现端到端指标还是没达到产品要求就从第一步重新来但这轮你会带着对芯片瓶颈更清晰的认知。4.7 一个完整案例的复盘我在Jetson Orin Nano上部署过一个2B参数规模的对话模型。初始方案直接部署INT8量化后的模型端到端时延高达2.8秒/token完全不可用。按六步流程走下来预算定位发现带宽是主要瓶颈内存接近上限。结构手术把模型的Embedding层和部分FFN层的维度减半并改用共享权重参数量降到1.1B。蒸馏用原版2B模型做教师蒸馏后小模型在评测集上的得分从86.3降到84.9损失可控。QATINT8量化后精度只掉了0.3个点对比PTQ的2.1个点下降。推理引擎改用TensorRT-LLM做流式生成打开KV Cache量化。验证最终端到端时延降到0.7秒/token内存峰值控制在1.6GB以内可稳定运行。结论同样的芯片模型参数量砍了45%但对话智能水平只降了不到2%时延反而缩短到原来的1/4。这就是固定芯片上下Scaling Law的真实形态——不是追求参数量最大而是把单位算力内的智能密度榨到最高。5. 反复踩过的坑与判断“模型变聪明”的正确姿势最后聊几个我在实战中被反复教育过的坑以及在端侧如何正确衡量“聪明”。5.1 坑一量化后只用ImageNet-1k的验证集做指标老实说这是最典型的自欺欺人。量化对模型的影响和输入分布高度相关ImageNet上的表现并不能代表你真实业务场景下的表现。我见过一个分类模型在ImageNet val上INT8只掉1%但在实际窄带物联网图片上直接崩了7%。原因就是真实图片有大量过曝、暗光、低对比度样本激活值分布和ImageNet完全不同量化scale失真。解决办法校准集和验证集必须来自部署现场采集的数据。哪怕只有几百张也比几千张公开数据集更能反映真实极端情况。5.2 坑二只看平均时延不关注P95和P99时延端侧环境下CPU主频、NPU频率、内存带宽都可能因为温度或任务并发而波动平均时延会掩盖严重的偶发卡顿。我在一个视频检测项目里就遇到过平均时延28ms但P99时延到了110ms导致视频画面周期性掉帧。排查后发现是内存总线被视频编码器抢占NPU的带宽需求周期性得不到满足。解决办法性能验收必须以P95/P99时延功耗曲线为准。如果P99和平均时延差距超过1.5倍就要考虑给关键推理任务设置实时优先级或者用双缓冲异步流水来吸收抖动。5.3 坑三把“生成的流畅度”误当成“任务的聪明度”端侧最容易被低估的效果是“端到端任务指标”。模型在单独测试时输出看起来很顺畅但放到业务闭环里比如配上后处理、纠偏、传感器融合可能反而效果变差。一个反例是小幅调低模型的置信度阈值单独看模型指标确实更“敏感”了但在闭环里带来了大量的误触发实际用户体验反而下降。所以判断“固定芯片上的模型是不是变聪明了”我有一套自己的核心标准任务指标优先于指标比如检测任务就看mAP但更要看低置信度样本下的表现分割任务看mIoU生成任务看带约束条件的评估不只看Perplexity。边缘样本必须专项验证所谓“最聪明”不只是平均效果好而是极端输入下依然不崩。把一个常规模型和一个通过蒸馏QAT优化后的模型放在暗光、遮挡、噪声等边缘样本下对比往往差距最明显。综合体验指标才是验收标准端到端时延、功耗、温度、连续工作时间稳定性各项综合达标的模型才算真正完成了“端侧Scaling Law”的闭环。5.4 坑四一上来就上AutoML/NAS我见到不少团队在固定芯片上一上来就堆NAS神经架构搜索试图自动搜出一个“最优模型”。想法不错但NAS的搜索空间如果不以芯片算子支持和带宽模型为依据搜出来的结构大概率还要人工再调整一轮。更现实的做法是小范围手工搜比如在3~4个候选骨架里选配合每轮profiling结果快速迭代比盲目NAS一两个月要高效得多。5.5 一个容易被忽略的“免费”提智操作输入预处理与后处理优化有时模型本身动不了太多但“输入喂给模型前的处理”和“模型输出后的处理”里藏着大量可以白嫖的智能增量。我在一个OCR项目里就是典型的例子模型识别效果一直上不去后来发现预处理环节的透视校正做得不准文字区域歪斜严重。修正了图像校正算法后同一个模型端到端准确率直接涨了6%。这件事让我意识到固定芯片上的“聪明”是全链路的聪明不只是权重里的聪明。写在最后的实践经验做了这么多端侧AI项目我最深刻的体会是端侧Scaling Law在很大程度上不是模型科学而是“预算感”的科学。你手里那块固定的芯片它的算力、带宽、内存就是项目最初的资产负债表而结构重设计、蒸馏、量化这些手段都是在这个资产负债表内做资产置换——把用不上的计算量换成推理时的准确率把冗余的参数量换成更稠密的智能。如果你正卡在一块跑不动的芯片上我的建议是先别急着换开发板也别急着找更小的模型。把芯片的三条红线实测清楚用profiling日志找出真正的短板然后对症做一次结构手术再用蒸馏把损失补回来最后用QAT把精度钉死。这套流程下来芯片还是那块芯片但模型的表现通常会上一个明显的台阶。下次有人再问“端侧模型能不能变到最聪明”我的回答是能在固定芯片的物理极限内逼近最聪明而那条逼近路径就是你亲手调出来的端侧Scaling Law。