Kimi K3 API 带着一个不寻常的组合登场：接近前沿水平的基准成绩、激进的定价，以及可供下载的权重。Moonshot AI 于 2026 年 7 月 27 日公开了这些权重，使 K3 成为迄今公开发布的最大模型，也是这一规模的模型首次在原则上可以由你自己运行。

对于已经在向前沿供应商付费的团队来说，这提出的是一个务实问题，而非哲学问题：它在你的技术栈里有没有位置，把一部分流量迁过去究竟会改变什么。本文讨论成本测算、集成工作，以及那些公开数字无法转化为生产表现的环节。

简而言之： Kimi K3 的缓存未命中输入约为每百万 token 3 美元，缓存命中输入约为 0.30 美元，输出约为 15 美元，上下文窗口为 1,048,576 个 token。它提供兼容 OpenAI 与 Anthropic 的接口，因此迁移一个工作负载基本上只是改动基础 URL 和模型名称。需要注意的是，思考始终开启且默认为最高强度，除非你有意设置，否则输出 token 会成为账单上最大的一项。

Kimi K3 究竟是什么

架构在这里很重要，因为它同时解释了定价和部署约束。

K3 是一个稀疏专家混合模型，总参数量 2.8 万亿，每个 token 激活约 1040 亿。它拥有 896 个专家，每个 token 路由到其中 16 个。正是这个比例让这种规模的模型得以被服务：你付出的是全部参数量的显存代价，而计算代价只相当于一个小得多的模型。

真正新颖的是注意力设计。Moonshot 在名为 Kimi Delta Attention 的线性注意力机制之上构建了 K3，并以大约三比一的比例与周期性的全注意力层交错排列，再辅以他们称为 Attention Residuals 的技术。线性层以低成本处理局部序列结构，全注意力层则保留全局信息流动。正是这一组合让百万 token 上下文在经济上可行，而不只是宣传口号。

模型卡还引出两个运维细节。权重以 MXFP4 提供，激活为 MXFP8；思考始终启用，意味着模型在每次请求中都会连同答案返回一个 reasoning_content 字段。你无法关闭推理，只能选择购买多少。

Kimi K3 API 的成本

公开的费率很直白，而各项之间的差距正是有趣决策发生的地方。

缓存未命中输入约为每百万 token 3 美元。缓存命中输入约 0.30 美元，相差十倍。输出约为每百万 token 15 美元。与部分供应商不同，该定价在整个上下文窗口内保持一致，不会在超过某个阈值后跳涨，这让长上下文任务的成本预测容易得多。

用一个现实的例子来算。假设某个客服工作流的智能体带有 4 万 token 的系统提示与知识前言，加上 2000 token 的对话，并生成 1500 token 的回答与推理。冷启动时，这次请求的输入约花费 12.5 美分，输出略高于 2 美分。而在缓存温热、4 万 token 前缀已被缓存的情况下，输入成本骤降到 1.5 美分以下，输出成本不变。按每天一万次请求计算，这个差额就是该功能的全部经济性。

由此得出两点。第一，组织提示词，让稳定的内容位于最前且永不变动，因为缓存只对保持完全一致的前缀有效。第二，密切关注输出侧，因为推理 token 按输出计费，而强度设置默认为最高。我们关于用缓存降低大模型延迟 的指南更详细地讨论了前缀纪律，这里几乎可以原样适用。

集成基本上就是改一个基础 URL

Moonshot 通过同时兼容 OpenAI 和 Anthropic 惯例的接口提供 K3，这意味着对多数应用而言迁移确实很小。把现有客户端指向 Moonshot 的端点，将模型标识设为 kimi-k3，再提供新的凭据即可。已经使用其中任一协议的代码通常无需修改就能工作。

上线前有三个差异值得显式处理。

第一是 reasoning_effort。K3 接受一个顶层字段，取值为 low、high 或 max，默认是 max。在分类或抽取类任务上保留默认值，等于为根本不需要的深度思考付费。日常调用请设为 low，把 high 或 max 留给真正受益的请求。

第二是 reasoning_content。由于思考始终开启，响应中除答案外还会携带推理字段。你的解析代码需要知道该字段存在，日志需要决定是否保留它，而界面绝不应该意外地把它显示出来。

第三是适用于任何供应商的常规纪律。把凭据保留在服务端，将调用置于自有代理之后以保留按用户计量和更换供应商的能力，并固定模型标识而不要追踪会移动的别名。我们如何构建该层，写在 OpenAI API 集成指南 中，它正是出于这个原因刻意保持供应商中立。

百万 token 上下文，以及何时该忽略它

1,048,576 token 的窗口是一项真实能力，同时也是最容易被误用的特性。

当任务确实需要跨整个语料进行推理时，它物有所值：把一份合同与其全部历史版本比对、追踪某个行为在整个代码仓库中的流转、梳理早期步骤仍然重要的长程智能体轨迹。在这些情况下，检索反而有害，因为决定哪一段相关的是检索器看不见的关系。

而对于面向文档集合的问答，它是错误的工具。每次请求都塞进百万 token，比检索出真正相关的四个段落更慢也昂贵得多，在精确查找上准确率往往还更低。诚实的原则是：大上下文用于那些你事先无法知道哪部分相关的问题，其余的都属于检索管线。

诚实地解读基准测试

K3 的成绩不错。在综合智能指数上，它紧随领先的商业前沿模型之后，同时明显超过上一代，并在智能体式与终端类编码评测中表现强劲。已公布的数字包括 Terminal-Bench 2.1 上接近九成的成绩，以及 FrontierSWE 上八十出头的结果。

这些数字需要一个适用于所有模型而非仅此一家的注解。编码基准的结果高度依赖运行所用的框架，混用不同框架的比较在同一模型上可能相差十到二十五分。用厂商自家智能体脚手架跑出的分数，无法与通用运行器的分数直接比较。当一张表格显示某个模型领先另一个时，请先确认两者是否以相同方式评测，再下结论。

实际含义是：公开基准适合用来筛选候选，不适合用来做最终决定。从你自己的流量中构建一个小型评测集，用你自己的提示词和脚手架跑一遍候选模型，在你真正要做的工作上比较。三十到一百个有代表性的样例，比任何排行榜都更能说明问题。

它在生产技术栈中的位置

2026 年合理的模式是路由而非站队，而 K3 很适合这一模式。

把高频的常规工作交给小而快、成本低的模型。把长程智能体任务、大型仓库任务和真正需要全语料推理的工作交给 K3，在这里上下文窗口与智能体表现对得起它的成本。同时保留一个商业前沿模型，用于那少数需要最佳答案、价格不是决定因素的请求。

前提条件是一个抽象层，让你无需改动应用代码就能在供应商之间迁移流量。把某个厂商的客户端硬编码到整个代码库的团队会发现切换需要数周，于是他们从不切换，于是也从未拿到那份节省。先把接缝做出来，模型选择就从一个项目变成一项配置决策。

还有一个尤其有利于 K3 的考量。由于权重已经公开，你基于 API 构建的工作负载日后可以迁移到自己掌控的基础设施上，而无需重写应用。这是一个真实的战略选项，我们的姊妹篇自托管 Kimi K3 对此有详细讨论。

把集成做扎实

Mecanik 作为人工智能集成服务 的一部分，为多家供应商构建生产级的语言模型集成。我们负责代理与路由层、提示缓存结构、强度调优、评测框架，以及那些防止一个有前景的功能变成不可预测账单的成本控制。

如果你正在考虑从现有供应商迁移到 Kimi K3，我们会把你的真实流量分别跑过两边，在你做出任何承诺之前把质量与成本的差异摆出来。关于更宏观的商业视角，我们的 AI 集成成本指南 说明了构建与运行预算的现实样貌。完整规格发布在 Kimi K3 模型卡 上。

相关文章: AI机构vs自建团队：2026年英国AI采用指南 、Claude API vs OpenAI API：开发者对比 2026 、DeepSeek R1 vs. OpenAI o3-mini：哪个 API 最好？ 、真正的人工智能存在吗？ 揭开神话与现实 。

常见问题

Kimi K3 API 的费用是多少？ 公开定价约为缓存未命中输入每百万 token 3 美元、缓存命中输入 0.30 美元、输出 15 美元，并在整个上下文窗口内一致适用。由于推理 token 按输出计费且强度默认为最高，通常输出才是最大的成本项。

Kimi K3 API 兼容 OpenAI 的客户端库吗？ 兼容。Moonshot 提供同时符合 OpenAI 与 Anthropic 惯例的接口，因此多数应用只需更改基础 URL、模型标识和凭据即可迁移。请为推理强度字段以及每次响应中返回的额外推理内容留出一点处理时间。

可以关闭 Kimi K3 的推理吗？ 不可以。思考始终启用，每个响应都会包含推理内容字段。你只能通过推理强度设置控制深度，它接受 low、high 或 max，默认是 max，因此在常规任务上请显式设置，以免为不必要的深度思考付费。

我应该用百万 token 上下文代替检索吗？ 只有当任务确实需要跨整个语料推理时才该如此，例如追踪某个行为在整个仓库中的流转。若是面向文档集合的问答，检索仍然比每次请求都填满上下文窗口更快、更便宜，通常也更准确。

Kimi K3 公布的基准分数可信度如何？ 分数本身是真实的，但依赖运行框架。编码类评测可能因所用智能体脚手架而相差十到二十五分，因此厂商自家框架给出的结果无法与通用运行器直接比较。做决定前请在你自己的任务上验证。