Skip to main content
Kimi API 兼容了 OpenAI 的接口规范,你可以使用 OpenAI 提供的 PythonNodeJS SDK 来调用和使用 Kimi 大模型,这意味着如果你的应用和服务基于 openai 的模型进行开发,那么只需要将 base_urlapi_key 替换成 Kimi 大模型的配置,即可无缝将你的应用和服务迁移至使用 Kimi 大模型,代码示例如下:
我们会尽力保证 Kimi API 与 OpenAI 的兼容性,但在某些特殊场合,Kimi API 与 OpenAI 仍然存在一些差异和不同(但这不影响整体兼容性),我们将详细阐述 Kimi API 与 OpenAI 的不同点,并提出可行的迁移解决方案以帮助开发者顺利完成迁移工作。 以下是与 OpenAI 兼容的接口列表:
  • /v1/chat/completions
  • /v1/responses
  • /v1/models
  • /v1/tokenizers/estimate-token-count
  • /v1/users/me/balance
  • /v1/files
  • /v1/files/{file_id}
  • /v1/files/{file_id}/content
  • /v1/batches
  • /v1/batches/{batch_id}
  • /v1/batches/{batch_id}/cancel

temperature 和 N 值

当你使用 OpenAI 的接口时,你可以同时设置 temperature=0n>1,即在 temperature 值为 0 的场合,同时返回多个不同的回答(即 choices)。 然而在 Kimi API 中,当你将 temperature 的值设置为 0 或接近 0 时(例如 0.001),我们将只能提供 1 个回答(即 len(choices)=1,如果你在把 temperature 设置为 0 的同时,使用了一个大于 1 的 n 值,我们将返回一个”非法请求”错误,即 invalid_request_error 额外的,请注意:Kimi API 的 temperature 参数的取值范围是 [0, 1],而 OpenAI 的 temperature 参数的取值范围是 [0, 2] 迁移建议 对于 kimi-k2.6 模型,temperature 参数有特殊要求:
  • 思考模式下固定使用 temperature=1.0
  • 非思考模式下使用 temperature=0.6
如果指定其他值,将会报错。建议调用这些模型时不要显式设置 temperature,或按照上述要求设置。

stream 模式下的 usage 值

当你使用 OpenAI 的 chat.completions 接口时,在流式输出(即 stream=True)的场合下,输出结果默认不包含 usage 用量信息(包括 prompt_tokens/completion_tokens/total_tokens),OpenAI 提供了一个额外的参数 stream_options={"include_usage": True} 来使返回的最后一个数据块包含 usage 信息。 在 Kimi API 中,我们除了 stream_options={"include_usage": True} 参数外,还会在每个 choice 的结束数据块中放置 usage 信息(包括 prompt_tokens/completion_tokens/total_tokens)。 迁移建议:通常情况下,开发者不需要做任何额外的兼容性举措,如果你的业务场景需要统计每个 choice 各自的 usage 信息,可以访问 choice.usage 字段,注意:在不同的 choices 中,仅有 usage.completion_tokensusage.total_tokens 字段的值是不同的,choices 们拥有相同的 usage.prompt_tokens 值。

已被废弃的 function_call

OpenAI 在 2023 年提供了 functions 参数以开启函数调用(即 function_call)功能。经过功能迭代,OpenAI 后续推出了工具调用(即 tool_calls)功能,并将 functions 参数标记为已废弃(deprecated),这意味着在后续的 API 迭代中,functions 参数随时可能被移除。 Kimi API 完整支持了工具调用(即 tool_calls)的能力,同时,由于 functions 已被废弃,Kimi API 不支持使用 functions 参数执行函数调用 迁移建议:如果你的应用或服务依赖于工具调用(即 tool_calls),那么不需要做任何额外的兼容性举措;如果你的应用或服务依赖于已经废弃的函数调用(即 function_call),我们建议你迁移至工具调用(即 tool_calls),工具调用拓展了函数调用的能力,同时支持函数并行调用,关于工具调用的具体示例,可以参考我们的工具调用指南: 使用 Kimi API 完成工具调用(tool_calls) 下面是一个从 functions 迁移至 tools 的示例: 我们会将需要改造的部分代码以注释的形式呈现,并附上说明,以便于开发者能更好理解如何进行迁移。
本页示例默认使用最新模型 kimi-k3。K3 使用请求顶层 reasoning_effort 配置推理强度(支持 "low" / "high" / "max",默认 "max")。换用 kimi-k2.6 等其他模型时,只需替换 model 字段,但各模型的参数配置存在差异,详见模型参数参考

关于 tool_choice

kimi-k3 支持 tool_choice"none""auto""required"null。如果应用依赖 OpenAI API 的 tool_choice: "required" 来确保模型至少调用一个工具,迁移到 kimi-k3 后可以直接保留该配置:
kimi-k2.7-codekimi-k2.6 不支持 "required";迁移到这些模型时,请改用 "auto""none"