1. 两个模型同时上桌为什么“调用”反而成了新问题GPT-6 价格腰斩、Opus 5.5 上线这两件事凑在一起对一线开发者来说其实是个挺微妙的节点。以前大家纠结的是“用哪个模型”现在纠结的是“怎么把两个都接进来还别把自己搞死”。我身边不少朋友第一反应是便宜了那就多调几次呗。结果真上手才发现调用这件事本身开始变得比模型能力更值得琢磨。先说清楚这篇东西是给谁看的。如果你只是偶尔在网页上问问问题那确实没必要折腾官方入口点一下就行。但如果你在做产品、做内部工具、或者像我一样喜欢把各种模型拼起来跑工作流那“丝滑调用两个模型”就是一个绕不开的工程问题。它涉及的不只是 API 地址和密钥还包括请求怎么路由、成本怎么控制、失败怎么兜底、本地和云端怎么混着用。我自己这段时间的体感是模型价格下降带来的最大变化不是“省钱”而是“试错成本变低”。以前调一次贵模型要掂量半天现在可以放心地让便宜模型先跑一遍贵的模型只处理真正难的部分。这种“分层调用”的思路才是标题里“丝滑”两个字真正的含义。下面我就按自己实际搭过的一套方案把思路、细节、坑和排查过程完整讲一遍。2. 整体设计思路为什么我不建议直接硬编码两个 API2.1 直接调两个接口问题出在哪最朴素的做法是在代码里写两个函数一个调 GPT-6一个调 Opus 5.5需要哪个就 if-else 一下。我一开始也是这么干的代码量确实少但很快就遇到几个现实问题。第一是密钥和地址散落在各处。项目稍微大一点前端、后端、脚本、定时任务里都可能有调用逻辑改一个模型名要全局搜索替换漏一处就出 bug。第二是没法统一做重试和降级。GPT-6 偶尔超时我想自动切到 Opus 5.5硬编码的方式就得在每个调用点都写一遍兜底逻辑重复且容易漏。第三是成本统计做不了。两个模型的计费方式、token 统计口径不一样散着调根本没法汇总。所以我的结论是只要你不是写个一次性脚本就应该在模型和业务代码之间加一层。这一层可以叫“AI 网关”也可以叫“模型路由层”名字不重要重要的是它把“调哪个模型、怎么调、失败了怎么办”这些事从业务逻辑里剥离出来。2.2 网关层要解决的四件事我给自己定的目标是四件事后来发现这四件事基本覆盖了绝大多数调用场景。统一入口业务代码只认一个地址、一套鉴权具体走哪个模型由网关决定。路由策略能按任务类型、成本、延迟、可用性自动选模型也能手动指定。降级兜底主模型失败或超时自动切备用模型业务侧无感知。可观测每次调用走了哪个模型、花了多少 token、耗时多少都能查到。这四件事里前两件决定“丝滑”后两件决定“敢不敢上生产”。很多人只做了前两件结果线上出问题两眼一抹黑这是很典型的坑。2.3 为什么选 ServBay 这类本地环境来搭热词里出现了 ServBay我理解它在这里的角色是“本地一键起服务”的工具。搭网关层不一定非要它但如果你像我一样习惯在本地先把整套流程跑通再上云那用这类集成环境确实省事。它把运行环境、依赖、端口管理都打包好了你只需要关注网关本身的逻辑。我的做法是本地用集成环境起一个轻量网关服务配置两个上游模型业务代码连本地网关。等逻辑稳定了再把网关配置原样搬到服务器。这样本地和线上行为一致不会出现“本地好好的上线就崩”的经典问题。需要说明的是具体用哪个工具不是重点重点是“本地可复现”这个原则。3. 核心细节拆解路由、降级、成本这三块怎么设计3.1 路由策略不是越智能越好路由听起来很高级但我的经验是规则越简单越可靠。我见过有人一上来就搞“根据 prompt 语义自动选模型”结果调试成本极高效果还不稳定。我自己的策略分三层从简单到复杂。第一层是显式指定。业务代码明确说“这次要用 Opus 5.5”网关就老老实实转发不做任何判断。这层覆盖了大部分确定性场景比如代码生成、复杂推理这种我知道贵模型更稳的任务。第二层是按任务标签路由。我在请求里带一个task字段比如task: summary走便宜模型task: reasoning走贵模型。网关维护一张映射表改策略只改表不动业务代码。这张表长这样任务标签首选模型备用模型说明summaryGPT-6Opus 5.5摘要类便宜优先reasoningOpus 5.5GPT-6推理类质量优先codeOpus 5.5GPT-6代码类实测更稳chatGPT-6Opus 5.5普通对话成本优先第三层才是动态兜底。当前两层都正常时不启用只有当首选模型报错、超时或限流时才触发切换。这样既保证了可预测性又留了容错空间。3.2 降级兜底超时和限流要分开处理降级这件事很多人只做了“报错就切”但实际线上更常见的是“没报错但很慢”和“被限流”。这两种情况处理方式不一样。超时我一般设两档软超时和硬超时。软超时比如 8 秒到了就启动备用模型的请求但主请求不取消谁先回来用谁。硬超时比如 20 秒到了直接取消主请求只用备用结果。这样既不会因为主模型偶尔慢就浪费一次调用也不会让用户等太久。限流则要看返回的状态码和错误信息。如果是明确的限流信号我会把该模型临时标记为“冷却中”冷却期内所有请求直接走备用避免反复撞墙。冷却时间我一般设 30 到 60 秒太短没意义太长又浪费恢复机会。注意降级不是无脑切。如果两个模型都失败要有一个最终的兜底响应比如返回缓存结果或明确的错误提示而不是让请求悬在那里。3.3 成本控制价格腰斩之后更要算清楚GPT-6 价格降了不代表可以随便造。我见过价格下降后调用量暴涨、月底账单反而更高的案例。原因就是大家觉得便宜了把不该用大模型的请求也丢进去了。我的做法是给每个任务标签设一个 token 预算上限。比如 summary 类任务输入加输出超过 4000 token 就拒绝或截断因为摘要本来就不需要那么长。这个上限写在网关配置里业务侧不用管。同时网关记录每次调用的 token 消耗按模型和任务维度汇总每周看一眼就能发现哪些任务在偷偷烧钱。这里有个细节不同模型的 token 计算方式可能不一样尤其是中英文混合的时候。我的经验是不要自己估算直接用接口返回的 usage 字段那个最准。如果接口没返回就按字符数粗略折算但只用于监控告警不用于精确计费。4. 实操过程从零把两个模型接进同一个网关4.1 环境准备与依赖安装我假设你已经有一个能跑服务的本地环境。如果用的是集成环境确认服务能正常启动、端口能访问就行。然后装几个基础依赖我用的是 Python 生态其他语言思路一样。pip install fastapi uvicorn httpx pydantic选 FastAPI 是因为它写异步接口很顺手网关这种 IO 密集型服务用异步能扛更多并发。httpx 用来发上游请求支持异步和超时控制。pydantic 用来做配置校验避免配置写错了到运行时才炸。配置我单独放一个文件不硬编码在代码里。这样本地和线上可以用不同配置改配置不用改代码。# config.py MODELS { gpt6: { base_url: https://api.example.com/v1, api_key: YOUR_KEY, model_name: gpt-6, timeout: 20, cooldown: 60, }, opus55: { base_url: https://api.example.com/v1, api_key: YOUR_KEY, model_name: opus-5.5, timeout: 20, cooldown: 60, }, } ROUTES { summary: [gpt6, opus55], reasoning: [opus55, gpt6], code: [opus55, gpt6], chat: [gpt6, opus55], }提示base_url 和 api_key 请替换成你自己实际使用的服务地址和密钥。不同服务商的接口格式可能有差异接入前先看一遍文档确认请求体和响应体的字段名。4.2 网关核心逻辑一次请求的完整生命周期网关收到请求后大致走这么几步解析请求、确定候选模型列表、按顺序尝试、记录结果、返回响应。我把核心逻辑写成一个函数方便复用。import time import httpx from fastapi import FastAPI, Request from config import MODELS, ROUTES app FastAPI() cooldown_until {} async def call_model(model_key: str, payload: dict): cfg MODELS[model_key] headers {Authorization: fBearer {cfg[api_key]}} body {**payload, model: cfg[model_name]} async with httpx.AsyncClient(timeoutcfg[timeout]) as client: resp await client.post( f{cfg[base_url]}/chat/completions, jsonbody, headersheaders, ) resp.raise_for_status() return resp.json() app.post(/v1/chat) async def chat(request: Request): payload await request.json() task payload.pop(task, chat) candidates ROUTES.get(task, ROUTES[chat]) last_error None for model_key in candidates: if cooldown_until.get(model_key, 0) time.time(): continue try: start time.time() result await call_model(model_key, payload) elapsed time.time() - start result[_meta] { model: model_key, elapsed: round(elapsed, 3), } return result except Exception as e: last_error e cooldown_until[model_key] time.time() MODELS[model_key][cooldown] continue return {error: all models failed, detail: str(last_error)}这段代码有几个点值得说。第一task字段从 payload 里 pop 出来不会传给上游模型避免上游报未知字段错误。第二冷却判断放在尝试之前冷却中的模型直接跳过不浪费一次请求。第三每次成功返回都带上_meta记录实际用了哪个模型、耗时多少方便排查。4.3 流式调用怎么处理上面是普通调用但实际用起来流式输出体验好太多。流式的处理逻辑不太一样因为响应是一段一段来的不能等全部结束再判断成功失败。我的做法是流式请求先建立连接拿到第一个数据块才算“成功”如果连接阶段就失败直接切下一个模型。一旦开始输出就不再切换因为切了用户会看到内容突然断掉重来体验很差。from fastapi.responses import StreamingResponse app.post(/v1/chat/stream) async def chat_stream(request: Request): payload await request.json() task payload.pop(task, chat) candidates ROUTES.get(task, ROUTES[chat]) async def generate(): for model_key in candidates: if cooldown_until.get(model_key, 0) time.time(): continue cfg MODELS[model_key] headers {Authorization: fBearer {cfg[api_key]}} body {**payload, model: cfg[model_name], stream: True} try: async with httpx.AsyncClient(timeoutcfg[timeout]) as client: async with client.stream( POST, f{cfg[base_url]}/chat/completions, jsonbody, headersheaders, ) as resp: resp.raise_for_status() async for chunk in resp.aiter_bytes(): yield chunk return except Exception: cooldown_until[model_key] time.time() cfg[cooldown] continue yield b{error: all models failed} return StreamingResponse(generate(), media_typetext/event-stream)注意流式场景下raise_for_status要在开始迭代数据块之前调用否则可能已经吐了一部分内容才发现状态码不对。这个顺序很关键我踩过这个坑。4.4 本地模型和云端模型混用热词里提到“调用本地模型”这其实是另一个很实用的场景。有些任务不敏感、量大、对延迟要求不高完全可以用本地跑的小模型处理省下云端调用成本。我的网关设计里本地模型和云端模型一视同仁都是配置表里的一项只是 base_url 指向本地地址。MODELS[local] { base_url: http://127.0.0.1:1234/v1, api_key: not-needed, model_name: local-model, timeout: 60, cooldown: 10, }本地模型超时时间我设得长一些因为本地推理速度受硬件影响大。冷却时间设短一些因为本地服务重启快没必要冷却太久。路由表里可以把一些低优先级任务指向本地比如日志摘要、格式转换这类。5. 常见问题与排查技巧实录5.1 请求发出去了但一直没响应这是最常见的问题原因通常有三类。第一类是网络问题上游地址不通或 DNS 解析失败。排查方法是先用 curl 直接打上游接口确认网络层没问题。第二类是超时设置不合理比如上游正常响应要 15 秒你设了 10 秒超时那必然失败。第三类是请求体格式不对上游在解析阶段就卡住了。我的排查顺序是先 curl 直连再检查超时配置最后对比请求体字段。这个顺序能覆盖九成以上的“无响应”问题。5.2 降级切换后结果风格不一致这个问题很隐蔽。GPT-6 和 Opus 5.5 的输出风格、格式习惯不一样降级切换后用户可能明显感觉到“换了个 AI”。我的处理方式是在网关层做一层输出规范化比如统一去掉多余的前后缀、统一 JSON 格式。如果业务对格式要求严格就在 prompt 里明确约束输出格式两个模型都遵守同一套约束切换时差异会小很多。5.3 成本统计对不上前面说过不同模型 token 计算口径可能不同。我遇到过一次网关统计的 token 数和账单对不上差了大概 15%。后来发现是流式响应的 usage 字段在最后一个数据块里我一开始没解析。修正后误差降到 2% 以内。所以流式场景一定要记得从最后一个 chunk 里取 usage。5.4 常见问题速查表现象可能原因排查动作请求无响应网络不通 / 超时太短 / 请求体错误curl 直连、检查超时、对比字段降级后风格突变模型输出习惯不同统一输出规范、prompt 约束格式成本统计偏差大流式 usage 未解析从最后一个 chunk 取 usage频繁触发降级主模型限流或冷却设置不当查看错误码、调整冷却时间本地模型响应慢硬件资源不足降低并发、缩短输入、换更小模型5.5 几个我踩过的坑第一个坑是把 task 字段透传给上游。有些上游对未知字段很严格直接报 400我排查了半天才发现是网关自己加的字段没清理。第二个坑是冷却时间设太短。一开始设 10 秒结果限流还没恢复就又去撞反复失败。后来改成 60 秒稳定多了。第三个坑是流式响应没做异常捕获。有一次上游中途断开网关直接把异常抛给客户端前端显示一半内容卡住。后来在流式生成器里加了 try-except断开时补一个结束标记前端就能正常收尾。6. 关于“丝滑”的一点个人体会搭完这套东西之后我最大的感受是丝滑不是靠某个神奇工具而是靠把边界情况想清楚。模型本身的能力固然重要但真正决定体验的是那些不起眼的细节——超时设多少、冷却多久、流式怎么收尾、成本怎么统计。这些东西官方文档不会写只能自己踩出来。另外价格下降确实改变了调用策略。以前是“能省则省”现在是“该用就用但要用对地方”。我现在会把大部分请求先给便宜模型只有它明确搞不定的才升级到贵模型。这种分层思路配合网关的路由和降级整体成本比之前硬调贵模型低了不少质量还没明显下降。如果你也在搭类似的调用层我的建议是先从最简单的显式路由开始跑通了再加降级和统计。一上来就搞复杂策略调试成本会高到让你怀疑人生。等基础稳定了再逐步加本地模型、流式、成本监控这些每一步都有明确的收益心里也踏实。 GPT-6与Opus 5.5双模型丝滑调用：AI网关路由、降级与成本控制实战
1. 两个模型同时上桌为什么“调用”反而成了新问题GPT-6 价格腰斩、Opus 5.5 上线这两件事凑在一起对一线开发者来说其实是个挺微妙的节点。以前大家纠结的是“用哪个模型”现在纠结的是“怎么把两个都接进来还别把自己搞死”。我身边不少朋友第一反应是便宜了那就多调几次呗。结果真上手才发现调用这件事本身开始变得比模型能力更值得琢磨。先说清楚这篇东西是给谁看的。如果你只是偶尔在网页上问问问题那确实没必要折腾官方入口点一下就行。但如果你在做产品、做内部工具、或者像我一样喜欢把各种模型拼起来跑工作流那“丝滑调用两个模型”就是一个绕不开的工程问题。它涉及的不只是 API 地址和密钥还包括请求怎么路由、成本怎么控制、失败怎么兜底、本地和云端怎么混着用。我自己这段时间的体感是模型价格下降带来的最大变化不是“省钱”而是“试错成本变低”。以前调一次贵模型要掂量半天现在可以放心地让便宜模型先跑一遍贵的模型只处理真正难的部分。这种“分层调用”的思路才是标题里“丝滑”两个字真正的含义。下面我就按自己实际搭过的一套方案把思路、细节、坑和排查过程完整讲一遍。2. 整体设计思路为什么我不建议直接硬编码两个 API2.1 直接调两个接口问题出在哪最朴素的做法是在代码里写两个函数一个调 GPT-6一个调 Opus 5.5需要哪个就 if-else 一下。我一开始也是这么干的代码量确实少但很快就遇到几个现实问题。第一是密钥和地址散落在各处。项目稍微大一点前端、后端、脚本、定时任务里都可能有调用逻辑改一个模型名要全局搜索替换漏一处就出 bug。第二是没法统一做重试和降级。GPT-6 偶尔超时我想自动切到 Opus 5.5硬编码的方式就得在每个调用点都写一遍兜底逻辑重复且容易漏。第三是成本统计做不了。两个模型的计费方式、token 统计口径不一样散着调根本没法汇总。所以我的结论是只要你不是写个一次性脚本就应该在模型和业务代码之间加一层。这一层可以叫“AI 网关”也可以叫“模型路由层”名字不重要重要的是它把“调哪个模型、怎么调、失败了怎么办”这些事从业务逻辑里剥离出来。2.2 网关层要解决的四件事我给自己定的目标是四件事后来发现这四件事基本覆盖了绝大多数调用场景。统一入口业务代码只认一个地址、一套鉴权具体走哪个模型由网关决定。路由策略能按任务类型、成本、延迟、可用性自动选模型也能手动指定。降级兜底主模型失败或超时自动切备用模型业务侧无感知。可观测每次调用走了哪个模型、花了多少 token、耗时多少都能查到。这四件事里前两件决定“丝滑”后两件决定“敢不敢上生产”。很多人只做了前两件结果线上出问题两眼一抹黑这是很典型的坑。2.3 为什么选 ServBay 这类本地环境来搭热词里出现了 ServBay我理解它在这里的角色是“本地一键起服务”的工具。搭网关层不一定非要它但如果你像我一样习惯在本地先把整套流程跑通再上云那用这类集成环境确实省事。它把运行环境、依赖、端口管理都打包好了你只需要关注网关本身的逻辑。我的做法是本地用集成环境起一个轻量网关服务配置两个上游模型业务代码连本地网关。等逻辑稳定了再把网关配置原样搬到服务器。这样本地和线上行为一致不会出现“本地好好的上线就崩”的经典问题。需要说明的是具体用哪个工具不是重点重点是“本地可复现”这个原则。3. 核心细节拆解路由、降级、成本这三块怎么设计3.1 路由策略不是越智能越好路由听起来很高级但我的经验是规则越简单越可靠。我见过有人一上来就搞“根据 prompt 语义自动选模型”结果调试成本极高效果还不稳定。我自己的策略分三层从简单到复杂。第一层是显式指定。业务代码明确说“这次要用 Opus 5.5”网关就老老实实转发不做任何判断。这层覆盖了大部分确定性场景比如代码生成、复杂推理这种我知道贵模型更稳的任务。第二层是按任务标签路由。我在请求里带一个task字段比如task: summary走便宜模型task: reasoning走贵模型。网关维护一张映射表改策略只改表不动业务代码。这张表长这样任务标签首选模型备用模型说明summaryGPT-6Opus 5.5摘要类便宜优先reasoningOpus 5.5GPT-6推理类质量优先codeOpus 5.5GPT-6代码类实测更稳chatGPT-6Opus 5.5普通对话成本优先第三层才是动态兜底。当前两层都正常时不启用只有当首选模型报错、超时或限流时才触发切换。这样既保证了可预测性又留了容错空间。3.2 降级兜底超时和限流要分开处理降级这件事很多人只做了“报错就切”但实际线上更常见的是“没报错但很慢”和“被限流”。这两种情况处理方式不一样。超时我一般设两档软超时和硬超时。软超时比如 8 秒到了就启动备用模型的请求但主请求不取消谁先回来用谁。硬超时比如 20 秒到了直接取消主请求只用备用结果。这样既不会因为主模型偶尔慢就浪费一次调用也不会让用户等太久。限流则要看返回的状态码和错误信息。如果是明确的限流信号我会把该模型临时标记为“冷却中”冷却期内所有请求直接走备用避免反复撞墙。冷却时间我一般设 30 到 60 秒太短没意义太长又浪费恢复机会。注意降级不是无脑切。如果两个模型都失败要有一个最终的兜底响应比如返回缓存结果或明确的错误提示而不是让请求悬在那里。3.3 成本控制价格腰斩之后更要算清楚GPT-6 价格降了不代表可以随便造。我见过价格下降后调用量暴涨、月底账单反而更高的案例。原因就是大家觉得便宜了把不该用大模型的请求也丢进去了。我的做法是给每个任务标签设一个 token 预算上限。比如 summary 类任务输入加输出超过 4000 token 就拒绝或截断因为摘要本来就不需要那么长。这个上限写在网关配置里业务侧不用管。同时网关记录每次调用的 token 消耗按模型和任务维度汇总每周看一眼就能发现哪些任务在偷偷烧钱。这里有个细节不同模型的 token 计算方式可能不一样尤其是中英文混合的时候。我的经验是不要自己估算直接用接口返回的 usage 字段那个最准。如果接口没返回就按字符数粗略折算但只用于监控告警不用于精确计费。4. 实操过程从零把两个模型接进同一个网关4.1 环境准备与依赖安装我假设你已经有一个能跑服务的本地环境。如果用的是集成环境确认服务能正常启动、端口能访问就行。然后装几个基础依赖我用的是 Python 生态其他语言思路一样。pip install fastapi uvicorn httpx pydantic选 FastAPI 是因为它写异步接口很顺手网关这种 IO 密集型服务用异步能扛更多并发。httpx 用来发上游请求支持异步和超时控制。pydantic 用来做配置校验避免配置写错了到运行时才炸。配置我单独放一个文件不硬编码在代码里。这样本地和线上可以用不同配置改配置不用改代码。# config.py MODELS { gpt6: { base_url: https://api.example.com/v1, api_key: YOUR_KEY, model_name: gpt-6, timeout: 20, cooldown: 60, }, opus55: { base_url: https://api.example.com/v1, api_key: YOUR_KEY, model_name: opus-5.5, timeout: 20, cooldown: 60, }, } ROUTES { summary: [gpt6, opus55], reasoning: [opus55, gpt6], code: [opus55, gpt6], chat: [gpt6, opus55], }提示base_url 和 api_key 请替换成你自己实际使用的服务地址和密钥。不同服务商的接口格式可能有差异接入前先看一遍文档确认请求体和响应体的字段名。4.2 网关核心逻辑一次请求的完整生命周期网关收到请求后大致走这么几步解析请求、确定候选模型列表、按顺序尝试、记录结果、返回响应。我把核心逻辑写成一个函数方便复用。import time import httpx from fastapi import FastAPI, Request from config import MODELS, ROUTES app FastAPI() cooldown_until {} async def call_model(model_key: str, payload: dict): cfg MODELS[model_key] headers {Authorization: fBearer {cfg[api_key]}} body {**payload, model: cfg[model_name]} async with httpx.AsyncClient(timeoutcfg[timeout]) as client: resp await client.post( f{cfg[base_url]}/chat/completions, jsonbody, headersheaders, ) resp.raise_for_status() return resp.json() app.post(/v1/chat) async def chat(request: Request): payload await request.json() task payload.pop(task, chat) candidates ROUTES.get(task, ROUTES[chat]) last_error None for model_key in candidates: if cooldown_until.get(model_key, 0) time.time(): continue try: start time.time() result await call_model(model_key, payload) elapsed time.time() - start result[_meta] { model: model_key, elapsed: round(elapsed, 3), } return result except Exception as e: last_error e cooldown_until[model_key] time.time() MODELS[model_key][cooldown] continue return {error: all models failed, detail: str(last_error)}这段代码有几个点值得说。第一task字段从 payload 里 pop 出来不会传给上游模型避免上游报未知字段错误。第二冷却判断放在尝试之前冷却中的模型直接跳过不浪费一次请求。第三每次成功返回都带上_meta记录实际用了哪个模型、耗时多少方便排查。4.3 流式调用怎么处理上面是普通调用但实际用起来流式输出体验好太多。流式的处理逻辑不太一样因为响应是一段一段来的不能等全部结束再判断成功失败。我的做法是流式请求先建立连接拿到第一个数据块才算“成功”如果连接阶段就失败直接切下一个模型。一旦开始输出就不再切换因为切了用户会看到内容突然断掉重来体验很差。from fastapi.responses import StreamingResponse app.post(/v1/chat/stream) async def chat_stream(request: Request): payload await request.json() task payload.pop(task, chat) candidates ROUTES.get(task, ROUTES[chat]) async def generate(): for model_key in candidates: if cooldown_until.get(model_key, 0) time.time(): continue cfg MODELS[model_key] headers {Authorization: fBearer {cfg[api_key]}} body {**payload, model: cfg[model_name], stream: True} try: async with httpx.AsyncClient(timeoutcfg[timeout]) as client: async with client.stream( POST, f{cfg[base_url]}/chat/completions, jsonbody, headersheaders, ) as resp: resp.raise_for_status() async for chunk in resp.aiter_bytes(): yield chunk return except Exception: cooldown_until[model_key] time.time() cfg[cooldown] continue yield b{error: all models failed} return StreamingResponse(generate(), media_typetext/event-stream)注意流式场景下raise_for_status要在开始迭代数据块之前调用否则可能已经吐了一部分内容才发现状态码不对。这个顺序很关键我踩过这个坑。4.4 本地模型和云端模型混用热词里提到“调用本地模型”这其实是另一个很实用的场景。有些任务不敏感、量大、对延迟要求不高完全可以用本地跑的小模型处理省下云端调用成本。我的网关设计里本地模型和云端模型一视同仁都是配置表里的一项只是 base_url 指向本地地址。MODELS[local] { base_url: http://127.0.0.1:1234/v1, api_key: not-needed, model_name: local-model, timeout: 60, cooldown: 10, }本地模型超时时间我设得长一些因为本地推理速度受硬件影响大。冷却时间设短一些因为本地服务重启快没必要冷却太久。路由表里可以把一些低优先级任务指向本地比如日志摘要、格式转换这类。5. 常见问题与排查技巧实录5.1 请求发出去了但一直没响应这是最常见的问题原因通常有三类。第一类是网络问题上游地址不通或 DNS 解析失败。排查方法是先用 curl 直接打上游接口确认网络层没问题。第二类是超时设置不合理比如上游正常响应要 15 秒你设了 10 秒超时那必然失败。第三类是请求体格式不对上游在解析阶段就卡住了。我的排查顺序是先 curl 直连再检查超时配置最后对比请求体字段。这个顺序能覆盖九成以上的“无响应”问题。5.2 降级切换后结果风格不一致这个问题很隐蔽。GPT-6 和 Opus 5.5 的输出风格、格式习惯不一样降级切换后用户可能明显感觉到“换了个 AI”。我的处理方式是在网关层做一层输出规范化比如统一去掉多余的前后缀、统一 JSON 格式。如果业务对格式要求严格就在 prompt 里明确约束输出格式两个模型都遵守同一套约束切换时差异会小很多。5.3 成本统计对不上前面说过不同模型 token 计算口径可能不同。我遇到过一次网关统计的 token 数和账单对不上差了大概 15%。后来发现是流式响应的 usage 字段在最后一个数据块里我一开始没解析。修正后误差降到 2% 以内。所以流式场景一定要记得从最后一个 chunk 里取 usage。5.4 常见问题速查表现象可能原因排查动作请求无响应网络不通 / 超时太短 / 请求体错误curl 直连、检查超时、对比字段降级后风格突变模型输出习惯不同统一输出规范、prompt 约束格式成本统计偏差大流式 usage 未解析从最后一个 chunk 取 usage频繁触发降级主模型限流或冷却设置不当查看错误码、调整冷却时间本地模型响应慢硬件资源不足降低并发、缩短输入、换更小模型5.5 几个我踩过的坑第一个坑是把 task 字段透传给上游。有些上游对未知字段很严格直接报 400我排查了半天才发现是网关自己加的字段没清理。第二个坑是冷却时间设太短。一开始设 10 秒结果限流还没恢复就又去撞反复失败。后来改成 60 秒稳定多了。第三个坑是流式响应没做异常捕获。有一次上游中途断开网关直接把异常抛给客户端前端显示一半内容卡住。后来在流式生成器里加了 try-except断开时补一个结束标记前端就能正常收尾。6. 关于“丝滑”的一点个人体会搭完这套东西之后我最大的感受是丝滑不是靠某个神奇工具而是靠把边界情况想清楚。模型本身的能力固然重要但真正决定体验的是那些不起眼的细节——超时设多少、冷却多久、流式怎么收尾、成本怎么统计。这些东西官方文档不会写只能自己踩出来。另外价格下降确实改变了调用策略。以前是“能省则省”现在是“该用就用但要用对地方”。我现在会把大部分请求先给便宜模型只有它明确搞不定的才升级到贵模型。这种分层思路配合网关的路由和降级整体成本比之前硬调贵模型低了不少质量还没明显下降。如果你也在搭类似的调用层我的建议是先从最简单的显式路由开始跑通了再加降级和统计。一上来就搞复杂策略调试成本会高到让你怀疑人生。等基础稳定了再逐步加本地模型、流式、成本监控这些每一步都有明确的收益心里也踏实。