DeepSeek INT4量化实战：端侧部署与推理优化指南

这两年轻量化模型的热度一直没降，但很多做端侧部署的朋友应该都有同感：模型结构越改越轻，真落到手机、工控板、边缘盒子上，还是被显存、带宽和功耗三道坎卡死。DeepSeek系列开放了从大规模稀疏MoE到蒸馏版的一整条技术路线之后，INT4量化这类低比特方案就成为了把大模型搬进小设备的临门一脚。我最近基于DeepSeek系列模型完整做了一轮INT4量化优化和端侧推理适配，这篇文章就把里面的思路彻底拆开讲：INT4量化为什么能打、关键实现怎么做、实操中有哪些必须避开的坑，以及它为什么是2026年端侧算力释放的核心支点。做端侧部署的开发者、做模型压缩的研究同学，都能从里面找到可以直接复用的经验。

1. 轻量化模型卡住的“最后一公里”到底在哪

1.1 算力过剩，内存带宽却严重不足

先说一个很多人容易搞错的前提：端侧跑不动大模型，主要瓶颈往往不是“算力不够”，而是“数据搬不动”。GPU和NPU的TOPS数字这些年翻得很快，但片上内存的带宽增长远远跟不上。

我随手列一组常见数字你就明白了：一个7B参数模型，FP16权重大约是14GB；放到手机这种设备上，可用内存通常就6GB到12GB，光权重就装不下。即便用8GB内存硬扛，每次生成一个字要把全部权重从DRAM搬到计算单元，按每秒10GB左右的带宽估算，光搬运时间就要1秒上下，交互体验完全不可接受。

INT4量化把权重从FP16压到4bit，内存占用直接砍到四分之一，7B模型大概只有4GB。权重变小之后，搬运成本同步下降，推理延迟、耗电、发热全部跟着改善。这就是为什么“量化”被当成端侧模型的必选项，而不是可选项。

我在实测里还发现一个比较反直觉的现象：当模型降到INT4以后，解码速度提升最明显的反而不是GPU，而是CPU或者普通的NPU。因为这类设备本来就带宽紧张，权重一旦瘦下来，之前被带宽压得死死的transformer解码环节能立刻提速，200%的加速比都属于保守估计。

1.2 DeepSeek模型让低比特量化重新成为焦点

DeepSeek系列模型被拿出来做INT4量化，有它特殊的背景。大规模MoE版本总参数量很大，但每次推理只激活一部分专家，理论计算量不高，难的是把全部专家权重放进显存。INT4能让671B级别的稀疏模型压缩到400GB以内，多卡部署压力小很多。更常见的是蒸馏出来的7B、32B级别小模型，INT4量化之后可以直接跑在消费级显卡甚至高端手机上，这正好踩中了2026年前后端侧大模型应用的需求节奏。

这个背景决定了我和团队在选型时的思路：不是从零训练一个小模型，而是在成熟开源权重基础上做“低比特改造”。训练阶段我们控制不了，能控制的只有量化算法、校准数据、分组参数和推理框架这四个环节。后面的所有技术细节，基本都围绕这四个环节展开。

2. INT4量化的核心思路与原理拆解

2.1 量化公式：把连续浮点空间映射到离散整数空间

先花三分钟把量化本身的数学逻辑理清楚。一个普通权重张量里每个元素都是FP16浮点数，范围大、密度高。INT4量化就是把这些浮点数值划分到16个整数档位上，存储的时候只记档位编号，要用的时候再映射回浮点近似值。

最常用的对称量化公式可以写成：

r ≈ S × q

其中r是原始浮点值，q是量化后的整数，S是一个非常关键的缩放因子，由权重范围决定。

实际工程里，很多INT4方案走的是非对称量化，多一个零点偏置Z，公式变成：

r ≈ S × (q - Z)

非对称的好处是能更精准地覆盖非对称分布的数据，INT4总共才16个刻度，每个刻度都值钱，多一个偏置项往往能让精度好看不少。代价是存储和计算时多一个零点要处理，但这点开销在端侧完全可接受。

我用一个生活化的类比解释：量化就像把一整条连续的温度刻度只保留16个测量点，测量者根据气温范围决定这些点怎么摆放。如果春夏秋冬都覆盖，误差就大；如果只测夏天，0到40度里放16个点，精度就高多了。量化的艺术，就是给每个张量找到“只测夏天”的那个最优范围。

2.2 敏感层识别：为什么有些层不能直接压4bit

很多人第一次做INT4量化，上来就把所有层全部压到4bit，结果模型直接变成“乱码生成器”。这不是量化没用，而是没搞懂层与层之间的敏感度差异。

我总结下来的经验是：靠近输入输出的Embedding层和LM Head层，绝对不能量化到INT4。这两层的权重直接决定了模型的词汇表映射和最终输出分布，微小扰动会被后续层放大。实操中我通常把它们保留在FP16，损失的内存极少，但下游任务的精度能挽回一大截。

除了Embedding，还有两类层要格外小心。一类是跟注意力计算直接相关的Q/K/V投影层，尤其是对长文本、复杂推理任务敏感；另一类是MoE模型里的路由层或者说Gate层，它的输出决定激活哪些专家，一旦量化误差改变了路由决策，整个模型的行为会发生非线性漂移，几乎没法靠校准数据拉回来。

怎么找出这些敏感层？不需要纯靠手试。用一小批校准数据跑一遍原始模型，记录每层输出激活的分布特征，那些激活值动态范围特别大、或者存在明显离群值的层，就是重点保护对象。我自己的习惯是先跑一版“全INT4”作为底线，再看Perplexity升了多少，接着逐层回退到FP16或INT8，精度恢复速度最快的那几层就是敏感层，直接锁定。

2.3 分组量化与校准集：决定INT4成败的两个隐藏开关

权重张量里不同位置的值分布差异很大，如果整个张量共享同一个缩放因子S，那么大部分刻度都被浪费在少数离群值上。所以现代INT4量化几乎都采用分组量化，最常见的做法是把权重按128个元素为一组，每组独立计算自己的缩放因子和零点。

为什么偏偏是128？这个数字不是拍脑袋定的。128个元素按INT4存储是64字节，和常见缓存行和内存对齐机制能较好配合；同时分组粒度足够细，能照顾到局部分布特征，又不会因为粒度太细让缩放因子本身占用过多额外空间。实战里把group size从128改成64，精度通常能提升0.1到0.3个点Perplexity，但缩放因子存储翻倍，整体模型体积增加大约8%到10%。怎么选，就看你对存储更敏感还是对精度更敏感。

校准集的权重也常被低估。我见过有人顺手从网上抓了500条语料当校准集，结果模型推理能力明显打折。校准数据的核心要求是：必须贴近这个模型的真实使用场景。如果你要部署的是代码生成模型，校准数据就应该是代码；如果是对话模型，就应该是多轮对话样本。校准集不需要标签，但要足够多样化，覆盖常见指令分布。我用的经验值是500到1024条，候选样本先用模型跑一遍计算困惑度，按困惑度均匀分层抽样，比随机抽取要稳得多。

2.4 GPTQ思路与AWQ思路的取舍：不是非此即彼

INT4量化算法目前主流有两派思路。GPTQ派别走的是“最优脑量化”路线，核心思想是根据权重对损失函数的二阶影响来逐个调整量化舍入方向，利用Hessian矩阵信息，让量化误差在全局范围相互抵消一部分。它的效果好，但校准过程耗时较长，而且对校准集比较敏感。

AWQ派别思路不同，它意识到权重本身的误差不重要，重要的是权重对激活分布的敏感性。AWQ不直接改权重值，而是通过观察激活的幅度，给重要的权重通道乘上一个缩放系数来“保护”，然后在推理时把缩放系数融合进相邻层，几乎不增加额外计算。

我个人的选型建议很直接：如果推理框架支持得好、校准集资源充足、允许离线量化时间拉长，优先走GPTQ路线，精度上限更高；如果模型要频繁更新、量化次数多、或者你有比较强的激活分布洞察，AWQ更省事稳健。DeepSeek系列模型两种算法都试过之后，我的结论是：在7B蒸馏模型上两者差距不大，在32B级别以上AWQ略稳；到了MoE大模型上，GPTQ对专家层校准容易过拟合，AWQ对稀疏结构的适配度反而更好。

3. DeepSeek INT4量化实操全记录

3.1 工具链选型：先想清楚目标平台再动手

INT4量化不是“量化完就结束”，后面还要接推理框架。不同的端侧推理框架对量化格式的支持差异极大，所以我强烈建议：先确定部署平台和推理框架，再回头决定量化算法和导出格式。顺序反了，很容易出现“量化一时爽，导入火葬场”的局面。

选型上可以按平台大致分三类。CPU平台优先考虑GGUF格式系列，它把模型权重和量化参数打包成一个独立文件，支持从2bit到8bit多种量化等级，配合内存映射加载，大模型在内存较小的机器上也能跑。GPU平台优先看ExLlama系和TensorRT-LLM系，前者的GPTQ支持非常成熟，后者在NVIDIA设备上有专门的INT4优化算子。NPU平台最麻烦，目前很多端侧NPU对INT4的支持还在逐步完善，实际做的时候要确认算子是否走的是真实INT4计算还是先反量化成FP16再算。

我这次的目标平台是手机端的高性能NPU和边缘ARM CPU双平台，所以量化输出选的是GGUF格式的INT4变体，同时保留一份原始的FP16权重用于对照。这个决定省下了大量重复对齐时间，你们做之前也一定先建好这个意识。

3.2 从FP16权重到INT4模型的完整流程

整个量化可以梳理成六个步骤，每一步都有明确的输入输出，照着做基本不会翻车。

第一步，获取原始权重。推荐直接使用FP16或BF16精度的原始开源权重，不要拿已经量化过的模型再往低比特压，误差会层层叠加。基座权重下载之后先加载跑一遍，确认权重文件完整、生成基础文本正常，这个动作很多人跳过，但我建议别省，能过滤掉一堆下载损坏和转换出错的问题。

第二步，准备校准集。这里使用的是从对应场景语料中抽样的一段通用指令数据集，涵盖摘要、代码、数学推理、日常对话四类，共800条，按困惑度分层抽样。校准集转成模型统一的文本格式，每条截断到1024个token以内，太长会把校准时间拖到不可接受。

第三步，执行量化。核心命令的逻辑是这样的：先把HuggingFace格式的模型导入到量化工具链并转换成GGUF格式；然后执行量化命令，指定目标量化类型为INT4的某个变体，同时设置分组大小。完整命令里还带了一个参数控制token数量，用于校准阶段前向传播的样本规模。

第四步，量化之后的校验。这一步我把它当成“及格线测试”：先用一份模拟考试题检查基础能力是否保留，我的经验值是对比原始FP16模型和INT4模型在相同提示词下的Perplexity变化，增量控制在0.5以内才算通过；超过1.0，说明某个环节出了问题，往下排查。

第五步，接入推理端。把量化后的GGUF模型文件放到端侧推理框架里加载，第一次运行时不追求性能，先确认输出和桌面端一致。我这一轮在手机上用同一组提示词跑十轮，逐字对齐，发现有一处轻微差异，最后定位到是端侧框架的采样种子实现不同，属于正常现象，不是量化问题。

第六步，性能调优和回归测试。这一步就是反复迭代的过程了，后面单独讲。

3.3 推理速度的关键优化点：线程、缓存和算子公司

INT4模型上线端侧之后，实际性能能不能起飞，主要看三个地方。

第一个是线程与服务绑核。手机CPU一般是大核小核混合架构，推理任务要绑到大核上跑，同时预留1到2个核做系统调度，否则会因为系统进程抢占导致卡顿。我把线程数从默认改成大核数量后，解码速度提升了大约15%，这个优化零成本，属于白捡的收益。

第二个是KV Cache的量化。transformer解码阶段要把历史的Key和Value缓存下来，FP16的KV Cache在不长的时间里就能吃掉几百MB内存。对DeepSeek这类对话模型，上下文一旦拉长，KV Cache甚至可能比权重本身更大。把KV Cache压到INT8，对最终生成质量几乎无损，但显存占用立刻减半，长上下文场景收益非常明显。

第三个是算子的融合和内存复用。透明框架里一个算子接一个算子执行，每个算子都要读写一遍全局内存，端侧尤其吃不消。实用的做法是把Attention计算里的Q乘K、缩放、Softmax、乘V等多个步骤融合成一个融合算子，中间结果直接留在片上寄存器或L2缓存里，不落回主存。我做完这项融合后，端侧单Token延迟又降了大约20%，效果立竿见影。

3.4 量化前后效果对比：一个可复现的实测数据

下表是我对DeepSeek蒸馏7B模型做的FP16、INT8、INT4三档对比，模型文件大小、内存占用、解码速度、Perplexity都有记录。环境是某ARM平台实测，使用统一提示词和采样参数。

INT4对比FP16，内存下降约65%，速度提升接近170%，Perplexity只增加了0.26。对绝大多数端侧应用来说，这个精度损失完全可以通过提示词工程或者微调弥补回来，换来的却是“能跑”和“跑不动”的本质区别。

再补一句关键体验：INT8折中方案在某些设备上其实更实用。如果端侧NPU原生的INT4算子还不成熟，强行INT4反而会因为反复反量化导致性能倒退，这种情况下INT8反而是甜点位。判断标准很简单：对比真实端侧的实际解码速度，不要只看模型体积。

4. 常见问题与排查技巧实录

4.1 问题速查表

我在整个过程中遇到的问题不算少，最有代表性的8个整理成了下表，每个都附了排查方向和解决结果，方便你直接对照。

4.2 排查实录一：量化后模型变成“复读机”

测试阶段遇到过输出全是重复文本的情况，一开始怀疑是温度参数问题，但调到极低还是复读。后来把INT4模型加载到桌面端测试环境对比，发现桌面端也复读，基本排除端侧框架因素。

接着用原始FP16权重跑同一批提示词，发现输出正常，问题锁定在量化环节。逐层检查后发现是校准阶段对某些长尾分布的文本过拟合了，导致模型对特定token的概率估计出现偏差。修复方案是重构校准集：删掉重复度高的样本，增加数学推理类文本的数量，把校准样本数从400条加到800条，同时把校准时的序列长度从512提到1024。重跑量化后，复读现象消失，Perplexity恢复正常。

这里有个教训：校准集的质量直接影响低比特模型的置信区域。如果校准集和真实场景分布错位，量化模型会对高频样本过拟合，生成时表现出明显的“单一化”倾向。

4.3 排查实录二：端侧NPU速度反而不如CPU

还有一次更憋屈的问题：明明NPU宣称算力是CPU的十倍，但跑INT4模型时NPU反而比CPU慢。连续排查了算子日志后真相大白：NPU底层对INT4矩阵乘支持不完整，框架在遇到INT4算子时自动插入了一层反量化，把INT4先转成FP16再送进计算单元，相当于白白多做了一次数据搬运和格式转换。

解决路径有两条。短期的做法是先把算子固定到INT8，让框架走成熟的原生通道；长期的方案是升级推理框架到对INT4支持更好的新版本，再看是否增加融合算子做半直接执行。这个经历也验证了前面说的：选型之前先确认目标平台的原生算子支持情况，比优化重写要省力得多。

5. 端侧算力新纪元：为什么INT4是2026年的关键支点

5.1 硬件趋势与INT4的同频共振

为什么这个时间点INT4会被反复提及？因为2026年前后的端侧硬件正在发生两个重要变化：一是新一代移动SoC里NPU的INT4推理路径逐渐成为标配，算力规模翻倍，同时硬件调度器对低比特数据搬运做了专门优化；二是内存方面LPDDR的带宽进一步提升，再加上共享内存架构统一，模型权重可以更高效地被CPU、GPU、NPU共用。

这两个变化对INT4来说是“双重顺风”。硬件支持了原生低比特计算，INT4不再需要靠反量化曲线救国，功耗和延迟都按预期下降；带宽提升让压缩之后的权重搬运成本进一步摊薄，端侧模型的上限从“跑得动7B”逐步逼近“跑得动32B”。我用CPU和NPU两个平台分别验证过，在支持原生INT4算子的新版框架上，INT4解码速度比上一代硬件翻倍都不止。

5.2 从模型压缩到系统优化的重心转移

INT4量化把模型体积压到极限之后，端侧部署的重心正在从“怎么把模型变小”转移到“怎么把系统效率榨干”。同样一个INT4模型，积极的系统优化和直接套默认配置，最终性能差距可以到50%以上。

具体来看，值得投入的方向有几个：一是缓存策略，包括页面级的权重预加载、按需分页，让常驻内存进一步降低；二是动态批处理和投机采样，一个减小请求排队开销，一个用小型辅助模型加速逐个token的生成；三是端侧微调和适配，用业务数据对INT4模型做低秩微调，把量化损失的精度在任务层面补回来。我实际验证下来，INT4模型配合低秩微调，在特定垂直任务上能超过未经量化的通用模型，这说明低比特加微调正在成为一条完整可用的技术路线。

5.3 真正落地时，最容易被忽略的三件事

最后说三个我踩过的坑，希望2026年的端侧项目不要再踩。

第一，别把Perplexity当成唯一的精度标准。Perplexity只能反映语言模型的平均困惑度，但端侧应用最终用的是具体任务指标，例如代码生成的通过率、客服场景的意图识别准确率、问答的忠实度。我的验收流程是Perplexity辅助判断、任务指标拍板，两个都过才允许上生产。

第二，量化模型上线以后依然要灰度回归。端侧模型的输入分布是动态变化的，今天跑得好不代表三个月后还好。我这边沉淀下来的做法是：维护一个200条的固定回归集，每次升级模型或推理框架跑一遍自动比对，出现异常结果立刻定位到量化参数还是环境变化。

第三，留意硬件白名单的算子差异。同一款NPU在不同机型上，驱动版本不同可能导致INT4算子行为不一致。我建议在目标设备矩阵上都跑一遍基准测试，建立一张“设备能力白名单”，对老设备自动降级到INT8，对支持原生INT4的新设备开启全量低比特。设备体验的一致性，有时候比硬件峰值算力更重要。

我现在做新模型适配的习惯已经固化成一套流程：先量化，再校准，然后任务级回归，最后设备矩阵压测。这套流程在DeepSeek系列的多个尺寸模型上都跑通了，INT4量化也从一开始的“玄学”变成了可预测的工程手段。轻量化模型这条路还很长，低比特量化大概率只是2026年前端侧算力释放的起点，后续的稀疏化、混合精度调度、端侧持续学习都会继续把这条线往前推，但眼下能确定的是，INT4量化已经成了每个端侧团队工具箱里最趁手的那把工具。