Kimi API 怎么接入？接口地址、价格与 key 申请实录
上周三晚上十一点，一个做 SaaS 客服的朋友给我发消息，说他老板要求两周内把系统从 GPT-4o 换成国产模型，问我"要不要重写整个后端"。我回他的第一句话是：如果只是换成 Kimi API，你大概率只需要改两行代码。
这不是安慰话。Kimi API 是目前国产大模型里对 OpenAI 生态兼容做得最彻底的那一档，`base_url` 加 `model` 两个字段一改，原来跑得好好的代码基本能直接复用。但真到落地的时候，身份认证、上下文档位、价格结构这些细节，踩坑的人一点都不少。
核心结论摘要：Kimi API 是指月之暗面（Moonshot AI）提供的、协议兼容 OpenAI 的模型调用接口。国内平台接口地址为 `https://api.moonshot.cn/v1`，key 需在 platform.moonshot.cn 申请；成本主要由上下文档位决定，8k 与 128k 档位单价差数倍，选对档位比讨价还价重要得多。
Kimi API 是什么：兼容 OpenAI 协议这件事最值钱
先把定义说清楚。Kimi API 是指由月之暗面开放给开发者的模型推理接口，调用的是 Kimi 背后的 moonshot 系列模型，而不是网页版那个聊天机器人。两者共用同一套底座，但 API 侧暴露的是标准的 `chat.completions` 协议。
很多人分不清"用 Kimi"和"接入 Kimi"。前者是你自己上网页提问，后者是你的程序去提问。区别在于：API 侧没有网页版的那些产品化封装（联网、插件、文件解析的交互层），你需要自己决定把哪些上下文塞进 prompt。
这里 K2 的发布是个分水岭。2025 年 7 月 Moonshot 开源的 Kimi K2 是 MoE 架构，总参数约 1 万亿、激活参数 320 亿左右，官方同时放出了 API 版本。这意味着过去只有大厂能玩得起的稀疏专家架构，现在一个独立开发者在控制台点几下就能调。坦白讲，这个开放节奏比同期不少国产大模型厂商都要激进。
接口地址与 key 申请：.cn 和 .ai 是两套互不相通的体系
这是我在 Kimi API 上踩的第一个坑，也是最容易致命的一个。
Moonshot 有国内和国际两个平台，域名不同，账号体系独立，key 完全不通用：
| 项目 | 国内平台 | 国际平台 | |---|---|---| | 控制台 | platform.moonshot.cn | platform.moonshot.ai | | 接口地址（Base URL） | `https://api.moonshot.cn/v1` | `https://api.moonshot.ai/v1` | | key 前缀 | `sk-` | `sk-` | | 通用性 | 仅限 .cn 端点 | 仅限 .ai 端点 |
注意表格最后一行。两边的 key 都是 `sk-` 开头，肉眼看不出区别，但拿 .cn 的 key 去请求 .ai 的端点，返回的会是 401。我第一次做灰度切换时就是复制粘贴错了 key，排查了快四十分钟，最后发现是域名和 key 配对错了。
Kimi API key (.cn) 的申请流程本身不复杂：注册账号 → 实名认证 → 控制台左侧"API Key 管理" → 新建 → 复制保存。有两点要提醒：
一是 key 只在创建时完整显示一次。页面刷新之后你就只能看到前几位和后几位了，所以必须先存进密钥管理工具再关页面。
二是 实名认证是硬门槛。国内平台不实名无法调用，这一步没有捷径。如果你在做海外业务、又不方便实名，那应该直接去 .ai 平台注册，别在 .cn 上折腾。
环境变量建议统一采用官方推荐命名，方便后续切环境：
.env 文件，切勿提交到 Git
MOONSHOT_API_KEY=sk-你的实际key MOONSHOT_BASE_URL=https://api.moonshot.cn/v1
Kimi API 价格：按上下文档位分档，选型比砍价更省钱
聊 kimi api价格之前得先明白一件事：Moonshot 的定价逻辑不是"模型越强越贵"，而是按上下文窗口分档。同一个底座模型，8k 档和 128k 档的价格能差好几倍。
截至我写这篇文章时的公开定价，大致是这个量级（具体数字请以 platform.moonshot.cn 的定价页为准，Moonshot 调价挺频繁的）：
| 档位 | 上下文上限 | 输入单价（元/百万 tokens） | 输出单价（元/百万 tokens） | 典型场景 | |---|---|---|---|---| | moonshot-v1-8k | 8K | 约 2 | 约 10 | 意图分类、字段抽取、短问答 | | moonshot-v1-32k | 32K | 约 5 | 约 20 | 长文摘要、多轮客服、代码问答 | | moonshot-v1-128k | 128K | 约 10 | 约 30 | 合同审阅、报告通读、整库检索 | | kimi-latest | 128K | 按实际指向档位计费 | 同左 | 需要联网/视觉的通用场景 |
看到这张表，很多人第一反应是"那我全用 8k 不就完了"。我劝你别急。上下文长度不够的时候，你的程序会报错，或者更糟——你被迫把长文档切成十几段分别调用，最后 token 总量反而比直接上 128k 还多。我在一个合同审阅项目里实测过：一份 5 万字的采购合同，切成 12 段走 8k 档，总消耗约 68 万 tokens；直接走 128k 档单次调用，消耗约 8 万 tokens。算下来后者反而便宜。
这个反直觉的结论，就是我说的"选型比砍价重要"。
128k 上下文为什么贵这么多：一次 prefill 的账
上面那个结论背后有实打实的技术原因，值得单独拆一段。
大模型推理分两个阶段：prefill 和 decode。prefill 是把你的整段输入一次性编码进 KV Cache，计算量随输入长度呈近似二次增长；decode 是逐 token 生成输出，每个新 token 都要和前面所有 token 做注意力计算。
关键点在于：长上下文贵的不是输出，而是 prefill 那一下。当你要处理 12 万 tokens 的输入，模型得先把这 12 万个 token 全部编码完才能吐出第一个字。这期间 GPU 得全程满载，而且是显存密集型的——KV Cache 本身就要吃掉大量显存，128k 上下文的 KV Cache 占用能到几十 GB 级别。
这就解释了为什么长上下文档位必须定价更高：它不是"服务更久"，而是"单次请求占用的显存和算力峰值更高"。你把 128k 的请求发过去，等于在推理集群上圈了一块很大的地，这块地在你生成完之前谁都别想用。
有意思的是，这也解释了为什么长上下文请求的首 token 延迟普遍偏高。我测过同一个 prompt 分别走 8k 和 128k 档，首 token 延迟差了接近一个数量级。做流式输出的时候这个体感特别明显——用户会盯着一个空屏幕等好几秒。
想更系统地理解这块，可以参考我们之前做的国产大模型推理成本横向对比，里面拆过不同厂商对 prefill 成本的定价策略差异。
用 OpenAI SDK 调 Kimi API：一段能直接跑的代码
理论说够了，上代码。因为协议兼容，你甚至不需要装 Moonshot 自己的 SDK，直接用 `openai` 包就行：
pip install openai>=1.0
from openai import OpenAI
client = OpenAI( api_key="sk-你的key", # 在 platform.moonshot.cn 创建 base_url="https://api.moonshot.cn/v1", # 注意 /v1 后缀不能漏 )
长文档摘要场景：直接走 32k 档，流式输出
stream = client.chat.completions.create( model="moonshot-v1-32k", messages=[
system 里明确输出格式，比在 user 里反复叮嘱有效得多
{"role": "system", "content": "你是合同审阅助手，只输出结构化结论，不要寒暄。"}, {"role": "user", "content": f"提取以下合同的风险条款，按【条款编号｜风险等级｜理由】格式输出：\n{doc}"}, ], temperature=0.2, # 抽取类任务压低温度，减少随机性 stream=True, )
for chunk in stream: delta = chunk.choices[0].delta.content if delta: # 部分 chunk 的 content 为 None，必须判空 print(delta, end="", flush=True)
三个实操细节：`base_url` 后面的 `/v1` 漏掉会直接 404；`temperature` 文档建议抽取类任务用 0.2~0.3，实际用下来确实比默认值稳定；流式返回里有些 chunk 的 `delta.content` 是 `None`，不判空会抛 `TypeError`。
函数调用和 JSON Mode 也支持，写法跟 OpenAI 那边基本一致，这里就不展开了。
我在三个项目里踩过的坑
说几个文档里不太会写、但实际会痛的点。
第一，128k 不等于"什么都能塞"。 我试过把一份 9 万字的招股书整个丢进 128k 档让它总结，结果模型对中间部分的细节召回明显变差。这跟"注意力在长序列上的衰减"有关，不是 Kimi 独有的问题。后来我的做法是：先用 8k 档做一轮粗筛，把相关章节挑出来，再走一次 32k 精读。两段式虽然多调一次，但准确率提升很实在。
第二，免费额度和速率限制要提前规划。 新账号有一定赠送额度，但调用频率限制比付费档位低不少。我做过一个压测脚本，跑免费档的时候频繁触发限流，后来改成带指数退避的重试逻辑才稳定下来。上线前务必用真实并发量压一遍。
第三，上下文长度和计费单位是两回事。 8k 档的意思是最多 8k tokens 的输入加输出总和，不是输入 8k 再送你输出额度。这块的边界在官方文档里写得很清楚，但第一次看容易扫过去。
关键要点速览
- **接口地址**：国内 `https://api.moonshot.cn/v1`，国际 `https://api.moonshot.ai/v1`，两套 key 不通用。
- **接入成本**：协议兼容 OpenAI SDK，迁移通常只需改 `base_url` 和 `model`。
- **价格逻辑**：按上下文档位计价，8k/32k/128k 三档，单价差数倍；长文档整段塞进去往往比切段便宜。
- **选型原则**：抽取分类走 8k，长文摘要走 32k，超长文档走 128k 或两段式；别为了省单价把文档切碎。
- **落地前必做**：确认 key 与端点域名配对、跑通限流重试、用真实并发压测。
相关推荐
继续深入：想系统理解大模型推理成本与长上下文的技术权衡，可以翻阅 VergeX 的「大模型」专题，我们从 prefill/decode、KV Cache 到 MoE 架构都做过拆解。
工具导航：如果你是第一次接触国产大模型的 API 集成，推荐从 VergeX AI 工具导航 入手，那里按调用场景分类整理了主流模型的接入文档与实测笔记，能帮你少走不少弯路。
订阅更新：Moonshot 的定价和模型版本更新节奏很快，本文涉及的数字可能会变。建议订阅 VergeX 更新（邮件或微信均可），我们会在官方调价或新模型上线后第一时间补充实测数据。