Open cssmagic opened 7 months ago
有不少群友已经在尝试 Kimi API 了，大家反馈的问题大多是共通的，因此魔法哥通过这篇文章统一解答一下。这些问题在调用其他大模型 API 时也有参考意义，建议收藏备用哦。
文章末尾还会跟大家分享一些 “内部消息”，让我们一起期待 Kimi API 的后续进展。
可能有小伙伴会问：“已经有网页版的 Kimi 智能助手了，我用得也挺好，为什么还需要 API？”
网页版的智能助手确实方便，但每次使用都需要登录网页进行对话，这对于程序化和自动化的场景就无能为力了。这里简单举两个例子：
你需要处理大批量的文本（比如翻译、改写、提炼大纲等），如果只能依靠网页对话，操作起来就十分繁琐。此时，如果你有一定的编程能力，就可以写一个脚本，通过 API 来调用大模型的能力，以程序化的方式实现批量处理，快捷高效。
你现在已经有一个对客户邮件做分类和转发的客服系统，现在想让它更智能一些，比如实现一定规则的自动回复。那我们就可以在这个系统中调用大模型的 API，对邮件内容进行判断和自动回复。
此外，现在已经有大量基于大模型 API 开发的工具，比如智能体搭建平台、浏览器插件等等。我们不需要自己从零开发，只需要在这些工具中配置好大模型 API 的访问途径，就可以享受这些工具的带来便利了。
Kimi 目前提供的 API 可以分为以下几类：
相信你已经看出来了，第二项 “模型推理” 就是最核心的能力。目前大型语言模型最典型的推理能力，就是 “对话式文本补全”，这也是行业标杆 ChatGPT 所引领的大模型工作模式。
Kimi API 前两项的接口设计是完全兼容 OpenAI 的，第三项接口也尽可能与 OpenAI 的设计保持一致。因此这三项都可以直接用通过 OpenAI 官方的 SDK 来调用，Kimi 官网的示例代码就是采用 OpenAI 的 Python 客户端库来写的。
这带来一个巨大的好处，理论上基于 OpenAI “Chat Completion” 接口的项目都可以用 Kimi API 跑起来。LangChain 等框架也可以把 Kimi API 当作 OpenAI 来调用。小伙伴们看到这里，是不是跃跃欲试了？
Kimi API 目前提供了三个规格的模型：moonshot-v1-8k / moonshot-v1-32k / moonshot-v1-128k。
moonshot-v1-8k
moonshot-v1-32k
moonshot-v1-128k
这三个模型在推理能力上没有区别，主要区别在于上下文窗口的大小。模型名称里的 8k、32k 和 128k 就是指模型的上下文窗口的 token 数量。而所谓 “上下文窗口”，是指模型一次能处理的输入和输出内容的总长度上限。
由于各个模型的计费标准随上下文规格递增，因此在选择模型时需要根据实际需求来判断。也就是说，我们在调用 API 之前，可以先评估一下输入长度和期望得到的输出的长度，然后选择一个合适的模型规格。
这里也简单科普一下 “token” 这个概念：大模型在处理自然语言的过程中，需要对原始文本进行分词操作，而 token 就是分词之后得到的字符片断。比如 “我知道了” 这句话，分词之后就是 “我”、“知道”、“了” 三个 token。
因此，token 数并不直接等同与单词数或汉字数。关于 token 与字数的对应关系以及不同模型的 “token 利用率”，魔法哥在 上期文章 有详细介绍，这里就不赘述了。
Kimi 目前只对 “Chat Completion” API 收费，按照 token 的实际用量来计费。即每次调用 API 时，根据输入和输出的 token 总量来计算费用。计费标准如下：
顺便一提，在 OpenAI 的 Chat Completion 接口中，输入和输出 token 的计费标准是不同的，输入比输出要便宜。而 Kimi 和其他国内大模型的 API 通常采用 “输入输出统一定价” 的计费模式。
讲到这里，大家肯定会关心：Kimi 的 API 定价到底贵不贵？
与国内其他大模型 API 的价格对比，Kimi 的定价属于中游水平。考虑到 Kimi 性能出色，这个价位还是相当划算的。
理论上来说，网页版 Kimi 智能助手和 API 背后的大模型能力是相同的。大家在实际使用中感受到的差异可能有以下两个原因：
网页版 Kimi 有联网搜索能力，而 API 则没有。如果开发者需要 Kimi 结合网络数据来回答问题，就需要自行调用其他搜索接口，然后把结果作为输入传给 API。
网页版 Kimi 内置了一套系统提示词，对其输出内容会有一定影响；而 API 的系统提示词是需要开发者手动提供的。当然我们可以参考网页版 Kimi 系统提示词的精髓，然后设计一个适合 API 调用的版本。
魔法哥把网页版 Kimi 的系统提示词存了一份在这里，大家可以仔细研究： github.com/cssmagic/Awesome-AI/issues/2
这确实是 AI 大模型与常规计算机程序的重要差异。大模型本质上是一种人工神经网络，它在推理过程引入了一定的随机性——即使每次的输入完全相同，输出结果也可能不同。
这种随机性在很多场景下是我们需要的，但在某些场景下可能会带来困扰。在这种情况下，我们有一些手段可以提升模型输出的可预测性和稳定性：
通过提示词对模型的输出进行更严格的约束。比如提供更详细的背景知识、更精确的格式要求、具体示例等等。
把 temperature 参数设置为一个较小的值。这个参数表示模型的采样温度，取值范围是 [0, 1]。较高的值（如 0.7）将使输出更加随机和发散，而较低的值（如 0.2）将使输出更加集中、更有确定性。
temperature
另外，如果你的应用确实存在反复调用相同输入的需求，可以考虑把模型的输出结果缓存起来，这样不仅响应更快，而且还能节省 API 调用成本哦。
当我们把大模型当作一个后端服务来使用时，通常期望它返回特定结构的 JSON 数据，以便与其他功能模块进行对接和交互。
OpenAI 的 Chat Completion 接口为了适应这种需求，提供了 JSON 模式。在调用接口时，把 response_format 参数设置为 { "type": "json_object" }，即可要求模型输出 JSON 格式的数据。
response_format
{ "type": "json_object" }
Kimi API 目前还不支持 JSON 模式（官方表示很快就会上线），但我们还是有一些手段可以实现 JSON 格式的输出：
通过提示词要求模型的输出特定格式的 JSON 数据，并提供示例。这种方法有效，但在极少数情况下模型的输出不一定完全符合要求。所以需要在应用层做好容错或重试处理。
有网友利用 Kimi API 的一个未公开的特性来强制模型输出 JSON 格式的数据，很有意思，大家也可以参考一下 ( zhuanlan.zhihu.com/p/687898495 )。不过请留意这个特性是 Kimi 私有的。
这里强调一下示例的重要性：如果没有示例，模型输出的 JSON 结构往往与我们的预期并不一致。包括 OpenAI 即使提供了 JSON 模式，也需要我们提供示例来约束其结构。
JSON 模式：如上面所说，Kimi API 很快就会推出 JSON 模式。
Function Calling：这是开发 AI Agent 的核心能力，Kimi 的 API 团队也是在以最高优先级在推进，估计很快就会发布。
多模态：图像识别能力已经成为大模型的标配了，Kimi 的多模态能力也在路上了，年内肯定会上。
200 万字上下文 API？这个功能应该会在网页版先上，估计到时候会作为付费套餐的特权推出，毕竟推理成本肯定会上一个台阶。而在 API 这一端，如果开放 200 万字上下文的模型，调用价格估计也会上天吧。所以各位开发者，还是好好修炼自己的 RAG 功力吧！
希望这篇文章能帮助到大家。如果你还有其他问题，欢迎在评论区留言，魔法哥会尽力解答！
新朋友请关注公众号，下次更新不迷路：
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏
有不少群友已经在尝试 Kimi API 了，大家反馈的问题大多是共通的，因此魔法哥通过这篇文章统一解答一下。这些问题在调用其他大模型 API 时也有参考意义，建议收藏备用哦。
文章末尾还会跟大家分享一些 “内部消息”，让我们一起期待 Kimi API 的后续进展。
大模型的 API 有什么用？
可能有小伙伴会问：“已经有网页版的 Kimi 智能助手了，我用得也挺好，为什么还需要 API？”
网页版的智能助手确实方便，但每次使用都需要登录网页进行对话，这对于程序化和自动化的场景就无能为力了。这里简单举两个例子：
你需要处理大批量的文本（比如翻译、改写、提炼大纲等），如果只能依靠网页对话，操作起来就十分繁琐。此时，如果你有一定的编程能力，就可以写一个脚本，通过 API 来调用大模型的能力，以程序化的方式实现批量处理，快捷高效。
你现在已经有一个对客户邮件做分类和转发的客服系统，现在想让它更智能一些，比如实现一定规则的自动回复。那我们就可以在这个系统中调用大模型的 API，对邮件内容进行判断和自动回复。
此外，现在已经有大量基于大模型 API 开发的工具，比如智能体搭建平台、浏览器插件等等。我们不需要自己从零开发，只需要在这些工具中配置好大模型 API 的访问途径，就可以享受这些工具的带来便利了。
Kimi 提供了哪些 API？
Kimi 目前提供的 API 可以分为以下几类：
相信你已经看出来了，第二项 “模型推理” 就是最核心的能力。目前大型语言模型最典型的推理能力，就是 “对话式文本补全”，这也是行业标杆 ChatGPT 所引领的大模型工作模式。
Kimi API 前两项的接口设计是完全兼容 OpenAI 的，第三项接口也尽可能与 OpenAI 的设计保持一致。因此这三项都可以直接用通过 OpenAI 官方的 SDK 来调用，Kimi 官网的示例代码就是采用 OpenAI 的 Python 客户端库来写的。
这带来一个巨大的好处，理论上基于 OpenAI “Chat Completion” 接口的项目都可以用 Kimi API 跑起来。LangChain 等框架也可以把 Kimi API 当作 OpenAI 来调用。小伙伴们看到这里，是不是跃跃欲试了？
Kimi 有哪些模型可以调用？模型之间有什么区别？
Kimi API 目前提供了三个规格的模型：
moonshot-v1-8k/moonshot-v1-32k/moonshot-v1-128k。这三个模型在推理能力上没有区别，主要区别在于上下文窗口的大小。模型名称里的 8k、32k 和 128k 就是指模型的上下文窗口的 token 数量。而所谓 “上下文窗口”，是指模型一次能处理的输入和输出内容的总长度上限。
由于各个模型的计费标准随上下文规格递增，因此在选择模型时需要根据实际需求来判断。也就是说，我们在调用 API 之前，可以先评估一下输入长度和期望得到的输出的长度，然后选择一个合适的模型规格。
这里也简单科普一下 “token” 这个概念：大模型在处理自然语言的过程中，需要对原始文本进行分词操作，而 token 就是分词之后得到的字符片断。比如 “我知道了” 这句话，分词之后就是 “我”、“知道”、“了” 三个 token。
因此，token 数并不直接等同与单词数或汉字数。关于 token 与字数的对应关系以及不同模型的 “token 利用率”，魔法哥在 上期文章 有详细介绍，这里就不赘述了。
API 如何计费？Kimi 定价贵不贵？
Kimi 目前只对 “Chat Completion” API 收费，按照 token 的实际用量来计费。即每次调用 API 时，根据输入和输出的 token 总量来计算费用。计费标准如下：
顺便一提，在 OpenAI 的 Chat Completion 接口中，输入和输出 token 的计费标准是不同的，输入比输出要便宜。而 Kimi 和其他国内大模型的 API 通常采用 “输入输出统一定价” 的计费模式。
讲到这里，大家肯定会关心：Kimi 的 API 定价到底贵不贵？
与国内其他大模型 API 的价格对比，Kimi 的定价属于中游水平。考虑到 Kimi 性能出色，这个价位还是相当划算的。
感觉调用 API 的回答效果和网页版 Kimi 智能助手不一样？
理论上来说，网页版 Kimi 智能助手和 API 背后的大模型能力是相同的。大家在实际使用中感受到的差异可能有以下两个原因：
网页版 Kimi 有联网搜索能力，而 API 则没有。如果开发者需要 Kimi 结合网络数据来回答问题，就需要自行调用其他搜索接口，然后把结果作为输入传给 API。
网页版 Kimi 内置了一套系统提示词，对其输出内容会有一定影响；而 API 的系统提示词是需要开发者手动提供的。当然我们可以参考网页版 Kimi 系统提示词的精髓，然后设计一个适合 API 调用的版本。
魔法哥把网页版 Kimi 的系统提示词存了一份在这里，大家可以仔细研究：
github.com/cssmagic/Awesome-AI/issues/2
为什么每次调用 API 返回的结果不一样？
这确实是 AI 大模型与常规计算机程序的重要差异。大模型本质上是一种人工神经网络，它在推理过程引入了一定的随机性——即使每次的输入完全相同，输出结果也可能不同。
这种随机性在很多场景下是我们需要的，但在某些场景下可能会带来困扰。在这种情况下，我们有一些手段可以提升模型输出的可预测性和稳定性：
通过提示词对模型的输出进行更严格的约束。比如提供更详细的背景知识、更精确的格式要求、具体示例等等。
把
temperature参数设置为一个较小的值。这个参数表示模型的采样温度，取值范围是 [0, 1]。较高的值（如 0.7）将使输出更加随机和发散，而较低的值（如 0.2）将使输出更加集中、更有确定性。另外，如果你的应用确实存在反复调用相同输入的需求，可以考虑把模型的输出结果缓存起来，这样不仅响应更快，而且还能节省 API 调用成本哦。
如何让模型返回 JSON 格式的数据？
当我们把大模型当作一个后端服务来使用时，通常期望它返回特定结构的 JSON 数据，以便与其他功能模块进行对接和交互。
OpenAI 的 Chat Completion 接口为了适应这种需求，提供了 JSON 模式。在调用接口时，把
response_format参数设置为{ "type": "json_object" }，即可要求模型输出 JSON 格式的数据。Kimi API 目前还不支持 JSON 模式（官方表示很快就会上线），但我们还是有一些手段可以实现 JSON 格式的输出：
通过提示词要求模型的输出特定格式的 JSON 数据，并提供示例。这种方法有效，但在极少数情况下模型的输出不一定完全符合要求。所以需要在应用层做好容错或重试处理。
有网友利用 Kimi API 的一个未公开的特性来强制模型输出 JSON 格式的数据，很有意思，大家也可以参考一下 ( zhuanlan.zhihu.com/p/687898495 )。不过请留意这个特性是 Kimi 私有的。
这里强调一下示例的重要性：如果没有示例，模型输出的 JSON 结构往往与我们的预期并不一致。包括 OpenAI 即使提供了 JSON 模式，也需要我们提供示例来约束其结构。
内部消息：Kimi API 的后续计划
JSON 模式：如上面所说，Kimi API 很快就会推出 JSON 模式。
Function Calling：这是开发 AI Agent 的核心能力，Kimi 的 API 团队也是在以最高优先级在推进，估计很快就会发布。
多模态：图像识别能力已经成为大模型的标配了，Kimi 的多模态能力也在路上了，年内肯定会上。
200 万字上下文 API？这个功能应该会在网页版先上，估计到时候会作为付费套餐的特权推出，毕竟推理成本肯定会上一个台阶。而在 API 这一端，如果开放 200 万字上下文的模型，调用价格估计也会上天吧。所以各位开发者，还是好好修炼自己的 RAG 功力吧！
参考资料
希望这篇文章能帮助到大家。如果你还有其他问题，欢迎在评论区留言，魔法哥会尽力解答！
新朋友请关注公众号，下次更新不迷路：
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏