前言¶

2026 年 7 月 27 日，Moonshot AI 在 Hugging Face 与 GitHub 同步发布了 Kimi K3 的全量模型权重与技术报告配套代码仓库。这是迄今公开可下载的、参数规模最大的开源权重模型之一——总参数量 2.8 万亿（2.8T），推理时激活约 1040 亿（104B），上下文窗口达 100 万 token。

在此之前，同等量级的模型几乎只存在于闭源 API 中。K3 的放出，让「开源权重能否追平闭源前沿」再次成为开发者社区的热点讨论。本文基于 MoonshotAI/Kimi-K3 官方仓库与 Hugging Face 模型页 核实关键信息，从架构、量化、评测到自托管部署逐一梳理。

Kimi K3 是什么¶

Kimi K3 是 Moonshot AI 的旗舰级原生多模态 Agent 模型，支持文本与图像输入，面向长周期编码、知识工作、推理与工具调用场景。官方将其定位为「世界上首个开放的 3T 级模型」（Open 3T-class model）。

与上一代 Kimi K2 系列相比，K3 的主要变化包括：

• 稀疏 MoE 规模大幅扩展（896 专家，每 token 激活 16 个）；
• 上下文从 K2.6 的约 25 万 token 扩展到 1048576 token；
• 引入 Kimi Delta Attention（KDA） 与 Attention Residuals（AttnRes），配合 Stable LatentMoE 框架，官方称相较 K2 整体 scaling 效率提升约 2.5 倍。

若暂时无法承担自托管成本，也可通过 Kimi API 调用 kimi-k3 模型。官方提供 OpenAI / Anthropic 兼容接口，定价为：缓存未命中输入 \(3 / 百万 token**，缓存命中 **\)0.30 / 百万 token，输出 $15 / 百万 token。

架构与关键参数¶

K3 采用 Mixture-of-Experts（MoE） 稀疏架构，核心规格如下（数据来自官方 README）：

KDA（Kimi Delta Attention） 是 Moonshot 为长上下文与大规模 MoE 设计的注意力机制。KDA 将 KV 缓存压缩为固定大小的状态向量，官方技术博客称在 128K 上下文下可将 KV 缓存占用降至标准 MLA 的约 1/16，在 1M token 场景下优势更明显。推理框架需实现 KDA 内核才能正确加载模型，因此不能直接用旧版 vLLM 跑通。

K3 默认始终开启 thinking 模式，API 会返回 reasoning_content 字段；多轮对话需将完整的 assistant 消息（含 reasoning 与 tool_calls）原样传回，这与普通 chat 模型的用法略有不同。

原生 MXFP4 量化¶

K3 从 SFT 阶段起 即采用量化感知训练（Quantization-Aware Training），最终以 MXFP4 权重 + MXFP8 激活 的形式发布。这是首个在该体量上以原生 4-bit 权重形式开源的主流模型。

MXFP4 的意义在于：在约 2.8T 参数量下，若按 4 bit/参数估算，纯权重数据约 1.4 TB 量级；实际 Hugging Face 上的 MXFP4 权重包体积约 594 GB 左右（含量化元数据与分片）。相比 FP16 全精度，下载与存储成本显著下降，但对 GPU 的低精度算力与推理框架支持提出了更高要求。

部署时需显式指定 --quantization mxfp4，并开启 --trust-remote-code 以加载 KDA 自定义算子。

编码与 Agent 评测表现¶

官方在 README 中公布了与 Claude Fable 5、GPT-5.6 Sol 等闭源模型的对比结果（K3 使用 reasoning_effort=max）。编码与 Agent 相关基准摘录如下：

可以看到，K3 在 Terminal-Bench 2.1、SWE-Marathon 等终端与长周期编码任务上表现突出，部分指标与闭源前沿模型互有胜负。需要留意的是：不同基准使用的 Agent harness 并不统一（Kimi Code、Codex、Claude Code 等），横向对比时应结合官方脚注理解，不宜简单得出「全面超越闭源」的结论。

社区讨论「开源追平闭源」，更多是指：在若干编码与 Agent 榜单上，K3 已具备与闭源旗舰同台竞技的能力，而非每一项基准均领先。

自托管推理：vLLM 部署要点¶

权重公开后，Moonshot 同步提供了 vLLM、SGLang、TokenSpeed 的部署指引。其中 vLLM 的正式 recipe 见 recipes.vllm.ai/moonshotai/Kimi-K3。

硬件门槛¶

这是 K3 自托管最需要正视的一点：它不是「单卡或八卡就能跑起来」的桌面级模型。

• 官方 vLLM recipe 建议至少 8× GB300，生产流量需多节点；
• Moonshot 文档推荐 64 及以上加速器 的超节点（Supernode）配置；
• ROCm 路径需 8× MI355X / MI350X 及对应 Docker 镜像。

即便 MXFP4 已将权重量压至约 594 GB，单张 H100（80 GB 显存）仍无法容纳完整模型；tensor parallel 与 expert parallel 跨节点分布式推理是常态。长上下文（如 1M token）还会额外占用大量 KV cache，实际部署时通常需将 max-model-len 从较小值（如 131072）起步，再按显存与吞吐需求逐步调高。

vLLM 启动示例¶

官方推荐使用 K3 专用 Docker 镜像 vllm/vllm-openai:kimi-k3（基于 CUDA 13，主机驱动需 r580+）。典型启动参数思路如下：

# 使用官方 K3 镜像（CUDA 13 / cu130）
docker pull vllm/vllm-openai:kimi-k3

# 单机 8 卡示例（具体参数以官方 recipe 为准）
python -m vllm.entrypoints.openai.api_server \
  --model moonshotai/Kimi-K3 \
  --trust-remote-code \
  --quantization mxfp4 \
  --tensor-parallel-size 8 \
  --max-model-len 131072 \
  --served-model-name kimi-k3

几点实践建议：

1. --trust-remote-code 必须开启，否则 KDA 自定义 CUDA 算子无法加载；
2. --quantization mxfp4 对应模型原生量化格式，Blackwell 硬件可直连硬件格式，H100/H200 上由框架模拟；
3. 多节点 MoE 通信：跨节点建议配置 --all2all-backend deepep_v2（RDMA）或 flashinfer_nvlink_one_sided（NVLink）；
4. 服务启动后暴露 OpenAI 兼容 API，现有 SDK 只需修改 base_url 即可接入。

若暂时不具备集群条件，可先通过 Kimi API 或第三方托管推理（如 Telnyx 等合作伙伴）体验，待硬件与运维能力就绪后再迁移至自托管。

开源许可与使用注意¶

K3 权重与代码仓库均采用 Kimi K3 License（自定义许可，非 OSI 标准开源协议）。根据社区对许可条款的解读：

• 研究与大多数商业用途可免费使用；
• 若作为 Model-as-a-Service 运营且 12 个月累计营收超过 2000 万美元，需另行签署商业协议；
• 产品 MAU 超 1 亿 或 MRR 超 2000 万美元 时，需在显著位置标注「Kimi K3」品牌。

下载权重前建议通读 LICENSE 文件，确认自身场景是否符合条款。

小结¶

Kimi K3 全量权重的释出，标志着开源模型首次在 3T 参数量级 上与闭源前沿正面交锋。MXFP4 原生量化、KDA 长上下文注意力、百万 token 窗口与多模态 Agent 能力，共同构成了其技术标签；而 594 GB 级权重 + 64 卡超节点推荐配置，也清晰划定了「能下载」与「能自建 serving」之间的鸿沟。

对绝大多数开发者而言，更现实的路径是：先用 API 验证业务场景，再评估集群成本与合规要求，最后决定是否自托管。无论如何，K3 的发布为开源生态提供了可复现、可审计的 frontier 级基线，后续微调、蒸馏与垂直领域适配的工作值得持续关注。