系统设计题考的是「把 Demo 变成能上线的服务」的能力。调通一次 API 很容易，难的是几百个用户同时用时：上游限流了怎么办、费用怎么不失控、出了问题怎么查、换了模型怎么知道没变差。
这类题没有标准答案，面试官看的是你能不能主动想到风险、说清取舍。HiveGPT 本身就是一个大模型网关，前面几条路线里你用到的 Key、分组、用量记录、限流报错，都是这一课的实际例子。
题库
如果让你设计一个给公司内部所有团队用的大模型网关，核心模块有哪些？限流怎么做？
- 核心模块：
- 统一接口（如兼容 OpenAI 格式），屏蔽不同供应商的差异；
- 鉴权：每个团队、项目发自己的 Key，上游供应商的密钥集中保管、不下发；
- 路由：按模型名映射到供应商和账号，支持故障转移；
- 计量计费、日志监控、缓存、内容审核。
- 限流：
- 同时限请求数（RPM）和 token 数（TPM），按 Key、团队、模型分层设额度；
- 输出 token 请求前不知道，先按 max_tokens 预占，结束后按实际用量修正；
- 用 Redis 做分布式计数（令牌桶或滑动窗口），长请求还要限并发数；
- 超限返回 429 并带上 Retry-After。
大模型的流式输出（SSE）在网关和后端里要注意什么？用户中途断开连接怎么办？
- 转发：收到一块转一块，关掉反向代理的缓冲（如 Nginx 的
proxy_buffering off），否则用户看到的是一次性输出。 - 超时：首 token 超时和整体超时分开设；长时间无数据时可以发心跳保持连接。
- 用户断开：检测到客户端断开就取消上游请求，避免白白消耗；已生成的部分仍要计费，记录到断开为止的用量。
- 用量：流式下 usage 通常在最后一个事件里（OpenAI 格式需要设置
stream_options.include_usage）。 - 错误处理：开始输出后状态码已经发出，中途出错只能在事件流里发错误事件；也不能再换上游重试，用户已经看到部分内容了。
大模型应用可以在哪些层面做缓存？prompt cache 和语义缓存分别是什么？
- prompt cache（前缀缓存）：由模型供应商实现，请求开头和之前的请求相同时复用已算好的结果，这部分输入更便宜、首 token 更快。所以把系统提示、工具定义、固定文档放前面，变化的用户输入放后面。
- 精确缓存：请求完全相同时直接返回之前的结果，适合确定性的离线任务。
- 语义缓存：问题向量和历史问题足够相似就复用答案。风险是相似但不同的问题被误命中、答错，要设相似度阈值，只缓存通用内容，并带上权限范围和过期时间。
- 另外，Embedding 结果、检索结果也可以缓存。
AI 应用上线后费用涨得很快，你会从哪些方面控制成本？
- 先观测：按用户、功能、模型统计 token 和费用，找到花钱的大头，而不是凭感觉优化。
- 模型分级：简单任务（分类、抽取、改写）用小模型，复杂任务才用大模型或推理模型；推理模型按需调低推理强度。
- 减少输入：精简提示词，多轮对话做摘要，RAG 只放相关的块。
- 控制输出：设合理的 max_tokens，要求简洁的输出格式。
- 用好缓存：调整提示词结构提高 prompt cache 命中率。
- 非实时任务：走批处理接口，通常有折扣。
- 兜底：每个用户设配额，项目设预算告警，防止滥用或程序 bug 刷爆账单。
上游模型服务超时、限流或者宕机时，你的系统怎么保证可用？
- 区分错误：429、5xx、超时可以重试；参数错误、鉴权失败、余额不足重试也没用，直接返回。
- 重试：指数退避加随机抖动，遵守上游的 Retry-After；限制重试次数和总耗时，避免用户等太久。
- 故障转移：切换到备用账号或其他供应商的同等模型；必要时降级到更小的模型，并让调用方知道。
- 熔断：某个账号或供应商连续失败就暂时摘掉、冷却一段时间，避免请求继续打到故障节点、引发雪崩。
- 边界：流式已经开始输出就不再重试；会产生副作用的请求（如发消息的 Agent 步骤）要保证幂等。
大模型应用的可观测性要记录哪些东西？和传统后端相比有什么不同？
- 每次调用：模型、输入和输出 token、首 token 延迟和总延迟、费用、错误码、finish_reason（比如是不是被长度截断）。
- 链路追踪：用 trace 把一次请求里的检索、模型调用、工具调用和 Agent 的每一步串起来，出问题时能还原过程。
- 内容：采样保存输入输出用于排查和评测，注意脱敏和用户隐私。
- 质量信号：用户点赞点踩、重新生成次数、线上抽样评测分数。
- 不同之处：结果不确定，同样的输入可能有不同输出；很多问题不是报错，而是「答得不好」，光看错误率和延迟发现不了，所以要单独监控质量。
换模型或者改提示词之前，你怎么确认效果没有变差？
- 评测集：从真实请求里挑代表性案例，加上边界情况和历史上出过的 bug，标好期望结果。
- 评分方式：能用规则判断的用断言（格式对不对、是否包含关键信息）；开放式回答用 LLM 评分，并定期人工抽检校准；关键场景人工评审。
- 对比：新旧版本在同一评测集上比较质量，同时比较成本和延迟。
- 流程：提示词做版本管理，评测接入 CI，改动先跑回归。
- 上线：灰度或 A/B 测试，监控线上指标，有问题能快速回滚。
- 闭环：线上发现的失败案例持续补进评测集。
一个多租户的 AI 平台，API Key 和数据要怎么设计，才能做到隔离和安全？
- 平台 Key：数据库只存哈希，创建时只显示一次；支持轮换和吊销；可设权限范围（能用哪些模型）、额度和有效期。
- 上游密钥：供应商的 Key 加密存储（或放在 KMS 里），只在服务端使用，不出现在日志和前端。
- 数据隔离：每个请求都带租户身份，数据库查询、向量检索、缓存都按租户过滤，缓存的 key 里要包含租户标识，防止串数据。
- 资源隔离：配额和限流按租户设置，避免一个租户耗尽共享的上游额度，影响其他人。
- 审计：记录谁在什么时候用哪个 Key 做了什么；日志里的敏感内容脱敏。
面向公众的 AI 应用怎么做内容安全？输入和输出两侧分别要做什么？
- 输入侧：用关键词加分类模型审核用户输入；检测提示词注入；限制长度和请求频率，防止批量滥用。
- 输出侧：模型生成后再审核一遍；流式输出可以按句或分段审核，发现问题就中断并替换提示；系统提示限定应用的服务范围。
- 合规：在国内面向公众提供生成式 AI 服务，需要按规定完成备案，并对 AI 生成的内容做标识。
- 运营：保留必要日志，提供举报入口，定期复盘被拦截和漏放的案例。
- 取舍：规则太严会误拦正常请求，影响体验；太松会漏放，要按业务场景平衡，并持续调整。
生成视频、处理长文档这类要跑几分钟的任务，你会怎么设计接口和后台？
- 异步接口：提交后立即返回任务 ID，不让 HTTP 请求一直挂着；客户端轮询状态，或通过 Webhook、SSE 接收进度和结果。
- 后台执行：任务进消息队列，由 worker 消费，按上游额度控制并发。
- 状态持久化：排队、运行中、成功、失败、已取消，存在数据库里，服务重启后能恢复。
- 可靠性：设超时和重试；用幂等键防止重复提交；长任务分段处理，失败时从断点继续。
- 结果：大文件存对象存储，返回链接。
- 体验与计费：显示进度，支持取消；提交时预扣费用，失败后退还。
答题思路
系统设计题时间长、范围大，结构比细节更重要：
- 先结论：先给出整体方案的骨架。「我会把它设计成异步任务：提交返回 ID，队列加 worker 执行，状态存库，结果推送。」
- 再原理：说明为什么这样设计。「几分钟的任务如果用同步请求，连接会被网关超时切断，失败了也无法恢复。」
- 再实践与取舍：逐个展开关键点和代价。「轮询实现简单但有延迟和额外请求，SSE 实时但要维护长连接，我会……」
动手设计前，先花一两句话确认需求和规模：多少用户、多少 QPS、对延迟和成本哪个更敏感。这既能让方案有针对性，也能体现你的工程习惯。
延伸阅读：AI 系统设计面试题总结、大模型网关详解、AI 可观测性与 Trace、LLM/Agent 安全实战。
模拟面试
5 道题从上面的题库随机抽，逐题作答，每题都会得到打分、点评和要点。系统设计题回答要有结构，先给骨架再展开，篇幅有限时优先讲清关键取舍。
🎤 模拟面试每场 5 题，AI 面试官逐题打分点评，总分 = 平均分 × 10
登录后开始模拟面试小结
- 网关的核心是统一接口、鉴权、路由、限流、容错和计量；流式和缓存各有容易踩的坑。
- 成本、可观测、评测发布要形成闭环：先量化，再优化，用评测证明没有变差。
- 回答先确认需求和规模，再按「结论 → 原理 → 实践与取舍」展开。
到这里 D 路线的四课就学完了。四组模拟面试都过 60 分后，到路线页领取结业证书。