端侧模型的部署，这两年有个很明显的趋势：硬件平台越来越固定，但模型迭代速度却越来越快。你手里可能是一块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 架构选型的决策表

把上面的分析整理成一张表，方便你对照自己的场景选：

选型的核心逻辑是：先看内存能不能放下，再看延迟能不能接受，最后在能放下的里面选精度最高的。顺序不能乱，因为内存是硬约束，放不下直接出局。

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算，层数24，hidden size 2048，KV 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 部署阶段的算子融合与内存复用

模型训好了，部署阶段还有一波优化空间。端侧推理框架一般都会做算子融合，把Conv+BN+ReLU这种组合融成一个算子，减少访存。但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内存的SoC，Scaling逻辑完全不同。

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 调优的优先级顺序

端侧调优不能乱调，得有优先级。我一般按这个顺序：

1. 先确认内存放得下：放不下一切免谈，先量化或者换小模型。
2. 再确认延迟可接受：延迟超标就减层数或者换MoE。
3. 然后提精度：在内存和延迟约束内，用蒸馏、微调、数据增强提精度。
4. 最后抠功耗：功耗超标就动态调频或者限制并发。

这个顺序不能反，因为后面的优化都建立在前面的约束满足之上。

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，权重INT4，KV cache INT8，算子融合。延迟165ms，精度比初始方案高，内存占用在预算内。

这个案例的核心经验是：端侧Scaling不是单点优化，而是架构、量化、算子、内存管理的组合拳。单改一个地方往往达不到目标，得几个手段一起上。

注意：每次优化后都要重新测精度，因为量化、架构改动都可能掉点。我一般会准备一个端侧场景的测试集，每次改动都跑一遍，确保精度不掉出可接受范围。

端侧Scaling Law说到底就是一门在约束下找最优的学问。芯片固定了，约束就固定了，剩下的就是在这个盒子里把模型调到最聪明。我的经验是，别迷信大模型，也别迷信某个架构，多测、多算账、多看profiler，答案自然就出来了。