多提供商LLM API兼容性笔记：我们尝试的三种方法

这不是一篇论文，而是过去几个月我们团队试图将对OpenAI、Anthropic和Google模型的访问统一到单个内部接口的生产工程笔记。我们的服务需要根据任务调用这三者，而“如何让它不那么痛苦”这个问题比我想象中更有趣。这里没有什么新颖的研究，但我没看到有多少人写过，所以还是写下来。 方法一：将所有内容规范化为OpenAI聊天补全格式。这是事实上的行业默认，OpenAI SDK的形状是通用语言，大多数可观测性工具都支持它。对于简单的聊天补全来说没问题。但问题在以下三个方面显现： * 工具/函数调用架构。Anthropic的tool\_use/tool\_result内容块在往返过程中无法干净地映射到OpenAI的tool\_calls结构。你可以将其扁平化，但会丢失并行工具调用语义以及Claude内部使用的有序内容块。在我们内部的评估（80个多轮工具使用场景，评估工具选择准确性和参数正确性）中，我们测量到当强制使用OpenAI规范化时，原生Claude的得分从0.87下降到0.79，且三次运行结果一致。样本量小，未经同行评审，但方向足够明确，我们停止了在这条路径上的投入。 * 流式传输格式。Anthropic使用事件类型的SSE（message\_start, content\_block\_delta等），OpenAI使用delta块，Gemini的流式传输有自己的形状。包装器能处理常见情况，但当你需要细粒度的流式控制（例如，针对正在进行的工具调用）时，抽象往往会有泄漏。 * 安全/系统控制。Gemini的安全设置、Anthropic的系统提示处理以及OpenAI的开发者消息行为都有微妙不同的语义。“将所有内容翻译成系统角色”会丢失信息。 方法二：每个服务保留原生SDK，在应用层路由。保留了完整的提供商语义。代价是你需要维护三个SDK集成、三个重试/超时/认证代码路径，而路由逻辑成为每个需要多提供商访问的服务的一部分。我们发现随着添加更多提供商，维护负担的增长速度快于功能价值。 方法三：网关原生暴露多个API规范，而不是归一化到一个规范。这种模式不太常见。我们评估了Portkey和TokenRouter，它们完全属于这一类别。LiteLLM代理模式类似但不完全相同：其默认行为是OpenAI格式规范化，这使其在大多数使用模式上更接近方法一，但可以配置为在特定路由上进行提供商原生透传。这个领域中原生规范端点的吸引力在于，现有客户端代码可以继续使用它原本编写的SDK。代价是你现在依赖网关来跟踪上游API变更，这是一个实际存在的维护负担，你只是外包了而不是消除了。如果网关在某个新功能（扩展思维、计算机使用、结构化输出扩展等）上落后了，你就陷入困境。 一个我们尚未解决的相关问题：当主要上游提供商降级时（我们在四月底的一次Anthropic容量事件中略有体会），纯代理网关在该提供商内没有回退到其他路径的方法。一些网关在路由层后面保持自己的推理能力作为最后的手段，而另一些则没有。这是否真正有用完全取决于回退路径可以提供哪些模型，因为显然一个Llama类的回退无法在需要Opus的工作负载上替代Opus。对于我们的用例，我们将其视为降级模式选项，而不是真正的替代方案。 关于方法一与方法二在规模上的质量代价，我没有一个清晰的答案。我们的内部评估样本量太小，无法写入论文，但方向性发现（在规范化为聊天补全时，代理工具使用任务的可测量下降）足够一致，以至于我们决定不为我们的用例走那条路。