摘要 (Executive Summary)

随着生成式人工智能（GenAI）的快速迭代，大语言模型（LLM）已从单纯的技术验证走向大规模生产落地。然而，当前市场上的 LLM 服务提供商在 API 接口设计哲学上存在显著的分野。

本报告对全球与本土主流 LLM 服务商（OpenAI、Anthropic、Google、AWS、Azure、阿里百炼、百度千帆等）的 API 请求架构进行深度剖析。研究发现：市场正处于“开发者优先的 OpenAI 行业事实标准”与“云厂商优先的企业级资源治理架构”双轨并存的阶段。 本报告整理了请求格式的分类模型、参数映射关系、工程痛点，并提出了企业级集成时的架构应对策略。

---

一、 引言与 API 设计哲学分化

LLM API 规范的分化本质上源于各厂商核心定位与客户群目标的不同：

                    ┌─────────────────────────────────────────┐
                    │          LLM API 设计哲学分化            │
                    └────────────────────┬────────────────────┘
                                         │
                 ┌───────────────────────┴───────────────────────┐
                 ▼                                               ▼
     【开发者/原生开发者优先】                       【云基础设施/企业治理优先】
  代表：OpenAI, Anthropic, DeepSeek               代表：AWS Bedrock, Google Vertex, Azure
  · 以 Payload JSON 为核心                        · 以 URI 资源路由与 REST/RPC 为核心
  · 扁平化的 URL 设计                             · 严格的 IAM、区域划分与部署实例绑定
  · 极致的极简集成体验                             · 高度的多租户隔离与企业安全审计

1. 以 Developer Experience (DX) 为核心（开源/AI 原生派）：

• 采用“极简 HTTP 路径 + 全量 JSON 载荷（Payload）”的风格。模型被视为一种动态参数而非静态资源，追求几行代码即可完成调用。

2. 以 Enterprise Cloud Governance 为核心（传统云计算巨头派）：

• 采用严格的“REST 资源层级/RPC 动作路由 + 云原生鉴权（IAM/SigV4/API-Key）”风格。模型被视为云上的特定部署实例（Deployment）或托管资源，强调区域（Region）、配额（Quota）与访问控制（RBAC）。

---

二、 请求格式的三大分类模型

依据参数（模型标识、推理参数、上下文数据、鉴权凭证）在 HTTP 请求中的放置位置，可将主流请求格式划分为以下三类：

1. 全载荷主导型（Payload-Centric Design）

• 核心特征：HTTP 请求路径（URI Path）保持静态且高度统一（如 /chat/completions 或 /messages），绝大部分控制参数与推理参数均放置于 Request Body（JSON）中。

• 参数位置分布：

• Model ID：在 Request Body 中指定（如 "model": "gpt-4o"）。

• 推理参数：在 Request Body 中指定（如 temperature, top_p, max_tokens）。

• 鉴权凭证：放置于 HTTP Request Header（Authorization: Bearer <TOKEN>）。

• 代表厂商：OpenAI、Anthropic、Moonshot AI、DeepSeek、Groq、vLLM / Ollama 等。

2. 路径路由与 RPC 混合型（Path Routing & RPC Design）

• 核心特征：模型标识（Model ID）或特定的服务动作（Action Method）被直接硬编码在 URI 路径中。服务端通过 URI 路由决定底层硬件资源分配或处理逻辑。

• 参数位置分布：

• Model ID / 动作：在 URI Path 中指定（如 /models/gemini-1.5-pro:generateContent）。

• 推理参数：在 Request Body 内的嵌套字段中指定（如 generationConfig）。

• 鉴权凭证：使用 Header（AWS SigV4）或 Query String 参数（?key=xxx）。

• 代表厂商：Google Gemini (AI Studio / Vertex AI)、AWS Bedrock。

3. 部署代理与凭证增强型（Deployment & Query-Augmented Design）

• 核心特征：专为企业级多租户或按需部署场景设计。API 请求映射的不是通用“模型名”，而是用户在云平台上创建的“部署实例（Deployment ID）”或“服务 Endpoint”。

• 参数位置分布：

• Model ID / Endpoint：映射为 URI Path 中的资源节点（如 /deployments/{deployment-id}）。

• 系统级控制参数：通过 URI Query String（如 ?api-version=2024-02-01 或 ?access_token=xxx）传递。

• 推理参数：在 Request Body 中指定。

• 代表厂商：Azure OpenAI、百度文心千帆。

---

三、 主流服务商深度剖析与请求示例

1. OpenAI / Anthropic（标准 Payload 派）

• OpenAI：

POST /v1/chat/completions HTTP/1.1
Host: api.openai.com
Authorization: Bearer sk-proj-...
Content-Type: application/json

{
  "model": "gpt-4o",
  "messages": [{"role": "user", "content": "Hello"}],
  "temperature": 0.7,
  "stream": false
}

• Anthropic：

POST /v1/messages HTTP/1.1
Host: api.anthropic.com
x-api-key: sk-ant-...
anthropic-version: 2023-06-01
Content-Type: application/json

{
  "model": "claude-3-5-sonnet-20240620",
  "max_tokens": 1024,
  "messages": [{"role": "user", "content": "Hello"}]
}

2. Google Gemini API（路径 RPC 派）

Google 引入了类似 gRPC 的 REST 映射后缀（如 :generateContent），并将控制配置独立打包在 generationConfig 结构中：

POST /v1beta/models/gemini-1.5-pro:generateContent?key=YOUR_API_KEY HTTP/1.1
Host: generativelanguage.googleapis.com
Content-Type: application/json

{
  "contents": [
    { "role": "user", "parts": [{"text": "Hello"}] }
  ],
  "generationConfig": {
    "temperature": 0.7,
    "maxOutputTokens": 1000
  }
}

3. AWS Bedrock（底层云原生与 Converse API 双轨制）

• 原生 API（模型 ID 位于 URI，Body 依赖各模型原生的 Schema）：

POST /model/anthropic.claude-3-5-sonnet-20240620-v1:0/invoke HTTP/1.1
Host: bedrock-runtime.us-east-1.amazonaws.com
Authorization: AWS4-HMAC-SHA256 ...

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1000,
  "messages": [...]
}

• Converse API（云厂商推出的统一抽象 API）：

POST /model/anthropic.claude-3-5-sonnet-20240620-v1:0/converse HTTP/1.1

4. Azure OpenAI（云部署映射派）

Azure 将模型映射为 Endpoint 资源，且强制要求通过 Query String 传递版本号：

POST /openai/deployments/my-custom-gpt4/chat/completions?api-version=2024-02-01 HTTP/1.1
Host: my-resource.openai.azure.com
api-key: YOUR_AZURE_KEY

{
  "messages": [{"role": "user", "content": "Hello"}],
  "temperature": 0.7
}

---

四、 主流供应商全景对比矩阵

供应商 / 平台	核心 API 路径模式	模型标识 (Model ID) 位置	鉴权方式 (Authentication)	推理控制参数位置	OpenAI API 兼容度
OpenAI	/v1/chat/completions	Request Body (model)	Bearer Header	Body 直联	原版原生
Anthropic	/v1/messages	Request Body (model)	Custom Header (x-api-key)	Body 直联	结构不同 (系统词/Message分割)
Google Gemini	/v1beta/models/{model}:{action}	URI Path	Query Parameter / Bearer	Body (generationConfig)	需适配器转换
Azure OpenAI	/openai/deployments/{deploy-id}/...	URI Path (Deployment Alias)	Custom Header (api-key)	Body 直联	高 (除 URI/Header 外 Body 一致)
AWS Bedrock	/model/{modelId}/invoke	URI Path	AWS SigV4 签名	Body (依模型提供商而异)	低 (推荐使用 Converse API)
阿里百炼 (DashScope)	/api/v1/services/aigc/...	Request Body (model)	Bearer Header	Body (parameters)	提供专门兼容 Endpoint
百度千帆	/rpc/2.0/ai_custom/v1/.../{endpoint}	URI Path ({endpoint})	Query Parameter (access_token)	Body 直联	需转换 / 需看兼容模式
DeepSeek / Kimi	/v1/chat/completions	Request Body (model)	Bearer Header	Body 直联	100% 完全兼容

---

五、 工程集成中的异构痛点与挑战

在构建多模型路由（Multi-LLM Router）或企业级 GenAI 网关时，格式异构带来了以下四类核心工程挑战：

1. 字段语义与命名不一致 (Parameter Field Discrepancies)

不同供应商在推理参数的命名和数值范围上存在细微差别，容易引发运行时错误：

• 最大 Token 限制：OpenAI 过去使用 max_tokens（新版为 max_completion_tokens），Google 使用 maxOutputTokens，Anthropic 使用 max_tokens（且为必填项）。
• System Prompt 注入方式：
• OpenAI / DeepSeek：作为 messages 数组中的第一个元素 {"role": "system", "content": "..."}。
• Anthropic：作为 Body 顶层独立字段 "system": "..."（不得放入 messages 数组）。
• Google Gemini：放置在 systemInstruction 对象结构中。

2. 流式传输（Streaming Protocol）协议细节差异

虽然主流厂商均使用 Server-Sent Events (SSE) 进行流式响应，但数据块的包装逻辑不同：

• OpenAI / 兼容厂商：每一行以 data: {...} 开头，结束标志为 data: [DONE]。
• Anthropic：抛出具体的事件类型（如 event: content_block_delta），数据结构中包含显式的索引字段。
• Google Gemini：返回的是完整 JSON 数组的增量片断，而非单一的标准文本 Delta。

3. 鉴权与安全审计粒度碰撞

• 标准 API Key（如 OpenAI/Anthropic）易于管理，但难以细粒度控制网络边界与租户生命周期。
• 云原生 IAM/SigV4（如 AWS Bedrock）具备高安全性，但请求发起方必须引入复杂的签名算法 SDK，导致请求头膨胀且难以直接通过简单 HTTP 客户端调用。

---

六、 架构应对策略与演进趋势

1. 企业级集成架构设计建议

针对供应商 API 的异构性，推荐采用“适配器模式（Adapter Pattern）”构建统一网关层：

                      ┌─────────────────────────┐
                      │    企业内部应用客户端     │
                      └────────────┬────────────┘
                                   │  标准 OpenAI 格式 Request
                                   ▼
                      ┌─────────────────────────┐
                      │   统一 LLM 网关/中转层   │
                      │  (LiteLLM / One API)    │
                      └────────────┬────────────┘
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         │ (协议转换 & 参数映射)    │ (SigV4 签名 & URI 组装) │ (格式展开)
         ▼                         ▼                         ▼
┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
│ OpenAI / DeepSeek│      │   AWS Bedrock    │      │  Google Gemini   │
│  (Payload 模式)   │      │ (Path Routing)   │      │    (RPC 模式)    │
└──────────────────┘      └──────────────────┘      └──────────────────┘

• 使用开箱即用的中间件：引入如 LiteLLM、One API 或自研 Gateway，在网关层完成“OpenAI 交互协议 $\to$ 目标厂商协议”的双向映射（包含 Request 重组与 SSE Stream 转换）。
• 配置解耦：将 URI 模板、鉴权方式、模型 ID 映射关系抽离至环境变量或数据库配置表，避免代码硬编码。

2. 未来演进趋势

1. OpenAI 格式成为“事实上的应用层标准”：不仅开源大模型推理引擎（vLLM, TGI, Ollama, LM Studio）全面原生兼容 OpenAI 格式，包括阿里云百炼、百度千帆在内的云厂商也均已提供“OpenAI 兼容 Endpoint”。
2. 云厂商底层收敛（Unified APIs）：AWS 推出 Converse API，Google 推出 Unified AI SDK，云计算厂商正在逐步抹平内部不同基础模型之间的调用差异。

---

七、 结论

不同大模型服务供应商在请求格式上的差异，本质上是“AI 软件生态快速迭代的灵活性”与“传统云计算基础设施合规性与资源管理”之间的博弈与妥协。

在当前技术选型中，建议企业内部统一采用 OpenAI 规格作为标准的交互协议，并通过网关中间件去适配各公有云及私有部署的特定 URI 与 Body 格式。这种解耦架构能够最小化未来的供应商锁定风险，并大幅降低技术栈的维护成本。