7 月 27 日晚九点半，月之暗面把 Kimi K3 的完整权重推上了 HuggingFace。96 个分片。我按官方文件清单，把每个分片的字节数挨个加了一遍，得到 1,560,936,091,448 字节，约 1.56 TB——这个数你可以自己复算，把仓库文件列表里那 96 个 safetensors 的 size 加起来就是。后来我发现，两位社区开发者也各自算了一遍，结果一模一样。
社区的动作非常快。权重落地 1 小时 46 分，第一个转制版本就出来了；15 小时内出了十四个版本，GGUF、NVFP4、MLX、剪枝，能想到的路子都有人在试。
然后我把里面做得最认真的两个版本逐字读完，看到的不是开源盛事，而是两张写得明明白白的失败记录。
先把话说清楚，免得后面误会：跑不动的不是 K3 本身，它在官方推荐的配置上跑得好好的。跑不起来的，是社区想把它塞进单机的这条路。 这一整篇讲的都是后者。
527 GB 做完了，没有人加载过
第一个是 1.5 bit 量化版。从 1453.8 GiB 的官方源文件压到 527.48 GiB，94 个分片，等效 1.63 bpw。这活儿干得很扎实，作者连权重空间的重建误差都算了，比常规四位量化掉了一截。
说明页最上面是一行红字：这个文件在任何已发布版本的 llama.cpp 上都加载不了。支持 K3 的代码，目前还是一个没合并的 PR。
作者自己列了张验证状态表，「能否加载」那一栏写着：未验证，到目前为止还没有人加载过。
更麻烦的还在后头。IQ1_S 这种极低比特量化通常需要一份重要性矩阵来指导，不然出来的东西，用 llama.cpp 自己的话说，就是垃圾。而这份矩阵根本生成不了——要生成它，得先把模型跑起来，可模型跑不起来。
一个技术底子很硬、态度极其克制的开发者，花大力气做完了 527 GB 的转换，最后在首页老老实实写下「没人加载过」。这比任何唱衰都更有说服力。
社区 1.5bit 量化版 model card。来源：HuggingFace GrEarl/Kimi-K3-GGUF-IQ1_S，2026-07-28 截图
剪掉七成专家塞进 Mac，0.16 字每秒
第二个更狠。作者开场一句话就交代了他为什么动手：没有任何一台 Mac 装得下未剪枝的 Kimi K3。整个模型 1.56 TB，就算压到 2 bit 也还有约 870 GB，而顶配 Mac 的天花板是 512 GB。
他用了 Cerebras 的 REAP 剪枝方法，92 个 MoE 层里，每层从 896 个专家中只保留 242 个。模型从两万七千多亿参数砍到 7930 亿，451 GB。塞进一台 512 GiB 的 M3 Ultra，加载花了 66 秒，峰值占用 451 GB。
这个跑起来了。速度是 0.16 token/秒。
他在这串数字后面紧跟着写了一句：不是笔误，也没法交互。
「读这个再下载」——作者把速度写在了最显眼的地方。来源：HuggingFace pipenetwork/Kimi-K3-REAP73-MLX-mxfp4-q8，2026-07-28 截图
更值钱的是他后面那段分析。每解码一个 token，要从内存里读大约 87 GB 的权重。其中 25.8 GB 是被路由到的专家，剩下 60.8 GB 是每个 token 都必须碰一遍的非专家权重。这部分只占大约 2% 的参数量，却吃掉了每个 token 的大部分带宽。他又做了一个更激进的 350 GB 版本验证，0.20 token/秒——速度收益基本只跟体积走。
结论是他自己下的：在这个硬件上，没有任何剪枝比例能让 K3 变成可交互的。
这句话一下子关掉了很多人的幻想。剪得更狠不是出路，因为瓶颈根本不在专家上。
他还差点踩了一个坑，值得所有做量化的人记住：早期用 C4 的多语言配置做校准，中日韩文字只占语料的 0.03%，按他自己的判断，这本来会悄无声息地把负责处理中文的专家剪掉。他后来换成刻意配比的 12.6 MB 语料，才绕开了这件事。
门槛就摆在那儿，一寸没让
上面两个案例里所有的退化和不可用，都是压缩和剪枝付出的代价。剪枝版中文会退化成重复循环，那是 6.6% 密度的激进剪枝造成的，作者自己也写明了「预期会有明显退化」。
官方那边的口径很清楚。vLLM 的官方配方是八卡起步，它给出的参考启动命令直接写着张量并行 16、节点数 2——两台八卡机连起来，才是那条命令跑得动的样子；官方博客推荐的生产配置则是 64 个及以上加速器的 supernode。这两个数不矛盾，一个是能开机的下限，一个是真干活时的建议。
官方推理栈给出的部署门槛。来源：vLLM Recipes，2026-07-28 截图
还有一个容易被忽略的细节：官方放出来的权重本身就已经是量化版了，MXFP4 权重配 MXFP8 激活，而且是从 SFT 阶段就开始做的量化感知训练。这意味着，不存在一个精度更高的 K3 可以拿来对比，也意味着 1.56 TB 已经是压缩之后的数字了。社区想再往下压，是在一个已经压过的东西上继续压。
这一屏基本就是「开放权重」的全部内容：权重分片 + 推理代码 + 一份自定义许可，没有训练代码、没有训练数据。来源：HuggingFace moonshotai/Kimi-K3，2026-07-28 截图
那这次开放，到底是给谁的
它是给那些最低也得凑出 8 张顶级加速器、生产上还得往 64 张走的人的——云厂商、有自己机房的大企业、国家级或校级研究机构。对他们来说，这次开放的价值是实的：能本地部署，能在自己的数据上微调，敏感数据不必交给别人的 API，还能拿它去蒸馏小模型。许可证全文我读了一遍，没有任何一条禁止用它或它的输出去训练别的模型，这点你可以放心。
如果你是个人开发者，或者几个人的小团队，得把预期调一调。这里有个时间上的对照，我觉得比任何评论都说明问题：权重落地之后 2 小时 4 分，仓库里就合进了一个开启推理服务商的标记，Together、Fireworks、Featherless 三家先后 live——通往「你花钱买 API」那条路，两小时就修通了。而通往「你自己跑」那条路，一天之后还停在 0.16 token/秒。
所以你实际得到的，是多了几家可以选的供应商，而不是一个能自己攥在手里的模型。这跟「我能自己跑」，是两件完全不同的事。
社区自己把这件事说得比我清楚。GitHub 上第一波 issue 里，有人问「能不能出个 27B 或者 70B 的」，正文只多加了一句：「让普通人也能用得上啊。」HuggingFace 讨论区里，有人开帖问「我说我能在家里把这家伙运行起来，你们信吗」，有人在张罗众筹部署全量版本，还有人挂着 48G 显存说也想玩。其中一个帖子的标题，等于一句话把我想说的讲完了：A great model for “a few people”。
顺便说一句边界：这次给的是权重加推理代码，训练那套没给。够你跑、够你微调，不够你从头造一个。许可证里写了包含训练代码，实际发出来的东西里却没有——权利写得比货多。
下次看到「某模型开源了」
免费的是权重，贵的是让它开口说话。这句话我建议你记住，能省不少时间。
具体一点，公告里有两个地方比通稿正文有信息量得多。一个是官方推荐部署配置写在哪一行——那一句基本就框定了这次开放跟你有没有关系。另一个是社区衍生版的说明页，尤其是那些自称跑通了的，去看他们贴出来的实测速度和失败案例。那是最不会骗人的地方，也是这次我能写出这篇的全部原因。
Kimi K3 这次的开放是件好事，只是受益的人比大多数人想的窄。这件事本身没什么可失望的，该改的是我们一看到「开源」就默认「我也能用」的这个反射。
主要来源
- 月之暗面 Kimi K3 官方模型仓库与许可证全文（HuggingFace / GitHub，2026-07-28 查阅）
- 月之暗面 Kimi K3 官方发布博客（含部署配置建议）
- Kimi K3 技术报告（arXiv，2026-07-27）
- vLLM 官方 Recipes 的 Kimi-K3 部署配方页（2026-07-28 查阅）
- 社区衍生版说明页两份：GrEarl 的 1.5bit GGUF 量化版、pipenetwork 的 REAP 剪枝 MLX 版（均建于 2026-07-27）
- HuggingFace 与 GitHub 上的公开讨论与 issue（2026-07-28）
文中权重体积 1,560,936,091,448 字节为按官方文件清单 96 个分片逐项累加所得，可自行复算； 两位社区开发者独立给出的 1,453.8 GiB 与 1.56 TB 与此一致。