1. 端侧Scaling Law到底在问什么最近小半年我绝大部分精力都花在一件事上把模型塞进一块焊死的芯片里然后想尽办法让它变得“最聪明”。这里说的端侧Scaling Law不是学术界论文里那种动辄几万亿参数、几千张显卡堆出来的幂律曲线而是我们在RK3588、Jetson Orin Nano、甚至STM32这种固定算力设备上反复碰壁之后总结出来的朴素规律——芯片不能换模型怎么变才能变聪明先说清楚什么叫“固定芯片”。它意味着算力是定死的内存是定死的内存带宽是定死的功耗墙也是定死的。很多时候连NPU支持哪些算子都定死了。我见过太多人一上来就拿着7B、13B的模型往板子上塞结果要么跑不起来要么生成一个token要等两秒体验直接崩掉。这背后的本质是云端的Scaling Law假设算力可以随模型同步增长模型变大的代价可以无限分摊但端侧不是。一旦芯片型号确定你可以调节的只有模型结构、参数规模、量化方式、数据质量、推理策略而不是芯片本身。所以端侧Scaling Law研究的核心命题是在算力、内存、带宽围成的约束空间里怎么分配“预算”才能让最终用户的体感智商最高。这个“最聪明”不是论文里的benchmark分数而是你拿在手上用的时候它回话准不准、快不快、稳不稳、功耗能不能撑住。这个问题的适用范围非常广。做嵌入式TinyML的朋友在MCU上倒腾小模型做边缘AI的在Jetson上部署大模型做手机端推理的在SoC上做加速本质上都在求解同一个约束优化问题。只是约束的严格程度不同。后面我写的这些内容不针对某个特定平台而是把固定芯片下的总体方法论摊开来讲有些规律放在MCU上成立放在手机SoC上也成立。1.1 云端那套“大就是好”的规律在端侧哪里断了先回忆一下云端Scaling Law大致说了什么模型参数量增加、训练数据量增加、算力增加模型的loss会按照近似幂律下降模型“越来越聪明”。这个规律在算力可以无限扩张的前提下当然没毛病。可一旦落到固定芯片上首先断掉的就是“算力随模型增长”这个隐含假设。芯片的算力就像一栋楼的承重墙楼面积不能超出承重墙能支撑的极限。云端的做法是不断把楼盖高同时加粗承重墙端侧则是承重墙已经浇筑完毕你只能在楼内做装修——调整户型结构、减少不必要的走廊、把杂物间改成储物墙。参数量一涨内存占用跟着涨单token推理延迟跟着涨功耗也跟着涨。最致命的是内存带宽往往比算力更先到瓶颈后面我会专门算这笔账。另一个被端侧打破的假设是“数据可以无限扩充”。云端大模型训练时可以灌入几十万亿token效果不够就继续灌但端侧小模型的容量有限甚至可以说“容量就像一个小仓库乱堆东西只会让你找不到需要的物品”。数据塞多了、塞乱了模型反而会学到一堆噪声这在端侧小模型上体现得尤其明显。所以端侧Scaling Law里数据质量优先级远高于数据数量。1.2 “聪明”在端侧怎么量化如果把“聪明”作为优化目标先得定义度量方式。云端可以看loss、看MMLU、看HumanEval一套benchmark打天下端侧不行。同一个模型在A芯片上可能跑得很流畅在B芯片上因为带宽低、NPU算子支持不全速度直接掉一半。因此端侧评估“聪明”必须是一个多目标函数至少要包含这四项质量分在特定任务上的准确率、生成内容的可用度这是传统意义上的智能水平速度分首token时延、生成token/s直接决定用户是否愿意用资源分内存峰值、Flash占用能不能在目标芯片上落盘运行功耗分平均功耗、峰值功耗、散热表现对应设备的续航与外壳温度。举个很直观的例子同一个1B模型FP16版本在内存足够的芯片上能跑但在8GB内存的板子上就得掂量一下显存余量INT8量化版本速度能提升近一倍质量几乎不掉INT4量化版本速度更快但一旦任务的专有名词多、逻辑复杂生成内容就可能开始胡言乱语。这些不是理论推演是我在不同板子上实测过的曲线。后面我会给出一张量化决策表直接照着选就行。所以在端侧说“模型变聪明”我更愿意把它理解为在质量不崩、资源不超限、体验不卡顿的前提下让模型在目标场景下的知识密度和推理能力最大化。这个“知识密度”概念很关键它指的是一份预算每MB模型参数、每MB内存占用能够承载多少有效能力。2. 固定芯片上影响“聪明”的三个旋钮2.1 参数规模不是越大越好而是刚好够用端侧模型选参数规模最忌讳的是“参照云端逻辑”。我在RK3588上试过从0.5B一路升到3B结论非常清晰0.5B模型响应极快但知识面窄1.5B模型在综合能力上明显提升速度还能接受3B模型质量最好但生成速度掉到不可用的边缘而且内存占用接近板子极限开着浏览器再跑模型就容易OOM。这不是说3B模型不好而是说在这块芯片上3B的边际收益已经被边际成本吃掉了。端侧模型选型应该反过来思考先定芯片能稳定承载的延迟和内存上限再倒推参数规模可接受的范围然后在范围内选质量最高的模型家族。比如Orin Nano这种8GB内存、68GB/s带宽的平台对应的是“7B以内量化到INT4还能跑”的甜点区RK3588这种6TOPS INT8算力、LPDDR4带宽的平台就更适合1B到3B之间。除了参数总量架构选择也直接影响“聪明”和“跑得动”的平衡。同样是3B规模稠密模型和MoE模型的访存行为完全不同。MoE每次推理只激活部分专家理论计算量更低但所有专家参数都要驻留内存对带宽的消耗未必小。这引出一个反直觉的经验在端侧有时一个结构更稀疏、激活更高效的模型反而比一个参数更多但激活路径长的模型更适合固定芯片。2.2 数据质量小模型的“知识密度”比大模型更敏感很多人以为端侧模型就是“把大模型缩小”所以只要会剪枝、量化、蒸馏就够了。但我在实践中发现数据质量对端侧小模型的影响可能比网络结构设计还大。原因是什么呢大模型参数量大、层数多本质上是一个超大容量的记忆系统即使训练数据里有大量重复、噪声它也能靠规模硬扛从海量内容中统计出正确答案小模型容量有限每一个参数都在“刀刃上”低质量数据所占的比例越高模型记住正确规律的空间就越少。举个我踩过的坑曾用一批网络爬取数据微调一个1B模型数据量很大但质量参差不齐。评测时发现模型在某些常识问题上反而变笨了回答开始出现张冠李戴。后来把这批数据做了一遍清洗去掉低质量重复页、AI生成痕迹明显的碎片、无意义的口水话只保留知识密度高的部分重新微调效果立刻回到正常水平甚至更好。所以端侧Scaling Law里有一条非常重要的经验在算力固定的区域模型的聪明程度更多取决于数据管线而不是参数堆叠。训练数据要追求“高知识密度”——单位字节里包含多少有用的信息。实践中我会做这么几件事全量去重包括语义去重、过滤低质量网页内容、用强模型合成针对目标任务的指令数据、按任务类别做配比平衡。这套流程做下来0.5B模型在某些垂直场景下的表现甚至能超过不做数据处理时的1.5B模型。2.3 推理策略算力不够时用“手段”补“能力”第三个旋钮很多人会忽略。固定芯片上模型权重是固定的但“模型怎么被使用”却是可以优化的。我把这称为“推理侧Scaling Law”在不改权重的前提下仅仅通过调整上下文、检索、解码头策略就能显著提升模型在具体任务上的表现。最简单也是最常见的手段是RAG检索增强。给一个只有0.5B的小模型挂上本地知识库在固定场景下的回答准确率能上升一大截。原理上讲小模型参数里存不了太多事实性知识RAG把这些知识放到外部存储器里推理时动态取回来相当于扩展了模型的有效记忆容量。对于固定芯片来说这个路线几乎零部署成本却能让小模型“变聪明”。另一个手段是投机采样。用一个小草稿模型快速生成候选token再由目标模型验证。在带宽受限的芯片上这种方案能把生成速度提升两倍甚至更多。再比如说上下文窗口的裁剪与缓存固定芯片的内存有限KV Cache会随上下文长度线性增长。在不牺牲关键信息的前提下设置合理的上下文长度、开启KV Cache量化、采用流式处理都能变相给模型腾出更多计算资源。这三个旋钮不是孤立的。最理想的状态是参数规模选在芯片甜点区数据管线做到高知识密度推理策略充分榨干芯片的剩余性能。三者合在一起才是“固定芯片上模型最聪明”的完整答案。3. 实测总结端侧Scaling Law的几条规律3.1 规律一内存带宽才是端侧智能的天花板之前说过很多次“芯片算力是瓶颈”但真正做端侧部署之后你会发现解码阶段decode的最大瓶颈往往是内存带宽而不是TOPS算力。原因在于模型生成每个token时都要把模型权重从头到尾读一遍这个过程是访存密集型的几乎不需要太多矩阵乘算力。解码速度的物理上限直接取决于带宽和模型驻留大小最大生成速度token/s ≈ 内存带宽GB/s / 模型驻留内存GB举一个具体例子1B参数模型INT8量化后约1GB驻留内存如果芯片实测带宽只有20GB/s那么理论最大解码速度就是20 token/s左右。如果INT4量化后驻留内存降到0.55GB理论上限就能提到36 token/s。很多芯片标称算力很高但解码速度就是上不去原因就在这——算力在解码阶段根本吃不满带宽先拉满了。所以在端侧选模型时别只盯着参数和精度先问三个问题这块芯片实测带宽多少模型量化后驻留内存多少我需要的最低生成速度是多少这三个数一对齐模型规模的可行范围就出来了。RK3588属于LPDDR4带宽标称值看着可以实测持续带宽会打折Jetson Orin Nano用的是LPDDR5带宽表现好不少一些新款手机SoC带宽更高能跑更大的模型。3.2 规律二量化存在甜点区越到后面收益越缩水端侧量化几乎是必选项但它不是什么免费的午餐而是在“速度”和“智损”之间不断试探边界的过程。我的实测经验大致如下量化方案模型规模速度提升质量损失适用场景FP160.5B~1B基线无内存宽裕、追求最高质量INT81B~3B提升约80%~100%几乎无损可忽略大多数端侧任务INT4/AWQ/GPTQ3B~7B再提升约60%有损失视敏感层而定内存吃紧、模型偏大INT4直接量化0.5B以下提升但有限损失明显不建议小模型扛不住最反直觉的一点是模型规模越小量化带来的相对损失越难接受。一个0.5B的模型本身“聪明度”就紧巴巴的INT4量化后可能直接跌破可用线而7B模型本身冗余多INT4量化后虽然会变笨一点但综合能力仍然远强于1B模型。所以量化决策不是看“这个格式有多流行”而是看“模型本身的冗余度有多少”。如果你发现量化后质量崩得厉害不要急着放弃量化先做两件事第一把高敏感层挑出来保持FP16第二用一份和真实部署场景一致的校准数据重新做量化。这招能救回大部分损失。3.3 规律三小模型强数据管线胜过盲放大参数量这条规律是我在多个项目里反复验证过的。固定芯片上模型参数从0.5B涨到1.5B速度可能下降一倍质量提升可能只有零点几个百分点但如果把0.5B模型的训练数据换成一版高质量、高密度、目标场景对齐的数据质量提升往往比参数翻倍还明显。道理也不复杂端侧模型的瓶颈参数是“容量×带宽×数据质量”共同决定的。参数翻倍带来的是容量翻倍但带宽和内存预算也被翻倍的权重吃掉了推理速度会下降。数据质量提升则不加任何推理成本纯粹提高了每个参数的利用效率。所以在优化顺序上我始终建议先做数据优化再做蒸馏最后才是考虑要不要换更大的模型。从工程角度看这套逻辑等于把“Scaling Law”从云端搬到端侧后原来的横轴从“参数规模”变成了“数据有效密度”和“推理效率”。谁在这两条轴上做得好谁就能用同样的芯片拿到更好的模型体验。4. 给固定芯片找“最聪明配置”的实操流程4.1 第一步对芯片做一次“能力审计”很多人部署模型翻车不是模型不行而是根本不了解自己在哪块芯片上干活。能力审计是固定芯片Scaling Law的第一步也是后面所有选择的前提。审计清单至少要包含以下几项算力CPU平台、GPU/NPU可能提供的TOPS算力、支持的数据精度内存大小、类型、实测带宽务必实测理论值经常虚标、共享内存还是独立显存算子支持目标NPU或GPU支持的算子列表某些复杂算子或高版本算子可能不支持功耗与散热持续推理时的功耗墙超过会降频部署框架芯片厂商SDK能力比如TensorRT、ONNX Runtime、MNN、TFLite、llama.cpp的适配程度。我习惯把常用芯片整理成一张选型对照表每次接手新项目更快定位合理范围芯片平台典型内存实测带宽参考更适合的模型规模主要限制STM32H7等MCUKB到MB级很低参数几MBTinyML模型Flash、RAM、带宽RK35888GB~32GB约20~40GB/s0.5B~3BINT8/INT4带宽、算子支持Jetson Orin Nano8GB约68GB/s3B~8BINT4显存、功耗手机SoC6GB~16GB50~100GB/s1B~7BINT4/AWQ散热、带宽这张表的数字是大致参考不同批次、不同主板设计、不同散热条件都会影响实际表现所以做一遍实测审计永远值得。4.2 第二步定义“最聪明”的目标函数你追求的“聪明”是什么这个问题如果不定义清楚后面的优化就会变成无头苍蝇。我通常会构建一个量化评分函数综合评分 质量分权重×任务质量分 速度分权重×速度达标率 - 内存超限惩罚 - 功耗超限惩罚举例来说一个实时语音交互项目首token延迟权重极高内存次之质量分占比反而可以放低一个离线知识问答项目质量分权重最高速度和功耗可以放宽。先把目标函数定下来后面做配置对比时一目了然不然两个方案各有优劣很难拍板。4.3 第三步系统性搜索最优配置而不是“碰运气调参”搞清楚芯片家底和目标函数之后最优配置搜索就可以按固定流程做了。我给团队定了一套四阶段流程每次迭代只改一个变量避免变量混杂导致说不清是哪个操作带来的收益。第一阶段是基线选择。选2~3个同量级、不同架构的候选模型家族在目标芯片上做最简单的FP16/INT8部署记录质量和速度基线淘汰明显不合适的。第二阶段是蒸馏与剪枝。如果候选模型太大先在服务端用更大的教师模型蒸馏出同架构小模型再评估效果。剪枝在这个阶段也要做敏感度分析找出哪些层可以剪掉而不掉点。第三阶段是量化扫描。从INT8开始逐个尝试不同的量化方法和精度档位同时用真实场景校准数据做量化校准记录每档的质量和速度变化。第四阶段是推理层优化。调整框架后端、并行线程、缓存策略、投机采样、KV Cache量化等把芯片的剩余性能尽量榨干。每阶段产出一张对比表最后用目标函数综合打分选出最优解。这套流程听起来繁琐但实际执行下来是最高效的因为每一步都有数据支撑不会出现“凭感觉觉得这个方案效果好”的情况。4.4 第四步原型验证与持续迭代固定芯片上的“最聪明”不是一次搜索就能定死的。模型部署上线后真实使用场景的数据分布和测试集往往有差距需要做持续的数据回流和模型更新。好消息是因为你已经把数据管线建起来了后续迭代模型权重、调整量化配置都可以在流水线上快速完成。我特别想提醒的是模型迭代时要做好新旧版本A/B对比。用同一套评测集、同一套用户反馈采集机制别拿“感觉变聪明了”当结论。固定芯片上的每次模型更新都应该有客观数据进行支撑这样模型才会越变越可靠。5. 常见问题与排查技巧实录5.1 生成速度远低于理论值怎么办很多人部署完模型发现速度只有理论值的一半甚至更低先别怪芯片。按这个顺序排查确认是否真的用上了硬件加速后端而不是在跑CPU回退路径检查线程数和内存分配是否优化到位很多框架默认配置偏保守用工具实测内存带宽确认理论带宽是否因主板设计或散热降频缩水对比prefill阶段和解码阶段耗时找出耗时大头检查上下文长度和KV Cache缓存命中情况过长的上下文会显著拖慢速度。实际项目里我遇到最多的情况是NPU或GPU的算子支持不全某个不重要的小算子触发了大量数据拷贝回退导致整个推理链路被拖慢。用一个profiler工具看一下算子耗时分布问题立刻显形。5.2 量化后模型“变笨”明显怎么救如果量化后质量下降到你无法接受先做混合精度找出敏感层通常是前几层和最后几层把这些层保留为FP16其余层量化。这个操作能挽回大多数质量损失。其次是换量化方法从简单的RTN换成AWQ或GPTQ这类基于校准数据的量化方案。再有就是检查校准数据集它必须和真实部署场景保持一致数据分布不要拿测试集当校准集那是作弊而且会让模型在真实场景下表现更差。还要多说一句小模型的鲁棒性远低于大模型。0.5B的模型少量低质量训练样本就可能带来明显偏置这在安全层面非常危险。之前接触过“模型中毒攻击”的研究大意是攻击者在训练数据里掺入少量精心构造的样本就能让模型在特定输入下产生错误输出。对端侧小模型来说这个影响会放大因为参数少、冗余小几乎每条数据都有较高权重。所以数据清洗这一步既是质量线也是安全线。5.3 内存算着够用一跑就OOM这种情况经常出在KV Cache和中间激活上。很多人的内存估算只算了模型权重忘了上下文越长KV Cache占用越大。粗略估算公式是KV Cache大小 ≈ 层数 × 注意力头数 × 头维度 × 上下文长度 × 2 × 字节数举个例子一个8层模型、8个注意力头、头维度64上下文长度4096FP16存储单条序列的KV Cache大约是8×8×64×4096×2×2字节算下来接近268MB。一个用户开多轮对话缓存累积起来非常可观。对策也简单限制最大上下文长度、启用KV Cache量化、实现流式加载历史消息、必要时使用外部记忆或RAG来压缩上下文。注意别为了省内存把上下文压得太狠否则模型指令跟随能力会下降得不偿失。5.4 芯片NPU不干活算子一直回退CPU这个问题在国产边缘NPU上尤其常见。很多NPU的算子库覆盖有限模型里一旦出现不支持的算子整段推理就会回退到CPU。常见触发点包括某些归一化层的复杂实现、自定义激活函数、高版本的Attention结构。解决思路有三个方向第一改动模型结构换成算子库支持的等价实现比如用GELU近似替换、把LayerNorm结构重写为标准形式第二做算子融合把多次小算子拼成一次大算子调用减少数据搬运第三如果原有的Attention实现开销太大可以尝试线性注意力或窗口注意力变体。每改动一步都要重新跑评测集确保没有引入格式上的意外错误。5.5 一套通用的排查顺序最后分享一个自己长期在用的排查顺序速度不对先查带宽和算子里耗内存不对先查KV Cache和框架缓存质量不对先查数据和量化整体不对就回退到最小可运行配置逐步加回功能。这套思路帮我省下大量排查时间也推荐给所有做固定芯片模型部署的朋友。干了这段时间的端侧模型优化我最大的感受是端侧Scaling Law本质上不是在讲模型有多大而是在讲约束下如何最合理地花钱。每一份算力、每一兆内存、每一瓦功耗都是预算模型“变聪明”靠的是把这些预算花在刀刃上。固定的芯片不可怕可怕的是不懂权衡一味地堆积参数或盲目追求量化精度。先用能力审计和数据管线把地基打好再在参数、量化、推理策略之间找那个综合最优解你手里的芯片就能发挥出比纸面配置高得多的真实水平。