主流AI大模型（LLM）API介绍

整体而言，OpenAI的LLM API已成为行业事实标准，其他厂商的API要么完全兼容OpenAI规范，要么在细节上存在少量差异。实际开发中，若需切换不同厂商的LLM API，主要有两种便捷方式：使用兼容中转平台，或借助兼容SDK统一调用。

一、OpenAI 核心API介绍

OpenAI提供了三类核心API，覆盖模型查询、传统聊天交互、现代Agent开发等场景。

1. GET /v1/models

请求说明

请求方式：GET（无需请求体 body）；

常见参数（Query）：无必填参数

响应示例

javascript 复制代码

{
  "object": "list",
  "data": [
    {
      "id": "gpt-5.4",
      "object": "model",
      "created": 1735689600,
      "owned_by": "openai"
    },
    {
      "id": "gpt-5.4-mini",
      "object": "model",
      "created": 1735689600,
      "owned_by": "openai"
    }
    // ... 更多模型 
  ]
}

调用示例

javascript 复制代码

curl https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"

2. POST /v1/chat/completions（传统聊天补全接口）

基础文本对话、代码生成、知识问答等常规场景；

body核心请求字段

model（string，必填）：指定调用的模型名称，如 "gpt-5.4" 或 "gpt-5.4-mini"；
messages（array，必填）：对话消息列表，每条消息需包含 role（角色：system/user/assistant/tool）和 content（消息内容）；
temperature（number，默认1.0）：控制输出随机性，取值范围0~2，值越低输出越确定、越严谨；
max_tokens（integer）：限制模型输出的最大token数量；

其他可选字段：top_p、frequency_penalty、presence_penalty（控制输出多样性）、stream（是否流式输出）、tools/tool_choice（函数调用）、response_format（结构化输出，如JSON Schema）。

调用示例（curl）

javascript 复制代码

curl https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
  "model": "gpt-5.4-mini",
  "messages": [
    {
      "role": "system",
      "content": "你是一个有帮助的助手。"
    },
    {
      "role": "user",
      "content": "讲一个笑话"
    }
  ],
  "temperature": 0.7
}'

响应关键字段

choices $0$ .message.content：模型返回的核心文本内容；
usage：token使用量统计，包含prompt_tokens（输入token数）和completion_tokens（输出token数）。

响应示例（简化版）

javascript 复制代码

{
  "id": "chatcmpl-8Z7XyW2vQ4bN6mK8pL0sT1uR3",
  "object": "chat.completion",
  "created": 1735776000,
  "model": "gpt-5.4-mini",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "为什么AI不会感冒？因为它只有芯片，没有鼻芯片！"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 28,
    "completion_tokens": 15,
    "total_tokens": 43
  }
}

补充说明：stream参数与SSE协议

stream参数

stream是/v1/chat/completions接口的可选参数，用于控制模型的响应方式：

stream=false（默认）：非流式输出，模型完成全部内容生成后，一次性返回完整JSON响应；
stream=true：流式输出，模型生成内容时，会将结果按token片段逐步返回，而非等待全部生成完毕，适合聊天界面、实时交互（如各模型厂商的网页端的打字效果）。

SSE协议（流式输出的实现方式）

当stream=true时，OpenAI API会通过SSE（Server-Sent Events，服务器向客户端推送事件）协议返回流式数据，SSE是一种基于HTTP的简单推送协议，可实现服务器向客户端单向、持续地推送数据，无需客户端频繁发起请求。

3. POST /v1/responses

OpenAI目前主力推荐的接口，相比传统的Chat Completions接口更现代、更强大，尤其适合构建Agent类应用。

核心优势

支持原生多模态输入，可同时传入文本、图像等内容；
内置对话状态管理，无需每次请求手动传入完整对话历史，降低开发成本；
强化Agent能力，支持工具调用、reasoning_effort（推理强度控制）、并行工具调用等；
支持background运行、context compaction（上下文压缩）等高级特性。

二、主流LLM API（非OpenAI）介绍

根据与OpenAI API的兼容程度，可分为「高度兼容」和「非完全兼容」两类。

1. 高度OpenAI兼容模型

这类模型的API Schema几乎与OpenAI的Chat Completions接口完全一致，开发时只需修改 base_url（接口地址）和 API Key，即可复用OpenAI的代码，无需大量适配。

DeepSeek：高度兼容OpenAI Chat Completions接口
Grok：完全兼容OpenAI格式，且在逐步适配Responses API风格
Qwen：提供OpenAI兼容模式，同时支持Responses API兼容调用（含内置工具等特性）；除此之外，Qwen还有自己的DashScope 原生 API，是 Qwen 最原生的接口，功能最完整，参数支持最丰富（支持深度思考、网页搜索等）
Kimi：支持OpenAI兼容接口，messages结构与OpenAI一致；工具调用和结构化输出基本沿用OpenAI格式，迁移时仅需修改base_url和API Key；长上下文场景下，输入格式无特殊变化。
GLM（智谱）/ MiniMax：均提供OpenAI兼容模式，Schema差异极小，messages + tools格式与OpenAI完全一致；

共同特点：多数模型优先支持Chat Completions风格接口，Responses API的兼容度因平台而异（Grok、Qwen支持较好）。

2. 非完全兼容模型（Schema有明显差异）

（1）Claude (Anthropic)

核心输入：messages数组（与OpenAI类似），但role限制更严格，仅支持user/assistant两种角色，system提示词需单独放在system字段中；
工具调用（Tool Use）：支持tools数组，但格式与OpenAI有差异（无"function"包裹层，字段命名略有不同）；
结构化输出：支持JSON格式，但需通过tools或特定参数实现，与OpenAI的response_format: json_schema不完全等同；
特色字段：包含cache_control（提示词缓存）、extended_thinking（模型思考过程）、max_tokens等专属字段；
响应格式：content以块数组形式返回，可能包含文本（text）和工具调用（tool_use）两种类型；
总结：核心交互概念与OpenAI类似，但字段命名、工具定义、响应结构无法直接互换，需针对性适配代码。

（2）Gemini (Google)

原生Schema差异：官方API Schema与OpenAI差异较大，需使用Google GenAI SDK或其原生REST格式调用；
核心输入：使用contents数组（而非OpenAI的messages），每个content包含text、inline_data（多模态数据）等部分；
工具调用：通过tools和tool_config配置，函数声明（function declarations）结构与OpenAI不同；
结构化输出：通过generation_config + response schema（JSON Schema风格，但配置位置与OpenAI不同）实现；

三、LLM API 统一调用解决方案

实际开发中，通常不会写死某一种LLM，而是通过配置动态切换模型。

但开发者不应该去学习每一种模型的API规范，也无需为每种模型单独实现------核心思路是统一为OpenAI格式，适配所有主流模型。主要有两种解决方案：

1. 使用中转平台

中转平台已做好多模型兼容适配，开发者只需按照OpenAI格式调用中转平台接口，由平台自动转发至目标模型，无需关注各模型的Schema差异。

海外：OpenRouter
国内：ofox.ai

2. 使用兼容性SDK

通过专门的兼容SDK，将不同厂商的API统一封装为OpenAI格式，开发者只需调用SDK的统一接口，即可切换任意支持的LLM。

OneAPI & LiteLLM：开源兼容SDK，支持众多主流LLM，统一输出OpenAI格式；