端侧Scaling Law：固定芯片下如何把模型调到最聪明

端侧模型的部署这两年有个很明显的趋势硬件平台越来越固定但模型迭代速度却越来越快。你手里可能是一块RK3588、一颗ESP32或者某个带NPU的SoC芯片买回来那天算力就锁死了可业务方还在不断提新需求——识别精度再高一点、响应再快一点、功耗再低一点。这时候一个很现实的问题就摆在面前在算力、内存、带宽全部固定的前提下模型到底怎么调才能逼近这块芯片的能力上限这就是端侧Scaling Law要回答的事。它和云端那套堆参数、堆数据、堆算力的逻辑完全不是一回事。云端你可以加卡、加机器端侧你只能在一块已经焊死的硅片上做文章。所以端侧Scaling Law研究的不是更大就更好而是在固定预算下模型架构、参数规模、数据配比、量化策略怎么组合才最优。这篇内容我会把端侧Scaling Law的核心逻辑拆开讲结合MoE、Transformer这些架构在端侧的真实表现聊聊固定芯片上把模型调到最聪明的实操思路。适合做端侧AI部署、嵌入式模型优化、以及正在纠结模型选型的同学参考。1. 端侧Scaling Law和云端到底差在哪1.1 云端Scaling Law的底层假设在端侧全部失效先说清楚云端Scaling Law的基本盘。Kaplan那套 scaling law 也好Chinchilla 的最优配比也好它们背后都有一个隐含前提算力是可以线性扩展的。你增加参数量就相应增加训练token再相应增加FLOPs三者同步放大loss就按幂律下降。这个逻辑在数据中心里成立因为GPU可以堆。但端侧完全不是这个游戏规则。端侧的第一个硬约束是内存带宽不是算力。很多芯片标称算力几十TOPS看起来很唬人但实际跑大模型时瓶颈根本不在MAC阵列而在权重从DRAM搬到SRAM的这条路上。你算力再强权重搬不进来也是干等。这就是为什么很多端侧芯片跑小模型飞快一上大模型就拉胯——不是算不动是喂不饱。第二个硬约束是功耗墙。端侧设备要么电池供电要么散热受限。芯片跑满算力的时候功耗可能直接翻三倍温度上来之后降频实际持续算力可能只有峰值的百分之三四十。所以端侧Scaling Law必须把功耗和热设计算进去这是云端根本不用操心的维度。第三个约束是内存容量。云端一张卡80GB显存端侧可能总共就几GB甚至几百KB的SRAM。模型参数、激活值、KV cache全都要塞进这个池子里超了就OOM。所以端侧的scaling不是连续的而是有明确的容量台阶——你能塞进SRAM的模型和塞不进的是两个世界。1.2 端侧Scaling Law的核心变量重新定义既然约束变了那scaling law的自变量也得重新定义。云端看的是参数量N、数据量D、算力C。端侧我建议看这四个变量有效参数量不是总参数而是每次推理实际激活的参数。MoE架构下这两个数字能差一个数量级。内存占用峰值包括权重、激活、KV cache、临时buffer的总和这个才是决定能不能跑起来的关键。单token能耗每生成一个token消耗多少焦耳直接决定续航和发热。端到端延迟从输入到输出的总时间包含预处理、推理、后处理。这四个变量之间是互相拉扯的。你想降延迟可能得减层数但减层数精度就掉你想提精度可能得上MoE但MoE的专家调度又增加内存和延迟。端侧Scaling Law的本质就是在这几个维度里找帕累托最优。我实测过一个对比同样一块RK3588跑一个7B的dense模型和跑一个总参13B但激活只有2B的MoE模型后者精度更高但延迟反而更低因为每次只激活一小部分专家。这就是端侧scaling的独特之处——总参数可以大但激活参数必须小。1.3 固定芯片下的最聪明是个多目标优化问题最聪明这个词在端侧不能简单等同于精度最高。业务场景不同聪明的定义完全不同。语音唤醒场景聪明是低误唤醒率加低延迟图像分类场景聪明是高top-1加低功耗对话场景聪明是回答质量加首token延迟。所以端侧调模型第一步不是选模型而是定义清楚你的优化目标。我一般会画一个四象限横轴是精度纵轴是延迟然后标出功耗约束线。你的目标就是在这条约束线下方找到精度最高的那个点。这个点往往不在最大模型上而在某个中等规模加特定架构的组合上。提示很多团队一上来就想上最大的模型结果发现延迟超标、发热严重最后又灰溜溜换回小模型。先定约束再选模型顺序不能反。2. 固定算力下模型架构怎么选才不浪费2.1 Dense Transformer在端侧的天花板在哪Dense Transformer是端侧最成熟的方案工具链支持最好量化方案最全。但它的scaling曲线在端侧有个明显的拐点。我拿几个不同规模的dense模型在同一块芯片上测过参数量从0.5B到7B精度确实随参数上升但延迟上升得更快。具体来说0.5B到1B这个区间精度提升明显延迟增加可接受1B到3B精度还在涨但边际收益递减延迟开始变得敏感3B以上精度提升很小但延迟和内存占用陡增。这个拐点位置和芯片的内存带宽强相关——带宽越高拐点越靠后。所以dense模型在端侧不是不能大而是大到一定程度就不划算。如果你的芯片内存带宽只有几十GB/s那3B可能就是上限再大就是浪费算力在等数据搬运。2.2 MoE为什么成了端侧Scaling的关键抓手MoE混合专家架构在端侧火起来不是偶然。它的核心思想是总参数可以很大但每次推理只激活其中一小部分专家。这样模型容量上去了但计算量和内存搬运量没同步上去。我举个具体例子。一个总参8B、激活2B的MoE模型和一個2B的dense模型相比计算量差不多但MoE的有效容量大得多因为不同输入会路由到不同专家相当于多个子模型共享一套推理开销。在端侧这种算力固定的场景下这几乎是唯一能免费提升容量的办法。但MoE在端侧也有坑。第一个坑是专家调度开销。路由网络本身要算专家切换要访存如果专家粒度太细调度开销可能吃掉收益。第二个坑是负载均衡。如果大部分token都路由到少数几个专家那其他专家就是白占内存。第三个坑是内存占用。虽然激活参数少但所有专家的权重都得放在内存里待命所以总内存占用还是按总参数算。注意MoE在端侧部署时专家数量不是越多越好。我实测下来4到8个专家是比较甜的点再多调度开销就压不住了。2.3 架构选型的决策表把上面的分析整理成一张表方便你对照自己的场景选架构类型适用场景内存占用延迟表现精度上限部署难度小Dense1B唤醒、关键词识别低极低中低中Dense1-3B图像分类、简单对话中低中高低大Dense3B复杂对话、生成高高高中MoE激活2B多任务、复杂对话高中高高蒸馏小模型特定任务低极低中低选型的核心逻辑是先看内存能不能放下再看延迟能不能接受最后在能放下的里面选精度最高的。顺序不能乱因为内存是硬约束放不下直接出局。3. 参数、数据、量化三者的配比怎么定3.1 端侧不存在参数越多越好这回事云端Chinchilla给出的是参数量和训练token的最优比例大约1:20。但端侧这个比例完全不适用因为端侧的约束不是训练算力而是推理内存和延迟。端侧我建议反过来想先定推理预算再倒推参数量。比如你的芯片有4GB内存可用KV cache和激活要占1GB那权重最多3GB。按INT8量化算就是3B参数按INT4算就是6B参数。这个数字才是你的参数上限超过这个数精度再高也跑不起来。定完参数量再定训练数据量。端侧模型的数据量不需要像云端那么大因为模型容量本身就受限。我一般按参数量的50到100倍来配数据再多就是过拟合或者浪费。关键是数据质量尤其是和端侧场景匹配的数据——你在服务器上训的通用模型直接拿到端侧用效果往往不如用端侧采集的数据微调过的小模型。3.2 量化不是精度杀手配比错了才是量化在端侧是必选项但很多人对量化有误解觉得量化一定掉精度。实际上量化掉不掉精度取决于模型本身有没有冗余。一个训练充分、权重分布集中的模型INT8量化几乎无损一个训练不足、权重分布散乱的模型INT4量化可能直接崩掉。我实测下来的经验是权重量化INT8基本无损INT4在大部分模型上掉点1%以内可以接受。激活量化这个比权重量化敏感得多尤其是Transformer里的attention部分激活值动态范围大INT8都可能掉点。建议激活至少用INT8关键层可以保留FP16。KV cache量化这个对内存节省最明显INT8 KV cache能省一半内存精度影响很小强烈建议开。量化和参数量之间还有个联动关系。你量化到INT4相当于参数量翻倍那就可以上更大的模型。但量化本身有开销反量化要算所以不是量化越狠越好。我一般建议权重INT4、激活INT8、KV cache INT8这个组合在端侧是比较平衡的。3.3 一个实际的配比计算过程假设你的芯片有6GB可用内存目标延迟100ms以内跑一个对话模型。我来算一遍第一步定KV cache。对话场景上下文长度按2048算层数24hidden size 2048KV cache大小约等于 2 × 24 × 2048 × 2048 × 2字节FP16≈ 400MB。量化到INT8就是200MB。第二步定激活和临时buffer。这部分和batch size、序列长度相关保守估计500MB。第三步算权重预算。6GB - 200MB - 500MB ≈ 5.3GB。按INT4量化权重可以到约10B参数按INT8约5B参数。第四步看延迟。10B参数INT4每次推理要搬5GB权重如果内存带宽是50GB/s光搬权重就要100ms加上计算肯定超。所以得降到5B INT8或者3B INT4。第五步定架构。3B这个规模dense可以MoE也可以。如果任务复杂上MoE总参6B激活1.5B内存占用按6B算但计算按1.5B算延迟能压下来。这一套算下来最终方案就清晰了。端侧调模型算账比调参重要。4. 从训练到部署端侧Scaling的完整链路4.1 训练阶段就要考虑端侧约束很多团队的做法是在服务器上正常训练训完了再想办法塞到端侧。这个流程在端侧Scaling下是低效的因为训练时没考虑推理约束训出来的模型往往内存超标或者延迟爆炸。正确的做法是训练时就带上端侧约束。具体来说架构搜索时就把内存和延迟作为约束用NAS神经架构搜索的时候把内存占用和推理延迟加到目标函数里搜出来的架构天然适配端侧。训练时模拟量化用QAT量化感知训练让模型在训练阶段就适应低精度这样部署时量化掉点更少。蒸馏时对齐端侧数据分布用端侧采集的真实数据做蒸馏而不是只用公开数据集。我做过对比同样一个模型训练时带端侧约束的版本部署后精度比不带约束的高3到5个点延迟低20%以上。这个差距在端侧是很可观的。4.2 部署阶段的算子融合与内存复用模型训好了部署阶段还有一波优化空间。端侧推理框架一般都会做算子融合把ConvBNReLU这种组合融成一个算子减少访存。但Transformer架构的融合点和CNN不一样重点是这几个QKV投影融合把query、key、value三个线性层融成一个矩阵乘减少kernel launch开销。Attention融合把softmax和后续的加权求和融在一起避免中间结果写回内存。FFN融合两层线性加激活融成一个block。内存复用也很关键。端侧内存有限推理过程中不同层的激活值可以复用同一块内存因为前一层算完后面就不用了。这个叫内存池化能省不少峰值内存。我实测过一个模型开了内存池化之后峰值内存降了30%。4.3 实测中的意外情况与应对端侧部署最不缺的就是意外。我列几个常见的意外一标称算力跑不满。芯片手册写的是峰值算力实际跑模型可能只有30%。原因是内存带宽瓶颈或者算子没适配。应对方法是先用profiler看瓶颈在哪如果是带宽就量化权重如果是算子就换框架或者手写算子。意外二量化后精度崩了。通常是某些层的激活值动态范围太大。应对方法是做逐层敏感度分析把敏感层保留高精度其他层量化。意外三MoE负载不均。某些专家被频繁调用其他专家闲置。应对方法是加负载均衡loss或者在推理时做专家缓存把热门专家常驻SRAM。意外四发热降频。跑一会儿就降频延迟波动大。应对方法是限制并发或者做动态频率调节在延迟和发热之间找平衡。提示端侧调优一定要有profiler不能靠猜。我见过太多团队凭感觉调调了半天不如profiler看一眼。5. 不同芯片平台上的Scaling实践差异5.1 高算力SoC和低功耗MCU是两套逻辑端侧芯片跨度很大从几百KB内存的MCU到几十GB内存的SoCScaling逻辑完全不同。MCU级别的芯片比如ESP32这种内存就几百KB根本跑不了Transformer。这个级别的Scaling Law其实是怎么在极小内存下塞进一个能用的模型主流做法是TinyML那一套用极小的CNN或者决策树。Transformer在这个级别基本没戏除非是极简的蒸馏版本。SoC级别比如RK3588这种有NPU、有几GB内存才能谈端侧Scaling Law。这个级别的核心矛盾是NPU算力和内存带宽的匹配。NPU算力再高内存喂不上就是浪费。所以SoC上的Scaling重点是让模型的计算密度和芯片的带宽匹配。5.2 NPU和GPU的Scaling策略不一样NPU和GPU的架构差异导致Scaling策略不同。GPU通用性强算子支持全但功耗高NPU专用性强能效高但算子支持有限不支持的算子会fallback到CPU性能暴跌。在NPU上做Scaling第一件事是确认你的算子都被支持。MoE里的路由、gather、scatter这些操作很多NPU支持不好。如果非要上MoE可能得改架构用NPU友好的方式实现路由。GPU上相对自由但功耗是问题。GPU跑大模型的功耗可能直接让设备过热所以GPU上的Scaling更看重能效比而不是绝对性能。5.3 内存带宽才是真正的Scaling瓶颈不管什么芯片端侧Scaling的最终瓶颈几乎都是内存带宽。我测过好几款芯片算力差几倍但跑同一个模型延迟差不多因为都卡在带宽上。所以端侧Scaling的第一性原理是减少内存搬运。具体手段包括量化减少权重体积算子融合减少中间结果写回内存复用减少峰值占用MoE减少激活参数稀疏化跳过零权重这些手段的本质都是让数据少搬几次。谁能把搬运量降下来谁就能在固定芯片上跑更大的模型。6. 把模型调到最聪明的实操清单6.1 调优的优先级顺序端侧调优不能乱调得有优先级。我一般按这个顺序先确认内存放得下放不下一切免谈先量化或者换小模型。再确认延迟可接受延迟超标就减层数或者换MoE。然后提精度在内存和延迟约束内用蒸馏、微调、数据增强提精度。最后抠功耗功耗超标就动态调频或者限制并发。这个顺序不能反因为后面的优化都建立在前面的约束满足之上。6.2 几个容易被忽略的调优点KV cache的管理对话场景KV cache会随上下文增长如果不管理跑久了内存就爆了。应对方法是滑动窗口或者KV cache淘汰策略。首token延迟和后续token延迟要分开看首token延迟取决于prefill阶段后续token延迟取决于decode阶段。两个阶段的瓶颈可能不一样优化手段也不同。batch size不是越大越好端侧batch size大了内存和延迟都上去但吞吐不一定提升因为带宽是瓶颈。我一般建议端侧batch size设为1最多2。温度对性能影响很大芯片温度上来之后降频延迟可能翻倍。所以散热设计要和模型选型一起考虑。6.3 一个完整的调优案例最后分享一个我实际做过的案例。场景是智能音箱上的语音对话芯片是某款带NPU的SoC内存4GB目标延迟200ms以内。初始方案是一个3B的dense模型INT8量化。实测延迟350ms超标。分析发现瓶颈在内存带宽权重搬运占了大部分时间。第一步优化权重降到INT4。延迟降到280ms还是超标但精度掉了0.5个点可接受。第二步优化换MoE架构总参6B激活1.5B。内存占用上去了但计算量和搬运量下来了。延迟降到180ms达标。精度比原来3B dense还高1个点。第三步优化KV cache量化到INT8内存省了200MB给MoE的专家权重腾了空间。第四步优化算子融合把QKV和FFN融合延迟再降15ms。最终方案MoE 6B激活1.5B权重INT4KV cache INT8算子融合。延迟165ms精度比初始方案高内存占用在预算内。这个案例的核心经验是端侧Scaling不是单点优化而是架构、量化、算子、内存管理的组合拳。单改一个地方往往达不到目标得几个手段一起上。注意每次优化后都要重新测精度因为量化、架构改动都可能掉点。我一般会准备一个端侧场景的测试集每次改动都跑一遍确保精度不掉出可接受范围。端侧Scaling Law说到底就是一门在约束下找最优的学问。芯片固定了约束就固定了剩下的就是在这个盒子里把模型调到最聪明。我的经验是别迷信大模型也别迷信某个架构多测、多算账、多看profiler答案自然就出来了。