夜雨聆风但是，要将模型要变成产品，还需要解决很多问题：
模型能不能在有限显存里运行？用户多久看到第一个字？同时来一万个请求会不会崩？一次调用到底花多少钱？模型升级后，原来的机器还能不能继续用？
这些问题不决定模型“聪不聪明”，却决定模型能力能不能送到用户手里，也决定这门生意能不能成立。要解决这些问题，就需要 AI Infra。
模型负责生产智能，Infra 负责把智能变成一种可以稳定、快速、规模化交付的服务。
对于产品经理来说，AI Infra 是很重要的工程：延迟会影响用户体验，吞吐会影响服务容量，显存会影响并发上限，GPU 利用率会影响毛利率。许多看起来像模型问题的产品选择，最后都要回到 Infra。
但是，AI Infra 又确实很难理解，主要有四个原因：
跨度太广：从晶体管、芯片封装、高带宽显存 HBM，一路跨到多卡网络、编译器、Kernel 和在线调度。 过程不可见：真正决定性能的数据移动是看不见的。页面上只出现一句回答，机器内部却在寄存器、片上缓存、HBM 和多张 GPU 之间搬运海量数字。 问题会动态变化：同一个模型，处理长输入的 prefill 阶段可能缺算力，逐个生成 token 的 decode 阶段可能缺带宽。Batch、精度或硬件一变，昨天的结论今天就不一定成立。 名词太多：BF16、SM、Tensor Core、FSDP、TP、PagedAttention 接连出现，大家记住了缩写，却不知道它们分别解决了哪个物理问题。
这篇文章的目标，就是想办法以产品经理的视角，把 AI Infra 讲清楚。全文会跟着一份模型数据走完整条路：它怎样被表示成数字，怎样存进显存，怎样被送到计算单元，为什么一张卡会堵，为什么加卡后又会产生通信，最后怎样影响延迟、并发和成本。
全篇试图解释的矛盾是：计算电路越来越快、越来越多，但数据的存放和搬运受物理限制没有同比例变快。于是昂贵的计算单元经常不是不会算，而是在等数据。
下面我们直接走进机器内部，看真实发生的物理机制。
一、先把模型装进机器：一张 GPU 里面究竟有什么
先把“大模型”三个字放下。对机器来说，模型首先是一张极其巨大的数字表。
所谓参数，就是这张表里的数字。训练的过程，是不断调整这些数字；推理的过程，是把输入和这些数字做一层层矩阵运算。
数字必须占存储空间。计算机用 bit（0 和 1）保存数据，8 个 bit 组成 1 个字节（Byte）。
模型参数通常不是整数，为了同时表示正负以及大小差异极大的数字，计算机会使用浮点格式。可以把浮点数理解为科学计数法的二进制版本：
1 bit 记录正负号； 一部分 bit 记录小数点应该移动多少位（指数）； 剩下的 bit 记录具体数值有多精细（尾数）。
精度格式决定每个参数占多少 bit，并同时影响显存容量、带宽占用、计算速度与模型误差，常见的精度格式有这几种：
FP32 用 32 个 bit 保存一个数，因此一个参数占 4 字节。它记录得细、范围大，代价是占空间，搬运和计算电路也更大。 BF16是用 16 个 bit 保存一个数，因此一个参数占 2 字节。包含 1 bit 符号、8 bit 指数、7 bit 尾数。它保留了和 FP32 相同的指数位数，覆盖相近的数值范围，仅牺牲了部分尾数精细度。
为什么深度学习偏爱 BF16？因为神经网络计算通常能容忍一定的小数精度损失，但不能容忍数值范围不够导致上溢或下溢。BF16 牺牲部分精细度，换取了较大的动态范围，同时把存储和搬运量直接减半。
现在来看一个 70B 模型：70B 表示约 700 亿个参数。如果使用 BF16，每个参数 2 字节，光权重就大约占 140 GB。一张 80 GB 的 GPU 显存，连完整的模型都放不下。
所以 PM 讨论模型部署时，不能只问“多少 B”，必须同时问使用什么精度。
FP8 用 8 bit 保存一个数；4-bit 量化是用约 4 bit 表示一个权重。70B BF16、70B FP8 和 70B 4-bit 需要的显存完全不同，换来的数值误差和硬件要求也不同。
但这只回答了模型容量的问题。为了理解后面的运行机制，我们需要走进 GPU 内部，看数据到底经过哪些物理位置。
从晶体管到计算单元
GPU 芯片是一块硅片，上面刻着海量晶体管。
晶体管本质上是由电压控制的开关。控制端电压变化决定电流能否通过。多个晶体管组合成逻辑门，逻辑门再组合成加法器、乘法器和存储电路。数据（0 和 1）物理上就是电路中稳定的两种高低电压状态。
大模型最核心的计算是矩阵乘法。把文本转换成向量后，每一层都要拿输入矩阵和权重矩阵相乘并累加。
CPU 依靠少量复杂核心，擅长处理逻辑分支多、步骤不一的串行任务。
GPU 选择了另一条路：堆叠大量结构相似的计算单元，让同一种运算同时作用在海量数字上。
GPU 芯片被划分成许多重复的计算区域，NVIDIA 称之为SM（Streaming Multiprocessor，流多处理器）。
把一个 SM 理解为芯片上的一个独立计算核心区。它负责接收一批线程任务、安排它们执行，并提供这批任务所需的计算电路和近端存储。
线程可以理解为一份最小工作单（例如“把矩阵某位置的几个数相乘并累加”）。GPU 会把海量线程分组调度，让许多位置并行计算。
SM 里面既有普通算术单元，也有Tensor Core。Tensor Core 不是独立芯片，而是一组专门为矩阵乘加（A × B + C）设计的专用硬件电路。普通单元一次处理几个标量，而 Tensor Core 一条指令就能完成一个小矩阵块的乘加。专用电路不需要照顾所有通用逻辑，直接把深度学习高频运算做成硬件数据通路，极大地提升了计算效率。
SM 内部还配有寄存器和片上缓存。矩阵数字必须先送到这些近端存储中，计算电路才能读取并执行运算。
精度的降低会直接提升物理效率：一个 BF16 数只有 16 bit，比 FP32 少一半。相同带宽下一次可搬运两倍数量的数据；乘法器电路更小、更省电，相同芯片面积就能布置更多并行乘法器。
FP8、FP4 沿着这个方向继续压缩，但精度越低，数值误差控制难度越大，需要硬件速度与模型质量综合评估。
至此，“算力”可以定义得更具体：它来自芯片上有多少 SM，每个 SM 里有多少计算电路，这些电路每个时钟周期能处理多少数据，以及软件能否持续给它们喂饱数据。
数据离计算电路有多远
GPU 并没有一块既无限大又无限快的存储。原因很物理：存储电路越追求极致速度和直接访问，占用的硅片面积就越大、成本越高；基于尺寸和成本的考量，想把容量做大，就必须采用结构更密集但访问步骤更多的方案。
因此，GPU 将存储设计成多层金字塔结构：
寄存器（Register）：位于 SM 内部，紧贴计算电路。正在参与计算的输入、地址和中间结果放在这里，读取路径极短、速度极快。但容量极其有限，如果每个线程占用过多寄存器，同时驻留在 SM 中的线程数量就会减少。 共享内存（Shared Memory）/ L1 Cache：位于 SM 附近，由片上 SRAM 构成。SRAM 用多个晶体管维持 1 bit 状态，无需刷新，响应极快，但占面积大。L1 Cache 由硬件自动缓存数据，共享内存由程序员显式调度。 L2 Cache：位于 GPU 计算芯片上，由所有 SM 共享。某个 SM 用过的数据若留在 L2，其他 SM 访问时即可避免读取 HBM。 HBM（高带宽显存）：显存的主体，采用 DRAM。DRAM 依靠微小电容里的电荷表示 0 和 1，电荷会泄漏需定期刷新，读取时还需经过内存控制器。DRAM 每 bit 占用面积小、适合做大容量，但延迟较高。 跨机存储：另一张 GPU 的 HBM（走 NVLink/PCIe）；跨机 GPU 的 HBM（走网卡和 InfiniBand/RoCE 网络）；CPU 内存及 SSD。
存储路径总览：寄存器 → 共享内存/L1 → L2 → 本卡 HBM → 另一张 GPU → 跨机网络 → CPU 内存/存储，越靠左，容量越小、访问越快；越靠右，容量越大、路径越长、延迟和能耗越高。
这个物理层级图是 AI Infra 最底层的架构图。FlashAttention 试图让数据在片上 SRAM 停得更久；PagedAttention 减少 HBM 空间浪费；张量并行（TP）和专家并行（EP）则不得不让数据跨卡传输，因而极度依赖高速互联通道。
遇到任何 Infra 新技术，都可以先问三个问题：它减少了哪一段的数据搬运？让哪份数据在近处多停了一会儿？还是为了扩展容量，反而让数据走了更远的路？
HBM 为什么又高又宽
普通内存条（DDR）离 GPU 太远、通道太窄。AI 加速卡采用 HBM，是为了让大容量内存贴近计算芯片，并提供极宽的并行数据通道。
一摞 HBM 由多层 DRAM die 垂直堆叠而成。上下层之间通过 TSV（硅通孔） 连接，即穿透硅片的垂直金属通道，信号可直接上下穿行。
HBM 的“高”解决了容量问题（垂直堆叠），“宽”解决了带宽问题（上千条并行线路同时传输数据）。
这里还需要澄清两个概念：
延迟（Latency）：发出读取请求后，第一批数据多久到达。 带宽（Bandwidth）：传输稳定后，每秒总共能搬运多少数据。
大模型需要连续搬运海量权重，因此带宽通常比单次访问延迟更早成为系统瓶颈。但在多卡频繁同步小结果时，等待每一轮通信开始的延迟又变得至关重要。
2026 年的HBM4 将数据接口扩展到 2048 条连接，单堆栈带宽突破 2.8 TB/s。但接口越密、走线越紧，封装、信号完整性、供电、散热和良率的挑战也呈指数级上升。
算力与带宽的物理失衡
行业里常用一句话总结内存墙：算力是面积游戏，带宽是周长游戏。
计算单元可以铺在二维硅片面积上，面积增大，乘法器和缓存成倍增加；但数据进出计算单元，必须经过芯片边缘的内存接口、走线和控制器，物理边界和接线资源无法像内部计算单元那样无限制扩展。
先进封装正在不断拓宽这个“边界”，但修路的代价是更高的面积占用、功耗和成本。算力与数据供给能力的增长不对称，是贯穿 AI Infra 的根本物理矛盾。
判断工具：算术强度（Arithmetic Intensity）
如何判断一个具体任务到底卡在哪里？引入算术强度：
如果 GPU 的峰值算力为 C（FLOPs/s），显存带宽为 B（Bytes/s），那么比例 C / B 就是该硬件的物理分界线（Roofline 模型）：
任务算术强度 < C / B：属于 带宽瓶颈（Memory-bound），计算单元大量时间在空等数据； 任务算术强度 > C / B：属于 计算瓶颈（Compute-bound），计算单元全速运转，显存带宽有富余。
对 PM 来说，它的价值在于帮你问对问题：现在的慢，是因为计算做不过来（算力不够），还是因为数据送不过来（带宽不够）？如果判断错了，买再多算力也解决不了问题。
二、模型装进去了，用户为什么还在等
通过前面对单卡硬件结构的拆解，我们知道了如何计算模型权重的静态占用。但把模型“静态”装进显存只是第一步。当真实用户请求涌入、模型开始动态跑起来时，数据开始在寄存器、缓存与 HBM 之间剧烈流动，系统的瓶颈会立刻从“能否装下”变成“动态算力与带宽的供给问题”。
单人测试时速度很快，但接入真实流量后，产品上出现了两种“慢”：
有些用户很久才看到第一个字； 另一些用户很快看到开头，但后面一字一字蹦得很慢。
同一个模型，为什么会有两种不同的卡顿？因为推理在物理上天然分为两个阶段。
Prefill 阶段：模型一次性读完 Prompt
用户输入 Prompt 后，模型必须先一次性处理全部输入 Token。这叫Prefill（预填充 / 读题阶段）。
所有的输入 Token 可以并行进入矩阵计算。同一份模型权重从 HBM 搬到片上后，可以同时服务这批 Token，数据复用率极高，算术强度也很高。
Prefill 是标准的计算密集型任务，它直接决定了TTFT（首字延迟，Time to First Token）。上下文越长，Prefill 越重。长上下文不仅意味着读入更多文字，Attention 还要处理呈平方级增长的 Token 关系。
Decode 阶段：逐字生成答案
首字生成后，模型进入Decode（解码 / 逐字作答阶段）。
生成下一个 Token 必须依赖上一个 Token 的输出，这种自回归过程在时间轴上无法并行。在 Batch 较小（如单用户）时，每一步计算量极小，但整套海量模型权重仍然需要从 HBM 完整搬运到计算单元一次。读取了数百 GB 的参数，仅仅为了产生一个 Token。
此时权重复用率极低，算术强度极低。Tensor Core 根本没吃满，HBM 带宽却已经顶格。因此，低 Batch Decode 主要是慢在“读显存”，而不是慢在“算力不足”。
因此，在产品评审中，脱离条件的“每秒多少 Token”没有任何意义。必须追问：输入多长、输出多长、Batch 多大？测的是 Prefill 还是 Decode？是单用户延迟还是整机吞吐？
KV Cache：用显存换时间的必然产物
Decode 时需要关注历史所有 Token。如果每一步都重新计算历史 Token 的表示，开销不可接受。
Transformer 架构将历史 Token 在每一层生成的 Key 和 Value 向量保存下来，下一步直接复用，这就是KV Cache。前面的计算结果被保存下来避免重算，但这些记录本身要一直占用昂贵的显存空间。
KV Cache 显存占用计算公式：
(乘以 2 是因为要同时保存 Key 和 Value)
这个公式解释了几个关键产品现象：
注意力机制演进： 标准多头注意力（MHA）中每个 Query Head 拥有独立的 KV Head； 分组查询注意力（GQA）让一组 Query Head 共享一份 KV Head； 多查询注意力（MQA）让所有 Query Head 共享一份 KV Head。
吞吐与用户体验的博弈
增加 Batch 可以提高权重复用率和系统总吞吐，但请求需要排队凑 Batch，等待时间变长；长 Prompt 的 Prefill 还会抢占算力，导致正在 Decode 的用户遭遇严重卡顿。
线上推理评估必须看综合指标矩阵：
TTFT（Time to First Token）：首字延迟，用户等多久看到第一个字。 ITL（Inter-Token Latency）：Token 输出间隔，文本流式吐出的顺滑度。 吞吐量（Throughput）：整套系统每秒交付的总 Token 数。 并发数（Concurrency）：单卡/单集群同时支持的活请求数。 P95 / P99 延迟：保障最慢 5% 或 1% 用户的服务质量。 单位成本：满足延迟 SLO 前提下，每百万 Token 的成本。
极致追求吞吐会导致单用户体验变差；极致追求低延迟会导致 GPU 算力闲置、成本飙升。
理解了推理时 Prefill 和 Decode 的动态博弈之后，我们再来看另一个常见的业务场景：模型微调与训练。
三、产品要微调模型，为什么显存突然翻了许多倍
在推理场景中，显存的主要矛盾在于“动态 KV Cache 随并发膨胀”。但当业务需要对模型进行定制微调或持续训练时，显存消耗会再次发生质的飞跃。因为推理只需要“只读参数”并记录过程激活，而训练必须在正向和反向传播中“更新参数、计算梯度并保存优化器状态”。
如果直接用推理的账本估算训练显存，项目一定会崩溃。除了模型参数本身，训练过程还要在显存中保存三类东西：
梯度（Gradients）：记录每个参数应该向哪个方向调整。 优化器状态（Optimizer States）：以最常用的 AdamW 为例，为了决定更新步幅，需要保存梯度的“一阶动量”（移动平均）和“二阶动量”（平方移动平均）。混合精度训练中通常还会保留一份 FP32 的主权重。 激活值（Activations）：前向传播在每一层留下的中间结果，反向传播计算梯度时必须用到它们。
在常见配置下，参数 + 梯度 + 优化器状态的显存占用高达14 ~ 16 字节 / 参数（甚至更高）。按此估算，一个 7B 模型的静态模型状态显存就高达近 100 GB ~ 112 GB，这还没算激活值和临时缓冲区。
这就是为什么“十几 GB 的模型文件，训练却需要好几张大显存卡”的原因。
激活值在长上下文中的危险性
激活值占用随 Batch Size、序列长度、层数和隐藏维度线性甚至平方级增长。上下文从 4K 扩展到 32K，激活值显存会呈剧烈爆表。
解决办法是激活检查点（Activation Checkpointing / 重计算）：前向传播时只保留少量关键层的激活值，其余丢弃；反向传播需要时，再重新做一次前向计算补齐。
片上存储放不下半成品时，就先丢弃，需要时重新计算。这体现了典型 AI Infra 的折衷思维：用计算时间换显存空间。
然而，重计算也是有极限的。当单卡用尽了量化、重计算等所有单卡优化手段，显存依然放不下时，堆叠多张 GPU 就成了唯一的选择。
但从这一刻起，系统的核心瓶颈正式从“单卡内部的数据搬运”演变成“跨卡、跨网络的物理通信”。
四、一张卡不够，为什么加卡不能直接线性加速
多张 GPU 在物理上是独立的，各有自己的计算单元和 HBM。单板内、机架内、跨机架的通信通道不同，带宽和延迟有天壤之别。
并行策略必须严格服从物理网络拓扑。拆分模型不是在架构图上画框，而是决定哪些数据在每一层需要跨越哪一段真实物理链路。
1. 数据并行与 FSDP
标准 DDP（分布式数据并行）：每张卡都复制一份完整的模型权重，各自处理不同的数据小批次（Mini-batch），反向传播结束后同步梯度。 核心痛点：每张卡都要保存完整的模型状态，完全不节省模型状态显存。 FSDP（Fully Sharded Data Parallel，全分片数据并行 / ZeRO-3）：将参数、梯度和优化器状态完全切块分摊到各个 GPU 上。 工作机制：平时每张卡只保留自己的分片。计算某一层前，执行 All-Gather（各出碎片，收齐完整参数），临时拼出该层完整权重，算完立即释放；反向传播后执行 Reduce-Scatter（累加梯度并切块），每张卡只保留属于自己的梯度分片。 FSDP 没有让显存需求消失，而是用“动态传输与临时聚合”替代了“静态常驻”，用增加通信的代价换取了显存开销的大幅下降。
2. 张量并行（TP，Tensor Parallelism）
如果模型的单层矩阵太大，连单卡都放不下，就必须把单层权重矩阵拆开到多张 GPU 上。
计算时，各卡只计算矩阵的一部分，随后在层内部进行高频同步（如 All-Reduce）。 物理约束：通信发生在每一个 Transformer 层的内部，频率极高、处于关键路径上。因此，TP 必须放置在带宽最高、延迟最低的高速互联域（如 NVLink / NVSwitch）中。如果跨慢速网络做 TP，整机性能会被通信延迟吞干。
3. 流水线并行（PP，Pipeline Parallelism）
将模型的不同层按深度顺序切分到不同 GPU 组上。第一组卡算前几层，把中间激活值传给下一组；反向传播时沿相反方向传回。
优点：只在流水线阶段交界处传输激活值，通信量小，适合跨节点连接。 缺点：存在 流水线气泡（Pipeline Bubble）——刚开始时后面的卡在空等，快结束时前面的卡已空闲。可以通过微批次（Micro-batch）切分减少气泡比例，但会增加调度复杂度和激活显存。
4. 专家并行（EP，Expert Parallelism）
专为 MoE（混合专家模型）设计。Top-k 路由器将每个 Token 分发给最匹配的 $k$ 个专家，EP 将不同的专家分散在不同的 GPU 上。
工作机制：路由决定 Token 去向后，通过 All-to-All 集合通信将 Token 发送到对应 GPU，计算完后再送回。 物理痛点：若大量 Token 集中选中某几个热门专家，会导致热门 GPU 排队爆满、其余 GPU 闲置，整机速度取决于最慢的热点卡。
混合并行策略（3D / 4D 并行）
实际大模型系统通常混合使用上述策略，原则极其清晰：
模型状态太大 ： 用 FSDP / ZeRO； 单层太宽放不下 ： 用 TP（限定在机架内 / NVLink 高速域）； 模型太深或跨节点 ： 用 PP； MoE 模型： 叠加 EP； 扩大总吞吐 ：外层叠加 DP。
五、针对这些问题，人们提出的四项技术
总结前面的分析，我们发现不管在单卡还是多卡场景下，系统都在频繁遭遇物理级别的“数据堵车”：
单卡算子层：N*N注意力中间矩阵在 SRAM 与 HBM 之间频繁来回搬运，挤爆显存带宽； 内存管理层：动态 KV Cache 预留过大，产生大量显存碎片，挤占并发容量； 在线调度层：长 Prompt Prefill 霸占 GPU，导致 Decode 逐字吐出严重卡顿； 多卡通信层：数据并行广播梯度时，中心节点网络带宽瞬间瘫痪。
业内最著名的四大明星技术，正是针对这四个物理堵车点精准设计的解法。
1. FlashAttention：把数据留在离计算电路最近的地方
标准 Attention 计算公式：
在序列长度为 N 时，S 和 P 是 N*N 的庞大中间矩阵。朴素实现会把计算出的 S 写入 HBM，Softmax 读取 S 写回 P，最后乘 V 时再从 HBM 读取 P。大部分时间都浪费在片上 SRAM 与显存 HBM 之间反复搬运中间矩阵上。
FlashAttention 采用Tiling（分块）与Online Softmax（在线归一化）技术：
将 Q, K, V 切成能装进片上共享内存（SRAM）的小块； 在 SRAM 内部连续完成矩阵乘法、Softmax 局部累加与输出更新，直接吐出最终结果 O 存回 HBM；
2. PagedAttention：把动态 KV Cache 变成固定页管理
传统 KV Cache 必须申请连续显存，为了应对不确定的生成长度，系统不得不预留大量空间，造成严重的内部内存碎片。
vLLM 提出的 PagedAttention 借鉴了操作系统的虚拟内存分页机制：
将 KV Cache 划分为固定大小的 Block（物理块）； 通过 Page Table（页表） 将逻辑上连续的 KV Cache 映射到物理上分散的 Block 中； 支持 Copy-on-Write（写时复制）：多请求共享 System Prompt 前缀时，只需指向同一份物理块，写入个性化内容时才复制。
它极大地消除了显存碎片，使得同一张 GPU 能容纳多倍的并发请求，间接拉高了资源利用率与吞吐。
3. 连续批处理（Continuous Batching）与 Chunked Prefill
连续批处理：传统 Batching 必须等待整批请求全部结束才能翻台。连续批处理在每次 Decode 迭代后重新调度，结束的请求立即释放，新请求随时插入，动态维护 Batch。 Chunked Prefill（分块预填充）：超长 Prompt 的 Prefill 会长时间霸占算力，导致 Decode 请求卡顿。Chunked Prefill 将长 Prompt 拆分成多个 Chunk，在 Token Budget（单次迭代算力预算）内，将 Prefill Chunk 与 Decode 请求混合调度，兼顾了高吞吐与流畅的 ITL。
4. Ring All-Reduce：让梯度沿环高效传递
在朴素的集中式梯度聚合方案中，中心节点容易成为通信瓶颈。若所有 GPU 都将梯度发给单台主节点汇总，主节点网卡会瞬间爆满。
Ring All-Reduce 将 N 张 GPU 连成环状，把大小为 M 的梯度切成 N 份：
Reduce-Scatter 阶段（N-1 轮）：每张卡向顺时针邻居发送一块并累加； All-Gather 阶段（N-1 轮）：将累加好的最终梯度环传给所有卡。
每张卡的总通信量为：
当卡数 N 较多时，传输量趋近于 2M——总传输数据量与卡数无关，完美打通了所有卡的网卡带宽。因此，它对大消息具有较高的带宽利用率。但通信轮次会随卡数增加，并且性能仍然受网络拓扑和消息大小影响。
5. 四项技术的对比
六、为什么极致优化会反过来绑定硬件
了解了上述明星技术的原理解法后，我们会发现像 FlashAttention 这样的优化，本质上是在做一件极其精细的事：重排指令和数据流，让数据在最快的位置停留更久。
但当这种优化做到极致时，它必然会走向与具体硬件架构的深度绑定，因为GPU 并不是一块均匀的“算力”：
每个 SM 的寄存器和共享内存极其有限； Tile 设得过大，寄存器爆掉导致并发下降；Tile 设得过小，数据搬运开销再次显现。
此外，片上共享内存存在Bank Conflict（存储体冲突）、Tensor Core 数据等待、指数计算单元 bottleneck 等物理细节，必须依赖硬件性能计数器逐项调优。
当硬件架构升级（如从 NVIDIA Hopper 跨越到 Blackwell）时，物理瓶颈会再次移动：
Hopper（H100/H200） 引入了 TMA（Tensor Memory Accelerator） 硬件搬运单元、异步 Tensor Core 与 Warp Specialization（分工流水线），催生了 FlashAttention-3； Blackwell（B200/GB200） 的 Tensor Core 算力增长远超 SRAM 带宽，不得不再次重排算子流水线，演进出 FlashAttention-4。
追求通用性能时，代码只需跨平台跑通；追求极致性能时，代码必须是一份针对特定硬件流水线的物理动线图。软硬件高度协同（Co-design）已成为必然。
七、一个懂 Infra 的产品经理，最后会怎样做判断
从底层晶体管一路看到软硬件协同，我们贯通了 AI Infra 的完整物理逻辑。回到最开始的提问：产品经理了解这些，到底如何转化为实际的产品和商业决策？
1. 选型时，不只看效果榜单
同为 70B 模型，Dense 结构每个 Token 走全部网络，MoE 结构只激活部分专家；MHA/GQA/MQA 的 KV Cache 显存相差数倍；BF16/FP8/INT4 对带宽与质量影响迥异；100K 上下文与 8K 上下文对应完全不同的 Prefill 成本。模型能力接近时，架构是否契合目标硬件与流量形状，直接决定产品毛利。
2. 看性能数字时，需要明确被省略的条件
看到“性能提升 3 倍”时，追问：
绝对值是多少？测的是单 Kernel 还是端到端服务？ 基线是弱实现还是强实现？ 在目标规模的真实 Prompt 和流量下是否依然成立？ 输入/输出长度、Batch Size、精度与并行度是多少？ 优化后 TTFT、ITL、P99 和单位 Token 成本如何变化？
3. 容量规划时，从请求形状（Request Shape）出发
规划容量时，只报 QPS 远远不够。100 QPS 下，平均输入 500 token 与 50K token 的 Prefill 负担完全不同；平均输出 20 token 与 2000 token 的 Decode 时间完全不同。
规划容量必须拿到：输入长度分布、输出长度分布、并发峰谷、模型精度和 SLO 目标。
4. 训练与推理的成本是有显著差异的
训练是重型工厂模式：一次运行数周，关键看稳定性、故障恢复与集群扩展效率（MFU/HFU）。 推理是零售餐饮模式：流量实时波动，围绕量化、PagedAttention、Chunked Prefill、推测解码（Speculative Decoding）等手段，看满足 SLO 约束下，每块钱能交付多少 Token。
5. 关注技术进展
内存：HBM4 在进步，但长上下文与高并发增长更快，搬运依旧昂贵。 通信：从单卡扩展到机架（NVLink/NVSwitch），网络拓扑决定多卡能否像一台机器工作。 能源：电力供给、散热（液冷）与数据中心建设周期直接决定算力产能上限。 软件复杂度：极致性能需要跨模型、Kernel、调度与拓扑深度协同，工程复杂度与迭代成本剧增。
最后，让我们再回顾一遍
AI Infra 为什么重要？因为模型能力只有经过 Infra，才能成为用户及时拿得到、公司长期付得起的产品能力。
怎样把 AI Infra 讲明白？不要从名词开始，跟着数据走：它存放在哪里，要搬到哪里，搬一次做多少计算，为什么需要跨卡，哪一段物理链路让所有人等待。
整篇文章可以浓缩为五句话：
内存的问题在于计算能力与数据供给能力增长不对称，远不只是显存容量小。 数据离计算单元越远，容量越大，但访问与搬运成本越高；绝大多数优化都在提升近端数据复用率。 Prefill 阶段属于计算密集型，Decode 阶段属于显存带宽密集型；同一个推理请求内部存在两种不同的资源需求。 标准数据并行不省模型显存；FSDP、TP、PP、EP 用不同方式拆分状态或计算，代价都是通信，且必须服从真实物理拓扑。 FlashAttention、PagedAttention、连续批处理和 Ring All-Reduce，分别从算子、内存、调度和通信层减少 GPU 的无谓等待。
从基础数据结构到集群拓扑，AI Infra 的底层规律始终一致：优化永远围绕着数据的存储与搬运展开——让最昂贵的计算电路减少空等，让计算出来的每一个 Token 都能以更低延时、更低成本送到用户手中。
