prometheusAIR/Kimi-K3-REAP55-GGUF · Hugging Face

来源：https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#kimi-k3-reap55-iq1_m-ggufKimi-K3-REAP55-IQ1_M-GGUF

Kimi-K3 (2.8T-A104B) 移除 55% 的专家，然后量化至约 2.15 bpw —— 319 GiB。

REAP 专家剪枝（每层从 896 个专家→400个，所有 92 个 MoE 层），然后对 gate/up 进行 iq1\_m 量化、对 down 进行 iq2\_xxs 量化，并使用自建的 imatrix。稠密权重为 q8\_0。

这是目前已知可运行的最小 Kimi-K3 GGUF 版本。高度实验性，主要用于对比。专门构建以避开 iq1\_s / iq2\_s / iq3\_s 张量类型，这些类型在 sm_120（RTX PRO 6000 Blackwell、RTX 50 系列）上会导致 CUDA matmul 损坏并静默产生垃圾数据。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#requires-llamacpp-pr-26185需要 llama.cpp PR #26185

Kimi-K3 支持未包含在任何 llama.cpp 发行版中。你需要 PR #26185 (https://github.com/ggml-org/llama.cpp/pull/26185)（kimi-k3 架构）。没有它，这里的一切都无法工作。

已知聊天解析器问题

llama.cpp 的自动解析器通过对模板渲染进行 diff 来推导分隔符，并选取最短的区分字符串。对于 XTML，它得到了 <|sep|> 和 <|close|> —— 两者都出现在每个通道中。因此，推理在第一个孤立的 <|close|> 处终止，剩余的框架内容被当作内容处理。修复方法是使用一个专用的处理器来匹配完整的通道标签，根据 <|open|>think<|sep|> + <|open|>response<|sep|> 进行调度，遵循 llama.cpp 已经用于 GPT-OSS 通道格式的相同模式。它还会连接工具调用 —— 目前未经测试，而且几乎肯定由于同样的歧义问题而无法正常工作。

llama.cpp 的解析器修复

你必须应用此处包含的小补丁（kimi-k3-chat-parser.patch）。请参见下面的“构建 llama.cpp”。如果该架构将来被上游合并，此要求将不再存在。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#running-it运行方法

llama-server \ --model Kimi-K3-REAP55-IQ1_M-00001-of-00008.gguf \ -ngl 99 -ot "ffn_.*_exps=CPU" --no-repack \ -c 32768 -ctk f16 -ctv f16 \ -b 8192 -ub 8192 \ --threads 8 --fit off --jinja

其中四个参数并非显而易见，每个都是通过实测得出，而非猜测：

• --no-repack 是必需的。 没有它，CPU 后端会声明专家张量用于其 repack 缓冲区，并尝试在 RAM 中分配整个池；加载会失败并显示 failed to allocate CPU_REPACK buffer of size ...。
• -ngl 99，绝不能是部分值。 llama.cpp 会卸载最后 N 层（i_gpu_start = n_layer + 1 - ngl），因此任何部分 -ngl 都会将第 0 层放在 CPU 上——而第 0 层是 K3 的唯一稠密层，承载着融合的 Gated Delta Net 操作。结果是在提示处理看似成功后，在 ggml-cuda.cu 中硬崩溃。GGML_CUDA_DISABLE_GRAPHS=1 也无济于事。这个设置之所以有效，是因为 q8_0 稠密层只有约 55 GiB。
• -ub 8192 比默认值快约 5 倍（在磁盘流式传输配置下）。每个 ubatch 基本上会拉取所有专家，因此每次都会对专家池进行一次完整的扫描——你希望扫描次数越少越好。在 5099 个令牌的提示上测量：-ub 512 = 1383 秒，-ub 8192 = 274 秒。这正好与通常的 VRAM 驻留直觉相反。
• --threads 8，不要更多。 这里的预填充受内存带宽限制，而非核心数限制。在 16 核/32 线程的部件上，8 线程比 12 线程快 11.7%，而 30 线程比 12 线程慢。调整到你的聚合内存带宽峰值即可。

保持 mmap 开启（不要传递 --no-mmap）—— 专家池设计上从磁盘流式传输。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#hardware-note–the-speeds-above-are-storage-bound-not-model-bound硬件说明 —— 上述速度受存储限制，而非模型限制

硬件配置：RTX PRO 6000 Blackwell（96 GB）、Ryzen 9 9950X3D（16c/32t）、125 GiB DDR5、2× Samsung 9100 PRO Gen5 NVMe RAID0。

稠密权重位于 GPU 上；262 GiB 的专家池通过页面缓存从 NVMe 流式传输。由于只有 125 GiB 的 RAM，大约只有 42% 的池可以缓存，因此解码速度由存储和页面缓存提供专家权重的速度决定，而非 GPU。后果：

• 热态 ≠ 冷态。 持续工作会使池保持热态，达到约 0.48 tok/s；加载后的第一个请求约为 0.32。两者都是真实的，只是度量不同。
• 更多 RAM 比更快的 GPU 更有帮助。 如果专家池能完全放入页面缓存，解码将受 RAM 带宽限制，速度应该会快几倍。
• 解码随上下文长度保持平稳—— 从 4K 到 64K 均约为 0.43–0.51 tok/s，没有下降，因为成本在于流式传输专家而非注意力。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#what-was-pruned-and-what-that-costs-you剪枝了什么，以及对你的代价

REAP（REAP the Experts: Why Pruning Prevails for One-Shot MoE Compression (https://arxiv.org/abs/2510.13999)，Cerebras）通过对校准集上的 gate x ||expert_output|| 进行评分，并保留得分最高的专家。显著性是在 264,141 个令牌上测量的，使用了一个专门构建的工具，该工具直接钩入 llama.cpp 的计算图，因此无需 PyTorch 流水线或原始的 safetensors 文件。

校准语料库刻意狭窄—— 大约 33% 代码、28% 技术散文、20% 工具调用/智能体轨迹、20% 长上下文——并且完全去除了多语言内容。

校准语料库未充分代表的内容会被静默剪枝掉。 预计此版本在多语言任务以及远离代码、技术英语、推理和工具使用的领域上比完整模型弱。如果你需要宽广的覆盖范围，请使用未剪枝的量化版本。

每个样本都通过 K3 的真实聊天模板（包含填充的思考通道）进行渲染，因此专家是根据模型实际运行的聊天+推理分布而非原始文本进行评分的。

上下文中的剪枝深度：Cerebras 验证了约 30-50% 的剪枝可达到近乎持平的性能；在 Qwen3-480B-Coder 上以 50% 剪枝保留了 97.6% 的编码能力。此版本为 55%，刚好超出那个范围，因此它是面向特定领域而非通用型。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#validation验证

• 普查：2573 个张量，276 个专家张量对应 400 个槽位，专家参数精确为 276 x 11,010,048 x 400，零 sm_120 损坏类型。
• Imatrix 覆盖：全部 92 层的所有 400 个保留专家都收到了激活（最少 225，平均 10,813）——没有专家被盲目量化。
• 大海捞针：在 4K/8K/16K/32K/64K x 深度 0.15/0.5/0.85 下，15/15 精确检索。
• 推理抽查：正确的算术运算并自我验证，且自然终止而非到达令牌上限。

未测试：多语言、端到端工具调用、超过 64K 的上下文（1M 需要仅 KV 就需要 28 GiB），以及任何标准基准套件。不引用困惑度，因为唯一测量的语料库是我们自己的校准集，这会偏向于针对它剪枝的模型。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#known-issues已知问题

• XTML 标记泄漏到 content 中（<|open|>think<|sep|>、<|close|>response<|sep|>）。这是上游解析器的空白，在未剪枝模型上也可复现——并非此版本的缺陷。
• K3 始终在思考，且尚无推理预算控制，因此请为完成分配宽裕的预算，否则答案会在推理块内被截断。应用附带的补丁可临时修复

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#provenance来源

从原生的 MXFP4-QAT 发行版转换而来。路由专家以 MXFP4 形式提供，因此转换为 GGUF 是一种无损的字节重打包——此版本源自全精度主模型，而非来自重新量化的中间结果。剪枝是在 GGUF 空间中通过对专家维度进行切片完成的，该维度是最外层的，因此每个专家是连续的，所以存活的专家是字节精确的副本。

根据Kimi-K3 许可证 (https://huggingface.co/moonshotai/Kimi-K3) 授权，继承自基础模型。

https://huggingface.co/prometheusAIR/Kimi-K3-REAP55-GGUF#building-llamacpp构建 llama.cpp

补丁针对上游主分支 cf11c4c05（2026-07-27）生成，已验证可干净应用且零错误编译。附近的主分支应能轻微模糊匹配。

`` git clone https://github.com/ggml-org/llama.cpp cd llama.cpp git checkout cf11c4c05 git apply /path/to/kimi-k3-chat-parser.patch

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 # 120 = Blackwell; 请根据你的 GPU 设置 cmake –build build –target llama-server -j ``