Kimi API key (.cn)怎么用？国内站接入与踩坑实录
上周有个做跨境电商的朋友半夜给我发消息，说他的客服机器人全部报 401，代码一行没动，前天还好好的。我让他把 key 贴出来看了一眼就笑了——他用的是国际站申请的那串凭证，但 `base_url` 写的是 `api.moonshot.cn`。两套体系根本不认对方。
这种坑我见得太多了。Kimi 的开放平台在国内站（platform.moonshot.cn）和国际站是分开运营的，账号、余额、key 彼此独立。很多人图省事直接翻 .ai 的文档照着写，结果就是 key 和接入点对不上，报错还看不出原因。所以这篇我想把 Kimi API key (.cn) 这件事从头讲清楚：它到底是什么、怎么申请、怎么跑通第一条请求，以及我真实项目里踩过的几个坑。
核心结论摘要：Kimi API key (.cn) 是指在月之暗面国内开放平台（platform.moonshot.cn）创建的 API 凭证，格式以 `sk-` 开头，只能配合 .cn 域接入点 `https://api.moonshot.cn/v1` 使用。它与国际站（.ai）的 key 属于两套独立账号体系，互相不通用，混用会直接返回 401 鉴权失败。
Kimi API key (.cn) 是什么？和 .ai 的 key 有何不同
先把定义说清楚，不然后面全是糊涂账。
那 .cn 和 .ai 到底差在哪？我用一张表说清楚，这也是我最常被问的问题：
| 对比项 | 国内站（.cn） | 国际站（.ai） | | --- | --- | --- | | 平台入口 | platform.moonshot.cn | platform.moonshot.ai | | 接入点 base_url | `https://api.moonshot.cn/v1` | `https://api.moonshot.ai/v1` | | 账号体系 | 手机号注册 + 实名认证 | 邮箱注册 | | 结算货币 | 人民币 | 美元 | | key 通用性 | 与 .ai 不互通 | 与 .cn 不互通 | | 适用对象 | 国内开发者、需合规备案的业务 | 海外业务、海外主体 |
这张表里最要命的一行是"key 通用性"。我见过至少三个团队是因为开发环境用 .ai 的 key、生产环境切到 .cn 却忘了换凭证，排查了大半天。记住一句话：key 和 base_url 必须来自同一个站点，成对出现。
有意思的是，两边的 SDK 用法几乎一模一样，都兼容 OpenAI 的接口格式，这也正是混淆高发的原因——代码长得太像了，只有那一行 `base_url` 和那串 key 不一样。
申请与接入实操：跑通第一条请求
申请流程其实不复杂
整个流程我走过好几遍，个人开发者大概十分钟能搞定：
- 打开 platform.moonshot.cn，用手机号注册并登录；
- 完成实名认证（个人认证或企业认证，这是国内合规硬性要求，不认证拿不到可用的 key）；
- 进「API Key 管理」页面，点创建，系统会生成一串 `sk-` 开头的凭证；
- **立刻复制保存**——这串东西只在创建时完整显示一次，关掉页面就看不到了；
- 按需充值。新账号一般会有一定的体验额度，具体额度和有效期以官方页面为准，别拿旧文章里的数字当准。
这里插一句我的建议：别把 key 直接硬编码在代码里。我带过的一个实习生就是这么干的，然后把代码 push 到了公开仓库，第二天收到账单短信。用环境变量，或者用密钥管理服务，几秒钟的事。
认证机制：一个 Bearer 头就够了
Kimi API key (.cn) 用的就是最标准的 Bearer 鉴权，没有 OAuth 那套来回跳转的流程。请求时在头部带上：
Authorization: Bearer sk-你的key Content-Type: application/json
原理很直白：服务端拿到这个 key 后，去数据库里查它对应哪个账号、有没有余额、有没有权限调到你要的那个模型，任何一环对不上就返回 401 或 403。
跑通第一条请求
下面这段 Python 代码我调过很多次，可以直接跑（前提是 `pip install openai`，国区访问 .cn 接入点不需要代理）：
pip install "openai>=1.0"
from openai import OpenAI
关键点：.cn 站点的 key 必须配 .cn 的 base_url，成对使用
client = OpenAI( api_key="sk-你的国内站APIKey", # 在 platform.moonshot.cn 创建 base_url="https://api.moonshot.cn/v1", # 注意这里是 .cn，不是 .ai )
resp = client.chat.completions.create( model="moonshot-v1-8k", # 先用最小的模型验证链路 messages=[ {"role": "system", "content": "你是 Kimi。"}, {"role": "user", "content": "用一句话解释什么是 MoE 架构。"}, ], temperature=0.3, # 对话类任务建议 0.3 附近，稳定且不发散 )
打印模型返回的正文
print(resp.choices[0].message.content)
如果你的网络环境不方便装 SDK，用 curl 也能验证：
curl https://api.moonshot.cn/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $MOONSHOT_API_KEY" \ -d '{ "model": "moonshot-v1-8k", "messages": [{"role": "user", "content": "你好"}] }'
第一条请求能拿到回复，说明 key、接入点、余额三件事都对上了。整个过程我建议先用 `moonshot-v1-8k` 这种便宜的小模型试水，别上来就撩最大的那个，浪费钱。
模型选型与成本控制
选模型这件事，坦白讲，大多数人是在"用牛刀杀鸡"。我见过用 128k 模型去做文本分类的，成本是必要开销的十几倍。
月之暗面国内站目前主流的几款模型大致是这样的定位（具体可用列表和定价以官方文档为准，他们更新挺频繁）：
| 模型 | 上下文 | 定位 | 适合干什么 | | --- | --- | --- | --- | | moonshot-v1-8k | 8K | 轻量快跑 | 文本分类、短对话、格式清洗 | | moonshot-v1-32k | 32K | 中长文本 | 合同抽取、报告摘要、会议纪要 | | moonshot-v1-128k | 128K | 超长上下文 | 长文档问答、代码库理解 | | kimi-latest | 动态 | 指向最新主力模型 | 通用对话、需要持续跟新能力 | | 视觉系列 | 8K/32K/128K | 多模态大模型 | 图片理解、图表问答、OCR 场景 |
这里我要多说一句关于 Kimi K2 的事。根据《Kimi K2 技术报告》（arXiv:2507.20534，2025年7月发布），K2 采用的是 MoE（混合专家）架构，总参数量达到 1T，但每个 token 只激活其中约 32B 的参数。这个设计的意义在于——它把"大模型推理的成本"和"大模型的容量"这两件事解耦了。你享受到了万亿参数级别的知识容量，实际算力开销却接近一个 30B 级别的稠密模型。这对我们做应用的人来说，最直接的感受就是长上下文的单次调用价格比想象中低。
不过话说回来，MoE 也不是没有代价。激活参数少意味着单次前向计算的并行度设计更复杂，首 token 延迟在某些负载下会抖。我在高峰期做过压测，同样的 prompt，响应时间波动能到 2 倍以上。所以对延迟敏感的场景，还是老老实实做重试和超时兜底。
成本控制上，我总结了几条自己一直在用的习惯：
- **先用小模型做 POC**，验证 prompt 有效再换大模型，别反着来；
- **警惕 system prompt 的隐性开销**，很多人塞了一大段角色设定，每轮对话都重复计费，长会话里这笔钱很可观；
- **开启流式输出**，用户感知快，也省得因为超时重试；
- **长文档做分段而不是整段塞**，除非真的需要全篇关联理解。
关于多轮对话的 token 管理，这块其实还有不少可以优化的空间，我在《大模型 API 调用成本优化实战》这类专题里会展开讲，这里先不跑题。
我在真实项目里踩过的坑
说几个血泪教训，都是真实发生过的。
第一个坑就是开头说的 key 和接入点不匹配。 症状是清一色 401，错误信息还很含糊。排查思路很简单：打印出你正在用的 `base_url` 和 key 前几位，确认是不是同一个站点的。
第二个坑是 key 里混入了空白字符。 从网页复制的时候，末尾经常带一个换行或空格，肉眼完全看不出来，但服务端一比对就挂。我们后来养成习惯，所有 key 在加载时先 `.strip()` 一下，这个小动作救过好几次命。
第三个坑和额度有关。 有一次生产环境突然大批请求失败，我第一反应是服务挂