Kimi K3.1 Pro 开放权重：下载、许可证与 API 怎么选？
Kimi K3.1 Pro 官方权重已在 Hugging Face 开放下载。本文介绍 2.8T 总参数、104B 激活参数的 MoE 架构、约 1.56 TB 的模型文件、自定义许可证的收入门槛及豁免条件，以及针对不同硬件的部署方案。提供固定版本下载与文件校验命令、最小 API 请求示例，并说明如何比较自托管与 API 的运营成本。104B 激活参数不等于完整模型的存储或显存需求。
本文内容
Kimi K3.1 Pro 的模型权重已在 Moonshot AI 官方 Hugging Face 仓库开放下载。开发者可以先通过托管 API 测试编码任务；只有当业务确实需要控制模型权重和推理环境时，再评估自托管的硬件成本与许可证要求。需要注意，104B 激活参数不代表完整模型的文件大小，也不能直接用来估算显存需求。
截至 2026-11-11，官方仓库已包含模型检查点、配置文件和自定义许可证。实际需要决定的是：自己部署这套权重，还是通过 API 购买推理服务。
Kimi K3.1 Pro 开放权重包含什么？
这次发布的是 Kimi K3.1 Pro 的实际模型检查点，而不只是一个可调用的 API 模型名称。Moonshot 在技术公告中介绍，这是一款基于 Kimi K3、经过跨领域联合强化学习后训练的多模态模型。
官方模型卡公布了以下规格。精确的上下文限制也可以在 Kimi API 定价文档中确认。
| 项目 | 官方公布的规格 |
|---|---|
| Hugging Face 仓库 | moonshotai/Kimi-K3.1-Pro |
| 模型架构 | Mixture-of-Experts（MoE，混合专家架构） |
| 总参数量 | 2.8T |
| 激活参数量 | 104B |
| 上下文窗口 | 1,048,576 tokens |
| 许可证 | 自定义 Kimi K3.1-Pro License |
MoE 模型处理每个 token 时，只激活部分参数。但未被激活的专家网络仍然保存在模型检查点中。因此，规划存储空间时应查看实际文件大小，不能只根据 104B 激活参数估算。
仓库文件列表显示，整个仓库约为 1.56 TB，权重分片文件名以 of-000096.safetensors 结尾。模型配置采用 mxfp4-pack-quantized 格式。vLLM 部署指南进一步说明，路由专家的权重使用 MXFP4，其余权重使用 BF16。
对于编码团队，开放权重带来的是更多部署选择，并不意味着下载后就能得到一个完整的编码 Agent。推理引擎和 Agent 客户端仍需要分别选择。在迁移现有工作流之前，应验证仓库文件读取、工具执行，以及实际任务的验收测试。
Moonshot 的 API 快速入门文档还列出了托管版本 kimi-k3.1-pro-highspeed。其速度表现属于托管服务的能力说明，不能认为下载相同权重后就能在自己的硬件上达到同样的性能。
Kimi K3.1 Pro 许可证有哪些限制？
Kimi K3.1-Pro License允许在满足许可证条件的前提下进行商业使用。不过，部署前应分别检查 MaaS 收入门槛、产品名称展示要求以及适用的豁免条件。
以下是面向开发者的条款解读，不构成针对具体业务的法律意见。
MaaS：按连续 12 个月的总收入判断
许可证第 2 条针对的是许可证持有人或其关联公司经营 Model as a Service（MaaS，模型即服务）业务的情况。
如果许可证持有人及其关联公司的合计收入，在任意连续 12 个月内超过 $20 million，就必须与 Moonshot AI 另行签订协议，才能将该软件或其衍生作品用于商业目的。
这里有两个容易误解的地方。
首先，收入范围是许可证持有人及其关联公司的合计收入，而不是仅计算 Kimi K3.1 Pro 产生的收入，也不是仅计算 MaaS 业务收入。
其次，满足上述条件时，需要在商业使用软件或其衍生作品之前签订单独协议，而不是达到门槛后再处理。
许可证对 MaaS 还有具体定义：向第三方开放语言模型推理或微调能力，并允许第三方对输入、参数或训练数据进行实质性控制。
这一界定存在两类排除情况：
- 模型能力仅嵌入特定产品功能或执行框架（harness）中的终端用户产品。
- 仅将请求转发给其他运营方所托管模型的服务。
因此，不应简单地把所有集成模型 API 的应用都认定为 MaaS，也不能认为所有面向终端用户的 AI 应用都自动获得豁免。实际业务是否符合排除条件，应由法律专业人士结合服务形态判断。
品牌展示：按产品的月活和月收入判断
许可证第 3 条针对使用该软件或其衍生作品的商业产品和服务。
当相关产品或服务满足以下任意一项条件时，必须在其用户界面中显著展示 Kimi K3.1-Pro：
- 月活跃用户数超过 100 million。
- 月收入超过 $20 million。
这里使用的是月活跃用户数（MAU），不是日活跃用户数（DAU）。
收入统计周期也不同于 MaaS 条款：品牌展示条件考察的是一个月的收入，而不是连续 12 个月的合计收入。
因此，评估许可证时需要分别检查这两套门槛，不能混为一谈。
哪些情况适用豁免？
许可证第 4 条明确，以下使用方式不受第 2 条和第 3 条要求约束：
- 内部使用。
- 通过 Moonshot AI 官方产品访问软件。
- 通过 Moonshot AI 认证的推理合作伙伴访问软件。
其中，内部使用有明确边界：不得向第三方提供软件本身、软件输出或软件底层能力。
需要特别区分 API 兼容性与合作伙伴认证。一个网关能够调用 Kimi 模型，并不意味着它已获得 Moonshot AI 的认证推理合作伙伴身份，也不能据此认定其适用许可证豁免。
上述豁免仅涉及第 2 条和第 3 条，并不代表可以忽略许可证的其他要求。复制或分发软件时，还需要保留规定的版权声明和许可声明，并分别检查所用服务提供商的条款。
如何下载并验证 Kimi K3.1 Pro 权重？
建议先下载许可证和配置文件，确认容量与许可条件，再下载完整模型。提前准备好足够空间的文件系统，并按照 Hugging Face CLI 安装说明安装当前版本的 hf CLI。
下面使用 Bash，并固定到 2026-11-11 已检查的仓库版本。这样可以避免下载过程中因仓库内容更新而产生版本混用。
KIMI_REPO="moonshotai/Kimi-K3.1-Pro"
KIMI_REV="d9e99b0792a5e93b78ea9bea62a68167e36ddd9e"
KIMI_DIR="$PWD/kimi-k3.1-pro"
hf download "$KIMI_REPO" README.md LICENSE config.json \
--revision "$KIMI_REV" --local-dir "$KIMI_DIR"
hf download "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" --dry-run第一条下载命令只获取 README.md、LICENSE 和 config.json，方便先检查模型和许可证信息。
第二条命令通过 --dry-run 预览完整下载需求。Hugging Face 下载文档说明，该模式会列出仍需下载的文件及其大小，而不会实际传输模型权重。
请注意，仓库显示的 1.56 TB 并不是整个部署环境所需的全部存储空间。还要为下载缓存、推理引擎的工作文件等预留容量。
确认许可证和存储容量满足要求后，在同一个 Bash 会话中执行：
hf download "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" &&
hf cache verify "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" --fail-on-missing-files这里先下载固定版本的完整文件，再执行校验。
Hugging Face 的文件验证命令会将本地文件与 Hub 上的校验和进行比对。--fail-on-missing-files 还会检测仓库文件是否下载完整。
只有在没有缺失文件、没有校验和不匹配，并且验证成功时，才继续部署。
需要注意，文件验证成功不等于模型能够正常推理。它只能证明本地文件与指定仓库版本一致，不能证明推理引擎和硬件兼容。
如果发现校验和不一致，可以针对报告中的文件，使用相同版本和 --force-download 参数重新执行 hf download。重新下载后，应再次验证，再启动推理服务。
自托管需要什么硬件？
Kimi K3.1 Pro 应按照特定硬件和推理引擎的部署方案运行，不应将其当作能够直接放进普通工作站的 104B 模型。
截至 2026-11-11，vLLM 部署指南给出一个基于八张 NVIDIA GPU 的参考配置：两个 GB300 tray，或者一个 B300 node。
这里的八卡配置是文档提供的基准部署方案，不代表所有环境的最低硬件要求，也不保证特定吞吐量。
vLLM 文档还说明，该基准配置尚未针对吞吐量进行调优。因此，应优先按照针对 Kimi K3.1 Pro 的专用部署指南操作，而不是直接套用通用的模型启动命令。
另一个选择是 SGLang 部署指南。文档指出，该模型使用 kimi-k3.1-day-0 分支，并区分已经验证的配置和仍在验证中的配置。
如果团队准备采购硬件，建议先选定一套文档明确支持的配置进行试验：
- 记录推理引擎版本、镜像 digest 和模型检查点版本。
- 先执行短请求，确认模型能完成推理。
- 分别提高上下文长度和并发请求数，避免同时改变多个条件。
- 记录运行内存、首 token 延迟和每个完成任务的成本。
官方标称的上下文窗口，并不能保证模型在任意并发配置下都有足够的运行内存。
与 API 进行比较时，还应固定 Agent 客户端、工具配置、推理档位和验收测试，避免把测试条件的差异误认为模型部署方式的差异。
如果需要控制检查点、定制模型或管理推理环境，自托管更值得评估。如果团队缺少集群运维能力，或者无法充分利用昂贵的计算资源，自托管的优势就会下降。
制定预算前，可以参考自托管模型成本核算清单，避免简单地将 API 账单与 GPU 采购价格作比较。
如何先通过 API 测试 Kimi K3.1 Pro？
在购买硬件之前，可以先使用 kimi-k3.1-pro 执行一个简单的编码请求。
注意区分 API 模型 ID 与 Hugging Face 仓库名称。两者不是同一个标识符。
以下接入路径已于 2026-11-11 核对：
| 接入方式 | Model ID | OpenAI 兼容 Base URL | 身份验证 |
|---|---|---|---|
| Moonshot API | kimi-k3.1-pro | https://api.moonshot.ai/v1 | 自己的 Moonshot API Key |
| BetterToken API | kimi-k3.1-pro | https://www.bettertoken.ai/v1 | 自己的 BetterToken API Key |
截至上述核对日期，BetterToken 的模型列表包含这一准确 ID。
如果选择网关接入，应单独核对当前网关价格。下文提供的 Moonshot API 官方价格不能直接当作 BetterToken 报价。
下面先使用 Moonshot 官方 API 测试。
按照 Moonshot API 快速入门中的平台入口创建 API Key。随后在 Bash 中执行以下命令。第一行通过隐藏输入收集密钥，不会将密钥字符显示在终端。
read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY
curl --fail-with-body --silent --show-error \
"https://api.moonshot.ai/v1/chat/completions" \
-H "Authorization: Bearer ${MOONSHOT_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"model": "kimi-k3.1-pro",
"reasoning_effort": "low",
"max_completion_tokens": 4096,
"messages": [
{
"role": "user",
"content": "Return a Python function add(a, b) and one assert checking add(2, 3) == 5."
}
]
}'请求让模型返回一个 Python 加法函数，以及验证 add(2, 3) == 5 的断言。
检查响应的 choices[0].message.content，确认其中包含函数和断言。扩大测试规模之前，还应查看响应中的 token 使用量。
这个最小请求验证的是 API 身份认证和文本生成能力，并不能证明模型已经能够作为编码 Agent 读取或修改项目文件。
根据 Kimi 的推理档位文档，reasoning_effort 支持 low、high 和 max，默认值为 max。模型始终启用推理。示例选择 low，是为了执行一个较小的连通性测试。
如果 API 返回错误，应首先确认请求端点、API Key 所属的服务提供商以及准确的模型 ID。
如果响应被截断，应先检查输出 token 限制，不要直接认定是模型生成质量有问题。
对于多轮 API 对话和工具调用，必须将 API 返回的完整 assistant 消息原样放回 messages，包括 reasoning_content 和 tool_calls。
完成基本 API 验证后，可以参考 Kimi K3.1 Pro 的 Claude Code 与 Codex 接入指南，进一步验证真实的文件读取任务。
另外，API token 计费与 Kimi 会员订阅、Kimi Code 的使用额度是不同的体系。如果实际阻塞原因是订阅额度限制，可参考 Kimi K3.1 Pro 额度与 API 计费指南。
自托管与 API 的成本应该怎么比较？
应比较在相同质量要求下，完成同类任务的总成本，而不是只比较模型权重是否免费下载与 API 每 token 的价格。
即使权重可以下载，自托管仍然涉及 GPU、服务器内存、存储、网络、运维，以及可能需要的额外商业许可协议。
截至 2026-11-11，Moonshot API 平台列出的价格如下。单位为 USD / 1,000,000 tokens。根据 Kimi 价格条款，以下费用不包含适用税费。
| API 模型 | 常规输入 | 输出 | 缓存命中 | 默认 5 分钟缓存写入 |
|---|---|---|---|---|
kimi-k3.1-pro | $2.00 | $10.00 | $0.20 | $2.00 |
kimi-k3.1-pro-highspeed | $4.00 | $20.00 | $0.20 | $4.00 |
Kimi 缓存文档将输入 token 分为缓存命中、缓存写入和未缓存输入等类别。
对于 Chat Completions 和 Responses，如果省略 prompt_cache_options，默认缓存写入有效期为 5m。
前面的 API 请求没有提供这个字段，因此使用默认设置。
计费时，不要将已经按缓存写入计费的 token 再次算作常规输入。选择不同的缓存有效期时，也需要使用对应的缓存写入费率。
可以用一个明确假设的场景估算成本。
假设使用标准版 kimi-k3.1-pro 完成一个任务，消耗 100,000 输入 token 和 10,000 个计费输出 token。
假设没有缓存命中，所有输入 token 要么不使用缓存，要么按照默认的 5 分钟有效期写入缓存。
在该场景下，常规输入和默认缓存写入的单价均为每百万 token $2.00。
Estimated token charge
= (100,000 × $2.00 + 10,000 × $10.00) / 1,000,000
= $0.30 before taxes因此，这个假设任务的 API token 费用估算为 $0.30（税前）。
这只是按照公开费率进行的计算，不是实际运行任务后的测量结果。
计算输出费用时，应使用 API 报告的输出 token 使用量，而不是仅根据用户看到的最终答案长度推算。
如果任务还需要额外工具或其他服务，也应计入对应成本。只有确定工作负载不使用这些服务时，才能将其排除。
对于自托管，应将完整运营成本除以成功完成的同类任务数量。
成本项目应包括空闲计算资源、服务器内存、存储、电力或硬件租赁、网络、维护，以及可能需要的商业许可协议。
两种方案都应记录重试成本和验收失败的任务，不能只统计成功请求消耗的 token 或 GPU 时间。
对于应用原型和需求量尚不确定的项目，优先使用 API。只有当模型控制需求足够明确，而且实际测得的工作负载能够支撑运营费用时，再考虑自托管。
如果计划提供 MaaS 服务，应先明确业务是否触发许可证条件，再承诺部署方案或进行硬件采购。