细节是魔鬼，如何给超大参数规模的模型做量化？以科研大模型 Intern-S2-397B 为例
书生-S2 官方全精度权重约 807GB，我们把它压到 98GB，跑进 128GB 内存的 Mac。压缩本身不难，难在一路上容易踩坑的细节。
一个 4000 亿参数的科研大模型，官方全精度权重约 807GB，8 比特版也要 400 多 GB。我们想让它跑进一台 128GB 内存的 Mac，于是把它压成了低比特版本，最终 98GB，提供给活水模型（42model）的用户。
听上去只是「跑一遍量化工具」的事。真做下来，决定成败的全是细节。
一台 Mac，一个 807GB 的模型
这次压缩的是上海人工智能实验室开源的书生-S2（Intern-S2-397B），Apache-2.0 许可。据官方介绍，它的通用能力（知识、代码、智能体）达到开源模型第一梯队。在生命科学与材料结构相关的科学任务上，比如 Biology-Instructions、Mol-Instructions，它大幅领先其他开闭源旗舰。在 IMO-Proof、AdvancedMathBench 这类考验长程严谨推理的数学基准上，它整体领先现有开源模型，达到 Gemini 3.1 Pro 等顶尖闭源模型的水平。
书生-S2 是 MoE（混合专家）结构，每层有 512 个「专家」，每处理一个 token 只请其中 10 位出场。这意味着计算量不大，但所有专家都得常驻内存。所以问题归结为一句话，怎么把 400 多 GB 的专家们装进 128GB，还让他们说人话。
模型越大，瓶颈越不在 GPU
这次整个流程里（一台 M3 Max，原始文件分放在一块 SSD 和一块 USB 机械硬盘上），拖慢我们的不是算力，全是磁盘。
第一步是把官方权重转成我们工具链用的格式。原始文件太大，我们没有专门腾一块新盘，而是分放在一块 SSD 和一块传统机械硬盘上。结果转换时 CPU 只用到 10%，读盘每秒只有十几到二十几兆，光这一步就花了四个多小时。整个压缩前后用了一天多，大半时间在等盘。
第二步是「校准」，让模型先读一批文本，记下哪些权重对结果影响大，压缩时据此分配精度。校准时模型要把文本真的算一遍，512 个专家都可能被用到，而它们分散在 400 多 GB 的文件里，所以每校准一批文本，几乎要把全部权重从盘里完整读一遍。把每批的文本量调大四倍，读盘遍数从 20 遍降到 5 遍，校准在两个多小时内完成。
所以做大模型量化，先把原始文件放到最快的那块盘上。
动手之前，先看看同行走到了哪里
工作快做完时，我们才发现开源社区的量化作者 bartowski 早已发布了书生-S2 的全套低比特版本，还公开了逐张量的配方。
对照之后有两个发现。一是我们和他独立走到了同一条原则上，低比特只给路由专家，其余部分保护起来。二是他多做了一步「逐层分配」，前面若干层的专家给高一点的精度，中间层给低一点，体积因此比我们小约 6GB。
我们最后没有照搬，而是用同一套测法把两种配方比了一遍（后面会讲），按结果选了自己的。但如果动手前先查一遍，能少走不少弯路。
低比特该给谁
同样是每个参数 1 到 2 比特的低比特压缩，精度分给哪些部分，决定了它是能用的模型还是一堆乱码。
MTP 层：推理不经过，校准也没有数据
书生-S2 在最后带了一层「多 token 预测」（MTP）头，训练时用来一次猜好几个 token，正常推理并不经过它。于是校准阶段它一个字也没读到，没有任何「哪里重要」的记录。
低比特压缩恰恰依赖这份记录。结果是压缩进行到第 1099 个张量（模型由一块块权重矩阵组成，每块叫一个张量，这个模型共 1118 块）时报错退出。解决办法是给 MTP 层单独指定一个不需要校准数据的中等精度。更重要的是在正式开始前先做一次「空跑」预检，几秒钟就能列出每个张量会被怎么处理，缺什么一眼可见。
敏感权重：3GB 的小张量，决定近百 GB 的模型能不能用
第一版我们用了量化工具的默认配方，整体压到约 1.6 比特，84GB。结果模型彻底「说胡话」：中文回答陷入重复的引号，写斐波那契数列的代码时反复输出同一段乱码，一道火车相遇的应用题只输出一串无意义的数字。困惑度（衡量模型对文本有多「意外」，越低越好）从 8 比特版的 4 左右涨到了 48。
为了排除「是不是采样参数没调好」，我们换成官方推荐的采样设置重新测试，依旧崩坏。问题确实出在压缩上。
按张量类别统计后发现，默认配方把一批小而敏感的部分也压到了 1 到 2 比特，包括注意力、线性注意力、共享专家，连词嵌入也被压到了 2 比特（q2_K）。这些部分加起来只有约 3GB，却是每个 token 都要经过的。真正的大头是约 72GB 的路由专家，每个 token 只用到其中一小部分，对压缩的容忍度高得多。
第二版改成混合配方，路由专家压到 1 到 2 比特，其余部分基本都保留 8 比特。体积只多了约 14GB，四道测试题都恢复正常，火车题和代码题的答案正确，困惑度回到 4.7 左右。
差别不在压多狠，而在压哪里。
量得准，比压得狠更难
困惑度要同源
困惑度是量化时常用的指标，但它有两个前提容易被忽略。
第一，要用同一个程序、同一份文本、同样的参数去测。不同程序算出的困惑度，只能当量级参考，不能拿来比几个百分点的差距。
第二，测试文本不能是校准时用过的文本。我们一开始就在自己的校准文本上比较，结果用我们校准数据的版本显得更好。这相当于让学生在自己做过的练习题上考试。换成一份两份校准文本里都没有的中文技术文档（约 2 万字，逐段核对过零重叠），所有版本用同一个程序重测，排名就变了，而且各版本与原模型的差距从「约 7%」变成了 9% 到 13%。
比困惑度更关键的，是 KL 散度
即便换了考卷，几个版本的困惑度差距仍在误差范围内，分不出高下。
困惑度只看模型给「正确答案」打了多少概率，不同段落之间波动很大。KL 散度（KLD）换了一个角度，让压缩版和 8 比特版读同一段文字，逐个 token 比较两者对「下一个字」的整个预测分布差多少。它是一一配对的比较，误差一下子缩小到千分之三左右，版本之间的差别就看得出来了。
| 版本 | 体积 | KL 散度（越低越接近原模型） | 首选 token 与 8 比特版一致 |
|---|---|---|---|
| 我们的混合配方 | 98.1GB | 0.137 | 81.2% |
| 社区逐层配方 + 社区校准数据 | 91.6GB | 0.180 | 78.7% |
| 社区逐层配方 + 我们的校准数据 | 91.6GB | 0.186 | 78.8% |
在这组测试里，多出的 6GB 换来了实打实的保真度，我们因此选择上线混合配方。所以，比较量化版本时，不仅要看困惑度，更要看 KL 散度，后者更关键：它逐个 token 配对比较，受段落难易的影响小，版本间的差别更明显。
现在，你可以在自己的 Mac 上跑它
书生-S2 的这个版本已经上架活水模型。打开活水模型（42model），在「模型 → 发现 → 科研」里就能看到 Intern-S2-397B。它属于「前沿」模型，下载前会先做一次自检，并要求存到一块外置盘上，不占用系统盘。如果列表里还没有它，重启一次应用即可刷新。
几点需要提前知道：
- 需要 128GB 内存，外加一块剩余空间 100GB 以上的外置盘，模型文件 98GB。
- 在 Apple M3 Max（128GB）上，用 GPU 生成每秒约 6 到 15 个 token，视上下文长短而定。
- 这个版本只包含文本部分，暂不支持看图。
- 每个参数约 1.95 比特是相当极限的压缩，所以它归在「前沿」实验模型里。我们只在一台电脑、一份中文文档上做了这组对比，没有跑下游基准，请把它当作参考而不是定论。
你在自己电脑上跑过最大的模型是哪一个？哪一步最折腾？欢迎在评论区聊聊。
807GB 到 98GB，中间没有什么魔法，只是把每一个细节都认真对待了一遍。
活水 AI 实验室（42ailab） — 探索智能边界的 AI 创新实验室，以认知科学为基石，推动 AI 与人类智能的深度融合，真正理解并增强智能 —— 碳基的，也是硅基的。
活水模型（42model） — 由活水 AI 实验室出品的高性能本地 AI 大模型推理引擎，让翻译、转写、识别、对话、编程等 AI 能力在你的本机免费私密运行；并可借云端算力微调专属模型，回传本机运行。