Kimi-K3.1-Pro-Coder压缩至775GB，三级卸载让单卡跑2.8T MoE

摘要：独立开发者 Grawnch 将 2.8 万亿参数 Kimi-K3.1-Pro-Coder 的路由专家按访问热度分成三档量化，平均降至约 1.92 bpw，并通过 Strata 三级缓存和路由前瞻预取在单张 RTX PRO 6000 Blackwell 上完成推理。模型体积由 1.77TB 降至 775GB，批量吞吐 36.8 tok/s、单流解码 10.8 tok/s；AIME 2025 与 LiveCodeBench 均报告 29/30，但结果主要来自作者自测，仍需独立复现。

---

2.8T 模型如何压进 775GB

Grawnch 发布的 Kimi-K3.1-Pro-Coder 量化版本把 2.8T 参数模型的存储需求从约 1.77TB 降至 775GB，压缩幅度约 56%。项目同时开放 96 个权重分片、Strata 调度器和 dr-triton 反量化内核。

其核心思路不是对整个模型统一施加低比特量化，而是利用 MoE 专家访问频率的稀疏性，把每层的 384 个路由专家分为三个量化档位：2.81、2.56 和 1.44 bpw，路由专家平均约 1.92 bpw。共享专家、注意力层和嵌入层仍保留 BF16/F32，从而减少对模型主干精度的破坏。

不过，775GB 并不是普通桌面用户可以忽略的成本。模型仍需要至少约 775GB 下载空间、大容量内存和高速 NVMe；所谓“单卡运行”依赖 CPU 内存与 SSD 共同承载权重，而不是模型完整驻留显存。

三级卸载如何绕开 PCIe 瓶颈

Strata 将专家权重按访问温度放入三个层级：

• Tier 1：高频专家常驻 GPU VRAM；
• Tier 2：温热专家固定在 pinned RAM；
• Tier 3：低频专家通过 NVMe mmap 按需读取。

真正决定性能的不是层数本身，而是能否在路由决策之后、执行专家计算之前完成数据搬运。Strata 使用 router lookahead prefetching，根据后续路由信息提前拉取冷专家，作者报告有效命中率为 97.9%。

但这一数字不能直接等同于端到端命中率。路由预测错误的专家仍可能造成无效 PCIe/NVMe I/O，而高层路由决策与低层专家预取之间也可能存在时序错位。真实性能因此还取决于 SSD 随机读取、NUMA 拓扑、PCIe 带宽、内存带宽和批量大小。

dr-triton 把反量化留在 GPU 侧

若在 CPU 端先把压缩权重展开成 BF16，再经 PCIe 传输，传输量会显著放大。dr-triton 使用融合 Triton 内核，让权重以压缩格式穿过 PCIe，仅在 GPU SRAM 中执行反量化。

这种设计减少了主机内存占用和总线流量，但代价是每次专家加载都需要额外反量化计算，并且必须为不同量化格式编写专用内核。对于算力紧张的消费级 GPU，I/O 节省未必总能抵消 kernel launch、反量化与临时缓冲区带来的开销。

精度与基准结果

作者对全部 93 层及 lm_head 进行了对比：

| 指标 | 1.77TB 基础版 | 775GB 量化版 | 变化 | |---|---:|---:|---:| | AIME 2025，Pass@1 | 29/30 | 29/30 | 完全一致 | | LiveCodeBench，30 题 | 29/30 | 29/30 | 完全一致 | | Top-1 Token 一致率 | 100% | 95.20% | 下降 4.80 个百分点 | | Top-5 Token 一致率 | 100% | 99.92% | 下降 0.08 个百分点 | | AIME 2025 PPL | 2.2135 | 2.2358 | +1.01% | | LiveCodeBench Hard PPL | 2.1136 | 2.1562 | +2.02% | | LiveCodeBench Overall PPL | 2.6911 | 2.7629 | +2.67% |

AIME 和 LiveCodeBench 的表面得分没有下降，但 Top-1 一致率降至 95.20%，说明模型在部分题目上的内部生成路径已经改变，只是恰好仍给出了相同答案。30 道题的样本也很小，29/30 与 29/30 相同不能证明所有任务上无损。

LiveCodeBench 窗口只覆盖 10 道简单题、10 道中等题和 10 道难题，缺少完整滚动窗口、采样参数和运行脚本细节，也未给出多次运行的置信区间。因此，这些成绩更适合作为压力测试结果，而不是严格的模型等价性证明。

单 Blackwell 实测表现

作者使用单张 RTX PRO 6000 Blackwell（96GB）+ 176GB RAM，在 Colab 环境中报告：

• 批量或 Prefill 评测吞吐：36.8 tok/s；
• 单流解码吞吐：10.8 tok/s。

其余配置多为作者估算而非实测。例如，24–32GB RTX 4090/5090 搭配 128GB DDR5 和 Gen4 NVMe 的估算为批量 11–14 tok/s、单流 4–5.5 tok/s；双卡配置估算可达到 18–22 tok/s 单流解码。这些数字可用于理解分层容量趋势，但不宜作为采购或容量规划依据。

批量吞吐与单流解码也存在明显区别。评测模式可以通过更大的批处理窗口摊薄专家加载成本，而真实交互更依赖每个请求的首 Token 延迟和抖动。即使平均 TPS 较高，NVMe 尾延迟仍可能让交互体验不稳定。

开发者如何落地

项目提供了三个主要入口：

1. Hugging Face 上的 775GB、96 分片权重；
2. Strata 三级卸载与前瞻预取引擎；
3. dr-triton 融合反量化内核。

用户可以按机器条件重新配置 VRAM、RAM 与 NVMe 的容量比例。512GB DDR5 机器可以将更多冷专家固定在内存中；24–32GB 显卡则必须缩小 Tier 1，并增加 RAM 与 NVMe 压力。

权重采用自定义 packed tensor layout，不能直接交给原生 llama.cpp 或 vLLM 运行。拥有自有 PyTorch/Triton 推理框架的团队，可以导入 dr-triton 与 strata_coder 反量化模块，自行管理放置和调度；否则需要使用 Strata。

部署前应至少验证四组指标：实际路由分布下的专家命中率、首 Token 延迟与 P99 延迟、冷启动 I/O 时间，以及真实代码仓库上的多轮任务成功率。若目标是生产服务，仅凭 30 题基准不足以判断量化模型能否替代原始权重。

工程价值与边界

这项工作的主要贡献是把超大 MoE 的压缩粒度与运行时热度耦合：不再让全部专家承担相同的位宽，而是让常驻 GPU 的专家保持较高精度、较冷专家使用更激进压缩，并通过预测性 I/O 隐藏存储延迟。

它也清楚展示了这条路线尚未解决的问题。775GB 权重对多数个人开发者仍不现实；单流 10.8 tok/s 虽可用于代码辅助，但体验明显受限于等待时间；平均 KLD、Top-1 一致率和 PPL 变化则表明量化并非完全无损。更关键的是，所有结果来自作者自报环境，跨 NVMe、内存容量、CUDA/Triton 版本和模型路由分布的泛化仍待独立复现。

---

消息来源：Reddit r/LocalLLaMA (2026-11-08)

—— 完 ——

主题标签： #Kimi-K3.1-Pro-Coder 关注 #MoE量化 关注 #三级卸载 关注 #Triton 关注 #单GPU推理 关注