同名路径不同形状：一把 key 上各家后端的 /chat/completions 差异对照

为什么会有差异

许多 LLM API 聚合站都提供“OpenAI 兼容”的 /v1/chat/completions 端点。这意味着你可以用同一套 SDK 调用不同厂商的模型。但兼容不等于完全一致：每个模型家族最初的 API 设计不同，聚合层在转换时只能尽量对齐。结果就是，同一个字段在不同后端上可能被支持、被忽略、或者触发错误，而文档里往往不会逐一说明。

理解这些差异，能帮你写出更可靠的代码，避免在切换模型时出现难以排查的行为。

请求字段的常见处理方式

核心字段

model、messages、temperature、max_tokens、stream 这些核心字段，绝大多数后端都会正确处理。其中 messages 的角色（system/user/assistant）通常都能识别，但 system 消息的权重和位置可能因模型而异。

可选字段的三种命运

对于非核心字段，通常有三种情况：

1. 被支持：后端原生支持该字段，或聚合层能正确转换。
2. 被忽略（静默丢弃）：字段被接受但不产生任何效果，也不报错。
3. 报错：字段不被识别，请求返回 400 错误。

静默丢弃最危险，因为你以为它生效了，实际上没有。

各模型家族的具体差异

Claude（Anthropic）

Claude 的原生 API 与 OpenAI 格式差异较大。在兼容层下：

• system 消息通常会被提取并转换为 Anthropic 的 system 参数。
• temperature 支持，但有效范围可能被限制。
• logprobs、top_logprobs 通常不支持，可能被忽略。
• response_format 可能不支持 JSON mode，或只支持部分模式。
• tools 和 tool_choice 通常支持，但工具调用的返回结构在流式模式下略有不同。

GPT（OpenAI）

原生格式，因此支持最完整：

• 所有标准字段基本都支持。
• logprobs、top_logprobs 可用（但具体模型可能有限制）。
• responseformat 支持 jsonobject 和 json_schema（视模型而定）。
• tools、tool_choice 行为与官方文档一致。

DeepSeek

DeepSeek 提供 OpenAI 兼容接口，支持大部分常用字段：

• temperature、topp、maxtokens 正常。
• response_format 支持 JSON 输出。
• tools 支持函数调用。
• logprobs 可能不支持。

Qwen（通义千问）

Qwen 的兼容接口覆盖较广：

• 基本参数支持良好。
• response_format 支持 JSON 模式。
• tools 支持，但工具调用的细节可能与 OpenAI 略有出入。
• logprobs 通常不支持。

GLM（智谱）

GLM 的 OpenAI 兼容层支持常用参数：

• temperature、topp、maxtokens 可用。
• response_format 可能支持 JSON。
• tools 支持函数调用。
• logprobs 通常忽略。

Kimi（月之暗面）

Kimi 的兼容接口：

• 核心参数支持。
• response_format 支持 JSON 模式。
• tools 支持。
• logprobs 通常不支持。

注意：以上是基于常见情况的概括，实际支持情况会随模型版本和聚合层实现变化。

哪些字段容易被静默丢掉？

根据经验，以下字段在跨后端时最容易被忽略：

• logprobs 与 top_logprobs
• logit_bias
• user
• seed
• presencepenalty 与 frequencypenalty（部分后端支持，部分忽略）
• responseformat 中的 jsonschema（很多后端只支持 json_object）
• tools 中的 strict 模式

这些字段被忽略时，API 通常不会报错，你只能通过测试发现。

响应结构的差异

响应体大多遵循 OpenAI 格式，但细节有别：

• id 前缀不同，不要依赖它判断模型。
• usage 字段通常包含 prompttokens、completiontokens、total_tokens，但部分后端可能缺少某些子字段。
• choices[].finishreason 取值可能不同，例如 stop、length、toolcalls 之外的额外值。
• 流式响应中，delta 的结构基本一致，但工具调用的分片方式可能不同。

实用建议

1. 只依赖核心字段：如果代码需要在多个模型间切换，尽量只用 messages、temperature、max_tokens、stream 这些普遍支持的参数。
2. 对可选字段做能力检测：在关键流程中，先发一个简单请求测试字段是否生效，或查阅聚合站文档。
3. 不要假设字段生效：对于 logprobs、seed 等，如果结果不符合预期，先确认后端是否支持。
4. 统一错误处理：捕获 400 错误，并对不同后端的错误信息做归一化。
5. 记录模型标识：在日志中记录实际使用的模型，便于排查差异。

在聚合站上调用时

使用聚合 API 时，一个 API key 可以路由到多个模型。由于计费按官方价乘以系数，建议在开发阶段用低成本模型测试字段兼容性，再切换到生产模型。

如果你贡献自己的 key，返利按官方价乘以系数以 USDC 结算，这会影响你的成本结构，但不改变接口行为。

总之，把“OpenAI 兼容”理解为“核心接口兼容”，对可选字段保持谨慎，就能写出跨模型健壮的代码。