Kimi K3 开源｜2.8T 参数，首张 3T 级开放权重落地
Moonshot AI 把 Kimi K3 开源了，挂在 Hugging Face 上。总参数量 2.8T，激活参数 104B，MoE 架构，每个 token 选 16 个专家。这是目前公开材料里最大的开源权重之一，官方称之为「world's first open 3T-class model」。
K3 用了 Kimi Delta Attention（KDA）和 Attention Residuals（AttnRes），注意力层由 69 层 KDA 加 24 层 Gated MLA 组成，共 93 层。视觉编码器是 MoonViT-V2，401M 参数。上下文窗口标称 100 万 token。这些数字本身不新鲜，真正值得看的是它怎么落地——量化、推理引擎、Agent 工具链，以及和同级别闭源模型的对比。
量化：云端路线
量化走的是 MXFP4 权重加 MXFP8 激活，而且从 SFT 阶段就开始做 quantization-aware training。MXFP4 对消费级硬件不太友好，需要专门的 hardware 支持，Moonshot 选这条路更像是给云端推理和高端 GPU 集群准备的，而不是让个人开发者拿 RTX 4090 就跑。
这一点在下载数据上能看出端倪：Hugging Face 页面显示下载量 1,456,459，finetunes 36 个，quantizations 34 个。社区已经在接，但距离主流生态还有距离。
部署与工具链
官方推荐了三个推理引擎：vLLM、SGLang、TokenSpeed，各有 recipes。OpenAI 和 Anthropic 兼容的 API 已在 platform.kimi.ai 上线，选 kimi-k3 模型即可调用。
同时还有 Kimi Code CLI，作为专属 Agent 框架，/model 命令可以切换到 K3。Moonshot 在推的闭环比较清晰：API 给短平快的调用方，Kimi Code CLI 给需要 tool use、多轮、长上下文的开发场景。
Benchmark 表现
GPQA Diamond 上 K3 拿到 93.5%，和 Claude Fable 5 的 92.6%、GPT-5.6 Sol 的 94.1% 接近。不过 CritPt 只有 23.4%，DeepSWE 67.5% 也落后 GPT-5.6 Sol 的 73.0%。
Terminal-Bench 2.1 是 88.3%，和 GPT-5.6 Sol 的 88.8% 几乎持平。FrontierSWE 81.2% 明显落后 Claude Fable 5 的 86.6%，但 SWE-Marathon 42.0% 略高于 GPT-5.6 Sol 的 39.0%，也比 Claude Fable 5 的 35.0% 好看。
Agentic 能力
Agentic 赛道是 K3 的重点战场。BrowseComp 91.2%，DeepSearchQA F1 95.0%，AutomationBench 30.8%，JobBench 54.3%，AA-Briefcase Elo 1548，Harvey Lab-AA 94.6%。和 Claude Fable 5 相比，K3 在 BrowseComp 上接近，AutomationBench 和 JobBench 处于中游，Harvey Lab-AA 略低。OSWorld 2.0 是 58.3%，Claude Fable 5 是 66.1%。
整体看，K3 在 agentic 场景不是统治级的，但属于第一梯队，某些 benchmark 已经接近闭源最优。
视觉能力
WorldVQA 51.0% 低于 Claude Fable 5 的 56.7%，但 MMVU 82.1% 接近，MathVision 94.3/97.8% 和 GPT-5.6 Sol 的 95.8/97.8% 差距不大。整体视觉能力处于中等偏上，不是短板，但也不是最突出的点。
开源协议
K3 用的是 Kimi K3 License，和常见的 Apache 2.0 或 MIT 不一样，具体限制需要看 LICENSE 文件全文，材料里没有展开。这个选择本身说明 Moonshot 在保留商业化控制权——开源权重但不开放自由使用。
实际使用注意点
从实际使用角度，K3 有几个值得关注的特点。
thinking 是默认开启的，返回 reasoning_content，推理 effort 分 low/high/max 三档。多轮对话需要把完整的 assistant message（包含 reasoning_content 和 tool_calls）回传，这是 preserved thinking history 模式的硬性要求。
100 万 token 上下文在实际使用中需要配合 context compaction 策略。官方测试里 BrowseComp 在 300K token 触发压缩的情况下拿到 91.2%，全 100 万 window 无压缩是 90.4%，说明长上下文管理对 agentic 任务有实质影响。
下载量 145 万、36 个 finetune、34 个量化版本，说明社区已经动了。但 MXFP4 量化路线的落地门槛、开源协议的商业限制、以及和 Claude Fable 5 / GPT-5.6 Sol 在某些 benchmark 上的差距，都是实际部署前需要考量的点。
K3 适合需要 100 万 token 上下文、重度 tool use、长期 agent 任务的企业或开发者。希望开箱即用、对推理成本敏感、或者需要在消费级硬件上跑的个人用户，可能不太适合。