API + 自托管混合推理方案：灵活性与成本的最优解
“全用 API”和”全部自建”都是极端选择，多数团队最终走向混合方案——用 API 处理弹性流量，用自建资源处理合规或成本敏感的负载。关键是把路由逻辑设计对。
我带过的一个团队最早是纯 API 起步，量小的时候一个月账单几千块，没人操心。业务涨到日均几百万 token 之后账单涨到五位数，老板才开始问这笔钱能不能省一半。这时候直接一刀切全自建也不现实——大促流量一来，自建节点的显存和队列根本扛不住，服务直接超时。真正能省钱又不翻车的做法，是把流量拆开：可预测的那部分自己扛，不可预测的峰值和高难度任务继续交给 API。下面几种模式，是我们踩过坑之后沉淀下来的，你可以对照自己的业务场景挑一种起步，不用一次上全套。
为什么需要混合方案？
单纯 API 的问题：合规数据无法外发、高并发稳定流量边际成本偏高。
单纯自建的问题：峰值流量难以弹性扩容、运维成本固定、模型迭代慢。
混合方案的思路：用自建资源处理可预测的基线流量，用 API 承接弹性峰值和特殊场景。
怎么判断哪部分是「基线」？拉一下过去 30 天的 QPS 曲线，取 P50 作为基线容量，自建按 P50 的 1.2 倍左右配置资源，长期稳定跑满即可；P50 到 P95 之间的波动交给自建的弹性余量，P95 以上的尖峰直接甩给 API，不要为了应付一年可能就出现几次的尖峰去囤显卡——那笔钱够你付好几年的 API 账单了。
混合架构的四种常见模式
模式 1：按合规性分流
最常见也最简单的分流逻辑——看数据能不能出本地：
请求
├── 含敏感数据（用户个人信息、内部文档）→ 本地自建模型
└── 非敏感数据（通用问答、公开内容）→ 商业 API
适合金融、医疗、政务场景，合规边界清晰，路由判断简单。
按合规性分流看着简单，真正踩坑的地方在「元数据」。用户输入的正文你脱敏了，但请求里附带的 user_id、IP、设备指纹这些字段如果原样透传给商业 API，一样构成数据外发。我们之前审计时发现日志采集器把请求头里的手机号也带出去了，业务代码自己完全没意识到。建议在网关层加一道统一的字段级脱敏中间件，而不是指望每个业务方自己记得清理，人是靠不住的，流程才是。
模式 2：按模型能力分级路由
不同难度的任务用不同模型，平衡质量与成本：
请求
├── 简单任务（分类、摘要、格式化）→ 自建小模型（7B）
├── 中等任务（代码辅助、内容生成）→ 自建中模型（32B）
└── 复杂任务（深度推理、长文档）→ 商业 API 旗舰模型
| 层级 | 模型规模 | 单次成本 | 适合任务 |
|---|---|---|---|
| 轻量层（自建） | 7B–14B | 极低 | 意图分类、提取、简短回复 |
| 中等层（自建/API） | 32B–72B | 中 | 代码生成、内容创作、RAG |
| 旗舰层（API） | 700B+ / GPT-4 级 | 较高 | 复杂推理、多步 Agent |
分级路由最大的风险是分类器判断错了任务难度。我们上线初期用关键词加简单规则做分类，结果一批需要多步推理的复杂问题被误判成「简单任务」扔给了 7B 模型，回复质量明显下滑，客服那边收到不少投诉才发现。后来改成先用一个轻量分类模型打分，分数落在中间地带（比如 0.4–0.6）的请求直接升级到旗舰层兜底，而不是卡在一刀切的阈值上。这样多花的 API 成本大概是总量的 3%–5%，但避免了质量事故，账算下来完全划算。
模式 3：按流量弹性切换
自建资源处理日常流量，流量峰值时自动溢出到 API：
请求 → 负载均衡器
├── 自建节点队列未满 → 优先走自建（低成本）
└── 自建节点超载（队列 > 阈值）→ 溢出到 API（弹性兜底）
这一模式需要 API Gateway 支持动态路由规则，如 LiteLLM、One API 等均可配置。
LiteLLM 内置的几种路由策略行为差别不小，选错了很容易踩坑：
| 策略 | 判断依据 | 适合场景 | 坑 |
|---|---|---|---|
| least-busy | 当前排队请求数 | 节点数少、负载波动大 | 队列深度是采样值，有几秒延迟，突发流量下容易「刚判断完就已经过载」 |
| latency-based-routing | 近期响应延迟 | 节点性能不均衡 | 冷启动节点会被误判为「快」，反而被灌满流量 |
| usage-based-routing | token 用量配额 | 需要按配额限流的多租户场景 | 配额刷新周期设置不当会导致月初/月末流量抖动 |
我们最后选的是 least-busy 加一个简单的滑动窗口平滑，把采样延迟的问题缓解掉，没有再用 latency-based-routing，因为冷启动误判在我们的场景里出现频率太高。
模式 4：主备容灾切换
自建作为主路径，API 作为故障兜底：
自建推理服务
├── 健康 → 正常服务
└── 故障（超时/OOM/重启）→ 自动 Failover 到 API
配合网关的健康检查和重试机制，对用户无感知。
主备切换这块，你大概率会先遇到这个报错：httpx.ReadTimeout: timed out 或者 vLLM 端返回 CUDA out of memory。前者通常是自建节点排队过长，网关的健康检查还没反应过来；后者是并发请求把显存打爆，vLLM 进程直接崩溃重启，这段时间内的请求全部失败。
根因排查顺序：先看 Prometheus 里 GPU 显存曲线是不是在故障前就已经贴着上限走，如果是，说明是容量不够，加健康检查频率只是治标；如果显存正常但请求还是超时，多半是队列参数没配对（比如 vLLM 的 --max-num-seqs 设太高，超过实际显存能撑住的并发）。
修法是两步走：一是把健康检查间隔从默认 60 秒调到 10 秒以内，让 Failover 反应更快；二是给自建节点加一个基于显存占用率的熔断，占用率超过 90% 就主动拒绝新请求走降级，而不是硬扛到 OOM 崩溃——崩溃重启的恢复时间比主动降级长得多，用户感知的中断时间会差一个数量级。
关键技术组件
| 组件 | 作用 | 推荐选型 |
|---|---|---|
| API Gateway | 统一入口，路由、负载均衡、限流、计费 | LiteLLM Proxy / One API / New API |
| 自建推理服务 | 本地 GPU 推理，OpenAI 协议兼容 | vLLM / SGLang |
| 监控告警 | 监控队列深度、GPU 利用率、错误率 | Prometheus + Grafana |
| 路由规则引擎 | 按 tag/model/成本动态决策 | LiteLLM Router |
这份配置里容易被忽略的是 api_base 和 model 两个字段的配合关系：LiteLLM 并不关心你本地服务用的是什么框架，它只按 OpenAI 协议的请求 / 响应格式转发。vLLM 从 0.4 版本之后默认就暴露了 /v1/chat/completions 等 OpenAI 兼容接口，所以 api_base 只要指向这个地址，LiteLLM 就能把它当成一个「普通的 OpenAI 兼容后端」来路由，业务侧完全感知不到后面到底是 vLLM 还是 gpt-4o。这也是混合架构能落地的前提——如果你的自建服务没有做协议兼容，还得自己写一层适配器，工作量不小，建议直接选支持 OpenAI 协议的推理框架，省掉这一步。
LiteLLM Proxy 的路由配置示例：
model_list:
- model_name: qwen-fast # 对外暴露的模型名
litellm_params:
model: openai/qwen2.5-7b
api_base: http://localhost:8000/v1 # 本地 vLLM
- model_name: gpt-4o # 旗舰任务走商业 API
litellm_params:
model: gpt-4o
api_key: sk-xxx
router_settings:
routing_strategy: least-busy # 按队列深度路由
fallbacks: [{"qwen-fast": ["gpt-4o"]}] # 本地失败时回退到 API
fallbacks 这行配置容易被想当然地理解成「只要出错就切」，实际上不是所有错误都会触发。LiteLLM 默认只在网络层错误、超时、5xx 这类「服务不可用」的信号上触发 fallback，业务层面的 400（比如请求参数不对、内容审核拒绝）不会被当成 fallback 的理由——不然一个格式错误的请求会被无意义地在自建和 API 之间来回打两遍，白白浪费一次调用额度。
还有一个流式请求的坑：如果你开了 stream=True，一旦本地节点已经开始往客户端吐 token，中途才发现要 fallback，是没法「撤回」已经发出去的内容的。所以流式场景下的健康判断必须卡在首 token（TTFB）之前——网关要在发出第一个 chunk 之前就确认好走哪条路径，一旦开始流式输出，这次请求就只能跟到底，出问题也只能让客户端自己重连重试。
成本测算：混合方案的账怎么算
假设月总 token 量 10 亿，其中：
- 80% 为简单任务（可用自建 7B 处理）
- 20% 为复杂任务（需商业 API）
| 部分 | 月 token 量 | 方案 | 估算成本 |
|---|---|---|---|
| 简单任务 | 8 亿 | 自建 7B（1 张 A10G） | 约 8,000–15,000 元（含人力摊销） |
| 复杂任务 | 2 亿 | 商业 API | 随定价波动，参考各厂商公开价格 |
相比全量使用商业旗舰 API 或全量自建旗舰模型，混合方案通常可降低总成本 30–60%，具体取决于任务分布和流量稳定性。
上面的成本测算只算了 token 总量，没算并发能力，实际选型时这个更关键。一张 A10G（24GB 显存）跑 7B 模型，用 vLLM 的连续批处理，大概能稳定支撑 20–30 并发、单请求平均延迟控制在 1–2 秒内；再往上加并发，延迟会明显劣化，与其硬扛不如加机器。
| GPU 型号 | 显存 | 适合模型规模 | 参考并发上限 |
|---|---|---|---|
| A10G | 24GB | 7B–8B | 20–30 |
| A100 40GB | 40GB | 13B–14B | 30–40 |
| A100 80GB | 80GB | 32B（量化后） | 20–30 |
按你的实际日均 QPS 反推需要几张卡，比先囤卡再算 token 量靠谱得多——很多团队一开始按「总量便宜」买了一堆卡，结果并发能力不够，高峰照样得溢出到 API，钱花了两份。
混合方案的注意事项
- API 兼容性：自建推理服务必须兼容 OpenAI API 协议，否则路由切换时需要适配层
- 延迟一致性：自建和 API 的延迟特性不同，混合后需测试 P95/P99 延迟分布
- 计费追踪：混合方案下成本分散，需要统一的 token 计量和账单系统
- 密钥管理：自建和多家 API 的密钥需要统一管理，避免泄露风险
- 重试风暴：如果自建节点和 API 同时触发限流或过载，网关的重试逻辑如果没有加随机退避（jitter），所有失败请求会在同一秒集中重试，反而把刚恢复的节点或者 API 配额再次打满，形成雪崩。建议重试间隔用指数退避加随机抖动（比如 1s、2s、4s 各加 0–500ms 随机值），并且给每个 backend 设置独立的熔断阈值，避免一个节点的问题传导到整个链路。
常见问题
什么时候该从纯 API 过渡到混合方案？
当月 API 账单超过自建一张 GPU 的月总成本（含人力），且业务负载相对稳定，可以开始评估混合方案。建议先用 API 验证业务，再引入自建降低边际成本。
混合路由对业务代码有影响吗？
通过 API Gateway（如 LiteLLM）统一入口，业务代码只需对接 Gateway 的 OpenAI 兼容接口，路由逻辑对业务完全透明，切换 backend 不需要改业务代码。
自建节点宕机时，自动切到 API 的延迟有多高？
取决于 Gateway 的健康检查间隔和重试策略。LiteLLM 默认健康检查间隔 60 秒，可调整到 10 秒以内。Failover 触发后第一个请求可能有额外延迟（重试时延），之后恢复正常。
本地模型和 API 模型的输出风格不一致，用户能感知到吗？
能。同一个问题让 7B 模型和 GPT-4 级模型回答，措辞详略、格式习惯都会有差异，敏感的用户确实会注意到「这次回复怎么不一样」。如果你的产品对一致性要求高（比如客服话术），建议在 system prompt 里统一约束输出格式和语气，减少两边模型的风格差异，而不是指望模型本身长得一样。
混合方案怎么做灰度切流，而不是一刀切上线？
先按流量比例小范围切，比如 5% 的请求走自建，观察一周的错误率和延迟分布，确认稳定之后再逐步加到 20%、50%，直到你对自建节点的容量和故障率有把握再全量。不要在没有实际流量数据的情况下直接把所有基线流量都切过去，自建节点的真实表现和压测环境往往有差距。
延伸阅读：
- 成本测算框架：自建推理成本测算指南
- 自托管 vs API 详细对比：微调自托管 vs 用 API：怎么选？
- 算力专题 Hub：算力专题
- 直接用托管 API 省去运维？加入候补，体验接入即用服务