FDE W7D4 学习手册 · AI Gateway 自研核心

W7 周级拆解 Day4 · A 级 + B 级（必须掌握 + 架构权衡，面试核心）· 约 4h · 学完能讲清"自研 AI Gateway 的核心模块，以及什么该自研、什么直接用 LiteLLM"

一、AI Gateway 定位（从 W1D4 演进）

1.1 是什么

AI Gateway 是横在"所有 AI 应用"和"所有模型 Provider"之间的统一接入层，对所有 LLM 流量做集中治理：路由、重试、Fallback、成本、Trace、限流。所有应用不直接调厂商 API，而是调 Gateway。

1.2 与 Spring AI（W7D1~D3）的分层

二、Model Adapter / Provider 路由

2.1 路由维度

• 按场景：简单问答→Qwen（便宜），复杂推理→DeepSeek，长文摘要→Claude。
• 按模型健康：某 Provider 报错率高则切到备选。
• 按成本/配额：预算内选贵模型，超预算降级到便宜模型。
• 按用户/业务线：VIP 走强模型，普通走经济模型。

2.2 Model Adapter

每个 Provider 一个 Adapter，把厂商请求/响应规范成 Gateway 内部统一结构（呼应 W1 自研 Adapter）。Gateway 据此做路由，业务无感知。

public interface ModelAdapter {
    ChatResponse chat(ChatRequest req);          // 统一请求/响应
    String provider();                           // qwen/deepseek/claude
    boolean healthy();
}
// 路由：按场景选 adapter
ModelAdapter a = router.select(req.scenario(), req.userTier());
return a.chat(req);

三、超时重试与 Fallback

3.1 重试

• 只重试可重试错误：超时、429 限流、5xx。不重试 4xx 业务错误（如参数错）。
• 指数退避 + 抖动，防重试风暴。
• 重试要带幂等意识：对话重试同 prompt 结果不同，但 Provider 侧重试是安全的（不重复计费逻辑由 Provider 保证）。

3.2 Fallback

主模型持续失败时，切到备选模型（如 DeepSeek 挂了→Qwen），返回结果并标记 `fallback=true` 供上游感知。Fallback 是"降级保可用"的关键。

四、Token 成本统计

4.1 统计什么

• 按 provider / 模型 / 业务线 / 用户 统计 token 与花费。
• 从响应 usage 取真实 prompt/completion tokens（呼应 W4 cost 字段）。
• 实时写入 Kafka → 数仓，做成本分摊与预算告警。

4.2 配额与预算

按业务线设月度预算，超阈值降级或拦截；按用户设日调用上限。这是"AI 成本可控"的核心。

五、Trace Hook

5.1 作用

Gateway 在 HTTP 出口生成/透传 trace_id，记录 model/provider/token/latency/status，和 W7D3 应用层 Advisor 的 trace_id 必须是同一个，形成端到端链路。

5.2 与 W4 / W7D3 衔接

• W4 定义 Trace 字段规范；W7D3 在 Advisor 实现；W7D4 Gateway 在接入层实现——三者同一 trace_id 串联。
• Gateway 记的是"接入层视角"（哪家 Provider、花多少 token、延迟多少）；应用层记"业务视角"（调了哪个工具、哪步慢）。

六、简单限流（维度 / 算法）

6.1 限流维度

6.2 算法

• 令牌桶：允许突发、平滑限流，最常用。
• 漏桶：恒定速率，防突发。
• 滑动窗口：精确计数。

七、与 W1D4 多模型统一接入的演进

八、自研 Gateway 与直接用 LiteLLM 的取舍

8.1 LiteLLM 是什么

LiteLLM 是开源的统一 LLM 网关/SDK，一行配置接入 100+ 模型，自带负载均衡、重试、Fallback、成本追踪、限流。文档见 docs.litellm.ai。它解决的正是 W7D4 大部分模块。

8.2 取舍矩阵

8.3 决策建议

• 中小团队 / 求快：直接用 LiteLLM，省去重复造轮子。
• 强定制 / 内部系统深耦合 / Java 技术栈：在 LiteLLM 思路上自研，或"LiteLLM 做底层 + 自研薄封装接内部治理"。
• 保险 / 金融合规：常需把成本/审计/鉴权接自有系统，自研或深度集成更可控。

九、候选人视角：Java 企业 AI 平台网关能力

• 统一管控：所有 AI 流量经 Gateway，集团多险种/多 Agent 共享统一配额、统一成本视图。
• 合规内建：鉴权、审计留痕、敏感词拦截在 Gateway 做，业务应用零改动获得合规能力。
• 成本运营：按业务线分摊 AI 成本，预算告警，避免"AI 账单失控"。
• 韧性：重试/Fallback 保证理赔等关键链路在模型抖动时不中断。

十、高可用与安全生产实践

• 无状态：Gateway 不存会话（记忆在应用层/Redis），可水平扩展。
• 降级：Gateway 自身依赖（如成本统计的 Kafka）故障时不阻塞主链路，异步+降级。
• 配置热更新：路由/限流规则改了即时生效，不重启。
• 自我保护：Gateway 被打爆时优先保核心业务线（理赔），非核心降级。
• 可观测：Gateway 自身指标（QPS/延迟/错误率）进监控，异常告警。

十一、学习资源（中文 / 官方）

• LiteLLM 文档（docs.litellm.ai）——Proxy 模式（网关）的路由、负载均衡、成本、限流、重试、Fallback 配置。
• LiteLLM GitHub（BerriAI/litellm）——proxy 示例与 OpenTelemetry 集成。
• Spring Cloud Gateway（spring.io/projects/spring-cloud-gateway）——Java 团队做自研网关的基石。
• Spring AI 文档（docs.spring.io/spring-ai）——应用层 ChatClient/Advisor（与 Gateway 分层）。

十二、面试达标线①：AI Gateway 核心模块

十三、面试达标线②：自研 Gateway vs 直接用 LiteLLM 的取舍

1. LiteLLM 能做什么：开箱即用的多模型路由、重试、Fallback、成本追踪、限流、OpenTelemetry Trace——覆盖 W7D4 大部分模块。
2. 什么该用现成：多模型接入、重试/Fallback、基础限流、成本统计这些"通用能力"直接用 LiteLLM/Spring AI，别从零造轮子。
3. 什么该自研：深度定制路由策略、内部系统对接（自有鉴权/审计/工单）、成本分摊到内部账、金融强合规留痕、且团队是 Java 技术栈时——这些"企业独有逻辑"自研或用 LiteLLM 做底层 + 自研薄封装。
4. 决策主线：不是二选一，而是"LiteLLM/Spring AI 当轮子，自研当车体"——保留对核心治理的控制，同时不重复造基础件。

十四、W7D4 自测清单

十五、高频面试题速记卡