关于大模型常见参数的说明，以及在OpenAI标准下的不同厂商的参数兼容性问题 原创

“ 理解模型的API参数，是我们使用好模型的前提，这也是很多人搞不明白为什么我配置了参数却没什么用，原因就是对不同模型厂商的参数理解不彻底。”

关于大模型的使用问题，其参数是其中非常重要的一个环节，原因就在于大模型的具体表现是由这些参数控制的；比如说temperature 就是用来控制模型的发散性参数。temperature的值越小，其输出的文本更确定，更适合对准确性要求更高的场景；其值越大，模型发散性越高，更适合情感，写作场景。

而stream参数是用来控制模型是否启用流式输出，在之前关于Langchain的文章中也提到过；任何上层应用框架控制流式输出或非流式输出，最终都是通过这个参数值进行控制的。

所以，今天我们就来梳理一下模型的参数，都有什么用，以及在兼容openai sdk标准的情况下，其参数是怎么传递的。

大模型的参数问题

在当前的大模型应用中，所有与大模型的交互都是通过模型参数控制的；当然这里所说的参数主要是指大模型的应用参数，或者说API参数，而不是指大模型本身动辄多少亿的权重参数。

任何基于大模型开发的上层框架，不论其怎么封装怎么设计，其最终调用大模型都是通过这些接口和参数进行的；比如说langchain的提示词模板，记忆等封装的花里胡哨的，但其最终只是会拼接成模型API所需要的messages模板参数。

一般情况下，大部门的模型厂商的模型参数都是差不多的，比如说model，messages，stream，temperature等我们最常用的参数，还有就是一些我们不怎么常用的参数，如top_k和top_p等。

虽然，现在的OpenAI基本上已经成为事实上的行业标准，不同的模型厂商参数也都在向OpenAI的参数标准进行靠拢，这样能实现不同模型之间的低成本迁移。

但是，不同的模型厂商虽然大部分参数都是差不多的，但由于不同厂商模型的特殊性或业务需求，因此不同的厂商也会有其独特的参数需求。

比如说关于函数调用——function call，在OpenAI和千问就有一些区别，以及​​​response_format格式化输出参数也不完全相同。​​​

​​​在前两年模型发展初期，各大模型厂商的参数和标准各不相同，因此就导致一个问题，那就是在不同模型厂商之间的迁移会变得很困难，需要重写一部分与模型交互的代码;特别是在前两年openai突然限制大陆地区的使用，因此当时国内的模型厂商很快就兼容了openai的协议标准，这样就可以把之前使用openai模型的应用快速迁移到国内的模型厂商。​​​

但毕竟还是那句话，每家模型厂商的业务和需求不同，即使再怎么兼容也会有部分微小的差异；因此，不同模型厂商为了同时兼容openai的标准，以及自身业务的需求，就对这些参数做了兼容；比如以千问为例，就是在openai sdk的参数中加了一个extra_body参数，其值是一个json对象，这样通过extra_body就可以传递一些openai没有但千问特有的参数。

如qwen3的思考模式就是通过传递extra_body={"enable_thinking": False}参数来实现的。

而对上层应用框架来说也是如此，以Langchain为例，其通过再上层接口中提供model_wargs和extra_body来兼容底层不同的模型厂商，openai，qwen，deepseek等，以及不同的部署框架vllm，ollama等。

所以，从应用者的角度来看，搞懂这些模型参数对我们开发大模型应用有着巨大的帮助；而且这也是模型本地部署必须要解决的一个问题，相同的模型使用不同的部署框架，可能其参数和效果都会不一样。

本文转载自​​AI探索时代​​ 作者：DFires