什么是兼容 OpenAI 的 API
兼容 OpenAI 的 API，接受和 OpenAI /v1/chat/completions 端点完全相同的请求格式，返回相同的响应结构。唯一变化的只有 base URL。
Token Landing 在这个兼容层上做了一件额外的事：你熟悉的请求格式背后，每条请求会根据你配置的路由策略，自动分发给旗舰模型或经济模型。OpenAI SDK、LangChain、LlamaIndex，以及所有能说 OpenAI 协议的工具，不需要任何改动就能直接使用。
为什么选择兼容而不是自定义格式
我们考虑过做一套自定义 API——那样可以在请求格式上做更多花活。但和十几个团队聊完之后，答案很清楚：没有人想重写自己的 API 客户端。一个基础设施负责人直接告诉我们："我们代码库里有 47 个地方在调 OpenAI，我不打算动任何一个。"
所以我们选了兼容路线。迁移只需要一行配置：
# 迁移前
client = OpenAI(api_key="sk-...")
# 迁移后
client = OpenAI(
api_key="your-token-landing-key",
base_url="https://api.token-landing.com/v1"
)就这样。你的 prompt、system message、function calling、streaming 逻辑、重试处理、错误类型——全部不变。
请求背后实际发生了什么
请求进来时，路由层会看几个信号来决定它去哪里：
| 信号 | A 档（旗舰） | 性价比档（经济） |
|---|---|---|
| 对话第一轮 | 是——用户对第一印象很敏感 | 否 |
| 工具/函数调用 | 是——失败会直接暴露给用户 | 否 |
| 仅系统 prompt（预热） | 否 | 是——没有用户看这个 |
| 摘要/信息抽取 | 否 | 是——经济模型完全胜任 |
| 向量化生成 | 否 | 是——专用 embedding 模型 |
你通过路由策略来配置这些规则。默认策略对大多数对话类产品效果不错；如果你跑的是代码生成流水线或 RAG 系统，可以自定义哪些请求走 A 档。
Streaming 支持
Streaming 和 OpenAI 的实现完全一样。设 stream: true，你拿到的是同样格式的 Server-Sent Events，delta 结构、finish_reason 信号、末尾的 usage 报告都一致。
我们在 time-to-first-token 上做了一个小优化：边缘路由在路由决策还没完全确定时就可以开始从响应最快的模型发送内容，对聊天 UX 有细微但可感知的改善。
Function Calling 与工具使用
完整支持。tools 和 tool_choice 参数行为完全相同。工具调用请求默认走 A 档，因为工具失败通常会级联地暴露给用户。
如果你在做批量工具调用（比如从文档里批量抽结构化数据），可以手动覆盖为性价比档，这类请求能省 60-70%。
迁移检查清单
- 获取 API 凭证（填写联系表单）
- 换 base URL——OpenAI 客户端配置里改一行
- 配置路由策略（入职时我们会一起设置）
- 影子部署测试——对比切换前后的质量和成本
- 切换生产流量——满意后全量切
大多数团队一天内完成迁移。最耗时的部分通常是决定路由规则，而不是技术迁移本身。
暂不支持的功能
坦白说：我们目前不支持图片生成（DALL-E 端点）、微调，以及 Assistants API。我们专注在 /v1/chat/completions 和 /v1/embeddings，这两个覆盖了绝大多数生产用例。Assistants API 支持在 2026 年 Q3 路线图上。