你的 New API 接了 Codex 却生不了图？教你两招“曲线救国”

最近在捣鼓自建的 New API 或各类兼容接口的聚合方案，经常会遇到这么一个坑：你手头接了好多渠道，大部分只支持 Codex 这种文本模型，一旦前端发起画图请求（比如 gpt-image 相关的调用），后端直接报错或者无响应。

有没有办法在现有的 New API 里单独接入一个专门的生图渠道，然后和 Codex 渠道混到同一个分组里，让系统自动识别并转发到正确的通道？答案是：完全不能直接“混用”，但可以通过配置思路来变相实现。

一、为什么同组混用会翻车？

很多人的第一反应是：“我在 New API 后台加一个 Channel 专门用来生图，然后把它和 Codex 的 channels 放到同一个 Group（分组）里，是不是请求来了 API 就会自己轮询或分发到这个生图渠道？”

想法很美好，但大多数 New API 或 OneAPI 的实现逻辑里，分组是根据“模型名称”或“渠道类型”来做负载均衡的。它并不会智能判断：“这个请求是图片，我把它发到 Channel A；这个是文本，我发到 Channel B”。

如果你直接硬塞到一个组里，通常会发生两种情况：

请求被分发到了 Codex 渠道：因为 Codex 渠道在负载均衡中被选中了，但它根本不支持生图接口，直接返回 400/404 错误。
所有请求都流向生图渠道：如果负载均衡恰好把流量都打到了生图渠道，那么你的普通文本请求也会被处理失败（因为生图渠道可能不支持 gpt-3.5-turbo 等文本模型），导致服务完全不可用。

所以，模型混用最忌讳的就是功能不匹配放在同一个负载均衡组里。

既然混在同组不行，那我们就把“生图”伪装成一个特定的模型。这是最稳妥、最符合 New API 设定的玩法。

添加独立渠道：在 New API 后台添加一个专门的生图渠道（比如接入 Midjourney 接口、DALL-E 3 的官方中转，或者其他支持 gpt-image 的网关）。
设置独有的“模型名称”：别把这个渠道映射为 gpt-4 或 gpt-3.5-turbo，而是起一个专门的名字，比如 custom-sd-image 或者 dall-e-3-proxy。注意，这个名字要和你前端应用调用时的模型名对应上。
前端分流调用：
- 当你需要写代码或文本时，前端请求 model: "gpt-3.5-turbo"，New API 会把它分发到 Codex 渠道组。
- 当你需要画图时，前端请求 model: "dall-e-3-proxy"，New API 就会精准地把这个请求打到你的生图渠道上。

不需要改复杂的网关底层逻辑，利用路由规则（基于模型名）就实现了“多模态分流”。这也是生产环境最常用的做法，把不同能力的接口做成不同的服务地址或不同的 Model Name。

如果你不想改前端调用代码，就想让前端统一发 gpt-4 的请求，后端自动判断是生图还是文本，那就得在你的 New API 前面再加一层“中间件”或“网关”。

部署一个反向代理（如 Nginx 或 Cloudflare Workers）。
解析请求内容：在转发请求到 New API 之前，拦截并检查 JSON Body。
- 如果 Body 里包含 images 关键字，或者 max_tokens 配合特定的 Prompt 特征，判别为生图请求。
- 否则判别为普通文本请求。
Rewrite 路径或 Header：
- 如果是生图请求，由代理层把请求转发到你的“生图专用渠道 URL（可能是一个独立的 New API 分组或者是第三方接口）”。
- 如果是文本请求，正常转发到现有的 Codex 集群。

这种方式对用户透明，但运维成本较高，而且对请求内容的识别可能不够精准（毕竟现在多模态也能看图写字），容易误判，不建议新手尝试。

如果你仅仅是想把现有的 Codex 渠道利用起来，而它本身不支持 OpenAI 标准的 Images API（比如只是个 Claude 或 SD 的中转），你可以尝试“用文生图”的方式曲线救国。

但很多 Codex 模型（即使是 GPT-4）其实可以通过 Prompt 让它返回 SVG 代码或者 ASCII Art，但这并非严格意义上的“生图接口”。如果你的需求是必须在 UI 里直接展示图片链接，那这条路走不通。

这时候你可以尝试修改 New API 的 “自定义渠道重定向”（如果该版本支持）：将生图类请求的错误捕获后，自动转发到另一个 URL。这种配置取决于你使用的具体 OpenAI 延伸项目是否支持 channel_override 功能。

遇到 Codex 不支持生图，千万别强行混组。核心思路只有一条：根据“模型名”做物理隔离。

别纠结于能不能放在同一个分组，API 层面讲究的是“专注单一职责”。把文本和图片的流量分开，不仅不会乱，还能更方便地统计不同渠道的消耗和限流情况，何乐而不为？