Jimmy Song – 工作负载实践

训练、推理与分离式系统：工作负载的系统观

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

更多 GPU 缩短计算时间的前提，是通信、输入和同步跟得上；工作负载的形状决定平台的形状。

训练是一个同步问题

训练不只是前向传播，它是一个不断循环的链条：输入准备、前向计算、反向计算、梯度同步、优化器更新、检查点、评估，任何一个环节都可能成为主导。这正是互连与集合通信中扩展效率方程的应用场景：先测单卡、再测单机、最后测多机，才知道瓶颈在哪一环。

检查点不是事后想法。如果一个作业要跑一周，恢复契约就是硬件决策的一部分。

推理是一个尾延迟问题

推理服务关心排队、批处理、token 生成、上下文长度、预热、模型加载和尾延迟。GPU 可能利用率很高，而用户可感知的延迟已经违反 SLO，仅按平均利用率自动伸缩，可能反应太迟或太早。

信号	回答什么
队列深度	请求在等什么
首 token 时间（TTFT）	用户等多久看到第一个字
token 间延迟（ITL）	生成过程是否流畅
活跃序列数	批处理压力
KV 缓存压力	上下文容量还剩多少
模型加载时间	扩容/故障恢复的速度

表 1: 推理服务的正确信号

这些信号的物理根因展开见LLM 推理的物理层，指标口径见GPU 指标语义。

模型、数据与控制平面

一个生产 AI 平台把模型工件和缓存与请求服务的 Pod 分开：它定义模型如何到达、如何校验、引擎在哪里构建、权重如何缓存、版本如何滚动、故障节点如何预热。这正是 Kubernetes 开始像 AI 应用平台而非通用容器调度器的地方。

平面	主要关切	有用信号
模型	权重、画像、引擎、版本	缓存命中、加载时间、摘要
服务	流量、批处理、副本、延迟	TTFT、ITL、队列深度、吞吐
加速器	GPU 分配、内存、拓扑	利用率、余量、错误
数据	数据集搬运与局部性	读带宽、缓存命中、I/O 等待
控制	发布、策略、自动伸缩、恢复	调谐与准入状态

表 2: 生产 AI 平台的五个平面

这张表与生产架构的平面划分互补：那里讲集群治理平面，这里讲工作负载侧平面。

多节点推理

超大模型可能被切分到多块 GPU 或多个节点。系统因此继承训练同样的互连与拓扑问题，但 SLO 是请求路径而非批次时间。一个吞吐上看起来不错的设计，如果同步或网络抖动出现在关键路径上，仍可能有不可接受的尾延迟。预填充/解码分离（PD 分离）正是这一约束下的产物，见Kthena与LLM 推理物理层的讨论。

总结

训练问“每步同步花了多少”，推理问“第 99 个百分位的请求等了多久”，多节点系统问“关键路径上有几次跳变”。用这三问审视工作负载，再选平台组件，顺序不能反。本章是工作负载实践部分的序章：vLLM、PyTorch、Ray/KubeRay 与拓扑约束分别把这三种系统观落到具体引擎。

LLM 推理的物理层：预填充、解码与 KV 容量账

Jimmy Song — Fri, 28 Aug 2026 00:00:00 +0000

推理平台的所有配置争论（并发、批大小、显存水位、共享粒度）最终都归结为两笔物理账：一笔算力账，一笔显存账。

vLLM一章从资源治理视角讨论吞吐与尾延迟；本章补上它的物理地基：为什么解码受带宽屋顶线约束、为什么 KV cache 是容量货币、为什么连续批处理和分页 KV 是必然设计。这些账同样决定Kthena一类的推理调度器在优化什么。Roofline 模型的推导见微架构，显存机制见显存管理。

两阶段：同一模型，两种性格

预填充（prefill）：一次性并行处理整条 prompt，生成第一个 token。大矩阵乘法，受算力屋顶线约束，是 GPU 的舒适区。
解码（decode）：此后每生成一个 token，都要带着全部历史（KV cache）再算一遍前向。每步计算量小，但每步都要把全部模型权重从显存读一遍，受带宽屋顶线约束。

由此得到推理平台最实用的一行公式：

单路解码速度上限 ≈ 显存带宽 ÷ 权重量
H100 (3.35 TB/s) 跑 70B BF16 (140 GB) ≈ 24 token/s（物理规律，不是软件差）

它解释了三件事：量化（FP8 权重减半）直接让解码翻倍；换带宽更高的卡（H200）比换算力更高的卡对推理更有效；以及批量推理的本质是把“读一遍权重”摊到多个请求上，把算术强度从 1 提高到 B。吞吐随批量大致线性上升，直到撞上算力屋顶线或显存容量。

KV cache：容量货币

自回归生成需要缓存每个 token 的 Key/Value 向量：

每 token KV 字节数 = 2(K与V) × 层数 × KV头数 × 头维度 × 精度字节
Llama-3-70B (80层, 8 KV头, 头维128, BF16) = 320 KB/token
→ 一个 4k 上下文的请求 ≈ 1.25 GB 显存

GQA（分组查询注意力）是现代模型 KV 变小的原因：Llama-3-70B 用 8 个 KV 头对应 64 个查询头，KV 比 MHA 等效结构小 8 倍。架构选择直接等于容量选择。

推理容量公式（平台做容量规划时的第一行代码）：

可并发请求数 ≈ (显存总量 × 利用率 − 权重 − 激活/开销) ÷ (每token KV × 平均上下文)

示例（H100 80G，利用率 0.9，4k 平均上下文）：8B 模型单卡约 100+ 并发；70B 需要 TP=8 才有合理并发；32B 级模型在单卡只剩个位数并发，这就是“中等模型为什么也要 TP”的算术。

连续批处理与分页 KV：两次必然的进化

静态批（攒一批一起进出）的浪费是显然的：长短请求互相等，新请求必须等整批结束。**连续批处理（continuous batching）**在每个解码步重新组批：完成的请求下车、排队的新请求上车。这是 vLLM/TRT-LLM/SGLang 的共同底座。

连续批处理把压力转移到内存管理：早期引擎按“最大长度”为每个请求预留连续显存，浪费 60–80%。分页 KV（PagedAttention）把操作系统的分页机制搬进显存：

操作系统概念	分页 KV 对应
物理页（4KB）	KV 块（默认 16 token）
页表	每请求的 block table
写时复制（COW）	采样 n>1 / beam 分叉时共享块
共享库页缓存	前缀缓存：相同 system prompt 的请求共享已算好的块
swap	显存不足时把块换到主机内存

表 1: 分页 KV 与操作系统分页的对应

其中前缀缓存对平台价值最大：RAG/Agent 类“长固定前缀 + 短输出”的流量，块级节省可达 90% 以上，同样显存服务多一个数量级的并发，且 TTFT 大幅下降。前缀命中率应当与 KV 水位一起纳入容量模型与验收指标。

分块预填充：吞吐与尾延迟的调节阀

一条 16k prompt 的预填充是一个百毫秒级的大 kernel；若引擎“先做完预填充再解码”，期间所有正在解码的请求都停摆，TTFT 与 ITL（token 间延迟）天然冲突。**分块预填充（chunked prefill）**把长 prompt 切块掺进解码批逐步消化，用少量 TTFT 换取 ITL 的稳定。更激进的方案是预填充/解码分离部署（如 Kthena 一类调度器的 PD 分离模式），把冲突移到集群层，代价是 KV 迁移与路由复杂度。

与共享/配额层的配合：一道必考题

推理引擎按 gpu_memory_utilization × 物理显存 计算自己的 KV 池。在软切分配额（HAMi 的 nvidia.com/gpumem）下，若 Pod 配额 40GB 而机器 80GB、utilization 拍 0.9，引擎会按 72GB 规划显存池，配额拦截层在池初始化时注入 OOM，Pod 进入启动崩溃循环。正确做法是让两个数字来自同一个变量：

gpumem 配额 ≈ 权重/TP + 期望KV池 + 激活/图/上下文底噪(约2-3GB)
gpu_memory_utilization ≈ gpumem ÷ 物理显存 ← 从配额反推, 而不是拍 0.9

同理，core 份额（nvidia.com/gpucores）对解码型负载的限流效果天然偏弱：它管的是执行时间，而解码的瓶颈在带宽（见微架构的 Roofline 模型）。推理租户的配额要以显存为主、算力为辅，且同卡邻居的负载类型比份额数字更影响尾延迟（见vLLM的抖动分析与指标语义）。

常见误区

误区	真相
推理 GPU 只用了 5% 算力，太浪费	解码受带宽屋顶线约束，5% 算力可能是物理最优；看 DRAM 指标
并发越大吞吐越高	过拐点后只伤延迟，且显存容量先耗尽
前缀缓存是个小优化	长固定前缀流量下是数量级的容量与 TTFT 收益
量化伤质量所以不用	权重量化在评测上普遍近无损，且是带宽优化的第一手段
vLLM 已经做多租户了，平台不用管	引擎内是请求级公平；副本层的配额、伸缩、隔离仍是平台职责
分离部署一定更好	引入 KV 迁移与路由复杂度；规模或 SLO 不极端时分块预填充常常足够

表 2: 推理物理层的常见误区

总结

推理的物理层可以压缩成三句话：解码是带宽问题（单路上限 = 带宽 ÷ 权重量，量化与高带宽卡是正解）；KV cache 是容量货币（并发、模型选型、TP 宽度都按 KV 账算）；批处理与分页是结构解（连续批把算术强度提上去，分页把浪费降下来，前缀缓存再省一个量级）。下一章vLLM把这些物理事实映射为资源治理旋钮；可观测告诉你用哪三个数字确认系统运行在预期区间。

参考资料

vLLM：推理吞吐与尾延迟的资源真相

Jimmy Song — Tue, 30 Dec 2025 05:03:12 +0000

推理平台的真正挑战，不在于极限吞吐，而在于如何用资源契约守住尾延迟的底线。

在线推理平台最容易掉进一个“看起来很合理、结果很不稳定”的陷阱：把吞吐（tokens/s、QPS）拉满之后，尾延迟（p95/p99）反而开始失控；更糟的是，这种失控常常不是线性恶化，而是突然抖动、周期性爆炸、或者在某些请求形态/租户组合下才出现。

vLLM 之所以值得单独一章讨论，是因为它把“吞吐与尾延迟冲突”的核心机制暴露得非常清楚：并发与批处理把 GPU 利用率推高的同时，也把显存（KV cache，Key-Value Cache）与调度队列变成了系统的“弹性瓶颈”。当共享/隔离策略变化时，这个瓶颈会被放大或被抑制，最终决定平台的可预测性。

本章将从 vLLM 的并发与显存行为出发，回答三个工程问题：

为什么吞吐优化天然会冲击尾延迟？冲击发生在哪些资源环节？
平台应该如何定义“资源请求”与“验收指标”，让容量与体验可讨论、可评审？
哪些配置组合最容易引发系统性抖动（jitter），以及如何提前规避？

吞吐与尾延迟：不是权衡口号，而是队列与显存的物理后果

在在线推理场景中，提升“吞吐”通常有三种主要手段：

提高并发：即同时活跃的请求数量（更多 sequences / requests）。
加大批处理：将更多 token 计算合并进一次或更少次数的 GPU kernel 调用（continuous batching，连续批处理）。
提高占用率：尽量让 GPU 计算单元持续忙碌，减少空洞和上下文切换。

这些手段的共同副作用是：请求进入 GPU 的等待时间上升，且等待时间的方差变大（队列效应）。尾延迟通常在以下两种情况下爆炸：

短请求被长请求“拖住”：混合工作负载下，批处理与调度更倾向于追求整体吞吐，导致短请求在队列里等待“拼批”或被长请求占用算力窗口。
显存接近水位线：KV cache 越逼近显存上限，越容易触发保守策略（拒绝、回退、offload、或者更频繁的调度切片），从而产生非线性的延迟抖动。

因此，在推理平台中，吞吐与尾延迟的矛盾，往往不是“算法优化 vs 用户体验”的抽象冲突，而是两个非常具体的资源事实：

调度队列的排队时间（谁先算、谁后算、如何拼批）
KV cache 的驻留与碎片（显存水位、可用块、回收/分配成本）

vLLM 的工程价值在于：它把这两件事做成了“可控旋钮”，也就意味着：你把旋钮拧到极致时，系统会以尾延迟或稳定性作为代价支付账单。

vLLM 的关键资源模型：并发、KV cache 与“水位线管理”

理解 vLLM 的资源本质，抓住以下两点即可：

并发不是免费：每个活跃序列都要占 KV cache

对于大多数 Transformer 推理而言，KV cache（Key-Value Cache） 是决定显存曲线的主项。直观来看：

并发越高 → 同时活跃的序列越多 → KV cache 占用越大
上下文越长 / max_model_len 越大 → 单序列 KV cache 上限越高
输出越长 → 序列更久才结束 → KV cache 驻留时间更长

这意味着平台在讨论“QPS 能跑多少”之前，必须先回答一个更硬的问题：在给定显存与模型配置下，你能稳定承载多少“活跃 token”。吞吐的上限通常不是算力，而是显存与调度策略共同限定的“并发安全区”。

连续批处理提升吞吐，但会把尾延迟变成“队列治理问题”

vLLM 的 continuous batching（连续批处理）会不断把新 token 合入批次，从而提高 GPU 利用率。但连续批处理天然引入一个事实：

更大的批次通常意味着更高的平均吞吐
但也意味着单个请求更可能等待更久才能进入下一次计算窗口

因此，尾延迟治理的本质是“不要让队列变成黑箱”。你需要明确哪些请求优先、如何限制长尾请求对系统的占用、以及何时应该牺牲一点吞吐换取稳定性。

下图展示 vLLM 的资源模型以及吞吐与尾延迟的物理后果。左侧展示吞吐优化的三种手段（提高并发、加大批处理），代价是尾延迟风险（队列等待时间上升、显存接近水位线）。中间蓝色区域展示 KV cache 作为显存硬边界的三条规则：并发越高 KV cache 占用越大、上下文越长单序列上限越高、输出越长驻留时间越长。黄色区域展示 continuous batching 将尾延迟变成队列治理问题。右侧虚线框总结两个资源瓶颈：调度队列排队时间、KV cache 驻留与碎片。底部核心洞察：vLLM 把队列与显存做成了可控旋钮，拧到极致时以尾延迟或稳定性支付账单。

图 1: vLLM 的资源模型：并发、KV cache 与吞吐尾延迟的物理后果

平台应该怎么定义资源请求：从“GPU 张数”走向“可运营的推理配额”

Kubernetes 的原生资源模型让我们习惯于“请求 1 张 GPU”，但在线推理的真实瓶颈并不等价于“1 张卡”。如果平台只提供“GPU=1”这一维度，团队会通过提高并发/批处理去榨干吞吐，最终把尾延迟与抖动成本转嫁给平台。

更可运营的做法是：把推理资源请求拆成三层配额语义（不一定都暴露给用户，但平台需要内部具备）：

下图展示三层资源配额语义。第一层（蓝色区域）：硬资源（GPU + 显存安全余量），强调显存 headroom 不是浪费而是尾延迟稳定性的保险。第二层（黄色区域）：软配额（并发与上下限），包括最大并发序列数和最大上下文/输出长度，如果只控制 QPS 不控制上下文会得到平时很好偶尔爆炸的系统。第三层（绿色区域）：体验配额（SLO 绑定的可用吞吐 - Goodput），定义为在满足指定尾延迟 SLO 的前提下系统能持续输出的有效吞吐，如果 tokens/s 上去但 Goodput 没上去说明只是把抖动转移给用户。底部核心理念：从 GPU 张数走向可运营的推理配额，让资源请求与验收具备可讨论可评审的基础。

图 2: 三层资源配额语义：从 GPU 张数走向可运营的推理配额

硬资源：GPU + 显存安全余量（headroom）

GPU：依然以整卡（或 MIG slice）作为硬隔离单元最可靠。
显存 headroom：不要把显存用到“刚好满”。平台需要设定一个保守水位线，例如只允许 vLLM 使用显存的某个比例，其余留作碎片、峰值波动、驱动/通信开销与异常回退空间。这不是“浪费”，而是尾延迟稳定性的保险。

软配额：并发与上下限（Admission Control）

平台建议明确以下两个“准入阈值”：

最大并发序列数（max concurrent sequences）：超过就排队/拒绝，而不是让系统进入不可预测区。
最大上下文长度与最大输出长度（prompt/output cap）：它们决定 KV cache 的最坏情况上界。

如果你只控制 QPS，不控制上下文与输出长度，你会得到一个“平时很好、偶尔爆炸”的系统。

体验配额：SLO 绑定的“可用吞吐”（Goodput）

吞吐指标最好不要只看 tokens/s，而要引入 Goodput：在满足指定尾延迟 SLO 的前提下，系统能持续输出的有效吞吐。 这会迫使所有优化回到同一个目标：既要快、也要稳。

验收指标怎么定：别只测“平均”，要把尾延迟拆开测

为了让平台具备可运营性，在线推理的验收建议至少包含四组指标，且每组都要给出 p50/p95/p99（或至少 p95/p99）：

在介绍各项指标前，先说明其作用和意义。

TTFT（Time To First Token，首 token 延迟）：直接反映“队列与调度”是否健康。吞吐拉满时，TTFT 往往最先恶化。
TPOT（Time Per Output Token，输出 token 间隔）：反映生成阶段的稳定性。共享环境中，TPOT 抖动通常意味着算力争用、带宽争用或调度切片不稳定。
Throughput（tokens/s 与 Goodput）：
- tokens/s 反映吞吐能力
- Goodput 反映“在 SLO 下的吞吐”。如果 tokens/s 上去了但 Goodput 没上去，说明你只是把抖动转移给用户。
可靠性：拒绝率、OOM/回退率、重试率。尾延迟失控往往伴随拒绝、OOM、或回退策略触发。验收必须把这些作为“失败”而不是“另一个状态”。

实操建议：验收用例必须覆盖至少三种负载形态：

短 prompt + 短输出（典型聊天）

长 prompt + 短输出（RAG/长上下文检索）

短 prompt + 长输出（长文生成）

以及“混合形态”作为压测常态。

下图展示验收指标体系。顶部四个关键指标：TTFT（首 token 延迟）直接反映队列与调度健康、吞吐拉满时最先恶化；TPOT（输出 token 间隔）反映生成阶段稳定性、抖动意味着算力带宽争用；Throughput 包含 tokens/s 和 Goodput（SLO 下的吞吐），tokens/s 上但 Goodput 不上说明只是把抖动转移给用户；Reliability（可靠性）包括拒绝率、OOM/回退率、重试率，尾延迟失控往往伴随这些事件。中间展示四种验收负载形态：短 prompt+ 短输出（聊天）、长 prompt+ 短输出（RAG）、短 prompt+ 长输出（长文生成）、混合形态（压测常态）。底部绿色区域说明为什么要看 p50/p95/p99。底部核心原则：吞吐优化的收益是平均意义上的，尾延迟是最坏情况的，如果验收不看 p99 会把问题留给生产。

图 3: 验收指标体系：别只测平均，要把尾延迟拆开测

最容易引发系统性抖动的配置组合（以及为什么）

下面列出一些在 vLLM + Kubernetes 场景中最常见的“看似合理、实则高风险”的组合。它们的共同特点是：把系统推到了“显存水位线 + 队列效应”的非线性区间。

在介绍每种配置前，先说明其风险和表现。

把显存利用率设得过满 + 提高并发

典型表现：平时很稳，一旦某些请求变长或并发上冲，就出现 TTFT 飙升、TPOT 抖动、甚至 OOM。
原因：KV cache 分配与碎片会在高水位时变得脆弱，任何波动都会触发“分配失败/回退/拒绝”链式反应。
规避策略：设定显存 headroom，宁可牺牲一点峰值吞吐，也要保证“高峰不崩”。

混合长短请求但不做队列隔离或优先级

典型表现：短请求的 p99 被长请求拖到不可用；用户感知为“突然卡住”。
原因：continuous batching 在追求整体吞吐时，可能让短请求等待更久以换取更大的批次，长请求又延长了序列驻留时间。
规避策略：至少做到“按模型/租户/请求类型”分队列；必要时分开部署两套参数（高吞吐池 vs 低延迟池）。

上下文长度上限过大且不做准入

典型表现：少量超长上下文请求就能让整个服务抖动。
原因：超长 prompt 直接把 KV cache 推到最坏情况上界，导致其他请求在显存/调度上被挤压。
规避策略：对外暴露明确的 context cap；超长上下文走单独服务池或异步通道。

多租户共享同一张卡，但隔离手段不足

典型表现：单个租户的突刺会影响所有租户；TPOT 抖动明显。
原因：算力、显存带宽、PCIe/CPU/网络都可能成为干扰路径。没有足够隔离时，推理服务会出现“看不见的邻居”。
规避策略：
- 强隔离场景优先 MIG（Multi-Instance GPU，MIG）或至少整卡独占
- 共享场景必须配合严格准入（并发、上下文、输出）和监控/计量，否则就是“谁先抢到算谁的”

盲目追求更大 batch / 更高并发，而不绑定 SLO

典型表现：压测报告很好看，但线上体验很差。
原因：吞吐优化的收益是平均意义上的，尾延迟是最坏情况的；如果验收不看 p99，你会把问题留给生产。
规避策略：把 Goodput 作为核心 KPI：SLO 达标前提下的吞吐，才是平台应该交付的吞吐。

一套可落地的“推理资源契约”：让团队与平台可对齐

为了让推理平台可运营，建议把“资源请求与验收”固化成一份契约（可以写进平台文档或服务模板），至少包含：

模型与服务形态：模型版本、精度、并行策略（如有）
用户侧限制：最大上下文、最大输出、并发配额、速率限制
平台侧保障：GPU/MIG 规格、显存 headroom、隔离策略、调度队列策略
SLO 指标：TTFT/TPOT 的 p95/p99 目标，允许的拒绝率/错误率
验收用例：短/长/混合负载的固定脚本与基线阈值
容量结论：在 SLO 下的 Goodput（可用吞吐）与可承载并发区间

这样做的收益是：当某个团队说“我们要更高 QPS”，平台可以回答“在保持 p99 TTFT=… 的前提下，你可以提高并发到 X；如果你要更高，需要牺牲尾延迟或迁移到高吞吐池”，而不是陷入“感觉应该可以”的争论。

总结

vLLM 把在线推理的资源真相讲得很直白：

吞吐来自并发与批处理，但代价是队列等待与尾延迟风险。
显存（KV cache）是并发的硬边界，水位线决定稳定性。
共享与隔离策略会放大或抑制这种边界：隔离不足时，抖动是系统性问题，不是“调参没调好”。
平台要交付的不是“峰值 tokens/s”，而是“在 SLO 下的可用吞吐（Goodput）”。

在后续实验章节中，我们会把这些结论落到可复现实验：如何用不同的共享/隔离方案（整卡、MIG、共享数据平面等）去跑同一组 vLLM 负载，并用 TTFT/TPOT/p99 与 Goodput 给出可验证的取舍曲线。这样，你的 GPU 平台能力才能从“能跑”升级为“可预测、可验收、可治理”。

PyTorch：训练与微调的调度语义与抢占影响

Jimmy Song — Tue, 30 Dec 2025 05:02:56 +0000

训练平台的本质挑战不是“GPU 够不够”，而是如何把调度语义变成可治理的资源服务。

训练/微调与在线推理看似都“吃 GPU”，但它们对平台的压力点完全不同。推理更像排队系统（到达率、并发、尾延迟），训练更像生产流水线（持续吞吐、同步通信、拓扑敏感）。因此，推理平台做得好不等于训练平台就能跑得稳。训练要稳定、要效率，核心不在“能启动多少卡”，而在“能否持续产出有效步数”。

本章聚焦三个问题：

训练/微调的资源曲线是什么？为什么它比推理更敏感、也更容易被共享、抢占、碎片化击穿？
训练作业需要哪些调度语义？例如最小可用、成组调度、拓扑亲和、可抢占、可挂起。
资源紧张时怎么维持整体效率？抢占与弹性策略如何设计，才能让平台“忙而不乱、抢而不崩”。

训练/微调的资源曲线：稳定吞吐优先，而非瞬时峰值

训练与推理的性能瓶颈表现不同。在线推理常见“QPS 与 P99 的冲突”，而训练/微调则是“有效吞吐（有效 tokens/steps）与系统摩擦（通信/抖动/重启）的冲突”。

训练的关键资源特征如下：

持续性

训练通常是小时/天级任务，价值来自连续推进的 step。任何中断都会引入无效成本（回滚、重建 cache、重新 warmup）。
同步通信与拓扑敏感

分布式训练（如 DDP、FSDP、ZeRO）依赖高频 collective（AllReduce/AllGather）。这类通信对节点内 NVLink、节点间 RDMA、网络拥塞极其敏感：
- 同样的 GPU 数量，跨机分散往往显著慢于同机集中。
- “坏邻居”带来的网络抖动会直接映射为 step time 抖动。
- 一张慢卡可能拖慢整个同步组（典型的“拖尾”）。
资源单位更刚性

推理可以在共享方案下“切小块”跑起来；训练往往需要固定数量的 GPU + 固定拓扑约束才有意义。可以理解为：要么成团满足，要么就不该启动。
显存与 IO 的相互制约

微调（尤其 LoRA/QLoRA）表面上更轻，但仍可能被显存碎片、数据加载瓶颈、checkpoint IO 限制。训练的“资源曲线”不是单维 GPU utilization，而是 GPU/CPU/内存/网络/存储的耦合曲线。

结论： 对训练而言，“让作业快点开始”不如“让作业开始后别掉速、别中断”。因此调度系统要支持：成组准入、拓扑约束、抢占策略、可恢复机制。

训练工作负载分层：你调度的是“语义”，不是 Pod

治理训练/微调时，建议按“调度语义”分层，而不是按框架或模型分层：

A 类：单机微调/小规模训练（1～N GPU，单节点）

目标：快速周转、低运维成本。
典型：LoRA、短跑实验、评估任务。
调度重点：排队公平、基本配额、低抢占损失。

B 类：分布式训练（多节点 DDP/FSDP，强同步）

目标：稳定 step time，避免跨域/跨机不确定性。
调度重点：最小可用（min-available）、成组调度（gang）、拓扑（机内优先、机架/域约束）、低抖动环境。

C 类：弹性训练（可伸缩 worker、容忍波动）

目标：在资源紧张时保持总体吞吐最大化。
调度重点：允许伸缩/重排、与自动扩缩容协同、抢占后快速恢复。

平台治理的关键是：不同层的作业要用不同的承诺模型。A 类可以“尽快跑”；B 类必须“整团满足”；C 类才适合机会式资源。

下图展示训练工作负载的分层分类。A 类（绿色）：单机微调/小规模训练（1～N GPU，单节点），目标快速周转、低运维成本，调度重点是排队公平、基本配额、低抢占损失。B 类（黄色）：分布式训练（多节点 DDP/FSDP，强同步），目标稳定 step time 避免跨域不确定性，调度重点是最小可用 min-available、成组调度 gang、拓扑约束、低抖动环境。C 类（蓝色）：弹性训练（可伸缩 worker，容忍波动），目标资源紧张时保持总体吞吐最大，调度重点是允许伸缩重排、与自动扩缩容协同、抢占后快速恢复、机会式资源利用。底部灰色区域展示训练的四个关键资源特征：持续性、同步通信与拓扑敏感、资源单位更刚性、显存与 IO 相互制约。结论：对训练而言让作业快点开始不如让作业开始后别掉速、别中断，调度系统必须支持成组准入、拓扑约束、抢占策略、可恢复机制。

图 1: 训练工作负载分层：你调度的是语义，不是 Pod

PyTorch 训练需要的调度语义清单

训练系统落到 Kubernetes 时，最容易踩的坑是：把“训练作业”降维成“Pod 集合”，于是丢掉了语义。要让训练可治理，需要至少具备以下语义（由控制面实现，而非靠用户自觉）：

最小可用（Min-Available）

分布式训练常见需求：没有足够 worker/PS/launcher 就不要启动。否则会出现：

只启动了一部分 worker，反复 crash / backoff；
训练框架一直等 rendezvous，造成 GPU 空转；
资源被占着不产出，形成隐性浪费。

成组调度（Gang Scheduling）

训练的基本单位是一个“组”（一个 job），不是单个 Pod。成组调度解决两件事：

同时分配：避免分配到一半卡住；
一致性：保证训练拓扑与通信预期一致。

拓扑与亲和（Topology Awareness）

对训练而言，拓扑优先级通常是：

同一节点（NVLink/共享内存）
同机架/同网络域（RDMA/更低抖动）
跨域（最不稳定）

如果控制面无法表达拓扑偏好，训练会被随机摊开，导致吞吐不可预测。

可抢占（Preemptible）与不可抢占（Guaranteed）

训练平台必须允许用户声明“可抢占”层（低优先级、容忍中断）与“保证层”（关键训练、不可随意打断）。否则多租户下要么大家都不敢跑大任务，要么谁都在抢占别人。

可挂起/恢复（Suspend/Resume）

比“杀掉重启”更温和的治理手段是“挂起”：

把训练从运行态转为等待态，释放 GPU；
资源回来后再恢复；
结合 checkpoint，降低抢占损失。

这会显著改善资源紧张时的整体效率与用户体验（尤其是大作业）。

下图展示 PyTorch 训练需要的 5 种核心调度语义。最小可用（Min-Available）：没有足够 worker/PS/launcher 就不要启动。成组调度（Gang Scheduling）：同时分配与一致性，保证训练拓扑与通信预期一致。拓扑与亲和（Topology Awareness）：优先级从高到低为同节点（NVLink）、同机架（RDMA）、跨域（最不稳定）。可抢占/保证（Preemptible/Guaranteed）：声明可抢占层（低优先级）与保证层（关键训练）。可挂起/恢复（Suspend/Resume）：比杀掉重启更温和，结合 checkpoint 降低抢占损失。右侧灰色区域强调这些语义由控制面实现而非靠用户自觉：Kueue 负责准入配额优先级与公平，Volcano 负责成组调度与策略落地，数据平面定义资源单位与隔离边界。底部展示拓扑优先级，核心理念：把训练作业降维成 Pod 集合会丢失语义，要让训练可治理需要完整的调度语义支撑。

图 2: PyTorch 训练需要的调度语义清单

抢占的真实代价：你抢走的是“已完成的有效工作”

抢占不仅仅是“把 GPU 让给更重要的人”，它伴随三类成本：

重启成本（Restart Overhead）

重新拉起容器、重新下载权重/数据、重新初始化通信组。
回滚成本（Rollback / Lost Progress）

checkpoint 周期越长，被抢占损失越大；周期越短，IO 压力越大。这是一个可度量的权衡。
震荡成本（Systemic Thrashing）

如果抢占策略不稳定，会出现“你抢我、我抢你”的系统性抖动：
- GPU 使用率看似很高，但有效训练吞吐下降；
- 队列里作业频繁切换，整体完成时间变长；
- 用户感知为“平台不靠谱”。

抢占策略的目标不应是“让某个高优先级作业立刻启动”，而是：

在满足关键作业 SLA 的前提下，让全局有效吞吐最大，并把无效成本控制在可接受范围内。

下图展示抢占的三种真实成本。重启成本（红色）：重新拉起容器、重新下载权重/数据、重新初始化通信组、重新 warmup。回滚成本（黄色）：checkpoint 周期越长被抢占损失越大，周期越短 IO 压力越大，这是一个可度量的权衡。震荡成本（蓝色）：GPU 使用率高但有效训练吞吐下降、作业频繁切换整体完成时间变长、你抢我我抢你的系统性抖动、用户感知为平台不靠谱。绿色区域说明抢占策略的正确目标：在满足关键作业 SLA 的前提下让全局有效吞吐最大并把无效成本控制在可接受范围内，而不是简单让某个高优先级作业立刻启动。灰色区域列出降低抢占损失的 5 种策略：区分可抢占层与保证层、制定 checkpoint 规范、引入挂起恢复机制、避免震荡、分离训练与推理资源池。底部核心洞察：抢占不是免费的，真正的代价是已完成的有效工作和系统稳定性。

图 3: 抢占的真实代价：你抢走的是已完成的有效工作

把训练纳入队列治理体系：以 Kueue 为准入核心

推荐的治理分工如下：

Kueue：负责准入、配额、优先级与公平（Admission / Quota / Fairness）
解决“谁能用、何时能用、能用多少”，并做全局资源承诺与统计。
调度器/批处理控制面（如 Volcano 或具备同等语义的组件）：负责成组调度与策略落地（Gang / Policy）
解决“怎么分配到具体节点、如何满足 min-available、如何处理拓扑与抢占”。
数据平面（MIG/共享方案）：定义资源单位与隔离边界
决定“一个训练作业申请的 GPU 单位到底是什么”。

这套组合能避免一个常见错误：用一个组件同时管准入、公平、拓扑与成组，最终谁都管不好。

验收指标：训练平台要验“有效产出”，不是只看 GPU 利用率

建议把验收指标分三层：

作业级（Job）

Time-to-Start：从提交到开始训练的时间（含队列等待）
有效吞吐：tokens/s 或 steps/s（建议对关键模型固定基准）
step time P50/P95：衡量抖动
重启次数与恢复时间：抢占/失败后的恢复能力
checkpoint 开销占比：IO 成本是否可控

队列级（Queue）

公平性：同优先级作业的等待时间分布
阻塞与头阻塞（HOL）：大作业是否长期卡住队列
抢占损失率：被抢占导致的无效 GPU 时间占比

集群级（Cluster）

有效训练吞吐总量（全局）
跨作业干扰事件（网络/存储拥塞导致的抖动）
碎片率：由于资源单位/拓扑导致的不可用碎片

关键风险点清单（评审时必须回答）

多节点训练是否强制 min-available + gang？否则大概率出现“占着资源不产出”。
拓扑不可控时，性能 SLO 如何保证？不能保证就要在产品层明确“best effort”。
抢占发生时，checkpoint 策略谁负责？频率如何约束？不回答就等于默认“抢占不可用”。
恢复时是否会造成队列震荡？需要明确：恢复优先级、冷却时间、最大并发恢复数。
训练与推理是否共享同一物理池？如果共享，必须有明确的隔离与优先级边界，否则推理尾延迟会被训练放大。

总结

PyTorch 训练/微调之所以难，不在于 GPU 数量，而在于它需要的平台语义更多：成组、最小可用、拓扑、可恢复、可抢占、可解释。当这些语义被治理体系（以 Kueue 为准入中心）承接后，训练就不再是“谁先抢到算谁的”，而是变成可评审、可实施、可验收的资源服务。

下一章将进入更具体的拓扑与分布式场景（Ray 与拓扑），把“语义”落实到可观测、可实验的结论链中。

Ray/KubeRay 与拓扑约束：从单卡到多节点

Jimmy Song — Tue, 30 Dec 2025 05:03:00 +0000

资源数量易得，资源位置难控。多节点 GPU 平台的核心挑战，是让“可调度”真正等于“可用”。

单卡阶段，讨论“共享/隔离”时，很多经验默认了一个前提：瓶颈主要在 GPU 本身与显存。一旦进入多卡、多节点，瓶颈会迅速外溢到 NUMA、PCIe/NVLink、NIC/交换网络与通信库。于是会出现一种最常见、也最隐蔽的失败：看起来可调度（scheduler 成功把 Pod 放上去了），但跑起来不可用（吞吐崩、尾延迟抖、NCCL 报错、训练步时不稳定）。

本章聚焦于以下三个核心问题：

控制面如何表达拓扑约束：让“该去哪儿跑”从拍脑袋变成可声明、可审查、可执行的约束。
数据平面如何暴露资源单元：让“我到底拿到了什么”可以被工作负载和平台共同验证。
如何避免“可调度但不可用”的伪成功：把拓扑从“最佳努力”升级为“可验收”。

单卡经验在多卡/多节点场景下的失效

在多卡/多节点环境下，性能瓶颈不再只由 GPU 算力决定，而是由一组链路共同决定。下文介绍这些关键链路及其影响。

性能主导因素的迁移

以下是多卡/多节点场景下影响性能的主要链路：

CPU ↔ GPU 的亲和性（NUMA, Non-Uniform Memory Access）：GPU 挂在哪个 CPU Socket，下游内存/PCIe Root Complex 是谁，决定了数据喂给 GPU 的效率与抖动上限。
GPU ↔ GPU 的互联（NVLink / PCIe）：同一节点内，GPU 间通信的拓扑决定了 NCCL ring/tree 的实际带宽与延迟。
节点 ↔ 节点的网络（以太网 / RoCE / IB / EFA）：跨节点 all-reduce、参数同步、KV cache 分片都依赖网络与 RDMA（Remote Direct Memory Access）栈质量。
系统软件栈的“隐形限制”：驱动版本、NCCL/UCX、容器权限、/dev/shm、IOMMU、cgroup/CPU pinning 等，都会把“可用性”变成概率事件。

典型“伪成功”症状

以下场景中常见“调度成功但不可用”的现象：

训练作业：NCCL 初始化慢/失败；步时波动大；跨节点带宽远低于预期；节点间拓扑不一致导致效率崩盘。
Ray 推理/Serving：同一模型副本放到了跨 NUMA 的 GPU 上，吞吐下降但 p99/p999 尾延迟暴涨；或者 worker 分散到网络质量差的节点，出现系统性抖动。
Ray 分布式任务：placement group 表面满足资源数，但实际落点跨机架/跨 AZ，导致“可跑但不值钱”。

结论：从单卡到多节点，本质是从“资源数量问题”升级为“资源位置问题”。

拓扑约束的三个层次

为了便于理解拓扑约束，通常将其分为三层，层级越低越贴近硬件：

集群拓扑（Cluster Topology）：Region / Zone / 机房 / 机架 / 交换域 / 网络平面（如是否同一 ToR、是否同一 RDMA fabric）。
节点拓扑（Node Topology）：NUMA 节点、CPU socket、PCIe 拓扑、GPU/NIC 挂载关系、NVLink island。
设备拓扑（Device Topology）：GPU 之间的 P2P 能力、NVLink 链路数量、GPU 与 NIC 的亲和（GPUDirect RDMA）、MIG（Multi-Instance GPU）实例归属等。

控制面负责将这些拓扑“表达出来并约束调度”，数据平面负责将这些拓扑“暴露出来并可被验证”。

下图展示拓扑约束的三个层次。集群拓扑（蓝色区域，最上层）：Region/Zone/机房/机架/交换域/网络平面，适用于跨机房部署、容灾、网络质量约束。节点拓扑（黄色区域，中间层）：NUMA 节点/CPU socket/PCIe 拓扑/GPU NIC 挂载关系/NVLink island，适用于单节点多卡训练、PCIe/NVLink 优化、NUMA 亲和。设备拓扑（绿色区域，最底层）：GPU 之间 P2P 能力/NVLink 链路数量/GPU 与 NIC 亲和/MIG 实例归属，适用于 MIG 虚拟化、GPU-GPU 通信优化、RDMA 亲和。底部灰色区域说明控制面与数据面的职责分工：控制面将拓扑表达并约束调度（Kubernetes 的 nodeSelector/affinity/spread/gang + Ray 的 Placement Group），数据平面将拓扑暴露并可验证（NFD、GPU/NIC 拓扑采集）。核心理念：从单卡到多节点，本质是从资源数量问题升级为资源位置与结构问题。

图 1: 拓扑约束的三个层次：从集群到设备

控制面：Kubernetes 如何表达拓扑约束

Kubernetes 默认调度以“资源计数 + 约束过滤”为主。要让其理解拓扑，需用到以下原语：

节点选择与亲和（NodeSelector / NodeAffinity）

通过标签将“节点能力/位置”编码成可声明条件：

topology.kubernetes.io/zone=...
kubernetes.io/hostname=...
自定义：gpu.nvidia.com/arch=hopper、rdma=true、nvlink.island=...、numa.policy=...

适用于粗粒度过滤（如同 AZ、同机房、必须 RDMA 等），但不适用于细粒度“同一节点内 GPU 亲和”或“跨节点成组”需求（此时需更强语义）。

反亲和与分布（PodAntiAffinity / TopologySpreadConstraints）

通过分散副本到不同故障域或网络域，避免“同机架/同节点热点”：

推理副本：跨节点/跨机架 spread，提高容灾与尾延迟稳定性。
训练 worker：通常更希望“靠近”而不是 spread（此时需用 gang + 机架亲和）。

组调度（Gang Scheduling）

多卡/多节点训练的核心不是“一个 Pod 能不能放”，而是“一组 Pod 能否一起放到满足拓扑的资源集合上”。

在原生 Kubernetes 中，组调度能力尚在完善。常见方案包括：

Volcano：PodGroup / queue / priority / preemption（偏批处理语义）。
Kueue：准入 + 配额 + 资源承诺/归还（偏治理语义）。

无论选用哪种方案，核心目标都是：

要么整组满足拓扑并一起启动，要么都不启动。

控制面：Ray/KubeRay 如何表达“资源位置”

Ray 的抽象是“资源与调度”，KubeRay 负责将这些抽象落到 Kubernetes 上。需理解两套语义如何叠加。

Ray 的资源表达：从“数量”到“形状”

Ray 常见的资源表达方式包括：

num_cpus / num_gpus：数量型资源（最基础）。
自定义资源：如 {"accelerator_type:A100": 1} 或 {"rdma": 1}（用于约束落点）。
Placement Group：将一组任务/actor 以“bundle”打包调度，并指定策略：
- STRICT_PACK：尽量同节点（适合单节点多卡，最强 locality）。
- STRICT_SPREAD：强制分散（适合高可用副本或跨节点并行但要求分散）。

实战建议：多节点训练/多 actor 并行时，优先用 placement group 明确“通信边界”，否则只能依赖调度器默认行为。

KubeRay 的落地：WorkerGroupSpec + K8s 约束

KubeRay 的 RayCluster / RayJob 通常按 head/worker 分组定义 PodTemplate。可将 Kubernetes 的拓扑约束写入每个 group：

训练 worker group：nodeAffinity 约束到同一网络域（如同机架/同 IB fabric），并配合 gang（Volcano/Kueue）。
推理副本 group：topology spread 到不同节点/不同故障域，降低尾延迟系统性风险。
需要 RDMA 的 group：强制 rdma=true，并加 admission 校验。

Ray 的 placement group 与 Kubernetes 的 affinity/spread 并不互斥：

Kubernetes 负责“候选节点集合”（能跑、在哪儿跑）
Ray 负责“组内结构”（谁跟谁在一起、谁必须分开）

数据平面：如何暴露“你拿到的资源单元”

控制面负责“表达约束”，数据平面则必须将资源单元暴露为可观测、可校验的事实。否则平台只能凭标签与静态配置猜测拓扑，伪成功难以避免。

节点侧：发现与标注（Discovery & Labeling）

需将“拓扑事实”转化为节点标签或可查询信息。常见方式包括：

Node Feature Discovery（NFD, Node Feature Discovery）：将硬件能力/特征打到 Node label。
GPU/NIC 拓扑采集：将 NVLink island、PCIe Root Complex、NIC 亲和等生成标签或 CRD（Custom Resource Definition，具体实现相关）。
网络域标签：机架、ToR、fabric id（来自机房资产系统或自动发现）。

目标是让调度约束不依赖人工维护，否则维护成本极高。

设备侧：GPU 资源暴露与隔离

根据所选数据平面（整卡、MIG、共享虚拟化），暴露的资源单元不同：

整卡：资源单元清晰，但仍需暴露拓扑（如 GPU0 和 NIC0 的亲和、GPU0/1 是否 NVLink）。
MIG（Multi-Instance GPU）：资源单元离散且带强隔离，需要额外暴露“实例属于哪张物理卡/哪组 NVLink”信息，避免“实例可分配但通信不可控”。
共享虚拟化（如 HAMi 类）：更需可观测性与干扰检测，否则无法证明共享后性能是否满足 SLA（Service Level Agreement，服务等级协议）。

避免“可调度但不可用”：将拓扑约束升级为可验收

伪成功往往源于缺少“端到端校验”。建议将校验分为三层：准入校验、启动校验、运行时验收。

准入校验（Admission）

在作业进入队列或被准入前，检查是否声明了必要的拓扑需求，且集群中存在满足条件的资源池：

需要 RDMA 的训练：必须声明 rdma=true，且配额池中有对应资源。
需要同节点多卡（NVLink）的推理：必须声明 nvlink=true 或“同 island”标签。
多节点训练：必须声明 minNodes、gpusPerNode、topologyScope（同机房/同机架/同 AZ）。

结果只有两种：可准入 / 不可准入。避免作业“先进队列再慢慢失败”。

启动校验（Startup Probing）

作业启动时，在 worker init 阶段做快速自检，尽早暴露“不可用”：

GPU ↔ GPU P2P/NVLink 可用性探测（同节点）
NCCL/UCX 初始化探测（跨节点）
NIC/IB 设备存在与权限（容器内可见、驱动匹配）
/dev/shm、hugepage、CPU pinning/NUMA policy 是否满足

启动校验失败应快速 fail-fast，并将失败原因写入事件与指标系统，避免“挂起与重试风暴”。

运行时验收（SLO/SLA）

将“拓扑是否正确”转化为可观测指标与验收门槛：

训练：
- NCCL all-reduce 带宽/延迟（可用基准测试或训练过程 proxy 指标）
- step time 的 p95/p99 抖动
- GPU util、PCIe/NVLink throughput、网络吞吐与重传
推理（Ray Serve / vLLM on Ray）：
- p99/p999 latency 与 tail amplification
- 每卡吞吐稳定性（标准差/变异系数）
- 关键路径的 CPU NUMA 远端访问比例（若可采集）

当验收不达标时，排查方向主要有两类：

约束未表达清楚（调度放错地方）
资源单元未暴露清楚（以为有 NVLink/有 RDMA，实际没有或不可用）

下图展示避免“可调度但不可用”的三层校验体系。准入校验（红色区域）：作业进入队列或被准入前，检查是否声明必要的拓扑需求、集群中是否存在满足条件的资源池，结果只有可准入或不可准入两种，避免先进队列再慢慢失败。启动校验（黄色区域）：作业启动时 worker init 阶段做快速自检，包括 GPU↔GPU P2P/NVLink 可用性、NCCL/UCX 初始化、NIC/IB 设备与权限、/dev/shm/hugepage/CPU pinning/NUMA policy，要求快速 fail-fast 并将失败原因写入事件与指标系统。运行时验收（蓝色区域）：将拓扑正确性转化为可观测指标，训练验收 NCCL all-reduce 带宽延迟、step time 的 p95/p99 抖动、GPU util 等，推理验收 p99/p999 latency、每卡吞吐稳定性、CPU NUMA 远端访问比例。底部说明验收不达标时的两个排查方向：约束未表达清楚（调度放错地方）、资源单元未暴露清楚（以为有 NVLink/RDMA 实际没有或不可用）。核心理念：伪成功源于缺少端到端校验，必须把拓扑从最佳努力升级为可验收。

图 2: 避免可调度但不可用：三层校验体系

参考组合：从“能跑”到“可交付”的三种模式

下表总结了三种常见的 GPU 平台成熟度路径，便于后续架构组合参考。

这是三种典型模式的对比：

模式	适用场景	关键点
单节点多卡优先（最强 locality）	单机多卡推理、单机训练、低运维复杂度团队	- K8s：强制同节点（nodeAffinity + 资源 bundle） - Ray：placement group `STRICT_PACK` - 数据平面：整卡或 MIG（强调实例与物理卡映射可见）
多节点训练（通信优先 + gang）	分布式训练/微调、Ray Train、多节点数据并行	- gang：Volcano 或 Kueue（保证整组准入/启动一致） - 网络域亲和：同机房/同 fabric - 启动校验：NCCL/UCX/RDMA 预检必做
推理多副本（稳定性优先 + spread）	在线推理、多租户、多副本 HA	- spread：跨节点/跨故障域分散，避免同域抖动 - 资源治理：配额/准入（Kueue）防止被训练挤爆 - 验收：以尾延迟为硬指标，优先“稳定”而非“峰值吞吐”

表 1: GPU 平台多节点能力落地模式对比

下图展示三种典型落地模式的演进路径。模式 1（绿色）：单节点多卡优先（最强 locality），适用场景是单机多卡推理、单机训练、低运维复杂度团队，关键技术点包括 K8s 强制同节点（nodeAffinity + 资源 bundle）、Ray placement group STRICT_PACK、数据平面整卡或 MIG（强调实例与物理卡映射可见）。模式 2（黄色）：多节点训练（通信优先 + gang），适用场景是分布式训练/微调、Ray Train、多节点数据并行，关键技术点包括 gang（Volcano 或 Kueue 保证整组准入启动一致）、网络域亲和（同机房同 fabric）、启动校验（NCCL/UCX/RDMA 预检必做）。模式 3（蓝色）：推理多副本（稳定性优先 + spread），适用场景是在线推理、多租户、多副本 HA，关键技术点包括 spread（跨节点跨故障域分散避免同域抖动）、资源治理配额准入（Kueue 防止被训练挤爆）、验收以尾延迟为硬指标（优先稳定而非峰值吞吐）。底部展示成熟度演进路径：从能跑（模式 1）→ 可交付（模式 2）→ 可运营（模式 3）。核心理念：多节点 GPU 平台的核心挑战是让可调度真正等于可用，避免伪成功。

图 3: 三种典型落地模式：从能跑到可交付

落地清单（Checklist）

上线 Ray/KubeRay 多节点能力前，建议至少明确以下问题：

拓扑事实从哪来？（NFD/资产系统/自动探测）
拓扑如何表达？（label/affinity/spread/gang + Ray placement group）
资源单元是什么？（整卡/MIG/共享；是否可观测可计量）
准入是否强制？（缺少拓扑声明能否进入队列/能否被准入）
启动是否 fail-fast？（NCCL/RDMA/NVLink/NUMA 校验）
验收指标是什么？（训练 step time 抖动、推理尾延迟、通信带宽）
失败如何归因？（事件 + 指标 + 日志链路，能快速区分“放错地方”还是“资源不真”）

总结

从单卡到多节点，GPU 平台的挑战已从资源数量升级为资源位置与结构。Kubernetes 侧通过 affinity/spread/gang 将“候选落点”转化为可执行约束；Ray 侧用 placement group 明确“组内结构”语义；数据平面则需将拓扑事实与资源单元暴露为可验证信号。唯有如此，才能避免“可调度但不可用”的伪成功，让分布式能力真正成为可交付的 GPU 平台能力。