从FP32到INT4，一个7B模型的"减肥"全流程。
量化不是魔法，它有代价——而且是PM必须知道的代价。现在几乎所有AI硬件都在喊"端侧大模型"。7B参数，INT4量化，跑在NPU上，听起来很顺。
但你有没有想过，一个原本需要14GB显存的模型，是怎么缩到2GB还能跑的？中间到底丢了什么？丢了多少？
今天这篇不讲行业大势，不讲市场格局。就钻进这个技术本身——一个7B模型从"云端版本"到"眼镜版本"，到底经历了什么。
做硬件PM不一定需要会写量化代码，但必须知道量化在做什么、代价是什么、哪些场景扛得住哪些扛不住。不然你立项时选的技术路线，可能连自己都不清楚它到底牺牲了什么。
· · ·
起点：一个7B模型，没压缩之前有多大
大模型的参数，本质上是一堆数字。每个参数就是一个浮点数，记录了训练过程中学到的"权重"。
7B模型，顾名思义，有7亿个参数。每个参数默认用FP32存储——32位浮点数，精度最高，占4个字节。
7B 参数量 70亿个权重 | 28GB FP32存储 7B × 4字节 | 14GB FP16存储 7B × 2字节 |
28GB——这个数字意味着什么？你的手机内存可能只有8GB，眼镜的RAM可能只有2GB。28GB连放进手机都放不进去，更别说眼镜了。
所以第一步，所有人都会做FP16转换：把32位浮点砍成16位。精度从"7位有效数字"变成"3位有效数字"，模型体积直接减半。
FP16到底丢了什么：FP32能表达 0.0000001 级别的微小差异，FP16只能表达 0.001 级别。对于大模型里的大多数参数来说，0.001的精度已经够用了——因为训练时参数的分布本来就在一个相对粗的尺度上。FP16量化对推理结果的影响，通常在1-2%以内，基本可以忽略。 FP16是"免费午餐"——精度损失微乎其微，体积减半。所以现在云端推理也基本都用FP16，没人用FP32了。
但14GB还是太大。眼镜要装进去，还得继续砍。
· · ·
第二步：INT8量化——开始有代价了
从FP16砍到INT8（8位整数），是量化的第一个真正难关。
原理不复杂：把浮点数映射到-128到127的256个整数档位上。就像把一个连续的光谱，压缩成256个色阶。
关键变量是"max"——你要把多大范围内的浮点值，塞进-128到127这256个格子里？
这就是INT8量化最核心的取舍：
量化粒度决定精度：
· per-tensor量化（整个矩阵用一个缩放系数）：最简单，精度损失最大。因为模型参数分布不均匀——有的集中在0附近，有的分布很宽。一个系数管整个矩阵，就像用一把尺子量所有东西，粗的粗、细的细。
· per-channel量化（每行/每列独立缩放）：精度好得多，但计算时需要逐通道还原，NPU要有这个能力才能高效跑。
· per-group量化（每128或256个参数一组）：精度和per-channel接近，是目前INT8的主流做法。 INT8量化后，模型体积从14GB降到7GB。推理速度大约提升2-3倍（整数运算比浮点运算快），功耗也降了。
代价呢？
看到规律了吗？容错越高的任务，量化损失越小；需要精确推理的任务，量化损失越大。
翻译、摘要——这些"输出质量有点偏差用户也不太在意"的场景，INT8基本没问题。但逻辑推理和多轮对话——这些"一步错步步错"的场景，INT8就开始扛不住了。
7GB，比14GB小了一半。但眼镜的RAM只有2GB。还得继续砍。
· · ·
第三步：INT4——真正的硬核压缩，代价也最大
INT4，就是把每个参数用4位存储——只有16个档位（-8到7）。7B模型从7GB压到3.5GB。
加上一些优化（group quantization、混合精度），实际落地时模型大小在2-3GB左右。终于能塞进眼镜了。
2-3GB INT4量化后 终于能塞进眼镜了 | 7GB INT8 还是太大 | 14GB FP16原版 根本装不进去 |
但代价呢？16个档位表达原本几万个不同值的参数——这不是压缩，是暴力归类。
INT4的真实代价：
1. 小参数被吞掉：模型里很多参数的值在0.001-0.01之间——对FP16来说这些是"微调信号"。INT4只有16个档位，-8到7，这些0.01级别的小值，要么被归成0，要么被归成1。微调信号没了，模型在细节判断上变"粗"了。
2. 稀疏能力下降：大模型有一种隐含的"注意力选择性"——该关注什么、该忽略什么。INT4量化把这个选择变得更粗暴——要么"完全关注"（值映射到7），要么"完全忽略"（值映射到0）。中间的"稍微关注"被吞掉了。
3. 累积误差放大：单步推理的误差不大，但大模型是几十层层层传递。INT4的误差从第一层开始，每经过一层就叠加一点，到最后一层输出时，累积偏差可能比单层大3-5倍。
4. 量化敏感层不均匀：不是所有层都受影响一样大。模型的最后几层（输出层、注意力头）对量化最敏感，这几层用INT4的损失远大于前几层。好的量化方案会对这几层保留FP16——这就是"混合精度量化"。 这就是为什么各家都在推"混合精度"方案——不是一刀切INT4，而是大部分层用INT4，少数关键层保留INT8甚至FP16。这样模型大小控制在3GB左右，精度损失尽量压到10%以内。
· · ·
PM视角：量化不是技术问题，是产品问题
讲完了量化的原理和代价，回到PM最该关心的问题：这些数字怎么影响你的产品决策。
三条PM判断规则：
1. 先定义场景，再选量化方案
你的产品核心场景是什么？如果是翻译和摘要——INT4就能扛，体积最小，速度最快。如果是多轮对话和复杂推理——INT4扛不住，至少要混合精度，甚至INT8。不要反过来：先选芯片再想场景。芯片的NPU算力决定了你能跑什么量化方案，量化方案决定了你能支撑什么场景。
2. 量化损失要转化成用户语言
不要跟用户说"精度损失12%"。用户听不懂。转化成体验语言：
· 翻译场景：12%损失 = 每10句有1句翻译偏差（用户可能感知不到）
· 问答场景：12%损失 = 每8个问题有1个回答错误（用户立刻投诉）
· 多轮对话：12%损失 = 对话5轮后开始"忘事"（用户觉得笨）
同一个12%，不同场景下用户感知完全不同。
3. 用端云协同补偿量化损失
端侧跑INT4/混合精度覆盖80%的日常简单任务，剩下的20%（复杂推理、多轮对话）走云端FP16。用户感知不到切换——端侧先秒回一个"初步答案"，云端同步跑一个"精确答案"，如果差异大就自动修正。
这样你端侧只承担简单任务的量化损失，复杂任务的精度由云端保障。产品宣传可以讲"端侧秒级响应"，技术实现上是端云双保险。 量化不是让模型变"笨"了——是让它在有限资源里做取舍。取舍的方向，应该是PM来定，不是算法工程师来定。
算法工程师告诉你"INT4精度损失12%"。PM的工作是判断：这12%在我的产品场景里，用户能不能接受？能接受就用INT4争取最小体积和最快速度；不能接受就用混合精度或INT8，或者端云协同补上去。
· · ·
全流程总结：7B模型的"减肥"路线
一个7B模型从云端到眼镜的完整压缩路线：
Step 1：FP32 → FP16
28GB → 14GB · 精度损失 ≈1% · 基本免费
Step 2：FP16 → INT8
14GB → 7GB · 精度损失 ≈5% · 开始有代价，简单场景OK
Step 3：INT8 → INT4 / 混合精度
7GB → 2-3GB · 精度损失 ≈8-12% · 真正的硬核压缩，复杂场景扛不住
Step 4：端云协同补偿
端侧覆盖简单任务，云端兜底复杂任务 · 用户感知接近FP16
━━━━━━━━━━━━━━━━━━━━
最终效果：2-3GB模型塞进眼镜，日常场景秒级响应，复杂场景云端兜底。这是目前最务实的产品路线。
粤ICP备14082021号
免费POC，
零成本试错
