RH
RouterHub AI API 中转站导航与平台推荐
登录
博客

Kimi K3 登场：首个开源 3T 级模型，如何重写多模型路由与成本决策

Moonshot 发布 2.8T 参数的 Kimi K3，登顶前端代码竞技场、独立智能榜排名第四。开源权重虽将开放，但真正影响开发团队的是它的定价、冗长度与任务分工——本文拆解如何把它接入多模型路由。

muchacha 2026-07-17 04:42:54

正文

2026 年 7 月 16 日，Moonshot AI 发布了 Kimi K3，并称其为"世界上第一个开放的 3T 级模型"。发布当天，它在前端代码竞技场（Frontend Code Arena）以 1679 分登顶、反超 Claude Fable 5，在独立评测机构 Artificial Analysis 的智能指数上排到全部 189 个模型中的第 4 位。Hacker News 首页的讨论帖迅速冲到 1300 多分。

对普通用户来说，这是又一个"更强的聊天模型"。但对每天要在多个模型 API 之间做取舍的开发团队来说，K3 带来的问题更具体：它值不值得进入你的路由表？该把哪些任务分给它？以及一个很容易被基准分数掩盖的问题——它的账单会不会比看起来贵得多？

本文把发布信息、独立评测和定价放在一起，从"要不要路由到它"的角度做一次拆解。

Kimi K3 到底是什么

先把厂商披露的规格和第三方评测的数字摆清楚。以下参数来自 Moonshot 官方博客与 API 文档，性能与价格来自 Artificial Analysis 的独立测评。

项目 Kimi K3
总参数量 约 2.8 万亿（Mixture-of-Experts）
激活方式 每 token 激活 896 个专家中的 16 个（“Stable LatentMoE”）
上下文窗口 1,000,000 token
架构 Kimi Delta Attention（混合线性注意力）+ Attention Residuals
模态 原生视觉，文本 + 图像输入，默认"max thinking"
训练精度 量化感知训练，MXFP4 权重 / MXFP8 激活
智能指数 57 分，排名 4/189（同类平均约 30）
输入价格 $3.00 / 百万 token
输出价格 $15.00 / 百万 token
缓存命中价 $0.30 / 百万 token（降幅约 90%）
输出速度 约 62 token/秒（略低于平均 68）
可用形式 Kimi.com、Kimi Work、Kimi Code、Kimi API（模型 id：kimi-k3）
开源权重 计划 2026 年 7 月 27 日前放出

有几点值得单独标注：

  • 它现在还不是"可下载的开源模型"。 发布当天 K3 只有 API 和网页版，完整权重要到 7 月 27 日才开放。在此之前，任何"接入 K3"都只能走 API。
  • 参数规模决定了自托管几乎不现实。 2.8T 参数即便量化后，一台顶配的 512GB Mac Studio 也装不下。也就是说，即便权重开放，绝大多数团队实际能用上的仍是托管 API，而不是自己跑一份。
  • 默认满血思考。 K3 发布时默认使用 max thinking effort，低/高档 effort 模式要后续更新才提供。这直接影响延迟和成本——你暂时无法为简单任务调低推理强度。
  • 许可证尚未确认。 K3 的开源协议官方还没明说，此前 K2、K2.5 采用的是 Modified MIT，所以这只是合理预期，不是既定事实。

基准强在哪、弱在哪

K3 的定位很清楚：Moonshot 自己也承认，它的整体表现仍落后于最强的两个闭源模型——Claude Fable 5 和 GPT-5.6 Sol。但在一些具体任务上，它已经进入第一梯队：

  • 前端/代码生成：登顶前端代码竞技场，分数超过 Fable 5。
  • 智能体知识工作：在 Artificial Analysis 的 briefcase 类评测中，K3 在部分智能体知识工作项上超过了 GPT-5.6 Sol。
  • 综合智能指数：57 分排名第 4，明显高于同类平均的 30 分。

换句话说，它不是全能冠军，而是在编码和长链路智能体任务上具备顶级竞争力的开放选项。对于把模型当成"可替换后端"的团队，这正是需要单独评估的那一类模型——不是要不要全量切换，而是"哪些工作流适合分给它"。

被基准分数掩盖的成本陷阱

如果只看单价，K3 的 $3 / $15（输入/输出，每百万 token）在旗舰模型里算中等偏上。但真实账单不是由单价决定的，而是由单价 × 实际生成的 token 数决定的。这里有个容易被忽略的信号：

在 Artificial Analysis 跑完整个智能指数评测时，K3 生成了 1.3 亿 token，而同类模型的平均值是 6300 万——它的冗长度差不多是平均的两倍。

把这两件事叠加起来看：K3 的输出价是 $15/百万，而它平均要为同样的任务多写一倍的字。也就是说，它的"有效输出成本"可能接近标称价格的两倍。对于按量计费、又跑大量长输出（代码生成、深度报告、智能体多轮）的场景，这不是小数点后的差异，而是月度账单能不能对得上预算的问题。

缓解手段是存在的，但需要主动使用：

  1. 用好缓存命中价。 K3 的缓存命中价是 $0.30/百万，比正常输入价便宜约 90%。对有大量固定前缀（系统提示、工具定义、长文档上下文）的应用，命中率直接决定成本。
  2. 控制输出长度。 在提示层约束输出格式、要求精简，能显著压掉冗长度带来的溢价。
  3. 等 effort 分档。 一旦低档 effort 模式上线，简单任务就不必付满血思考的代价。

对做多模型路由的团队意味着什么

K3 的出现，本质上是又一次提醒：在旗舰模型层，"选一个最强的用到底"已经不是最优解。 榜单前几名的差距只有几分，而它们在具体任务上的强弱、价格、速度、冗长度差异巨大。真正决定成本和体验的，是任务和模型之间的分配方式。

以 K3 为例，一个务实的接入策略大致是这样的：

  • 按任务路由，而不是全量切换。 把前端/代码生成、长链路智能体这类它擅长的工作分给 K3；把对延迟敏感、或者简单到不需要满血推理的请求留给更快、更便宜的模型。K3 约 62 token/秒的速度偏慢，交互式场景要谨慎。
  • 把冗长度纳入成本模型。 路由决策不能只比单价，要比"这个任务在这个模型上的预期总 token 成本"。对 K3 这种高冗长度模型，输出侧的权重要调高。
  • 利用长上下文，但别浪费它。 100 万 token 窗口适合长文档、大代码库场景，但每次都塞满上下文会让缓存和成本失控——配合缓存前缀和上下文裁剪才划算。
  • 为"权重开放后"预留退路。 7 月 27 日权重开放后，理论上可以自建推理，但 2.8T 的规模意味着对绝大多数团队而言，托管 API 仍是现实路径。真正的灵活性来自于：你的调用层能不能在自建、官方 API、第三方托管之间平滑切换，而不用改业务代码。

这些能力——按任务把请求分发到不同模型、统一比较真实 token 成本、集中管理多个提供商的密钥与配额、在提供商之间无缝切换——正是一个统一路由层 / 模型调用网关要解决的问题。模型每隔几周就换一次排名，但如果你的应用是直接硬编码某一家的 SDK 和密钥，每次想接入新模型都要改代码、重测、重新对账。把模型访问收敛到一个可配置的路由层，才能让"K3 上线了，先给代码任务灰度 10%"这种决策变成一次配置改动，而不是一次发版。

小结

Kimi K3 是一个真实的里程碑：首个 2.8T 参数量级、进入独立榜单前四、并承诺开放权重的模型。但对开发团队而言，它不是"要不要全量迁移"的问题，而是"如何把它安置进现有的多模型体系"的问题。它在代码和智能体任务上够强，值得进入路由表；但它偏慢、冗长、输出价不低，需要用缓存、输出约束和按任务路由来管住成本。

模型排名会继续每隔几周洗一次牌。能长期受益的，是那些把模型当作可替换后端、并在调用层保留灵活性的团队——新模型一来，接入是一次配置，而不是一次重构。

参考来源

相关阅读