近期AI热点003｜Kimi K3 技术拆解：2.8 万亿参数、API 接入与真实评价
近期AI热点003｜Kimi K3 技术拆解：2.8 万亿参数、API 接入与真实评价
主要信息源：Kimi 官方技术博客与 API 文档、MoonshotAI GitHub、Artificial Analysis、Hacker News、爱范儿实测
关键词：Kimi K3、Moonshot AI、开源大模型、MoE、KDA、API 接入、长上下文、AI Agent
7 月 18 日更新：官方 API 参数与
max推理限制未变；完整权重仍计划在 7 月 27 日前发布。本文同步更新了独立评测和社区讨论数据。
下文的计费数字仅用于估算 Token 消耗对工程预算的影响，计费规则以发布时的官方文档为准。
2026 年 7 月 16 日，月之暗面发布 Kimi K3，并把它定位为面向长程编程、端到端知识工作和推理任务的旗舰模型。
Kimi K3 的总参数量达到 2.8 万亿，采用 Kimi Delta Attention（KDA）、Attention Residuals（AttnRes）和更稀疏的 MoE 架构，原生支持视觉输入，并提供 1,048,576 Token 的上下文窗口。
不过，关于“开源”需要先把时间线讲清楚。
Kimi 官方已经宣布 K3 是开放模型，并承诺在 2026 年 7 月 27 日前发布完整权重，技术报告也会随权重公布。截至权重正式上线之前，开发者可以通过官方在线服务和 API 测试 K3，但还不能根据官方模型卡完成真正可复现的自托管部署。
因此，本文重点讨论当前已经可以验证的模型架构、API 接入、调用限制、成本和公开评价。自托管只记录官方状态，不展开尚未得到模型卡支持的部署命令。
先看清 Kimi K3 的技术规格
| 项目 | 官方信息 |
|---|---|
| 总参数量 | 2.8 万亿 |
| 模型结构 | MoE，896 个专家、每次激活 16 个 |
| 注意力结构 | Kimi Delta Attention 与 Gated MLA 组成的混合结构 |
| 深度信息流 | Attention Residuals |
| 上下文窗口 | 1,048,576 Token |
| 输入模态 | 文本、图像和视频 |
| 输出模态 | 文本 |
| API 模型名 | kimi-k3 |
| 推理模式 | 始终开启；目前 reasoning_effort 仅支持 max |
| 完整权重 | 官方承诺最迟于 2026 年 7 月 27 日发布 |
官方没有在首发文档中公布完整的激活参数量、层数、隐藏维度、专家大小、KV Cache 结构和训练 Token 数量。这些数据需要等待模型配置与技术报告，不能根据“16/896 个专家”简单算出整个模型的激活参数量。
2.8 万亿参数，不等于每个 Token 都计算 2.8 万亿参数
K3 使用更稀疏的 Mixture of Experts。每个 Token 只路由到 896 个专家中的 16 个，这会显著减少单次前向计算量。
但 MoE 有两个容易混淆的概念：计算量和存储量。
每个 Token 只激活少量专家，降低的是计算成本；部署节点仍然需要存放完整专家权重，除非使用专家按需加载或 CPU/NVMe Offload，而这又会引入明显的通信与延迟开销。
换句话说，K3 可能拥有比同规模稠密模型更可控的推理计算量，但 2.8 万亿参数仍然是一份非常庞大的权重资产。它不会因为“每次只用 16 个专家”就突然变成一张消费级显卡能跑的模型。
KDA 与 AttnRes 在解决什么
标准 Transformer 的全注意力计算会随着序列长度增长快速增加。Kimi Delta Attention 是一种混合线性注意力机制，目标是在长序列中降低注意力计算压力，同时保留处理复杂上下文的能力。
Attention Residuals 解决的是另一个方向的问题：模型变得更深以后，信息如何跨层传递。传统残差连接主要沿相邻层传播，AttnRes 则允许网络从多个历史块中选择和聚合信息，减少深层网络中的信息损失。
官方还引入 Stable LatentMoE，并称 K3 相比 K2 的整体扩展效率约提升 2.5 倍。这个数字描述的是官方定义下的整体 scaling efficiency，不应直接理解为“同一张显卡上速度快 2.5 倍”。实际吞吐量仍取决于专家并行、KDA 内核、量化格式、跨节点网络和推理框架实现。
官方对能力的表述其实比较克制
Kimi 官方技术博客明确写道：K3 的整体性能仍落后于 Claude Fable 5 和 GPT-5.6 Sol，但在其评测套件中超过了其他被测试模型。
官方展示的重点不是简单问答，而是长时间自主执行：
- 在相同沙箱中持续优化 GPU Kernel。
- 从零构建带有 Tile IR、MLIR Pass 和 PTX 代码生成的 MiniTriton 编译器。
- 通过截图反馈迭代前端、3D 游戏和 CAD 任务。
- 在 48 小时自主任务中使用开源 EDA 工具设计并验证芯片原型。
- 阅读论文、编写数值程序并完成端到端科研分析。
这些案例能说明模型的目标方向，但仍属于厂商提供的案例。代码、完整轨迹、Token 消耗、失败样本和复现环境是否公开，会直接影响它们的证据强度。
API 计费与 Token 成本边界
官方文档列出的基础计费单价如下，单位均为每 100 万 Token。这里保留数字是为了计算不同上下文与输出长度下的调用成本：
| 计费项 | 文档单价 |
|---|---|
| 输入 Token，命中缓存 | 0.30 美元 |
| 输入 Token，未命中缓存 | 3.00 美元 |
| 输出 Token | 15.00 美元 |
| 上下文窗口 | 1,048,576 Token |
Kimi 帮助中心还列出 Web Search 每次调用 0.004 美元。不过 K3 文档同时提示，Web Search 正在更新，近期不建议用于生产流程。进行系统设计时，应把模型 Token、工具调用和失败重试分别计量。
三个成本例子
假设不考虑税费和其他工具费用：
| 场景 | 计算 | 费用 |
|---|---|---|
| 10 万输入 + 5000 输出，输入未缓存 | 0.1 × $3 + 0.005 × $15 | 0.375 美元 |
| 同一长前缀命中缓存 + 5000 输出 | 0.1 × $0.3 + 0.005 × $15 | 0.105 美元 |
| 100 万输入 + 10 万输出，输入未缓存 | 1 × $3 + 0.1 × $15 | 4.50 美元 |
这里最值得注意的不是输入单价本身，而是输出长度和推理过程。
K3 当前始终开启思考模式，并且只能使用 max 推理强度。如果一个任务产生大量 reasoning_content，即使用户最后只看到几百字答案，账单也可能主要来自推理和输出 Token。
因此，K3 当前更适合高价值、长流程任务，不适合不加区分地替换所有普通对话接口。
现在可执行的 API 接入
Kimi API 兼容 OpenAI SDK。Python 3.9 以上环境可以按下面的方式安装：
python -m venv .venv
# Linux / macOS
source .venv/bin/activate
# Windows PowerShell
.venv\Scripts\Activate.ps1
python -m pip install --upgrade "openai>=1.0"
在环境变量中保存 API Key，不要把密钥写进代码仓库：
# Linux / macOS
export MOONSHOT_API_KEY="你的 API Key"
# Windows PowerShell
$env:MOONSHOT_API_KEY="你的 API Key"
最小调用代码如下：
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="max",
max_completion_tokens=8192,
messages=[
{
"role": "system",
"content": (
"你是代码审查助手。先定位高风险问题，再给出最小修改方案；"
"没有证据时不要猜测。"
),
},
{
"role": "user",
"content": "请审查下面的并发任务队列实现，并给出修改后的代码。",
},
],
)
message = response.choices[0].message
print(message.content)
print(response.usage)
建议显式设置 max_completion_tokens。官方默认值是 131072，最高可以设置到 1048576；如果业务不需要超长输出，不设置上限会放大异常任务的成本风险。
流式输出要分别处理推理和答案
stream = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="max",
max_completion_tokens=8192,
stream=True,
stream_options={"include_usage": True},
messages=[{"role": "user", "content": "分析这个项目的模块依赖并给出重构顺序。"}],
)
for chunk in stream:
delta = chunk.choices[0].delta
reasoning = getattr(delta, "reasoning_content", None)
if reasoning:
print(reasoning, end="", flush=True)
if delta.content:
print(delta.content, end="", flush=True)
在生产环境中，通常不应把完整思考内容直接展示给最终用户。更稳妥的做法是把 reasoning_content 与最终 content 分开处理，只记录必要的运行指标，并遵守业务数据与日志安全要求。
多轮对话和工具调用的几个坑
K3 虽然使用 OpenAI 兼容接口，但不是把模型名替换掉就万事大吉。
第一，K3 目前只支持 reasoning_effort="max"。不要继续使用 K2.x 的 thinking 参数。
第二，temperature=1.0、top_p=0.95、n=1、presence_penalty=0 和 frequency_penalty=0 已固定。官方建议从请求中省略这些字段。
第三，在多轮对话和工具调用中，必须把 API 返回的完整 Assistant Message 放入下一轮历史，不能只保留 content。工具执行结果还必须使用对应的 tool_call_id 回传。
第四，视觉输入不支持直接传公网图片 URL，应使用 Base64 Data URL 或 ms://<file-id>。
第五，K3 支持 tool_choice="none"、"auto" 和 "required"，也支持动态加载工具定义。对于高风险操作，应在应用层继续保留权限检查和人工确认，不能只依赖 Prompt。
百万上下文怎么用才不浪费
K3 的普通请求会自动尝试上下文缓存，不需要手动创建 Cache ID 或指定 TTL。
要提高命中率，应把不经常变化的内容放在最前面，并保持长前缀完全稳定，例如：
- 固定 System Prompt。
- 固定代码仓库索引或知识库正文。
- 固定工具定义。
- 把每次变化的问题放在消息末尾。
不要在长前缀里插入当前时间、随机 ID 或动态排序内容，否则很容易破坏缓存复用。
生产环境还应记录 prompt_tokens、缓存命中 Token、推理 Token、答案 Token、首 Token 延迟和完整任务耗时。百万上下文是容量上限，不是每次请求都应该填满的目标。
API 接入的工程化注意事项
如果暂时不自托管模型，可以把 K3 当作外部推理服务，在自己的业务侧部署一层轻量网关：
业务客户端
│
▼
鉴权与配额网关
│
├── Prompt 模板与敏感信息处理
├── Token 预算、超时与取消
├── 工具权限与人工确认
├── 重试、熔断与降级模型
└── Usage、延迟和质量指标
│
▼
Kimi API
上线时至少应增加以下控制：
- 将 API Key 放进 Secret Manager，而不是镜像或配置文件。
- 给单次请求设置输入、输出和工具调用预算。
- 仅对网络错误、限流和部分 5xx 做带抖动的指数退避；不要盲目重试已经执行过外部动作的 Agent 请求。
- 使用流式接口并支持客户端取消，避免用户断开后模型继续产生高价输出。
- 对长任务保存状态，区分模型失败、工具失败和业务校验失败。
- 为普通聊天准备更便宜的模型，只把复杂编程与知识工作路由到 K3。
- 上线前用自己的任务集统计“每个成功任务成本”，不要只比较每百万 Token 单价。
K3 发布约两天后，Hacker News 主讨论帖已经达到约 1995 Points 和 1161 条评论。讨论热度很高，但可归纳成四类较稳定的观点。
第一类：关注点集中在架构和长程任务
部分社区讨论认为，开放模型与高规格闭源模型之间的差距正在缩小。KDA、AttnRes、896 专家 MoE，以及官方展示的 GPU 编译器、芯片设计和长程科研任务，是讨论较多的部分。
爱范儿的首轮体验也更偏正面：其团队使用 K3 完成了多个 Three.js 场景、交互系统和应用原型，认为 K3 在前端视觉、交互实现和持续迭代方面表现突出。Code Arena 首发榜单中，K3 以 1679 分位于前端代码榜首。不过这类榜单更接近人类偏好盲测，能够反映前端成品偏好，不能替代后端正确性、可维护性和生产稳定性评测。
第二类：单位任务成本取决于推理长度
社区对 K3 的 Token 消耗存在较多讨论。由于当前只能启用 max 推理强度，静态单价并不能直接代表一个任务最终需要的预算。
真正影响成本的是推理 Token。开发者 Simon Willison 分享的一个 SVG 生成案例只有 95 个输入 Token，却生成了 16658 个输出 Token，其中 13241 个是推理 Token，按官方价格约为 0.25 美元。单个案例不能代表平均水平，但它很好地说明了“输出偏长”为什么会放大账单。
第三类：独立评测很强，但速度与冗长是现实问题
Artificial Analysis 给 K3 的 Intelligence Index 评分为 57，在其 7 月 18 日页面收录的 187 个同类模型中排名第 4；测得输出速度约为每秒 62 Token，低于同类平均的 71 Token。
该机构还指出，K3 在完整 Intelligence Index 测试中生成约 1.30 亿输出 Token，而同类平均约为 6300 万，评价是“较慢、非常冗长、价格偏高”。其页面更新后的完整评测模型费用约为 2709.75 美元；这类动态统计会随着评测集和计费记录调整。
这些数据补充了厂商提供的评测结果，但仍不是所有业务的统一答案。编程 Agent、法律分析和普通客服的 Token 分布完全不同，最终仍要回到自己的任务集。
第四类：开放状态仍待权重与许可证确认
7 月 18 日再次核对 MoonshotAI 官方 GitHub，组织中仍没有 Kimi K3 权重仓库，Artificial Analysis 也暂时将其标为 Proprietary Model。原因并不复杂：权重尚未发布。
官方已经给出 7 月 27 日这一明确期限。届时最需要检查的不是下载按钮，而是许可证是否允许商用和再分发、是否提供官方量化版本、主流推理框架是否同步支持，以及技术报告能否解释评测与部署细节。
对 K3 后续发展的预估
短期内，K3 更可能首先用于长程编程、前端与视觉联动、复杂报告生成，以及需要大上下文的 Agent 任务。普通聊天、短摘要和高吞吐分类任务较难支撑当前的推理成本。
官方已经表示后续会增加低和高推理强度。如果这些档位能明显减少推理 Token，K3 的单位任务成本和延迟会获得更大的调节空间。
K3 后续能否形成更广泛的开发者生态，主要取决于四件事：
- 权重与许可证能否按时、完整地发布。
- KDA 和超稀疏 MoE 能否迅速获得高性能开源推理内核。
- 独立评测和企业实测能否复现官方的长程任务能力。
- 低推理强度与量化版本能否降低单位成功任务的成本。
在这些信息公布以前，更合适的观察重点仍然是 API 的真实任务表现、推理长度、工具调用稳定性和百万上下文效果，而不是提前估算尚不可执行的本地部署方案。
参考资料
- Kimi：Kimi K3: Open Frontier Intelligence，2026-07-16
https://www.kimi.com/blog/kimi-k3 - Kimi API：Kimi K3 快速上手
https://platform.kimi.ai/docs/guide/kimi-k3-quickstart - Kimi API：Kimi K3 官方定价
https://platform.kimi.ai/docs/pricing/chat-k3 - Kimi API：OpenAI API 兼容说明
https://platform.kimi.ai/docs/guide/migrating-from-openai-to-kimi - MoonshotAI GitHub 组织
https://github.com/MoonshotAI - Artificial Analysis：Kimi K3 Intelligence, Performance & Price Analysis
https://artificialanalysis.ai/models/kimi-k3 - Hacker News：Kimi K3: Open Frontier Intelligence 讨论帖
https://news.ycombinator.com/item?id=48935342 - 爱范儿：连夜实测 Kimi K3，建议改名 Kable
https://www.ifanr.com/1672232 - 新华社：Chinese company releases world’s largest open-source AI model，2026-07-17
https://english.news.cn/20260717/66d0dd4a939b430ab2334c766a92ea93/c.html
更多推荐
18
0- 0
已为社区贡献13条内容
所有评论(0)