AI 系统设计专题
大厂面试越来越爱考「设计一个 XX 大模型系统」，考的是把模型能力变成高可用、低成本、可扩展生产系统的综合能力。本文给出通用方法论与几个高频场景的设计要点。基础应用工程见 LLM 应用开发实战，项目案例见 AI 项目实战案例。
通用方法论：怎么答系统设计题
和传统系统设计一样，先澄清需求 → 估算规模 → 画架构 → 讲权衡 → 谈演进，但要叠加大模型特有的考量：
- 需求澄清：QPS、并发、延迟要求（实时对话 vs 离线批处理）、准确率要求、是否要私有化、预算。
- 大模型特有维度：选什么模型（闭源 API vs 开源自托管）、上下文长度、是否需 RAG/微调、Token 成本、幻觉容忍度、数据合规。
- 架构分层：接入层 → 编排层（Prompt/RAG/Agent）→ 模型层（API 或自托管推理）→ 数据层（向量库/缓存/DB）→ 可观测与安全。
- 非功能性：高可用、限流降级、成本控制、监控、安全（见 大模型安全）。
答题骨架：八段式模板
系统设计题最怕一上来画框图。更稳的顺序是：
| 步骤 | 你要说什么 | 大模型系统里的例子 |
|---|---|---|
| 1. 澄清场景 | 用户是谁，任务是什么，是否实时，是否强合规 | 客服实时问答 vs 离线批量报告生成 |
| 2. 估算规模 | QPS、并发、文档量、上下文长度、预算 | 100 QPS、P95 3s、千万级 chunk |
| 3. 定义指标 | 准确率、召回率、延迟、成本、安全 | Recall@5、Faithfulness、TTFT、单次 token 成本 |
| 4. 画主链路 | 请求如何从用户到模型再返回 | API 网关 → 编排 → RAG/Tool → 模型 → 审核 |
| 5. 讲数据流 | 文档、向量、会话、日志、反馈怎么流动 | 离线索引链路 + 在线查询链路 |
| 6. 讲可靠性 | 超时、重试、降级、限流、熔断 | GPT 限流切 Claude，再切自部署 Qwen |
| 7. 讲评估闭环 | 离线集、线上反馈、bad case 回流 | RAGAS + 人工标注 + 灰度 A/B |
| 8. 讲演进 | MVP 到生产怎么迭代 | 单模型 → 模型网关 → 多模型路由 → 自动评估 |
面试时可以用一句话收束：
这个系统不是“调一次模型”，而是一个有数据链路、模型链路、评估链路和治理链路的生产系统。
大模型系统的通用架构
用户
│
┌─────▼──────┐ 鉴权/限流/路由
│ 接入网关 │
└─────┬──────┘
┌─────▼───────────────────┐ 编排层
│ Prompt / RAG / Agent │── 缓存（语义缓存/前缀缓存）
│ 模型路由（大小模型分级） │
└─────┬───────────────────┘
┌─────▼─────┐ ┌──────────┐ ┌──────────┐
│ 模型服务 │ │ 向量库 │ │ 业务 DB │
│ (vLLM/API)│ │ (Milvus) │ │ │
└───────────┘ └──────────┘
│
监控 / 日志 / 评估 / 护栏（贯穿全链路）高频场景一：高并发大模型推理服务
目标：支撑大量并发请求，低延迟、高吞吐、可控成本。
要点：
- 推理引擎：用 vLLM（PagedAttention + 连续批处理）或 TensorRT-LLM 提吞吐，详见 推理优化。
- 水平扩展：多副本 + 负载均衡；按 GPU 利用率自动扩缩容。
- 流量治理：限流、排队、超时、熔断降级（高峰降级到小模型或缓存答案）。
- 成本优化：模型分级路由（简单请求走小模型）、语义/前缀缓存、限制输出长度、离线走 Batch。
- 关键指标：TTFT、TPOT、吞吐、P99 延迟、GPU 利用率、每千 token 成本。
高频场景二：企业知识库问答（RAG）
目标：基于私有文档的可信问答，带溯源。
要点（详见 AI 项目实战 与 RAG 进阶）：文档接入与解析 → 切分策略 → Embedding/向量库选型 → 混合检索 + Rerank → Prompt 模板与引用 → RAGAS 评估 → 增量更新 → 多租户与权限隔离 → 缓存与成本。
高频场景三：大模型私有化部署
目标：数据不出内网的企业级部署。
要点：
- 模型选型：开源模型（Qwen/DeepSeek/LLaMA）按需求选尺寸，配合量化。
- 硬件：GPU 选型与显存估算，详见 GPU 与硬件。
- 推理框架：vLLM / TGI / SGLang，统一 OpenAI 兼容接口便于迁移。
- 高可用：多机多卡、负载均衡、健康检查、灰度。
- 安全合规：数据隔离、审计日志、内容护栏、权限。
高频场景四：实时/流式对话系统
要点：流式输出（SSE）降低体感延迟、多轮对话的上下文管理（见 记忆系统）、会话隔离、并发连接管理、内容审核在流中处理。Java/Spring 岗位还要说明慢客户端背压、断开取消、done/error/cancel 终态和长任务异步化，见 Java / Spring AI 生产架构系统设计面试题。
五类高频系统设计模板
模板一：企业知识库 RAG
一句话目标：让员工基于企业私有文档提问，答案可信、可溯源、可权限隔离。
文档源
-> 解析清洗：PDF/Word/HTML/表格/OCR
-> 切分入库：chunk + 元数据 + ACL + embedding
-> 查询链路：query rewrite + 权限过滤 + hybrid search + rerank
-> 生成链路：上下文压缩 + 引用溯源 + 拒答 + 安全审核
-> 评估闭环：检索指标 + 生成忠实度 + 用户反馈关键权衡：
- 长上下文 vs RAG：长上下文适合少量材料，RAG 适合海量、更新、权限和溯源。
- 向量检索 vs BM25：向量补语义，BM25 补关键词、代码、术语、编号。
- 召回多 vs 噪声少：Top-K 太小漏资料，太大增加幻觉和 token 成本。
追问准备：
- 文档删除后如何保证用户检索不到旧 chunk？
- 权限过滤是在召回前、召回后还是两者都做？
- RAG 答错时怎么判断是检索错还是生成错？
模板二：Agent 任务执行平台
一句话目标：让模型安全调用工具完成多步骤任务，同时可观测、可回放、可降级。
用户任务
-> 意图分类：问答 / 工作流 / 高危操作
-> 计划生成：结构化 plan，限制最大步数
-> 工具执行：schema 校验、权限、超时、幂等、审计
-> 状态管理：短期状态 + 长期 memory + trace
-> 验证器：规则校验 / LLM Judge / 人工确认
-> 结果返回：自然语言 + 过程摘要 + 风险提示关键权衡：
- Workflow vs Agent：稳定流程用 Workflow，不确定探索才用 Agent。
- 自由规划 vs 受控执行：开放性越强，越要限步数、加验证器和人工确认。
- 记忆越多越好吗：不是。错误记忆会污染未来任务，必须有写入策略和删除能力。
追问准备：
- Agent 死循环怎么防？
- 工具调用参数错、权限错、业务失败分别怎么恢复？
- 高危写操作如何设计 human-in-the-loop？
模板三：模型网关与多模型路由
一句话目标：统一接入多家模型，对业务提供稳定、低成本、可审计的 OpenAI-compatible 接口。
业务应用
-> 虚拟 Key 鉴权 / 租户配额
-> 模型路由：能力、成本、可用性、合规
-> 流量治理：RPM/TPM 限流、排队、重试、熔断
-> 供应商适配：OpenAI / Claude / Qwen / DeepSeek / vLLM
-> 计量计费：token、延迟、错误、降级命中率
-> 审计安全：敏感词、PII、日志留存、数据出境策略详见 模型网关与多模型路由。
关键权衡：
- 业务直连模型最快，但治理能力最差；模型网关多一跳延迟，换来统一治理。
- 成本路由省钱，但要防小模型错误率上升。
- 降级不是简单换 URL：不同模型的 prompt、工具调用格式和安全策略可能不同。
追问准备：
- RPM 和 TPM 为什么都要限？
- 如果主模型 429，重试、排队、降级怎么排序？
- 如何给不同业务线拆 token 成本账单？
模板四：高并发推理平台
一句话目标：用有限 GPU 支撑高吞吐、低延迟、可扩容的模型服务。
请求入口
-> 排队与准入：限流、优先级、batch window
-> 推理引擎：vLLM / SGLang / TensorRT-LLM
-> GPU 调度：模型副本、显存水位、健康检查
-> 性能优化：PagedAttention、连续批处理、量化、KV Cache
-> 观测：TTFT、TPOT、tokens/s、GPU 利用率、OOM、队列等待
-> 降级：小模型、短输出、缓存答案、异步任务关键权衡：
- TTFT 和吞吐常常冲突：batch window 大吞吐高，但首 token 变慢。
- 量化省显存和成本，但要用评估集证明精度可接受。
- 长上下文提升能力，但 KV Cache 成本会随并发快速膨胀。
追问准备：
- Prefill 和 Decode 的瓶颈分别是什么？
- PagedAttention 解决了什么内存问题？
- P95 延迟突然升高，你怎么定位是排队、prefill、decode、网络还是存储？
模板五：AI Coding 平台
一句话目标：让团队安全使用 AI 编程工具，提升交付效率，同时控制代码质量和权限风险。
需求 / Issue
-> Spec 模板：目标、范围、验收、风险
-> 上下文构建：代码索引、规则文件、相关文件、错误日志
-> Agent 执行：生成代码、测试、文档、迁移
-> Review Gate：diff 审查、安全扫描、测试、构建
-> 交付闭环：commit、PR、CI、回滚
-> 知识沉淀：CLAUDE.md / rules / prompt 模板 / 失败案例库关键权衡：
- IDE 工具适合局部补全，CLI Agent 适合长任务和多文件修改。
- 让 AI 自由改全仓很快，但风险高；限定上下文和写入范围更稳定。
- AI 生成测试有用，但不能替代人类定义关键业务断言。
追问准备：
- 如何证明 AI Coding 真提升效率，而不是增加 review 成本？
- AI 改坏核心逻辑时如何快速回滚？
- 团队如何管理项目规则、敏感文件和权限？
系统设计答题加分项
- 主动谈权衡（API vs 自托管、RAG vs 微调、长上下文 vs RAG、效果 vs 成本 vs 延迟）。
- 有量化意识：估算 QPS、显存、Token 成本，而不是只画框。
- 强调评估与迭代闭环：上线不是终点，要建评测集、收集 bad case、持续优化。
- 考虑失败与降级：上游 API 挂了、GPU 不够、被注入攻击时怎么办。
高频追问
Q：设计大模型系统和传统系统设计有什么不同？ 多了大模型特有维度：模型选型（API vs 自托管）、Token 成本、上下文长度、幻觉与评估、RAG/微调的取舍、GPU 资源与推理优化。但「澄清需求→估算→分层架构→讲权衡→谈演进」的方法论一致。
Q：API 调用还是自托管开源模型，怎么选？ API 省心、按量付费、上手快，但有数据合规顾虑、长期高频成本高、受限于供应商；自托管可控、数据不出门、规模化后单位成本低，但要承担 GPU、运维、推理优化。看数据敏感度、规模、团队能力综合定。
Q：怎么设计一个高并发的大模型服务？ vLLM 等高吞吐引擎（PagedAttention+连续批处理）+ 多副本水平扩展 + 限流排队熔断降级 + 模型分级路由 + 语义/前缀缓存 + 全链路监控；关注 TTFT/TPOT/吞吐/P99/成本等指标。
Q：大模型系统怎么控成本？ 模型分级路由（简单任务用小模型）、缓存（语义缓存复用相似问答、前缀缓存复用 system prompt）、Prompt 与上下文精简、限制输出长度、离线任务走 Batch API、自托管时用量化和高吞吐引擎提升单卡产出。
Q：系统设计题怎么答出彩？ 别只画框图，要：澄清需求与规模、给出量化估算（QPS/显存/Token 成本）、主动讲清关键权衡、设计失败降级路径、强调评估与持续迭代闭环。