什么是 AI 系统设计项目?
AI 系统设计是由 Outcome School 创始人 Amit Shekhar 维护的开源学习指南。它讲解如何围绕大型语言模型设计完整系统,而不是将 AI 产品视为一次简单的模型 API 调用。
该指南将数据库、缓存、队列、负载均衡器和网关等常见系统设计组件,与 GPU、令牌、长时间运行的请求、流式输出、非确定性行为以及按请求计费的模型成本等 AI 特有约束联系起来。
AI 系统设计就是常规系统设计,加上 AI 模型带来的新型运维约束。
本资料面向 AI 工程师、LLM 工程师、后端工程师、机器学习工程师、平台工程师、架构师、学生,以及任何准备 AI 系统设计面试的人员。
为什么 AI 系统设计很重要
在脚本中调用 LLM API 可能只需要几行代码,但为大量用户运营这项功能则是另一类问题。生产系统必须在处理长提示词和逐令牌响应的同时,控制延迟、吞吐量、可靠性、隐私、输出质量和成本。
例如,一个生产环境中的客户支持助手可能需要:
- 即使流量增加,也能快速开始响应。
- 通过检索让回答以公司文档为依据。
- 防止私密信息泄露。
- 处理模型故障、超时和速率限制。
- 尽管输出具有非确定性,仍能衡量回答质量。
- 将令牌和基础设施成本控制在既定预算内。
该仓库整理了解决这些问题所需的构建模块,并将许多主题链接到更深入的相关文章。
核心主题与功能
推理基础
指南从令牌、推理服务器、推理引擎以及 GPU、TPU 和 LPU 等 AI 硬件开始。它解释了 LLM 如何自回归地生成文本:先预测一个令牌,再利用该输出预测下一个令牌。
指南还介绍了推理的两个主要阶段:
- Prefill(预填充):处理输入提示词,并构建生成所需的内部状态。
- Decode(解码):逐个令牌生成响应。
这些阶段会影响首令牌时间、每秒令牌数、吞吐量和基础设施选型。指南还涵盖分块预填充,以及将预填充和解码工作负载分离。
扩展、路由与缓存
扩展部分涵盖垂直扩展、水平扩展、张量并行、流水线并行、自动扩展、GPU 估算和成本估算。LLM 特有的负载均衡方法包括最少未完成令牌数、前缀感知路由和会话粘滞。
缓存部分区分了多个层次:
- KV 缓存:在生成过程中复用注意力的键和值。
- 提示词缓存:缓存重复的提示词前缀。
- 语义缓存:缓存含义相似的查询结果。
- 嵌入缓存:避免重复计算嵌入。
指南还介绍了模型路由,包括基于规则、分类器、嵌入、LLM 和级联的路由方法。
检索与上下文管理
指南讲解嵌入、向量数据库、向量索引和检索增强生成,通常称为 RAG。其检索流程包括文档解析、数据摄取、分块、混合搜索、HyDE 查询转换、重排序、ColBERT、Agentic RAG、GraphRAG 和无向量 RAG。
指南还通过截断、摘要、滑动窗口、压缩和分层记忆来应对上下文窗口限制。相关概念包括上下文腐化、信息埋没中间位置行为、RoPE 衰减和上下文工程。
智能体与多智能体系统
智能体部分研究 AI 智能体的核心组成、端到端智能体循环、工具调用、结构化输出、记忆和常见故障模式。同时,它还区分了确定性的 AI 编排与更具自主性的智能体行为。
其他主题包括模型上下文协议(MCP)、Agent Skills、计算机使用智能体、浏览器智能体、循环工程、图工程、子智能体、协调模式和 Agent2Agent 协议。
生产环境运维
该仓库不仅关注模型调用,还涵盖以下生产环境问题:
- 通过 Server-Sent Events 或 WebSockets 实现流式传输。
- 通过异步处理和消息队列处理长时间任务。
- 基于请求数、令牌数、并发数或成本设置速率限制。
- AI 网关和多租户架构。
- 防护措施、提示词注入防御和 AI 红队测试。
- PII 脱敏、数据驻留、审计日志和合规条款。
- 追踪、可观测性、评估和 LLM-as-a-judge 工作流。
- 超时、带退避的重试、备用模型和优雅降级。
指南还涵盖量化、连续批处理、推测解码、Flash Attention、专家混合、模型蒸馏和分组查询注意力等推理优化技术。
安装与设置
该仓库是学习指南,而不是软件库,因此无需安装软件包、API 密钥或运行时环境。你可以直接在 GitHub 上阅读。
如需保留本地副本,可以使用 Git 克隆仓库:
git clone https://github.com/amitshekhariitbhu/ai-system-design.git
cd ai-system-design
在 Markdown 查看器或能够渲染 Markdown 的编辑器中打开 README。由于指南会持续扩充,请定期更新本地副本:
git pull
README 中未描述构建命令。主要的准备工作是选择学习路径,并使用目录在不同概念之间导航。
如何使用本指南
选项 1:按照完整学习路径进行学习
如果你刚开始接触 AI 系统设计,请按顺序阅读本指南。建议的概念学习顺序如下:
- 学习 token、推理服务器和 AI 硬件。
- 理解 prefill、decode、延迟和吞吐量。
- 学习扩展、估算和负载均衡。
- 比较缓存和模型路由策略。
- 学习嵌入、向量数据库和 RAG。
- 学习上下文窗口管理。
- 探索流式传输、队列、速率限制和网关。
- 学习智能体、工具、MCP、结构化输出和记忆。
- 继续学习多智能体、多模态和语音系统。
- 加入防护措施、隐私、可观测性和评估。
- 学习成本控制、微调基础设施和推理优化。
- 应用本仓库的系统设计问题解决框架。
选项 2:准备面试
准备面试时,可以先阅读关于解决任何 AI 系统设计问题的章节。然后重新学习每个设计决策所需的技术基础。该框架包含八个阶段:
- 需求:确定用户、规模、延迟目标、隐私需求和约束条件。
- AI 目标:定义模型必须完成的任务。
- 数据准备:确定源数据如何收集、解析、清理和建立索引。
- 架构设计:安排网关、服务、模型、检索、缓存、队列和存储的位置。
- 模型选择与提示:根据质量、延迟和成本选择模型及提示策略。
- 评估:定义如何衡量输出和系统行为。
- 部署与服务:规划推理、扩展、流式传输和弹性能力。
- 监控:观察质量、延迟、错误、token 消耗和成本。
选项 3:作为参考使用
如果你已经在构建 AI 应用,可以将目录作为参考。例如,在减少重复计算时查阅缓存章节,在检索质量较弱时查阅 RAG 章节,或者在系统从技术上能够运行但答案质量不明确时查阅可观测性和评估章节。
基础使用示例:设计支持助手
该仓库不是可执行框架,因此“使用”是指将其中的概念应用到设计问题中。以一个必须根据公司私有文档回答问题的客户支持助手为例。
1. 定义需求
在选择模型之前,先写下功能和运行需求:
使用场景:客户支持问答
知识来源:私有产品和政策文档
响应模式:流式文本
质量要求:答案必须以检索到的文档为依据
安全要求:不得泄露私有数据
运行目标:低延迟、可控成本、容错能力
在有实际测量数据时,补充预期流量、提示长度、输出长度、峰值并发量和可接受延迟。这些数值会影响 token、GPU、吞吐量和成本估算。
2. 描绘请求路径
使用本指南中的构建模块组装出的高层设计可以表示为:
客户端
-> AI 网关
-> 身份验证和速率限制
-> 输入防护和 PII 处理
-> 检索流水线
-> 查询嵌入
-> 向量或混合搜索
-> 重排序
-> 提示构建
-> 模型路由器或推理服务器
-> 输出验证和防护
-> 流式响应
-> 链路追踪、评估和成本监控
这是设计工作表,而不是仓库提供的代码。每个组件都对应指南涵盖的一个主题。
3. 设计检索流水线
解析并导入源文档,将其划分为合适的文本块,创建嵌入,并存储可搜索的表示形式。在查询时,检索相关文本块;当仅依靠向量相似度无法提供足够相关的结果时,可以考虑混合搜索或重排序。
将最终上下文控制在模型的上下文窗口内。当检索材料、对话历史和指令争夺有限空间时,本指南中的上下文管理策略可以提供帮助。
4. 规划延迟和流式传输
将首 token 延迟与生成速度分开测量。Prefill 会影响生成开始的速度,而 decode 会影响后续 token 到达的速度。通过 SSE 或 WebSockets 进行流式传输,可以改善用户感知的响应速度,而不会减少底层模型的计算量。
5. 增加可靠性和安全性
使用超时、带退避的重试、备用模型、优雅降级和输出验证。在模型周围设置输入和输出防护,防范提示注入,在需要时对 PII 进行脱敏,并保留适当的审计日志。
6. 进行评估和观测
追踪完整请求,而不是只监控模型调用。本指南中有用的维度包括延迟、吞吐量、token 使用量、成本、检索行为、模型输出质量、工具执行和智能体行为。由于 LLM 输出具有非确定性,评估不能只依赖传统的精确匹配单元测试。
进阶技巧
优化正确的延迟阶段
不要把模型延迟视为一个单一数字。应诊断瓶颈究竟来自预填充、解码、检索、排队,还是外部工具。首个令牌时间和每秒令牌数代表不同的用户体验,可能需要采用不同的优化方式。
路由请求,而不是所有任务都使用同一个模型
本指南介绍了多种模型路由策略。生产环境的设计可以先对请求进行分类,将较简单的任务交给成本更低的模型,同时为困难场景保留能力更强的模型。当前一个响应不够充分时,级联路由可以继续升级到更强的模型。
在正确的层级应用缓存
KV 缓存、提示词缓存、语义缓存和嵌入缓存解决的是不同问题。首先确定重复的内容是什么:生成状态、提示词前缀、语义等价的问题,还是嵌入计算。然后选择匹配的缓存,并考虑正确性、新鲜度、隐私和租户边界。
将检索质量视为一条流水线
RAG 的质量并不只取决于向量数据库。解析、分块、嵌入、查询转换、混合搜索、重排序和上下文组装都会影响最终答案。在归咎于语言模型之前,应先评估检索流程中的中间结果。
仅在工作流确实需要时使用智能体
应区分可预测的编排与能够动态选择工具或操作的智能体。本指南还指出,MCP 对标准化工具和上下文集成很有帮助,但对于简单工作流来说可能过于复杂。选择能够满足需求的最简单方案。
尽早估算令牌、GPU 和成本
粗略估算可以在实施前暴露成本高昂的假设。估算每次请求的输入和输出令牌数、请求量、并发数、吞吐量要求以及预期模型成本。请记住,英文文本平均每个令牌约包含四个字符,但实际分词结果取决于模型的分词器。
用自己的话解释每个主题
README 建议将每个已完成的章节讲解给其他人。进一步的做法是记录每项架构选择背后的权衡:为什么需要队列,为什么某种缓存有帮助,为什么可以接受备用模型,以及该选择如何影响质量、延迟、安全性或成本。
建议的练习计划
- 阅读指南中的一个主要章节。
- 不看原文,概括其目的和权衡。
- 将该组件加入示例架构。
- 为该组件定义至少一个指标。
- 描述一种故障模式和一种缓解措施。
- 当概览内容不足时,阅读链接的深度文章。
- 结合代码助手或实时语音智能体等案例研究,重复这一练习。
这种方法可以将仓库从参考资料列表转变为实用的设计课程。
结论
AI System Design 为读者提供了一条内容广泛且适合初学者的学习路径,涵盖从 LLM 推理基础到 RAG、智能体、安全性、评估、可观测性、容错和成本优化等生产环境问题。它不是一个可安装的软件包,而是一份用于理解 AI 组件如何协同工作的结构化指南。
如果你是初学者,请从基础开始;如果你正在准备面试,也可以从八步设计框架开始。无论采用哪种方式,都应将每个概念应用到具体系统中,衡量其影响,并记录决策背后的权衡。
