Kimi K3 是开源吗开放权重、许可证条款与调用姿势原文OpenRouter Blog - 《Is Kimi K3 Open Source? Weights, License, and How to Call It》https://openrouter.ai/blog/insights/kimi-k3-open-source一、一个经常被说错的词开放权重不等于开源给 Agent 选模型时我们习惯比分数、比价格、比上下文长度很少有人翻到许可证那一页。但许可证在你只是自己跑着玩的时候无所谓在你准备把它接进一个要上线的产品时会立刻变成硬约束。OpenRouter 这篇解读把两个常被混用的词拆得很清楚它们回答的是不同的问题。开放权重open-weight回答的是权重有没有公开。发布方把训练好的参数放出来你可以下载、可以检查。至于附在权重上的许可证可以是发布方自己写的任何文本。开源open-source在 OSIOpen Source Initiative的口径下回答的是另一个问题许可证是否满足 Open Source Definition并出现在 OSI 批准列表上。像 Apache-2.0、MIT 这类许可证有 SPDX 标识符也在那张列表里。Kimi K3 满足第一种定义不满足第二种。Moonshot AI 在 Hugging Face 以 moonshotai/Kimi-K3 的名义发布了 checkpoint用的是一份自定义的 Kimi K3 License没有 SPDX 标识符也不在 OSI 批准列表上模型卡上的 license 字段填的是 other名字是 kimi-k3。所以Kimi K3 是开源的这句话严格说是错的。能在 Hugging Face 下载权重和开源可商用是两件事。二、这份许可证给了你什么先把授予的范围说清楚。许可证文本把软件定义为模型权重、参数、配置文件、推理与训练代码以及相关文档。它免费授予的权利包括使用、复制、修改、合并、发布、分发、再许可、出售副本以及运行、部署、微调、创建衍生作品。差不多是你能想到的全套。基础条件只有两条Section 1在所有副本或软件的实质性部分中保留版权声明与许可声明使用行为需符合适用法律法规。这两条基本无感。三、真正影响上线决策的是两条阈值条款前面都是常规操作下面这两条才是需要拿去和法务过一遍的。Model as a Service 收入闸门Section 2。许可证把 MaaS 定义为让第三方访问语言模型推理或微调例如通过 API并且该第三方能对输入、参数或训练数据行使有意义的控制。定义里有两个排除项——把模型能力嵌在具体功能或 harness 里的终端用户产品不算把请求转发给他人托管的模型也不算。触发条件是你或你的任何关联方经营 MaaS 业务且在任意连续 12 个月内合计收入超过 2000 万美元。这时你必须在把该软件或其衍生作品用于任何商业目的之前先与 Moonshot AI 单独签署协议。用户界面署名Section 3。当软件或其衍生作品用于商业产品或服务且该产品月活超过 1 亿或月收入超过 2000 万美元时产品界面必须显著展示 Kimi K3 字样。四、两条豁免决定了大多数团队落在哪一格Section 4 给了两个豁免场景都不受上面两条阈值条款约束内部使用。定义为不把软件、其输出或其底层能力提供给第三方。也就是说用 K3 做公司内部的编码 Agent、内部知识库问答通常落在这里。通过 Moonshot AI 官方产品或认证推理伙伴访问。这两条豁免很关键因为它意味着如果你只是通过托管 API 用 K3或者只在内网跑大概率不会被阈值条款扫到真正需要额外签约的是把模型能力本身对外售卖的那类业务。原文也明确提醒许可证文本描述的是 2026-09-11 发布的版本文章不构成法律意见上线前请读原文。这一点必须照做我也把同样的口径转述给你。五、checkpoint 里到底是什么下面这张表的数字来自 Hugging Face 模型卡。项目内容总参数2.8T每 token 激活参数104B专家共 896 个每 token 激活 16 个注意力Kimi Delta Attention 与 Attention Residuals视觉编码器MoonViT-V2401M 参数上下文长度1,048,576 token权重格式MXFP4 权重、MXFP8 激活量化感知训练许可证Kimi K3 LicenseHugging Face 仓库moonshotai/Kimi-K3模型卡把 K3 描述为原生多模态模型能理解文本、图像和视频。thinking 常开reasoning_effort接受 low、high、max 三个取值默认 max。模型卡还列出了三套有公开配方的本地服务栈vLLM、SGLang、TokenSpeed。这里有个现实提醒2.8 万亿参数的 checkpoint 需要多节点服务硬件。原文很直白——如果没有那套硬件托管 API 就是跑这个模型的方式。自建部分原文没有覆盖也不做基准测试。六、多轮与工具调用有一个最容易写错的点模型卡明确写着多轮对话和工具调用时必须把 API 返回的完整 assistant message 回传进 messages包括 reasoning 内容与 tool calls。这一点在自建 Agent 循环里是最容易踩的坑。很多人写历史管理时习惯只存 content把 reasoning 字段和 tool_calls 丢掉结果就是模型在多轮里失忆——因为它拿不到自己上一轮是怎么推理、调了哪些工具的。做 Agent 的时候历史消息的完整回传应该当成硬规则写进代码而不是靠事后排查。七、怎么调一个最小示例下面是官方示例TypeScript SDK的等价写法// 摘自 OpenRouter 官方示例import{OpenRouter}fromopenrouter/sdk;constopenRouternewOpenRouter({apiKey:process.env.OPENROUTER_API_KEY??,});constresultawaitopenRouter.chat.send({chatRequest:{model:moonshotai/kimi-k3,messages:[{role:user,content:[{type:image_url,imageUrl:{url:https://example.com/screenshot.png}},{type:text,text:Summarize this screenshot and list the open questions.},],},],reasoning:{effort:high},stream:false,},});if(resultinstanceofReadableStream){thrownewError(Expected a non-streaming response);}console.log(result.choices[0].message.content);逐个说明model 是模型 IDmessages 里 content 是数组可以同时放图片和文本这也是原生多模态的直接体现reasoning.effort 控制推理强度这里显式设成 highstream 设为 false 时返回值是对象而不是流所以示例要先做一次类型判断避免拿到 ReadableStream 之后调用 choices 报错。返回值里除了 choices还有 usage。官方在 9 月 11 日跑过一次等价请求返回了图片的一句话描述、一个 reasoning 字段以及 usage 对象96 prompt tokens、119 completion tokens、87 reasoning tokens。另外K3 的参数里包含 reasoning、reasoning.exclude 和 reasoning.enabled。官方测过把 exclude 设为 true 会去掉响应里的推理文本但模型仍在推理把 enabled 设为 false 时响应里没有 reasoning 字段但答案是更长的、把过程写进 content 的版本。模型卡说 thinking 常开而单次调用无法区分端点是停止了内部推理还是只是不再返回所以要把 enabled 当成对端点的请求而不是保证。八、价格不是一个数字而是一张随端点变化的表选型时最容易误判的一点同一个模型 ID不同端点的价格和能力并不一样。2026-09-11 的目录里 kimi-k3 有 19 个端点prompt 价格区间$1.80 到 $6.00 每百万 tokencompletion 价格区间$9.01 到 $22.50 每百万 tokencache-read 价格区间$0.21 到 $0.60 每百万 tokenMoonshot AI 自家端点prompt $3.00、completion $15.00、cache read $0.30最大输出长度按端点不同从 16,384 到 943,718 token参数支持也不统一当天有两个端点没有列工具调用两个没有列结构化输出。如果你的请求依赖某个参数要把provider.require_parameters设为 true这样只会路由到支持请求中全部参数的端点。这是一个特别实用的兜底开关——否则你会遇到本地测试好好的、线上偶发不支持工具调用这类难排查的问题。其他几条要点目录里有 moonshotai/kimi-k3 和 Batch API 用的 :batch 变体没有 :free 变体。每个端点都列了 cache-read 价格命中时按该端点的 cache-read 费率计费响应里通过usage.prompt_tokens_details.cached_tokens报告缓存命中的 token 数。价格和端点会变以官方文档与模型页的当日表格为准。九、和 K2 系列对比署名义务没变多了一道收入闸门Kimi K2 和 K2.5 用的是 modified MIT也就是在 MIT 基础上加了一条商业产品月活超过 1 亿或月收入超过 2000 万美元时要在界面上显著展示模型名。Kimi K3 License 保留了这个署名条款另外新增了 MaaS 收入闸门。所以从 K2.5 迁到 K3署名义务是一样的多出来的是那道需要判断我到底算不算 MaaS 业务的门。十、给 Agent 开发者的落地清单不要用能否在 Hugging Face 下载来判断能不能商用去看许可证正文。上线前先给自己定位是内部使用、是走官方或认证伙伴、还是经营 MaaS。这决定你受不受阈值条款约束。多轮调用务必回传完整的 assistant message包含 reasoning 与 tool calls。依赖工具调用或结构化输出时用 require_parameters 兜底路由。同一个模型 ID 在不同端点上的价格、参数支持、最大输出长度都不同别只看一个数字。许可证、价格、端点清单都在变发布前以官方文档为准本文描述的是 2026-09-11 的许可证文本与当日目录数据不构成法律意见。对做 Agent 的人来说这篇解读的价值不在于它给出一个能不能用的结论而在于把判断依据摆出来了权重公开到什么程度、许可证在什么条件下会咬人、调用时有哪些和别的模型不一样的地方。把这三件事想清楚选型才算真的做完。
Kimi K3 是开源吗：开放权重、许可证条款与调用姿势
Kimi K3 是开源吗开放权重、许可证条款与调用姿势原文OpenRouter Blog - 《Is Kimi K3 Open Source? Weights, License, and How to Call It》https://openrouter.ai/blog/insights/kimi-k3-open-source一、一个经常被说错的词开放权重不等于开源给 Agent 选模型时我们习惯比分数、比价格、比上下文长度很少有人翻到许可证那一页。但许可证在你只是自己跑着玩的时候无所谓在你准备把它接进一个要上线的产品时会立刻变成硬约束。OpenRouter 这篇解读把两个常被混用的词拆得很清楚它们回答的是不同的问题。开放权重open-weight回答的是权重有没有公开。发布方把训练好的参数放出来你可以下载、可以检查。至于附在权重上的许可证可以是发布方自己写的任何文本。开源open-source在 OSIOpen Source Initiative的口径下回答的是另一个问题许可证是否满足 Open Source Definition并出现在 OSI 批准列表上。像 Apache-2.0、MIT 这类许可证有 SPDX 标识符也在那张列表里。Kimi K3 满足第一种定义不满足第二种。Moonshot AI 在 Hugging Face 以 moonshotai/Kimi-K3 的名义发布了 checkpoint用的是一份自定义的 Kimi K3 License没有 SPDX 标识符也不在 OSI 批准列表上模型卡上的 license 字段填的是 other名字是 kimi-k3。所以Kimi K3 是开源的这句话严格说是错的。能在 Hugging Face 下载权重和开源可商用是两件事。二、这份许可证给了你什么先把授予的范围说清楚。许可证文本把软件定义为模型权重、参数、配置文件、推理与训练代码以及相关文档。它免费授予的权利包括使用、复制、修改、合并、发布、分发、再许可、出售副本以及运行、部署、微调、创建衍生作品。差不多是你能想到的全套。基础条件只有两条Section 1在所有副本或软件的实质性部分中保留版权声明与许可声明使用行为需符合适用法律法规。这两条基本无感。三、真正影响上线决策的是两条阈值条款前面都是常规操作下面这两条才是需要拿去和法务过一遍的。Model as a Service 收入闸门Section 2。许可证把 MaaS 定义为让第三方访问语言模型推理或微调例如通过 API并且该第三方能对输入、参数或训练数据行使有意义的控制。定义里有两个排除项——把模型能力嵌在具体功能或 harness 里的终端用户产品不算把请求转发给他人托管的模型也不算。触发条件是你或你的任何关联方经营 MaaS 业务且在任意连续 12 个月内合计收入超过 2000 万美元。这时你必须在把该软件或其衍生作品用于任何商业目的之前先与 Moonshot AI 单独签署协议。用户界面署名Section 3。当软件或其衍生作品用于商业产品或服务且该产品月活超过 1 亿或月收入超过 2000 万美元时产品界面必须显著展示 Kimi K3 字样。四、两条豁免决定了大多数团队落在哪一格Section 4 给了两个豁免场景都不受上面两条阈值条款约束内部使用。定义为不把软件、其输出或其底层能力提供给第三方。也就是说用 K3 做公司内部的编码 Agent、内部知识库问答通常落在这里。通过 Moonshot AI 官方产品或认证推理伙伴访问。这两条豁免很关键因为它意味着如果你只是通过托管 API 用 K3或者只在内网跑大概率不会被阈值条款扫到真正需要额外签约的是把模型能力本身对外售卖的那类业务。原文也明确提醒许可证文本描述的是 2026-09-11 发布的版本文章不构成法律意见上线前请读原文。这一点必须照做我也把同样的口径转述给你。五、checkpoint 里到底是什么下面这张表的数字来自 Hugging Face 模型卡。项目内容总参数2.8T每 token 激活参数104B专家共 896 个每 token 激活 16 个注意力Kimi Delta Attention 与 Attention Residuals视觉编码器MoonViT-V2401M 参数上下文长度1,048,576 token权重格式MXFP4 权重、MXFP8 激活量化感知训练许可证Kimi K3 LicenseHugging Face 仓库moonshotai/Kimi-K3模型卡把 K3 描述为原生多模态模型能理解文本、图像和视频。thinking 常开reasoning_effort接受 low、high、max 三个取值默认 max。模型卡还列出了三套有公开配方的本地服务栈vLLM、SGLang、TokenSpeed。这里有个现实提醒2.8 万亿参数的 checkpoint 需要多节点服务硬件。原文很直白——如果没有那套硬件托管 API 就是跑这个模型的方式。自建部分原文没有覆盖也不做基准测试。六、多轮与工具调用有一个最容易写错的点模型卡明确写着多轮对话和工具调用时必须把 API 返回的完整 assistant message 回传进 messages包括 reasoning 内容与 tool calls。这一点在自建 Agent 循环里是最容易踩的坑。很多人写历史管理时习惯只存 content把 reasoning 字段和 tool_calls 丢掉结果就是模型在多轮里失忆——因为它拿不到自己上一轮是怎么推理、调了哪些工具的。做 Agent 的时候历史消息的完整回传应该当成硬规则写进代码而不是靠事后排查。七、怎么调一个最小示例下面是官方示例TypeScript SDK的等价写法// 摘自 OpenRouter 官方示例import{OpenRouter}fromopenrouter/sdk;constopenRouternewOpenRouter({apiKey:process.env.OPENROUTER_API_KEY??,});constresultawaitopenRouter.chat.send({chatRequest:{model:moonshotai/kimi-k3,messages:[{role:user,content:[{type:image_url,imageUrl:{url:https://example.com/screenshot.png}},{type:text,text:Summarize this screenshot and list the open questions.},],},],reasoning:{effort:high},stream:false,},});if(resultinstanceofReadableStream){thrownewError(Expected a non-streaming response);}console.log(result.choices[0].message.content);逐个说明model 是模型 IDmessages 里 content 是数组可以同时放图片和文本这也是原生多模态的直接体现reasoning.effort 控制推理强度这里显式设成 highstream 设为 false 时返回值是对象而不是流所以示例要先做一次类型判断避免拿到 ReadableStream 之后调用 choices 报错。返回值里除了 choices还有 usage。官方在 9 月 11 日跑过一次等价请求返回了图片的一句话描述、一个 reasoning 字段以及 usage 对象96 prompt tokens、119 completion tokens、87 reasoning tokens。另外K3 的参数里包含 reasoning、reasoning.exclude 和 reasoning.enabled。官方测过把 exclude 设为 true 会去掉响应里的推理文本但模型仍在推理把 enabled 设为 false 时响应里没有 reasoning 字段但答案是更长的、把过程写进 content 的版本。模型卡说 thinking 常开而单次调用无法区分端点是停止了内部推理还是只是不再返回所以要把 enabled 当成对端点的请求而不是保证。八、价格不是一个数字而是一张随端点变化的表选型时最容易误判的一点同一个模型 ID不同端点的价格和能力并不一样。2026-09-11 的目录里 kimi-k3 有 19 个端点prompt 价格区间$1.80 到 $6.00 每百万 tokencompletion 价格区间$9.01 到 $22.50 每百万 tokencache-read 价格区间$0.21 到 $0.60 每百万 tokenMoonshot AI 自家端点prompt $3.00、completion $15.00、cache read $0.30最大输出长度按端点不同从 16,384 到 943,718 token参数支持也不统一当天有两个端点没有列工具调用两个没有列结构化输出。如果你的请求依赖某个参数要把provider.require_parameters设为 true这样只会路由到支持请求中全部参数的端点。这是一个特别实用的兜底开关——否则你会遇到本地测试好好的、线上偶发不支持工具调用这类难排查的问题。其他几条要点目录里有 moonshotai/kimi-k3 和 Batch API 用的 :batch 变体没有 :free 变体。每个端点都列了 cache-read 价格命中时按该端点的 cache-read 费率计费响应里通过usage.prompt_tokens_details.cached_tokens报告缓存命中的 token 数。价格和端点会变以官方文档与模型页的当日表格为准。九、和 K2 系列对比署名义务没变多了一道收入闸门Kimi K2 和 K2.5 用的是 modified MIT也就是在 MIT 基础上加了一条商业产品月活超过 1 亿或月收入超过 2000 万美元时要在界面上显著展示模型名。Kimi K3 License 保留了这个署名条款另外新增了 MaaS 收入闸门。所以从 K2.5 迁到 K3署名义务是一样的多出来的是那道需要判断我到底算不算 MaaS 业务的门。十、给 Agent 开发者的落地清单不要用能否在 Hugging Face 下载来判断能不能商用去看许可证正文。上线前先给自己定位是内部使用、是走官方或认证伙伴、还是经营 MaaS。这决定你受不受阈值条款约束。多轮调用务必回传完整的 assistant message包含 reasoning 与 tool calls。依赖工具调用或结构化输出时用 require_parameters 兜底路由。同一个模型 ID 在不同端点上的价格、参数支持、最大输出长度都不同别只看一个数字。许可证、价格、端点清单都在变发布前以官方文档为准本文描述的是 2026-09-11 的许可证文本与当日目录数据不构成法律意见。对做 Agent 的人来说这篇解读的价值不在于它给出一个能不能用的结论而在于把判断依据摆出来了权重公开到什么程度、许可证在什么条件下会咬人、调用时有哪些和别的模型不一样的地方。把这三件事想清楚选型才算真的做完。
