# FDE W7D5 评测题 · LiteLLM 集成与 Build vs Buy ADR > 配套手册：《FDE-W7D5-LiteLLM集成与BuildVsBuyADR-学习手册.html》 > 候选人背景：36 岁，Java + 大数据 + 医疗保险，偏企业 AI 平台与部署交付。 > 题型：L1 基础 / L2 进阶 / L3 深度 / L4 场景，共 13 题。 > 评分：每题满分 5 分（4 档：0 / 2 / 3.5 / 5），折叠区为参考答案，先自答再展开。 --- ## L1 基础（概念清晰、能准确表述） ### Q1. LiteLLM 是什么？它主要解决哪两类问题？ - **考察点**：对 LiteLLM 定位的准确理解（网关 / 统一调用层 + 企业治理层），区分 SDK 与 Proxy 两种形态。 - **评分维度**：① 是否明确"不是模型，是网关"；② 能否说出"统一各家 API 格式"与"企业治理能力"两类价值；③ 是否点出 SDK 与 Proxy 形态差异。
参考答案（点击展开） LiteLLM 是轻量级 LLM 网关 / 统一调用层，本身不产生 token，只转发。解决两类问题：① **统一调用格式**——用一套 OpenAI 兼容接口调 100+ 家模型（SDK 形态即可）；② **企业治理**——虚拟 Key、预算、配额、多租户、项目级成本、管理界面（主要在 Proxy Server 形态提供）。SDK 是代码内调用，Proxy 是独立网关服务，治理能力主要在 Proxy 才有。
### Q2. 什么是虚拟 Key（Virtual Key）？它带来哪些企业价值？ - **考察点**：密钥隔离机制、与厂商 Master Key 的关系、应用场景。 - **评分维度**：① 能否讲清"虚拟 Key 映射真实厂商 Key"；② 是否列出隔离/配额/可吊销/按 Key 拆分；③ 是否点出"不提高模型效果，只是治理手段"。
参考答案（点击展开） 虚拟 Key 是发给业务/用户的"假 Key"，用户用它调 Proxy，Proxy 内部用真实 Master Key 调厂商。价值：密钥隔离（厂商 Key 不落业务侧）、按 Key 计费与配额、按团队/应用发放、随时吊销（泄露只吊销虚拟 Key，不波及厂商 Key）。注意：它是治理手段，不提高模型效果；若所有业务共用一个 Key，就丧失了按 Key 拆分成本与定位问题的价值。
### Q3. 预算（Budget）和配额（RPM/TPM）有什么不同？它们如何构成成本护栏？ - **考察点**：累计/周期概念 vs 瞬时概念的区分，成本护栏的组合使用。 - **评分维度**：① 预算是累计/周期的花费上限；② RPM/TPM 是每分钟请求/Token 的瞬时限速；③ 能否结合"模型白名单"说明三件套护栏。
参考答案（点击展开） 预算是**累计/周期**的花费或 Token 上限（Key/团队/项目级），超限直接拒绝，防失控刷爆月度额度；配额 RPM（每分钟请求数）、TPM（每分钟 Token 数）是**瞬时**限速，防单 Key 打满厂商限速、影响他人。再叠加模型白名单（限制只能用便宜模型），三者构成成本护栏。建议多级预算 + 预算水位告警，避免"默默失败"。
### Q4. ADR（架构决策记录）的标准四段结构是什么？每段回答什么？ - **考察点**：ADR 基本结构，是否理解"记决策理由而非实现细节"。 - **评分维度**：① 四段名称准确；② 每段回答的问题清楚；③ 是否点出"不写实现细节，只写决策与理由"。
参考答案（点击展开） 四段：① **背景 Context**——面临什么问题/约束（业务、合规、团队、时间）；② **决策 Decision**——决定怎么做（一句话结论+范围）；③ **权衡 Options/Trade-offs**——还考虑过哪些、为何没选（体现比较过）；④ **后果 Consequences**——正负影响与后续动作（诚实列负面）。ADR 记"为什么这么选"，不是系统设计文档，不写实现细节。
--- ## L2 进阶（能结合企业/Java 平台场景分析） ### Q5. LiteLLM 的多租户（team/org）与项目级成本（Project Tag）如何支撑企业内部的成本结算（Chargeback）？ - **考察点**：多租户隔离、标签聚合报表、内部结算链路。 - **评分维度**：① 多租户按团队隔离 Key/预算；② 请求带 project 标签、Proxy 落库聚合；③ 能否联系"CFO 可见、内部 Chargeback"的商业价值与伪造风险。
参考答案（点击展开） 多租户用 team/org 维度隔离不同团队（各持 Key、预算、模型权限）；项目级成本给每次请求打 `project` 标签，Proxy 落库后聚合成报表，回答"哪个项目花多少、调什么模型"。这支撑内部 Chargeback：IT 部门能跟业务线算账，CFO 能看到"理赔自动化项目本月花 ¥X"。注意：标签是调用方自传，可被伪造，结算前要做可信来源校验；聚合依赖 Proxy 落库，库故障则数据缺失。
### Q6. Spring AI 如何对接 LiteLLM？请说明分层职责，并指出一个常见的反模式。 - **考察点**：Java 侧集成配置、应用层 vs 网关层职责边界。 - **评分维度**：① base-url 指 Proxy、api-key 填虚拟 Key；② 分层（业务/治理/推理）；③ 反模式：把预算/Key 校验写进业务代码。
参考答案（点击展开） Spring AI 的 OpenAI 兼容客户端，把 `base-url` 指向 LiteLLM Proxy 地址（如 `http://litellm-proxy:4000/v1`），`api-key` 填虚拟 Key，背后是 LiteLLM 还是真 OpenAI 对 Java 代码透明。分层：Java/Spring AI 管业务编排、Prompt、工具调用、重试；LiteLLM 管统一格式、虚拟 Key、预算、多租户、成本；厂商管推理。**反模式**：把预算/Key 校验逻辑写进 Spring AI 业务代码——那是网关该干的，重复实现易不一致，且 Proxy 挂了要在应用层配降级。
### Q7. 做 Build vs Buy（自研 Gateway vs 直接用 LiteLLM）决策时，应按哪些维度评估？为什么"不站队"更重要？ - **考察点**：决策框架思维，而非立场。 - **评分维度**：① 列出维度（速度/定制/维护/合规/治理能力）；② 说明金融场景重点（数据不出网、合规审计、团队能否运维 Python）；③ "不站队、讲过程"的判断。
参考答案（点击展开） 评估维度：启动速度、定制深度、维护成本、可控性/合规、企业治理能力。金融场景重点看：数据不出内网（LiteLLM 可私有部署满足）、特殊合规审计、团队能否运维 Python 网关。"不站队"更重要，因为面试官考的是**决策过程的可辩护性**，不是立场；且"Buy 不用维护"是误区——开源也要跟版本、安全更新、排障。
### Q8. 生产环境部署 LiteLLM Proxy 为什么必须高可用？给出关键部署要点。 - **考察点**：网关单点风险、无状态、数据持久化。 - **评分维度**：① 网关是 AI 流量咽喉、单点挂全瘫；② K8s 多副本 + 无状态 + 水平扩展；③ 数据库独立部署 + 备份；配置与密钥用 Secret。
参考答案（点击展开） Proxy 是所有 AI 流量的咽喉，单点部署一旦挂，全公司 AI 能力停摆，所以必须高可用。要点：K8s 多副本、网关本身**无状态**（便于水平扩展，别把会话状态存本地）、数据库（Postgres）独立部署且有备份（Key/预算/Spend 都在库里）、配置用 yaml、厂商 Key 与库密码放 Secret。日志靠 callback 外推到 Kafka/Datadog。
--- ## L3 深度（能对比、能设计、能写文档） ### Q9. 对比"自研 Gateway（D4）"与"直接用 LiteLLM"，分别适合什么信号？请做一张对比并给出你的倾向判断方法。 - **考察点**：两种路径的深度对比与决策信号识别。 - **评分维度**：① 自研信号（深度定制路由/已有 Java 治理底座/特殊合规/核心能力不愿外包）；② 直接用信号（快速拿治理能力/厂商多切换勤/团队小/需求在能力边界内）；③ 倾向判断：先看是否真有 LiteLLM 解决不了的点。
参考答案（点击展开） 自研适合：深度定制路由（按业务语义的复杂策略 LiteLLM 表达不了）、已有 Java 微服务治理底座不想割裂、特殊合规审计（留痕格式自定义）、核心能力不愿依赖外部。直接用适合：要快速拿到 Key/预算/租户/成本治理能力、模型厂商多切换频繁、团队小交付急、需求在 LiteLLM 能力边界内。倾向判断：先确认"是否真有标准能力解决不了的点"——90% 企业场景 LiteLLM 够用，遇扩展先用 hook/callback，只有卡脖子才评估局部自研。自研要诚实算账（1-2 人月 + 长期维护）。
### Q10. 请手写一份 ADR：是否引入 LiteLLM 作为企业模型网关（W7 保险交付场景）。 - **考察点**：ADR 四段的实际写作能力，约束具体、决策可验证、权衡完整、后果诚实。 - **评分维度**：① 背景含具体约束（时间/团队/合规）；② 决策一句话 + 范围；③ 权衡列出自研与直连并否决理由；④ 后果含正面 + 负面（如引入 Python 运维）。
参考答案（点击展开） ``` ADR-007 引入 LiteLLM 作为企业模型网关 【背景】W7 落地企业 Agent 平台，需统一调多家模型，具备虚拟 Key/预算/多租户/成本结算。 团队以 Java 为主，交付窗口 2 个月，金融客户要求数据不出内网。 【决策】采用 LiteLLM Proxy 作网关层；Spring AI 经 OpenAI 兼容接口对接；厂商 Master Key 存 Secret， 业务侧只持虚拟 Key。 【权衡】- 自研 Gateway：可控高，但要 1-2 人月并实现全套治理，超窗口 → 不选。 - 直连厂商无网关：最简单，但无预算/租户/成本 → 否决。 - 直接用 LiteLLM：开箱治理 + 私有部署满足不出网，不足用 callback 扩展 → 选。 【后果】+ 2 周具备治理能力，Spring AI 零改造接多模型；成本可结算支撑 Chargeback。 - 引入 Python 组件，需建运维与版本跟进能力；遇标准外定制需评估 hook/薄适配。 ```
### Q11. LiteLLM 的成本数据从哪里来？为什么说"项目级成本标签可能被伪造"，这对企业内部结算意味着什么？ - **考察点**：成本数据链路、可信来源、结算可靠性。 - **评分维度**：① Proxy 落库 + Spend 报表；② 标签是调用方自传可被伪造；③ 结算前需可信来源校验（如网关侧按 Key/租户强制打标）。
参考答案（点击展开） 成本数据来自 Proxy 每次调用记录的 token 用量、模型、耗时、Key/团队/项目，落到 Postgres/MySQL 或日志/BI，通过 `/spend` 和 Daily Spend 报表查询。项目标签是**调用方自己传的 metadata**，理论上可被伪造（业务线把成本挂到别的项目）。意味着：内部 Chargeback 不能盲信客户端标签，应在网关侧按虚拟 Key / 租户**强制**归属（Key 属于哪个团队是网关认定的，客户端改不了），客户端标签仅作辅助维度。同时库故障会导致数据缺失，要持久化 + 备份。
--- ## L4 场景（企业 Agent 平台 / 保险实例综合应用） ### Q12. 某保险公司要上线企业 Agent 平台，涉及理赔、核保、客服三条业务线。请用 LiteLLM 设计"多租户 + 预算护栏"方案，并说明 Java 侧（Spring AI）如何接入。 - **考察点**：把 D5 能力落到保险多业务线场景，含租户隔离、预算、接入。 - **评分维度**：① 三业务线建三个租户 team；② 各发虚拟 Key + 各自预算 + 模型白名单；③ 项目标签做 Chargeback；④ Spring AI base-url 指 Proxy、按业务线用不同虚拟 Key。
参考答案（点击展开） 设计：在 LiteLLM 建三个租户 team（claims / underwriting / service），各团队发独立虚拟 Key；每个 Key 设预算（如理赔线月度 $X）与模型白名单（如只准用 gpt-4o-mini，贵模型需审批）；RPM/TPM 限速防单线打满影响其他线；请求带 `project` 标签做成本报表，支撑三条线内部结算。Java 侧：Spring AI 的 `base-url` 统一指向 LiteLLM Proxy，不同业务线微服务用各自虚拟 Key（配置隔离），业务代码只认一个 OpenAI 兼容地址，模型厂商切换对 Java 透明。网关 Proxy 用 K8s 多副本 + 独立库高可用。
### Q13. 场景：你所在的保险科技团队只有 3 人，2 个月交付窗口，但客户要求"按保单类型做自定义路由"（如高额保单走私有模型、普通保单走公有模型）。请你做 Build vs Buy 决策，并写出对应的 ADR 片段。 - **考察点**：约束下的真实决策 + ADR 落地，识别"定制路由"是核心矛盾。 - **评分维度**：① 识别"自定义路由"是 LiteLLM 标准能力边界外的点；② 决策倾向：先用 LiteLLM + 薄路由适配层（而非全自研）；③ ADR 四段完整、背景含 3 人/2 月约束。
参考答案（点击展开） 决策：不全自研 Gateway（3 人/2 月养不起），也不纯用 LiteLLM（标准路由表达不了"按保单金额路由"）。采用 **LiteLLM Proxy + 薄路由适配层**：在 Java 侧（Spring AI 之前）加一层轻路由，按保单类型选不同虚拟 Key（高额→私有模型 Key，普通→公有模型 Key），LiteLLM 仍负责 Key/预算/成本治理。这样治理能力复用开源，只自研"路由那一点"。 ADR 片段： ``` 【背景】3 人团队，2 月窗口，金融客户要求按保单金额自定义路由（高额走私有模型）。 【决策】LiteLLM Proxy 作网关 + Java 侧薄路由层按保单类型选虚拟 Key，不自研全套网关。 【权衡】全自研：超人力；纯 LiteLLM：标准路由无法满足按金额路由 → 加薄适配层折中。 【后果】+ 复用开源治理，2 月可交付；- 路由层需自维护，后续评估并入网关 hook。 ```
--- ## 评分汇总表 | 题号 | 层级 | 主题 | 满分 | 自评 | 考官评 | |------|------|------|------|------|--------| | Q1 | L1 | LiteLLM 定位 | 5 | | | | Q2 | L1 | 虚拟 Key | 5 | | | | Q3 | L1 | 预算 vs 配额 | 5 | | | | Q4 | L1 | ADR 四段 | 5 | | | | Q5 | L2 | 多租户与成本结算 | 5 | | | | Q6 | L2 | Spring AI 集成 | 5 | | | | Q7 | L2 | Build vs Buy 维度 | 5 | | | | Q8 | L2 | 网关高可用 | 5 | | | | Q9 | L3 | 自研 vs 直接用对比 | 5 | | | | Q10 | L3 | 写 ADR 示例 | 5 | | | | Q11 | L3 | 成本数据可信性 | 5 | | | | Q12 | L4 | 保险多租户方案 | 5 | | | | Q13 | L4 | 约束下决策+ADR | 5 | | | **计分**：每题 0 / 2 / 3.5 / 5 四档。总分 65。 - **达标线①（企业能力）**：Q1–Q3、Q5 合计应 ≥ 22/25，能口头讲清虚拟 Key/预算/多租户/成本。 - **达标线②（决策+ADR）**：Q4、Q7、Q9、Q10 合计应 ≥ 17/20，能讲清 Build vs Buy 框架并完整写出 ADR 四段。 - **整体达标**：总分 ≥ 50/65，且两条达标线同时达标，方可进入下一阶段（W7D6 部署交付）。