1比特每参数！763B DeepSeek-V4.1-Flash压缩版发布

模型压缩新突破：763B参数塞进1比特

大模型压缩技术迎来一次颇具想象力的尝试。ISTA Deep Algorithms and Systems Lab 在 Reddit 发布了 DeepSeek^广告-V4.1-Flash-1017 的 Coder 构建版本，通过 GSQ 与 RCO 两项技术，将原始 763.2B 参数的稀疏混合专家模型压缩到平均每参数 1 比特，同时保留一半的专家。

DeepSeek-V4.1-Flash-1017 本身是一个稀疏 MoE 模型：每层 384 个路由专家，每个 token 激活其中 6 个，总参数 763.2B，其中 551.9B 位于 transformer 部分。这次发布的 Coder 版本在每层保留 192 个专家（即剪掉一半），transformer 权重体积为 72.1 GB，而未经剪枝的 IQ2_XXS 构建为 138.2 GB。

1比特是怎么算出来的？

官方对"1 bit per parameter"的算法给出了明确解释：72.12 GB 除以原始 551.9B transformer 参数，得到 1.05 比特，四舍五入为 1。被移除的专家按零比特计入。

这里有一个容易被误读的点：没有任何单个权重被存储到低于 1 比特。Coder 保留的 280.1B 参数平均为 2.06 比特——只是剪枝掉的那部分参数被计为零，拉低了整体平均值。这种口径在压缩社区并不罕见，但确实需要读者留意。

此外，共享的 Engram 文件（110.6 GB）和视觉投影器与未剪枝版本完全相同，因此只需下载一次。

GSQ 与 RCO：两项压缩技术拆解

GSQ（Gumbel-Softmax Quantization）是一种训练后标量量化方法，它联合学习网格分配和组缩放，在低比特宽度下缩小了标量量化与向量量化之间的差距，同时保持能以标准 GGUF 类型部署。

RCO（Riemannian Constrained Optimization）则通过对任务损失做梯度下降来精确满足预算约束，无需为每个约束单独调参。在这个项目中，RCO 负责选择保留哪些专家，优化目标是相对于未剪枝模型的 KL 散度，约束条件是每层一个精确预算。

为什么每层只能保留相同数量的专家？

GGUF 格式为整个模型存储单一的专家数量，因此每一层必须保留完全相同的专家数；层间不均衡会导致填充，反而抵消剪枝节省的内存。RCO 将每层预算视为硬约束，在优化每一步都精确保持所有层的预算，同时所有层通过全模型上的单一损失联合优化。相比之下，惩罚项方法只能近似满足预算，且需要为每层调一个系数。

标量量化与向量量化的差别：量化本质上是用更少的比特表示权重。标量量化对每个权重独立取整到某个码本，实现简单、可用标准 GGUF 类型部署；向量量化把一组权重作为一个整体映射到码本中的某个向量，能利用权重间的相关性，在同等比特下通常误差更小，但码本查找和部署格式更复杂。GSQ 的价值在于缩小两者差距的同时保留标量量化的部署便利性。

Gumbel-Softmax 的作用：网格分配本质上是离散选择（每个权重归到哪个量化格点），离散选择不可导，无法直接反向传播。Gumbel-Softmax 是一种重参数化技巧，用带温度参数的连续松弛近似离散采样，使梯度可以穿过选择操作回传，从而让"选格点"和"学组缩放"能在同一个训练后优化流程中联合进行。

GGUF 的存储结构：GGUF 是 llama.cpp 使用的模型文件格式，它以张量为单位组织权重，并在元数据中记录模型的全局结构超参数，其中专家数量是模型级的单一字段，而非逐层可变。因此若各层保留的专家数不一致，加载器只能按最大层补齐，被填充的空位同样占用内存，剪枝省下的空间被部分抵消。

结构化剪枝与预算约束：剪掉整组专家属于结构化剪枝，相比非结构化稀疏更容易在通用推理引擎上获得实际加速。RCO 的"硬约束"指的是在每一步梯度更新后把参数投影回可行域，使预算始终精确成立；惩罚项方法则把约束写进损失，只能在优化结束时近似满足，且不同层需要不同的惩罚系数，调参成本高。

性能表现：代码生成几乎无损，智能体任务有所下降

官方公布了两个基准测试结果：

• LiveCodeBench v6：88.57，对比基座模型 89.71，保留 98.7%
• SWE-bench Verified：77.00，对比基座模型 81.20，保留 94.8%

SWE-bench Verified 需要在真实代码仓库上运行长程智能体轨迹，对容量削减的容忍度低于单题代码生成——这符合多轮误差累积时的预期表现。换句话说，剪枝对"写一段代码"影响很小，但对"多步操作真实仓库"影响更明显。

官方还展示了三个由该 Coder 单文件生成的 HTML 示例：骑自行车的鹈鹕动画 SVG、three.js 体素宝塔花园，以及可玩的第一人称体素沙盒。

两个基准的差异：LiveCodeBench 是竞赛风格的算法题基准，输入输出明确、单轮求解，模型只需在一次生成中写出正确程序，误差没有累积机会。SWE-bench Verified 则从真实开源仓库中抽取 issue，要求模型在多轮工具调用中定位文件、修改代码并跑通测试，单步的小偏差会沿轨迹放大，因此对模型容量更为敏感。这也解释了为何同为代码任务，两处保留率相差近四个百分点。

KL 散度作为剪枝目标：RCO 以相对于未剪枝模型的 KL 散度作为优化目标，衡量的是保留模型与原模型在输出分布上的差异，而不是直接优化下游任务准确率。这种做法的好处是无需任务标注即可在全模型上联合优化，代价是分布拟合得好并不保证每个具体能力都同等保留。

使用方式与获取渠道

该 GGUF 模型可在 llama.cpp b11870 或更新版本以及 Strata 中运行。仓库附带完整的逐张量 RCO 分配方案。

• Coder（专家剪枝版）：Hugging Face 上的 ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-Coder-GGUF
• 量化模型（未剪枝）：ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF
• GSQ 论文：arxiv.org/abs/2604.18556，代码：github.com/IST-DASLab/GSQ
• RCO 论文：arxiv.org/abs/2605.00649，代码：github.com/IST-DASLab/RCO

官方将 Coder 构建定位为实验性发布，欢迎反馈，尤其关注校准混合数据中未覆盖的能力。同时也接受对其他模型进行量化或剪枝的请求。

这次发布意味着什么

把 763B 级 MoE 模型压到 72 GB 的 transformer 权重，意味着消费级或单机多卡环境有了运行超大模型的可能——尽管 110.6 GB 的 Engram 文件仍是不可忽视的额外开销。GSQ 和 RCO 的组合提供了一条可复现的技术路径：前者处理低比特量化的精度损失，后者以硬约束方式解决结构化剪枝的预算分配。对于关注开源推理部署和模型压缩的开发者，这是一个值得跟踪的实验性方向。

Engram 的定位：文中提到的共享 Engram 文件是模型结构中的一部分额外参数，与 transformer 权重分开存放，未参与本次剪枝与量化，因此体积保持 110.6 GB 不变。这使得"72 GB 的 transformer 权重"并不等于完整可运行模型的总占用，实际部署时仍需为 Engram 预留显存或采用 CPU 卸载等策略，评估硬件门槛时应把两部分合并计算。