当一个团队第一次把 AI 编码助手接入开发流程时大家讨论最多的是“哪家模型写代码更强”。但往往运行两三个月后讨论的话题就会彻底改变变成“这个需求是让模型直接生成还是走规则引擎”“模型一旦抖动线上哪些业务可以降级”这种从“模型选型”到“架构取舍”的转变才是 AI 原生开发真正开始的地方。这篇文章想聊两件事一是 AI 原生开发到底在重排团队的哪些东西二是 LLM 网关作为模型依赖的入口怎么把故障取舍落到可执行的工程策略上。如果你正处于团队引入 AI 但还没有统一入口的阶段或者已经在维护多个大模型调用但疲于应付稳定性问题这篇文章会给你一个相对完整的框架。1. AI 原生开发在重排什么三个层面的真实变化很多人把 AI 原生开发理解为“用 AI 写代码”这个理解太浅了。它更准确的定义是把大模型当成系统里的一个原生依赖围绕它的特性重新设计团队分工、研发流程和系统架构。1.1 角色层核心工作从“写代码”变成“定义质量”传统开发流程中研发团队的核心产物是代码测试团队的核心产物是用例交付团队关心的是上线结果。引入大模型之后最难的不是让模型生成一段代码而是怎么定义“生成结果是对的”。于是团队里开始出现以前没有的角色提示词工程师负责把业务需求转化成模型能理解的输入并且持续优化输入结构。评测工程师负责建设评测集、设定评分标准判断模型输出是否满足业务要求。模型运营人员负责跟踪模型升级、成本消耗、调用量变化类似传统运维对服务器的关注。AI 基础设施工程师负责维护 LLM 网关、模型路由、熔断降级、日志链路。这不是把原来的开发岗位改个名字而是新增了一类“围绕模型输出的质量与运营”的岗位。真正的 AI 原生团队不会把所有工程师都变成提示词工程师但一定会有人专门扛起“输出质量”这个指标。1.2 流程层开发流程从“代码驱动”变成“评测驱动”传统敏捷开发里需求被拆成用户故事开发完成后提测测试人员根据验收标准验证功能。AI 原生开发多了一个非常关键的环节评测回归。原因很简单。传统代码的行为是确定的同一个输入永远得到同一个输出。大模型不是它的输出有随机性模型的版本升级也可能带来行为漂移。如果不建评测集你今天精调好的提示词可能因为模型一个微小的版本变化就整体失效。所以评测集在 AI 原生开发里的地位已经等同于传统开发里的自动化测试套件。这里有一个团队最容易踩的坑把提示词当代码管理却没有把评测结果当测试报告管理。提示词确实应该进 Git但更重要的是每次修改提示词或切换模型后必须拿同一套评测集跑一遍对比分数再决定合并还是回滚。评测驱动的流程一旦建立起来AI 改造才算是融入了研发闭环。1.3 架构层模型从“API 调用”变成“外部核心依赖”更隐蔽的变化发生在架构层面。早期接入 AI 只是“请求第三方 API”一个服务里写死一个 URL配上 API Key 就算完。但当一个系统里几十个服务都在调用大模型时模型就不再是一个普通外部接口而是一个核心依赖。既然是核心依赖它就需要像数据库、缓存、消息队列一样被治理需要统一入口而不是每个服务各自直连。需要超时和重试因为模型 API 的延迟和可用性不受你控制。需要熔断和降级因为模型服务在极端情况下一定会出问题。需要成本控制因为 token 消耗是持续性的真金白银。这就是 LLM 网关登场的背景。它解决的并不是“调用模型好不好用”的问题而是“当模型成为核心依赖之后如何治理这个依赖”的问题。2. LLM 网关是什么和传统 API 网关的区别2.1 没有网关时是什么状态先看一个没有 LLM 网关的典型状态。一个中型团队前端页面要 AI 总结客服系统要 AI 回复内容团队要 AI 写摘要运营要 AI 做标签。每个项目各自接入模型供应商各自维护 API Key各自处理超时和重试。结果往往是密钥散落在不同项目的环境变量里权限失控。每个项目对同一个模型写了三套完全不同的超时和重试逻辑。一个模型服务抖动所有直连它的服务一起跟着抖。月底成本核算时根本说不清哪个场景消耗了多少 token。出了问题想排查链路每个项目都有日志但拼不起一条完整链路。这些痛点叠加起来就是 LLM 网关要解决的原始需求。2.2 LLM 网关的定义LLM 网关是介于应用服务和大模型 API 之间的中间层。它负责统一接收应用的模型调用请求做认证鉴权、模型路由、速率限制、超时重试、熔断降级、成本统计和链路追踪再转发给真实的大模型供应商。一句话概括应用不再关心“这次请求会打到哪个模型、怎么控制失败、怎么统计成本”这些全部交给网关。2.3 与传统 API 网关的差异很多团队会问我们已经有 Kong、APISIX、Spring Cloud Gateway为什么还需要 LLM 网关这里的核心差异是治理维度不同。维度传统 API 网关LLM 网关核心对象HTTP 接口、微服务大模型调用、提示词、token路由依据URL、请求头、服务名任务类型、成本预算、场景要求故障处理超时、限流、熔断超时、重试、降级到备用模型或本地预案成本感知无按 token 计费、配额控制、结果缓存输出管理只转发响应可能需要校验输出格式、处理敏感信息典型指标QPS、成功率、延迟token 消耗、生成质量、降级命中率传统网关负责的是“流量怎么走”LLM 网关负责的是“模型怎么选、失败怎么办、成本怎么控”。如果团队已经用了微服务网关不等于不需要 LLM 网关两者会同时存在应用先经过微服务网关再到 LLM 网关最后才到模型供应商。3. LLM 网关的核心能力拆解3.1 模型路由按场景把请求分发给最合适的模型模型路由是 LLM 网关最基础也最有价值的能力。它的目标不是把请求随便丢给一个模型而是结合任务类型、成本和延迟要求做决策。举一个常见场景一个应用里同时有摘要生成、意图识别、代码解释、情感分析四个功能。摘要和解释需要理解能力强的大模型意图识别和情感分析这类简单分类任务小模型完全能胜任。如果所有请求都走同一个大模型不仅成本高延迟也上不去。通过网关配置就可以让简单任务路由到小模型复杂任务路由到大模型。以下是一个配置风格的示例重点演示路由思路字段名以实际网关产品为准# llm-gateway-route.yaml routes: - name: content-summary match: scene: summary priority: high target: provider: openai-compatible model: gpt-4.1-mini fallback_model: gpt-4o-mini timeout: 30s max_tokens: 2048 - name: intent-classification match: scene: intent priority: low target: provider: openai-compatible model: gpt-4o-mini fallback_model: claude-3-haiku timeout: 10s max_tokens: 512路由策略一般包含三个要素匹配条件、目标模型、兜底模型。匹配条件可以是业务场景、用户等级、输入长度等目标模型是正常情况下使用的模型兜底模型是主模型失败或超时后切换的备选。这里容易踩坑的地方是路由条件不要只写场景名还要考虑该场景对延迟和成本的真实要求。网关配置不是写好就永远不动而是需要根据线上调用量和成本报表持续调整。3.2 超时、重试与幂等模型 API 不像数据库那么好伺候模型 API 的失败模式和数据库有本质区别。数据库连接失败可以快速重试因为事务有明确的幂等控制而大模型生成是“重试一次就可能生成完全不同的结果”而且每次都消耗 token。所以在配置重试时要区分可重试和不可重试的错误可重试HTTP 429限流、503、504、网络超时。不可重试400请求参数错误、401鉴权失败、403无权限。429 是特别典型的场景。模型供应商为了控制负载会对调用频率做限流。一旦出现 429正确的做法不是立刻重试而是采用指数退避策略每次等待时间翻倍比如 1s、2s、4s同时加上随机抖动避免所有请求同时重试形成惊群效应。网关层还要做幂等控制。应用在发起模型调用时应该生成一个唯一的 request_id网关根据 request_id 判断当前请求是否已经重试过避免同一业务被重复提交产生多次扣费。3.3 熔断与降级故障取舍的真正落点熔断是链路上防止故障扩散的成熟手段。在 LLM 网关里熔断器会对每个模型实例记录连续失败次数当失败率达到阈值时熔断器打开后续请求不再打到真实模型而是直接走降级逻辑。等冷却时间结束后进入半开状态放小部分流量探测确认模型恢复后再关闭熔断器。降级是故障取舍的核心动作。模型不可用时的降级方案通常有以下几类切换备用模型主模型挂了切到另一个供应商的模型。返回本地缓存相似请求之前有过成功结果直接复用。使用静态模板针对特定场景返回预设文案或规则处理结果。简化生成放弃复杂输出返回一个更短、更保守的回答。直接报错明确告诉用户当前功能不可用。这几种方案的业务代价完全不同。切换备用模型最接近原体验但成本高返回缓存快但没有新内容静态模板稳定但不够智能直接报错最透明但可能流失用户。没有绝对正确的方案只有根据业务等级选择的方案。4. 故障取舍LLM 网关面对的真实选择题“故障取舍”不是理论话题而是每天可能发生的工程决策。我们把几个关键选择展开来看。4.1 取舍一宁可报错还是宁可降智这是最核心的选择。当模型不可用或输出质量不稳定时你是给用户一个明确的错误提示还是退而求其次给一个质量略低但可用的结果一个客服售后场景就是很好的例子。如果 AI 客服依赖的模型服务故障直接提示“系统繁忙”当然最诚实但用户会非常不满。更优的做法可能是降级到 FAQ 检索或人工客服入口用户至少能获得咨询路径。这里的“降级”不等于“坏结果”而是用一个更可控的结果替代不可控的结果。反过来在医疗建议、法律意见这类高风险场景中宁可拒绝回答也绝不能给出质量不达标的生成结果。因为低质量答案的代价远超“服务暂时不可用”。团队在进行故障取舍前必须先把业务划分等级再对号入座选择降级策略。4.2 取舍二重试到底几次熔断到底多敏感重试和熔断天然存在张力。重试太多可能放大故障把已经拥堵的模型打得更慢熔断太敏感则可能在模型短暂抖动时就把业务切到降级造成不必要的体验下降。推荐的做法是给不同场景配置不同的参数。核心支付链路要少重试、快熔断智能摘要类非核心功能可以容忍更长重试。具体数值没有统一标准但团队应当明确一个目标网关的默认配置只是起点线上运行后要根据错误率、延迟、降级命中率持续调优。4.3 取舍三成本和体验谁优先模型调用是按 token 计费的。同一个问题用大模型解决要花 1 元用小模型只要 0.1 元但生成质量可能差一点。当业务规模上来后这个成本差距会非常显著。LLM 网关的价值在于让这个取舍变得可见、可配置。通过网关你可以监控每个场景的 token 消耗甚至给不同项目设置配额。这样团队负责人不需要每天看账单只要看网关报表就能知道哪个业务在烧钱然后主动决定是否下调模型档位或开启结果缓存。成本控制不是上线后才做的事而是网关配置阶段就应该考虑的事。4.4 故障取舍的本质说到底故障取舍要回答的问题是系统在降级状态下保留什么、舍弃什么。保留的是用户的访问能力、关键路径、基础体验舍弃的是复杂性、完全智能化、极端准确性。这个判断不是技术团队单独能定的必须结合业务目标才能在故障发生时做出恰当的取舍。5. 从工具引入到 AI 原生开发团队落地的四步路径5.1 第一步单点试点不铺开团队从零转向 AI 原生时最容易犯的错误是全面开花。建议先选一两个高频、低风险的场景试点比如“客服自动摘要”“代码提交信息生成”。把这些场景跑通本质上是验证团队对模型输出质量的定义能力。试点阶段不急着引入网关但要记录调用方式、失败率、成本和数据回流环节为后面统一管理做准备。5.2 第二步统一入口收敛模型调用当试点场景被验证有效其他业务开始跟进时就应该引入 LLM 网关。这一步的核心目标是收敛所有模型调用走同一个入口统一认证、统一日志、统一成本统计、统一失配策略。统一入口带来的价值很快会显现新场景接入从“找 API、配 Key、写重试逻辑”变成“在网关加一条路由”周期明显缩短故障时也能在网关层快速确认是模型问题还是业务问题。5.3 第三步建立评测集让质量回归成为习惯统一网关之后下一步是建设评测集。一个最小可用的评测集包含三类数据正常输入覆盖高频业务场景的标准问题。边界输入容易混淆、容易出错的输入。恶意或异常输入测试提示词注入、超长输入、空输入。每次修改提示词、切换模型、升级模型版本都要用同一套评测集跑回归。评测结果直接决定这个变更能不能上线。5.4 第四步架构角色化固化职责边界当团队规模变大基础设施团队负责维护 LLM 网关、模型账号、配额和稳定性指标业务团队负责各自的提示词、评测集和场景回落策略。两者的边界要清晰业务团队不应直接改网关底层配置基础设施团队也不应替业务团队决定“这个场景能不能接受降智”。职责边界清晰后AI 原生开发的团队结构才算稳定下来。6. 可落地的配置示例与代码片段6.1 降级策略配置示例以下是一个按业务等级配置降级策略的示例假设网关框架支持类似 DSL 的配置# fallback-policy.yaml fallback_policy: - scene: customer_service level: P0 fallback_order: - switch_model - cache_result - static_template static_template: 当前智能服务繁忙请拨打人工客服电话 400-XXX-XXXX。 circuit_breaker: failure_threshold: 5 open_timeout: 30s - scene: content_summary level: P1 fallback_order: - switch_model - simplify_generation simplify_generation: max_tokens: 128 prompt_template: 请用一句话总结原文{{input}}这段配置表达了两层含义P0 客服场景宁可降级到人工入口也不能让用户得不到任何响应P1 摘要场景可以接受简化生成但保留核心功能。策略中的 fallback_order 从左到右依次尝试实际字段名以网关实现为准。6.2 调用侧处理降级结果的 Java 示例应用侧调用 LLM 网关时并不需要知道网关内部选择了什么降级方案只需要判断返回结果是否还在可接受范围内。以下是一个最小示例// 文件路径src/main/java/com/example/gateway/client/LlmGatewayClient.java public class LlmGatewayClient { private final RestTemplate restTemplate; private final String gatewayUrl; public LlmGatewayClient(RestTemplate restTemplate, String gatewayUrl) { this.restTemplate restTemplate; this.gatewayUrl gatewayUrl; } public LlmResponse call(String scene, String prompt) { LlmRequest request new LlmRequest(); request.setScene(scene); request.setPrompt(prompt); request.setRequestId(UUID.randomUUID().toString()); request.setTraceEnabled(true); try { ResponseEntityLlmResponse resp restTemplate.postForEntity( gatewayUrl /v1/chat, request, LlmResponse.class ); LlmResponse body resp.getBody(); if (body null || body.isFallback()) { // 网关层返回了降级结果这里由业务决定是否接受 log.warn(llm gateway returned fallback response, scene{}, scene); } return body; } catch (HttpServerErrorException e) { // 网关本身不可用或模型全部失败走业务兜底逻辑 return LlmResponse.businessFallback(AI 服务暂时不可用请稍后重试。); } catch (ResourceAccessException e) { // 网络超时不盲目重试交给上层决定 log.error(llm gateway request timeout, scene{}, scene, e); return LlmResponse.businessFallback(AI 服务超时请稍后重试。); } } }这段代码的关键点在于应用侧永远不直接选择模型只指定场景网关层是否降级、切换到哪个模型由网关决定。这样业务代码保持简单故障决策集中在基础设施层。上层的 LlmResponse 需要包含 isFallback 字段用来告知调用方当前结果并非模型原始输出业务方可以据此决定是否展示。6.3 评测回归脚本示例评测回归是 AI 原生开发里最需要固化下来的工程环节。下面是一个简化版的 Python 评测脚本读评测集、调用网关、计算得分# 文件路径eval/regression_eval.py import json import time import requests EVAL_SET_PATH ./eval_set.json GATEWAY_URL http://localhost:8080/v1/chat def load_eval_set(path): with open(path, r, encodingutf-8) as f: return json.load(f) def call_model(scene, prompt): payload {scene: scene, prompt: prompt, request_id: feval-{time.time()}} resp requests.post(GATEWAY_URL, jsonpayload, timeout30) resp.raise_for_status() return resp.json() def evaluate(case): result call_model(case[scene], case[prompt]) generated result.get(output, ) # 这里的评分函数可以替换为人工评分、LLM 评分或规则匹配 if case[type] contains: return float(any(kw in generated for kw in case[keywords])) if case[type] exact: return float(generated.strip() case[expected].strip()) return 0.0 def main(): cases load_eval_set(EVAL_SET_PATH) scores [evaluate(case) for case in cases] total sum(scores) / len(scores) print(feval score: {total*100:.2f}%) for i, case in enumerate(cases): print(f{i1}. [{case[scene]}] {case[name]}: {scores[i]}) if __name__ __main__: main()对应的评测集文件可以长这样[ { name: 客服摘要包含订单号, scene: customer_summary, type: contains, prompt: 请总结这段客服对话并提取订单号..., keywords: [20240101] }, { name: 意图识别准确, scene: intent_classification, type: exact, prompt: 我想退掉这个订单, expected: 退款意图 } ]评测脚本的运行方式是python eval/regression_eval.py如果输出分数低于上一次基线说明当前提示词或模型变更属于回归应阻止合并。这个最小评测框架可以很快扩展到多维度评分和自动回归任务中。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型调用偶尔超时未配置超时与重试或超时时间过短查看网关日志和调用链路耗时设置合理超时对限流和5xx采用指数退避重试一个模型故障拖垮所有业务业务直连模型没有统一网关查看模型供应商状态和各服务调用关系引入 LLM 网关统一熔断和降级模型不可用时用户收到负面体验没有降级策略或降级策略只返回报错看错误率和降级命中率指标按业务等级配置多级降级方案成本每个月都在涨没有成本配额所有请求都走大模型按场景统计 token 消耗报表开启模型分级路由和结果缓存设置配额模型升级后效果明显变差没有评测集和回归流程对比升级前后评测分数建立场景评测集升级前跑回归网关配置变更导致线上故障缺少配置管理和灰度发布检查配置变更记录网关配置纳入 Git 管理走灰度发布8. 最佳实践与工程建议8.1 先定义“可接受失败率”再选技术方案引入网关之前先和业务方对齐一个指标哪些场景可以接受降级哪些场景宁可报错也不能降智。这个共识会直接影响网关的熔断阈值和降级策略设计比任何技术选型都重要。8.2 网关配置要有版本管理LLM 网关的路由规则、降级策略、触发阈值都应该像应用代码一样纳入版本管理。每次修改需要走评审记录变更原因。否则模型行为变化时很难判断是模型升级导致的还是网关配置导致的。8.3 令牌和密钥管理要独立不要把所有模型的 API Key 放在业务项目的环境变量里。密钥应统一由网关管理业务侧通过网关的鉴权机制访问。涉及密钥的配置要使用独立的密钥管理系统避免密钥出现在日志和代码仓库中。同时建议用最小权限原则不同业务线只暴露自己需要的模型能力。8.4 模型切换一定要灰度无论是切换模型供应商还是升级模型版本都不要一次性切全量流量。建议先切 5% 到 10% 的流量观察评测分数、用户反馈、错误率和成本变化确认稳定后再逐步放量。这里评测集和网关配置灰度发布缺一不可。8.5 监控指标要覆盖到模型层传统监控主要看 QPS、成功率、延迟。AI 场景下至少还要增加token 消耗总量和分场景消耗。模型路由命中分布即每个模型承接了多少请求。降级命中率即多少请求走了降级策略。平均生成耗时即首 token 延迟和总生成时长。这些指标直接反映模型这个外部依赖的健康状况也是故障取舍是否奏效的证据。9. 总结与后续学习方向AI 原生开发对团队的重排不是说要把团队切成“用 AI 的”和“不用 AI 的”而是要把围绕模型的质量定义、评测回归、网关治理这些新任务固化到组织结构里。LLM 网关在其中承担的是“基础设施承重墙”的角色它把模型不可靠、成本不可控、调用分散这些老问题集中到一层解决让业务团队只需要关心场景本身。如果你想在一周内落地一个最小闭环可以按这个顺序做先选一个核心场景定义它的降级策略再搭一个最简单的统一入口把直连模型的调用收敛起来最后写几条评测用例跑一次回归脚本。不要把战线拉得太长先让团队看到“模型故障时系统依然可控”这个效果比任何架构设计都更有说服力。值得继续深入的方向包括模型评测框架的设计与自动化、多供应商模型路由策略、token 成本建模与配额治理以及网关层如何处理流式输出下的熔断与降级。这些都是 AI 原生开发走向成熟阶段绕不开的工程细节也是 LLM 网关真正发挥价值的地方。 AI原生开发中的LLM网关：从模型依赖到故障取舍的工程实践
当一个团队第一次把 AI 编码助手接入开发流程时大家讨论最多的是“哪家模型写代码更强”。但往往运行两三个月后讨论的话题就会彻底改变变成“这个需求是让模型直接生成还是走规则引擎”“模型一旦抖动线上哪些业务可以降级”这种从“模型选型”到“架构取舍”的转变才是 AI 原生开发真正开始的地方。这篇文章想聊两件事一是 AI 原生开发到底在重排团队的哪些东西二是 LLM 网关作为模型依赖的入口怎么把故障取舍落到可执行的工程策略上。如果你正处于团队引入 AI 但还没有统一入口的阶段或者已经在维护多个大模型调用但疲于应付稳定性问题这篇文章会给你一个相对完整的框架。1. AI 原生开发在重排什么三个层面的真实变化很多人把 AI 原生开发理解为“用 AI 写代码”这个理解太浅了。它更准确的定义是把大模型当成系统里的一个原生依赖围绕它的特性重新设计团队分工、研发流程和系统架构。1.1 角色层核心工作从“写代码”变成“定义质量”传统开发流程中研发团队的核心产物是代码测试团队的核心产物是用例交付团队关心的是上线结果。引入大模型之后最难的不是让模型生成一段代码而是怎么定义“生成结果是对的”。于是团队里开始出现以前没有的角色提示词工程师负责把业务需求转化成模型能理解的输入并且持续优化输入结构。评测工程师负责建设评测集、设定评分标准判断模型输出是否满足业务要求。模型运营人员负责跟踪模型升级、成本消耗、调用量变化类似传统运维对服务器的关注。AI 基础设施工程师负责维护 LLM 网关、模型路由、熔断降级、日志链路。这不是把原来的开发岗位改个名字而是新增了一类“围绕模型输出的质量与运营”的岗位。真正的 AI 原生团队不会把所有工程师都变成提示词工程师但一定会有人专门扛起“输出质量”这个指标。1.2 流程层开发流程从“代码驱动”变成“评测驱动”传统敏捷开发里需求被拆成用户故事开发完成后提测测试人员根据验收标准验证功能。AI 原生开发多了一个非常关键的环节评测回归。原因很简单。传统代码的行为是确定的同一个输入永远得到同一个输出。大模型不是它的输出有随机性模型的版本升级也可能带来行为漂移。如果不建评测集你今天精调好的提示词可能因为模型一个微小的版本变化就整体失效。所以评测集在 AI 原生开发里的地位已经等同于传统开发里的自动化测试套件。这里有一个团队最容易踩的坑把提示词当代码管理却没有把评测结果当测试报告管理。提示词确实应该进 Git但更重要的是每次修改提示词或切换模型后必须拿同一套评测集跑一遍对比分数再决定合并还是回滚。评测驱动的流程一旦建立起来AI 改造才算是融入了研发闭环。1.3 架构层模型从“API 调用”变成“外部核心依赖”更隐蔽的变化发生在架构层面。早期接入 AI 只是“请求第三方 API”一个服务里写死一个 URL配上 API Key 就算完。但当一个系统里几十个服务都在调用大模型时模型就不再是一个普通外部接口而是一个核心依赖。既然是核心依赖它就需要像数据库、缓存、消息队列一样被治理需要统一入口而不是每个服务各自直连。需要超时和重试因为模型 API 的延迟和可用性不受你控制。需要熔断和降级因为模型服务在极端情况下一定会出问题。需要成本控制因为 token 消耗是持续性的真金白银。这就是 LLM 网关登场的背景。它解决的并不是“调用模型好不好用”的问题而是“当模型成为核心依赖之后如何治理这个依赖”的问题。2. LLM 网关是什么和传统 API 网关的区别2.1 没有网关时是什么状态先看一个没有 LLM 网关的典型状态。一个中型团队前端页面要 AI 总结客服系统要 AI 回复内容团队要 AI 写摘要运营要 AI 做标签。每个项目各自接入模型供应商各自维护 API Key各自处理超时和重试。结果往往是密钥散落在不同项目的环境变量里权限失控。每个项目对同一个模型写了三套完全不同的超时和重试逻辑。一个模型服务抖动所有直连它的服务一起跟着抖。月底成本核算时根本说不清哪个场景消耗了多少 token。出了问题想排查链路每个项目都有日志但拼不起一条完整链路。这些痛点叠加起来就是 LLM 网关要解决的原始需求。2.2 LLM 网关的定义LLM 网关是介于应用服务和大模型 API 之间的中间层。它负责统一接收应用的模型调用请求做认证鉴权、模型路由、速率限制、超时重试、熔断降级、成本统计和链路追踪再转发给真实的大模型供应商。一句话概括应用不再关心“这次请求会打到哪个模型、怎么控制失败、怎么统计成本”这些全部交给网关。2.3 与传统 API 网关的差异很多团队会问我们已经有 Kong、APISIX、Spring Cloud Gateway为什么还需要 LLM 网关这里的核心差异是治理维度不同。维度传统 API 网关LLM 网关核心对象HTTP 接口、微服务大模型调用、提示词、token路由依据URL、请求头、服务名任务类型、成本预算、场景要求故障处理超时、限流、熔断超时、重试、降级到备用模型或本地预案成本感知无按 token 计费、配额控制、结果缓存输出管理只转发响应可能需要校验输出格式、处理敏感信息典型指标QPS、成功率、延迟token 消耗、生成质量、降级命中率传统网关负责的是“流量怎么走”LLM 网关负责的是“模型怎么选、失败怎么办、成本怎么控”。如果团队已经用了微服务网关不等于不需要 LLM 网关两者会同时存在应用先经过微服务网关再到 LLM 网关最后才到模型供应商。3. LLM 网关的核心能力拆解3.1 模型路由按场景把请求分发给最合适的模型模型路由是 LLM 网关最基础也最有价值的能力。它的目标不是把请求随便丢给一个模型而是结合任务类型、成本和延迟要求做决策。举一个常见场景一个应用里同时有摘要生成、意图识别、代码解释、情感分析四个功能。摘要和解释需要理解能力强的大模型意图识别和情感分析这类简单分类任务小模型完全能胜任。如果所有请求都走同一个大模型不仅成本高延迟也上不去。通过网关配置就可以让简单任务路由到小模型复杂任务路由到大模型。以下是一个配置风格的示例重点演示路由思路字段名以实际网关产品为准# llm-gateway-route.yaml routes: - name: content-summary match: scene: summary priority: high target: provider: openai-compatible model: gpt-4.1-mini fallback_model: gpt-4o-mini timeout: 30s max_tokens: 2048 - name: intent-classification match: scene: intent priority: low target: provider: openai-compatible model: gpt-4o-mini fallback_model: claude-3-haiku timeout: 10s max_tokens: 512路由策略一般包含三个要素匹配条件、目标模型、兜底模型。匹配条件可以是业务场景、用户等级、输入长度等目标模型是正常情况下使用的模型兜底模型是主模型失败或超时后切换的备选。这里容易踩坑的地方是路由条件不要只写场景名还要考虑该场景对延迟和成本的真实要求。网关配置不是写好就永远不动而是需要根据线上调用量和成本报表持续调整。3.2 超时、重试与幂等模型 API 不像数据库那么好伺候模型 API 的失败模式和数据库有本质区别。数据库连接失败可以快速重试因为事务有明确的幂等控制而大模型生成是“重试一次就可能生成完全不同的结果”而且每次都消耗 token。所以在配置重试时要区分可重试和不可重试的错误可重试HTTP 429限流、503、504、网络超时。不可重试400请求参数错误、401鉴权失败、403无权限。429 是特别典型的场景。模型供应商为了控制负载会对调用频率做限流。一旦出现 429正确的做法不是立刻重试而是采用指数退避策略每次等待时间翻倍比如 1s、2s、4s同时加上随机抖动避免所有请求同时重试形成惊群效应。网关层还要做幂等控制。应用在发起模型调用时应该生成一个唯一的 request_id网关根据 request_id 判断当前请求是否已经重试过避免同一业务被重复提交产生多次扣费。3.3 熔断与降级故障取舍的真正落点熔断是链路上防止故障扩散的成熟手段。在 LLM 网关里熔断器会对每个模型实例记录连续失败次数当失败率达到阈值时熔断器打开后续请求不再打到真实模型而是直接走降级逻辑。等冷却时间结束后进入半开状态放小部分流量探测确认模型恢复后再关闭熔断器。降级是故障取舍的核心动作。模型不可用时的降级方案通常有以下几类切换备用模型主模型挂了切到另一个供应商的模型。返回本地缓存相似请求之前有过成功结果直接复用。使用静态模板针对特定场景返回预设文案或规则处理结果。简化生成放弃复杂输出返回一个更短、更保守的回答。直接报错明确告诉用户当前功能不可用。这几种方案的业务代价完全不同。切换备用模型最接近原体验但成本高返回缓存快但没有新内容静态模板稳定但不够智能直接报错最透明但可能流失用户。没有绝对正确的方案只有根据业务等级选择的方案。4. 故障取舍LLM 网关面对的真实选择题“故障取舍”不是理论话题而是每天可能发生的工程决策。我们把几个关键选择展开来看。4.1 取舍一宁可报错还是宁可降智这是最核心的选择。当模型不可用或输出质量不稳定时你是给用户一个明确的错误提示还是退而求其次给一个质量略低但可用的结果一个客服售后场景就是很好的例子。如果 AI 客服依赖的模型服务故障直接提示“系统繁忙”当然最诚实但用户会非常不满。更优的做法可能是降级到 FAQ 检索或人工客服入口用户至少能获得咨询路径。这里的“降级”不等于“坏结果”而是用一个更可控的结果替代不可控的结果。反过来在医疗建议、法律意见这类高风险场景中宁可拒绝回答也绝不能给出质量不达标的生成结果。因为低质量答案的代价远超“服务暂时不可用”。团队在进行故障取舍前必须先把业务划分等级再对号入座选择降级策略。4.2 取舍二重试到底几次熔断到底多敏感重试和熔断天然存在张力。重试太多可能放大故障把已经拥堵的模型打得更慢熔断太敏感则可能在模型短暂抖动时就把业务切到降级造成不必要的体验下降。推荐的做法是给不同场景配置不同的参数。核心支付链路要少重试、快熔断智能摘要类非核心功能可以容忍更长重试。具体数值没有统一标准但团队应当明确一个目标网关的默认配置只是起点线上运行后要根据错误率、延迟、降级命中率持续调优。4.3 取舍三成本和体验谁优先模型调用是按 token 计费的。同一个问题用大模型解决要花 1 元用小模型只要 0.1 元但生成质量可能差一点。当业务规模上来后这个成本差距会非常显著。LLM 网关的价值在于让这个取舍变得可见、可配置。通过网关你可以监控每个场景的 token 消耗甚至给不同项目设置配额。这样团队负责人不需要每天看账单只要看网关报表就能知道哪个业务在烧钱然后主动决定是否下调模型档位或开启结果缓存。成本控制不是上线后才做的事而是网关配置阶段就应该考虑的事。4.4 故障取舍的本质说到底故障取舍要回答的问题是系统在降级状态下保留什么、舍弃什么。保留的是用户的访问能力、关键路径、基础体验舍弃的是复杂性、完全智能化、极端准确性。这个判断不是技术团队单独能定的必须结合业务目标才能在故障发生时做出恰当的取舍。5. 从工具引入到 AI 原生开发团队落地的四步路径5.1 第一步单点试点不铺开团队从零转向 AI 原生时最容易犯的错误是全面开花。建议先选一两个高频、低风险的场景试点比如“客服自动摘要”“代码提交信息生成”。把这些场景跑通本质上是验证团队对模型输出质量的定义能力。试点阶段不急着引入网关但要记录调用方式、失败率、成本和数据回流环节为后面统一管理做准备。5.2 第二步统一入口收敛模型调用当试点场景被验证有效其他业务开始跟进时就应该引入 LLM 网关。这一步的核心目标是收敛所有模型调用走同一个入口统一认证、统一日志、统一成本统计、统一失配策略。统一入口带来的价值很快会显现新场景接入从“找 API、配 Key、写重试逻辑”变成“在网关加一条路由”周期明显缩短故障时也能在网关层快速确认是模型问题还是业务问题。5.3 第三步建立评测集让质量回归成为习惯统一网关之后下一步是建设评测集。一个最小可用的评测集包含三类数据正常输入覆盖高频业务场景的标准问题。边界输入容易混淆、容易出错的输入。恶意或异常输入测试提示词注入、超长输入、空输入。每次修改提示词、切换模型、升级模型版本都要用同一套评测集跑回归。评测结果直接决定这个变更能不能上线。5.4 第四步架构角色化固化职责边界当团队规模变大基础设施团队负责维护 LLM 网关、模型账号、配额和稳定性指标业务团队负责各自的提示词、评测集和场景回落策略。两者的边界要清晰业务团队不应直接改网关底层配置基础设施团队也不应替业务团队决定“这个场景能不能接受降智”。职责边界清晰后AI 原生开发的团队结构才算稳定下来。6. 可落地的配置示例与代码片段6.1 降级策略配置示例以下是一个按业务等级配置降级策略的示例假设网关框架支持类似 DSL 的配置# fallback-policy.yaml fallback_policy: - scene: customer_service level: P0 fallback_order: - switch_model - cache_result - static_template static_template: 当前智能服务繁忙请拨打人工客服电话 400-XXX-XXXX。 circuit_breaker: failure_threshold: 5 open_timeout: 30s - scene: content_summary level: P1 fallback_order: - switch_model - simplify_generation simplify_generation: max_tokens: 128 prompt_template: 请用一句话总结原文{{input}}这段配置表达了两层含义P0 客服场景宁可降级到人工入口也不能让用户得不到任何响应P1 摘要场景可以接受简化生成但保留核心功能。策略中的 fallback_order 从左到右依次尝试实际字段名以网关实现为准。6.2 调用侧处理降级结果的 Java 示例应用侧调用 LLM 网关时并不需要知道网关内部选择了什么降级方案只需要判断返回结果是否还在可接受范围内。以下是一个最小示例// 文件路径src/main/java/com/example/gateway/client/LlmGatewayClient.java public class LlmGatewayClient { private final RestTemplate restTemplate; private final String gatewayUrl; public LlmGatewayClient(RestTemplate restTemplate, String gatewayUrl) { this.restTemplate restTemplate; this.gatewayUrl gatewayUrl; } public LlmResponse call(String scene, String prompt) { LlmRequest request new LlmRequest(); request.setScene(scene); request.setPrompt(prompt); request.setRequestId(UUID.randomUUID().toString()); request.setTraceEnabled(true); try { ResponseEntityLlmResponse resp restTemplate.postForEntity( gatewayUrl /v1/chat, request, LlmResponse.class ); LlmResponse body resp.getBody(); if (body null || body.isFallback()) { // 网关层返回了降级结果这里由业务决定是否接受 log.warn(llm gateway returned fallback response, scene{}, scene); } return body; } catch (HttpServerErrorException e) { // 网关本身不可用或模型全部失败走业务兜底逻辑 return LlmResponse.businessFallback(AI 服务暂时不可用请稍后重试。); } catch (ResourceAccessException e) { // 网络超时不盲目重试交给上层决定 log.error(llm gateway request timeout, scene{}, scene, e); return LlmResponse.businessFallback(AI 服务超时请稍后重试。); } } }这段代码的关键点在于应用侧永远不直接选择模型只指定场景网关层是否降级、切换到哪个模型由网关决定。这样业务代码保持简单故障决策集中在基础设施层。上层的 LlmResponse 需要包含 isFallback 字段用来告知调用方当前结果并非模型原始输出业务方可以据此决定是否展示。6.3 评测回归脚本示例评测回归是 AI 原生开发里最需要固化下来的工程环节。下面是一个简化版的 Python 评测脚本读评测集、调用网关、计算得分# 文件路径eval/regression_eval.py import json import time import requests EVAL_SET_PATH ./eval_set.json GATEWAY_URL http://localhost:8080/v1/chat def load_eval_set(path): with open(path, r, encodingutf-8) as f: return json.load(f) def call_model(scene, prompt): payload {scene: scene, prompt: prompt, request_id: feval-{time.time()}} resp requests.post(GATEWAY_URL, jsonpayload, timeout30) resp.raise_for_status() return resp.json() def evaluate(case): result call_model(case[scene], case[prompt]) generated result.get(output, ) # 这里的评分函数可以替换为人工评分、LLM 评分或规则匹配 if case[type] contains: return float(any(kw in generated for kw in case[keywords])) if case[type] exact: return float(generated.strip() case[expected].strip()) return 0.0 def main(): cases load_eval_set(EVAL_SET_PATH) scores [evaluate(case) for case in cases] total sum(scores) / len(scores) print(feval score: {total*100:.2f}%) for i, case in enumerate(cases): print(f{i1}. [{case[scene]}] {case[name]}: {scores[i]}) if __name__ __main__: main()对应的评测集文件可以长这样[ { name: 客服摘要包含订单号, scene: customer_summary, type: contains, prompt: 请总结这段客服对话并提取订单号..., keywords: [20240101] }, { name: 意图识别准确, scene: intent_classification, type: exact, prompt: 我想退掉这个订单, expected: 退款意图 } ]评测脚本的运行方式是python eval/regression_eval.py如果输出分数低于上一次基线说明当前提示词或模型变更属于回归应阻止合并。这个最小评测框架可以很快扩展到多维度评分和自动回归任务中。7. 常见问题与排查思路问题现象可能原因排查方式解决方案模型调用偶尔超时未配置超时与重试或超时时间过短查看网关日志和调用链路耗时设置合理超时对限流和5xx采用指数退避重试一个模型故障拖垮所有业务业务直连模型没有统一网关查看模型供应商状态和各服务调用关系引入 LLM 网关统一熔断和降级模型不可用时用户收到负面体验没有降级策略或降级策略只返回报错看错误率和降级命中率指标按业务等级配置多级降级方案成本每个月都在涨没有成本配额所有请求都走大模型按场景统计 token 消耗报表开启模型分级路由和结果缓存设置配额模型升级后效果明显变差没有评测集和回归流程对比升级前后评测分数建立场景评测集升级前跑回归网关配置变更导致线上故障缺少配置管理和灰度发布检查配置变更记录网关配置纳入 Git 管理走灰度发布8. 最佳实践与工程建议8.1 先定义“可接受失败率”再选技术方案引入网关之前先和业务方对齐一个指标哪些场景可以接受降级哪些场景宁可报错也不能降智。这个共识会直接影响网关的熔断阈值和降级策略设计比任何技术选型都重要。8.2 网关配置要有版本管理LLM 网关的路由规则、降级策略、触发阈值都应该像应用代码一样纳入版本管理。每次修改需要走评审记录变更原因。否则模型行为变化时很难判断是模型升级导致的还是网关配置导致的。8.3 令牌和密钥管理要独立不要把所有模型的 API Key 放在业务项目的环境变量里。密钥应统一由网关管理业务侧通过网关的鉴权机制访问。涉及密钥的配置要使用独立的密钥管理系统避免密钥出现在日志和代码仓库中。同时建议用最小权限原则不同业务线只暴露自己需要的模型能力。8.4 模型切换一定要灰度无论是切换模型供应商还是升级模型版本都不要一次性切全量流量。建议先切 5% 到 10% 的流量观察评测分数、用户反馈、错误率和成本变化确认稳定后再逐步放量。这里评测集和网关配置灰度发布缺一不可。8.5 监控指标要覆盖到模型层传统监控主要看 QPS、成功率、延迟。AI 场景下至少还要增加token 消耗总量和分场景消耗。模型路由命中分布即每个模型承接了多少请求。降级命中率即多少请求走了降级策略。平均生成耗时即首 token 延迟和总生成时长。这些指标直接反映模型这个外部依赖的健康状况也是故障取舍是否奏效的证据。9. 总结与后续学习方向AI 原生开发对团队的重排不是说要把团队切成“用 AI 的”和“不用 AI 的”而是要把围绕模型的质量定义、评测回归、网关治理这些新任务固化到组织结构里。LLM 网关在其中承担的是“基础设施承重墙”的角色它把模型不可靠、成本不可控、调用分散这些老问题集中到一层解决让业务团队只需要关心场景本身。如果你想在一周内落地一个最小闭环可以按这个顺序做先选一个核心场景定义它的降级策略再搭一个最简单的统一入口把直连模型的调用收敛起来最后写几条评测用例跑一次回归脚本。不要把战线拉得太长先让团队看到“模型故障时系统依然可控”这个效果比任何架构设计都更有说服力。值得继续深入的方向包括模型评测框架的设计与自动化、多供应商模型路由策略、token 成本建模与配额治理以及网关层如何处理流式输出下的熔断与降级。这些都是 AI 原生开发走向成熟阶段绕不开的工程细节也是 LLM 网关真正发挥价值的地方。