适用读者：做模型应用、却在容量/带宽/延迟上"凭感觉"的开发者；要从"会用框架"进阶到"能判断方案是否可行"的人。
前置：S23-J01–J04（本系列的入门四篇）、S20（模型机制）。
覆盖旧文：A-4333（前言，79 点）+ A-4334 §1.1（AI Infra 为什么重要，53 点）→ 132 点。
扩展点：E-S23-012（"搬什么/搬多少/搬几次/经过哪里/谁必须等"五问法）、E-S23-013（跨层配合：算法↔Infra↔数据）。
下一篇：S23-J06 · 关键数字：容量、算力、带宽、延迟。
补编说明：本篇起 S23 从"单卡综述"扩容为"教材级系列"，素材是 12 章 AI Infra 教材（id 4333–4345，约 70 万字）。原 A-1988 的六方向综述（J01–J04、A01）作为入门导读层保留，教材各章作为细讲层，两者不重复：综述回答"有哪些方向"，教材回答"每个量怎么算"。
1. 一句话结论
AI Infra 不是"机房的事"，而是"你的应用要付的账"：选多大的模型、留多长的上下文、允许多少并发、放本地还是云端——每个决定都会改变系统要完成的工作量。懂 Infra 的人能在写代码前算清这笔账；不懂的人只能上线后被账单和延迟教育。
出处：AI Infra 教材前言（
id 4333）。原文的类比：多数软件工程师不开发操作系统、编译器和芯片，但仍要学操作系统、编译原理、体系结构——因为要理解抽象背后的代价。
| 你以为在选择 | 实际在决定 |
|---|---|
| 用 70B 还是 7B | 权重显存、每 token 的读取量、几张卡 |
| 上下文留 4k 还是 128k | KV 缓存大小、并发上限、Attention 计算量 |
| 并发 8 还是 800 | 权重读取能否被分摊、延迟与吞吐的取舍 |
| 本地跑还是调 API | 一次交互的端到端时间与每千次调用的成本 |
2. 编程抽象上移：模型成了"操作系统"（E-S23-013）
原文的核心判断：
编程抽象从操作系统到模型上下文的迁移，是计算机系统领域数十年来最重要的变化之一。 模型成了 LLM 时代的操作系统，AI Infra 成了 LLM 时代的计算机体系结构。
这句话不是修辞，它对应三个具体变化：
| 传统系统 | LLM 系统 | 变化后果 |
|---|---|---|
| 编译器为"未知程序"生成通用代码 | 算子可为特定模型与特定加速器定制 | 跨层联合优化空间打开（第 5 章） |
| 缓存策略由硬件统一决定 | 模型同时产生权重、激活、KV、专家输入多种访问模式 | 一套自动缓存策略覆盖不了，需要分块/融合/流水（第 5 章） |
| 内存由 OS 管理 | 状态显式放在显存/内存池，需要自己算容量 | 容量成为一等约束（第 1、2 章） |
跨层配合的现实例子（原文举的模型设计）：模型结构里直接考虑 Infra 效率——把局部窗口、上下文压缩、稀疏选择结合起来，减少长上下文需要保存的状态与反复读取的数据；用非对称编码器—解码器架构，针对"输入多、输出少"的 Agent 负载重新分配计算。
判据：看到一个模型结构时，能说出"它要求加速器做哪些工作"；看到一张卡的规格时，能判断"怎样改模型或执行方式才用得上"。两个方向都能答，才算跨层理解。
3. 方法论：从约束推导设计（E-S23-012）
原文反复强调的方法只有一句：先列约束，再谈方案。
1) 明确任务与质量要求（多长上下文、多少并发、什么延迟）
2) 列计算量 F、读写量 R、需要驻留的容量 M
3) 检查容量：M ≤ 显存可行容量？
4) 检查带宽：R / β 是否成为瓶颈？
5) 检查算力：F / Π 是否成为瓶颈？
6) 检查依赖：哪些等待无法重叠（串行、通信往返）？
7) 最后才讨论分工：模型怎么切、状态放哪、执行怎么排
3.1 五个必须回答的问题
原文把全书线索归纳成五个问题——它们同时也是排查任何"为什么慢/为什么贵"的清单：
| 问题 | 落到哪一层 | 典型手段 |
|---|---|---|
| 搬什么 | 权重 / 激活 / KV / 专家输入 | 减少要搬的数据（量化、稀疏） |
| 搬多少 | 字节数与精度 | 低位宽、压缩 |
| 搬几次 | 复用次数（batch、缓存） | 批处理、KV 复用 |
| 经过哪里 | 片内缓冲 / 显存 / 卡间 / 网络 | 分块、融合、就近放置 |
| 谁必须等它 | 依赖链与串行步骤 | 重叠、流水、异步 |
判据：任何一个性能问题，如果五问答不出来，说明你还在猜。
3.2 为什么"估算"必须自己做
原文给了一个很实在的观察：AI 也会算错这笔账——能列公式、给出看似精确的数字，却漏掉决定结果的基本约束：
| 常见漏项 | 后果 |
|---|---|
| 只算权重读取，忘了注意力还要读 KV | 低估读取量 |
| 算了读取时间，没检查权重+KV+工作区是否放得进显存 | 方案根本跑不起来 |
| 按峰值算力推速度，没检查带宽能否持续供给 | 高估吞吐数倍 |
| 把工作量平均分给多卡，遗漏卡间通信 | 低估时间 |
| 算出高吞吐，没考虑串行依赖与通信往返 | 低估延迟 |
原文结论：漏掉任何一项，结论都可能偏离几倍甚至几个数量级。
4. 一个真实案例：延迟从 5 秒到 500 毫秒
原文作者做实时语音 Agent 时的经历（2023 年底 → 2024 年）：
| 阶段 | 延迟 | 做了什么 |
|---|---|---|
| 第一个演示 | 约 5 s | — |
| 拆开交互管线 | 2.5 s | 先估算"模型一次推理需要多少计算、读取多少数据" |
| 继续优化 | 1 s | 网络传输、数据库访问逐段压缩 |
| 最终 | 约 500–600 ms | 每段都按"下界"逼近 |
判据：延迟优化不是"换个更快的模型"，而是把整条管线拆成段，逐段算下界，找出离下界最远的那一段。 这与 S23-J03 的 roofline 是同一套思路，只是从"单个 kernel"放大到"整条请求链路"。
5. 本书的结构与本系列的分工
原文的十二章按"理解工作需求 → 认识执行资源 → 组织完整系统"展开：
| 部分 | 章 | 回答什么 | 本系列落点 |
|---|---|---|---|
| 一 模型与负载 | 1–3 | 计算量、数据量、依赖从哪来 | J05–J12 |
| 二 芯片与系统 | 4–7 | 单卡执行 → 多卡协作 | J13–J21 |
| 三 推理与训练系统 | 8–12 | 请求组织、状态管理、训练与部署 | J22–J32 |
不同读者的读法（原文建议）：
| 你是谁 | 重点章 | 遇到问题再回看 |
|---|---|---|
| 模型/应用开发者 | 8、9（推理服务）、11、12（环境与部署） | 4–7（容量、算子、通信） |
| 系统/网络工程师 | 5–7（执行与协作）、9、10 | 1–3（负载怎么来） |
| 芯片/体系结构工程师 | 4–7 | 8–12（硬件指标如何变成服务能力） |
6. 前提与边界
| 结论 | 成立条件 | 不成立时 |
|---|---|---|
| "先算下界再优化" | 下界可算（容量、带宽、算力已知） | 依赖关系复杂（多阶段流水）→ 下界要按关键路径算 |
| 五问法覆盖性能问题 | 问题在"数据搬移"这一层 | 问题在算法/数据质量 → 换方法，不是换硬件 |
| 跨层配合有效 | 团队能同时改模型与系统 | 模型由外部提供 → 只能在部署侧优化 |
7. 常见误区
| 误区 | 纠正 |
|---|---|
| "Infra 是运维的事" | 选模型、定上下文、定并发，都是应用侧在定 Infra 的账 |
| "算力翻倍就快一倍" | 带宽瓶颈时，算力翻倍几乎无效（J07 会算给你看） |
| "估算不精确所以没用" | 估算的价值是排除不可能方案，不是给出精确值 |
| "先上线再优化" | 容量/带宽约束是硬约束，上线前不检查会直接跑不起来 |
8. 自测
- 你的服务用的是 70B 还是 7B？换算成"每 token 要读多少 GB"是多少？
- 上下文从 4k 提到 32k，KV 显存涨几倍？并发上限怎么变？
- 用五问法描述你最近一次"接口变慢"：哪一问答不出来？
- 你的团队里，"改模型结构"和"改部署方案"是两拨人吗？跨层配合的接口在哪？
9. 下一篇
S23-J06 · 关键数字 —— Jeff Dean 的 12 项操作耗时、Amdahl 定律、四类资源（容量/算力/带宽/延迟）与 MFU/MBU，以及一张能直接查的 GPU 速查表。