本文设定一个具体任务：使用 8 张 H100 80GB 部署一个 70B、GQA、BF16 的 Decoder-only 模型，并满足在线聊天业务的延迟目标。我们不会寻找唯一答案，而是展示一套可以复用的决策过程。

图 1：容量规划不是一次显存除法，而是负载、资源、压测、归因和上线门禁构成的闭环。

这里的“容量”不是一个数字，而是一个约束向量：

$$Capacity=(\text{显存},\text{HBM 带宽},\text{计算吞吐},\text{互联},\text{并发},\text{SLO})$$

某个方案可能容纳更多请求，却因为 TPOT 超标而没有更高有效容量；另一个方案可能单请求延迟很低，却因 KV Cache 太小无法承受流量峰值。本文后续所有比较都以 Goodput 为最终尺度，而不是孤立的显存占用或 Tokens/s。

一、需求不能只写“部署 70B”

假设业务提供以下信息：

这些 SLO 只是演示。真实项目应根据交互产品、离线任务或 Agent 工作流重新定义。

还需要补齐：

• 到达率和峰值并发；
• Prompt 长度的完整分布；
• 系统 Prompt 是否大量重复；
• 是否要求多模型或 Multi-LoRA；
• 单机故障时是否允许降级；
• 成本、功耗和可用区约束。

1.1 从到达率估算活跃请求数

容量规划经常直接假设“并发 64”，却没有解释这个数字来自哪里。稳定系统中可以先用 Little’s Law 建立近似：

$$C\approx\lambda\times E[T]$$

$\lambda$ 是每秒到达请求数，$E[T]$ 是请求从进入到完成的平均驻留时间，$C$ 是系统中的平均活跃请求数。例如到达率 8 req/s、平均完成时间 6s，平均活跃请求约为 48。突发流量和长尾会让瞬时值更高，因此还需结合 P95/P99 和排队上限。

把并发与业务流量联系起来后，KV Cache 预算才不只是人为选择的压测参数。

二、第一步：权重能否装下

图 2：部署容量规划只使用右侧推理账本，但量化和并行选择仍要明确权重、KV 与运行时空间的边界。

70B BF16 权重的理论大小约为：

$$70\times10^9\times2\text{ Bytes}\approx140\text{ GB}$$

使用 TP=8 时，理想情况下每张卡约承担 17.5GB 权重。实际还会包含：

• 未均匀切分或复制的参数；
• CUDA Context；
• NCCL Buffer；
• Attention 和 GEMM Workspace；
• CUDA Graph；
• KV Cache；
• 框架分配器保留空间。

因此，权重能装下不是瓶颈终点，而只是说明 TP=8 在容量上可行。

2.1 是否需要 INT8 或 INT4

如果 BF16 已经为 KV Cache 留出足够空间，量化不一定是第一步。Weight-only 量化可能减少 Decode 读取权重的带宽并提高单机容量，但要确认：

• 目标 GPU 和推理框架是否有成熟 Kernel；
• 模型精度是否满足业务要求；
• Prefill 是否因反量化或 Kernel 形状变慢；
• TP 下量化元数据如何切分；
• 长上下文业务的主要瓶颈究竟是权重还是 KV Cache。

技术选型应该由 Benchmark 决定，而不是由“位宽更低”直接决定。

三、第二步：KV Cache 才是并发上限的关键

KV Cache 每 Token 大小为：

$$2LH_{kv}d_hb$$

代入 $L=80$、$H_{kv}=8$、$d_h=128$、BF16 的 $b=2$：

$$2\times80\times8\times128\times2=327680\text{ Bytes}$$

即整个模型每个 Token 约 320 KiB KV Cache。

如果 KV Head 能随 TP=8 均匀切分，每卡约承担八分之一，也就是约 40 KiB/Token。具体布局仍应以引擎和 Attention Backend 的实现为准。

3.1 平均负载和最坏负载不同

若 64 个并发请求平均已经缓存 2500 Token，总 KV Cache 约为：

$$64\times2500\times320\text{ KiB}\approx48.8\text{ GiB}$$

分到 8 张卡约 6.1 GiB/卡，看起来很轻松。

但如果 64 个请求同时接近 16K Prompt，并继续输出 500 Token，总 KV Cache 会超过 300 GiB，单卡分片也可能超过 40 GiB。再考虑权重、Workspace 和运行时空间，容量压力会明显上升。

因此不能用 P50 Prompt 推导最大并发，也不能简单用 P99 长度假设所有请求同时达到最坏值。需要用真实分布做 Trace Replay 或概率模型。

四、第三步：确定并行方式

图 3：本文场景是单机 8 卡，TP 通信位于 NVLink 域；扩展到多机时，应避免把高频 TP Collective 直接放到慢速跨机链路。

单机 8 卡 NVLink 环境下，TP=8 是直观起点：

• 权重均匀分片；
• 层内通信留在高速 NVLink 域；
• 不引入 Pipeline Bubble；
• 一个模型副本可以使用全部 GPU。

但它也有代价：

• 每个 Transformer 层都有 TP 通信；
• 小 Batch 下通信和 Launch 占比可能较高；
• 单个副本占用全部 GPU，故障域较大；
• 扩容粒度是整套 8 卡实例。

如果量化后模型可以用 TP=4，可能在一台 8 卡机器上部署两个副本，以数据并行方式处理不同请求。此时总吞吐、尾延迟和故障隔离可能更好，但单请求可用 KV Cache、单副本最长上下文和量化精度需要重新评估。

所以要比较的不是“TP=4 还是 TP=8 哪个更先进”，而是：

1
2
3

一个 TP=8 大副本
vs
两个 TP=4 小副本

在真实请求分布下，哪个获得更高 Goodput。

五、第四步：配置 KV Cache 与调度器

5.1 gpu_memory_utilization

这个参数决定引擎可以为权重、KV Cache 和运行时使用多少显存。设得太低会限制并发，设得太高则可能在 CUDA Graph、临时 Workspace 或长请求下 OOM。

建议从保守值开始，用压测观察：

• 实际可分配 KV Block 数；
• 峰值显存；
• 抢占次数；
• OOM 和碎片情况。

5.2 max_model_len

如果业务 P99 只有 16K，却把最大序列长度配置为模型理论支持的 128K，可能让引擎为极少出现的请求保留过多规划空间或降低可接纳并发。

更合理的方式是按产品能力设置上限，并为超长请求设计独立队列、限流或专用实例。

5.3 Block Size

• Block 过大：尾块浪费和细粒度调度能力下降；
• Block 过小：块表、哈希和管理开销增加。

不要只测固定长度。不同 Prompt 分布对最佳 Block Size 的偏好可能不同。

六、第五步：哪些功能值得开启

6.1 Prefix Cache

如果大量请求共享系统 Prompt、Few-shot 示例或固定文档前缀，Prefix Cache 可以跳过重复 Prefill，明显降低 TTFT。

如果 Prompt 开头包含随机 ID、时间戳或用户特定内容，Token 前缀很早就分叉，命中率可能很低。此时缓存会占用显存，却没有带来足够收益。

开启前至少统计：

• 可复用前缀长度；
• 请求之间的 Token 级重复率；
• 缓存命中率；
• 命中后节省的 Prefill 时间；
• 缓存块占用和淘汰频率。

6.2 Chunked Prefill

P99 Prompt 达到 16K 时，长 Prefill 很可能干扰正在 Decode 的短请求。Chunked Prefill 可以改善 TPOT 稳定性，但在相同调度预算下可能让长请求 TTFT 增加。

是否开启应由 SLO 决定：

• 聊天业务重视输出流畅度，通常更愿意保护 TPOT；
• 离线批处理只关心吞吐，未必需要同样的切块策略；
• 超长上下文可以进入独立队列，避免污染普通请求。

6.3 CUDA Graph 与 torch.compile

Decode 中 Batch Shape 相对稳定时，CUDA Graph 可以减少 CPU Launch 开销。需要同时评估：

• 捕获 Shape 覆盖范围；
• Graph 额外占用的显存；
• 冷启动时间；
• 动态控制流和调试需求；
• 捕获外算子是否形成新的同步点。

6.4 Speculative Decoding

投机解码使用 Draft 模型或 Self-Draft 结构提出多个候选，再由目标模型并行验证。收益依赖接受率：

• Draft 太弱：候选经常被拒绝；
• Draft 太大：草稿本身开销过高；
• 目标模型 Batch 已经很大：验证收益可能被调度和内存压力抵消。

它更适合作为单独 Benchmark 变量，而不是默认开启。

七、第六步：是否需要 Prefill/Decode 解耦

混合部署时，Prefill 和 Decode 共享 GPU：

• Prefill 偏 Compute Bound；
• Decode 偏 Memory Bound；
• 长 Prefill 会抬高 Decode TPOT；
• 两类阶段的最优 Batch 和并行配置不同。

PD 解耦将它们放在不同 Worker，并通过网络传输 KV Cache。它带来新的成本：

• KV 传输带宽和延迟；
• Worker 比例规划；
• 请求路由；
• 故障恢复；
• KV 一致性和生命周期管理。

只有当混部的相互干扰已经成为主要瓶颈，并且业务规模足以摊销复杂度时，PD 解耦才值得采用。单机 8 卡的第一版系统通常应先把混部调度做好。

八、第七步：设计一套可信 Benchmark

8.1 不要只测固定 Prompt

至少覆盖：

• 短输入、短输出；
• 长输入、短输出；
• 短输入、长输出；
• P99 长上下文；
• 高 Prefix 重复率；
• 无 Prefix 重复；
• 稳态到达和突发流量。

8.2 指标分层

8.3 性能回归门禁

每次修改引擎版本、模型权重、CUDA、Attention Backend 或量化方式后，自动执行相同负载集。门禁不应只限制平均吞吐，还应限制：

• P95/P99 TTFT 和 TPOT；
• 峰值显存；
• 错误率和 OOM；
• 输出正确性或精度回归；
• 长上下文稳定性。

九、常见故障如何定位

9.1 启动时 OOM

优先检查权重精度、TP 数量、最大序列长度、CUDA Graph 捕获和显存利用率，而不是直接降低 Batch。

9.2 运行一段时间后 OOM

重点检查 KV Cache 增长、长请求比例、缓存块占用、抢占策略和请求是否正确释放。

9.3 GPU 利用率低

可能原因包括：

• 请求不足，Batch 太小；
• CPU 调度或 Tokenization 跟不上；
• Kernel Launch Gap；
• TP 通信等待；
• 大量小 Kernel；
• 请求长度差异导致调度低效。

先用 Nsight Systems 区分 GPU 空闲和 GPU 内部低效，再决定是否进入 Nsight Compute。

9.4 吞吐很高但用户仍觉得慢

平均 Tokens/s 可能掩盖排队和尾延迟。检查 P99 TTFT、TPOT 和 Goodput，并按 Prompt 长度和并发分桶。

9.5 NCCL Hang

检查所有 Rank 是否按相同顺序进入集合通信、进程是否异常退出、网卡与拓扑是否正确，然后使用 NCCL_DEBUG=INFO 和 nccl-tests 分离代码与基础设施问题。

十、方案决策链与基线配置

一个完整方案不应该只报参数，而应呈现决策链：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

业务负载和 SLO
       ↓
模型权重与 KV 显存账本
       ↓
TP/副本数/量化选择
       ↓
KV Block 与调度配置
       ↓
Prefix、Chunked Prefill、CUDA Graph
       ↓
真实分布压测
       ↓
Goodput 与成本比较
       ↓
上线后的监控和回归门禁

对于本文场景，一个合理的第一版基线是：

• 使用 BF16、TP=8 建立正确性和性能基线；
• 使用 PagedAttention 和 Continuous Batching；
• 将最大上下文限制在业务真实需要范围；
• 对 16K 长 Prompt 开启或评估 Chunked Prefill；
• Prefix Cache 由实际前缀命中率决定；
• 用真实请求分布寻找 Token Budget 和并发上限；
• 再与量化后 TP=4、双副本方案比较 Goodput；
• 只有混部干扰无法满足 SLO 时，再评估 PD 解耦。

十一、技术 Q&A

Q1：TP=8 后，70B BF16 权重是否严格变成每卡 17.5GB？

17.5GB 只是参数均匀分片的理论值。Embedding、LM Head、Norm、小参数和量化元数据不一定都按同一方式分片；某些实现还会复制参数，或为集合通信准备连续 Buffer。容量规划应先根据引擎的实际分片规则计算下界，再用模型启动后的逐卡显存数据核对分片不均衡和额外状态。

Q2：为什么不能用 P50 Prompt 长度推导最大并发？

KV Cache 随每个活跃请求的实际缓存长度增长。按 P50 规划会在多个长请求同时出现时低估显存；假设所有请求都是 P99 又可能严重过度配置。更合理的方法是回放真实长度与到达 Trace，或按长度分桶建立概率模型，并为极端长请求设置独立队列、并发上限和 Token 配额。

Q3：Weight-only 量化为什么更可能加速 Decode？

Decode 的 Token 维很小，常受每轮读取大体量权重的 HBM 带宽限制。INT8/INT4 减少权重 Bytes，在具备高效融合反量化 Kernel 时可提高算术强度。Prefill 的大 GEMM 更接近 Compute Bound，其收益取决于低精度 Tensor Core、反量化开销和具体 Shape，因此加速比通常不会简单等于权重压缩比。

Q4：何时应引入 Chunked Prefill 或 PD 解耦，压测结果又如何转化为限流配置？

长 Prefill 阻塞 Decode、导致 TPOT 抖动时，可先用 Chunked Prefill 把计算切片；它会以潜在的 TTFT 增长换取更平滑的 Decode。当混部干扰经过统一调度仍无法满足 SLO，且流量规模足以支撑独立 Worker 池时，才值得用 PD 解耦换取阶段级隔离。压测时应找到满足 TTFT/TPOT SLO 的最高稳定到达率，以单副本 Goodput 乘以安全系数和可用副本数得到服务容量，再按 Prompt 长度或估算 Token 工作量实施 Admission Control；当排队时间、KV Block 水位或 P99 越过拐点时，应排队、拒绝或路由到长上下文池，而不是等到 OOM。

十二、系列导航

上一篇：Softmax 数值稳定性与 IO-Aware Attention

回到开篇：大模型训练与推理的显存模型

十三、参考资料

推理系统

• vLLM：高吞吐 LLM Serving 引擎。
• PagedAttention：KV Cache 分页与内存共享。
• Orca：Iteration-level Scheduling。
• SARATHI：Chunked Prefill。
• DistServe：Prefill/Decode 解耦。
• Fast Inference from Transformers via Speculative Decoding：投机解码。

量化与并行

• SmoothQuant：W8A8 激活平滑量化。
• AWQ：Activation-aware Weight Quantization。
• GPTQ：训练后权重量化。
• Megatron-LM：张量并行。

Benchmark 与指标

• NVIDIA NIM LLM Benchmarking Metrics：TTFT、ITL 和吞吐指标。
• MLPerf Inference：标准化推理 Benchmark。
• GenAI-Perf：生成式模型负载测试。
• vLLM Documentation：引擎参数、Serving 和 Benchmark 工具。
• AIInfraGuide：显存估算、推理引擎、并行部署与性能指标的中文资料，MIT License。

Softmax 是最典型的例子：从减最大值、Online Softmax 到 FlashAttention，数学公式没有改变，但数据扫描方式、并行规约方式和 HBM 访问量发生了根本变化。

图 1：标准实现物化完整 Attention Matrix，FlashAttention 让 Tile 在片上完成归一化与输出累加。

一、浮点数同时受精度和范围限制

浮点格式可以粗略拆成符号位、指数位和尾数位：

• 指数位决定能表示的数量级范围；
• 尾数位决定相邻数字之间的精细程度。

FP16 的尾数精度和动态范围都小于 FP32，最大有限值约为 65504。BF16 的尾数更短，但指数范围与 FP32 接近，因此更不容易在大模型训练中发生溢出。

这解释了一个常见现象：BF16 的数值精度不一定高于 FP16，但训练稳定性往往更好，因为它保留了更大的指数范围。

1.1 浮点加法不满足严格结合律

数学上：

$$(a+b)+c=a+(b+c)$$

浮点运算中，舍入可能让两边得到不同结果。GPU 并行规约改变了加法顺序，所以同一个 Reduce Kernel 在不同 Block 划分、不同卡数甚至不同算法下，结果可能不逐位一致。

不逐位一致不等于错误。判断正确性要结合绝对误差、相对误差、数据类型和算法条件数。

二、朴素 Softmax 为什么会溢出

Softmax 定义为：

$$p_i=\frac{e^{x_i}}{\sum_j e^{x_j}}$$

若某个 $x_i$ 很大，exp(x_i) 可能溢出为无穷；如果输入很小，又可能下溢为 0。

2.1 减最大值

令 $m=\max_j x_j$：

$$p_i=\frac{e^{x_i-m}}{\sum_j e^{x_j-m}}$$

因为分子分母同时乘以 $e^{-m}$，结果不变。所有 $x_i-m\leq0$，最大的指数项变成 1，从而避免正向溢出。

这不是经验技巧，而是严格的数学等价变换。

三、Safe Softmax 为什么需要三遍扫描

对一行长度为 $N$ 的输入，常见实现是：

1. 第一遍求最大值 $m$；
2. 第二遍求 $l=\sum_i e^{x_i-m}$；
3. 第三遍输出 $e^{x_i-m}/l$。

即使三遍计算都很简单，也要多次从内存读取同一行。在 GPU 上，Softmax 往往更受访存和规约限制，而不是指数计算本身。

如果一行较短，可以把输入暂存在寄存器或 Shared Memory；如果一行很长，缓存全部输入又会增加资源压力。

四、Online Softmax：维护一个可合并状态

逐个读取元素时，可以维护当前最大值 $m_k$ 和归一化分母 $l_k$：

$$m_{k+1}=\max(m_k,x_{k+1})$$

$$l_{k+1}=l_k e^{m_k-m_{k+1}}+e^{x_{k+1}-m_{k+1}}$$

当遇到更大的元素时，旧的指数和需要乘以 $e^{m_k-m_{k+1}}$，把它重新缩放到新的最大值基准。

4.1 两个局部状态如何合并

假设两段数据分别得到 $(m_a,l_a)$ 和 $(m_b,l_b)$，合并状态为：

$$m=\max(m_a,m_b)$$

$$l=l_a e^{m_a-m}+l_b e^{m_b-m}$$

这个合并操作在精确数学中满足结合律，因此可以在线程、Warp 和 Block 层级做树形规约。浮点实现仍可能因为合并顺序不同产生细微误差。

下面的 Python 实现适合验证合并公式。把一行随机切成多个 Chunk，分别计算状态后反复合并，最终分母应与整行 Safe Softmax 一致：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import math

def online_state(xs):
    m = -math.inf
    l = 0.0
    for x in xs:
        new_m = max(m, x)
        l = l * math.exp(m - new_m) + math.exp(x - new_m)
        m = new_m
    return m, l

def merge_state(a, b):
    ma, la = a
    mb, lb = b
    m = max(ma, mb)
    l = la * math.exp(ma - m) + lb * math.exp(mb - m)
    return m, l

并行实现的关键不是把这个循环原样搬到 GPU，而是让每个线程先处理局部元素，再用 Shuffle 和 Shared Memory 执行同一个 merge_state。

4.2 GPU 上的层级规约

一种典型实现是：

1
2
3
4
5
6
7

每线程处理多个元素并得到局部 (m, l)
             ↓
Warp Shuffle 合并 Warp 内状态
             ↓
Shared Memory 保存各 Warp 结果
             ↓
第一个 Warp 合并 Block 状态

与普通 Sum Reduce 不同，Online Softmax 规约的不是一个标量，而是带缩放规则的二元状态。

五、LayerNorm 与 RMSNorm 的数值问题

LayerNorm 对每个 Token 的隐藏维做归一化：

$$y=\frac{x-\mu}{\sqrt{\sigma^2+\epsilon}}\gamma+\beta$$

RMSNorm 省略均值中心化：

$$y=\frac{x}{\sqrt{\operatorname{mean}(x^2)+\epsilon}}\gamma$$

这些操作包含平方、求和和开方。若直接以低精度累积，大隐藏维下误差可能明显增加。因此常见 Kernel 会：

• 输入和输出使用 BF16/FP16；
• 局部统计量使用 FP32 累积；
• 采用 Welford 等稳定算法计算方差；
• 将 Residual Add、Norm 和类型转换融合，减少 HBM 往返。

算子融合的前提是数值语义明确。改变类型转换位置或规约顺序，可能让融合结果与拆分实现不再逐位一致。

六、混合精度训练为什么需要主权重

混合精度训练常见流程是：

1
2
3
4
5

FP32 主权重
   ↓ 转换
BF16/FP16 前向与反向
   ↓ 梯度
FP32 优化器更新

如果直接用 FP16 权重执行很小的更新，更新量可能因为尾数精度不足被舍入掉。FP32 主权重用于积累这些微小变化。

6.1 Loss Scaling

FP16 梯度可能下溢为 0。将 Loss 乘以缩放因子 $s$，梯度也会乘以 $s$；在 Optimizer Step 前再除以 $s$，可以把小梯度暂时移入 FP16 可表示范围。

动态 Loss Scaling 会在检测到 inf 或 nan 时降低缩放因子，在训练稳定时逐步增加。BF16 因为指数范围更大，通常不需要同样的 Loss Scaling，但仍要监控非有限值。

七、FlashAttention：把 Online Softmax 放进 Attention Tile

图 2：Q、K、V 按片上存储容量切块，每个 Q Tile 通过在线状态依次吸收 K/V Tile 的贡献。

标准 Attention 可以写成：

$$S=QK^T,\quad P=\operatorname{softmax}(S),\quad O=PV$$

如果把完整 $S$ 和 $P$ 写入 HBM，序列长度为 $N$ 时会产生 $O(N^2)$ 的中间数据。

FlashAttention 的核心流程是：

1. 将 Q、K、V 切成可以放入片上存储的 Tile；
2. 计算一个 $QK^T$ 小块；
3. 更新当前行的 Online Softmax 状态；
4. 按新的最大值重新缩放旧输出累加器；
5. 累加当前概率块与 V Tile 的乘积；
6. 不把完整 Attention Matrix 写回 HBM。

用算法状态表示，一个 Q Tile 的处理过程可以写成：

1
2
3
4
5
6
7
8
9
10
11
12

初始化：m = -∞，l = 0，O = 0

for 每个 K/V Tile:
    S_tile = Q_tile @ K_tile^T
    m_new  = max(m, rowmax(S_tile))
    P_tile = exp(S_tile - m_new)
    alpha  = exp(m - m_new)
    l_new  = alpha * l + rowsum(P_tile)
    O      = alpha * O + P_tile @ V_tile
    m, l   = m_new, l_new

最终：O = O / l

这里的 alpha 同时重缩放旧分母和旧输出累加器。只更新 l 而忘记缩放 O，会得到数值稳定但数学错误的 Attention。

对于输出累加器，还需要维护与 Softmax 分母一致的缩放关系。新的 Tile 如果抬高了行最大值，旧输出也要乘以相应缩放因子，然后才能与当前 Tile 的贡献相加。

7.1 为什么它仍是精确 Attention

FlashAttention 没有丢弃 Token，也没有近似概率矩阵。它只是利用 Online Softmax 的可合并状态，改变了计算和数据搬运顺序。因此在浮点误差允许范围内，它计算的是同一个 Attention。

7.2 为什么反向可以重计算

标准实现可能保存巨大的概率矩阵供反向使用。FlashAttention 保存更少的统计量，反向时重新计算局部分数。

这看起来增加了 FLOPs，却减少了更昂贵的 HBM 读写。只要重计算发生在高吞吐矩阵运算中，Wall-clock 时间仍可能更短。

八、V2 为什么继续优化工作划分

FlashAttention-2 没有推翻 V1 的数学核心，主要改进包括：

• 调整 Q 与 K/V 的循环组织，让输出不必反复写回 HBM；
• 减少非矩阵乘法相关的缩放和同步；
• 改变 Warp 之间的工作分配，减少 Shared Memory 通信；
• 对 Causal Mask 的无效块进行跳过。

这说明算法优化不仅要考虑大 O 复杂度，还要考虑硬件上不同指令的吞吐差异。Tensor Core GEMM 很快，并不代表标量指数、同步和数据搬运同样便宜。

九、正确性测试应该怎么做

一个高性能 Kernel 至少需要四类测试：

9.1 参考实现

用 PyTorch 或高精度 CPU 实现作为基准，对比 Forward 和必要的 Gradient。

9.2 极端输入

• 很大的正数；
• 很大的负数；
• 全部相等；
• 一行只有一个元素；
• 非对齐长度和尾块；
• 包含 Mask 的边界情况。

9.3 误差标准

同时报告绝对误差和相对误差。容限应根据 FP32、BF16、FP16 以及累积长度设置，不能用一套阈值覆盖所有情况。

9.4 性能与精度一起记录

只报告速度而不报告误差没有意义。推荐保存：

十、技术 Q&A

Q1：稳定 Softmax 为什么要减去最大值，Online Softmax 又如何合并局部状态？

在 Softmax 的分子和分母中同时乘以 $e^{-m}$ 不会改变结果。选择 $m=\max_i x_i$ 后，所有指数输入都不大于零，从而避免正向溢出。合并两个局部状态时，先取 $m=\max(m_a,m_b)$，再把两段分母重缩放到同一基准：$l=l_ae^{m_a-m}+l_be^{m_b-m}$。局部 $l$ 分别对应不同的指数尺度，不能直接相加。

Q2：合并公式在数学上满足结合律，为什么 GPU 结果仍可能不逐位一致？

公式在实数域等价，但浮点乘加、指数和规约的每一步都会舍入。不同 Warp/Block 划分会改变合并树，因此也会改变舍入误差的累积顺序。正确性测试应使用与 dtype 相匹配的误差容限和高精度参考，不能要求所有并行配置得到相同的 bit pattern。

Q3：FP16 为什么常需要 Loss Scaling，而 BF16 通常不需要？

FP16 的指数位较少，小梯度更容易下溢成零；Loss Scaling 先放大损失和梯度，更新前再按相同比例缩回。BF16 与 FP32 具有相同宽度的指数部分，动态范围大得多，通常不需要用同样方法避免下溢。不过 BF16 的尾数更短，仍然存在明显的舍入误差，因此“通常不需要 Loss Scaling”并不等于“数值精度等同于 FP32”。

Q4：FlashAttention 为什么仍是精确 Attention，重计算增加 FLOPs 又为何可能更快？

FlashAttention 没有稀疏化或截断 Attention，而是使用 Online Softmax 的等价缩放公式合并不同 K/V Tile，数学目标没有改变。它避免把巨大的 Attention Probability 写入 HBM 并再次读回；反向时宁可重算部分局部结果，也不保存这些中间张量。由于 GPU 的矩阵计算吞吐远高于 HBM 的数据供给速率，把低带宽的数据搬运替换为高吞吐计算，即使 FLOPs 增加，总时间仍可能下降。

十一、系列导航

上一篇：分布式训练的通信模型

下一篇：70B 大模型推理服务的容量规划与性能设计

十二、参考资料

数值计算与归一化

• What Every Computer Scientist Should Know About Floating-Point Arithmetic：浮点误差、舍入和异常值的经典介绍。
• Mixed Precision Training：主权重和 Loss Scaling。
• Layer Normalization：LayerNorm 原始论文。
• Root Mean Square Layer Normalization：RMSNorm。
• On Layer Normalization in the Transformer Architecture：Pre-Norm 与 Post-Norm。

Softmax 与 Attention

• Online Normalizer Calculation for Softmax：Online Softmax 状态及合并公式。
• FlashAttention：IO-Aware Exact Attention。
• FlashAttention-2：并行划分和工作分配优化。
• FlashAttention Official Repository：实现、测试和 Benchmark。
• CUDA Warp Shuffle Functions：Warp 级状态交换。
• AIInfraGuide：数学基础、混合精度、Online Softmax 与 FlashAttention 的中文推导和实现资料，MIT License。

本文从 AllReduce 出发，把集合通信、显存分片、模型并行和物理拓扑放进同一个框架。

图 1：高频 TP 通信位于单机 NVLink 域，较低频的数据并行同步跨节点进行。

分析任何并行策略时，可以先写出它的“通信签名”：

1

(参与者，传输对象，通信原语，单次数据量，调用频率，能否与计算重叠)

例如 DDP 的核心签名是“所有数据并行 Rank、梯度、AllReduce、约一个模型梯度大小、每训练 Step 一次并按 Bucket 拆分、可以与反向重叠”；TP 则是“同一 TP Group、层内激活或部分和、AllReduce/AllGather、与当前层 Shape 有关、每层多次、位于关键路径”。

当两个方案的缩写难以比较时，通信签名通常能直接暴露真正差异。

一、先看硬件：通信不是抽象的

同样是 GPU 之间传输数据，不同链路的性能可能相差一个数量级。

1
2
3
4
5
6
7

GPU HBM
  │
  ├─ NVLink / NVSwitch：单机 GPU 高带宽互联
  │
  ├─ PCIe：GPU、CPU 与设备互联
  │
  └─ InfiniBand / RoCE：跨节点网络

实际带宽受 GPU 型号、链路代际、拓扑、NIC、交换机和通信算法影响，不能只看宣传峰值。第一步应该在目标机器执行：

1

nvidia-smi topo -m

然后用 nccl-tests 测量真实 AllReduce、AllGather 和 ReduceScatter 带宽。

1.1 延迟—带宽模型

一次通信可以粗略表示为：

$$T\approx\alpha+\frac{M}{B}$$

$\alpha$ 是启动延迟，$M$ 是数据量，$B$ 是有效带宽。

• 小消息更受启动延迟影响；
• 大消息更受带宽影响；
• 高频层间通信不适合放在慢速跨机链路上；
• 低频大块通信可以通过流水和重叠摊销。

这就是为什么张量并行通常留在 NVLink 域，而数据并行更容易跨节点扩展。

二、集合通信是一组积木

假设有 $N$ 个 Rank，每个 Rank 持有一份或一片张量。

2.1 Broadcast

一个 Rank 把数据复制给所有 Rank，常用于同步配置或初始状态。

2.2 AllReduce

所有 Rank 的数据先做规约，每个 Rank 最终都得到相同完整结果。DDP 使用它同步梯度。

2.3 ReduceScatter

数据先规约，再把结果切成 $N$ 片，每个 Rank 只保留一片。它适合“规约后本来就只需要自己的分片”的场景。

2.4 AllGather

每个 Rank 提供一片，最终所有 Rank 都拿到完整张量。参数分片系统在计算前经常需要它临时恢复完整参数。

2.5 All-to-All

每个 Rank 给其他 Rank 发送不同数据。MoE 中 Token 需要根据 Router 结果发往不同专家，是典型 All-to-All 场景。

最重要的恒等关系是：

$$\operatorname{AllReduce}=\operatorname{ReduceScatter}+\operatorname{AllGather}$$

它既解释了 Ring AllReduce，也解释了 ZeRO/FSDP 为什么可以把规约结果直接保留为分片。

三、Ring AllReduce 为什么常用于大消息

Ring AllReduce 将 Rank 组织成环，分两个阶段：

1. ReduceScatter：每轮传递一个 Chunk，并对收到的数据规约；
2. AllGather：把最终 Chunk 沿环传播，让每个 Rank 恢复完整结果。

若每个 Rank 的张量大小为 $M$ Bytes，则每个 Rank 的总通信量近似为：

$$2\frac{N-1}{N}M$$

当 $N$ 较大时接近 $2M$，通信量不会随 GPU 数量线性爆炸。Ring 的优势是带宽利用率高，代价是通信步骤多；Tree 算法步骤更少，更适合延迟敏感的小消息或大规模节点。

例如 8 张 GPU 同步一个 2GB 梯度张量，每卡传输量约为：

$$2\times\frac{7}{8}\times2\text{ GB}=3.5\text{ GB}$$

若通信路径有效带宽为 350GB/s，仅带宽项理论下界约 10ms；如果跨节点有效带宽只有 40GB/s，则约 87.5ms。这里还没有计入每轮启动延迟、拓扑竞争和协议开销。这个数量级差异足以解释为什么同一并行策略在单机和多机表现完全不同。

NCCL 会结合消息大小和拓扑选择算法，手动强制 Ring 或 Tree 更适合诊断和对比，不应默认当作永久优化项。

四、DDP：每张卡保存完整模型

图 2：每个 Rank 保存相同模型、消费不同 Micro Batch，并在反向传播阶段同步梯度。

数据并行把 Batch 切给不同 Rank：

1
2
3
4
5
6
7
8

相同参数
不同数据
  ↓
各自 Forward / Backward
  ↓
AllReduce 梯度
  ↓
各自执行相同 Optimizer Step

只要初始参数相同、梯度同步正确，各 Rank 更新后的参数仍然一致。

若全局 Batch 均匀切成 $N$ 份，每个 Rank 的局部平均梯度为 $g_r$，那么全局平均梯度为：

$$g=\frac{1}{N}\sum_{r=0}^{N-1}g_r$$

DDP 对梯度执行 AllReduce Sum，再除以 World Size，本质上恢复了单卡全局 Batch 的平均梯度。若各 Rank 有效样本数不相等，例如最后一个 Batch 或过滤后样本数不同，就不能机械地对局部平均梯度再做等权平均，需要按样本数加权。

DDP 的优点是计算路径简单，通信可以通过 Bucket 与反向传播重叠。缺点是每张卡都保存完整的参数、梯度和优化器状态。当模型本身装不下单卡时，单纯增加 DDP Rank 没有帮助。

图 3：朴素实现把反向计算和通信串行化，AllReduce 阶段计算单元处于等待。

图 4：某个 Bucket 的梯度就绪后即可立即发起 AllReduce，与更早层的反向计算重叠。

图 5：Bucket 太小会产生大量启动延迟，太大又会推迟第一次通信，调优目标是最大化计算—通信重叠。

五、FSDP/ZeRO：不再让每张卡保存所有状态

ZeRO 的核心不是一种新的数学训练方法，而是把冗余训练状态分摊到多个 Rank。

FSDP Full Shard 与 ZeRO-3 的核心思想接近：

1
2
3
4
5
6
7
8
9
10
11
12

计算某个 FSDP Unit 前
    AllGather 参数分片
            ↓
       执行 Forward
            ↓
   不再需要时释放完整参数

Backward 时再次 AllGather
            ↓
     计算局部梯度
            ↓
 ReduceScatter 梯度并保留分片

相比 DDP，FSDP 用更多、更细粒度的通信换取显存。Unit 包得太大，峰值显存高；包得太小，集合通信次数和启动开销增加。

六、张量并行：把一次矩阵乘拆到多卡

以线性层 $Y=XW$ 为例，权重可以按列或按行切分。

6.1 Column Parallel

按输出维切分 $W$，每张卡计算一部分输出。Q/K/V 投影和 FFN Up/Gate 常使用这种方式。

6.2 Row Parallel

按输入维切分 $W$，每张卡产生部分和，最后需要 AllReduce 或 ReduceScatter。Attention 输出投影和 FFN Down 常使用这种方式。

Transformer 每层都会执行多次 TP 通信，因此它对带宽和延迟极其敏感。把 TP Group 跨越慢速网络，往往会让 GPU 大量等待通信。

七、流水线并行：把层放到不同 Stage

PP 将模型层切成多个 Stage，Stage 之间传递激活和梯度，而不是频繁恢复同一矩阵的完整结果。

它更适合跨节点，但会产生流水线 Bubble。Micro Batch 越多，Bubble 比例通常越低；同时激活缓存、调度复杂度和端到端延迟也会上升。

GPipe、1F1B 和 Interleaved 1F1B 的差异，本质上是 Forward、Backward 和激活存储的调度方式不同。

八、MoE 与上下文并行

8.1 Expert Parallel

MoE 的 Router 为每个 Token 选择专家。专家分布在不同 Rank 时，需要 All-to-All：先把 Token 发给目标专家，计算完成后再发送回来。

性能风险主要来自：

• Token 路由不均衡；
• All-to-All 对网络拓扑敏感；
• 热门专家过载；
• Padding 或 Capacity 限制造成浪费和丢弃。

8.2 Context Parallel

超长序列训练可以沿 Sequence 维切分。Ring Attention、Ulysses 等方案通过不同通信方式交换 K/V 或中间结果，避免单卡保存全部长序列激活。

九、并行策略应该映射到拓扑

一个常见原则是：

1
2

高频、延迟敏感通信 → 放在单机 NVLink 域
低频、大块通信     → 可以跨机

因此通常：

• TP 优先放单机；
• EP 尽量放高带宽域；
• PP 可以沿节点边界切分；
• DP/FSDP 负责跨副本扩展；
• CP 根据序列长度和网络能力安排。

9.1 两机 16 卡例子

若每台机器 8 张 GPU，设置 TP=8、DP=2：

1
2
3
4

TP Group 0: rank 0-7
TP Group 1: rank 8-15

DP Groups : (0,8), (1,9), ... (7,15)

TP 通信留在各自机器内，DP 梯度同步跨机。若模型层数和延迟允许，也可以使用 TP=4、PP=2、DP=2，让每台机器包含两个 TP Group，并在 Stage 间传递激活。

十、启动和排障同样属于并行设计

分布式代码中必须区分：

• rank：全局进程编号；
• local_rank：当前节点内进程编号；
• world_size：总进程数；
• process_group：参与某类集合通信的 Rank 集合。

一卡一进程时，设备绑定通常使用 local_rank，而不是全局 rank。

遇到 Hang，可以按下面顺序排查：

1. 每个 Rank 是否执行了相同顺序的集合通信；
2. world_size、Rank 和 Rendezvous 参数是否一致；
3. GPU 与 local_rank 是否正确绑定；
4. 网卡和 IB/RoCE 配置是否一致；
5. 是否有某个 Rank 在进入集合通信前异常退出；
6. 开启 NCCL_DEBUG=INFO 检查拓扑和连接信息；
7. 用 nccl-tests 将网络问题与训练代码问题分离。

NCCL_P2P_DISABLE 等开关适合定位问题，不应在没有证据时长期关闭高速路径。

十一、技术 Q&A

Q1：为什么 Ring AllReduce 每卡通信量接近两倍张量大小？

ReduceScatter 阶段每卡进行 $N-1$ 轮、每轮传输 $M/N$，通信量为 $(N-1)M/N$；AllGather 阶段相同，两者相加得到 $2(N-1)M/N$。GPU 数增大时系数趋近 2，但通信轮数和延迟项仍会增加。

Q2：FSDP 为什么用 ReduceScatter 返回梯度？

参数和优化器状态本来就是分片保存的，每个 Rank 最终只需要自己负责的梯度分片。AllReduce 会让每卡都得到完整梯度，随后又丢弃大部分，既浪费显存又多做了 AllGather；ReduceScatter 则在完成规约的同时直接把目标分片留在对应 Rank。

Q3：TP 为什么比 PP 更依赖低延迟、高带宽链路？

TP 在几乎每个 Transformer 层的线性层之间插入集合通信，频率高且直接位于关键路径；PP 主要在 Stage 边界传输激活和梯度，次数与 Stage/Micro Batch 调度相关，通信粒度更大、频率相对较低，也更容易通过流水调度重叠。因此 TP 通常限制在 NVLink 域，而 PP 更适合跨节点扩展。

Q4：如何区分集合通信 Hang 是代码问题还是网络问题？

先确认各 Rank 是否以相同顺序、相同张量形状进入同一 Collective，并检查是否有 Rank 提前异常退出；再用 NCCL_DEBUG=INFO 查看连接和拓扑。若独立 nccl-tests 在相同节点、网卡和数据规模下也失败，应优先排查驱动、IB/RoCE、端口和网络；若测试正常，问题更可能来自程序控制流或 Process Group 使用方式。

十二、系列导航

上一篇：LLM 推理引擎的内存管理与调度

下一篇：Softmax 数值稳定性与 IO-Aware Attention

十三、参考资料

集合通信与工具

• NVIDIA NCCL Documentation：NCCL API、算法和环境变量。
• NCCL Tests：测量集合通信的实际带宽和延迟。
• Bringing HPC Techniques to Deep Learning：Ring AllReduce 的直观解释。
• PyTorch Distributed：Process Group 与集合通信 API。

并行训练

• Megatron-LM：Transformer 张量并行。
• ZeRO：训练状态分片。
• PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel：FSDP 工程设计。
• GPipe：Pipeline Parallelism 与 Micro Batch。
• DeepSpeed Ulysses：长序列并行。
• Ring Attention：沿上下文维度分布 Attention。
• AIInfraGuide：集合通信、DDP/FSDP、ZeRO、TP/PP 与多维并行的中文资料，MIT License。

从这个角度看，PagedAttention 不只是一个 Attention Kernel，Continuous Batching 也不只是“把 Batch 做大”。它们共同构成了一套面向 Token 的内存管理和调度系统。

图 1：分页内存管理允许请求细粒度进入和退出，动态调度则把释放出来的块转化为更高有效 Batch。

一、概念映射

这个类比不是说 vLLM 内部实现了完整操作系统，而是说明两者面对的是同一类资源分配问题。

二、连续分配为什么会浪费 KV Cache

假设系统为每个请求提前预留一段连续 KV Cache。问题很快出现：

2.1 内部碎片

系统按照最大输出长度预留，但请求可能提前遇到 EOS。没有使用的预留空间无法立刻服务其他请求。

2.2 外部碎片

请求不断到达和结束后，显存中会留下大小不一的空洞。空闲空间总量也许足够，却找不到一段满足新请求的连续区域。

2.3 过度预留

生成长度不可预测。如果不提前预留，Decode 增长时可能搬迁；如果按上限预留，又会浪费大量空间。

KV Cache 的困难不在于一次分配，而在于它会随着每个请求逐 Token 增长。

三、PagedAttention：把连续逻辑空间映射到离散物理块

PagedAttention 将 KV Cache 切成固定 Token 数的 Block。请求看到的是连续的逻辑块，实际物理块可以分散在显存中。

1
2
3
4
5

请求逻辑块:  [0] [1] [2] [3]
                │   │   │   │
Block Table:   12   3  27   8
                │   │   │   │
物理块池: ... [3] ... [8] ... [12] ... [27] ...

Attention Kernel 根据逻辑块号查询 Block Table，再计算物理块地址和块内偏移。这样请求不需要一段连续的物理显存。

3.1 碎片如何变化

• 外部碎片基本被固定大小块消除；
• 每个请求只有最后一个未填满 Block 产生有限内部浪费；
• Decode 时按需申请新块，不必按最大长度提前预留；
• 请求结束后，物理块可以直接回到空闲池。

Block Size 仍然需要权衡：

• 太大：最后一块浪费增加，细粒度复用下降；
• 太小：Block Table 更大，管理和寻址开销增加。

四、共享、引用计数和 Copy-on-Write

分页之后，不同请求的 Block Table 可以指向同一个物理 KV Block。

典型场景包括：

• 多个请求拥有相同系统 Prompt；
• Beam Search 或并行采样共享同一 Prompt；
• 多轮对话复用已经计算过的前缀。

共享块需要引用计数。只读阶段多个请求共同引用；当某个分支需要修改共享尾块时，再执行 Copy-on-Write：为它分配新块并复制必要内容。

这与 fork() 后父子进程共享内存页、写入时再复制的思想一致。

五、Prefix Cache：把共享从同时发生扩展到先后发生

PagedAttention 解决了“如何共享物理块”，Prefix Cache 进一步解决“如何发现历史请求已经计算过相同前缀”。

5.1 vLLM 的块哈希

一个块的哈希不仅取决于当前 Token，还要包含父块哈希。这样同一段 Token 出现在不同上下文中时，不会被错误认为是相同前缀。

可以把第 $i$ 个块的键抽象为：

$$h_i=H(h_{i-1},\;tokens_i,\;model\_id,\;adapter\_id,\;extra)$$

tokens_i 相同但父哈希不同，说明它们之前的上下文不同，不能共享同一份 KV。模型、LoRA Adapter、Cache Salt 等会改变计算语义的信息也必须进入键空间。实现通常只缓存已经填满的块，因为未填满尾块还会在 Decode 中继续写入，不适合作为稳定的共享对象。

新请求到来后，系统逐块查询缓存：

1
2

命中块 → 增加引用计数 → 跳过对应 Prefill
未命中 → 分配新块       → 正常计算

Prefix Cache 主要降低重复前缀的 Prefill，因此最直接改善 TTFT，而不是 Decode 的 TPOT。

5.2 LRU 为什么还要结合引用计数

正在被请求使用的块不能淘汰，即使它很久没有被“新请求”命中。引用计数为 0 的缓存块才进入可淘汰集合，然后按 LRU 等策略回收。

5.3 RadixAttention

SGLang 使用 Radix Tree 表示 Token 前缀。公共前缀天然共享树路径，适合结构化、多轮和前缀复用明显的工作负载。

Hash Block 与 Radix Tree 没有绝对优劣：前者容易与分页块池结合，后者能更直接表示变长前缀结构。实际收益最终取决于 Prompt 是否真的重复。

六、Static Batching 的槽位空洞与队头阻塞

图 2：Static Batching 中短请求完成后的槽位保持空闲；Continuous Batching 在迭代边界立即补入新请求。

假设一个 Batch 有四个请求，分别需要生成 20、50、200、500 个 Token。Static Batching 通常要等最慢的请求完成，短请求结束后的槽位无法立即加入新任务。

结果是：

• 短请求被长请求拖累；
• 已完成请求占据 Batch 位置；
• GPU 有效 Batch 逐渐缩小；
• 尾延迟和吞吐同时恶化。

这类似让一组任务组成固定班级，必须等所有成员完成才能接收下一批。

七、Continuous Batching：每个 Token 都是一个调度点

Continuous Batching 在每次模型迭代后重新安排请求：

1. 移除已经结束的请求；
2. 释放或保留它们的 KV Block；
3. 从等待队列选择新请求；
4. 为本轮请求分配 Token 和 KV 预算；
5. 组成新的 Batch 执行。

这是一种 Iteration-level Scheduling。调度单位不再是“完整请求 Batch”，而是“一轮需要处理的 Token”。

PagedAttention 与 Continuous Batching 互相依赖：如果 KV Cache 只能整段连续分配，请求频繁进入退出会带来昂贵搬迁；如果没有动态调度，分页节省的空间也难以转化成更高并发。

调度循环可以简化为下面的伪代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

def schedule_step(waiting, running, token_budget, block_pool):
    batch = []

    # Decode 请求优先获得本轮所需 Token，保护输出流畅度。
    for req in running:
        if req.finished:
            block_pool.release(req.blocks)
            continue
        if token_budget >= 1 and block_pool.can_append(req):
            batch.append((req, 1))
            token_budget -= 1

    # 剩余预算用于新 Prefill 或尚未完成的 Prefill Chunk。
    while waiting and token_budget > 0:
        req = waiting.peek()
        computable = min(req.remaining_prompt_tokens, token_budget)
        allocatable = block_pool.max_allocatable_tokens(req)
        scheduled = min(computable, allocatable)
        if scheduled == 0:
            break
        batch.append((req, scheduled))
        token_budget -= scheduled
        update_request_state(req, scheduled, waiting, running)

    return batch

真实 vLLM V1 的策略比这段伪代码复杂，且版本会持续变化；这里想表达的稳定结构是：请求状态、Token 预算和 KV Block 预算必须在一次决策中共同满足。

八、长 Prefill 为什么会干扰 Decode

Decode 请求每轮只需要少量 Token，希望稳定、频繁地获得 GPU 时间。一个超长 Prompt 的 Prefill 如果一次执行完，会占据 GPU 较长时间，导致同批 Decode 请求的 TPOT 突然升高。

8.1 Chunked Prefill

Chunked Prefill 把长 Prompt 切成多个片段：

1
2
3
4

长 Prefill: [========================]

切块后:     [====] [====] [====] [====]
Decode:        |      |      |      |

它可能用更长一些的 TTFT，换取更平滑的 Decode TPOT 和更好的调度公平性；实际变化取决于 Token Budget、队列状态和请求长度分布。

8.2 Token Budget

统一调度器可以把每轮处理能力表示为 Token Budget：

1

本轮预算 = Decode Token + 新请求 Prefill Token + Chunked Prefill Token

当长 Prefill 超过剩余预算时，只处理可以容纳的部分，下轮从 num_computed_tokens 继续。这比硬编码“先 Prefill 还是先 Decode”更容易统一不同请求状态。

九、抢占：显存不够时让谁退场

当物理 KV Block 用尽，调度器需要释放资源。常见恢复方式有：

• 重计算：丢弃某请求的 KV，之后重新 Prefill；
• 换出：将 KV 搬到 CPU 内存，需要时再搬回；
• 延迟新请求：保持运行请求不变，让新请求继续等待。

选择取决于 PCIe 带宽、Prompt 长度、重计算成本和延迟 SLO。重计算看似浪费算力，但可能比大规模 CPU–GPU KV 交换更稳定。

十、吞吐、公平性与 SLO

调度器至少要同时考虑：

• Batch 越大，权重读取的摊销通常越好；
• Batch 太大，单轮时间和 TPOT 上升；
• 长 Prompt 有利于填满计算，却可能阻塞 Decode；
• 高缓存命中可以降低 TTFT，但缓存本身占用显存；
• 抢占能避免 OOM，但会引入重计算或传输。

生产环境真正应该优化的是 Goodput：在 TTFT、TPOT 和错误率满足 SLO 的前提下，系统完成了多少有效请求。

十一、源码阅读路线

阅读 vLLM 时，可以围绕三个问题定位，而不是从仓库第一行开始：

1. KV Block 如何申请、引用和释放；
2. Scheduler 每轮如何决定哪些请求处理多少 Token；
3. Attention Backend 如何根据 Block Table 读取 KV。

源码会持续演进，类名和文件路径可能变化，但“块池—请求状态—调度预算—执行后端”这四个角色比较稳定。

十二、技术 Q&A

Q1：PagedAttention 是否完全消除了 KV Cache 浪费？

它通过固定块和逻辑—物理映射基本消除了连续分配造成的外部碎片，也避免按最大长度过度预留；但每个请求的最后一个 Block 仍可能未填满，Block Table、引用计数和间接寻址也有管理成本。Block 越大尾块浪费越高，越小元数据和调度开销越高。

Q2：Prefix Cache 为什么主要改善 TTFT，且块哈希必须包含父块哈希？

命中缓存后，引擎可以跳过公共前缀的 Prefill，因此首 Token 更早产生；后续 Decode 仍要逐轮读取权重和历史 KV，所以 TPOT 通常不会直接缩短。由于 Transformer 的 KV 取决于当前 Token 之前的完整上下文，相同 Token Block 出现在不同父前缀后会产生不同 KV。将父块哈希纳入链式哈希，才能确保复用的是从起点到当前块都相同的完整前缀。

Q3：Continuous Batching 为什么依赖分页式 KV 管理？

迭代级调度要求请求可以每轮加入、退出和增长。若每个请求必须拥有一段按最大长度预留的连续 KV，新请求补位和旧请求释放会造成大量碎片或数据搬迁。固定块把请求生命周期的变化转化为块的申请与释放，使动态补位和显存回收的成本可控。

Q4：Chunked Prefill 与 Token Budget 共同决定了什么权衡？

Chunked Prefill 把长 Prefill 拆成较短片段，让 Decode 在片段之间获得 GPU 时间，从而降低 TPOT 抖动和 Head-of-Line Blocking；代价是长请求需要更多调度轮才能完成 Prefill，TTFT 可能增加。较大的 Token Budget 有利于形成大 Batch、提高吞吐并减少切块次数，但也会拉长单轮执行时间。两者需要结合请求长度分布和 TTFT/TPOT SLO 进行并发扫描，而不是独立地取极值。

十三、系列导航

上一篇：GPU 性能分析方法

下一篇：分布式训练的通信模型

十四、参考资料

论文与系统

• Efficient Memory Management for LLM Serving with PagedAttention：分页式 KV Cache 管理。
• Orca：Iteration-level Scheduling。
• SGLang: Efficient Execution of Structured Language Model Programs：RadixAttention 和结构化生成执行。
• SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills：Chunked Prefill。
• DistServe：Prefill/Decode 解耦与 Goodput。

文档与源码

• vLLM PagedAttention Design：Kernel 和块寻址设计。
• vLLM Automatic Prefix Caching：前缀块哈希和缓存语义。
• vLLM V1 Alpha Release：统一调度、Prefix Cache 和 CUDA Graph。
• vLLM V1 Core Source：KV Cache Manager、Block Pool 和 Scheduler。
• AIInfraGuide：PagedAttention、Continuous Batching、Prefix Cache 与 Chunked Prefill 的中文推导和源码导读，MIT License。

可靠的优化过程应该像故障诊断：先建立理论上限，再用工具验证瓶颈，最后用实验确认收益。本文用同一套方法串起 Vector Add、Reduce、GEMM、Softmax、FlashAttention 和 LLM Decode。

图 1：GPU 性能分析的对象不是抽象的“核”，而是 SM、执行单元和多级存储共同组成的系统。

一、性能问题先写成两个数字

对一个 Kernel，先估算：

• 总计算量：FLOPs；
• 最少数据搬运量：Bytes。

两者之比称为算术强度：

$$I=\frac{\text{FLOPs}}{\text{Bytes}}$$

如果一个操作只做很少计算，却要从 HBM 读取大量数据，它通常受带宽限制；如果每次读取的数据会被重复使用很多次，它更可能受计算吞吐限制。

1.1 Vector Add

计算 C[i] = A[i] + B[i]，每个元素读取两个 FP32、写回一个 FP32，共 12 Bytes，只执行一次加法：

$$I\approx\frac{1}{12}\text{ FLOPs/Byte}$$

这是典型的 Memory Bound 操作。继续增加算术单元不会明显加速，关键是合并访问、足够并发和接近峰值显存带宽。

1.2 GEMM

矩阵乘法包含大量乘加。如果通过 Shared Memory 和寄存器 Tiling 让数据被多次复用，算术强度可以大幅提高，最终接近 Compute Bound。

这两类操作构成了 Roofline 图上的两个极端。

二、Roofline：先判断优化方向

图 2：Roofline 中的“Bytes”来自不同存储层次；减少 HBM 流量和提高片上复用往往比减少一条算术指令更重要。

Roofline 模型给出的性能上限为：

$$P\leq\min(P_{peak}, I\times BW_{peak})$$

其中 $P_{peak}$ 是峰值计算吞吐，$BW_{peak}$ 是峰值带宽。

1
2
3
4
5
6
7
8

性能
  ^                    ───────── 计算上限
  |                 /
  |              /
  |           /      转折点
  |        /
  |     / 带宽上限
  +----------------------------> 算术强度

它不能直接告诉我们哪一行代码有问题，但能排除错误方向：

• 位于斜线区域：优先减少 HBM 访问、提高合并率和数据复用；
• 位于水平区域：优先提高 Tensor Core 使用率、指令并行和计算占用；
• 两个上限都远未达到：可能存在同步、分支、Launch、负载不均或数据准备问题。

2.1 一个带宽核算例子

对长度为 $N$ 的 FP32 Vector Add，有效数据量为 $12N$ Bytes。如果 $N=2^{28}$，Kernel 用时 2.4ms，则有效带宽约为：

$$BW_{eff}=\frac{12\times2^{28}}{2.4\times10^{-3}}\approx1.34\text{ TB/s}$$

这个数字必须与目标 GPU 在同一访问模式下的可达带宽比较，而不是简单除以产品手册峰值。如果向量起始地址未对齐、线程访问跨越更多内存事务或时钟频率受限，实际可达上限会下降。

类似地，GEMM 更适合报告 TFLOPS：

$$P_{gemm}=\frac{2MNK}{t}$$

统一用“完成了多少必要工作/消耗了多少时间”描述性能，才能跨实现比较。

三、建立可信基线

优化前至少要保证四件事：

1. 与参考实现比较正确性；
2. 预热，排除首次初始化和编译；
3. 使用 CUDA Event 测量 GPU 时间；
4. 多次执行并报告中位数或分位数。

1
2
3
4
5
6

cudaEventRecord(start);
for (int i = 0; i < repeat; ++i) {
    kernel<<<grid, block>>>(...);
}
cudaEventRecord(stop);
cudaEventSynchronize(stop);

如果每轮都调用 cudaDeviceSynchronize()，测到的可能不再是实际流水执行方式。端到端延迟和纯 Kernel 延迟也应分开报告。

四、同一套方法看五类算子

4.1 Reduce：并行度和同步的平衡

图 3：Warp Shuffle 将 Warp 内数据交换留在寄存器路径中，再用少量 Shared Memory 合并多个 Warp 的结果。

Reduce 的输入只读取一次，计算量很低，通常受带宽和规约开销影响。典型优化路径是：

1
2
3
4
5
6

全局原子加
→ Shared Memory 树形规约
→ 消除 Warp Divergence
→ 每线程处理多个元素
→ Warp Shuffle
→ 向量化加载

每一步都应该对应一个可验证的假设。例如使用 Warp Shuffle 的目的，不是“它更高级”，而是减少 Shared Memory 访问和 Block 内同步。

4.2 GEMM：用空间换数据复用

图 4：Thread Tiling 让一个线程计算多个输出元素，提高从 Shared Memory 到寄存器的数据复用。

朴素 GEMM 中，每个线程独立从全局内存读取一行和一列，数据重复读取严重。Block Tiling 把 A、B 的 Tile 搬入 Shared Memory；Thread Tiling 再把局部数据放入寄存器。

优化的代价也很明确：

• Tile 太小：复用不足；
• Tile 太大：Shared Memory 占用上升；
• 每线程输出太多：寄存器压力增大；
• 寄存器溢出：Local Memory 访问反而拖慢程序；
• Occupancy 降低：可能无法隐藏访存延迟。

因此 Occupancy 不是目标，而是资源预算的一部分。

图 5：线程编号连续并不自动保证合并访存；关键是一个 Warp 请求的地址能否落入尽量少的内存事务。

4.3 Softmax：多遍扫描与规约

数值稳定的 Softmax 通常要完成：

1. 求最大值；
2. 计算指数和；
3. 归一化输出。

这意味着多次读取同一行。Online Softmax 把最大值和指数和表示为可合并状态，减少扫描次数，并为 FlashAttention 的分块计算奠定基础。

4.4 FlashAttention：优化的不是 FLOPs

图 6：FlashAttention 的主要收益来自避免将完整 Attention 中间矩阵写回 HBM。

标准 Attention 会产生并写回 $S\times S$ 的分数或概率矩阵。FlashAttention 通过 Tiling 和 Online Softmax，让中间块停留在片上存储中。

它并没有改变精确 Attention 的数学定义，核心收益来自降低 HBM IO。这个例子非常适合说明：理论 FLOPs 相同的两个算法，真实速度可以完全不同。

4.5 Decode：Kernel 很快，系统仍可能很慢

LLM Decode 中的单个 Kernel 规模较小，CPU Launch、Python 调度和框架开销可能占据明显比例。此时只看 Kernel 内部指标是不够的，需要用 Nsight Systems 检查 GPU 时间线中的空洞。

CUDA Graph 可以录制并重放一组 Kernel，减少重复 Launch 开销。但它通常要求地址和形状相对稳定，也会增加捕获时间、显存占用和调试复杂度。

五、Nsight Systems：先看全局时间线

常用命令示例：

1

nsys profile --trace=cuda,nvtx,osrt -o report ./app

重点检查：

• Kernel 之间是否存在明显 GPU Idle Gap；
• CPU 是否在数据预处理、Python 或锁等待中停顿；
• Host-to-Device 拷贝能否与计算重叠；
• NCCL 通信是否与反向计算重叠；
• 是否存在大量极短 Kernel；
• 多个 CUDA Stream 是否真正并行。

Nsight Systems 适合回答“时间花在哪个阶段”，但不能完整解释某个 Kernel 为什么没有达到峰值。

六、Nsight Compute：下钻到单个 Kernel

1

ncu --set full -o kernel-report ./app

建议按下面顺序阅读：

6.1 Speed of Light

先比较计算吞吐和内存吞吐相对于设备峰值的比例。如果 Memory 接近上限而 Compute 很低，通常是 Memory Bound；反之则可能是 Compute Bound。

6.2 Memory Workload Analysis

检查：

• Global Load/Store 是否合并；
• 请求量与实际内存事务量是否相符；
• L1/L2 命中率；
• Shared Memory Bank Conflict；
• DRAM 吞吐是否接近有效上限。

6.3 Occupancy

确认限制 Active Warp 的资源：

• 每线程寄存器；
• 每 Block Shared Memory；
• Block 大小；
• 架构上的最大 Block 和 Warp 数。

高 Occupancy 可以帮助隐藏延迟，但不会自动提高算术强度或消除低效访存。

6.4 Warp Stall

不同架构和报告版本的指标名称可能变化，但常见信号包括：

• Long Scoreboard：Warp 长时间等待内存相关依赖；
• MIO Throttle：内存输入输出相关指令管线压力较大；
• Barrier：等待同步；
• Not Selected：有足够就绪 Warp，但当前没有被选中；
• Branch Resolving：分支控制流造成等待。

不要看到一个 Stall 指标高就直接下结论。它必须和访存事务、吞吐、Occupancy 以及源码位置一起解释。

七、一个可复用的优化闭环

第一步：定义目标

明确优化的是：

• 单 Kernel 延迟；
• 训练 Step Time；
• TTFT；
• TPOT；
• Tokens/s；
• 每美元吞吐。

第二步：建立模型

计算 FLOPs、Bytes、算术强度、理论带宽时间和理论计算时间。

第三步：获取证据

用 Systems 判断阶段，用 Compute 判断 Kernel，用框架 Profiler 补充算子和调用栈信息。

第四步：一次只修改一个变量

例如只改变：

• Block Size；
• Tile 大小；
• 向量化宽度；
• 是否融合；
• 是否使用 CUDA Graph。

第五步：记录收益和代价

至少记录正确性误差、延迟、吞吐、显存和适用输入范围。一个只在固定 Shape 上更快的 Kernel，不一定适合动态生产负载。

八、技术 Q&A

Q1：Occupancy 达到 100%，为什么 Kernel 仍可能很慢？

Occupancy 只描述 SM 上驻留 Warp 的比例，不描述每个 Warp 的访存是否合并、数据是否复用、指令是否有效或 Tensor Core 是否被使用。一个高 Occupancy Kernel 可以同时具有低算术强度、严重 Bank Conflict 和大量无效线程。只有当瓶颈是“没有足够就绪 Warp 隐藏延迟”时，提高 Occupancy 才直接有效。

Q2：Shared Memory Tiling 为什么能提高 GEMM 算术强度？

A、B 的一个 Tile 从 HBM 读取一次后，被 Block 内多个线程重复用于多个输出元素。必要 FLOPs 不变，而 HBM Bytes 减少，所以算术强度提高。Tile 继续增大时会消耗更多 Shared Memory 和寄存器，最终受 Occupancy、指令调度或片上带宽限制。

Q3：Nsight Systems 和 Nsight Compute 应该按什么顺序使用？

先用 Systems 判断端到端时间花在 CPU、数据拷贝、NCCL、Kernel 还是 GPU Idle；只有确认某个 Kernel 占据主要时间且内部效率不足后，再用 Compute 分析其内存事务、吞吐、Stall 和 Occupancy。直接对任意 Kernel 跑完整 NCU 容易得到大量指标，却没有优化优先级。

Q4：FlashAttention 的 FLOPs 相近为何仍能加速，而 Decode 的短 Idle Gap 又该如何处理？

标准 Attention 会把 $S\times S$ 分数或概率矩阵写入 HBM，再读回用于后续计算；FlashAttention 在 SRAM 中按 Tile 完成分数、在线归一化和与 V 的累加，避免物化大中间矩阵，因此通过减少 IO 获得加速。若 Decode 时间线的主要问题是 Kernel 之间存在大量短 Idle Gap，则瓶颈在 CPU 调度、同步或 Launch，此时应优先考虑 CUDA Graph、算子融合和减少框架往返，而不是继续优化已经很短的单个 Kernel。

九、系列导航

上一篇：LLM 自回归推理的执行路径

下一篇：LLM 推理引擎的内存管理与调度

十、参考资料

性能模型与硬件文档

• Roofline: An Insightful Visual Performance Model：算术强度与性能上限。
• NVIDIA CUDA C++ Programming Guide：CUDA 执行与内存模型。
• NVIDIA Deep Learning Performance Guide：深度学习工作负载性能分析。
• NVIDIA Nsight Systems User Guide：系统级时间线分析。
• NVIDIA Nsight Compute：Kernel 级性能指标。

算子优化

• CUTLASS：高性能 GEMM 模板和多级流水设计。
• How to Optimize a CUDA Matmul Kernel：从朴素实现到接近 cuBLAS 的优化过程。
• Online Normalizer Calculation for Softmax：Online Softmax 的递推状态。
• FlashAttention：IO-Aware Attention。
• FlashAttention-2：并行划分和非 GEMM 操作优化。
• Getting Started with CUDA Graphs：减少重复 Kernel Launch 开销。
• AIInfraGuide：CUDA 内存模型、Reduce/GEMM/Softmax 优化及 Nsight 工具链资料，MIT License。

本文不按模型组件逐个介绍，而是跟随一个 Token 从进入系统到离开 GPU。沿着这条数据流，可以自然解释 Prefill 与 Decode、KV Cache、Continuous Batching，以及 TTFT 和 TPOT 为什么会成为推理系统最重要的指标。

图 1：Prefill 与 Decode 共享模型结构，却具有完全不同的执行形状和性能瓶颈。

理解整条链路时，最好把系统看成三个相互耦合的状态机，而不是一条只会向前的流水线：

模型前向只负责把输入状态推进一步；生产推理的复杂性来自数百个请求状态机共享同一份模型状态，并由调度状态决定谁在下一轮获得计算和显存。

一、Tokenization 与离散输入表示

模型不能直接处理字符串。请求首先经过 Tokenizer，被转换为一串整数 ID：

1
2
3

"AI Infra 很有意思"
        ↓ Tokenizer
[2334, 6121,  ...]

现代 LLM 通常使用子词或字节级分词。Tokenizer 会影响：

• 同一句话被切成多少 Token；
• 上下文窗口实际能容纳多少文字；
• 推理计费和吞吐统计；
• 多语言场景中的输入效率；
• Prefix Cache 能否命中完全一致的 Token 前缀。

因此，服务端判断两个 Prompt 是否拥有相同前缀时，比较的不是肉眼看到的字符串，而是分词后的 Token 序列。

二、Embedding、位置编码与输入张量

每个 Token ID 都会在 Embedding 表中查到一个 $d$ 维向量。假设 Batch 为 $B$，序列长度为 $S$，隐藏维度为 $d$，进入 Transformer 前的张量形状是：

$$(B,S,d)$$

Embedding 本身不包含顺序信息，所以还需要位置编码。当前 Decoder-only 模型常使用 RoPE，将位置信息施加到 Q、K 上。这样 Attention 的内积不仅与内容有关，也能感知相对位置。

这一阶段看似简单，却决定了后续所有 Kernel 的形状。如果不能熟练跟踪 (Batch, Sequence, Hidden)，就很难分析 Attention 的显存、GEMM 的尺寸或张量并行的切分位置。

三、Decoder Block 的计算路径

图 2：Decoder-only 模型从 Embedding 开始，经过重复的 Decoder Block，最终由 LM Head 产生 Logits。

一个典型的 Pre-Norm Decoder Block 可以抽象成：

1
2
3

x
├─ RMSNorm → Causal Self-Attention → Residual Add
└─ RMSNorm → SwiGLU FFN          → Residual Add

3.1 Q、K、V 从哪里来

输入 $X\in\mathbb{R}^{B\times S\times d}$ 分别乘以投影矩阵：

$$Q=XW_Q,\quad K=XW_K,\quad V=XW_V$$

拆成多头后，Q 的形状通常是：

$$(B,H_q,S,d_h)$$

GQA 模型的 K、V 则是：

$$(B,H_{kv},S,d_h),\quad H_{kv}<H_q$$

Attention 的核心公式为：

$$\operatorname{softmax}\left(\frac{QK^T}{\sqrt{d_h}}+M\right)V$$

其中 $M$ 是 Causal Mask，它让当前位置只能看到自己和之前的 Token。

3.2 FFN 为什么不能忽略

Attention 负责 Token 之间的信息混合，FFN 则对每个 Token 独立做非线性变换。SwiGLU 通常包含 Gate、Up 和 Down 三个大矩阵乘，是参数量和计算量的重要组成部分。

从系统角度看，一个 Decoder Block 不是单个大 Kernel，而是一组 GEMM、Norm、激活、位置编码和 Attention Kernel。推理框架需要尽量减少中间张量读写和 Kernel Launch 次数。

四、Prefill 与 Decode 两阶段执行模型

自回归模型每次只生成一个新 Token，但处理输入 Prompt 和生成后续 Token 是两种完全不同的工作负载。

4.1 Prefill：一次处理完整 Prompt

假设 Prompt 有 $S$ 个 Token，Prefill 会让这 $S$ 个位置一起通过所有 Transformer 层。

特点是：

• GEMM 的矩阵尺寸较大；
• GPU 并行度高；
• 计算量随 Prompt 长度快速增长；
• 通常更接近 Compute Bound；
• 结束时生成所有历史 Token 的 K、V。

用户最关心的 Prefill 指标是 TTFT，也就是从请求进入系统到收到第一个输出 Token 的时间。

4.2 Decode：每轮只新增一个 Token

Decode 第 $t$ 轮只计算一个新位置的 Q、K、V。新 Q 要与之前所有 Token 的 K 做 Attention，然后产生下一个 Token 的概率分布。

此时矩阵乘的 $M$ 维通常很小，GPU 每轮却仍要读取大量模型权重和历史 KV。Decode 因而常表现为 Memory Bound：算术单元还没吃饱，显存带宽已经成为瓶颈。

五、为什么需要 KV Cache

如果没有 KV Cache，第 $t$ 轮生成时必须重新计算前面 $t-1$ 个 Token 的 K 和 V。整个生成过程会产生大量重复工作。

KV Cache 的策略很直接：

1
2
3

Prefill: 计算 Prompt 所有 K/V → 写入缓存
Decode : 只计算新 Token 的 K/V → 追加到缓存
         新 Q 读取全部历史 K/V

为什么不缓存 Q？因为历史 Token 的 Q 只用于它们各自产生输出。生成当前 Token 时，需要的是当前 Q 与全部历史 K、V，历史 Q 不再参与计算。

KV Cache 用显存换取了计算，但也带来了新的系统问题：

• 长上下文让缓存线性增长；
• 并发请求的长度不同；
• 请求随时到达和结束；
• 连续预留容易产生碎片；
• 相同系统提示词会被反复计算。

这些问题分别催生了 PagedAttention、Continuous Batching 和 Prefix Cache。

六、Logits 处理与采样解码

最后一层隐藏状态经过 Final Norm 和 LM Head，得到词表大小的 Logits。Softmax 将其转换为概率分布，但系统不一定选择概率最大的 Token。

6.1 Temperature

$$p_i=\operatorname{softmax}(z_i/T)$$

• $T<1$：分布更尖锐，输出更确定；
• $T>1$：分布更平坦，输出更多样。

6.2 Top-K

只保留概率最高的 K 个候选，再归一化采样。它限制候选数量，但没有考虑概率质量。

6.3 Top-P

按概率从高到低排序，保留累计概率达到 $p$ 的最小集合。分布很确定时候选少，分布不确定时候选会自动增多。

采样出新 Token 后，它会被追加到请求序列，重新进入下一轮 Decode，直到遇到结束符、长度限制或停止条件。

6.4 一个最小自回归循环

下面的伪代码刻意省略推理框架的调度细节，只保留模型状态如何跨轮次延续：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@torch.inference_mode()
def generate(model, input_ids, max_new_tokens, temperature=0.8):
    # 首轮输入完整 Prompt，模型返回首 Token 所需 logits 和每层 KV。
    output = model(input_ids=input_ids, use_cache=True)
    past_key_values = output.past_key_values
    next_token = sample(output.logits[:, -1], temperature)
    generated = [next_token]

    for _ in range(max_new_tokens - 1):
        # 后续每轮只输入上轮产生的一个 Token。
        output = model(
            input_ids=next_token[:, None],
            past_key_values=past_key_values,
            use_cache=True,
        )
        past_key_values = output.past_key_values
        next_token = sample(output.logits[:, -1], temperature)
        generated.append(next_token)
        if reached_stop_condition(next_token):
            break

    return torch.stack(generated, dim=1)

这段代码展示了 Prefill/Decode 的语义边界，但不适合直接作为生产服务：每个请求单独循环会产生小 Kernel 和频繁 Launch，也无法让完成的请求即时退出 Batch。vLLM、SGLang 等引擎优化的正是“多个这样的状态机如何共享一次模型执行”。

七、多请求推理与迭代级调度

如果 GPU 每次只为一个请求生成一个 Token，Decode 的小矩阵很难利用完整算力。推理引擎会把多个请求的当前 Token 拼成一个 Batch，让一次权重读取服务更多请求。

传统 Static Batching 要等整个 Batch 中所有请求都完成，短请求会被长请求拖住。Continuous Batching 则在每个 Decode 迭代重新组织 Batch：

1
2
3
4
5
6
7

完成的请求退出
        ↓
释放对应 KV Block
        ↓
从等待队列补入新请求
        ↓
执行下一轮 Token

Batch 越大，通常吞吐越高，但每个请求等待调度和执行的时间也可能增加。因此推理系统不是只追求 Tokens/s，而是在吞吐、TPOT 和尾延迟之间做平衡。

八、用指标描述这段旅程

8.1 TTFT

Time To First Token，包括排队、Tokenization、调度和 Prefill。长 Prompt、排队拥塞和冷启动都会抬高 TTFT。

8.2 TPOT / ITL

Time Per Output Token 或 Inter-Token Latency，反映回答逐字输出是否流畅，主要受 Decode 阶段影响。

8.3 E2E Latency

一个近似关系是：

$$T_{E2E}\approx TTFT+(N_{out}-1)\times TPOT$$

短回答可能由 TTFT 主导，长回答则更容易由 TPOT 主导。

8.4 Throughput 和 Goodput

Throughput 统计单位时间完成的请求或生成的 Token。Goodput 则只统计满足延迟 SLO 的有效工作。一个系统可能吞吐很高，但大量请求超过 TPOT 或 TTFT 限制，此时 Goodput 仍然很低。

九、建议实验

可以用同一模型做四组测试：

1. 固定输出长度，改变 Prompt 长度，观察 TTFT；
2. 固定 Prompt，改变输出长度，观察 E2E 延迟；
3. 改变并发数，记录吞吐和 P99 TPOT；
4. 对比单请求 Hugging Face 推理与 vLLM Continuous Batching。

记录结果时不要只写平均值，至少保留 P50、P95、P99 和实际 Prompt 长度分布。

十、技术 Q&A

Q1：为什么历史 Token 的 Q 不需要进入 KV Cache？

某个历史位置的 Q 只用于计算该位置自己的 Attention 输出。生成新 Token 时，需要的是“当前新位置的 Q”与“所有历史位置的 K/V”。历史 Q 不会再次参与后续位置的计算，缓存它只会增加显存而不会减少必要计算。

Q2：Prefill 和 Decode 使用同一个模型，为什么瓶颈不同？

Prefill 同时处理 $S$ 个位置，线性层形成较大的矩阵乘，数据复用和 Tensor Core 利用率较高；Decode 每请求每轮只有一个新位置，GEMM 的 Token 维很小，却仍要读取几乎全部层权重和历史 KV，因此算术强度低，通常更受 HBM 带宽和 Launch 延迟限制。

Q3：为什么增大 Batch 能提高 Decode 吞吐，却可能恶化 TPOT？

单请求 Decode 读取一次模型权重只服务一个 Token；把多个请求组成 Batch 后，同一轮权重读取可以为多个 Token 计算摊销，GEMM 的有效尺寸也变大。但 Batch 过大使单轮执行时间增加，新请求和已经处于 Decode 阶段的请求都要等待更久，所以吞吐上升不保证 TPOT 和尾延迟同步改善。

Q4：应如何用 TTFT、TPOT 和 Goodput 评价推理引擎？

TTFT 描述排队和 Prefill 后用户多久看到首 Token，TPOT 描述后续输出的流畅度，吞吐量描述系统总产出。Goodput 只统计同时满足 TTFT/TPOT SLO 的请求，可避免系统通过无限扩大 Batch 换取表面吞吐。测试时还应使用输入与输出长度分桶、并发扫描和真实到达 Trace；固定 Shape 无法暴露长 Prefill 干扰、动态补位、KV 碎片和 P99 排队时间。

十一、系列导航

上一篇：大模型训练与推理的显存模型

下一篇：GPU 性能分析方法

十二、参考资料

论文

• Attention Is All You Need：Transformer 和 Scaled Dot-Product Attention。
• LLaMA 2：现代 Decoder-only 模型的结构实例。
• GQA: Training Generalized Multi-Query Transformer Models：Query Head 与 KV Head 解耦。
• Efficient Memory Management for LLM Serving with PagedAttention：KV Cache 管理和 vLLM。
• Orca: A Distributed Serving System for Transformer-Based Generative Models：Iteration-level Scheduling。
• The Curious Case of Neural Text Degeneration：Top-P 采样。
• Fast Inference from Transformers via Speculative Decoding：并行验证多个候选 Token。

文档

• vLLM Documentation：离线推理、在线服务和引擎配置。
• NVIDIA NIM LLM Benchmarking Metrics：TTFT、ITL、吞吐等指标定义。
• The Illustrated Transformer：建立 Transformer 数据流直觉。
• AIInfraGuide：Tokenization、Decoder-only、Prefill/Decode 与 KV Cache 的中文资料，MIT License。

本文不按“模型结构、训练优化、推理优化”的教材顺序展开，而是从一张统一的显存账本出发，把 Transformer 参数、优化器状态、激活值和 KV Cache 放进同一个分析框架。目标不是背住某个模型需要多少 GB，而是拿到任意配置后，都能判断它是否装得下、为什么装不下，以及应该用什么代价换取空间。

图 1：训练显存和推理显存应使用两套状态模型，但最终都要回到统一的资源预算。

一、先区分两个问题：装得下和跑得好

“一张 H100 能不能运行 7B 模型”不是一个完整问题。至少还要补充四个条件：

• 训练还是推理；
• 使用 BF16、FP16、FP8、INT8 还是 INT4；
• Batch Size、序列长度和并发量是多少；
• 是否使用张量并行、FSDP、量化或 CPU Offload。

模型勉强装进显存，也不代表系统可以稳定运行。CUDA Context、通信 Buffer、临时 Workspace、CUDA Graph 和框架缓存都需要空间。生产环境通常不会把显存利用率推到理论上的 100%，否则一次较长的请求或稍大的临时张量就可能触发 OOM。

因此容量规划要依次回答：

1. 权重和长期状态占多少；
2. 随输入变化的动态状态占多少；
3. 运行时还需要留下多少安全空间；
4. 达到目标吞吐时，动态状态会增长到什么程度。

1.1 用“生命周期 × 副本数”统一不同状态

仅按“权重、梯度、激活”分类还不够。更稳健的模型是同时标注状态的生命周期和复制方式：

对于任意长期状态，可以用下面的抽象检查是否重复计算：

$$M_{state}=\text{元素数}\times\text{每元素字节数}\times\frac{\text{副本因子}}{\text{分片因子}}$$

这个公式比“参数量除以 GPU 数”多了一个关键变量：副本因子。某个张量即使理论上可分片，也可能因为计算或通信需要，在特定阶段临时恢复完整副本。FSDP 的峰值 AllGather、TP 中未切分的小参数以及 CUDA Graph 私有池都属于这类情况。

二、从配置文件估算参数量

设隐藏维度为 $d$，层数为 $L$，词表大小为 $V$，FFN 中间维度为 $d_{ff}$。

2.1 Embedding 和 LM Head

输入 Embedding 的参数量为：

$$V \times d$$

如果模型使用 Weight Tying，让输入 Embedding 和输出 LM Head 共享权重，这部分只存一份；否则还要再加一个 $V \times d$。

图 2：参数账本必须覆盖 Embedding、每层 Attention/FFN 以及最终输出层，而不能只按隐藏维度粗略估计。

2.2 Attention

标准 Multi-Head Attention 包含 Q、K、V 和输出投影，忽略 Bias 时约为：

$$4d^2$$

GQA 或 MQA 会减少 K、V 投影的输出维度。设 Query Head 数为 $H_q$，KV Head 数为 $H_{kv}$，单头维度为 $d_h=d/H_q$，则每层 Attention 参数量约为：

$$d^2 + 2d(H_{kv}d_h) + d^2$$

GQA 对总参数量的影响通常没有对 KV Cache 那么显著，但会直接改变推理时每个 Token 的缓存大小。

2.3 SwiGLU FFN

当前很多 Decoder-only 模型使用 SwiGLU。它包含 Gate、Up 和 Down 三个矩阵，因此每层约为：

$$3d \times d_{ff}$$

这也是为什么大模型中 FFN 往往比 Attention 占用更多参数。

2.4 一个可复用的近似式

忽略 Norm 和 Bias 等小项，一个 Decoder-only 模型可以近似写成：

$$N \approx Vd + L\left(P_{attn}+3dd_{ff}\right)$$

手算时不必追求个位数精度。容量规划更关心 7B、13B、70B 这种数量级，以及不同模块在总参数中的比例。

三、训练显存：为什么常见估算是每参数 16 字节

使用 BF16 参数和 AdamW 训练时，一种常见的静态显存账本如下：

因此，静态训练状态常用下面的数量级估算：

$$M_{static} \approx 16N$$

一个 7B 模型仅静态状态就约为 112 GB。即使不考虑激活值，它也无法直接放进一张 80GB GPU 中进行标准 AdamW 训练。

需要特别注意：16N 是便于做决策的工程近似，不是所有框架都严格一致。梯度精度、优化器实现、参数 Flatten、通信 Bucket 和分配器行为都会影响真实结果。

3.1 激活值为什么更难估算

参数和优化器状态主要由模型规模决定，激活值则还受到以下因素影响：

• Micro Batch Size；
• 序列长度；
• 层数和隐藏维度；
• Attention 是否保存 $S\times S$ 中间矩阵；
• 是否启用 FlashAttention；
• 是否启用 Activation Checkpointing；
• Tensor Parallel 和 Sequence Parallel 的切分方式。

激活显存通常可以抽象为：

$$M_{act} \propto B \times S \times d \times L$$

不同实现的常数项差异很大，所以最可靠的方法是先做理论上界，再用框架的显存快照和 Profiler 验证。

四、推理显存：权重之外，真正会增长的是 KV Cache

推理时不再保存梯度和优化器状态，显存的主体变为：

$$M_{inference}=M_{weights}+M_{KV}+M_{runtime}$$

4.1 权重显存

权重部分可以直接近似为：

这张表解释了为什么 70B BF16 模型至少需要两张 80GB GPU，而 INT4 版本可能装入单张大显存 GPU。但“装入”不等于吞吐一定更高：量化 Kernel、反量化开销和硬件支持同样重要。

4.2 KV Cache 通用公式

每层都要为历史 Token 保存 K 和 V。设层数为 $L$，KV Head 数为 $H_{kv}$，单头维度为 $d_h$，缓存精度字节数为 $b$，则每个 Token 的 KV Cache 为：

$$M_{KV/token}=2LH_{kv}d_hb$$

总 KV Cache 为：

$$M_{KV}=B\times S\times 2LH_{kv}d_hb$$

其中 $B$ 是并发序列数，$S$ 是已经缓存的平均序列长度。这里最容易被忽略的是：KV Cache 不只随上下文长度增长，也随并发数线性增长。

以 32 层、32 个 KV Head、Head Dimension 为 128 的 BF16 模型为例：

$$2\times32\times32\times128\times2=524288\text{ Bytes}$$

即每个 Token、每个请求约 0.5 MiB。当并发为 16、序列长度为 4096 时，KV Cache 约为 32 GiB。这还没有计入模型权重和运行时空间。

4.3 GQA 为什么对推理系统格外重要

如果 Query Head 为 64，而 KV Head 只有 8，那么相对于同样使用 64 个 KV Head 的 MHA，KV Cache 可以缩小到原来的八分之一。

这说明一个架构改动可能同时影响三个层面：

• 模型层：多个 Query Head 共享 K/V；
• Kernel 层：Attention 的读取和线程映射发生变化；
• 系统层：同一张 GPU 可以容纳更多并发请求。

五、把显存优化理解为交换

几乎所有显存优化都不是免费的。

做技术选型时，应该把问题改写成：“当前最稀缺的是显存、带宽、计算还是延迟？我愿意用什么资源交换？”

六、训练与推理的容量规划顺序

6.1 训练

1. 根据配置估算参数量；
2. 按优化器和精度计算静态状态；
3. 估算激活上界；
4. 判断是否必须进行参数分片；
5. 根据机器拓扑安排 TP、FSDP/DP 和 PP；
6. 留出通信 Buffer 与分配器碎片空间；
7. 用一个较小 Batch 实测峰值显存，再反推可用配置。

6.2 推理

1. 计算权重显存；
2. 计算目标并发和上下文长度下的 KV Cache；
3. 为 CUDA Graph、Workspace 和框架预留空间；
4. 决定 TP 数量与量化格式；
5. 决定 max_model_len、并发上限和显存利用率；
6. 用真实 Prompt 长度分布压测，而不是只测固定短输入。

6.3 把公式固化成容量估算器

理论公式适合白板推导，工程上更适合把假设写入一个可以审计的小工具。下面的函数故意不调用任何深度学习框架，便于检查单位和输入：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from dataclasses import dataclass

GIB = 1024 ** 3

@dataclass
class ModelConfig:
    layers: int
    hidden_size: int
    query_heads: int
    kv_heads: int
    head_dim: int
    parameters: int

def weight_gib(parameters: int, bytes_per_weight: float) -> float:
    return parameters * bytes_per_weight / GIB

def training_static_gib(parameters: int, bytes_per_parameter: float = 16) -> float:
    """BF16 参数/梯度 + FP32 主权重 + Adam m/v 的常用近似。"""
    return parameters * bytes_per_parameter / GIB

def kv_cache_gib(
    cfg: ModelConfig,
    batch_size: int,
    cached_tokens_per_request: int,
    bytes_per_element: int = 2,
) -> float:
    elements = (
        2
        * cfg.layers
        * cfg.kv_heads
        * cfg.head_dim
        * batch_size
        * cached_tokens_per_request
    )
    return elements * bytes_per_element / GIB

这个估算器还没有考虑 TP 切分、量化 Scale、对齐、块内碎片和运行时 Workspace。它的意义不是取代框架，而是把“我们假设了什么”显式保存下来。实测峰值与理论值不一致时，就可以逐项寻找缺失状态。

七、技术 Q&A

Q1：为什么 7B 模型的 BF16 权重约 14GB，标准 AdamW 训练却可能超过 100GB？

14GB 只计算了 7B × 2 Bytes 的模型权重。混合精度 AdamW 训练还要保存 BF16 梯度、FP32 主权重、FP32 一阶动量和 FP32 二阶动量，常用静态近似为 16 Bytes/参数，即约 112GB。实际训练还需要激活、临时张量、通信 Bucket 和 CUDA Runtime，所以 112GB 仍不是完整峰值。

Q2：为什么 GQA 对参数量影响有限，却能显著降低 KV Cache？

GQA 只缩小 K、V 两个投影以及对应缓存，Attention 中 Q 和输出投影、FFN、Embedding 都没有同比缩小，所以总参数量下降有限。KV Cache 只保存每层 K/V，它与 kv_heads 成正比；KV Head 从 64 减到 8 时，这部分缓存理论上直接缩小八倍。

Q3：ZeRO-3、Activation Checkpointing 和 INT4 量化分别解决什么状态？

ZeRO-3 分片训练期的参数、梯度和优化器状态；Activation Checkpointing 减少训练期保存的激活，用反向重计算交换显存；INT4 量化主要压缩推理权重，并降低权重读取带宽。三者作用对象不同，不能互相替代，但可以组合。

Q4：理论容量估算应该如何与运行时测量闭环？

先用公式得到静态下界和动态上界，再在目标硬件上分别测启动后、Prefill 峰值、Decode 稳态和压力场景峰值。PyTorch 可结合 memory_allocated、memory_reserved、Memory Snapshot 与 Profiler；推理引擎还应记录 KV Block 数、抢占次数和缓存命中率。理论模型负责解释，运行测量负责校准。

八、系列导航

下一篇：LLM 自回归推理的执行路径

九、参考资料

原始论文与技术报告

• Attention Is All You Need：Transformer 参数结构和计算路径的起点。
• LLaMA 2: Open Foundation and Fine-Tuned Chat Models：用于对照真实 Decoder-only 模型配置。
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models：训练状态分片的核心论文。
• PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel：FSDP 的工程经验与扩展性分析。
• GQA: Training Generalized Multi-Query Transformer Models：理解 KV Head 数量与 KV Cache 的关系。
• Efficient Memory Management for Large Language Model Serving with PagedAttention：推理阶段 KV Cache 分页管理。

文档与进一步阅读

• Transformer Math 101：参数量、FLOPs 和训练资源估算。
• PyTorch FSDP Documentation：分片策略和运行时行为。
• vLLM Documentation：推理显存参数与实际部署选项。
• NVIDIA H100 Tensor Core GPU Architecture：硬件显存、带宽和互联规格。
• AIInfraGuide：Transformer 参数、训练显存、ZeRO/FSDP 与 KV Cache 的中文技术资料，MIT License。

一、目标

Kubernetes(简称K8S) 是容器和集群管理的标准。Kubernetes 集群是由多个计算机（可以是物理机、云主机或虚拟机）组成的一个独立系统，通过 Kubernetes 容器管理系统，实现部署、运维和伸缩 Docker 容器等功能。本次搭建主要覆盖以下内容：

建立一个 Kubernetes 集群，包含一个主节点和两个工作节点，在集群上练习 kubectl 命令的基本操作。

练习通过命令行和 YAML 创建 Pod、Deployment 和 Job，并掌握 HPA。

练习为 Deployment 创建 Service，并通过 NodePort 暴露服务，再从客户端访问该服务。

为集群安装 LoadBalancer 软件，准备可用子网，并通过 LoadBalancer 方式暴露服务。

为集群安装 ingress-nginx 并验证。

为集群准备 NFS Server，安装 NFS Subdir External Provisioner，然后创建 PersistentVolumeClaim 并验证。

下载安装 Helm，用它安装 Rancher Dashboard，然后在 Dashboard 中管理集群并创建 WordPress 应用。

说明：部分镜像如 busybox、perl 等通过其他服务器提前拉取并打包到本地，再导入本地虚拟机使用。

二、安装并配置Docker

先配置 Docker 的 apt repository。

添加 Docker 官方 GPG key：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ sudo apt-get update
$ sudo apt-get install ca-certificates curl
$ sudo install -m 0755 -d /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
$ sudo chmod a+r /etc/apt/keyrings/docker.asc
Add the repository to Apt sources:
$ echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt-get update
# step 1: 安装必要的一些系统工具
sudo apt-get update
sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common
# step 2: 安装GPG证书
curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -
# Step 3: 写入软件源信息
sudo add-apt-repository "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"
# Step 4: 更新并安装Docker-CE
sudo apt-get -y update
sudo apt-get -y install docker-ce

或者安装制定版本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

$ apt-cache madison docker-ce | awk '{ print $3 }'
$ VERSION_STRING=5:20.10.24~3-0~ubuntu-jammy
$ sudo apt-get install docker-ce=$VERSION_STRING docker-ce-cli=$VERSION_STRING
# apt list --installed | grep docker
Set version lock
# apt-mark hold docker-*  containerd.io
List version locked software
# apt-mark showhold
Unlock the software
# apt-mark unhold docker-*
# vi /etc/docker/daemon.json
{
"oom-score-adjust": -1000,
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "5"
},
"exec-opts": ["native.cgroupdriver=systemd"],
"max-concurrent-downloads": 10,
"max-concurrent-uploads": 10,
"bip": "169.254.123.1/24",
"dns": ["202.201.0.133"],
"storage-driver": "overlay2",
"storage-opts": ["overlay2.override_kernel_check=true"]
}
}
# systemctl daemon-reload
# systemctl restart docker
# mkdir /etc/systemd/system/docker.service.d
# cd /etc/systemd/system/docker.service.d/
# vi http_proxy.conf
[Service]
Environment="HTTP_PROXY=http://noc:8912027@cg.lzu.edu.cn:8080"
Environment="HTTPS_PROXY=http://noc:8912027@cg.lzu.edu.cn:8080"
Environment="NO_PROXY=localhost,127.0.0.1,harbor.lzu.edu.cn"
# systemctl daemon-reload
# systemctl restart docker

这部分和 Docker 单独安装流程基本一致，下面保留最终安装效果，然后继续 Kubernetes 相关配置。

Linux全局代理添加

1
2
3
4
5
6

export HTTP_PROXY=http://noc:8912027@cg.lzu.edu.cn:8080
export HTTPS_PROXY=http://noc:8912027@cg.lzu.edu.cn:8080
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,*.lzu.edu.cn
export http_proxy=http://noc:8912027@cg.lzu.edu.cn:8080
export https_proxy=http://noc:8912027@cg.lzu.edu.cn:8080
export no_proxy=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,*.lzu.edu.cn

安装cri-dockered

1
2
3
4

# wget http://bigdata.cg.lzu.edu.cn/kubernetes/cri-dockerd_0.3.13.3-0.ubuntu-jammy_amd64.deb
# dpkg -i cri-dockerd_0.3.13.3-0.ubuntu-jammy_amd64.deb
# systemctl daemon-reload
# systemctl start cri-docker

关闭swap

命令行swapoff –a直接关闭

1

# vi /etc/fstab  注释掉swap引导项

查看br_netfilter模块和overlay是否被内核加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# lsmod | grep br_netfilter
# lsmod | grep overlay
# modprobe br_netfilter
# modprobe overlay
# cat <<EOF |  tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
# cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
# sysctl --system

set apt source of aliyun for kubernetes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | apt-key add
# echo "deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main" > /etc/apt/sources.list.d/k8s.list
# apt-get update
# apt-cache madison kubelet
# apt install kubeadm=1.26.8-00  kubelet=1.26.8-00  kubectl=1.26.8-00 -y
# systemctl enable kubelet
# apt-mark hold kubelet kubeadm kubectl
# source <(kubectl completion bash)
# echo 'source <(kubectl completion bash)' >>~/.bashrc
# vi /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"],
}
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --cgroup-driver=systemd"
# vi /usr/lib/systemd/system/cri-docker.service
[Service]
ExecStart=/usr/bin/cri-dockerd --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9 --container-runtime-endpoint fd://
# containerd config default > /etc/containerd/config.toml
Reboot the service:
systemctl daemon-reload
systemctl restart containerd.service
systemctl restart docker.service
systemctl restart cri-docker

三、安装kubernetes

control node:

1

# kubeadm version

1
2
3
4
5
6

# kubeadm init --apiserver-advertise-address=192.168.111.135 --control-plane-endpoint=192.168.111.135 \
--pod-network-cidr=10.244.0.0/16 --service-cidr=10.245.0.0/16  \
--image-repository registry.aliyuncs.com/google_containers \
--ignore-preflight-errors=Swap  \
--kubernetes-version=v1.26.8  \
--cri-socket unix:///var/run/cri-dockerd.sock

1
2
3
4

# mkdir -p $HOME/.kube
# cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
# chown $(id -u):$(id -g) $HOME/.kube/config
# kubectl get node

这里显示了一个控制节点docker，因为我使用的是docker主机名

worker node 加入集群（需要将ip地址改为对应的worker节点虚拟机）:

1
2
3
4

# kubeadm join 192.168.101.100:6443 --token 7k09zz.6ogjsk85qsqbc8wx \
--discovery-token-ca-cert-hash sha256:391c3cb957ec1a9e2f67b1516768d69029e712f4ca98e5b49d9cd8b651dde93d \
--control-plane  \
--cri-socket unix:///var/run/cri-dockerd.sock

由于当前设备只能启动一台虚拟机，这里没有继续展示 worker 节点加入过程，后续操作在单节点控制平面上完成。

1

# kubectl describe nodes docker

Delete the tain for control node in single node environment:

1
2

# kubectl taint node docker node-role.kubernetes.io/control-plane-
# kubectl taint node docker node.kubernetes.io/not-ready-

安装calico

1
2
3
4
5
6
7
8
9
10

# wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/tigera-operator.yaml
# wget https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/custom-resources.yaml
# vi custom-resources.yaml
ipPools:
- blockSize: 24
cidr: 10.244.0.0/16
# kubectl create -f tigera-operator.yaml
# kubectl create -f custom-resources.yaml
# kubectl get ns
# kubectl get node -o wide

安装metric-server

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# wget http://bigdata.cg.lzu.edu.cn/kubernetes/metrics-server-v0.7.1.tar
# docker image load -i metrics-server-v0.7.1.tar
# vi ./metrics-server/manifests/base/deployment.yaml
containers:
- name: metrics-server
image: gcr.io/k8s-staging-metrics-server/metrics-server:v0.7.1
imagePullPolicy: IfNotPresent
command:
- /metrics-server
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
# kubectl apply -k ./metrics-server/manifests/base/
# kubectl get pod -n kube-system | grep metric
# kubectl get service -A

1
2

# kubectl get pod -A
# kubectl get pods -n kube-system -o wide

1
2

# kubectl top nodes
# kubectl top pod -n kube-system

可以看到所有namespace都成功运行，配置成功。

四、练习kubectl基本命令

4.1 pod 基本操作

查看kubernetes集群信息

1

# kubectl cluster-info

查看kubernetes版本

1
2

# kubectl version
# kubectl version --short

查看kubernetes所支持的api-version

1

# kubectl api-versions

删除节点及重新加入

步骤1、通过kubeadm drain命令把节点设置为维护模式，会把已经在该节点上运行的业务pod驱逐到其他节点运行

1
2

# kubectl drain node03 --delete-emptydir-data --force --ignore-daemonsets
# kubectl get node

步骤2、删除这个节点

1

# kubectl delete nodes node03

步骤3、清空节点上的配置

1

# kubeadm reset（不管是master还是worker节点清空kubernetes配置都使用该命令）

v1.24以后使用docker-ce时需添加–cri-socket unix:///var/run/cri-dockerd.sock

1

# kubeadm reset --cri-socket unix:///var/run/cri-dockerd.sock

步骤4、重新加入集群

配置namespace练习

1
2
3
4
5

# kubectl get namespaces
# kubectl get ns
# kubectl create namespace ns1
# kubectl delete namespaces ns1
# kubectl config set-context --current --namespace=default

查看节点以及服务

1
2
3

# kubectl get service -A
# kubectl get node
# kubectl get service -A

五、使用命令行和yaml文件创建pod

5.1 Pod创建

查看pod

1
2
3
4

# kubectl get pod
# kubectl get pod -n kube-system
# kubectl get pod --all-namespaces
# kubectl get pod –A

创建pod，创建pod时可带诸多参数，运行kubectl run –h查看更多即可

1
2

kubectl run NAME --image=image  [--env="key=value"]  [--port=port]  [--labels=label=value]  [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...] [options]
# kubectl run pod1 --image=nginx

删除pod，增加参–force可加快删除速度

1

# kubectl delete pod pod1

1
2

# kubectl run pod1 --image=nginx --port=80
# 或kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent

集群内每一个pod都会获得一个地址(pod地址是相对临时的，service地址才是相对稳定的)

1

# kubectl get pod -o wide

通过IP访问pod

1

# curl http://10.244.239.9

在pod里执行命令

1

# kubectl exec  pod1 -- ls /usr/share/nginx/html

物理机和pod互拷文件

1
2
3

# kubectl cp /etc/hosts pod1:/usr/share/nginx/html/
# kubectl cp pod1:/usr/share/nginx/html/hosts /root/hosts
# kubectl cp pod1:/usr/share/nginx/html/ /opt/

进入pod里并获取bash

1
2
3

# kubectl exec -it pod1 -- bash
root@pod1:/#
root@pod1:/# exit

如果一个pod有多个容器默认进入的是第一个容器，想进入指定容器用-c指定容器名。

查看pod里的输出，如果一个pod有多个容器，需要使用-c指定查看哪个容器的输出。

1

# kubectl logs pod1

使用yaml的方式来创建pod可以在文件里指定更多的属性。

1
2
3

# mkdir pod ; cd pod
# kubectl run pod2 --image=nginx --dry-run=client -o yaml > pod2.yaml
# cat pod2.yaml

*YAML文件写法是分级的，子级和父级之间要缩进2个空格(不能按Tab键)，子级的第一个位置可以以“-”开头，这个“-”和父级对齐。

YAML文件里第一级常见参数主要有以下四个：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

apiVersion: 指定pod的apiVersion，固定值v1
kind: 指定当前yaml要创建的类型是pod，与apiVersion值是对应的
metadata:用于指定pod的元数据信息，包括pod名、pod标签和所在命名空间等信息
spec:定义容器及各种策略
# vi pod3.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod3
name: pod3
spec:
containers:
- command: ["sh","-c","echo aa;sleep 1000"]
image: nginx
imagePullPolicy: IfNotPresent
name: c1
resources: {}
- image: nginx
imagePullPolicy: IfNotPresent
name: c2
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

使用YAML文件创建pod：

1
2
3
4

# kubectl apply -f pod3.yaml
# kubectl get pod
# kubectl logs pod3 -c c1
# kubectl logs pod3 -c c2

查看pod属性

1

# kubectl describe pod pod3

进入pod并获取bash

1
2

# kubectl exec -it pod3 -- bash
# kubectl exec -it pod3 -c c2 -- bash

删除pod

1

# kubectl delete -f pod3.yaml

创建deployment

1

# kubectl create deployment nginx --image=nginx --replicas=2

查看deployment

1

# kubectl get deployments.apps

修改镜像下载策略以提高速度

1
2

# kubectl edit deployments.apps nginx
imagePullPolicy: Always

修改副本数

1

# kubectl scale deployment nginx --replicas=4

删除deployment

1

# kubectl delete deployments.apps nginx

通过yaml方式创建depoyment

1
2

# kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > d1.yaml
# vi d1.yaml

1

# kubectl apply -f d1.yaml

1
2
3
4

# kubectl get deployments.apps
# kubectl get deployments.apps -o wide
# kubectl get pod
# kubectl get pod -o wide

删除一个pod后，会自动创建出一个新的pod，以满足replicas数。

1
2

# kubectl delete pod nginx-57cc89bc77-2g66z
# kubectl get pod

删除deployment

1

# kubectl delete -f d1.yaml

当deployment的pod负载较大，需要更多的pod来分摊负载，就需要管理员手动去调整副本数。

可以设置让k8s根据pod负载情况自动去调整deployment里pod的副本数，这可以通过水平自动更新HPA(Horizontal Pod Autoscalers)来实现,通过检查pod的cpu负载通知deployment让其自动更新pod数量。

1
2

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]
--cpu-percent如果不写默认是80.

查看当前是否有hpa配置

1

# kubectl get hpa

创建hpa

1
2

# kubectl get deployments.apps
# kubectl autoscale deployment nginx --min=2  --max=10

查看

1
2

# kubectl get horizontalpodautoscalers.autoscaling
# kubectl scale deployment nginx --replicas=1

删除hpa

1

# kubectl delete horizontalpodautoscalers.autoscaling nginx

修改deployment的配置，设置每个容器的资源限制

1
2
3
4
5
6
7

# kubectl edit deployments.apps nginx
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
resources:
requests:
cpu: 100m

创建deployment副本数为1个

1

# kubectl scale deployment nginx --replicas=1

创建新的HPA，使得每个pod的cpu数最大使用率不超过70%

1

# kubectl autoscale deployment nginx --min=1 --max=5 --cpu-percent=70

为deployment创建一个服务，类型为NodePort

1
2

# kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort
# kubectl get service

在任一客户端安装ab测试对其进行压测：

1
2

# yum install httpd-tools –y   (# apt install apache2-utils)
# ab -t 600 -n 1000000 -c 1000 http://192.168.111.135:30267/index.html

随着请求CPU负载增加pod自动扩展。

负载降低后pod数不是立刻减少，要等到一段时间，默认是5m，目的是防止pod数的抖动。

升级镜像可以通过以下三种方法：

1、kubectl edit deploy

2、修改yaml文件，然后执行kubectl apply -f yaml文件

3、命令行方式修改。命令行方式可以记录镜像变更信息，回滚方便。

命令行升级deployment里镜像的语法：

1
2
3
4
5
6

kubectl set image deploy/名字  容器名=镜像  <--record>
# kubectl set image deploy/nginx nginx=nginx:latest
# kubectl set image deploy/nginx nginx=nginx:1.21
# kubectl get deployments.apps -o wide
# kubectl set image deploy/nginx nginx=nginx:1.20
# kubectl get deployments.apps -o wide

查看镜像变化过程，由于没有记录无法查看，

1

# kubectl rollout history deployment nginx

更新镜像时增加–record选项记录更新以方便镜像回滚。

1
2
3
4

# kubectl set image deploy/nginx nginx=nginx:1.20  --record
# kubectl set image deploy/nginx nginx=nginx:1.21  --record
# kubectl rollout history deployment nginx
# kubectl get deployments.apps nginx -o wide

如果变更后的镜像有问题，我们可以把镜像回滚到变更之前的版本，回滚的语法是：

1
2
3

kubectl rollout undo deployment 名字 --to-revision=版本
# kubectl rollout undo deployment nginx --to-revision=5
# kubectl get deployments.apps nginx -o wide

对deployment可能会有多个pod，使用滚动更新不是一次性全部更新，而是先更新几个pod镜像，更新完成后再更新几个，直至将所有pod全部更新完毕。

rollingUpgrade主要涉及两个参数：

1、maxSurge：指定一次创建几个pod，可以是百分比，也可以是具体数字

2、maxUnavailable：用来指定最多删除几个pod，可以是百分比，也可以是具体数字

1
2
3
4
5
6

# kubectl edit deployments.apps nginx
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate

默认为25%。可修改为1进行查看，即变更镜像时删除一个创建一个。

1
2
3
4

# kubectl scale deployment nginx --replicas=5
# kubectl set image deploy/nginx nginx=nginx:1.21
# kubectl set image deploy/nginx nginx=nginx:1.20
# kubectl get pod

因为docker现在被墙了，其他版本镜像无法拉取

5.2 job 练习： 计算圆周率小数点后 2000 位

job：执行一次性任务，如数据处理分析测试运算等。

创建一个yaml文件

1

# kubectl create job job3 --image=busybox --dry-run=client -o yaml -- sh -c "echo hello && sleep 30" > job3.yaml

对生成的yaml进行修改添加imagePullPolicy:IfNotPresent后创建job

1

# kubectl apply -f job3.yaml

当任务完成时job完成，pod状态变为Completed。

删除job

1

# kubectl delete jobs.batch job3

job练习：计算圆周率小数点后2000位

1
2
3

# kubectl create job job2 --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'
# kubectl get pod
# kubectl get jobs.batch

查看计算结果

1

# kubectl logs job2-le3gv

5.3 cronjob

cronjob是周期性的、循环的。（linux上使用cron周期性执行任务）

1

# kubectl get cronjobs.batch

创建cronjobs

1

kubectl create cronjob NAME --image=image --schedule=‘cron表达式' -- [COMMAND] [args...] [flags] [options]

创建一个每一分钟执行一次的cronjob

1

# kubectl create cronjob cjob1 --image=busybox --schedule="*/1 * * * *" --dry-run=client  -o yaml -- /bin/sh -c "echo hello && sleep 30" > cjob1.yaml

修改添加镜像下载策略imagePullPolicy: IfNotPresent

创建cronjob

1
2
3

# kubectl apply -f cjob1.yaml
# kubectl get cronjobs.batch
# kubectl get pod

每隔1分钟生成一个pod，该pod完成任务sleep 30后就结束。

Completed pod数由选项successfulJobsHistoryLimit决定，默认为3。

删除cronjob

1

# kubectl delete cronjobs.batch cjob1

5.4 StatefulSets

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

# vi headless-nginx.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
# kubectl apply -f headless-nginx.yaml
# vi stateful-nginx.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
minReadySeconds: 10
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: nginx:latest
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: web
# kubectl apply -f stateful-nginx.yaml

六、使用命令行和yaml文件创建deployment and job

6.1 deployment

1
2
3
4
5

# kubectl create deployment web1 --image=nginx --dry-run=client -o yaml > web1.yaml
# vi web1.yaml
# kubectl apply -f web1.yaml
# kubectl get deployments.apps -o wide
# kubectl get pod -o wide

1

# kubectl expose deployment nginx --name=web1 --port=80 --target-port=80

不使用–name指定服务名，则保持和deployment名字一致。

1

--port指服务端口， --target-port是后端pod运行服务的端口。

查看服务

1
2

# kubectl get svc
# kubectl get service -o wide

查看详细信息

1

# kubectl describe service web1

使用命令生成yaml文件

1

# kubectl expose deployment web1 --name=web1 --port=80 --target-port=80 --dry-run=client -o yaml > svc1.yaml

查看yaml文件

1

# vi svc1.yaml

使用yaml文件创建service

1

# kubectl apply -f svc1.yaml

查看

1

# kubectl get svc

删除服务

1

# kubectl delete -f svc1.yaml

6.2 服务发布

外部主机访问集群服务主要有三种方式：

1、NodePort

将服务映射到物理机(集群中所有节点)的某个端口提供外界访问

2、LoadBalancer

使用LoadBalancer给svc分配一个地址(外界可访问地址)，svc直接对外提供服务。

需要安装部署第三方工具metallb。

3、ingress

使用nginx-ingress实现反向代理，通过域名对外提供服务。

需要安装部署nginx-ingress控制器。

1
2
3

# kubectl expose deployment web1 --name=web1 --port 80 --type=NodePort
# kubectl get svc
# kubectl edit svc web1

Yaml文件为:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
labels:
app: web1
name: web1
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: web1
type: NodePort
status:
loadBalancer: {}

七、安装loadblancer

使用LoadBalancer需要安装部署第三方工具metalllb。

1

# kubectl edit configmap -n kube-system kube-proxy

修改 strictARP: true

下载部署metallb所需yaml文件

1
2
3

# mkdir ~/metallb
# cd ~/metallb/
# wget https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

部署metallb

可以修改配置文件添加imagePullPolicy: IfNotPresent然后进行部署

1

# kubectl apply -f metallb-native.yaml

查看

1
2
3

# kubectl get deployments.apps -n metallb-system
# kubectl get daemonsets.apps  -n metallb-system
# kubectl get pod -n metallb-system

创建一个外部地址池

1
2
3
4
5
6
7
8
9
10
11
12
13

# vi ipaddresspool.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
namespace: metallb-system
name: doc-l2-label
labels:
zone: east
spec:
addresses:
- 192.168.111.135/24
# kubectl apply -f ipaddresspool.yaml
# kubectl get ipaddresspools.metallb.io  -n metallb-system

修改地址池范围，指定可用地址

1
2
3
4

# kubectl edit ipaddresspools.metallb.io  -n metallb-system
spec:
addresses:
- 192.168.100.210 - 192.168.100.219

发布地址池：

1

# vi l2advertisement.yaml

1
2

# kubectl apply -f l2advertisement.yaml
# kubectl get l2advertisements.metallb.io -n metallb-system

创建一个pod

1

# kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent

为pod1创建一个名为svc1类型为LoadBalancer的服务

1
2

# kubectl expose pod pod1 --name=svc1 --port=80 --type=LoadBalancer
# kubectl get svc

访问EXTERNAL-IP即可。

删除svc1和pod1

1
2

# kubectl delete svc svc1
# kubectl delete pod pod1

八、安装ingress-nginx

官网：https://kubernetes.github.io/ingress-nginx/

1
2
3
4

# mkdir ~/ingress-nginx
# cd ~/ingress-nginx/
# wget http://bigdata.cg.lzu.edu.cn/kubernetes/ingress-nginx/deploy.yaml
# cat  deploy.yaml | grep image

所需镜像国内网络无法下载，从国外下载打包回来。并修改yaml文件中镜像名称和实际镜像名称一致。

校内镜像下载： wget http://bigdata.cg.lzu.edu.cn/kubernetes/ingress-nginx-v1.7.0.tar

下载镜像文件并在所有节点加载镜像。并根据实际镜像tag修改deploy.yaml文件。

1
2

# kubectl apply -f deploy.yaml
# kubectl get ns

1
2
3

# kubectl get pod -n ingress-nginx
# kubectl get svc -n ingress-nginx
# kubectl get configmaps -n ingress-nginx

修改pod副本数为worker数

1

# kubectl scale deployment ingress-nginx-controller -n ingress-nginx --replicas=2

1

# kubectl get svc -n ingress-nginx

创建一个名为pod1的pod

1

# kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent

为这个pod1创建名为pod1的svc

1

# kubectl expose pod pod1 --name=pod1 --port 80

创建ingress策略

1
2

# kubectl create ingress pod1.lzu.edu.cn --class=nginx --rule=pod1.lzu.edu.cn/*=pod1:80
# kubectl get ingress

手动添加解析后访问

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23