在 AIGC 应用、Codex 类代码助手和 Agent 系统中，一次请求返回 HTTP 200，并不代表任务已经完成。响应可能缺少结束事件，工具参数可能不是合法 JSON，图片地址可能无法读取，长文本可能被静默截断，Failover 后甚至可能返回一段语法正确但不符合业务约束的内容。若监控只统计状态码，仪表盘会显示"接口可用"，用户看到的却是空白回答、残缺代码或无法继续执行的工作流。
因此，本文不再把首包延迟（TTFT）或原始成功率当作唯一答案，而是引入"有效交付率"：请求先通过 HTTP 传输层，再通过协议契约层，最后通过任务验收层，三关全部通过才记为一次有效交付。评测对象覆盖供应方直连、LiteLLM、One-API、New-API 等开源项目以及统一中继；测试内容覆盖文本、长上下文、Codex 代码任务、视觉生成、429 Rate Limit、自动 Failover 和 Token 路由算法。
需要先划清数据边界。文中的策略表来自固定随机种子的本地故障注入回放，用来比较路由机制，不代表任何模型厂商或中继服务的真实性能。DeepSeek-V3/R1、Claude 3.5 Sonnet、GPT-4o/Codex API、Qwen2.5-Coder、Flux API 等名称仅作为历史或控制台路由别名，不暗示它们在 2026 年仍保持固定版本、区域、价格和能力。真实选型必须用团队自己的账号配额、网络地域、请求集和账单复测。
一、从状态码可用到有效交付：重新定义 API Gateway 的评测边界
LLM Gateway 位于应用与模型端点之间，负责鉴权隔离、模型别名解析、协议转换、并发整形、Token 预算、路由、重试、Failover、审计和费用归因。它与普通反向代理的差别，不在于能否转发一个 POST 请求，而在于是否理解"大模型请求完成"的业务语义。对普通 REST 接口，收到完整 JSON 往往可以结束；对流式 AIGC 接口，网关还要判断 SSE 是否正常收尾、工具调用是否闭合、输出是否满足模式约束。
本文把一次交付拆成三个门槛：
| 层级 | 通过条件 | 常见假阳性 | 应记录的证据 |
|---|---|---|---|
| 传输层 | 建连成功、状态码可接受、流未异常断开 | 200 后立即断流 |
状态码、响应头、字节数、结束原因 |
| 契约层 | 事件顺序、字段类型、调用 ID、JSON Schema 均合法 | 文本存在但工具参数损坏 | 事件类型、Schema 版本、解析错误码 |
| 验收层 | 输出满足任务约束，可被下游消费 | 答非所问、代码不可编译、图片不可取 | 验收规则、测试结果、失败分类 |
令总请求数为 (N)，通过三层的请求数分别为 (N_h)、(N_c)、(N_v)，则：
R_{http}=\\frac{N_h}{N},\\quad R_{contract}=\\frac{N_c}{N},\\quad R_{verified}=\\frac{N_v}{N}
有效交付率 (R_{verified}) 必然不高于前两项。三个数之间的差值比单独的成功率更有诊断价值：HTTP 成功率 - 契约通过率 反映协议转换、断流和解析损失；契约通过率 - 有效交付率 反映模型输出与业务验收之间的差距。如果只看第一项，网关可能把协议故障和质量故障全部藏在绿色指标之后。
有效交付还应与成本绑定。设本批请求实际产生费用为 (C)，则"每个有效任务成本"为 (C/N_v)，而不是 (C/N_h)。失败请求、重复重试和不可用输出同样可能产生 Token 费用。最低单价路由若让大量任务返工，其有效成本可能反而更高。这个指标不是要用自动打分取代人工判断，而是要求财务、运维和业务使用同一分母。
网关的 Trace 至少要贯穿 request_id、attempt_id、route_id、policy_version 和 schema_version。同一逻辑请求发生重试时，request_id 不变、attempt_id 递增；切换上游时同时记录旧路由、触发原因和新路由。日志只保存密钥指纹和必要元数据，不记录完整 Bearer Token、原始私密 Prompt 或工具敏感参数。没有这条证据链，团队无法分清失败来自客户端、网关、供应方还是业务验收器。
协议兼容也不能用"路径相似"定义。一个端点接受 /v1/chat/completions，不等于它支持流式工具调用、图片输入、结构化输出和所有结束原因。合理做法是建立能力清单和契约测试，让每条路由明确声明支持的 API 族、内容部件、上下文上限、流式事件和重试语义。API Gateway 只把请求送往已证明兼容的路由，未知能力默认拒绝，而不是靠线上请求碰运气。
二、混合并发回放：TTFT、TPS 与有效交付率为何给出不同答案
真实压测必须固定请求集、地域、连接复用、账号等级和采集窗口，否则"模型差异"很可能只是网络或配额差异。本文不伪造供应商实测成绩，而是建立一个可复现的策略回放：固定随机种子 20260807，生成 2,000 个逻辑请求，工作负载包含短对话 40%、代码任务 30%、长上下文 20% 和图片任务 10%。四条虚拟路由分别侧重低延迟、低价格、长上下文和多模态，且各自具有独立的 HTTP 错误率、契约错误率与质量失败率。
在第 850 至 1,049 个请求之间，回放额外向低延迟文本路由注入 12% 的传输错误，用于观察策略能否识别局部故障。所有延迟、价格和错误参数都是合成值；它们的作用是让四种策略面对同一序列，而不是影射某个真实平台。
| 回放项 | 参数 | 评测目的 |
|---|---|---|
| 总请求数 | 2,000 | 降低少量随机事件对比例的影响 |
| 负载结构 | 40/30/20/10 | 覆盖文本、代码、长文与图片 |
| 故障窗口 | 200 个请求 | 验证动态降权与故障隔离 |
| 候选策略 | 4 种 | 对比轮询、价格、延迟和契约 SLO |
| 最大尝试 | 契约策略 2 次，其余 1 次 | 控制重试放大 |
固定种子回放结果如下：
| 策略 | HTTP 成功率 | 契约通过率 | 有效交付率 | 延迟 P95 | 不支持路由 | Failover 次数 | 每个有效任务合成成本 |
|---|---|---|---|---|---|---|---|
| 轮询 | 69.35% | 68.45% | 64.15% | 1242 ms | 28.90% | 0 | 0.0024 |
| 最低价格 | 68.95% | 66.80% | 60.85% | 1370 ms | 30.05% | 0 | 0.0009 |
| 延迟优先 | 66.05% | 65.45% | 62.45% | 762 ms | 30.90% | 0 | 0.0020 |
| 契约 SLO | 99.10% | 96.45% | 89.10% | 1331 ms | 0 | 21 | 0.0039 |
这张表不能被读成"契约策略全面胜出"。延迟优先的 P95 最低，最低价格的合成成本最低；契约 SLO 以更高成本和更长尾延迟换取了更高的有效交付率。正确结论是：先明确业务目标，再决定权重。交互式代码补全可能愿意牺牲少量成功率来换取低 TTFT；财务批处理可以排队，却要求输出可审计；图片工作流则必须先过滤不支持视觉输入的路由。
TTFT 只测从发送请求到第一个有效内容事件的时间，不能在收到注释、心跳包或角色字段时停止计时。TPS 应在开始生成后按实际输出 Token 计算，同时保留 Tokenizer 版本。若网关把上游响应完整缓存后一次性返回，表面 TPS 会异常高，但用户等待首屏的时间更长。压测客户端必须消费到结束事件，校验事件序列后再结束连接，否则中途断流会被误记为成功。
真实环境建议采用阶梯并发：1、4、16、32、64 逐步升压，每档持续到 P95、队列深度和 429 比例稳定。除 TTFT、TPS 外，同时采集端到端时延、排队时间、活动连接数、断流率、契约通过率、有效交付率和每个有效任务成本。只有性能曲线、错误分类与资源曲线放在一起，才能判断瓶颈位于模型、网络、网关连接池还是本地验收器。
三、异构鉴权与 Codex 长上下文：把可解析代码当成交付门槛
Codex 类代码任务对 API 基础设施提出了比短对话更严格的要求。输入可能包含多个文件、补丁、诊断日志和工具定义；输出既可能是自然语言，也可能是函数调用、结构化补丁或长时间 SSE。一次静默截断不会总是触发 500，却可能让补丁少一个括号、让工具调用缺少参数，最终在执行阶段才暴露问题。
鉴权层应把客户端身份和上游密钥彻底分离。客户端凭证只用于访问网关，上游凭证由密钥管理系统按路由注入。路由转换时应验证 Authorization 恰有一个 Bearer 前缀，禁止把内部 Token 透传给错误域名。日志仅记录密钥版本、短指纹、目标主机和响应请求 ID。对于 401、403，通常不应盲目 Failover，因为错误可能来自统一配置；只有确认某个渠道密钥独立失效时，切换才有意义。
长上下文请求应在入队前完成预算检查。网关不能只计算输入文本长度，还要计入系统提示、工具 Schema、图片占位、历史消息和预留输出。设上下文上限为 (L)，估算输入为 (I)，预留输出为 (O)，安全余量为 (M)，只有 I + O + M <= L 才可进入该路由。若模型别名背后的实际上限改变，能力目录应先更新并重新执行契约测试，而不是等线上返回 context_length_exceeded。
对代码输出，验收器可以分层运行：先判断流是否完整、代码围栏是否闭合，再解析补丁或 AST，随后进行格式化、静态检查和受限单元测试。并非每个请求都要执行完整测试套件，但关键仓库至少应对候选补丁运行与变更范围相关的快速测试。模型说"已修复"不是验收证据，git apply --check、编译器结果和测试报告才是。
下面的 Python 示例演示一个最小契约验收器。它不评价答案是否聪明，只验证事件完整、结束原因存在、工具参数可解析，并调用业务侧检查函数：
python
from __future__ import annotations
import json
from dataclasses import dataclass
from typing import Callable
@dataclass
class StreamResult:
text: str
finish_reason: str | None
tool_arguments: list[str]
saw_done: bool
def verify_delivery(
result: StreamResult,
business_check: Callable[[str], bool],
) -> tuple[bool, str]:
if not result.saw_done:
return False, "missing_terminal_event"
if result.finish_reason not in {"stop", "tool_calls"}:
return False, "unexpected_finish_reason"
for raw_arguments in result.tool_arguments:
try:
value = json.loads(raw_arguments)
except json.JSONDecodeError:
return False, "invalid_tool_json"
if not isinstance(value, dict):
return False, "tool_arguments_not_object"
if not business_check(result.text):
return False, "business_acceptance_failed"
return True, "verified"生产实现还要处理增量工具参数：多个 SSE 片段必须按 choice index + tool call index + call id 拼接，不能按到达顺序混成一串。调用 ID 在助手消息、工具结果和后续请求之间必须保持一致。网关若在 Failover 时更换 API 协议族，需要明确映射调用 ID、结束原因和消息角色；无法无损映射时，应终止并返回可诊断错误，而不是伪造兼容响应。
超时也要拆分为连接超时、首包超时、事件空闲超时和总截止时间。代码生成可能首包正常但中途停滞，如果只设置首包超时，连接会无限占用；如果只设置很短的总超时，长回答又会被误杀。客户端应把剩余截止时间随每次尝试递减，Failover 不得重置为完整预算。否则一次用户请求会在多个渠道串行等待，造成队列堆积和重复扣费。
长文本稳定性报告应至少包含完成率、静默截断率、无效补丁率、编译通过率、工具调用闭合率和 P95 输出长度。这样才能分清"模型生成较慢"和"中继破坏了交付契约"。对于 DeepSeek、Claude、GPT-4o/Codex API 或 Qwen2.5-Coder 等路由别名，应报告测试时实际解析到的供应方、模型 ID 和能力快照，避免别名漂移让历史数据失去意义。
四、多模态混合调度：先匹配能力契约，再比较速度与价格
多模态不是在文本请求中多塞一个图片地址。Chat Completions 风格的 image_url、Responses 风格的 input_image、图像生成任务的尺寸与种子、语音接口的采样率和输出容器，分别属于不同契约。API Gateway 若只按模型名称选路，不检查端点族和内容部件，最常见结果就是请求获得 400；更隐蔽的情况是图片字段被忽略，模型只根据文本作答，状态码仍然是 200。
因此，每条路由都应带机器可读的能力清单，而不是维护一张散落在文档中的表。下面是一份简化示例：
json
{
"route_id": "vision-primary",
"api_families": ["chat_completions"],
"input_parts": ["text", "image_url"],
"streaming": true,
"tool_calls": false,
"structured_output": false,
"max_context_tokens": 32768,
"output_media": ["text"],
"contract_suite": "vision-chat-v3"
}请求进入网关后，先从 Body 推导需求向量，例如 chat_completions + image_url + stream，再与能力清单求交集。没有候选路由时立即返回明确的 unsupported_capability，不要把它送到便宜文本路由后再把上游 400 包装成通用错误。回放中轮询、最低价格和延迟优先策略出现约 29% 至 31% 的不支持路由，正是因为它们忽略了任务类型；契约策略在选路前过滤能力，因此该项为零。
契约测试要使用小而稳定的夹具。视觉输入可准备带确定文字与几何关系的测试图，验证模型是否真正读取图像；图片生成可检查 MIME、尺寸、字节数、可解码性和任务状态迁移；TTS 可检查采样率、声道、时长和容器头；工具调用则验证 JSON Schema 与调用 ID。夹具不应包含人脸、机密数据或不稳定的外链资源，最好存入受控对象存储并记录哈希。
多模态输入还涉及资源生命周期。若客户端传 Base64，网关需要限制解码后大小，不能只看请求体字符数；若使用对象地址，应校验允许的协议、域名、重定向次数、Content-Type 和下载上限，防止服务端请求伪造。临时地址的有效期必须覆盖排队、重试和供应方拉取时间。日志记录资源哈希与大小即可，不应长期保存原图。
图片与语音任务常采用异步提交和轮询，不适合沿用文本 SSE 的成功定义。提交成功只说明任务被接受，最终交付还要经过 queued -> running -> succeeded 状态链、结果资源可读取和媒体验收。轮询端应识别永久失败与可重试失败，使用带抖动的退避，并设置总截止时间。若网关在超时后创建第二个任务，必须依靠幂等键避免后台同时生成两份计费结果。
对于 MJ/Flux 图片 API 一类控制台别名，评测应记录参数是否被原样保留：宽高比、种子、参考图权重、安全策略和输出格式都可能因协议转换而丢失。不能只凭"拿到一张图"判定兼容。更合理的指标包括参数保真率、任务完成率、资源可读率、重复任务率以及每个验收通过资产的成本。
多模态 Failover 也比文本复杂。不同路由对提示词、尺寸、种子和安全边界的解释可能不同，切换后结果不一定具有等价语义。团队应给能力设置兼容等级：exact 表示可无损切换，degraded 表示需要转换且必须通知调用方，none 表示禁止自动切换。涉及品牌素材、固定角色或精确构图时，宁可返回可诊断失败，也不要静默换到不可复现的端点。
五、故障注入与动态降权：Failover 的目标是隔离失败而非增加重试
429 Rate Limit、连接超时、500、无效 JSON 和质量验收失败不能用同一重试规则处理。429 往往说明当前配额窗口或并发槽已满；连接前失败通常未产生推理；SSE 中途断流可能已经计费并向用户输出部分内容；工具调用完成后再重试，则可能重复执行外部动作。Failover 的第一步不是"换渠道再来一次"，而是判断请求是否幂等、是否已有可见副作用，以及剩余时间和成本预算是否允许。
可以把路由健康度拆为短窗和长窗。短窗用指数移动平均捕捉突发 429、超时与契约错误，长窗用于判断容量基线。路由分数可表示为：
S_r=w_lL_r+w_pP_r+w_eE_r+w_cC_r+w_qQ_r
其中 (L_r) 是归一化延迟，(P_r) 是价格，(E_r) 是传输错误，(C_r) 是契约错误，(Q_r) 是质量验收失败。权重由业务 SLO 决定。所谓"综合最佳"只是一个加权策略，不是普适答案；若样本量不足、错误分类错误或健康数据过期，复杂算法同样会做出错误选择。
动态降权需要三个保护机制。第一，熔断器在连续失败或短窗错误率越界后暂停新流量，只允许少量探测请求；第二，半开探测必须使用低风险、低成本夹具，不能直接拿用户长任务试错；第三，恢复要渐进放量，例如 1%、5%、20%、50%，观察契约与验收指标后再回到全量。立即恢复全部流量容易造成故障振荡。
text
请求进入
-> 能力与预算预检
-> 选择同一故障域外的候选路由
-> 第一次尝试
|-- 已验收 --------------------> 返回
|-- 不可重试/有副作用 ---------> 失败并告警
|-- 可重试且预算充足 ----------> 熔断状态检查
|-- 无候选 -> 失败
|-- 有候选 -> 第二次尝试 -> 验收候选路由还要考虑故障域。两个别名若最终使用同一供应方、同一账号、同一区域或同一出口 IP，它们不是独立备份。路由目录应标注 provider、account_pool、region、egress 和 gateway_cluster；Failover 优先选择不同故障域。否则上游账户被限流时，系统会在多个别名间高速空跑，进一步放大 429。
本次回放中，契约 SLO 策略最多尝试两次，共触发 21 次 Failover，有效交付率达到 89.10%；但它的 P95 为 1331 毫秒，合成成本也最高。这说明 Failover 有明确代价。策略应设置 max_attempts、总截止时间、最大附加 Token、最大附加费用和每类错误允许重试次数。任何一项耗尽，都应停止，而不是追求漂亮的成功率。
对流式文本，可在尚未向客户端发送有效内容且上游明确失败时切换；一旦已经输出 Token，再切换模型会造成语义重复或风格突变。可选做法是返回带错误类型的终止事件，让客户端决定是否重新发起。对非幂等工具调用，必须使用业务幂等键和执行状态表，模型重试不能绕过外部系统的去重机制。对异步图片任务，则应优先查询原任务状态，确认不存在或永久失败后再创建新任务。
故障演练不能只关掉一个进程。应分别注入 DNS 失败、TLS 超时、慢首包、SSE 断流、畸形事件、429、500、错误模型别名、能力清单过期和验收器不可用。每种故障都要核对是否准确分类、是否触发正确降权、是否泄漏敏感日志、是否重复计费，以及恢复后权重是否平滑。真正的韧性来自可证明的失败边界，而不是无限重试。
六、LiteLLM、One-API、New-API 与统一中继的可复现实验环境
开源项目与云端中继不应通过功能列表直接决胜。LiteLLM 更接近可编程的 LLM Gateway 与多供应方适配层，适合把路由策略、回调和可观测性纳入代码管理；One-API、New-API 常用于统一渠道、令牌、配额和管理界面；云端统一中继则把一部分部署、渠道维护和可用性责任交给外部服务。三类方案的控制权、运维负担和信任边界不同，必须在同一请求集下测试。
本文实验环境采用三组节点：供应方模拟器用于确定性回放；本地 Docker 节点分别部署 LiteLLM 与 One-API/New-API 类渠道管理组件；云端组接入一个 OpenAI 协议统一中继镜像作为网络对照，测试节点地址为 https://178.nz/yinc。该地址只承担环境标识，不构成性能背书。真实复测应隔离测试密钥与生产密钥，并确认数据处理、日志保留和网络出口符合团队制度。
推荐的最小环境包含负载发生器、网关数据面、Redis、配置数据库、Mock Provider、指标系统和验收器。Mock Provider 按请求头选择正常响应、慢首包、429、畸形 SSE 或中途断流，使每种实现接收完全相同的故障序列。真实端点只用于补充网络与协议验证，不能与模拟结果混成一张供应商排名表。
| 维度 | LiteLLM 类网关 | One-API/New-API 类管理层 | 云端统一中继 |
|---|---|---|---|
| 路由可编程性 | 较强，可将策略纳入代码 | 依赖版本与渠道配置 | 依赖服务公开能力 |
| 渠道与额度管理 | 需结合配置和外围系统 | 通常较集中 | 本地控制较少 |
| 数据与密钥边界 | 团队自行掌控 | 团队自行掌控 | 需评估第三方边界 |
| 升级责任 | 自行测试与发布 | 自行迁移与回滚 | 由服务方承担一部分 |
| 故障可见性 | 可深度埋点 | 取决于日志能力 | 取决于可提供的请求证据 |
| 退出与迁移 | 配置可导出但仍需适配 | 渠道数据需治理 | 必须验证协议与账单可迁移性 |
部署时应把控制面与数据面分离。数据库、管理界面或价格表更新不应阻塞正在转发的 SSE；路由规则通过带版本的只读快照下发，失败时继续使用最近一次有效配置。Redis 可以承担限流计数、短期健康状态和幂等缓存，但不能成为无降级方案的单点。Redis 不可用时，是拒绝新请求、退化为本机限流还是只允许白名单业务，必须预先定义。
对每个实现都执行同一套验收：启动与冷恢复时间、配置发布延迟、滚动升级断流率、密钥轮换、审计完整性、连接池上限、单实例资源、横向扩展效率以及灾难恢复。开源软件"无需许可证费用"不等于零成本，值班、升级、数据库备份、漏洞响应和契约维护都应计入总拥有成本；云端服务"无需自建"也不等于无需治理，仍要验证账单、限流、数据边界和退出方案。
环境结果必须可复现。镜像使用不可变摘要，配置移除密钥后进入版本库，测试请求集和能力清单记录哈希，系统时钟统一，所有节点保存构建版本。每轮测试输出原始事件摘要、策略版本、错误分类和验收报告。不要只保存聚合后的折线图，否则当某个版本的有效交付率下降时，无法回到单个请求定位原因。
七、极端限流治理：阻止 429 Rate Limit 演变为重试风暴
429 不是普通失败，而是容量控制信号。客户端、API Gateway 和上游 SDK 若各自重试三次，一个逻辑请求最坏会膨胀为多次尝试；当大量请求同时退避结束，又会形成同步尖峰。治理的核心是让系统只有一个重试决策者，并让入口速度服从可观测的下游容量。
入口首先要区分 RPS、RPM、并发连接、输入 Token、输出 Token 和账户余额。只按请求数限流会放过少量超长任务，也可能过度限制大量短请求。可以采用分层令牌桶：租户桶控制公平性，业务桶保护关键路径，路由桶匹配上游容量，Token 预算桶限制成本。请求只有同时取得必要配额才进入队列，未取得时返回明确的可重试时间或进入有界等待。
队列必须有长度上限和截止时间。无限队列只是把 429 变成超时和内存压力。交互式 Codex 请求可采用短队列，超过等待预算后快速失败；离线 AIGC 批处理可进入持久队列，但要有任务优先级、租户公平调度和取消能力。排队时间应从总截止时间中扣除，不能出队后重新获得完整超时。
处理 429 时，优先遵循可解析的服务端退避信息；若没有，再使用指数退避加随机抖动。退避上限受用户截止时间约束，并且同一故障域共享冷却状态。不能让每个进程独立认为自己只发少量探测，集群合计却持续压垮上游。对于明确的日配额耗尽，短暂重试没有意义，应直接熔断该账户池并告警。
频控还应与 Token 预留结合。请求入队时按输入估算和最大输出预留预算，完成后按实际消耗结算并释放差额。若上游没有返回用量，账务状态应标记为"待对账"，不能默认为零。Failover 发生时，每次尝试单独记账，再归并到逻辑请求，才能识别重复消费、Token 滥扣和不可交付输出的真实成本。
常见错误之一是对所有 5xx 和超时立即重试。慢首包可能仍在上游执行，客户端超时并不代表推理已取消。网关应尽可能向上游传播取消信号，同时把结果分为"确认未执行""执行状态未知""确认失败"。只有第一类可以低风险重试；第二类需要幂等键、状态查询或人工对账；涉及支付、发信、写库等工具调用时，默认禁止自动重放。
限流仪表盘至少显示入口请求率、放行率、队列深度、排队 P95、429 来源、退避次数、熔断状态、Failover 放大量、输入输出 Token 和有效交付率。若只看最终 429 比例，系统可能通过长时间排队把错误隐藏起来。容量评审应以 SLO 为准：在目标并发下，多少任务在截止时间内通过业务验收，而不是网关一秒能接收多少连接。
上线前可做逐级故障注入：先将一条路由容量降至 80%，再降至 50%，最后完全拒绝；观察队列是否有界、低优先级是否先被整形、关键业务是否保持预算、恢复时是否出现瞬时洪峰。任何策略变更都要设置最大重试放大系数，例如所有尝试数除以逻辑请求数不得超过预设阈值。超过阈值时，应自动关闭次要重试而非继续扩大压力。
八、团队规模与责任边界：选型首先是运维能力问题
同一套 API 基础设施不会适合所有团队。个人项目和小型团队通常缺少全天候值班，自建复杂控制面可能让维护成本高于调用成本；中型团队开始需要租户隔离、成本归因和灰度发布；大型企业还要处理跨地域、审计、数据驻留、灾难恢复和供应商退出。判断依据不是开发人数本身，而是业务损失、合规边界和能承担的运维责任。
| 团队形态 | 首要目标 | 合理起点 | 必备控制 | 何时升级 |
|---|---|---|---|---|
| 个人或验证团队 | 快速验证、限制预算 | 直连或薄网关 | 密钥隔离、硬预算、基本日志 | 出现多模型与稳定性要求 |
| 5--20 人产品团队 | 统一接入、减少适配 | 托管中继或单集群开源网关 | 限流、能力清单、请求追踪 | 需要多租户和专职值班 |
| 中型 IT 团队 | 成本归因、灰度和容灾 | 自建数据面配合备份路由 | SLO、熔断、配置版本、演练 | 跨区域或合规要求提高 |
| 企业级 Agent 平台 | 隔离、审计、可退出 | 多集群混合架构 | 全链路审计、故障域、灾备 | 持续按风险复评而非一次升级 |
小团队应避免一开始就搭建包含多数据库、复杂评分器和跨区集群的系统。最低可行治理可以只有统一入口、环境变量密钥、模型别名、请求预算、结构化日志和一个备用路由。等真实指标证明存在 429、协议漂移或费用归因问题，再增加队列、Redis、动态降权和验收器。复杂度必须对应已观察到的风险。
中型团队选择 LiteLLM、One-API、New-API 等开源项目时，需要明确代码所有者和运行所有者。前者负责适配器、契约测试与版本评审，后者负责容量、告警、备份和故障演练。如果"人人都能改配置，但没人对 SLO 负责"，开源的可控性会变成配置漂移。路由和价格变更应走评审、灰度、回滚流程，并带可检索的策略版本。
企业级系统不应把所有模型流量放在单一账号池或单一区域。数据面可以按业务敏感度和地域拆分，控制面发布经过签名的策略快照。关键业务拥有独立预算与故障域，实验流量不能耗尽生产配额。对于外部中继，要审查数据处理条款、日志保留、密钥托管、子处理方、事件通报和退出导出；对于自建开源项目，则要承担补丁、依赖漏洞和供应链审计。
选型会议应同时有应用开发、IT 运维、安全、财务和业务负责人。开发关注协议和 SDK，运维关注 SLO 与恢复，安全关注密钥和数据流，财务关注有效任务成本，业务负责定义"什么算交付"。缺少业务验收定义时，有效交付率无法计算；缺少运维容量数据时，再精细的 Token 路由算法也没有可信输入。
最终要算总拥有成本。自建成本包括计算、存储、监控、数据库、值班、升级、演练和安全响应；托管成本包括调用加价、网络、审计接入、供应商管理和退出改造。成本表应使用"每个有效任务"而不是"每百万 Token 单价"统一比较，因为后者无法反映重试、错误输出和人工返工。
九、按业务契约配置路由：代码、图像、批处理与 Agent 不应共用模板
AI 辅助编程最重视交互 TTFT、长上下文稳定性、工具调用完整性和代码验收。路由可先按仓库语言、上下文长度和工具需求过滤，再在兼容候选中选择低延迟端点。短补全的总截止时间应更紧，失败后快速让用户重试；大型重构可以进入任务模式，允许更长队列并运行编译与测试。不要让代码补全与离线文档生成争夺同一并发池。
代码场景的替代方案不是无限添加模型，而是缩小请求：本地索引先检索相关文件，只发送必要上下文；用语法树或补丁格式约束输出；对简单格式化与静态替换优先使用确定性工具。这样既降低 Token，又减少长上下文截断。涉及写文件、执行命令或提交代码的 Agent，每一步都要保留工具调用 ID、幂等键和审批边界，Failover 不能跳过已有执行状态。
AI 绘画与漫剧工作流更关注多模态参数保真、角色一致性、任务状态和资产可访问性。文本理解、分镜生成、图片生成、放大、局部编辑和配音应拆成不同队列与能力标签。Flux API 或其他图像别名只接收通过其参数契约的任务；不兼容尺寸或参考图语义时显式降级。结果验收包括媒体解码、分辨率、内容策略、资产哈希和人工抽检，而不是只看任务状态为成功。
图片任务耗时长且费用相对集中，必须使用持久任务 ID。客户端断开不等于取消生成，重连后应查询原任务。若业务要求可复现，保存模型解析 ID、参数、种子、输入资产哈希和变换链；如果上游不保证确定性，界面与审计记录也要如实标注。备用路由只有在参数语义等价时自动切换，否则交给编排层重新规划。
批量文本生成重视吞吐、成本和格式通过率，通常不需要最低 TTFT。可以按租户和截止时间进入持久队列，利用低峰容量，批次内设置固定 Schema 与验收器。最低价格策略只有在契约通过率接近时才有意义；若便宜路由产生更多无效 JSON，重试与清洗会吞掉价差。批处理还应支持断点续跑，以逻辑任务 ID 去重，不能在进程重启后整批重发。
面向客服或知识库的 RAG 应把检索与生成分别观测。回答不合格可能来自召回为空、引用错位、提示模板或模型输出，不能全部归因于 API。验收可检查引用标识、答案是否有证据覆盖、禁止字段是否出现，并对高风险回答转人工。路由策略不应因为某个模型"通常更强"就忽略数据地域、上下文长度和结构化引用契约。
Agent 工作流最需要控制副作用。模型调用、工具执行和状态写入应形成状态机，每个步骤都有输入哈希、调用 ID、执行结果和补偿动作。模型超时后先查询工具是否执行，再决定重试。对于不可逆操作，自动 Failover 只能发生在工具执行之前；执行之后的恢复由业务工作流负责，而不是由通用 API Gateway 猜测。
可以为每类业务建立独立策略模板：interactive-code 权重偏向 TTFT 与工具完整性，media-job 偏向能力等价和任务可恢复，batch-json 偏向格式通过率与有效成本，agent-critical 偏向幂等和审计。模板只提供默认权重，最终仍由观测数据校正。把所有请求放进一个"综合最佳"策略，会把不同业务的风险平均掉，最终谁都得不到真正需要的保障。
十、综合性价比与最终结论：用可验证交付选择基础设施
最终选型不应先问"哪个网关最快"，而应先问业务能接受什么失败。本文建议把评估分成六项：协议契约与多模态能力 20%、有效交付与故障隔离 25%、性能与容量 15%、安全审计 15%、运维可控性 15%、有效任务成本 10%。权重只是通用起点；离线低风险任务可以提高成本权重，执行外部动作的 Agent 则应提高契约、安全和审计权重。
| 候选架构 | 契约控制 | 故障隔离 | 运维负担 | 数据边界 | 适合的前提 | 主要退出风险 |
|---|---|---|---|---|---|---|
| 供应方直连 | 客户端分别实现 | 依赖应用侧 | 低到中 | 链路最短 | 模型少、团队小 | 多供应方适配分散 |
| LiteLLM 类自建网关 | 可深度定制 | 取决于部署设计 | 中到高 | 自主管理 | 有平台工程能力 | 版本与策略维护 |
| One-API/New-API 类管理层 | 渠道治理集中 | 取决于实例与账号池 | 中 | 自主管理 | 重视令牌和额度管理 | 配置与数据迁移 |
| 云端统一中继 | 取决于公开契约 | 需验证故障域 | 低到中 | 引入第三方 | 接入速度优先 | 可观测性与供应商锁定 |
| 混合架构 | 可按业务分层 | 可建立独立备份 | 高 | 可分级处理 | 关键业务且有运维团队 | 双体系语义漂移 |
打分前先设置淘汰项。无法隔离密钥、无法提供请求级证据、关键多模态契约不兼容、没有明确数据边界或无法导出配置的方案，即使价格和延迟得分很高，也不应进入关键生产路径。通过淘汰项后，再使用团队自己的回放数据归一化打分。分数旁必须保留原始指标和置信区间，避免一个总分掩盖短板。
验收门槛可以写成可执行 SLO：在指定请求集和并发下，有效交付率不低于目标值；TTFT P95、排队 P95 和总时延不超过各自预算；不支持能力的请求不得进入上游；重试放大系数、重复工具执行和未知计费请求低于阈值；单路由故障时，关键业务在规定时间内恢复。SLO 要按业务模板分别计算，不能用低风险批处理的高成功率稀释关键 Agent 的失败。
上线流程应遵循"契约测试、故障注入、影子回放、小流量灰度、分阶段扩容"。每次模型别名、网关版本、能力清单或 Token 路由算法变化都触发回归。生产中持续比较 HTTP 成功率、契约通过率和有效交付率：第一段差距扩大时排查协议和流式链路，第二段差距扩大时排查模型输出、提示和业务验收，三者同时下降时再检查容量与上游故障。
回到本文的回放结果，延迟优先在交互速度上有优势，最低价格控制了单次合成费用，契约 SLO 则显著减少了能力错配并提高有效交付，但支付了延迟与成本代价。没有一种策略天然"综合最佳"。真正可靠的 Token 路由算法，是先用能力契约排除错误候选，再在独立故障域内依据业务 SLO 选路，并用有界 Failover 控制失败扩散。
对资源有限的团队，合理起点是薄网关、明确预算、结构化日志和少量经过验证的备用路由；对已有平台工程能力的 IT 团队，可以自建开源项目并逐步加入能力清单、契约测试、动态降权和业务验收；对关键企业系统，混合架构只有在故障域、审计、灾备与退出路径均经过演练后才有价值。架构复杂度不是成熟度，能够解释每一次失败、限制每一次重试并验证每一次交付，才是生产级 AIGC API 基础设施的核心标准。
最终结论可以压缩为一句话：HTTP 200 只证明链路返回过内容，不能证明用户拿到了可用结果。把评测单位从"成功请求"改成"已验证任务"，会同时改变路由、监控、成本和团队责任的设计，也能让 LiteLLM、One-API、New-API、直连与统一中继回到同一套客观尺度上比较。