设备里的模型是怎么装进去的？压缩部署

手机断网也能听懂语音指令，音箱不开云服务也能响应唤醒词，相册里的照片在本地就能被搜出来——这些能力都依赖一个事实：AI 模型就装在设备里。可公开报道里的大模型动辄几百上千 GB，一台手机的总存储不过这个量级，模型是怎么被塞进去的？答案是压缩与部署的一整套流程：先瘦身、再减员、最后重新编排上岗。这篇按顺序拆解这条链路，看完就知道端侧模型牺牲了什么、换来了什么；装进设备的模型与云端的模型各干什么活，本地与云端体验一篇对比过，这里先管「怎么装」。

先瘦身：量化是把数变短

模型里存着海量参数，每个参数在原始训练时用高精度数字记录，占的存储与算力都多。量化做的事很直接：把这些长数字换成短数字。原来用 16 位存储的参数，压成 8 位，体积直接减半；压到 4 位，再减一半。手机里跑的端侧模型，多数在 4 到 8 位之间取平衡。代价是精度损失：数字变短，表达能力随之打折，压得太狠，模型回答的质量明显下滑，这是量化的第一笔账。好在精度损失并非线性摊在所有任务上，常见的分类、识别类任务对位数不敏感，复杂推理才容易露怯。不同精度档位之间怎么权衡、各档的适用场景，量化阶梯一篇列过对照，压缩端侧模型时选档的逻辑与那是同一套。

再减员：剪枝与蒸馏两条路

量化之外还有两路减法。剪枝的思路是模型里有大量参数贡献很小，把这些「不干活或少干活」的连接裁掉，模型变小，能力大体保住；裁掉之后通常还要微调一轮，把剪完的口子弥合。剪枝怎么判断哪些该裁、裁到什么程度，剪枝方法一篇专门讲过。蒸馏走另一条路：先留着大模型当老师，训练一个小模型去模仿老师的输出行为，学生不必复制老师的全部参数，只学它在具体任务上的判断方式，最后交出的是一个小而够用的模型。蒸馏与完整训练的差别、什么样的任务适合出学生模型，完整训练与蒸馏一篇有对照。三路手段常组合使用：先蒸馏出小模型，再量化压缩，最后剪掉冗余，体积从几十 GB 一路压到几百 MB 甚至更小。

装进去之后：端侧运行时的编排

压缩完成只是拿到一个合格的模型文件，要真正跑起来还有一段编排。第一步是格式转换：把模型转成设备推理框架认的格式，不同系统各有各的格式族，转换时还会做图优化——合并算子、调整执行顺序，把推理过程理顺。第二步是内存规划：模型参数加载进内存，运行时的中间结果也要占地方，内存预算超了就跑不起来，这也是为什么内存容量直接决定一台设备能装多大的模型。第三步是硬件调度：把神经网络运算尽量派给 NPU，剩下的杂活分给 CPU 与 GPU，调度得好，同样电量能多跑一截。三步走完，模型才算在设备里安了家。

压缩的代价与端云分工

把账算全，压缩不是免费的。能力上，被压缩的模型在复杂推理、长文本、罕见知识上明显弱于原版，端侧跑的普遍是「够用就好」的任务：唤醒词识别、常用指令理解、照片分类这类高频轻量的活。更新上，模型改进了要重新打包分发，设备端更新节奏比云端慢。安全上，模型装在用户手里，保护与管控都比云端复杂。所以实际产品的通用做法是分工：高频、低延迟、涉及隐私的任务放端侧，重活难活传给云端的大模型协同完成。日常验证分工的存在很简单：断网试试设备的 AI 功能，还在的端侧负责，失效的就是要上云的部分；让豆包把一款设备公开的 AI 功能清单按端侧与云端归类，再用 Kimi 对照本篇的取舍逻辑逐项检查归类的理由，端侧模型的门道就完整了。

端侧模型压缩速查

• 量化：把参数精度从 16 位压到 8 位或 4 位，体积骤减精度有损
• 剪枝裁掉低贡献连接，蒸馏让小模型学大模型的行为
• 三路手段常组合：先蒸馏、再量化、后剪枝
• 部署三步：格式转换、内存规划、NPU 调度
• 端云分工：轻活低延迟在端侧，重活难活上云端

关于端侧模型的常见疑问

• 压缩后的模型和原版差距有多大？：看任务。日常的分类、识别、唤醒词这类任务，压缩后的模型与原版表现接近，多数用户感知不到差别；复杂推理、长上下文、专业问答是差距集中区，压缩比例越大差距越明显。所以厂商展示端侧能力时，选的通常是前者。
• 模型装进设备后还能变聪明吗？：能，走更新。模型文件随系统或应用更新替换新版本，压缩部署的流程重走一遍。但更新的间隔以月计，不像云端模型可以随训练随时迭代，这是端侧的固有节奏，也是端云协同存在的原因之一。
• 想判断一台设备的 AI 功能是不是真在本地跑，怎么办？：两个土办法：断网测试，功能照常的八成在端侧；看设置里有没有「本地处理」相关开关与占用说明。让 DeepSeek 把产品页的功能说明逐条过一遍，标注哪些写明了本地执行，比逐项手动翻快得多。