我们直接在 aura-ai服务的代码中验证了这种区别，而不是在营销页面中：三个提供商模块（anthropic、 gemini、 openai）组成了网关，仅此而已。其余的情况证实这是一个真正的开发商类别，而不是一个孤立的营销论点。 Neon 发布了两个专用页面（“AI 网关”和“AI 代理后端”），LiteLLM 已将自己确立为参考开源项目，Braintrust 也致力于对其进行比较。
要点
- 在 代码中验证了 3 个本机提供程序：OpenAI、Anthropic (Claude)、Google Gemini (
aura-ai/src/llm/mod.rs)。 - Mistral、Scaleway AI 和 Ollama 通过通用 OpenAI 适配器 (
OPENAI_BASE_URL)，而不是通过专用客户端。 - 原生带来的不仅仅是连接：（项目、供应商）的断路器、重试回退、回退链（默认顺序 Anthropic → OpenAI → Google）、关闭原因的标准化。
- Anthropic 仅涵盖聊天：没有嵌入 API，这与涵盖两者的 OpenAI 和 Gemini 不同。
- Neon、LiteLLM 和 Braintrust 在市场方面确认了同一类别，但采用了三种不同的方法：托管网关、开源代理、比较内容。
Postgres 后端的 AI 网关是什么？
AI 网关将对外部 LLM 提供商的调用集中在单个接口后面，而不是在应用程序端对每个 SDK 集成进行编码。 API 密钥保留在服务器端，永远不会暴露给客户端。该网关在具有不同响应格式的提供商之上添加了一个公共重试、故障转移和成本计数层。
在像 Aurabase这样的 Postgres 后端上，这种选择有一个直接的后果：同一个网关为应用程序聊天、NL2SQL（自然语言转换为 SQL）和 RAG（pgvector 向量搜索）提供支持。集成度较差的提供商会同时降低所有三个功能，而不仅仅是一个。这就是本机/兼容区别不仅仅是实现细节的原因。
本地提供者或兼容端点：具体区别
本机客户端对提供者 API 的真实形式进行编码：请求结构、响应格式、特定于该提供者的使用字段。 Anthropic 就是这种情况，其“消息”API 与 OpenAI 或 Gemini 的情况不同，Gemini 的推理标记 (thoughtsTokenCount) 计数被添加到输出计数器中，而不是已包含在其中。
OpenAI 兼容端点重用现有的 OpenAI 客户端，仅更改基本 URL。这是可行的，因为第三方提供商（Mistral、Scaleway AI、Ollama）选择模仿 OpenAI 的 API 合约，通常会出现偏差：没有单独的推理令牌字段，无法保证错误的确切形式。模仿结束时，兼容性也结束。
Aurabase 的 3 位本地法学硕士客户，仅此而已
在 aura-ai 中组织提供程序的文件没有留下任何歧义的空间。三个模块，每个本机提供程序一个，没有任何其他声明。
每个模块都实现 ChatProvider 特征（完成、流式传输、模型名称）。其中两个 OpenAI 和 Gemini 还实现了 EmbeddingProvider。 Anthropic 不需要它：Claude 没有公开供应商端嵌入 API，这是 Anthropic 本身的产品事实，而不是 Aurabase 代码的缺点。
| 开放人工智能 | 本土客户 | 聊天+高保真向量嵌入的计算 |
|---|---|---|
| 人类（克劳德） | 本土客户 | 聊天推理和结构化模型完成 Claude |
| 谷歌双子座 | 本土客户 | 聊天 + 嵌入、附加推理标记计数 |
| 米斯特拉尔 | 兼容位置 | 通过标准 OpenAI 兼容协议进行路由（自定义 URL） |
| Scaleway人工智能 | 兼容位置 | 通过 openai.rs 客户端路由，变量 OPENAI_BASE_URL |
| 奥拉马（自托管） | 兼容位置 | 通过 openai.rs 客户端路由，变量 OPENAI_BASE_URL |
将 Mistral、Scaleway AI 或 Ollama 连接到 Aurabase 项目
配置 Mistral、Scaleway AI 或 Ollama 不需要新模块：相同的 OPENAI_BASE_URL 变量将 openai.rs 客户端重定向到另一个兼容端点。这是配置切换，而不是开发。
行为也会相应改变。 HTTP 错误仍然通过相同的机制进行分类（429 → 速率限制、5xx → 瞬态和可重试、404 → 未知模型），因为分类位于 HTTP 传输级别，而不是特定于提供程序的解析。接下来是：推理令牌的精确计数，特定于专用的 Gemini 客户端。
为什么 Native 能够改变游戏规则：切换、错误、计费
Aurabase 网关在三个本机客户端之上添加了三个弹性机制。每对（项目、提供者）的断路器会切断对反复失败的提供者的调用，并在重新打开之前使探测令牌处于半打开状态。带抖动的指数退避重试会重新启动瞬态错误（超时、5xx、429），而不依赖于外部随机数库。
当在链中配置多个提供程序时，每个提供程序在切换到下一个提供程序之前仅进行一次尝试，以避免放大（重试×回退），这会增加上游调用和总延迟。该通道的默认顺序是 Anthropic，然后是 OpenAI，然后是 Google Gemini。
每个提供商还以不同的方式命名停止响应的原因：OpenAI 的 length、Gemini 的 MAX_TOKENS、Anthropic 的 max_tokens，都是出于相同的现实（截断）。该代码将这三个词汇表标准化为一个通用集（stop、 length、 content_filter、 tool_use、 other）。如果没有这种标准化，多供应商客户端将需要了解所有三个词汇表才能检测被截断的响应。
计费说明了同样的风险。在 OpenAI 和 Anthropic，模型的推理已经包含在收取的输出代币的计数器中。在 Gemini，thoughtsTokenCount 单独添加到 candidatesTokenCount中：忽略它会低估查询的实际成本。通用 OpenAI 兼容适配器没有理由知道这种特殊性（特定于 Gemini 的本机响应格式）。
Neon、LiteLLM、Braintrust：2026 年最好的 LLM 网关在哪里？
市场证实，人工智能网关已成为一块预期的砖头，而不是孤立的营销论点。 Neon 发布了两个专用产品页面：“AI Gateway”和“AI 代理后端”，均面向 Postgres 开发人员。 LiteLLM 已成为一个参考开源项目，以接近 OpenAI 的格式统一对大量提供商的调用。智囊团则发布了自己对这一主题的比较，这表明该类别足够强大，足以证明专门的社论内容是合理的。
这些参与者响应了真正的需求：减少应用程序代码和给定 LLM 提供者之间的耦合。与 Aurabase 的区别在于集成。网关并不位于后端旁边：它在同一个 Postgres 数据库上与 NL2SQL 和 RAG 共享相同的服务。相反的折衷方案也存在：像 LiteLLM 这样的专用代理通常比集成到应用程序后端的网关覆盖更多的提供商。
| 光环基地 | 与 Postgres 后端集成（aura-ai 服务） | 3 个经过验证的原生 + OpenAI 兼容其余部分 |
|---|---|---|
| 霓虹人工智能网关 | 专用产品以及托管 Postgres 数据库 | 记录在两个单独的官方页面上 |
| 莱特法学硕士 | 独立开源代理，任意后端前端 | 通过接近 OpenAI 的格式提供广泛的提供商 |
何时选择原生网关，何时选择通用代理
当后端和 AI 必须保留在同一系统中时，像 Aurabase 这样的本机网关具有真正的优势：NL2SQL、RAG 和应用程序聊天共享相同的弹性策略和相同的计费，无需运行额外的服务。
存在相反的妥协。如果您的首要任务是覆盖大量提供商，或者网关必须为多个独立后端提供服务而不仅仅是 Postgres 项目，那么像 LiteLLM 这样的通用代理通常仍然是正确的选择。 Aurabase 并不寻求与这种覆盖广度竞争：赌注是跨 3 个主要提供商的深度，并与后端的其余部分集成。
要了解与使用外部连接器的方法（Supabase 选择的方法）相比，此集成如何具体改变 NL2SQL 的使用，请参阅 Supabase 依赖于连接器，而不是本机 NL2SQL。
集成本机网关与通用 LLM 代理
真正区分这两种方法的标准总结，没有价值判断：每种方法都响应不同的需求。
| 供应商 | 深度了解 3 个主要供应商 + OpenAI 兼容其余供应商 | 供应商广泛，普遍统一整合 |
|---|---|---|
| API 密钥 | 后端加密，与数据库同服务 | 代理端加密，服务与应用后端分离 |
| NL2SQL/RAG 链接 | 相同的服务，相同的提供商解析器 | 没有原生链接，构建您自己的集成 |
| 韧性 | 按（项目、供应商）断路器、回退、重试回退 | 取决于为代理选择的配置 |
| 部署 | 少一项需要操作的服务（已经在后端） | 可拆卸，可在多个项目/后端重用 |
要查看此网关在具体案例中的工作情况，请参阅 Postgres 上的 NL2SQL 教程。有关 Aurabase 原生 AI 功能的详细信息，请参阅 原生 AI页面。