我是小兵，一个动手派AI架构师。「AI工程化实战」系列第 5 篇。

值班同学切了指针，等了十分钟，曲线没下来

上篇《把 Prompt 当代码管起来》结尾预告的《LLM 网关选型》，就是这篇。

registry 上线第二周，转人工率又爬回来了。这次不是回滚错版本——是回滚了也没用：值班同学把版本指针切回旧版，等了十分钟，曲线没下来。

查日志才看清：线上压根没人按版本 ID 路由。三个服务直连 LLM API，各自写各自的重试，key 散在三个环境变量里，只有一处接了 registry 的 get()。

上篇我们说「registry 管资产，网关管路由」——资产是管住了，可路由这个决策点，线上根本没有地方落地。

这篇就回答一个问题：什么规模，选什么网关，才能让「按版本 ID 路由 Prompt」落地。结论先放这儿：registry 管的是资产，网关管的是路由，决策必须收敛到一处——不然上篇造的资产，线上用不起来。

直连 LLM API 的三连错

不接网关、直连 API，错法很固定，三条：

• key 散落无审计。三个服务三个环境变量，谁调的、哪个 key、花了多少，全无记录。
• 每个服务各写重试。各写各的 while 循环，主厂商一限流，所有服务同时重试——放大故障，账单和错误一起涨。
• 版本路由没落点。registry 切了指针，调用方不认版本 ID——上篇的资产被架空。

三连错病在同一个地方：把 LLM 调用当成每个服务自己的事。网关不是「多一层代理」，是运行时韧性的统一入口——路由、fallback、重试、限流、成本、安全、Trace，这七件事必须在同一个入口做。网关的意义不是多一层延迟，是「这些决策从此只在一处改」。

独家硬指标：按版本 ID 路由 Prompt

先分清一个容易混的点：选型表里的「路由」是模型路由（走哪个模型），这里说的路由，是按版本 ID 路由 Prompt（走哪一版 Prompt），两件事。

上篇把「线上跑哪版」管成「一个版本指针」，网关就是那个认指针的入口。指针切了，网关下一请求就取到新指针指向的 Prompt——这才是回滚生效。自研网关直接调 registry.get()，一行的事；商业/开源网关要逐项核对：支持从你自己的 registry 拉取 Prompt 吗？请求头能带版本 ID 吗？

先泼盆冷水：硬指标按你的 Prompt 是不是业务逻辑来定。客服话术、抽取指令这类业务逻辑，必须按版本路由，是条否决项；纯配置（换语气词）的团队，这条自动降级，别为它买单。下面的方案判断，都站在「你要版本路由」的立场。

什么规模选什么：三档

选型不是参数罗列，是「你的规模需要哪几项能力、哪些必须自研」。

• 第一档，小团队/快速验证（<10 并发）：轻量代理起步（One API / LiteLLM），先收拢 key。目标不是全能力，是把 key 收拢到一个统一入口。
• 第二档，中规模生产（几十~几百 QPS）：开源网关（LiteLLM / Portkey 开源版）+ 外层自包一层版本路由。网关本身开源可用，硬指标靠外层补齐。
• 第三档，规模化/强合规（政企/高并发）：自研决策骨架，或 Kong AI Gateway。私有化优先，能力要能审计、要能自定义。

拿不准就先问三个问题，把方案范围圈小：数据出不出得去？Prompt 要不要按版本路由？团队养不养得起自研运维？

一段最短代码：决策与 I/O 分离

自研网关的骨架我写了一版，纯标准库、无第三方依赖、无任何 API 密钥，离线就能跑。核心就一个心智——决策与 I/O 分离：路由、fallback、重试、限流全是不碰外部 I/O 的决策逻辑，唯一碰外部世界的点是 Provider.complete()，藏在可 mock 接口后。生产里把 MockProvider 换成真实 SDK，决策逻辑一行不改。

class Provider:  # 所有厂商实现同一个接口——业务只认 complete()，换模型不换代码    def complete(self, prompt):        raise NotImplementedError def resolve_prompt(registry, name, version_id=None):  # 按版本 ID 从 registry 取 Prompt（本专栏硬指标的落点）  # 找不到版本就抛异常，上层拒绝路由，绝不拿”最新的”糊弄过去    return registry.get(name, version_id) # 决策与 I/O 分离：路由/fallback/重试/限流全是不碰外部 I/O 的纯函数，# 唯一碰外部世界的点是 Provider.complete()，藏在可 mock 接口后——# 生产里把 MockProvider 换成真实 SDK，决策逻辑一行不改

这段代码里，硬指标长这样：resolve_prompt 找不到版本，就拒绝路由。把「按版本 ID 路由」改成「取不到就返回最新版」，5 个断言里第一个当场挂。完整可跑的骨架（含 fallback、决定式重试、按租户限流、5 个断言）见 CSDN 原文。

两个付过费的坑

坑一：fallback 粒度过粗。第一版网关 fallback 链只有一条全局配置（claude → gpt4 → llama）。某天下午 4 点 claude 崩了，全网关所有场景同时涌向 gpt4，gpt4 被干爆，P99 从 300ms 爬到 3s——比 claude 挂了还难受。修复：每场景一条链，链从路由表读、配置驱动，换链不换代码。

坑二：网关吞错误。网关 catch 所有异常，统一返回「系统繁忙」。某次线上事故排查，下游团队问「是模型挂了还是网关挂了」，谁都答不上来——日志里只有四个字，原始错误全丢了。修复：错误透传，status + err_type + 原始 message 一路带到底，下游才能分清是厂商限流（429）还是网关自己挂（5xx）。

六条路线，一句话一条

• 自研：唯一在「按版本 ID 路由 Prompt」上原生达标的路线，代价是运维加五个模块全自己写。适合决策逻辑本身是竞争力的团队。
• LiteLLM：MIT 开源自托管的性价比之选，100+ 厂商，虚拟密钥、成本追踪、自动 fallback 开源版就有。注意：分布式限流依赖 Redis；2026-03 的 PyPI 供应链事件（已修复）提醒我们，自托管要锁已修复版本、别追 latest。硬指标不达标，要版本路由就得外层包一层。
• Portkey：250+ 厂商，语义缓存、guardrails、可观测是亮点，但主打托管、自托管能力有限；2026-05-29 被 Palo Alto Networks 收购，路线图和定价要重新算；生产日志只留 30 天，长期审计别指望它。硬指标「半达标」：有 prompt 版本管理，但语义是平台自己的，不是从你的 registry 拉取，要逐项核对。
• Kong AI Gateway：通用 API 网关 + AI 插件，适合「已有 Kong 或要统一管 API+AI」的团队；3.14（2026-04）新增 Agent Gateway。但高级能力在 Enterprise/Konnect，开源版只有基础路由，硬指标要外层接。
• OpenRouter：聚合模型市场、按 token 计费，适合个人和轻量验证——无护栏、无私有化、数据出得去，当「工具」别当「基础设施」。
• One API / New API：国产自建中转的实惠路线。One API 单二进制/Docker 部署，约 28 家渠道，令牌、额度、负载均衡、自动重试；New API 是它的 AGPL 二开（约 4 万 star），支持多格式互转。注意 2026-04 曾爆支付逻辑漏洞（已修复），自建中转要对版本敏感；硬指标不达标、护栏基本为零。

另有一条 SaaS 支线：想全球化分发、零运维的团队，可以看 Cloudflare AI Gateway——托管、快，但绑 Cloudflare 生态，数据在边缘层过一遍，合规严格的直接排除。

决策树和 8 问 checklist（含「每年能不能拨出 0.5 人月养自研网关」这道运维题）都在 CSDN 完整版里，这里不占篇幅。

三句话总结

能力清单回答「你需要的七项是什么」，三档判断回答「什么规模选什么」，硬指标回答「按版本 ID 路由 Prompt 落在哪个方案」。

回到开头值班同学的十分钟：网关到位之后，指针切回旧版，下一个请求就取到旧 Prompt，转人工率跟着曲线下来——回滚从「切了没人看」变成「切了就生效」。

网关是运行时韧性的统一入口。《OWASP 安全护栏》（输入前置拦截 + 输出后置校验）和《JSON Schema 强约束》（输出结构校验），都要挂在这个入口上——能力清单里的「安全钩子」和「Trace」两行，就是提前留好的挂载点。

这篇是脱水版。完整版约 6500 字，含可离线跑的自研网关决策骨架、5 个测试断言、六条路线对比表、决策树和 8 问 checklist，已同步发布在 CSDN。点文末「阅读原文」看完整代码和推导过程。

评论区聊聊：你们现在直连 LLM API 的代码有几处？有没有和我一样，第一版网关死于「三处裸调、只有一处接 registry」？

我是小兵，一个动手派AI架构师。这里只写自己跑过、摔过、复盘过的AI工程化案例。如果你想持续收到这类实战内容，点击关注，下篇见。