直接答案： 月之暗面于 2026 年 7 月 16 日发布了 Kimi K3，开源权重于当月晚些时候发布——一个 2.8 万亿参数的混合专家模型，激活参数 104B，上下文窗口 1M token，采用定制的 “Kimi K3 License”。模型卡自报的编程成绩接近闭源前沿模型。对于自托管 AI 编程平台的团队，这是一个有意义的新选项——但该许可证不是标准的 OSI 许可证，部署规模很大，基准数字也是厂商自报的。像评估任何其他模型一样评估它：在你的仓库里、跑你的任务、在你的边界之内。
发生了什么
月之暗面于 2026 年 7 月 16 日发布了 Kimi K3，并于 7 月底在 Hugging Face 发布了开源权重；路透社次日将其描述为迄今发布的最大开源权重模型。官方模型卡中的主要规格：
| 规格 | 模型卡数值 | 需要你自行核实的 |
|---|---|---|
| 总参数 | 2.8T（混合专家） | 在你的延迟目标下的实际服务成本 |
| 激活参数 | 每次前向 104B | 用你的服务栈时真实 GPU 显存占用 |
| 上下文窗口 | 1M token | 长上下文下的有效质量，而不只是最大值 |
| 量化 | MXFP4 量化感知训练 | 你实际会运行的量化产物的准确性 |
| 许可证 | 定制 “Kimi K3 License” | 商业使用、再分发和署名的确切条款 |
模型卡还报告了编程 agent 基准结果——包括 Terminal-Bench 2.1 和 SWE-Marathon 上接近闭源前沿模型的得分。这些数字是厂商自报的，与每次发布一样，应作为筛选证据而非适用性证明。
这对自托管编程平台为什么重要
开源权重发布改变了把代码保留在自己边界内的组织的选项空间。在平台层面管理模型的平台，原则上可以把有边界的编程任务路由到完全运行在组织自有基础设施上的模型——这正是自托管 MonkeyCode这类自托管 AI 开发平台的核心承诺。
在任何人更新采购文档之前，有三个务实的告诫：
- 许可证是定制的。 “开源权重”不同于 OSI 批准的开源。Kimi K3 License 必须由法务审查商业使用、再分发和任何使用限制——这与我们建议的AGPL-3.0 义务纪律相同。
- 规模是真实的。 一个 2.8T 参数、104B 激活参数的 MoE 不是工作站部署。服务经济学——GPU、显存、agent 级长上下文的吞吐——将主导总成本。用你自己的数字套用我们的自托管 TCO 估算器。
- 厂商分数只是起点。 Terminal-Bench 和 SWE 类分数用来筛选候选；它们预测不了你仓库里的接受率。运行你评估任何闭源模型都会跑的同一个验收测试试点。
如何不带滤镜地评估它
- 在代表性仓库中定义 10–20 个带书面验收标准的有边界任务。
- 对照你当前的默认模型比较验收结果、评审工作量与可复现性——而不是对照排行榜。
- 如果数据主权是驱动力，核验整条路径：权重托管、服务栈、日志与留存，而不只是模型文件的位置。
- 把许可证审查记录为显式关卡。法务团队无法批准的模型，就不是可用模型。
开源权重 vs 开源：采购中容易绊倒的区分
“开源权重”这个词在发布报道中被大量使用，它不是“开源”的同义词。OSI 批准的开源许可证（MIT、Apache-2.0、AGPL-3.0）授予使用、修改和再分发的清晰权利。而像 Kimi K3 License 这样的定制模型许可证是一份专项合同：它可能限制商业使用、施加使用上限、要求署名或排除某些用户类别。“开源”这个字眼本身不包含任何这些。
对自托管编程平台，这双重重要。平台自己的许可证（MonkeyCode 是 AGPL-3.0）和模型的许可证是两套独立的法律审查，一个宽松的平台许可证不会软化一个严格的模型许可证，反之亦然。把它们当作独立的关卡：
| 层 | 示例 | 审查问题 |
|---|---|---|
| 平台许可证 | AGPL-3.0（MonkeyCode） | 如果我们修改它或通过网络暴露它，我们的义务是什么？ |
| 模型许可证 | 定制 “Kimi K3 License” | 它是否允许我们在我们的规模下商业使用，且无禁止使用冲突？ |
| 服务栈 | 推理服务器、量化工具 | 这些组件的许可证与上述是否兼容？ |
三层中任何一层未通过法律审查，组合就不可部署——无论基准表看起来多强。
结论
Kimi K3 的意义与其说在于它的规模，不如说在于它释放的信号：接近前沿的编程能力如今正以组织可以自行托管的权重形式到来。对于受监管和数据主权受限的团队，问题从“我们能把一个有能力的模型放进边界内吗？“变成了”我们能经济地运行它吗，它的许可证能通过法律审查吗？“这两个问题都是可回答的——用你自己的试点回答，而不是用发布当天的数字。