Kimi K3 API 怎么调用？长上下文要注意什么？
直接回答
Kimi K3 系列可以用 OpenAI 兼容接口调用，base_url 设为 https://token.easyapi.com/v1，model 填 kimi-k3 或 kimi-k3.1-pro 等目录中的型号即可。长上下文的输入 token 每次请求都计费，不要每次塞入全部资料，并用流式输出和输出上限控制延迟与花费。
月之暗面的 Kimi K3 系列可以在其官方开放平台调用，也可以通过提供 OpenAI 兼容接口的 AI 大模型 API 接入平台调用。在 EasyAPI 的公开目录里，目前有四个 Kimi 模型，其中 kimi-k3.1-pro-highspeed 是 2026-11-12 目录中新出现的型号。
调用本身很简单，真正需要花心思的是长上下文：窗口大不代表每次都该用满，输入越长，单次请求的费用和等待时间都越高。
关键要点
- EasyAPI 公开目录中的 Kimi 模型为
kimi-k3、kimi-k3.1-pro、kimi-k3.1-pro-highspeed、kimi-k2.7-code（截至 2026-11-12）。 - 按目录描述，Kimi K3.1 Pro 的上下文窗口约 100 万 token，思考模式常开，推理强度可按需调节。
- 按目录描述，K3.1 Pro 原生支持视觉理解，可接受视频输入，并支持函数调用与结构化输出。
- 三个 K3 系列模型在目录中都标注支持对话接口和 Responses 接口，
kimi-k2.7-code只标注对话接口。 - 按量计费下输入 token 每次请求都会计费，长上下文的成本主要来自重复发送的输入。
目录里的四个 Kimi 模型
下表内容来自 EasyAPI 公开目录中的模型描述：
| 模型 ID | 目录定位 | 支持的接口 |
|---|---|---|
kimi-k3 | 面向复杂编程、知识工作和长时间智能体任务的多模态推理模型 | 对话、Responses |
kimi-k3.1-pro | K3.1 系列首款模型，面向长程编程、3D 创作与金融研究等复杂任务，上下文约 100 万 token | 对话、Responses |
kimi-k3.1-pro-highspeed | 目录描述与 K3.1 Pro 相同，从名称看是它的高速版本 | 对话、Responses |
kimi-k2.7-code | K2 家族中侧重编程的型号，接受文本与图片输入，默认开启推理 | 对话 |
两点说明：目录没有给出高速版与标准版在速度上的具体差距，两者的单价也可能不同，请以模型广场的模型详情为准；kimi-k3 的目录描述没有注明上下文长度，需要长上下文时先在模型详情里确认。
调用示例
import os
from openai import OpenAI
client = OpenAI(
base_url="https://token.easyapi.com/v1",
api_key=os.environ["EASYAPI_API_KEY"],
)
with open("design-doc.md", encoding="utf-8") as f:
doc = f.read()
stream = client.chat.completions.create(
model="kimi-k3.1-pro-highspeed",
messages=[
{"role": "system", "content": "你是技术评审，只依据给出的文档回答。"},
{"role": "user", "content": f"{doc}\n\n请列出文档中互相矛盾的三处设计。"},
],
max_tokens=2000,
stream=True,
extra_body={"reasoning_effort": "low"},
)
for chunk in stream:
if chunk.choices and chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="")
reasoning_effort 是 EasyAPI 对话接口文档列出的字段，取值为 low、medium、high，用于支持推理的模型。Kimi K3.1 Pro 的思考模式常开，这个参数调节的是推理强度，而不是开关。
长上下文要注意什么
- 输入每次都计费。 多轮对话里如果每一轮都带上同一份长文档，这份文档会被重复计入输入 token。能先检索、切片再发送的，就不要整份塞进去。
- 看有没有缓存读取价格。 EasyAPI 的定价文档说明，配置了缓存倍率的模型会在详情里额外展示缓存读取价格。某个 Kimi 模型是否有这一项，以模型详情为准。
- 限制输出长度。 用
max_tokens设上限。思考过程也会产生输出 token，推理强度越高，耗时和费用通常越多。 - 用流式输出。 长输入的首字等待时间更长，流式能让你及时看到进度，也便于在客户端设置合理的超时。
- 把资料放前面、问题放最后。 这是长文档提问的通用写法，问题紧挨着回答位置，更不容易被忽略。
- 先小样本试算。 在请求体里加
usage: {"include": true}，响应的usage会多一个cost字段（本次费用，美元），用几条真实请求估出单次成本后再放量。
不适合的情况：如果任务只是短问答或简单分类，用约 100 万 token 窗口的旗舰型号并不划算，目录里其他更轻量的文本模型可能更合适。另外，视频输入在兼容接口下的具体传参方式，目录描述没有说明，使用前请查看模型详情或先做小规模测试。
常见问题
Kimi K3 的 API 可以直接用 OpenAI SDK 调用吗？
可以。把 base_url 设为 https://token.easyapi.com/v1，api_key 填 EasyAPI 的 Key，model 填目录中的 Kimi 模型 ID 即可，完整写法见 用 OpenAI Python SDK 调用国产大模型要怎么改代码。
kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed 有什么区别？
目录对两者的能力描述相同，区别体现在名称标注的「高速」上。速度和单价的实际差异目录没有写明，建议用同一批提示词分别调用，对比耗时和调用记录里的花费。
上下文有约 100 万 token，是不是可以把整个代码库都发过去？
技术上窗口够大，但不建议默认这样做。每次请求的输入都会计费，等待时间也更长，更稳妥的做法是只发送与当前问题相关的文件，确实需要全局视角时再发送全量内容。
怎么防止长上下文请求把余额花超？
可以给 API Key 设置周期预算，方法见 怎么给 API Key 设置每日/每月预算上限。同时在代码里限制 max_tokens，并先用少量请求核对单次费用。
小结
Kimi K3 系列通过 OpenAI 兼容接口即可调用，四个型号只需改 model 参数切换。使用长上下文时重点控制重复输入、输出上限和推理强度，并用真实请求试算成本。当前可用型号与实时价格见模型广场。