Stop Chasing New Models. Build Once and Access Them All.

停止追逐新模型。一次构建，畅享所有模型。

专家观点

切换大语言模型（LLM）看似简单，但管理独立的SDK、凭证和计费方式，使模型评估变成了基础设施的噩梦。Otari通过统一网关解决这一问题，将应用逻辑与服务提供商解耦，使团队能够无缝路由流量、测试新模型并控制支出。

#### 卡洛斯·阿尔瓦雷斯

2026年7月27日

—

4分钟阅读

一款新的LLM发布了。它运行更快、成本更低、推理能力更强，或更契合某项具体工作负载。

产品团队想要测试它。从表面看，这似乎只需更改模型名称并运行几次评估。

但从平台或基础设施的角度来看，事情很少这么简单。

新模型可能来自应用不支持的服务提供商。这意味着需要另一个SDK、认证方式、请求格式、错误模型、环境变量集合以及特定于提供商的行为规范。

真正的挑战不是获取更多模型，而是防止每个新模型都演变成另一个基础设施项目。

模型只是集成的一部分

当应用直接连接到LLM提供商时，它依赖的不仅是模型本身。

它还依赖提供商的SDK、凭证、请求和响应模式、流式传输实现、工具调用规范、速率限制、重试机制、模型标识符以及使用数据。

特定于提供商的逻辑开始蔓延至应用代码、凭证管理、可观测性、测试、部署流水线和事件响应。

当只有两个提供商时，这或许可以管理。但当新供应商出现、模型被弃用、API演进、团队需要为不同工作负载使用不同模型时，情况会变得复杂。

最终，团队维护的不再是AI应用，而是内部的提供商兼容性层。

我们以前就遇到过这个问题

软件团队以前曾面临过类似的问题。

在可重复的包管理和容器化环境成为标准之前，应用程序经常因为库、运行时和操作系统需要不兼容的版本而崩溃。更新一个依赖项可能会破坏不相关的组件。在两个环境中部署相同软件可能会产生不同结果。

我们称之为"依赖地狱"。

问题不在于依赖项本身不好，而是应用代码与独立演进的系统耦合过紧。

通过引入稳定的边界，如包管理器、锁定文件、容器和一致的接口，工程实践得到了改进。

如今LLM提供商开始呈现出独立的依赖生态系统。每个生态都在发展自己的SDK、API、凭证、模型、工具和计费机制。直接将应用连接到每个提供商，又重新创造了我们多年前在其他领域努力消除的耦合关系。

将应用生命周期与模型生命周期解耦

新模型应该只是配置变更，而不是应用重写。

应用和模型运行在不同的发布周期上。应用变更可能需要代码审查、安全检查、集成测试、分阶段部署和生产批准。而新模型持续不断出现，可能需要更快的评估或路由调整。

Otari 在应用程序与服务提供商之间提供一个稳定的 OpenAI/Anthropic 兼容端点。应用程序通过一个 API 密钥发送请求，而服务提供商选择、上游凭证、路由策略和故障转移行为均由网关处理。目前 Otari 已支持超过 40 个服务提供商。

应用程序集成可以保持稳定：

这种分离使应用程序能够掌控产品行为，而平台则负责模型访问和运营策略。

团队无需思考 "需要修改哪些代码来支持这个服务提供商？"，而是可以专注于思考 "哪个模型更适合处理这个工作负载？"。

团队仍需评估质量、延迟、隐私、可靠性和价格。Otari 并不会取代工程判断，它消除了围绕每个决策的重复集成工作。

更小的模型不应意味着更弱的平台

模型能力与平台能力并非同一回事。

轻量级或开源权重模型可能因成本、延迟、隐私或部署需求而更适合某些工作负载。但它们通常缺乏部分前沿模型 API 所附带的托管功能。

Otari 通过提供与模型无关的工具（如网页搜索和沙箱代码执行）来弥补这一差距，这些工具均通过同一网关提供。

当工具与服务提供商解耦后，小型模型的价值将显著提升。

分片问题远不止集成层面

直接对接服务提供商不仅会碎片化代码，还会导致凭证分散在不同系统中，并使财务可见性分散到多个账户和计费仪表板中。

集中管理凭证并降低暴露风险

Otari 集中存储上游服务提供商凭证，而应用程序使用工作区范围的 API 密钥调用网关。应用程序无需直接访问服务提供商密钥。

这建立了更清晰的安全边界。服务提供商凭证可集中管理和轮换，应用程序访问权限可单独限定，应用程序密钥泄露后的潜在影响范围也更容易控制。

统一使用情况并控制支出

多个服务提供商账户会使得成本归属变得困难。汇总后的发票总额无法说明具体是哪个应用程序、团队、用户、模型或环境产生了支出。

Otari 在统一位置记录跨服务提供商的请求和成本，支持预算管理、使用情况可见性和支出控制。其托管平台还通过组织和工作区对访问权限和支出进行分类管理。

这将成本管理更紧密地与请求本身关联。团队无需等到多张发票到达后才发现异常使用情况，而可以通过同一授权层定义限制并追踪支出。

构建产品，而非另一个服务提供商抽象层

模型选择将持续变化。团队将采用新模型、淘汰旧模型，并将不同工作负载路由到不同服务提供商。

试图预测一个永久服务提供商并非现实的平台策略。在每个应用程序中重建特定服务提供商的逻辑同样不可持续。

可持续的方法是为应用程序提供稳定的接口，同时允许模型层在接口后持续演进。

模型仍需测试。成本仍需计量。可靠性和安全性仍需设计。但这些决策应在专用控制平面中进行，而非通过在应用程序代码库中反复重写实现。

停止追逐供应商集成。构建产品时采用一个稳定的接口，让模型生态系统在后台自行演变。

探索 Otari

通过查阅 Otari 的多供应商路由指南，了解如何通过单一集成实现跨供应商的请求路由、集中凭证管理、添加回退机制，并将使用情况和支出整合到统一的运营视图中。