Chapter 03
多家 API 横向对比与选型
前两章讲清了原语和机制——它们在三家之间是共通的。这一章把 OpenAI、Anthropic、Google、开源本地放在一起：它们在哪些维度上不同、怎么按场景选、迁移时具体什么会断。数据截至 2026-06，定价为约数。
本章你将建立的 schema
- 一张对照表：上下文、价格、多模态、工具、结构化输出，各家的位置
- "OpenAI-compatible API"为什么成了通用语，以及它的边界
- 网关与本地部署各解决什么问题
- 按场景选型的决策树，以及迁移到另一家时具体哪些代码会断
3.1对照表：四类供应方
原语相同，但每家在能力边界、价格、强项上分化明显。下表是选型的起点，不是终点——具体数字会变，结构性差异不太会变。
| 供应方 / 代表模型 | 上下文 | 输入 / 输出价 | 多模态（输入） | 结构化输出 | 突出强项 |
|---|---|---|---|---|---|
| OpenAI · GPT-5.5 / 5.4 | ~400K | 5/30（5.4 档 2.5/15） | 图 + 音频 | strict json_schema（最强） | schema 可靠性、生态最广 |
| Anthropic · Opus 4.8 / Sonnet 4.6 | 1M | 5/25 ; 3/15 | 图（无音视频） | 原生 + 工具 schema | agentic / 长程任务、长上下文无附加费 |
| Google · Gemini 3.5 Flash / 3.1 Pro | 1M（Pro 至 2M） | 1.5/9 ; Lite 0.10/0.40 | 图 + 音频 + 视频 | responseSchema | 原生视频、质价比、Flash-Lite 极廉 |
| 开源本地 · DeepSeek V4 / Qwen / Llama 4 | 1M（Llama Scout 至 10M） | 自托管按算力；DeepSeek 托管约 0.44/0.87 | 图（视模型） | 看推理引擎（vLLM） | 可私有部署、license 宽松、价格极低 |
别只比"每 token 单价"。回到 §01.2：同一段文本各家 tokenizer 切出的 token 数不同；再叠加上下文是否有长度附加费、是否含 reasoning token、能否命中缓存。真实成本 = 单价 × token 数 × (1 − 缓存命中率)，单价只是其中一个因子。
3.2通用语：OpenAI-compatible API
OpenAI 的 /v1/chat/completions 请求形态成了事实标准，几乎所有供应方都额外提供一个"OpenAI 兼容"端点。
因为它把"换供应方"从"重写调用层"压缩成"改三个东西"：base_url、API key、model 字符串。Gemini（/v1beta/openai/）、Anthropic（api.anthropic.com/v1/）、DeepSeek、Mistral、Groq、Together、以及本地的 vLLM / Ollama / LM Studio 都暴露这个形态。一套代码，可在多家之间做 A/B 与回退。
# 未在本机验证——示例用途
from openai import OpenAI
# 指向 OpenAI
client = OpenAI(base_url="https://api.openai.com/v1", api_key=KEY_OAI)
# 指向本地 Ollama —— 只换了 base_url 和 model
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
resp = client.chat.completions.create(
model="qwen3.5", # 换家就换这个字符串
messages=[{"role": "user", "content": "订单 123 到哪了？"}],
)
OpenAI 兼容端点只覆盖"最大公约数"。各家原生独有的能力——Claude 的 prompt caching、extended thinking、原生结构化输出，OpenAI 的 strict 保证——经兼容层调用时往往被静默忽略。strict:true 走兼容层不报错，但也不再保证形状（回到 §2.2 的"没有掩码就只是倾向"）。结论：用兼容层做评测和原型可以，上生产要用原生 SDK 才能拿到全部特性。
3.3网关与本地部署
网关：一个接口，多家后端
- LiteLLM——开源、可自托管的代理 / SDK。统一成 OpenAI 形态，带按请求成本统计、回退、重试、预算上限。适合：要数据自控、要复杂路由与成本归因。
- OpenRouter——托管聚合器，一个 key 接 200+ 模型，响应里直接带
usage.cost，开箱即用。适合：要快、要简单；代价是流量过第三方 + 抽成。不少团队两者并用。
本地 / 自托管：什么时候值得
- vLLM——生产级多用户服务，PagedAttention + 连续批处理，吞吐远高于单机玩具方案。代价：要 GPU、要运维。
- Ollama——单机 / 工作站友好，Apple Silicon 上走 MLX，运维近乎零。
- LM Studio——图形界面优先，方便浏览和试模型。
数据不能出境 / 强隐私、可预测的高并发（按算力比按 token 更划算）、想要无每-token 账单时，自托管成立。代价：放弃前沿模型质量、零运维、弹性扩缩容，以及各家托管自带的多模态与工具基建。
3.4按场景选型
把上面的差异收敛成一棵决策树。先回答"能不能上云"，再按首要诉求分流。
3.5迁移会破坏什么
"换 base_url 就行"只在兼容层的最大公约数内成立。一旦用了原生 SDK 或原生特性，迁移会在这些点上断——每一点都回扣前两章的某个原语 / 机制。
| 断点 | 差异 | 回扣 |
|---|---|---|
| system prompt 放哪 | OpenAI 当 message / 顶层 instructions；Claude 顶层 system；Gemini systemInstruction。对话中间插 system 在 Claude 会被合并 | §01.1 |
| 助手角色名 | assistant（OpenAI/Claude） vs model（Gemini） | §01.1 |
| 工具调用格式 | 请求里的 schema 包法、响应里 tool_use / tool_calls / functionCall 的结构都不同 | §01.4 |
| 结构化输出机制 | strict json_schema / 原生 / responseSchema 不可互换；兼容层会丢掉 strict 保证 | §2.2 |
| 流式事件名 | chat.completion.chunk vs content_block_delta vs content.delta | §01.3 |
| 必填 / 互斥参数 | Claude max_tokens 必填；新 Claude 不许同设 temperature + top_p | §01.6 |
§本章 self-check
先合上教程作答。更系统的跨章辨析在下一章。
- 为什么"OpenAI 兼容端点能跑通"不代表"原生特性都能用"？举一个会被静默忽略的特性。
- 一个团队要做"内部合同审阅，合同最长 30 万字，数据绝对不能出公司"。按决策树走，落在哪个分支？为什么第一个判断就基本定了结果？
- 把一段 OpenAI 代码迁到 Claude，只改了 base_url 和 model，第一个最先炸的参数是什么？（提示：回扣 §01）
答案（先做完再展开）
- 因为兼容层只暴露"最大公约数"，原生独有能力（Claude 的 prompt caching / extended thinking / 原生结构化输出、OpenAI 的
strict形状保证）经兼容层调用会被静默忽略——比如strict:true不报错但不再保证形状。 - 落在"本地 vLLM + 开源模型"分支。因为决策树第一个问的就是"数据是否不能出境 / 需私有部署"——"绝对不能出公司"是硬约束，一票决定走自托管那一支，后面的上下文 / 价格 / 能力都在这个前提下再谈。30 万字（约 30 万+ token）还要求模型支持超长上下文，进一步指向长上下文的开源模型 + vLLM。
- 最可能炸的是
max_tokens：Claude 把它列为必填，而 OpenAI 可选——照搬不带就直接 400。其次是同时设了temperature和top_p（新 Claude 不允许）。
给"既要省钱又要可靠形状"的客服系统设计供应方组合
客服助手 90% 的请求是简单查询（要便宜），10% 是复杂理赔判断（要强推理 + 严格结构化输出给下游系统）。只用一家、或用网关分流，你会怎么搭？说明每条请求路径选了谁、为什么，以及结构化输出在这里为什么不能图省事走兼容层。
提示（卡住再展开）
考虑用网关按请求复杂度路由：简单查询 → Gemini Flash-Lite / DeepSeek Flash（§3.1 极廉档）；复杂理赔 → 走原生 SDK 的 OpenAI strict json_schema 或 Claude 原生结构化（§2.2 形状保证），因为下游系统消费这些字段，valid-but-wrong 会引发理赔错误。结构化那条路径不能走兼容层——§3.2 边界说明 strict 会被丢。