Kimi K3 使用指南：从 KDA 架构到 API 接入

2026 年 7 月，月之暗面发布了 Kimi K3。这是一款 2.8 万亿参数的 MoE 模型，激活参数约 1,040 亿，基于 Kimi Delta Attention（KDA）混合线性注意力机制和 Attention Residuals 构建，原生支持视觉理解，上下文窗口最高可达 1M token。它是全球首个开源的 3 万亿级别模型，权重已完整发布。

对开发者而言，K3 值得关注的不只是参数规模，而是它在长上下文效率、推理强度控制和 Agent 工作负载上的具体设计选择。本文从架构、接入、成本和路由四个维度展开。

一、架构选择：KDA 解决了什么问题

K3 的架构更新围绕一个核心目标展开：让信息在更长序列和更深模型中更顺畅地流动。

具体做法是在注意力层中引入 KDA。KDA 采用固定大小的递归状态保存历史，模型不会完整保留每个 token，而是在阅读过程中持续更新一份压缩记忆。官方技术报告显示，K3 约四分之三的注意力层由 KDA 取代，每个模块中安排 3 层 KDA 和 1 层 Gated MLA。在 1M token 上下文长度下，这一设计带来的解码加速最高可达 6.3 倍。

另一项更新是 Attention Residuals，每 12 层插入一次，用于改善深层模型中的信息传递。

MoE 层面，K3 在 896 个专家中激活 16 个，结合 Stable LatentMoE 框架后，相比 K2 的整体扩展效率提升约 2.5 倍。这个数字的意义在于：同样规模的算力，可以转化为更多的有效能力。

二、接入规范：从模型 ID 到参数约束

K3 的模型 ID 是 kimi-k3，接口兼容 OpenAI 格式，base URL 为 https://api.moonshot.cn/v1。初始化客户端的代码与标准 OpenAI SDK 一致，不需要额外的适配层。

但接入时有几个约束需要在写业务逻辑之前确认。

充值门槛。 K3 是旗舰模型，账户累计充值金额需达到 10 元才能解锁调用。新用户注册赠送的 15 元代金券不可用于 K3。

参数固定。 K3 的 temperature 不可修改，top_p 固定，n 固定为 1。这意味着如果业务代码依赖自定义采样参数，迁移到 K3 时需要在应用层做适配，而不是在请求参数里传值。

模型下线。 kimi-k2.5 已于 2026 年 8 月 31 日下线，调用将返回 404 错误。moonshot-v1 系列同样已退役。如果生产环境中仍有旧模型 ID，需要在路由层完成迁移。

三、推理强度：三档调节与缓存权衡

K3 常驻思考模式，没有 “关闭思考” 的开关。推理深度通过顶层 reasoning_effort 字段控制，支持 low、high、max 三档，默认 max。

三档的选择不是简单的 “越高越好”。low 适合格式转换、简单抽取这类任务，减少不必要的思考 token 消耗。high 覆盖日常编码和知识工作。max 留给复杂重构、多步推理和高难度算法题。

这里有一个容易被忽视的成本因素：切换 reasoning_effort 档位会破坏前缀缓存命中。如果你的调用模式是同一段长系统提示词加上不同的用户输入，频繁切换档位会导致缓存失效，输入侧的成本会显著上升。建议在会话开始前确定档位，而不是在会话中途调整。

四、成本结构：单价与缓存的双重杠杆

K3 的国内官方定价为：缓存命中输入 2 元 / 百万 tokens，未命中输入 20 元 / 百万 tokens，输出 100 元 / 百万 tokens。美元端，海外 provider 的标准费率为输入 $3.00 / 百万 tokens、缓存输入 $0.30 / 百万 tokens、输出 $15.00 / 百万 tokens。

表格

缓存命中与未命中之间的价差是 10 倍。在 1M 上下文窗口的模型上，这个差值的意义远超 “省钱”—— 它决定了长文档分析和代码库问答这类任务的成本量级。如果稳定前缀的复用率超过 70%，输入侧的实际成本可以降至标价的十分之一左右。反之，如果每次请求的内容完全独立，缓存机制几乎不产生收益。

输出侧是另一个杠杆。100 元 / 百万 tokens 的输出价在国产模型中处于旗舰档位。对于输出 token 占比高的 Agent 任务（代码生成、多轮工具调用），输出成本会主导账单。对于输出量小的分类和标签任务，输入侧的缓存策略影响更大。

与同档模型对比：DeepSeek V4 Pro 的输出价约为 K3 的三分之一，但 K3 在 SWE-Marathon（持续自主软件工程基准）上得分 42.0，超过 Claude Fable 5 的 35.0 和 GPT-5.6 Sol 的 39.0。Terminal-Bench 得分 88.3，同样高于 Fable 5 的 84.6。DeepSWE v1.1 得分 67.5（Claude Fable 5 为 70.0，GPT-5.6 Sol 为 73.0）。Gemini 3 Pro 在部分基准上与 K3 持平，但 K3 的价格结构和缓存策略对国内开发者更友好。

“谁更便宜” 取决于三个变量：缓存命中率、输出占比、以及是否需要 max 档推理。在说清楚这三件事之前，比较没有意义。

五、多模型路由：K3 和谁搭档

K3 的定位不是 “取代所有模型”，而是适合进入一个多模型池。它的强项在于需要长时间持续运行的任务：自主编程、多步骤研究、连续执行数百次工具调用并保持上下文连贯的 Agent 工作负载。

一个典型的配置是 K3 加 Claude。Claude 在复杂长任务的工具调用稳定性和推理能力上有优势，K3 的优势则体现在开放权重、成本可控和视觉理解原生集成。简单查询、短文本摘要这类任务不需要旗舰模型的推理深度，可以路由到更轻量的模型。但如果 Agent 架构从一开始就是 “单模型” 设计的 —— 一个模型、一个 API Key、统一的 token 单价 —— 那么所有请求都会按旗舰模型的价格计费。

硬编码路由的问题在于维护成本。用 if/else 判断 Prompt 长度或关键词，规则简单但很快变得难以扩展。用一个轻量 LLM 先做请求分类再调用主模型，则每个请求都需要两次模型调用，而且分类逻辑本身需要持续调优。

更可维护的方案是把模型选择下沉到基础设施层。应用不需要知道最终调用了哪个模型，路由层负责读取请求特征并分发。对于需要同时管理 K3、DeepSeek V4 和 Gemini 等候选模型的团队，星链 API 的统一入口允许在同一个 OpenAI 兼容端点下切换模型，只改 model 参数，不需要重写 base URL 和认证配置。调用日志可以在一个面板中对比不同模型的延迟和 token 消耗，这对做成本归因有实际帮助。

K3 原生支持文本、图像和视频输入。前端开发是视觉推理的典型应用场景：截图拖入对话，K3 根据画面内容推理并给出修改建议，模型基于视觉反馈迭代输出。这个能力在需要 GUI 交互的 Agent 任务中，可以减少人工描述界面的环节。

六、自托管与 API 的边界

K3 的权重已完整发布，支持自托管部署。但需要区分 “2.8 万亿参数” 和 “单次推理激活量”—— 激活参数约 1,040 亿，KV cache 和运行时开销仍然需要持续预留。

自托管的成本结构是固定成本加变动成本。API 模式下，空闲时不产生费用；自托管模式下，推理容量需要持续预留。对于流量有波峰波谷的团队，API 的按量计费通常更经济。对于调用量稳定且规模足够大的场景，自托管的边际成本优势才会显现。

另一个维度是数据主权。同样的模型能力，在不同账户、地区和组织设置下可能有不同的数据处理条件。如果输入数据涉及敏感信息，需要在选型阶段就把日志保留策略和访问权限纳入评估，而不是部署后再补救。

Kimi K3 的核心价值不在于参数数字本身，而在于 KDA 在 1M 上下文下的解码效率、reasoning_effort 的三档控制、以及原生视觉理解对 Agent 工作流的支撑。这些能力是否能转化为生产收益，取决于缓存策略的设计、路由层的合理性，以及对输出占比的准确判断。用真实任务跑一轮端到端成本对比，比看任何基准分数都更有决策价值。

了解更多：https://xinglianapi.com