GPT-6与Opus 5.5双模型接入：用ServBay搭建统一AI网关的完整实践

1. 当两个旗舰模型同时降价，开发者真正该关心什么

GPT-6 价格腰斩、Opus 5.5 上线，这两件事凑在一起，最直接的结果就是——原本因为成本问题只能"二选一"的团队，现在有了同时接入两个模型的空间。但问题也随之而来：两个模型的 API 协议不一样、计费方式不一样、流式返回格式不一样，如果每个业务代码里都硬编码两套调用逻辑，维护成本会迅速失控。

我自己在上一轮模型切换时就吃过这个亏。当时项目里散落着七八处直接调用某家 API 的代码，等到要换模型做 A/B 对比时，改一处漏一处，测试环境跑通了生产环境又炸。后来我把所有模型调用收敛到一个统一的 AI 网关层，才彻底解决了这个问题。这篇内容就是把这套做法完整拆开讲清楚：怎么用 ServBay 搭一个本地 AI 网关，把 GPT-6 和 Opus 5.5 统一成一套调用接口，同时兼顾流式输出、成本核算和故障切换。

适合谁看？如果你正在做多模型接入、想给现有项目加一个"模型可切换"的能力，或者单纯想搞清楚 AI 网关到底解决什么问题，这篇都能直接用。全文会给出可复现的配置、代码和踩坑记录，不是概念科普。

先说结论：统一网关的核心价值不是"省事"，而是把模型变成一个可替换的运行时依赖。当模型可以像数据库连接一样被配置管理时，你才能在价格波动、新模型上线时快速响应，而不是被某一家绑定。

2. 为什么不该在业务代码里直接调两个模型

2.1 硬编码调用的三个隐性成本

很多人第一反应是"我就在代码里写两个函数，一个调 GPT-6 一个调 Opus 5.5，用 if 判断一下不就行了"。短期看确实能跑，但隐性成本会在三个地方冒出来。

第一是协议差异的维护成本。GPT 系列走的是 OpenAI 风格的/v1/chat/completions，消息体是messages数组，角色用system/user/assistant；而 Opus 系列走的是 Anthropic 风格的/v1/messages，system是独立字段而不是消息数组里的一项，返回结构里content是一个块数组。你写两套解析逻辑，任何一边改了字段，另一边都要跟着动。

第二是流式输出的处理成本。两家的 SSE 事件类型命名不同，结束标志不同，增量文本的提取路径也不同。如果每个业务模块都自己解析一遍，代码重复率极高，而且一旦某家调整了事件格式，你要改的地方是 N 处而不是 1 处。

第三是成本与限流的观测成本。你想知道这个月 GPT-6 花了多少、Opus 5.5 花了多少、哪个接口调用最频繁，如果调用散落在各处，你只能靠日志拼凑。而网关层天然是流量入口，所有统计都能在这里一次性完成。

2.2 网关层到底拦截了什么

把调用收敛到网关后，业务代码只需要面对一个统一的接口。网关负责做四件事：协议转换、路由决策、流式透传、计量统计。

协议转换是把统一的内部请求格式翻译成各家 API 需要的格式；路由决策是根据配置或规则决定这次请求发给谁；流式透传是把各家的 SSE 流统一成一种事件格式再吐给业务；计量统计是记录 token 数、耗时、成功率。

这四件事里，协议转换和流式透传是最容易出问题的，后面会专门讲。路由决策和计量统计相对简单，但设计得好能带来很大灵活性，比如按成本路由、按任务类型路由、按可用性自动降级。

2.3 一个反直觉的点：网关不是越重越好

我见过一些团队把网关做成了一个庞大的中间件，里面塞了缓存、重试、限流、鉴权、审计、向量检索……最后网关本身成了故障源。我的建议是：网关只做协议适配和路由，其他能力按需外挂。

缓存可以放在网关前面，重试策略可以放在 SDK 里，鉴权可以交给上层。网关保持"薄"，才能保证它的稳定性和可替换性。这一点在选型时就要想清楚，否则后期想拆都拆不动。

3. 用 ServBay 搭本地 AI 网关的完整路径

3.1 为什么选 ServBay 而不是自己从零写

ServBay 本身是一个本地开发环境管理工具，能一键拉起各种运行时和服务。用它来承载 AI 网关的好处是：环境隔离干净、端口管理省心、本地调试方便。你不需要为了跑一个网关去折腾系统级的依赖，也不用担心和现有项目的端口冲突。

当然，如果你已经有成熟的容器化流程，用 Docker 跑网关也完全没问题。选 ServBay 主要针对的是本地开发和中小规模自托管场景——启动快、配置直观、出问题好排查。下面这套配置在 ServBay 环境下验证过，换成其他环境思路一致，只是路径和命令要调整。

3.2 环境准备与依赖安装

先在 ServBay 里创建一个新的站点，运行环境选 Node.js（建议 20 LTS 以上，因为要用到原生 fetch 和较新的流处理 API）。站点根目录假设为~/Sites/ai-gateway。

进入目录后初始化项目：

cd ~/Sites/ai-gateway npm init -y npm install express undici dotenv

这里用undici而不是内置的fetch，原因是undici对流的控制更细，处理 SSE 时能拿到更底层的控制权。dotenv用来管理密钥，千万不要把 API Key 写进代码或提交到版本库。

创建.env文件：

GPT6_API_KEY=your_gpt6_key_here GPT6_BASE_URL=https://api.example-gpt.com/v1 OPUS_API_KEY=your_opus_key_here OPUS_BASE_URL=https://api.example-opus.com/v1 GATEWAY_PORT=8787

注意：Base URL 和 Key 请以你实际拿到的服务商文档为准，不同渠道的路径可能带不同的前缀，配置前先确认清楚。

3.3 统一请求格式的设计

网关对外暴露一个/v1/chat接口，请求体设计成中立的格式，不偏向任何一家：

{ "model": "auto", "messages": [ { "role": "system", "content": "你是一个严谨的助手" }, { "role": "user", "content": "解释一下什么是幂等" } ], "stream": true, "max_tokens": 1024, "temperature": 0.7 }

model字段支持三种值：gpt6、opus5.5、auto。auto交给路由层决策。messages用 OpenAI 风格作为内部标准，因为它的结构最通用，转换到 Anthropic 风格时只需要把system抽出来即可。

这个设计的关键在于：内部格式一旦定下来，就不要因为某家 API 的偏好去改它。内部格式是契约，外部格式是适配细节。

3.4 协议转换的核心代码

先写一个把内部格式转成 GPT-6 请求的函数：

function toGPT6Request(body) { return { model: "gpt-6", messages: body.messages, stream: body.stream, max_tokens: body.max_tokens, temperature: body.temperature }; }

再写转成 Opus 5.5 请求的函数，注意system要单独抽出来：

function toOpusRequest(body) { const systemMsg = body.messages.find(m => m.role === "system"); const rest = body.messages.filter(m => m.role !== "system"); return { model: "opus-5.5", system: systemMsg ? systemMsg.content : undefined, messages: rest, stream: body.stream, max_tokens: body.max_tokens, temperature: body.temperature }; }

这两个函数看起来简单，但边界情况要处理好：如果没有 system 消息，Opus 的system字段应该省略而不是传空字符串；如果messages为空，两家都会报错，网关层应该提前拦截并返回明确的错误信息，而不是把错误透传给业务。

3.5 流式响应的统一封装

流式是最容易踩坑的地方。GPT-6 的 SSE 每行是data: {...}，结束标志是data: [DONE]；Opus 5.5 的事件类型更多，有message_start、content_block_delta、message_stop等，增量文本在content_block_delta的delta.text里。

网关要做的是把两者都转成统一的事件格式：

// 统一事件格式 // { type: "delta", text: "..." } // { type: "done" } // { type: "error", message: "..." }

处理 GPT-6 流：

async function* parseGPT6Stream(response) { const decoder = new TextDecoder(); let buffer = ""; for await (const chunk of response.body) { buffer += decoder.decode(chunk, { stream: true }); const lines = buffer.split("\n"); buffer = lines.pop(); for (const line of lines) { if (!line.startsWith("data: ")) continue; const data = line.slice(6).trim(); if (data === "[DONE]") { yield { type: "done" }; return; } try { const json = JSON.parse(data); const text = json.choices?.[0]?.delta?.content; if (text) yield { type: "delta", text }; } catch (e) { // 忽略不完整的分片 } } } }

处理 Opus 5.5 流：

async function* parseOpusStream(response) { const decoder = new TextDecoder(); let buffer = ""; for await (const chunk of response.body) { buffer += decoder.decode(chunk, { stream: true }); const lines = buffer.split("\n"); buffer = lines.pop(); for (const line of lines) { if (!line.startsWith("data: ")) continue; const data = line.slice(6).trim(); try { const json = JSON.parse(data); if (json.type === "content_block_delta" && json.delta?.text) { yield { type: "delta", text: json.delta.text }; } if (json.type === "message_stop") { yield { type: "done" }; return; } } catch (e) { // 忽略不完整的分片 } } } }

这里有个关键细节：buffer的处理必须保留最后一段不完整的行，因为网络分片不保证按行切分。我一开始没做这个处理，结果中文内容偶尔会丢字，排查了很久才发现是分片边界问题。

4. 路由策略：让 auto 模式真正有用

4.1 按成本路由的简单实现

auto模式最简单的策略是按成本选。假设 GPT-6 腰斩后每百万 token 输入 2 元、输出 8 元，Opus 5.5 输入 3 元、输出 12 元，那么默认走 GPT-6，只有在特定条件下才切到 Opus 5.5。

function routeModel(body) { if (body.model !== "auto") return body.model; // 简单策略：长上下文走 Opus，短请求走 GPT-6 const totalChars = body.messages.reduce((s, m) => s + m.content.length, 0); if (totalChars > 8000) return "opus5.5"; return "gpt6"; }

这个策略的依据是：长上下文任务通常对推理质量要求更高，Opus 5.5 在这类任务上表现更稳，多花的成本值得。而短请求用 GPT-6 性价比更高。

4.2 按任务类型路由

更精细的做法是让调用方显式声明任务类型，网关根据类型路由：

调用方在请求里加一个task_type字段，网关查表决定。这样业务代码不需要知道具体模型名，只表达意图，模型选择权收归网关。

4.3 故障自动降级

生产环境必须考虑某家服务不可用的情况。网关在调用失败时应该自动切到另一家：

async function callWithFallback(primary, fallback, body) { try { return await callModel(primary, body); } catch (err) { if (isRetryable(err)) { console.warn(`primary ${primary} failed, fallback to ${fallback}`); return await callModel(fallback, body); } throw err; } }

isRetryable要区分错误类型：网络超时、5xx 可以降级；4xx（比如参数错误、鉴权失败）降级没意义，应该直接抛给调用方。我踩过的坑是把 429 限流也当成可降级错误，结果两家都被限流时疯狂重试，反而加剧了问题。正确做法是限流时先退避，退避后仍失败再考虑降级。

5. 实测中暴露的五个坑与修复过程

5.1 中文流式输出的分片丢字

前面提到过，SSE 分片不按行切分，buffer必须保留最后一段。但还有一个更隐蔽的问题：多字节字符可能被切在两个分片之间。TextDecoder的{ stream: true }选项就是解决这个的，它会把不完整的多字节序列缓存起来，等下一个分片到了再一起解码。如果漏了这个选项，中文和 emoji 会随机出现乱码。

5.2 Opus 的 max_tokens 是必填项

GPT-6 不传max_tokens会用默认值，但 Opus 5.5 在某些版本里max_tokens是必填的，不传直接报 400。网关层应该给一个合理的默认值（比如 2048），而不是依赖调用方每次都传。

5.3 温度参数的取值范围差异

两家对temperature的取值范围定义不完全一致，有的允许 0 到 2，有的只允许 0 到 1。网关层要做钳制：

function clampTemperature(t, min = 0, max = 1) { if (typeof t !== "number") return 0.7; return Math.min(max, Math.max(min, t)); }

不钳制的话，调用方传个 1.5，一家正常一家报错，排查起来很费时间。

5.4 流式请求的错误处理时机

非流式请求出错，HTTP 状态码直接就是错误码。但流式请求一旦开始返回 200，后续的错误只能通过流内事件传递。网关必须在流开始前完成所有可能失败的校验（鉴权、参数、路由），否则业务方拿到 200 却在中途收到错误，处理逻辑会很别扭。

5.5 计量统计的 token 数从哪来

两家的响应里都会返回 token 使用量，但字段路径不同。GPT-6 在usage.prompt_tokens/usage.completion_tokens，Opus 5.5 在usage.input_tokens/usage.output_tokens。网关要统一成一套字段再记录，否则统计报表会缺一半数据。流式请求的 usage 通常在最后一个事件里，别漏了。

6. 把网关接入现有项目的两种方式

6.1 直接改 Base URL

最省事的方式是把现有项目里调用模型的 Base URL 指向网关地址，比如http://localhost:8787/v1。如果现有代码用的是 OpenAI 兼容的 SDK，基本不用改代码就能跑通。这种方式适合快速验证，但要注意 SDK 里可能有些字段网关没做透传，遇到问题先看网关日志。

6.2 封装成内部 SDK

更规范的做法是封装一个薄薄的内部 SDK，把网关的调用细节包起来：

class AIClient { constructor(baseUrl) { this.baseUrl = baseUrl; } async chat(messages, options = {}) { const res = await fetch(`${this.baseUrl}/v1/chat`, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ model: options.model || "auto", messages, stream: options.stream || false, task_type: options.taskType }) }); return res; } }

业务代码只依赖AIClient，模型切换、路由策略调整都在网关侧完成，业务无感知。这是我最推荐的落地方式，前期多花半天封装，后期省下的是无数次的改代码和回归测试。

6.3 本地模型也能接进来

如果你的场景里有本地模型（比如通过 LM Studio 跑的小模型），网关同样可以纳管。只要本地模型暴露了兼容的 HTTP 接口，就在网关里加一个 provider，路由时按任务复杂度决定走本地还是走云端。这样一套接口既能调 GPT-6、Opus 5.5，也能调本地模型，切换成本几乎为零。

7. 成本核算与观测该看哪些指标

网关跑起来之后，最有价值的副产品就是数据。我建议至少记录这几个字段：请求时间、模型名、输入 token、输出 token、耗时、是否流式、是否降级、错误类型。

基于这些数据能回答几个关键问题：哪个模型实际成本更高（不是看单价，是看实际用量乘以单价）、哪些接口的 token 消耗异常、降级发生的频率和原因、P95 延迟是多少。

我自己的做法是每天跑一个聚合脚本，把当天数据按模型和接口分组，输出一张简单的表。不要一上来就上复杂的监控系统，先用最朴素的方式把数据攒起来，等你看清楚规律了再决定要不要上工具。很多时候你会发现，真正烧钱的就那么两三个接口，优化它们比优化整个系统有效得多。

8. 关于多模型接入，我踩过之后才明白的几件事

第一，统一格式的价值远大于统一模型。模型会一直换，但只要你内部的请求和响应格式是稳定的，换模型就是改配置的事。我现在的项目里，模型名只出现在网关的配置文件里，业务代码里一个都找不到。

第二，流式处理值得单独花时间打磨。很多团队把流式当成"顺便支持一下"，结果线上问题一半出在流式上。分片边界、多字节字符、错误时机、结束标志，每一个都要单独测。我的做法是写一组针对流的单元测试，用模拟的分片数据喂进去，覆盖各种边界。

第三，降级策略要保守。不是所有错误都该降级，降级本身也可能失败，降级后的模型输出格式可能和预期不同。我现在的策略是：只在明确的网络错误和 5xx 上降级，且降级后记录一条告警，人工确认是否需要调整。

第四，别急着追求"智能路由"。一开始用最简单的规则就好，比如按长度或按任务类型。等积累了足够的数据，再考虑用数据驱动的方式优化路由。过早引入复杂的路由逻辑，只会让你在出问题时不知道该怀疑哪一层。

这套网关我从最初的两百行代码，慢慢迭代到现在能稳定支撑日常调用，中间改过很多次。核心经验就一条：把变化的部分隔离出来，让不变的部分保持简单。模型是变化的，协议是变化的，价格是变化的；而你的业务逻辑、你的内部格式、你的调用方式，应该尽量不变。网关就是那道隔离墙。