项目里需要同时用 GPT-4.1 和 Claude，两套 SDK、两套 Key、两份账单管理起来很烦。后来切到 OpenAI 兼容的统一端点方案，记录一下接入细节和踩的几个坑。

问题背景

不同模型各有所长这事不用多说了——GPT-4.1 mini 快且便宜，Claude Sonnet 推理更强。实际开发中经常需要按任务类型动态选模型，但直接对接多家 API 意味着：

• 维护多套 Key 和 SDK 依赖
• 处理各家不同的请求格式
• 分别查看用量账单

统一 API 网关的思路就是把这些差异屏蔽掉，暴露一个 OpenAI 兼容端点，通过 model 参数路由到不同厂商。我目前在用的是 TikHub AI（ai.tikhub.io）提供的统一端点，支持 GPT、Claude、Gemini 以及 Sora、Kling 等视频生成模型，一个 Key 全部覆盖，下面的代码和踩坑记录都基于这个环境。

接入代码

标准 OpenAI SDK，只改 base_url：

from openai import OpenAI

client = OpenAI(
    api_key="your-key",
    base_url="https://api.tikhub.io/v1"
)

# GPT-4.1 mini — 日常任务
resp = client.chat.completions.create(
    model="gpt-4.1-mini",
    messages=[{"role": "user", "content": "解释 REST API 的核心概念"}]
)

# Claude Sonnet — 需要更强推理时切过去
resp = client.chat.completions.create(
    model="claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "分析这段代码的安全隐患并给出修复方案..."}]
)

Claude Code、Cursor、Aider 这些工具的接入更简单，改环境变量就行：

# Claude Code
export ANTHROPIC_BASE_URL=https://api.tikhub.io
export ANTHROPIC_API_KEY=your-key

# Aider / 其他 OpenAI 兼容工具
export OPENAI_API_BASE=https://api.tikhub.io/v1
export OPENAI_API_KEY=your-key

按任务路由模型

实际跑起来之后自然会做一层路由，不同任务走不同模型：

MODEL_ROUTER = {
    "draft":    "gpt-4.1-mini",             # 初稿，成本低
    "review":   "claude-sonnet-4-20250514",  # 润色，质量高
    "analysis": "claude-opus-4",             # 长文本，200K 上下文
}

def call_llm(task_type: str, prompt: str) -> str:
    model = MODEL_ROUTER.get(task_type, "gpt-4.1-mini")
    return client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.3
    ).choices[0].message.content

初稿走 GPT-4.1 mini、润色走 Claude Sonnet 这个组合实测性价比最好。全程 Opus 效果当然更强，但成本差 5-10 倍，多数场景没必要。

Dify / n8n 接入

Dify：「设置」→「模型供应商」→「OpenAI-API-compatible」，填入 TikHub AI 的 base URL 和 Key 即可。

n8n：OpenAI 节点里改 Base URL，同样指向统一端点。

配置完之后工作流里切模型就是换个参数的事。

踩坑记录

Function Calling 兼容性：OpenAI 的 tool calling 格式通过兼容层调 Claude 时，偶尔有参数解析差异。建议业务层做一层抽象，别直接依赖某家的特有字段。

首 Token 延迟：GPT-4.1 mini 首 token 约 200ms，Claude Sonnet 约 500-800ms。如果有实时性要求，路由逻辑本身要轻，否则快模型的优势会被吃掉。

模型名称校验：自定义端点填模型名时必须完全匹配，先 curl 测一下比较稳：

curl https://api.tikhub.io/v1/chat/completions \
  -H "Authorization: Bearer your-key" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4.1-mini","messages":[{"role":"user","content":"ping"}]}'

以上就是整个接入过程，主要解决多模型管理的工程痛点。欢迎在评论区交流看法。