OpenAI API 基础 URL（2026）：直连与兼容端点

OpenAI API 基础 URL（2026）：直连与兼容端点

快速回答：官方 OpenAI API 基础 URL 是 https://api.openai.com/v1。将其用作 SDK 的 base_url 或 baseURL，然后让 SDK 追加资源路径。常见的完整端点包括 https://api.openai.com/v1/responses 和 https://api.openai.com/v1/chat/completions。

对于 Flatkey 的 OpenAI 兼容网关，请使用 https://router.flatkey.ai/v1 作为基础 URL。对应的聊天补全端点为 https://router.flatkey.ai/v1/chat/completions。不要将完整的 /chat/completions 路径粘贴到仅需要基础 URL 的 SDK 字段中。

OpenAI API 基础 URL 表

基础 URL 与端点：区别

基础 URL是在 SDK 中一次配置的共享前缀。端点则是单个 API 操作的完整路径。混淆两者会导致最常见的集成失败：

• 404 Not Found：你提供了错误的路径或重复添加了 /v1。
• 401 Unauthorized：该密钥不属于你正在调用的基础 URL。
• /v1/v1/...：你配置的基础 URL 和客户端代码都追加了 /v1。
• .../chat/completions/chat/completions：SDK 仅需要基础 URL 的位置却传入了完整端点。

为基础 URL 使用单一事实来源，将密钥保存在环境变量中，并在迁移生产流量前运行一个小型 /models 或聊天请求。

OpenAI 兼容 API 网关改变了什么

关键变化在于运营层面，而非概念层面。

这就是团队首先搜索 openai compatible api gateway 的原因。他们并不是在寻求新的提示词格式，而是在寻求更低的重写风险。

更改生产环境前，请使用这份迁移检查清单

采用 openai compatible api gateway 最安全的方式，是将其视为一次受控的集成变更，而不是一个全面的抽象项目。

1. 列出你当前使用的确切 OpenAI 端点。大多数团队认为自己使用的是“OpenAI API”，而实际上使用的只是较小的子集，例如聊天补全、responses、嵌入或图像生成。
2. 确认哪些调用必须在应用代码中保持不变。这样可以确保范围如实明确，并保护“最小迁移”的说法。
3. 检查你当前的 SDK 是否已支持自定义基础 URL。当前官方 OpenAI Python 和 Node 客户端均支持。
4. 先选择一个预发布环境工作流。从已符合标准 OpenAI 请求格式的路由开始。
5. 在上线前实时验证目标模型。不要依赖旧截图或过时的目录假设。
6. 写明回退规则。审核人员应了解该路由是否可以切换模型、失败时关闭，或排队处理。
7. 批准兼容性说明。你发布的表述应针对受支持的请求范围使用“OpenAI-compatible”，而非“与 OpenAI 完全相同”。

这份检查清单使 openai compatible api gateway 在生产审查中更具可信度。

最小变更代码示例

当前官方 OpenAI SDK 已经记录了对自定义基础 URL 的支持。这是一个机制层面的原因：当网关保留你已使用的 OpenAI 风格请求结构时，openai compatible api gateway 可以实现低摩擦迁移。

Python 示例

from openai import OpenAI

client = OpenAI(
    api_key="sk-fk-your-flatkey-key",
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Return a one-line health check."},
    ],
)

print(response.choices[0].message.content)

Node 示例

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-5.4-mini",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "Return a one-line health check." },
  ],
});

console.log(response.choices[0].message.content);

cURL 示例

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [
      { "role": "user", "content": "Return a one-line health check." }
    ]
  }'

对许多团队而言，这是 openai compatible api gateway 不一定意味着要重写客户端的首个证明。重要的限制条件是，您选择的工作流必须适配受支持的请求范围。

在称迁移为“即插即用”之前需要验证什么

这是大多数 openai compatible api gateway 页面表述不严谨的地方。除非定义边界，否则“即插即用”的说法过于宽泛。

请在评审中使用下表：

当这些检查比单独迁移各个提供商所需的摩擦更少时，openai compatible api gateway 就具有价值。

实用的上线顺序

当您希望尽量少改代码时，以下是采用 openai compatible api gateway 最清晰的上线路径：

1. 梳理当前调用路径。 记录当前 SDK 版本、端点系列、模型 ID、流式设置和重试假设。
2. 在预发布环境中更改一个基础 URL。 首先保持相同的客户端使用模式。不要将此变更与无关的提示词或模型变更捆绑进行。
3. 首次测试只保留一个已批准的模型。 首次成功的标准是传输兼容性，而不是广泛的模型覆盖。
4. 执行响应和错误形态检查。 比较输出、状态码、延迟预期和日志记录行为。
5. 评审模型路由策略。 确定路由是固定到一个模型、可故障转移到同等类别的模型，还是必须故障关闭。
6. 仅在确认实时目录后再扩展。 截至 2026 年 7 月 15 日，Flatkey 的公开定价数据源显示共有 170 行，其中 95 行可用；但生产环境上线仍需要在发布当天对确切模型进行验证。

正是这一顺序，使 openai compatible api gateway 成为迁移控制层，而非另一个未知的集成环节。

这与直接迁移到提供商有何不同

提供商文档已经表明，OpenAI 风格兼容性正变得普遍。Google 介绍了通过 OpenAI 库访问 Gemini 的方式。DeepSeek 介绍了 OpenAI 和 Anthropic 兼容性。但每个提供商仍有各自的密钥、基础 URL 和运营边界。

这正是 openai compatible api gateway 所解决的缺口。您无需教每个团队使用新的、特定于提供商的设置，而是可以集中迁移范围，并将评审工作转向模型审批、可观测性和模型路由策略。

这也解释了为何当前的 Flatkey 表述比“它可与 OpenAI SDK 配合使用”更有力。更重要的好处在于，openai compatible api gateway 可以集中访问和评审，而无需立即重写应用程序。

审核人员可批准的合规措辞

请在最终发布审核中使用如下措辞：

除非审查人员能够证实，否则应避免以下表述：

这些注意事项不会削弱对OpenAI 兼容 API 网关的介绍，反而会使其更可信。

何时选择 OpenAI 兼容 API 网关

在以下情况下，OpenAI 兼容 API 网关通常是合适的选择：

• 团队已依赖 OpenAI 风格的客户端流程，并希望选择干扰最小的迁移路径
• 已经需要使用多个模型系列
• 需要在一个位置审查访问权限、使用情况和已批准的路由
• 模型变更足够频繁，需要制定共享的模型路由策略
• 希望先进行受控迁移，再考虑更深入的网关功能

如果不满足这些条件，直接配置提供商可能仍然更简单。本文应如实说明这一取舍。

AWS 团队：Bedrock 的 OpenAI 兼容基础 URL

如果您的模型运行在 AWS 上，Amazon Bedrock 提供了自己的 OpenAI 兼容基础 URL：https://bedrock-runtime.{region}.amazonaws.com/openai/v1，并使用 Bedrock API 密钥进行身份验证。我们的 Amazon Bedrock OpenAI 兼容 API 指南介绍了端点、密钥、模型 ID 以及 /models 的限制。

结论

OpenAI 兼容 API 网关的价值不在于创造一种新的 API 模式，而在于让团队保留熟悉的 OpenAI 风格集成方式，同时通过一个可审查的统一层来管理访问、模型审批和上线控制。

对于 Flatkey，最有力且可供审查的说法很直接：保留现有的客户端模式，将基础 URL更改为 https://router.flatkey.ai/v1，验证所需的具体工作流是否受支持，并在扩大流量之前批准模型路由策略。这才是开发者真正需要的迁移清单。