CubicQuant：用三次曲线重塑低比特量化，Kimi K3 2.5Bit 模型首发实践

魔搭ModelScope社区

28人浏览 · 2026-08-12 17:58:45

魔搭ModelScope社区 · 2026-08-12 17:58:45 发布

当权重只剩 2～4 bit，真正稀缺的不只是比特数，而是每一个量化等级应该放在哪里。CubicQuant 的思路是：继续保留规整、可打包的整数码流，但允许每个权重组用一条单调三次曲线重新安排内部量化等级。基于这一技术，QuantTrio 发布了 Kimi-K3-Cubic-2.5Bit，这是 Cubic 量化的首个公开大模型实践。

模型地址：QuantTrio/Kimi-K3-Cubic-2.5Bit
技术报告：CubicQuant: Parametric Non-Uniform Codebooks for High-Throughput LLM Inference with 1-8-Bit Weights
推理运行时：QuantTrio/vllm-cubic

先看结论：这次发布了什么？

Kimi-K3-Cubic-2.5Bit 基于 2.8T 参数的 Kimi K3，将路由专家权重按层混合量化为 Cubic W2、W3 和 W4，并保留注意力、共享专家、视觉模块等关键部分的源精度。

按模型附带的量化审计报告计算，这些被转换的专家张量平均 payload 为 2.3696 bit，计入每组的 scale 和两个曲线参数后，有效位宽为 2.4986 bit。模型文件共 341 个 Safetensors 分片，约 899 GiB。

模型卡披露的参考部署配置为一台 8 × NVIDIA H200 141GB 节点，采用 TP8 + EP。在指定的短提示、长输出解码测试中：

单请求短上下文解码约为 57 output tokens/s；
64 路并发聚合解码约为 800～900+ output tokens/s；
未使用 dSpark 或其他推测解码；
搭配运行时的 fp8_q16 KV Cache 时，有效最大上下文长度约为 728,640 tokens。

这些数字是模型卡给出的特定硬件、启动参数和解码窗口观测值，不是跨硬件的普适结论，也不是包含预填充和排队时间的端到端吞吐保证。

还有一条同样重要的边界：2.5Bit 指路由专家量化张量的有效位宽，不代表整个 2.8T 模型的所有权重都被压到 2.5 bit。

为什么低比特量化需要一种新的“网格”？

标量量化可以理解为：用有限数量的重建值，去近似连续分布的原始权重。比特越少，可用等级越少，“把等级放在哪里”就越重要。

常见方案各有侧重：

方案	量化等级如何产生	优点	低比特下的主要约束
均匀整数 INT	等间距线性网格	打包规整、解码简单、易于执行	每组只能缩放网格，不能改变内部等级分布
低比特浮点	固定指数-尾数结构	动态范围更灵活	等级分布由格式预先决定，未必匹配每个权重组
学习型自由码本	直接学习多个重建值	表达能力强	查表、元数据和内核实现更复杂
CubicQuant	用少量参数生成非均匀等级	兼顾局部适应与规整码流	需要额外曲线参数和融合解码内核

大模型权重往往在零附近更密集，同时又存在较长尾部。均匀网格只能整体放大或缩小：步长太大，会浪费零附近的精度；步长太小，又容易裁掉尾部。

CubicQuant 的核心目标，就是在“固定网格”和“自由码本”之间寻找中间点：

编码仍然是连续、致密的低比特整数；但整数所代表的重建值，不再必须等间距。

CubicQuant 核心：把直线网格“掰弯”

对于大于 1 bit 的权重格式，设 payload 位宽为 B，正侧最大整数码为：

整数码 k 的归一化幅值坐标为：

CubicQuant 用一条归一化三次曲线，把均匀的整数坐标映射为非均匀重建等级：

最终重建权重为：

其中：

s 是该权重组的 FP32 scale，决定正负端点；
a、b 是两个 FP16 形状参数，决定内部等级如何重新分布；
三次项系数 c=1-a-b 由前两者推导，不需要额外存储。

这个形式刻意保留了三个重要性质：

精确零点：前面的 t 保证 q(0)=0；
精确端点：c=1-a-b 保证 q(1)=1，最大正负码始终对应 ± s；
等级有序：候选参数必须满足 q'(t)>0，避免量化等级交叉或反转。当 a=1,b=0 时：

也就是说，对称均匀整数本身就是 CubicQuant 的一个精确特例。拟合时只要始终保留这个候选点，在参数序列化前，最优 Cubic 解在同一目标下就不会比对应的最优裁剪 INT 解更差。

直观地说，CubicQuant 并不移动零点和最大幅值，只“弯曲”中间的等级。对于高斯或拉普拉斯型分布，曲线可以把更多等级挪到零附近，同时给尾部保留更远的端点。

为什么只用两个形状参数？

如果给每个组自由学习一整张码本，表达能力当然更强，但会带来更多元数据、查表和执行复杂度。CubicQuant 选择用 a、b 两个参数描述整条单调曲线，是一种有意识的约束：

比均匀 INT 多出局部非均匀性；
比自由码本少得多的元数据；
码流仍是普通的 1～8 bit 标量整数，可连续打包；
量化等级可以在 GPU tile 内快速生成或查表，而不必展开整张权重矩阵。

技术报告把这种关系写成一个清晰的误差边界：

左边是自由标量码本的 Lloyd-Max 下界，右边是最优裁剪均匀整数。CubicQuant 的问题不再是“能不能超过 INT”，而是“只用两个形状参数，能收回多少 INT 与自由码本之间的差距”。

在报告的总体分布分析中，W4～W8 CubicQuant 收回了高斯分布下 84.8%～96.1%、拉普拉斯分布下 91.4%～96.9% 的 INT-Lloyd-Max 误差差距。

存储开销是透明的：B+64/G bit

对每个包含 G 个权重的组，CubicQuant 存储：

G× B bit 的整数 payload；
一个 FP32 scale：32 bit；
两个 FP16 形状参数：32 bit。

因此元数据总计 64 bit/组，折算到每个权重：

Group Size	每权重元数据	W2 有效位宽	W3 有效位宽	W4 有效位宽
128	0.500 bit	2.500 bit	3.500 bit	4.500 bit
256	0.250 bit	2.250 bit	3.250 bit	4.250 bit
512	0.125 bit	2.125 bit	3.125 bit	4.125 bit

更大的组可以摊薄元数据和码本生成成本，但也让同一条曲线覆盖更宽的权重区域；更小的组适应性更强，却需要更多元数据。CubicQuant 没有把这个权衡藏在“平均 bit”里，而是用公式直接给出。

以 G512 为例，和两字节 BF16 权重相比，单个矩阵的理想常驻权重压缩比为：

格式	字节/权重（含元数据）	BF16/Cubic 理想压缩比
W2 G512	0.265625	7.53×
W3 G512	0.390625	5.12×
W4 G512	0.515625	3.88×

这里是表示层面的比例，不等于内核加速比，更不等于完整模型文件会按同样比例缩小。完整模型还包含未量化张量、配置文件、索引和其他数据。

从曲线到量化器：数据无关的组内拟合

CubicQuant 把“格式”和“估计器”分开。格式只规定码流、scale、形状参数和解码函数；用什么数据、什么损失来选择它们，可以独立演进。

当前技术报告和 Kimi-K3-Cubic-2.5Bit 使用的是数据无关参考流程：

将静态权重切分为组；
对每个组搜索单调的 a,b 候选；
联合优化 scale 和软裁剪阈值；
将每个权重分配到最近的重建等级；
把 a,b 转为 FP16、scale 保留 FP32，再重新计算编码和误差。

整个导出过程不需要校准集，也不读取激活样本。模型卡同时公开了完整转换脚本 quantize_k3.py，参考环境中使用 8 × H200 和高速本地存储，转换约需 35～40 分钟。

数据无关不意味着格式只能做权重 MSE。未来完全可以把同一存储格式接入激活加权、协方差加权或近似 Hessian 目标；变化的是参数与码值的选择方式，不是 checkpoint 布局和运行时数值契约。

一份 checkpoint，同时服务 A16 与 Dynamic A8

CubicQuant 支持两种执行语义：

Model-dtype/A16：激活使用 FP16 或 BF16，内核消费连续 Cubic 重建值；
Dynamic A8：每个激活行在运行时动态量化为 INT8，权重等级也映射到确定的 INT8 carrier，再使用整数点积和 FP32 组级缩放。

如果只按连续曲线拟合，得到的等级在第二次投影到 INT8 网格后可能不再最优。为此，CubicQuant 显式定义权重侧 carrier：

并用联合目标同时考虑连续重建误差 LC 与 carrier 重建误差 LA8：

这不是推理时把两条路径混在一起平均，而是在离线拟合时让同一份权重兼顾两种运行方式。部署时，A16 只走连续路径，Dynamic A8 只走 carrier 路径。

Kimi-K3-Cubic-2.5Bit 的转换默认启用这项 A8 carrier 修正，因此同一 checkpoint 可以通过运行时开关在 A16 与 Dynamic A8 之间切换。

压缩权重必须“边解码、边计算”

Cubic 码并不是 Tensor Core 原生数据类型。如果先把整张低比特权重矩阵展开为 BF16 或 INT8，再送去矩阵乘法，就会把完整权重写回、再读出，抵消大部分带宽收益。

CubicQuant 采用 tile-local 的融合路径：

低比特码流 + 组级参数
          ↓
GPU tile 内解包并生成 Cubic 等级
          ↓
临时转换为 model dtype 或 INT8 carrier
          ↓
立即进入当前 tile 的点积
          ↓
FP32 组级缩放与累加 → 模型输出 dtype

临时展开的权重只存在于当前计算 tile，不会物化为一张完整的高精度矩阵。运行时同时提供窄行 GEMV、二维 dense kernel，以及部分场景的原生 CUDA/INT8 路径。

这也解释了为什么 A8 不是在所有形状上都更快：

当 M=1、接近单 token 解码时，激活动态量化和整数路径启动成本很难摊薄，成熟的 A16 GEMV 通常更快；
当行数增加，权重解码可以在更多激活行之间复用，A8 的固定成本被摊薄，整数主循环开始占优；
临界点还会随位宽、组大小、矩阵形状、路由密度、GPU 架构和编译栈变化。

报告在 H200 上观察到的正是这种 workload-dependent crossover，而不是“A8 永远更快”。因此 vLLM Cubic 会针对设备和算子签名校准候选 kernel，选择窄行、dense、原生或通用路径。

Dynamic A8 仍然是算子局部模式，不是永久保持 INT8 激活的整图执行。报告还公开了一个负结果：把 INT8 激活 carrier 持久化到相邻 MLP 算子之间，额外的规约、同步、scale 生成和写回成本超过了省下的 BF16 流量，因此没有进入保留设计。

实验结果：先看表示能力，再看执行边界

1. 有限组重建误差

报告从 Uniform、Gaussian 和 Laplace 三种零均值分布中各抽取 15,360 个样本，以 G128 分组独立拟合。W4 的 NRMSE 如下：

分布	Cubic W4	最优裁剪 INT4	最佳枚举有限 FP4	相对 INT4 降低	相对 FP4 降低
Uniform	0.062979	0.065536	0.065536	3.90%	3.90%
Gaussian	0.092396	0.106803	0.102027	13.49%	9.44%
Laplace	0.106764	0.148571	0.113906	28.14%	6.27%

Uniform 的总体最优本来就是线性网格，有限组中出现的小幅收益来自每个实际样本组对理想分布的偏离。Gaussian 和 Laplace 在零附近更密集、尾部更长，非均匀等级的优势更明显。

这些数据证明的是标量重建能力，不是困惑度、推理能力或下游任务准确率。

2. H200 内核交叉点

技术报告在单张 H200 上测试了两个代表性大矩阵形状和 W2、W5、W8 三个位宽。结果显示：

M=1 时，A16 更快；
到 M=16 后，部分位宽已经出现 A8 优势；
M=64 和 M=256 时，Dynamic A8 在所测形状中明显占优。

但这些只是 Hopper 上的隔离 kernel 证据。报告明确没有据此宣称跨 GPU 的普适加速，也没有把完整服务系统的变化全部归因于权重格式。

Kimi-K3-Cubic-2.5Bit 是怎样得到 2.4986 bit 的？

该模型没有给所有层使用同一种位宽，而是根据层位置采用混合策略：

范围	量化策略
Dense layer 0	BF16 源精度
MoE layers 1～3 路由专家	Cubic W3，G256
MoE layers 4～32 路由专家	Cubic W3，G512
MoE layers 33～91 路由专家	Cubic W2，G512
MoE layer 92 路由专家	Cubic W4，G512
Attention / KDA / MLA	BF16 源精度
Shared experts 与普通 MLP	BF16 源精度
视觉塔、多模态投影、Embedding、Norm、LM Head	源精度

92 个 MoE 层的平均 payload 为：(3×3+29×3+59×2+1×4)/(92) =2.3696 bit

其中 3 个 G256 层各增加 0.25 bit/weight 元数据，其余 89 个 G512 层各增加 0.125 bit/weight 元数据：

(3×0.25+89×0.125)/(92) =0.1291 bit

两者相加：2.3696+0.1291=2.4986 bit

这正是量化审计文件给出的 expert_effective_bits。它是对被转换专家张量的精确统计，而不是一个由模型文件大小反推的宣传数字。

审计结果还给出了各格式的组内重建 NRMSE 和裁剪比例：

格式	NRMSE	被裁剪权重比例
W2 G512	0.451251	12.2307%
W3 G256	0.179608	2.6971%
W3 G512	0.181007	2.9948%
W4 G512	0.043047	0.5635%

这里的 Loss 是按源权重能量归一化的组内重建 NRMSE，不是模型任务分数。W2 承担了主要压缩比，也带来了更高的重建损失和裁剪比例；前部和末端的部分专家层使用 W3/W4，是精度与存储之间的分层折中。

快速部署：使用 vLLM Cubic 运行时

模型数据约 899 GiB，参考部署已经验证的是 Linux x86-64、Python 3.12、CUDA 13.0、PyTorch 2.13.0、8 × H200、TP8 + EP。下载和部署前请先确认本地存储、显存、网络和运行环境。

从 ModelScope 模型页下载 checkpoint 后，可安装模型卡指定的 vLLM Cubic 版本：

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install \
 'https://github.com/QuantTrio/vllm-cubic/releases/download/v0.26.1%2Bcubic.20260805/vllm-0.26.1%2Bcubic.20260805-cp38-abi3-linux_x86_64.whl'

以下是启动参数骨架；生产部署请以模型卡中的完整命令和当前运行时说明为准：

export CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
# 1：Dynamic A8；0：weight-only A16
export VLLM_CUBIC_DYNAMIC_A8=1
vllm serve /path/to/Kimi-K3-Cubic-2.5Bit \
  --served-model-name Kimi-K3-Cubic-2.5Bit \
  --trust-remote-code \
  --quantization cubic \
  --kv-cache-dtype fp8_q16 \
  --gpu-memory-utilization 0.985 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --mm-encoder-tp-mode data \
  --max-model-len auto \
  --max-num-seqs 128 \
  --max-num-batched-tokens 2048 \
  --enable-prefix-caching \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 8000

首次启动可能需要数分钟编译 Triton kernel、校准当前 GPU 和矩阵形状的 Cubic kernel，并捕获 CUDA Graph。校准结果会保存在 Triton cache 中，兼容环境下的后续启动可以复用。

fp8_q16 是 vLLM Cubic 提供的可选 KV Cache 模式，并不是 Cubic 权重量化本身。若更重视 KV 精度，可以使用 --kv-cache-dtype auto 回到 BF16 KV Cache，但可用上下文长度会下降。

应该怎样理解这次发布？

CubicQuant 的价值不只是“又一种低比特格式”，而是把表示、拟合与执行拆成了三个清晰层次：

表示层：整数 payload 保持规整，两个参数负责局部非均匀性；
拟合层：当前可以数据无关拟合，未来也能接入激活或二阶信息；
执行层：同一 checkpoint 同时支持 A16 与 Dynamic A8，并依据形状和设备选择 kernel。

这套设计也给出了明确的未完成项：

技术报告尚未给出完整的模型困惑度、推理、指令跟随、长上下文和多模态任务评测；
有限组实验只覆盖一个 group size，未形成 W1～W8 的完整模型级扫描；
物理性能证据目前以 H200 为主，不能直接外推到 Ampere、Ada 或 Blackwell；
低重建误差不自动等于更高的下游质量；
内核局部加速不自动等于端到端服务加速。

Kimi-K3-Cubic-2.5Bit 已经证明，CubicQuant 不只存在于公式里：它能以 1～8 bit 致密码流存储，能在 GPU tile 内直接重建并消费，也能承载一个 2.8T 级 MoE 模型的公开 checkpoint。

下一阶段更值得关注的问题，不再只是“能不能跑”，而是：在相同模型、并行拓扑、KV Cache、请求分布和硬件条件下，它能以多低的位宽守住多少模型能力，又能为真实服务带来多少容量与吞吐收益。

相关链接

ModelScope 模型：QuantTrio/Kimi-K3-Cubic-2.5Bit
CubicQuant 技术报告：arXiv:2608.06763
vLLM Cubic 运行时：QuantTrio/vllm-cubic
指定运行时版本：v0.26.1+cubic.20260805
Kimi K3 基座模型：moonshotai/Kimi-K3

说明：本文中的格式定义、分布实验和 H200 隔离 kernel 结论来自 CubicQuant 技术报告；模型位宽、文件规模、量化策略、参考部署与吞吐数据来自 Kimi-K3-Cubic-2.5Bit 模型卡及其随附量化审计文件。所有性能数字都应结合对应硬件、软件版本、输入输出长度和并发设置理解。