Kimi K3 已于 2026 年 7 月 16 日正式发布。已确认信息包括:2.8T 总参数、1M token 上下文、原生视觉能力、API 模型名 kimi-k3,以及 $3/M 未缓存输入、$15/M 输出的国际 API 定价。

但有三个边界必须先说清楚:2.8T 是总参数,不是每个 token 的激活参数;模型权重计划在 7 月 27 日前发布,目前还不能当成“已经开源”;厂商 benchmark 很强,但测试配置并不完全一致,不能直接写成“全面超过所有竞品”。

本文不做发布稿复述,重点回答四个开发者问题:API 到底多少钱、怎么接、从 K2.6 迁移要改什么、现在是否值得上生产。

一、先看结论:K3 可以测试,但不建议按标题数字直接全量迁移

结论状态依据
Kimi K3 已于 2026-07-16 发布已确认Moonshot AI 官方发布页
总参数为 2.8T已确认官方发布页
每个 token 激活 16/896 个专家已确认官方架构说明
每个 token 激活 2.8T 参数错误解读官方没有这样声明,且与 MoE 描述不符
上下文窗口为 1,048,576 tokens已确认官方 API 文档
国际 API 价格为 $3/$15已确认官方定价页,分别为未缓存输入/输出
权重已经可以下载截至 7 月 17 日为 False官方承诺 7 月 27 日前发布,尚未看到公开 checkpoint
K3 全面超过 GPT/Claude无法确认厂商表格结果有输有赢,且 harness 不一致

工程结论很直接:如果你的任务是长上下文代码、文档分析、视觉文档或复杂 agent,可以用 5% 流量做 A/B 测试;如果你依赖低 reasoning effort、内置联网搜索、严格短输出或立即私有化部署,当前版本仍有明显限制。

二、2.8T 是总参数,激活参数仍未公开

Kimi K3 使用 Mixture-of-Experts 架构。官方披露的关键信息是:模型共有 896 个专家,每个 token 路由到其中 16 个专家;同时使用 Kimi Delta Attention、Attention Residuals 和 Stable LatentMoE。

这不等于“每次推理都跑满 2.8T 参数”。

要计算真实的每 token 推理量,还需要知道共享层规模、专家维度、注意力部分参数、路由结构以及其他架构细节。官方尚未披露 active parameter count,因此不能根据 16/896 简单相除后编出一个数字。

对自部署而言,可以先算一个理想化的存储下限。假设全部 2.8T 参数都按 4 bit 保存:

2.8T x 4 bit / 8 = 1.4 TB

这还没有包含量化 scale、元数据、KV cache、运行时 buffer 和副本。官方建议使用 64 张及以上加速卡。由此可以确认的是,K3 即使按计划开放权重,也不是普通单机可以轻松部署的模型。

三、官方 API 定价与三组成本计算

K3 国际 API 的公开价格如下:

Token 类型每 1M tokens 价格
Cache hit 输入$0.30
Cache miss 输入$3.00
输出$15.00

场景 1:小型 coding agent

每月 10M 输入、2M 输出,全部输入未命中缓存:

输入:10 x $3 = $30
输出:2 x $15 = $30
合计:$60/月

场景 2:RAG/文档系统,80% 输入命中缓存

每月 100M 输入、20M 输出:

未缓存输入:20M x $3/M = $60
缓存输入:80M x $0.30/M = $24
输出:20M x $15/M = $300
合计:$384/月

如果 100M 输入全部未缓存,总成本是 $300 + $300 = $600。稳定 system prompt、工具定义和文档前缀可以把这组工作负载从 $600 降到 $384。

场景 3:大规模 agent

每月 1B 输入、200M 输出:

缓存情况输入成本输出成本总成本
全部未缓存$3,000$3,000$6,000
90% 输入缓存命中$570$3,000$3,570

这组数据暴露了一个关键点:缓存只能降低输入成本,输出依旧按 $15/M 计费。

Artificial Analysis 的早期独立测量显示,K3 在其评测中生成了约 130M 输出 tokens,而可比模型中位数为 63M。这个结果不能直接外推到所有业务,但足以提醒开发者记录“单个成功任务的输出 token 数”。

如果在同一评测规模下分别输出 63M 和 130M tokens:

63M x $15/M = $945
130M x $15/M = $1,950
差额 = $1,005

所以不能只比较 token 单价。生产环境应该比较:

Cost per accepted task
= 总输入成本 + 总输出成本 + 重试成本 + 工具调用成本

四、K3 与 K2.6 不是同价升级

Moonshot 官方中文定价页显示,K3 与 K2.6 的人民币价格差距明显:

Token 类型K2.6K3K3/K2.6
缓存命中输入¥1.10/M¥2.00/M1.82x
未缓存输入¥6.50/M¥20.00/M3.08x
输出¥27.00/M¥100.00/M3.70x

如果现有系统跑在 K2.6 上,不能只改模型名。K3 必须通过更高任务成功率、更强长上下文能力、更少重试或多模态能力,才能覆盖 1.82x 到 3.70x 的单价上升。

五、Python 接入示例

K3 提供 OpenAI 兼容接口。下面示例使用官方端点,环境变量中保存 API Key:

import os
from openai import OpenAI
​
client = OpenAI(
    api_key=os.environ["KIMI_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)
​
response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Review this API design and list the three highest-risk failure modes.",
        }
    ],
    reasoning_effort="max",
    max_completion_tokens=4096,
)
​
print(response.choices[0].message.content)
print(response.usage)

如果通过 TokenMix 已接入的模型路由调用,当前 catalog 中的模型 ID 是 moonshot/kimi-k3。调用前应以实时模型目录为准,不要把第三方价格或模型状态硬编码到长期配置中。

client = OpenAI(
    api_key=os.environ["TOKENMIX_API_KEY"],
    base_url="https://api.tokenmix.ai/v1",
)
​
response = client.chat.completions.create(
    model="moonshot/kimi-k3",
    messages=[{"role": "user", "content": "Summarize the attached incident log."}],
    reasoning_effort="max",
    max_completion_tokens=2048,
)

对应的 cURL 请求:

curl https://api.moonshot.cn/v1/chat/completions \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {"role": "user", "content": "Find the root cause in this deployment log."}
    ],
    "reasoning_effort": "max",
    "max_completion_tokens": 4096
  }'

六、从 K2.6 迁移必须检查的 6 个变化

官方 quickstart 已明确列出若干 K3 特有约束。忽略它们,可能导致请求报错、上下文损坏或成本失控。

检查项K3 当前行为迁移动作
Reasoning 参数使用顶层 reasoning_effort删除 K2 风格的 thinking 参数
Reasoning 档位当前仅支持 max不要假设可以切换到 low/medium
Samplingtemperature=1、top_p=0.95 等值固定删除自定义 sampling 覆盖
对话历史必须保留完整 assistant message不要只保存可见文本
会话切模型不支持在对话中途换模型换模型时新建会话
内置联网搜索官方称正在更新,不建议当前使用接自己的 search tool

此外,官方文档指出公共图片 URL 目前不受支持。做视觉任务时,需要使用官方支持的上传或编码方式,不要沿用其他 OpenAI 兼容模型的 URL 输入假设。

建议增加输出上限

K3 当前固定在最大 reasoning 档位,独立评测又显示输出量偏高。建议所有生产请求都显式设置 max_completion_tokens,同时记录:

  • 输入 tokens;

  • cache hit tokens;

  • reasoning/output tokens;

  • 工具调用次数;

  • 重试次数;

  • 最终任务是否被接受。

不要只看一次请求多少钱,要看一次成功任务需要几次请求。

七、Benchmark 应该怎么读

Moonshot 发布页给出了多项厂商自报成绩:

BenchmarkKimi K3表中最高对照值结论
DeepSWE67.573.0未领先
Terminal-Bench 2.088.388.8接近领先
BrowseComp91.290.4厂商表中领先
GPQA Diamond93.594.1未领先
MMMU-Pro81.683.0未领先
OmniDocBench91.189.8厂商表中领先

这些数字可以证明 K3 值得测试,但不能证明它“全面第一”。官方脚注显示,不同模型使用了不同 reasoning 模式、工具配置或评测 harness。最稳妥的做法是:用表中 K3 强项确定测试方向,然后在自己的任务集上复测。

Artificial Analysis 的早期独立数据为:Intelligence Index 57、输出速度约 62 tokens/s、首 token 时间约 1.99 秒。独立数据比厂商单表更适合作为外部基线,但服务商扩容和推理优化可能改变速度,因此仍应以实际 API 压测为准。

八、权重发布前不要把“开源”写成既成事实

截至 2026 年 7 月 17 日,官方说法是“7 月 27 日前发布完整权重”。这属于可验证的发布承诺,不等于权重已经上线。

真正决定能否私有化部署的检查项包括:

检查项当前状态
checkpoint 文件尚待发布
license尚待随发布核验
reference inference code尚待核验
主流推理框架适配尚待社区和官方实现
量化版本尚待发布后验证
实际显存、吞吐和并发尚无稳定独立结论

7 月 27 日后,也不应该只确认“文件存在”。还要检查 license 是否允许目标商业场景,以及 vLLM、SGLang 等推理框架是否有可复现的部署结果。

九、生产采用建议

使用场景当前建议原因
长上下文代码分析小流量测试1M context 有价值,但需测检索准确性与成本
多模态文档小流量测试OmniDocBench 厂商成绩强,需自测真实文档
研究型 agent小流量测试BrowseComp 成绩强,但内置搜索仍在更新
严格低延迟聊天谨慎当前只有 max reasoning,且独立测速不算快
严格短输出任务谨慎早期独立评测显示输出量偏高
立即自部署等待权重、license、框架适配尚待验证
K2.6 直接替换不建议直接全量价格与 API 行为均有变化

推荐的上线顺序是:

  1. 选 50 到 200 个真实任务建立固定测试集。

  2. 先跑 K2.6 或当前生产模型作为 baseline。

  3. K3 使用相同工具、相同输入和明确输出上限复测。

  4. 记录任务成功率、总 tokens、重试、延迟和人工接受率。

  5. 仅在“每个成功任务成本”与质量同时达标后扩大流量。

结论

Kimi K3 的发布不是传闻:2.8T 总参数、1M 上下文、原生视觉和 $3/$15 API 都有官方依据。它也不是一张 benchmark 表就能定性的模型:激活参数未公开、权重尚待发布、输出偏长可能改变实际成本,API 迁移还存在多项约束。

对开发者最合理的动作是现在开始小流量评测,而不是现在就全量替换。7 月 27 日后再单独核验 checkpoint、license 和本地部署成本。

参考资料:

说明:TokenMix 当前模型目录中已提供 moonshot/kimi-k3 路由。本文涉及的官方价格、模型状态和第三方路由价格均可能调整,接入前应查询实时目录。

更多推荐