近期AI热点003｜Kimi K3 技术拆解：2.8 万亿参数、API 接入与真实评价

xiaominglao

1116人浏览 · 2026-07-18 10:00:01

xiaominglao · 2026-07-18 10:00:01 发布

近期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