首页/AI/AI 应用速查/月之暗面 Kimi 系列(K2 等)

月之暗面 Kimi 系列(K2 等)

月之暗面的模型线:moonshot-v1 长上下文系列(8k/32k/128k)起家,K 系列推理模型与 K2 开放权重 MoE 逐步接棒,API 兼容 OpenAI 协议。

AI 应用速查AI更新于 2026-10-13

Kimi 系列是什么

Kimi 是月之暗面(Moonshot AI)的模型线:早期以 moonshot-v1 系列(8k/32k/128k 三档上下文)打开长文档市场,之后推出 K 系列推理模型与 Kimi K2 这类开放权重的 MoE 模型。API 走 api.moonshot.cn 的 /v1/chat/completions,与 OpenAI 协议兼容,支持工具调用与结构化输出。K2 的开源版可自行部署,与官方 API 版在后训练与工具链上存在差异,两边的评测结论不能互换使用。

基本信息

厂商月之暗面 Moonshot AI
接入地址api.moonshot.cn/v1/chat/completions
协议兼容OpenAI Chat Completions 风格
鉴权方式Authorization: Bearer <API Key>
代表型号moonshot-v1-8k/32k/128k、Kimi K2 系列
计费口径按输入输出 token,长窗口输入按实际长度计价

典型使用场景

  • 长文档问答:合同、研报、论文整篇投喂后抽取结论与数据
  • RAG 生成端:把召回片段拼进上下文做二次归纳与比对
  • 国内合规替代:与 GLM、豆包组成多供应商路由池
  • 工具调用:作为 Agent 的规划与函数调用模型
  • 开源版自部署预研:内网数据不出域时先验证可行性
  • 多语言长文处理:跨语种文档摘要与要点翻译

长文档调用要点

长文档调用要点
# 密钥放环境变量
export MOONSHOT_API_KEY=你的密钥
# 长文本任务:文档在前、问题在后,末尾再复述一次约束
cat > payload.json <<'EOF'
{"model":"moonshot-v1-128k","temperature":0.3,"messages":[
  {"role":"system","content":"只依据给定文档回答,文档中没有就回答未提及"},
  {"role":"user","content":"<文档全文>\n\n问题:违约金比例是多少?"}]}
EOF
curl -s https://api.moonshot.cn/v1/chat/completions -H "Authorization: Bearer $MOONSHOT_API_KEY" -H "Content-Type: application/json" -d @payload.json

上下文档位怎么选

档位放进什么注意点
8k单轮问答、单段摘要整篇文档放不下,会截断丢信息
32k多段文档、中等长度报告成本随输入长度线性上升
128k整篇长手册、批量章节中段信息易被忽略,关键要求建议前后各说一次
K 系列推理、工具调用与 Agent 编排推理过程会占用输出 token,预算要放宽
moonshot-v1 与 K 系列是两条线:前者偏长文本吞吐,后者偏推理与工具调用。同一业务换线必须重跑评测集,不能沿用旧结论。
带日期或 preview 后缀的模型标识会定期下线,生产配置不要写死;调用报模型不存在时先查官方模型列表确认停用。

易错点

  • 把长窗口当全知:超长输入中段内容容易漏读,关键条款要在提问里重复强调或先做抽取
  • 订阅或调用写死 preview 模型标识:版本下线后接口直接报错,需保留稳定版兜底
  • 拿开源 K2 的效果当 API 版评测结论:后训练与工具链不同,能力分布有差异
  • 长文档任务不控制输入长度:一次塞满窗口,成本随长度上涨且延迟明显变高
  • 依赖单一供应商跑关键链路:缺少降级模型,上游抖动会直接中断业务

数据来源与参考

  • Moonshot AI 开放平台文档 platform.moonshot.cn

相关工具

​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌