夜雨聆风很多 AI 应用的 demo 都是这样开始的：
业务代码里写一个 prompt，调用一个模型 API，把结果返回给前端。
这条链路很轻。
但只要它进入生产，就会立刻变重。
模型会超时，供应商会限流，Token 成本会失控，输出质量会漂，审计会追问某次回答为什么用了某个模型，安全同学会问 API Key 和敏感日志放在哪里。
这时候你会发现：
大模型网关不是锦上添花，而是 AI 应用进入生产的分水岭。
先想一个很普通的内部 AI 助手。
它一开始只服务研发团队。
大家用它查文档、总结工单、生成周报、解释代码。
第一版很快就能做出来：
前端输入问题。
后端拼 prompt。
调用模型 API。
返回答案。
如果只是演示，这够了。
但上线几周以后，问题会陆续冒出来：
• 客服场景需要便宜模型，法务场景必须走强模型 • 一个供应商偶尔 429，业务线程被拖住 • 用户上传了长文档，一次请求花掉几万 Token • 同样是“生成报告”，有人点了两次，系统生成了两份 • 某个模型夜里延迟变高，前端一直转圈 • 财务问本月大模型账单是谁花的，没人说得清 • 安全问日志里有没有原始用户输入和业务敏感信息，没人敢拍胸口
这时候，问题已经不是“prompt 写得好不好”。
也不是“模型够不够强”。
而是你有没有一层基础设施，把模型调用这件事管起来。
这层东西，就是大模型网关。
一、直连模型 API，适合 demo，不适合生产
很多团队的第一版 AI 功能，都是业务服务直接调用某个模型 SDK。
这很自然。
因为 demo 阶段最重要的是证明一件事：
这个能力有没有价值。
但如果业务代码里到处都是模型调用，后面会越来越难收拾。
比如：
• A 服务直接调 OpenAI • B 服务直接调 Anthropic • C 服务直接调私有化模型 • D 服务自己写了一套重试 • E 服务自己算 Token • F 服务完全没有记录 usage
短期看，每个团队都很灵活。
长期看，所有治理能力都被打散了。
你想换模型，要改很多业务代码。
你想做成本统计，发现每个服务记录字段都不一样。
你想做统一限流，发现请求早就从不同路径打出去了。
你想排查一次线上回答，发现只有最终文本，没有 prompt、模型、上下文、Token、延迟和错误类型。
这就是直连模型 API 的问题。
它让 demo 很快，但也让生产治理失去中心。
大模型网关第一步要解决的，就是把模型调用从业务代码里抽出来：
业务系统不关心具体供应商 SDK。
业务系统只提交一个结构化请求。
网关负责选择模型、调用模型、处理失败、记录成本、留下 trace。
这一步听起来朴素，但很关键。
因为只有模型调用先集中起来，后面的路由、fallback、限流、成本归因、审计和安全才有落点。
二、模型路由不是炫技，而是场景分层
一提多模型路由，很多人会想到很复杂的智能 Router。
用小模型判断任务类型。
用 embedding 匹配模型 profile。
用历史质量数据训练选择器。
这些当然有价值。
但早期更重要的不是智能，而是可解释。
一个生产系统里的模型选择，通常先来自业务场景：
• 意图识别：快模型 • 文本分类：便宜模型 • 普通摘要：平衡模型 • 长文档分析：长上下文模型 • 法务审核：高质量模型 • 代码修复：代码能力强的模型 • 语音实时对话：低延迟模型
这不是算法问题。
这是工程判断。
你要先知道每类任务真正看重什么：
• 成本 • 延迟 • 稳定性 • 上下文长度 • 结构化输出能力 • 工具调用能力 • 安全要求 • 质量下限
然后把这些判断写进路由规则。
比如：
{ "scene": "intent_classification", "selected_model_tier": "tier-fast", "route_reason": "scene_rule:low_risk,cost_priority,estimated_tokens=320"}这段信息比“本次用了某某模型”更重要。
因为它回答了一个生产系统必须能回答的问题：
为什么是这个模型？
如果没有 route_reason，后期根本没法复盘。
用户投诉答案质量差，你不知道是不是路由错了。
账单突然上升，你不知道是不是某个 Prompt 版本导致输出变长。
某个模型延迟升高，你不知道哪些场景受影响。
所以模型路由的起点不是“让系统看起来聪明”。
而是让每次模型选择有理由、有记录、可回放。
三、fallback 不是失败就换模型
很多人把 fallback 理解得太简单：
主模型失败，就切备用模型。
这句话只有一半对。
真正进入生产以后，你必须先区分失败类型。
网络瞬断，可以短重试。
供应商 5xx，可以重试、熔断、切供应商。
429 限流，可以读取 Retry-After，排队或切同级模型。
结构化 JSON 解析失败，可以尝试修复或降级 schema。
但有些错误不应该直接 fallback。
上下文超限，不是换模型重试就能解决，可能要压缩历史消息、减少 RAG 片段、缩小工具 schema，或者切长上下文模型。
参数错误，不应该重复打供应商，应该修请求。
安全拒答，也不应该绕过安全策略去换另一个模型硬答。
高风险业务更要小心。
如果一个法务审核任务原本应该走强模型，主模型不可用时，系统不能静默降到便宜模型，然后照常给出结论。
这会把风险藏起来。
更合理的做法是：
• 标记本次发生降级 • 进入人工复核 • 缩小输出范围 • 或者直接告诉用户稍后重试
fallback 的目标不是“无论如何都给一个答案”。
fallback 的目标是让系统在失败时仍然可控。
这里还有一个非常容易忽略的点：
fallback 必须和幂等绑定。
比如用户点击“生成报告”。
主模型其实已经生成完了，但网关等待响应超时。
如果系统立刻切备用模型再生成一次，最后可能落库两份报告，成本也扣两遍。
所以对高成本生成任务，网关侧最好把最终 LLMResponse 按 tenant_id + idempotency_key 缓存下来。
重复请求进来时，直接返回历史结果。
这不是小优化。
这是 AI 调用链的成本和一致性护栏。
四、LLM 限流不能只看 QPS
传统 API 限流，经常按 QPS。
每秒多少请求。
超过就拒绝。
但大模型调用不能只这么看。
两个请求都是一次调用，成本可能差几十倍。
一个请求输入 500 Token，输出 100 Token。
另一个请求输入 80K Token，输出 8K Token。
它们在 QPS 里都是 1。
但对供应商配额、账单、延迟和系统资源来说，完全不是一个量级。
所以大模型网关要同时看多层预算：
• 用户级：防止单用户刷接口 • 租户级：控制团队或客户预算 • 模型级：防止热门模型被打满 • 供应商级：避免外部依赖拖垮系统 • Token 级：按真实输入输出压力控制成本
更稳的流程是：
先 estimate。
再 reserve。
调用模型。
拿到真实 usage。
最后 reconcile。
也就是：
调用前先估算输入 Token 和保留输出 Token。
用户桶、租户桶、模型桶、供应商桶都扣得动，才把请求发出去。
调用结束后，再用供应商返回的真实 input_tokens、output_tokens 对账修正。
估算不可能完全准。
不同供应商、不同模型的 tokenizer 和 usage 字段也不完全一致。
但粗估也比不估强。
尤其是 RAG、长上下文、Agent 多工具调用这些场景，不做预算很容易失控。
很多团队说要优化大模型成本。
但如果连一次请求到底花了多少 Token、归属哪个租户、哪个场景、哪个 Prompt 版本都不知道，那不是优化。
那是在猜。
五、成本归因和审计，是上线后的生存能力
AI 应用进入生产以后，成本问题会变得非常具体。
不是“模型有点贵”。
而是：
• 哪个租户花得最多 • 哪个用户触发了异常调用 • 哪个场景输出特别长 • 哪个 Prompt 版本让 Token 用量上升 • 哪个模型 fallback 次数最多 • 哪类请求命中缓存最多 • 哪类请求经常从便宜模型升级到强模型
这些问题都需要网关记录。
成本归因不是财务报表才需要。
它会反过来影响系统设计。
如果你发现某个低价值场景长期调用强模型，就应该降级。
如果你发现某个 RAG 场景输入 Token 过高，就应该优化 chunk、rerank 和上下文压缩。
如果你发现某个 Prompt 版本让输出长度翻倍，就应该回滚或重新评测。
审计也是一样。
一次 AI 请求不应该只留下最终答案。
至少要能沿着 request_id 查到：
• 谁发起的请求 • 属于哪个租户 • 是哪个业务场景 • 用了哪个 Prompt 版本 • 注入了哪些上下文摘要 • 选择了哪个模型 • 为什么选择它 • 有没有 fallback • 输入输出 Token 是多少 • 延迟和 TTFT 是多少 • 错误类型是什么
注意，我说的是上下文摘要。
不是把所有原始用户输入、业务数据、检索片段、工具结果都明文存下来。
生产系统里，日志本身也可能成为风险源。
PII、业务敏感数据、API Key、内部文档、客户资料，都要有脱敏、加密、留存周期和访问控制。
大模型网关通常持有上游 API Key，也会经过大量敏感请求。
它不是普通工具库。
它是安全边界的一部分。
六、不要一开始就造复杂 Router
看到这里，很容易走向另一个极端：
那我是不是应该一开始就做一个很强的大模型网关？
不一定。
更现实的演进路径是分阶段。
第一阶段，只解决一件事：
别让业务代码直连一堆供应商 SDK。
哪怕路由规则一开始全是配置写死，也比散在十几个服务里强。
这个阶段最重要的产物是：
• 统一入口 • 统一模型名 • 统一日志 • 统一错误分类
第二阶段，再做规则路由。
比如免费用户走小模型，企业用户复杂任务走强模型。
分类任务走快模型，法务任务强制走高质量模型。
主模型 429 时切备用供应商。
每次都记录 route_reason。
第三阶段，再做 fallback、限流、Token 预算和成本归因。
这时候你开始真正知道：
钱花在哪里。
失败发生在哪里。
哪些场景需要升级。
哪些场景可以降级。
第四阶段，才考虑分类路由、语义路由、级联路由。
比如先用便宜模型处理轻量任务，置信度低或校验失败时再升级强模型。
这能省钱，但会增加延迟和链路复杂度。
不是所有场景都适合。
第五阶段，才是学习型 Router、个性化 Router、Agentic Router。
比如多步 Agent 里：
规划用强模型。
工具参数生成用快模型。
最终总结用便宜模型。
这听起来很诱人。
但它需要 trace、评测集、质量标签、成本上限和回放能力。
没有这些基础，智能路由会变成新的黑盒。
所以我很喜欢 AIGuide 这篇大模型网关材料里的一个判断：
没有 trace，不上分类器。
没有评测集，不上学习型 Router。
没有成本上限，不上 Agentic 路由。
先把规则路由、fallback、usage 和 route_reason 跑稳，再谈智能化。
七、网关把前几篇文章重新连起来
写到第 07 篇，AIGuide 这条线其实已经开始合流了。
前面讲 LLM API，不是为了让你会调一个聊天接口。
是为了理解模型调用链里有超时、重试、流式、结构化输出和服务端校验。
前面讲 RAG，不是为了让你会接一个向量库。
是为了理解知识进入模型时会带来检索、引用、上下文长度、权限和版本问题。
前面讲 Agent，不是为了说“会调工具就很智能”。
是为了理解多步任务会放大模型调用次数、工具风险、状态恢复和人工确认问题。
前面讲 Context Engineering，不是为了发明一个更潮的 prompt 名词。
是为了控制哪些信息进入模型、进入多少、什么时候压缩、什么时候拒绝。
前面讲评测，不是为了上线前打一个分。
是为了让 Prompt、模型、路由、RAG、Agent 改动以后，都能回归和追踪。
而大模型网关，正好站在这些东西中间。
它不替你解决所有问题。
但它会把很多问题变成可治理的对象。
模型选择，变成路由策略。
失败处理，变成 fallback 表。
上下文长度，变成 Token 预算。
成本失控，变成归因报表。
质量漂移，变成 trace + eval。
安全风险，变成权限、脱敏、审计和凭证治理。
这就是为什么我说：
大模型网关是 AI 应用进入生产的分水岭。
不是因为每个项目都要立刻上一个复杂平台。
而是因为你一旦开始思考网关，就已经不再把 AI 应用看成“prompt + API”。
你开始把它看成一个真实后端系统。
八、开发者真正要迁移的，还是工程判断力
如果你是后端开发者，大模型网关应该是一个很熟悉的东西。
它和传统 API Gateway、服务治理、限流、熔断、观测、计费、安全有很多相通之处。
只是治理对象变了。
过去你治理的是 HTTP 请求、RPC 调用、数据库连接、消息队列和第三方接口。
现在你还要治理模型调用。
模型调用有几个新特点：
• 成本按 Token 变化 • 输出有概率性 • 上下文会影响结果 • 模型能力会随供应商更新而变化 • 失败原因不只来自代码 • 质量需要评测系统辅助判断
但底层工程判断没有失效。
你仍然要问：
这个能力的边界在哪里？
失败时怎么降级？
谁有权限调用？
成本归到哪里？
出了问题能不能回放？
上线前有没有回归？
数据和凭证有没有保护？
这些问题，比“今天哪个模型最强”更长期。
模型会变。
供应商会变。
价格会变。
上下文窗口会变。
但只要 AI 应用进入生产，路由、fallback、限流、成本、观测、安全和审计就一直会在。
所以第 07 篇的结论很简单：
不要把大模型网关理解成一个高级组件。
先把它理解成一个生产意识。
当你的 AI 功能从 demo 走向真实业务时，你迟早要回答这些问题：
这次为什么用这个模型？
失败以后怎么处理？
Token 花在哪里？
质量有没有退化？
敏感数据有没有泄露？
出事以后能不能复盘？
能回答这些问题，AI 应用才开始像一个生产系统。
回答不了，就还是一个包装得更好看的 Prompt Demo。
来源说明
本文内容主要基于 Snailclimb / JavaGuide 的 AIGuide 系列材料整理，并结合我自己的阅读理解、知识库实践和 AI Coding 经验做了重写和串联。重点参考：
• https://javaguide.cn/ai/system-design/llm-gateway.html • https://javaguide.cn/ai/system-design/ai-application-architecture.html • https://github.com/Snailclimb/AIGuide
如果你也在系统学习 AI 应用开发、RAG、Agent、Context Engineering、评测、系统设计和 AI Coding，欢迎继续关注这个系列。
往期推荐：
