Jimmy Song – 认识机器与问题

GPU 基础认知：从硬件到 Kubernetes 的完整视角

Jimmy Song — Sun, 25 Jan 2026 11:43:53 +0000

GPU 不是“更快的 CPU”，而是吞吐型计算的工程范式转变。理解它，才能用好它。

本文旨在为“第一次被 GPU 项目拖进深水区”的工程师建立一个稳定、可复用的 GPU 心智模型。你需要理解的不是某个 API，而是 GPU 作为一种硬件与运行时栈，在资源形态、约束、可治理边界上的本质差异。后续关于异构生态、共享隔离、控制面/数据面、平台能力模型与选型决策轴，都会回到这里的基本事实。

在下文中，将从硬件到 Kubernetes，梳理 GPU 的工程全景，帮助你建立系统性认知。

一页总图：从硬件到 Kubernetes

下方流程图将 GPU 的物理层级与 Kubernetes 使用路径整合在一张图中。阅读后续章节时，你可以随时定位问题发生的层级：是硬件约束、驱动/运行时、容器栈，还是 Kubernetes 的资源模型边界。

图 1: GPU 从硬件到 Kubernetes 的全景流程

GPU 是什么：工程视角的一句话定义

GPU 是为大规模数据并行计算设计的专用计算设备，通过牺牲控制流灵活性换取极高的吞吐密度。与 CPU 相比，GPU 更像“吞吐型计算平台”，而不是“通用计算资源”。

为了让后续讨论更直接，下表用最小必要对照建立直觉。

这是 CPU 与 GPU 的工程特性对比表：

维度	CPU	GPU
设计目标	低延迟、强控制流	高吞吐、弱控制流
并行模型	少量复杂核心（十级）	大量简单核心（千级）
主要瓶颈	指令路径 / Cache	显存容量与带宽
调度主体	OS（CFS 等）	驱动 + Runtime（CUDA）
虚拟化成熟度	极高	天然较弱，需要专门方案补齐

表 1: CPU 与 GPU 的工程特性对比

这组差异决定了一个后续反复出现的事实：Kubernetes 天生擅长管理 CPU，却难以直接表达 GPU 的内部资源。

GPU 这块硬件里面有什么

理解 GPU 调度与治理，最重要的不是“有哪些指令”，而是“哪些部件会成为资源约束、隔离边界或干扰来源”。从基础设施治理角度，一个 GPU 可以拆成五类核心部件：

计算单元（SM / Tensor Cores）
显存（HBM / GDDR）
片上缓存（L2 / Shared Memory）
互联（PCIe / NVLink / NVSwitch）
驱动与固件（Driver / Firmware）

后续所有关于共享、隔离、干扰、尾延迟的问题，几乎都能在这五类部件里找到物理根因。

显存是什么，算力是什么

许多没有 GPU 使用经验的人容易将“显存”和“算力”混为一谈。但在实际调度与治理中，两者扮演完全不同的角色。

显存（Memory）

显存是 GPU 的本地内存空间（数据中心卡多为 HBM）。模型参数、KV Cache、激活值、临时张量等都会占用显存。显存的工程特征决定了它是 GPU 资源治理的第一约束：

显存通常需要连续可用空间，容易出现碎片问题
显存不像 CPU 内存那样可以被操作系统透明分页
显存占用常常与进程生命周期强绑定（模型加载即占用）

一个非常典型且关键的现象是：节点上显示还有剩余显存，但新任务仍然无法启动。这通常与显存碎片、连续分配失败、或者框架的显存预留策略有关。

算力（Compute）

算力对应 SM/Tensor Core 的计算能力，通常用 TFLOPS 表示。算力的工程特征更像“可时间片共享的吞吐资源”：

算力决定跑得快不快，但不直接决定能不能跑
多进程/多任务通常可以共享算力（但会相互干扰）
算力的治理重点在干扰控制与 QoS，而不是“能否分配”

在实际系统里，你可以记住一个非常有用的结论：

工程经验

算力是软约束，显存是硬约束。

这句话直接关联到后面“为什么 GPU 资源治理难”，以及“为什么很多共享方案最终卡在显存上”。

以 NVIDIA 为主线理解 GPU 生态与演进脉络

GPU 生态当然不止 NVIDIA，但在工程现实里，NVIDIA 长期承担了数据中心 AI 计算的事实标准角色：软件栈、框架适配、云厂商形态、Kubernetes 生态默认假设都深度围绕 CUDA 体系。

NVIDIA GPU 三条产品线（理解生态的最小划分）

在阅读后续“异构生态导引”前，建议先区分 NVIDIA 内部三种主要产品线：

数据中心/计算型：A/H/L 系列（训练/推理/HPC 主战场）
消费级/游戏：GeForce RTX（不适合作为基础设施治理样本）
专业图形：RTX A / 旧 Quadro（图形工作站场景为主）

本手册讨论的核心对象是第一类：数据中心计算型 GPU。后续关于拓扑、共享隔离、计量观测、MIG/MPS 等，也主要发生在这一类卡上。

代际演进看什么：不是发布时间，而是工作负载假设

从基础设施视角，GPU 架构的演进更像“对 AI 工作负载假设的变化史”。一个简化但足够工程化的理解方式是：

Volta（V100）之后，Tensor Core 让 AI 负载成为核心假设
Ampere（A100）推动训练规模化
Hopper（H100）更强调大模型训练与推理并发形态
Blackwell（B200/B300）把尺度推到机柜级（NVL72），并让 FP4 低精度成为推理主流假设

你不需要记住每一代的细节，但要记住一条方法论：代际差异会直接影响资源形态（显存大小、互联拓扑、分区能力、观测接口），而资源形态会反过来决定治理与调度策略。

GPU 资源如何被使用、分配与释放

本节从“单机最小闭环”开始，逐步扩展到多 GPU、多节点、再到 Kubernetes。建议先理解单机路径，再关注编排与调度。

单节点：一个进程如何使用 GPU

一个典型 GPU 进程在单节点上的资源路径通常如下：

进程加载 CUDA Runtime
通过驱动建立上下文（context）
分配显存（模型加载、缓存分配）
提交 kernel 执行（计算占用算力）
进程退出或释放资源（显存回收）

这里有两个重要事实：

资源生命周期往往与进程生命周期强绑定
多进程共享一张卡天然缺乏强隔离，需要额外机制补齐

单机多卡：互联与通信决定上限

单机多卡常见形态包括数据并行与模型并行。此时“算力”不再是唯一瓶颈，互联成为关键变量：

PCIe：通用但带宽相对有限
NVLink / NVSwitch：为多卡高带宽互联设计

在基础设施层面，拓扑不是细枝末节，它会直接决定调度策略（例如是否需要拓扑感知的放置）。

多节点：调度与通信是两件事

多节点训练/推理需要跨节点通信（如 NCCL）。调度系统负责把作业放到哪些节点，通信系统负责把这些节点连接成高效的训练拓扑。两者属于不同层级：

调度：选择节点、分配资源、满足约束
通信：实际的数据交换效率与稳定性

因此在多节点场景里，“把 Pod 放对地方”只是第一步，拓扑与网络质量会决定最终的训练效率与尾延迟。

GPU 在 Kubernetes 中如何被使用

许多人以为“在 Kubernetes 上用 GPU”是 Kubernetes 原生就很擅长的事。实际上，Kubernetes 的设备资源模型对 GPU 这类设备的表达能力有限，许多关键治理能力需要插件、运行时或数据平面补齐。

Kubernetes 的最小 GPU 使用链路

Kubernetes 使用 GPU 的标准路径通常由三块组成：

Device Plugin：把 GPU 暴露为可调度资源（默认粒度多为整卡）
容器工具链：把驱动与用户态库正确注入容器（如 NVIDIA Container Toolkit）
kube-scheduler：只负责把 Pod 放到“有该资源的节点上”

这里需要明确一个关键边界：

能力边界

Kubernetes 负责节点级别的放置，但不负责 GPU 内部的显存、算力、公平性与干扰控制。

这正是后续章节（尤其是“为什么 GPU 资源治理难”“控制面地图”“能力模型”“设备资源模型边界”）要深入展开的原因。

单节点 Kubernetes 与多节点 Kubernetes 的差异

为避免将“单机使用 GPU”和“Kubernetes 使用 GPU”混为一谈，下表给出最小对比：

场景	主要调度变量	复杂性来源
单节点 Kubernetes	这张卡在不在这台节点上	资源分配、容器注入
多节点 Kubernetes	节点间拓扑与网络条件，作业形态更复杂	分布式训练、推理集群、拓扑

表 2: 单节点与多节点 Kubernetes 使用 GPU 的差异

因此，多节点场景下更容易出现“资源看似满足但性能不稳定”的现象，根因往往不是调度本身，而是拓扑与干扰问题在系统层被放大。

加速的经济学：为什么“再加点算力”不一定更快

一个服务可能受限于 CPU、内存带宽、I/O、同步，或在等待另一个服务。GPU 只能改善其中既可卸载、又大到足以摊平数据搬运和启动开销的那一部分。设想一个请求：CPU 上准备输入花 2 ms，拷贝花 1 ms，GPU kernel 执行花 3 ms，等待网络或数据库花 4 ms。把 kernel 加速十倍，只从 10 ms 的请求里省出 2.7 ms。加速器有用，但这个系统并不是“一个 GPU 问题”。

瓶颈	典型表现	第一个该问的问题
计算	指令活动高；算力越多扩展越好	该运算能否用 GPU 支持的 kernel？
内存带宽	数据搬运时计算单元闲置	数据能否更好地复用或布局？
主机/设备传输	GPU 突发执行后是漫长空隙	拷贝能否与计算重叠或避免？
通信	各 rank 在集合通信处等待或链路饱和	拓扑与 rank 映射是否正确？
调度	硬件不错但排队时间很长	限制来自容量还是放置策略？

表 3: 瓶颈分诊表：先问第一个问题

在选型硬件之前，先按批大小、算术强度、内存占用、同步频率、精度容忍度和通信模式对工作负载做一次分类，这个小练习能避免最常见的失败模式：为错误的工作负载买对了加速器。工作负载的形状还决定了它适合的共享与调度方式，这条线索贯穿硬切分与软切分与调度问题域。

总结

本文以工程师视角梳理了 GPU 从硬件到 Kubernetes 的全链路知识脉络，强调了显存与算力的本质差异、NVIDIA 生态的工程现实、以及资源治理的关键边界。理解这些基础事实，是后续深入异构调度、共享隔离、平台能力模型等议题的前提。下一章GPU 微架构与 Roofline 模型将钻进卡内部：SM、显存层级的真实数字，以及“算力”与“带宽”两条屋顶线如何决定一切后续讨论。

GPU 微架构与 Roofline 模型：算力、带宽与干扰的物理根因

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

GPU 的“快”受两道互不相关的上限约束——算力上限与带宽上限，正是 Roofline 模型（屋顶线模型）刻画的两条屋顶线。不知道负载撞上的是哪一条，所有利用率数字、选型决策与共享策略都是在猜。

GPU 基础认知一章建立了“GPU 是吞吐设备”的心智模型。本章把模型落到数字上：芯片里有什么、每层有多快、以及如何用 Roofline 模型判断一个负载的瓶颈。这些数字是后续硬切分与软切分中“为什么 core 份额对某些负载无效”、可观测与计量中“为什么利用率会骗人”的物理根因。

SM、warp 与张量核：算力的三个层级

一块 H100 SXM 有 132 个 SM（Streaming Multiprocessor）。SM 是 GPU 的基本“工作间”，每个 SM 内部：

4 个 warp 调度器：每周期各发射一条指令。调度的最小单位是 warp，即 32 个线程绑在一起执行同一条指令。GPU 不会调度“单个线程”，正如 Kubernetes 不会调度“半个容器”。
普通算术单元（FP32）：合计约 67 TFLOPS。
张量核（Tensor Core）：专用矩阵乘加单元，稠密 BF16 约 989 TFLOPS，是普通算术单元的 15 倍。

工程含义

训练与推理的算力几乎全部来自张量核。一个没有走张量核路径的 GEMM，等效于只用了一块 1/15 算力的卡。看到训练“莫名其妙地慢”，先查精度路径（TF32/FP16/FP8）再怀疑硬件。

GPU 隐藏内存延迟的方式不是 CPU 式的乱序执行与预测，而是用海量并行 warp 互相填补空转：一个 warp 等显存，调度器立刻切换到另一个就绪的 warp。这解释了为什么 GPU 程序“并发度不足”时性能塌方：不是慢，是没有足够的 warp 可切。

内存层级：一张必须记住的数字表

层级	容量	延迟	带宽	与 Kubernetes 世界类比
寄存器	256 KB/SM	~0	极高	CPU 寄存器
共享内存/L1	228 KB/SM	~30 周期	~33 TB/s（聚合）	本地 L1/L2
L2 缓存	50 MB（全卡）	~200 周期	~5 TB/s	节点缓存层
HBM 显存	80 GB	~500 ns	3.35 TB/s	节点内存
NVLink（卡间）	无	~1–2 μs	900 GB/s（双向）	机柜内专线
PCIe Gen5 x16	无	~1–2 μs	64 GB/s	节点内普通总线
InfiniBand 400G	无	~1–2 μs	~50 GB/s	跨节点网络

表 1: H100 SXM 的内存与互连层级（数量级）

两个推论：

数据搬运常常比计算贵。主机到显存走 PCIe，比显存带宽慢 50 倍；跨节点再慢且再窄。这是 GPUDirect RDMA、NVLink 存在的原因，详见互连与集合通信。
要把 3.35 TB/s 吃满，同时在飞行中的数据必须约 1.7 MB（带宽 × 延迟）。没有足够的并发读请求，带宽就是纸面数字，这是 GPU 程序深流水线化的根本原因。

Roofline 模型：判断瓶颈的一行公式

一个负载每从显存读取 1 字节能做多少次浮点运算，称为算术强度（AI）。可达性能为：

可达性能 = min(峰值算力, 算术强度 × 显存带宽)

这就是 Roofline 模型（屋顶线模型）：峰值算力与“算术强度 × 显存带宽”各自画出一道上限，取较低者即负载的性能天花板。H100 的屋脊点（ridge point）约为 295 FLOP/字节：AI 高于此撞算力屋顶线，低于此受带宽屋顶线约束。三个典型负载的位置：

负载	算术强度	可达性能	受哪条屋顶线约束
大矩阵乘法（4096³）	~1000+	~989 TFLOPS（100%）	算力
中小矩阵（128³，分块后）	~40	~140 TFLOPS（14%）	带宽
LLM 解码（逐 token 生成）	~1	~3.4 TFLOPS（0.3%）	带宽（灾难性）

表 2: 典型负载在 Roofline 上的位置（H100, BF16）

解码行是理解推理平台一切现象的钥匙：生成每个 token 都要把全部模型权重从显存读一遍，每读 2 字节只做 1 次乘加。单路解码的速度上限 ≈ 显存带宽 ÷ 权重量（H100 跑 70B BF16 ≈ 24 token/s），与买了多少 FLOPS 无关。批量推理之所以能把吞吐拉高几十倍，本质是把“读一遍权重”摊到多个请求上，把算术强度从 1 提到 B。展开见LLM 推理的物理层。

由此还能读出选型与优化语言：

换 H200（算力不变、带宽 1.43 倍）能让解码提速 43%：推理选型买的是带宽和容量，不是 FLOPS。
权重量化（FP8/INT4）直接成倍提升解码速度，因为它减少的是要读的字节数。
“GPU 利用率只有 5% 算力”的推理集群可能是健康的，判定标准见GPU 指标语义。

功耗墙：共享场景的隐形干扰源

H100 满载 700W。多个租户共用一块卡时，总功耗可能触发功率墙，驱动随即降频，所有租户一起变慢 10–20%，而任何“利用率”指标都看不出原因。这是数据平面各共享机制共同的盲区：时间片、MPS、软切分都不管理功耗。

nvidia-smi --query-gpu=clocks.sm,clocks_throttle_reasons.active,power.draw --format=csv -l 1
# 看到 "SW Power Cap" 活跃且 SM 时钟下降，即触发功率墙

工程经验

“加了一个租户，大家慢了 15%”而所有利用率指标正常：先查降频原因，再查缓存争用，最后才怀疑应用。

常见误区

误区	真相
利用率 100% = 干满活了	利用率只表示“有 kernel 在跑”，与算力、带宽占用无关
算力高就是好卡（对推理）	解码受带宽屋顶线约束；H200 只加带宽就能快 43%
张量核是可选加速	不走张量核等效 1/15 算力的卡
显存 80GB 就能塞 75GB 负载	还有每进程 0.3–0.8GB 上下文、碎片与框架开销，见显存管理
共享卡上变慢一定是邻居抢算力	功耗墙降频与 L2 缓存冲刷同样常见且更隐蔽

表 3: 微架构层的常见误区

总结

微架构层的三个事实贯穿全书：张量核贡献了几乎全部算力；显存带宽是与算力并列的第二条屋顶线，且是推理负载的真正瓶颈；功耗与缓存是共享场景的隐形干扰源。带着 Roofline 模型看后续章节：软切分的 core 份额只管时间、管不了带宽（硬切分与软切分），MIG 之所以隔离强是因为它连显存带宽都切了（MIG），而监控必须同时看算力与带宽两条管道（GPU 指标语义）。

参考资料

CUDA 执行模型：内核、流与图，以及故障签名

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

你不需要写 CUDA 程序，但你需要知道一次“GPU 计算”由哪些动作组成、每一层故障长什么样，否则排障时你只能重启。

本章补齐从微架构到Kubernetes 管理模型之间缺失的一层：CUDA 运行时如何把计算落到 GPU 上。理解这一层，可观测里的指标、故障模式里的报错、vLLM 的参数才都有出处。

一次计算的完整旅程：host 与 device

GPU 是 CPU 的协处理器，不能独立工作。以向量加法 C = A + B 为例，完整路径是：

cudaMalloc 在显存里分配 A、B、C；
cudaMemcpy 把数据从主机内存拷入显存（走 PCIe，约 64 GB/s）；
CPU 发射 kernel（内核）：一段在 GPU 上执行的函数，每个线程算一个元素；
cudaMemcpy 把结果拷回主机；
cudaFree 释放。

要点：搬运与计算的代价同量级，且搬运路径比计算路径慢一个数量级以上。数据靠近 GPU（权重视驻显存、网络直达显存）是所有高性能栈的第一设计原则。

Kernel、grid、block：并行结构的声明

启动 kernel 时声明并行层级：grid（总并行度）→ block（放进 SM 的单位）→ thread（最小执行单元，32 个一组成为 warp）。可以用 Kubernetes 语言类比：kernel ≈ Job，block ≈ Pod（调度到某个 SM 的单位），thread ≈ 容器内进程。

平台工程师只需带走一句翻译：

一个 Python 训练/推理步骤 = 几十到上千个小 kernel 依次执行。 PyTorch 的每个算子（矩阵乘、LayerNorm、激活）就是一或多个 kernel。

Stream：GPU 内部的队列

stream（流）是 kernel 的执行队列：同流严格 FIFO，异流可并行（若 SM 有空闲）。陷阱在默认流：它会隐式同步其他所有流，框架以为在并行，实际被串行化。NCCL、数据加载、vLLM 内部都在精细管理多流；在火焰图里看到的每一行泳道就是一个 stream。

启动开销与 CUDA Graph：为什么推理引擎都在“录图”

每发射一个 kernel，CPU 要花 3–10 微秒准备。推理解码一步发射几百上千个小 kernel，启动开销可能超过计算本身：

每步 500 kernels × 5μs = 2.5ms 纯开销（常与计算同量级）

CUDA Graphs 把一整步的 kernel 依赖“录制”成图，之后每步一次调用重放整图，启动开销从 N×5μs 降为一次几 μs。vLLM 默认对解码步做图捕获，--enforce-eager（关掉录图）会让小批量解码吞吐下降 10–40%。

对平台有两个连带影响：一张重放的图接近一个超长 kernel，会改变多租户时间片交错的粒度（见数据平面谱系）；图捕获要求显存地址稳定，这影响引擎的显存布局策略（见显存管理）。

显存与上下文底噪

每个 CUDA 进程建立上下文（context）需常驻 0.3–0.8GB 显存（驱动、kernel 镜像、库工作区），未算任何张量。这解释了两个平台现象：一块卡上塞 20 个小进程会白白烧掉 6–16GB；以及“用 1 个推理引擎进程做多租户，优于 20 个小进程挤一块卡”。显存分配、缓存与碎片的完整机制见下一章GPU 显存管理。

故障签名：这一层的报错怎么读

报错/现象	含义	第一反应
`CUDA out of memory`	显存不足（不是主机内存）	走显存排查树
`CUDA error: device-side assert`	kernel 内断言（多为索引越界）	应用 bug，非平台问题
`CUDA driver version is insufficient`	驱动与 CUDA 运行时不匹配	版本治理，见管理模型
`illegal memory access`	显存越界	应用 bug；偶发则查 XID/ECC
程序 hang 在 NCCL init	通信初始化等不到对端	调度问题（部分启动），见调度问题域
XID 错误码（dmesg/nvidia-smi -q）	驱动级事件：13 显存错、43 降频、79 掉卡	纳入节点告警；79 级需隔离换卡

表 1: CUDA 层故障速查

两个 OOM 是两棵树

Pod 被 OOMKilled（exit 137）是主机内存问题（cgroup）；进程内 CUDA out of memory 是显存问题（绕过 cgroup）。两个 OOM、两套排查树，混在一起是 GPU 平台最高频的误诊。

总结

CUDA 执行模型给平台工程师的三件事：一次步骤 = 一串 kernel（所以有启动开销与 CUDA Graph）；stream 是 GPU 内部队列（所以并行可能被默认流悄悄串行化）；这一层的故障有稳定签名（XID、两类 OOM、NCCL hang），可以直接做成 runbook。它们分别通向显存管理、推理工作负载与故障模式手册。

参考资料

GPU 显存管理：分配器、碎片与 OOM 排查树

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

Kubernetes 能限制 Pod 用多少内存，却管不住它用多少显存。这不是配置遗漏，是显存根本不经过内核的内存管理。

阅读位置：上一章《CUDA 执行模型》 · 下一章《互连与集合通信》。

GPU 基础认知给出了“算力是软约束，显存是硬约束”的一阶结论；本章把显存这条硬约束拆到底：分配路径、框架行为、碎片机制、OOM 排查。它是HAMi显存配额（nvidia.com/gpumem）的计量口径、vLLM显存水位线策略与MIG硬边界的共同地基。

铁律：显存绕过 cgroup

K8s 的 memory.limit 经 cgroup 管主机内存。显存则通过 NVIDIA 驱动的设备节点（/dev/nvidia0、/dev/nvidia-uvm 等）分配，内核对此没有记账：

容器视角
├── 主机内存 7.9Gi / limit 8Gi ← cgroup 可见，超限则 OOMKilled
└── 显存 79Gi / 80Gi ← cgroup 不可见，再涨即 CUDA OOM

于是：给了 Pod 一块 GPU，它就能吃光整卡显存，原生 K8s 无任何手段限制。这正是共享方案（HAMi 的 gpumem 配额、vGPU 的显存分区、MIG 的物理切分）存在的根本原因：三种机制分别在API 层、驱动层、硬件层补这个洞。

分配为什么慢，以及人人都有“缓存分配器”

驱动级分配（cudaMalloc/cudaFree）是微秒到毫秒级操作，且释放还可能同步整个设备。训练循环每步分配/释放张量的话，时间全耗在驱动上。因此所有 DL 框架内建了缓存分配器（PyTorch 的 CUDACachingAllocator），思路与 jemalloc/tcmalloc 一致：

按大小分池：小块（<1MB 请求，2MB 段）、大块（≥1MB，20MB 段）；
释放的张量不还给驱动，留在池内等待复用；
torch.cuda.empty_cache() 才把空闲段还给驱动，它是诊断工具，生产循环里调用通常是 bug。

由此得到平台必背的一对指标：

reserved（nvidia-smi 看到的） = allocated（真实张量） + 缓存 + 碎片

nvidia-smi 的进程显存“只涨不跌”不是泄漏，是分配器的设计。把它当成泄漏去杀 Pod，是运维最常见的误操作之一。

碎片：还有内存却 OOM

外部碎片：池里有 10GB 空闲，但都是 1GB 的洞，来一个 5GB 请求 → 放置失败 → OOM。识别特征是报错信息里“reserved but unallocated”数值很大。对症配置：

PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True # 虚拟地址连续映射，基本消灭外部碎片
PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512 # 保守方案：禁止大切小

内部碎片：大小取整（2MB/20MB 段、推理引擎的 KV 块取整）造成的零头，单看小、量大时可观。分页 KV 的块大小选择就是这个问题在推理层的重现（见LLM 推理的物理层）。

与软切分配额的口径联动

HAMi 一类软切分方案在分配调用上拦截并记账（见数据平面谱系）。这意味着两件事：

计的是 reserved 口径（分配量），不是活跃张量，框架缓存会被当成“已用”；
跑在配额 Pod 里的 PyTorch 若不调 PYTORCH_CUDA_ALLOC_CONF，可能在“真实张量没用满”时就撞注入的 OOM。

软切分 Pod 模板应默认带分配器配置，这是显存配额从“能声明”到“能用”的临门一脚。

两棵 OOM 排查树

	Pod OOMKilled（exit 137）	进程内 CUDA out of memory
资源	主机内存（cgroup）	显存（绕过 cgroup）
常见元凶	pinned host buffer、NCCL 共享内存、数据加载	权重+KV+ 激活超预算、碎片、配额口径
排查入口	`kubectl describe pod`、容器内存曲线	`nvidia-smi` 总量 → 进程 reserved−allocated → 内存快照
修复方向	调 memory limit / 减少主机侧缓存	容量公式 / `expandable_segments` / 配额口径

表 1: OOMKilled 与 CUDA OOM 的分流

CUDA OOM 一侧的树状顺序：先看卡上是否真有空（共享卡则查邻居与配额）；再看 reserved−allocated（大 → 碎片，走分配器配置）；再看 allocated 本身（用 torch.cuda.memory._record_memory_history() + memory_viz 定位张量来源）；最后核对容量公式（权重 + KV 池 + 每进程上下文底噪 0.3–0.8GB + 框架开销）。

工程经验

“显存还有剩余但新任务起不来”与“报 OOM 但 nvidia-smi 显示远没满”是同一枚硬币的两面：前者多半是碎片或连续分配失败，后者多半是进程内池子或配额口径。两者都指向本章，而不是“加卡”。

精度是一份工程契约

内存预算的另一根调节旋钮是精度。FP32 提供数值范围和熟悉的参照；FP16 与 BF16 减少内存、可提升 Tensor Core 吞吐，但二者在指数范围和稳定性行为上不同；FP8 及更低比特格式能在受支持的架构上解锁更高吞吐和容量，但需要缩放、校准、kernel 与质量验证。

格式	适用角色	需要的验证
FP32	参考运算与敏感操作	数值基线与性能对比
TF32	加速的兼容 FP32 风格训练路径	框架默认值与架构支持
FP16 / BF16	训练与推理	损失缩放、范围、累加、质量
FP8	现代训练/推理	缩放策略、算子覆盖、回归测试
INT8	量化推理	校准与任务精度
FP4 / 微缩放	新兴低比特 AI 路径	精确的 Blackwell 时代软件与模型支持

表 2: 数值格式的角色与验证要求

正确的问题不是“可用的最低精度是什么”，而是“在这套架构和软件栈上，满足应用质量与稳定性目标的最低精度是什么”。对显存预算而言，精度直接改写占用表里的权重、激活与 KV 缓存三项，这也是LLM 推理的物理层中量化提速的内存侧解释。

常见误区

误区	真相
调大 Pod memory limit 能解决 CUDA OOM	无关，显存不经 cgroup
`empty_cache()` 能防 OOM	只释放空闲缓存；循环里调用反而拖慢
nvidia-smi 显示 79GB 就是模型有 79GB	含缓存与碎片，真实张量看 allocated
OOM 一定是模型太大	多数是碎片、水位线或配额口径问题
多个小进程共用 GPU 更灵活	每进程 0.3–0.8GB 上下文底噪，且无隔离

表 3: 显存层的常见误区

总结

显存是 GPU 治理的第一硬约束，四个事实各有推论：

绕过 cgroup：所以需要配额层
框架持有缓存：所以 reserved ≠ allocated
会碎片化：所以有“还有内存却 OOM”
有每进程底噪：所以进程数本身是成本

这四个事实分别决定了软切分的计量口径、vLLM的水位线设计、MIG 硬边界的价值，以及 OOM 排障的第一步永远是“分清哪棵树”。

参考资料

GPU 世代、模块与产品语言：把规格书读对

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

“H100 服务器”不是一份合格的物料清单：在读懂架构、产品、模块、平台、机架这五个词之前，规格书读得越细，坑埋得越深。

五个层级的词

这些词常被压成一句营销话术，但它们回答的是不同的问题：

架构（architecture）描述一个设计家族，如 Ampere、Hopper、Blackwell；
产品（product）是某款具体 GPU SKU，如 H100、H200、B200；
模块或外形规格（form factor）描述它如何接入系统，如 PCIe 卡、SXM 模块；
平台（platform）描述经过验证的 GPU、CPU、链路、网络、散热与固件组合，如 HGX、DGX；
机架级系统（rack-scale system）描述一个更大的通信与服务域，如 NVL72。

这套词汇一旦清晰，规格书就好读了：“H100”不会告诉你它是 PCIe 还是 SXM；“Blackwell”不会告诉你系统配的是哪种显存、互连网络或功耗包络；“NVL72”不是一块 GPU，而是一个机架级域。

带正确告诫的世代地图

名称	层级	解读
A100	Ampere 世代产品	广泛使用的数据中心加速器；确切显存、外形与 MIG 配置因 SKU 而异
H100	Hopper 世代产品	Tensor Core 与 Transformer Engine 世代；SXM 与 PCIe/NVL 配置不同
H200	Hopper 家族产品	面向内存容量的选择；需核实确切板卡与平台
B100 / B200	Blackwell 世代产品	Blackwell 家族名；不要从家族名推断相同的功耗、显存或拓扑
GB200	Grace Blackwell 超级芯片	CPU–GPU 设计点，有自己的片间互连与平台假设
HGX / DGX / MGX	平台标签	集成度与生态责任的不同程度

表 1: GPU 世代与产品速查

如何不靠猜来对比 A100、H100 与 Blackwell

NVIDIA 的 H100 页面列出 H100 SXM 配置为 80 GB、3.35 TB/s 显存带宽、最高 700 W 可配置 TDP、最多七个 10 GB MIG 实例；同一页面列出 H100 NVL 条目为 94 GB、3.9 TB/s、350–400 W 可配置 TDP、最多七个 12 GB MIG 实例，其互连数值随外形不同而不同。这些数值绑定于具名的产品条目，不应外推到每一块 H100 板卡。

Blackwell 架构页描述了两颗受掩模版限制的裸片通过 10 TB/s 片间互连相连、第二代 Transformer Engine，以及包括 FP4 在内的微缩放格式。正确的解读是架构能力，而不是每个应用都自动获得标题里的吞吐，能否兑现取决于负载的算术强度（见微架构与 Roofline 模型）。

PCIe 与 SXM：选择改变系统

PCIe 卡适配广泛的服务器生态，通常更易采购、更换与混插。SXM 模块为紧耦合系统设计，配合更高的供电、专用基板和纵向扩展互连网络。这个决定影响机箱、散热、固件、可维护性、互连，以及未来升级的形态；SXM 平台的 NVLink 带宽优势（见互连与集合通信）正是由此而来。

采购纪律

索取确切的 GPU SKU、内存技术与容量、TDP 范围、外形规格、点对点拓扑、网卡挂载方式、支持的驱动范围和服务流程。把这五层词汇写进采购清单，逐项确认。

总结

产品语言是选型防坑的第一道防线：分清架构、产品、模块、平台、机架，才能把“我要 H100”细化成一份可验收的物料清单。结合微架构与 Roofline 模型的负载分析和决策轴的评估框架，选型就从“听厂商讲”变成“按清单核”。

参考资料

NVIDIA H100 与 Blackwell 架构官方页面。

互连与集合通信：拓扑如何决定调度上限

Jimmy Song — Mon, 31 Aug 2026 02:39:18 +0000

多 GPU 系统的性能上限往往不在 GPU 里，而在 GPU 之间：同一组 8 张卡，放对地方和放错地方，通信能力差一个数量级。

微架构讲的是卡内；本章讲卡间与机器间。它是Ray/KubeRay 拓扑约束与调度问题域的物理前提，也解释了MIG与共享方案的一个关键限制：实例间 P2P 关闭。

带宽金字塔

路径	带宽（数量级）	相对显存带宽	类比
HBM 显存	3.35 TB/s	1×	本地内存
NVLink（卡间，双向合计）	900 GB/s	~0.27×	机柜内专线
PCIe Gen5 x16	64 GB/s	~0.02×	节点内普通总线
InfiniBand 400G	~50 GB/s	~0.015×	跨节点网络

表 1: H100 时代的通信层级（与显存带宽对照）

要点：NVLink 只存在于同一台服务器内部（经 NVSwitch 芯片把 8 卡全互联）；跨机器只能走网卡。同样的 8 卡张量并行，放一台 HGX 里和拆到两台机器，通信能力差近 10 倍。

读拓扑表：nvidia-smi topo -m

 GPU0 GPU1 ... NIC0 NIC1
GPU0 X NV18 PIX PIX
GPU1 NV18 X PIX PIX
Legend: NV18 = 18 条 NVLink 直连 | PIX = 同一 PCIe 交换机
 PXB = 同主机跨 PCIe 交换机 | PHB/SYS = 经过 CPU / 跨 NUMA

三类读法：

GPU↔GPU 全是 NV18：NVSwitch 全互联，任意 8 卡组合都好；
GPU↔NIC 的 PIX/PXB：哪块网卡离哪块 GPU 近，而 GPUDirect RDMA（网卡 DMA 直达显存，免主机中转）依赖这个亲和；云环境开启 ACS 会强制绕 CPU，是“本地快云上慢”的经典原因；
异常格子：本该 NV 的位置出现 PHB/SYS，说明拓扑降级，训练吞吐会无声下跌。

环形 AllReduce：通信量的小学数学

数据并行训练每步要把各卡梯度归约（AllReduce）。NCCL 的环形算法把数据切块沿环传递，每卡发送量为：

每卡发送量 = 2 × (N-1)/N × 数据量 ≈ 2 倍数据量（与卡数几乎无关）

这个“常数发送量”是数据并行能扩展到几百卡的数学根基。工程上只需两个结论：

环的速度由最差一段决定：环上任何一步跨机器，整环被拉到网卡带宽。所以 NCCL 启动日志（NCCL_DEBUG=INFO）里的 Via NVL（好）与 Via SYS/PCIe（坏）值得纳入部署验收；
nccl-tests 的 busbw 才是可比指标：busbw = algbw × 2(N-1)/N 归一化了环系数，单节点 H100 大消息应达 430–480 GB/s（NVLS 开启后 700+）；只有 200 左右说明掉到了 PCIe。

拓扑对调度的三条硬规则

张量并行（TP）留在同一 NVSwitch 域内：TP 每层通信，小而频，跨机即灾难。推理 TP=4/8 的部署同理。
跨 MIG/vGPU 实例的并行是陷阱：MIG 实例间（以及多数 vGPU 形态下）P2P/NVLink 不可用，跨实例的 TP 会退化到 PCIe 甚至主机中转。多实例节点只服务 TP=1 的模型分档。
Kubernetes 原生不感知这些：调度器只数卡数，选哪几张卡发生在 kubelet 侧且拓扑盲。现实践是节点级独占（大任务整节点）、注入有序的 CUDA_VISIBLE_DEVICES，以及未来由DRA把“同一 NVSwitch 域的 4 张卡”变成可声明约束。

工程经验

排查“多卡任务慢”的标准顺序：先看 NCCL 日志走的路径，再看拓扑表，最后才怀疑应用。多数“GPU 性能问题”在这一层就有了答案。

NVLink 数字必须带上世代标签

NVIDIA 当前的 NVLink 页面描述了 Rubin 的第六代 NVLink：每 GPU 3.6 TB/s、72 GPU 域共 260 TB/s 聚合带宽；Blackwell 页面则是第五代 NVLink、72 GPU 域 130 TB/s。这些数字不可互换。一份严肃的架构文档总会写清代数、平台、方向约定，以及数字是每链路、每 GPU 还是聚合值；把它与世代、模块与产品语言的五层词汇一起写进采购清单。

图 1: 物理位置决定了数据可走的路径

GPUDirect：在受支持处消除多余拷贝

GPUDirect 系列技术减少 GPU 显存与网卡、存储等对端设备之间的拷贝。GPUDirect RDMA 可让网络适配器经由受支持的软硬件路径直接向显存搬数据；GPUDirect Storage 面向存储与显存之间经由加速路径的数据搬运。注意它们是端到端特性：需要验证固件、驱动、内核模块、PCIe 布局、权限、容器能力和库行为。“网卡支持 RDMA”不能证明应用正在使用显存直传。

rank 映射与扩展效率

一个分布式进程拥有 rank 和设备分配，从 rank 到 GPU、从 GPU 到网卡、从 GPU 到对端链路的映射影响每一次集合通信的路径。正确性也许能在糟糕的映射下幸存，性能不会。应用可以完美调优于单节点域，却在跨节点域上无法扩展，所以基准计划必须至少有三条基线：单 GPU、单服务器全部 GPU、同一工作负载跨两台及以上服务器。结果可以用一行诊断式表达：

扩展效率 = 单设备耗时 / (N × N 设备耗时)

它是诊断工具而非经济模型：请在旁边同时记录通信占比、排队时间、失败和每次完成运行的成本（见容量经济）。

常见误区

误区	真相
8 GPU 的 Pod，K8s 会放好	原生调度拓扑盲，可能跨 4 台机器
NVLink 900GB/s 是任意两卡之间	是每卡聚合双向带宽，经 NVSwitch 仲裁
万兆以太网也能跑分布式训练	能跑，AllReduce 慢一个数量级，卡在等网络
MIG 实例间还能 NVLink 通信	默认关闭，跨实例 TP 是性能陷阱
加了 GPU 的节点网络就够了	RDMA 亲和、peermem、ACS 是一组独立的主机级前置条件

表 2: 互连层的常见误区

总结

互连层给平台的结论可以压缩成一句：通信留在金字塔上层。训练的数据并行可以跨机（环形算法发送量是常数），张量并行必须同机同域；共享与切分方案会改变 P2P 可用性，因此“切分后能否并行”是选型时必须显式回答的问题（见决策轴）。把拓扑表纳入节点档案、把 NCCL 路径纳入部署验收，是成本最低的两项治理动作。

参考资料

作为拓扑的服务器：机箱里的距离不平等

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

“同一台服务器”不等于“同样的距离”：数据搬运的成本取决于路径，而路径由拓扑决定。

打开机箱：CPU、内存、PCIe、GPU、网卡、存储

一台服务器是一张图：CPU 插槽拥有内存通道；PCIe 根复合体（root complex）连接设备；GPU 与网卡可能分属不同的 NUMA 节点；NVSwitch 或 PCIe 交换芯片可能创建额外路径；NVMe 设备可能离某个插槽更近。Linux 内核通过 NUMA 与 PCI 元数据暴露这张图的一部分，厂商工具则暴露加速器专属的链路。

去神话的 NUMA

NUMA（非统一内存访问）意味着内存访问成本取决于内存域。CPU 访问挂在自己插槽下的内存通常是本地访问；访问另一插槽的内存则是远端访问。确切的延迟和带宽取决于平台与负载，但架构层面的区分是可靠的。

对 GPU 工作负载，关键问题常常是：哪些 CPU 核心、哪个内存库、哪个 PCIe 根复合体、哪块网卡离这块 GPU 最近？主机侧数据加载器、页锁定内存（pinned memory）、中断、RDMA 和控制线程都会受影响。Kubernetes 层面对应的治理机制见NUMA 感知调度。

观察	可能原因	有用证据
GPU 喂不饱	远端内存或缓慢的输入管线	numactl、CPU 亲和性、输入吞吐
集合通信慢	GPU/网卡配对错误或缺对等链路	nvidia-smi topo -m、NCCL 图日志
抖动	主机争用、中断或共享 PCIe 路径	CPU 绑核、PCIe 树、节点负载构成
Pod 被拒	严格拓扑策略无法满足提示	kubelet 策略与设备插件提示

表 1: 服务器层拓扑问题的观察与证据

检查仪式

nvidia-smi -L
nvidia-smi --query-gpu=index,name,pci.bus_id,memory.total,power.limit \
 --format=csv
nvidia-smi topo -m
lscpu -e=CPU,NODE,SOCKET,CORE
numactl --hardware
lspci -tv
lspci -vv -s <GPU-PCI-BDF>

这些输出不是文书工作

把它们存为节点镜像的工件。拓扑是工作负载性能契约的一部分，互连与集合通信的“读拓扑表”与排障手册的收敛流程，都从这里出发。

为什么 BIOS 和固件也在故事里

IOMMU 模式、PCIe 链路设置、电源管理、固件、风扇策略和平台固件都会影响设备可见性与性能。一个通过了软件冒烟测试的节点，仍可能带着一份在负载下发生变化的硬件或固件配置。请把平台基线当作带版本的基础设施，这与安全、可靠性与生命周期中的版本矩阵是同一个思想。

总结

调度器眼中的“一个节点”，在物理上是距离不平等的一张图。把拓扑检查变成装机仪式、把结果存成工件，NUMA 与互连层面的性能问题就有了第一手证据。下一章的加速器全景把视野从单机扩展到生态。

异构加速器全景与生态：芯片类型、厂商版图与 Kubernetes 集成

Jimmy Song — Sun, 19 Apr 2026 00:00:00 +0000

成熟的 AI 系统不是押注单一算力，而是运行在异构芯片组合之上。对平台工程师来说，真正影响选型的不是谁融资多，而是这块卡能不能跑通你现有的 Kubernetes 调度体系。

本章用两个正交的坐标系建立加速器认知：设备类别（这块芯片是什么、擅长什么）与厂商版图（谁在做、集成难度如何）。两个视角回答不同的问题，缺一不可：只知道类别会陷入“NPU 都是端侧芯片”之类的误解，只知道厂商则容易把营销参数当工程事实。

为什么要分类：两种坐标系

很多团队一聊 AI 基础设施，第一反应就是“是不是该多买点 GPU”。到了 2026 年，这个问题已经过时了。很多 AI 芯片分析喜欢用“头部/腰部/尾部”或者“第一/第二梯队”来划分厂商，这种分法对投资人也许有用，但对基础设施工程师价值有限：一个融资三轮的通用 GPU 厂商和一个已经量产交付的专用推理芯片公司，放在一起比“梯队”没有意义，因为它们解决的是完全不同的问题。

更实际的做法是用两个正交的坐标系：

按设备类别分：CPU、GPU、TPU、NPU、DPU、APU、LPU。类别内部，工程决策的逻辑相似：通用 GPU 之间比 CUDA 兼容性和驱动成熟度，专用 AI 加速器之间比框架支持和场景适配。
按厂商阵营分：通用 GPU、专用 AI 加速器、云厂商自研芯片、垂直场景芯片。阵营决定了你能不能买到、能不能本地部署、能不能接入多云。

Kubernetes 集成成熟度则是横跨所有类别与阵营的一条评估主线。

设备类别：从 CPU 到 LPU

这些芯片类别不是营销产物，而是系统压力层层递进的结果：计算需求的增长超过了通用芯片单一路线能承载的效率边界。深度学习带来矩阵计算爆发，GPU 崛起；随后边缘 AI、低延迟推理、数据中心网络瓶颈、多租户隔离，又各自催生了新的专用处理器。

类别	全称	擅长什么	典型场景	最常见误用
CPU	Central Processing Unit	通用计算、复杂逻辑	控制面、预处理、调度	拿来硬扛大模型计算
GPU	Graphics Processing Unit	并行矩阵计算	训练、批量推理	用来做低并发强实时对话
TPU	Tensor Processing Unit	张量计算加速	Google Cloud 训练/推理	当作通用 GPU 使用
NPU	Neural Processing Unit	低功耗推理（端侧）与数据中心推理（昇腾）	AI PC、边缘设备、推理服务器	以为 NPU 只在端侧，或拿端侧 NPU 做训练
DPU	Data Processing Unit	网络/存储卸载	大规模 AI 集群	小规模场景过度建设
APU	Accelerated Processing Unit	CPU+GPU 紧耦合	单机微调、HPC	只看 FLOPS 忽略内存优势
LPU	Language Processing Unit	低延迟语言生成	实时 Agent、语音 AI	当通用训练芯片

CPU 的强项一直没变：分支判断、多任务调度、I/O 管理、数据预处理、Tokenizer、Agent workflow orchestration。它擅长的是决定“下一步做什么”，而不是把同一个乘加动作重复几十亿次。在 AI 系统里，CPU 更像控制平面，没有 CPU，GPU 集群往往也跑不顺。

GPU 赢在大规模并行矩阵计算：数千核心加 HBM 加 Tensor Core，把 Transformer、CNN、Embedding 依赖的矩阵乘法做到极致，至今仍是训练的默认选择。但 GPU 的利用率经常被高估（作业碎片化、多租户抢占、显存不匹配），GPU 越多调度越难，而且它不是天然适合低并发强实时的交互场景。

TPU 的逻辑是放弃通用性，换取特定任务的极致效率：针对 Transformer、JAX/TensorFlow 与 Google Cloud 深度优化。它更像一整套平台能力而不是单独一块卡，适合大规模训练与高密度 serving，不适合任意框架迁移、本地部署或高自由度实验。

NPU 需要特别澄清：它既是端侧 AI 的主角，也是数据中心的主力。端侧 NPU 为电池、发热、响应速度与本地隐私而生，负责实时字幕、本地 Copilot、语音助手；而华为昇腾 910 系列是数据中心训练与推理芯片，本书昇腾 vNPU一章分析的全部是机架级 NPU 服务器。把 NPU 等同于端侧芯片，会直接漏掉数据中心 AI 算力版图中的一大块——华为昇腾正是其中的代表。

DPU 解决的是“问题不在 GPU，而在网络”的场景：RDMA 管理、存储 I/O、East-West 流量、加密开销。NVIDIA BlueField 是典型代表，几十卡以下感受不明显，几百卡以上会变成真实成本。

APU 押注统一内存：现实中大量性能浪费在 CPU 内存与 GPU 显存之间的 PCIe 来回复制上，APU 让两者紧耦合、共享地址空间。AMD MI300A 与 Apple Silicon Unified Memory 是代表路线。

LPU（Groq 提出）赌的是“LLM 推理是一条可高度流水线化的固定路径”，强调 token 生成延迟、确定性执行与极低 jitter。它是推理特化路线的实验方向，不是 GPU 替代品。

厂商版图：四大阵营

下面的图谱按通用 GPU、专用 AI 加速器、云厂商自研芯片和垂直场景芯片四个阵营组织厂商，底部标注了横跨所有类型的 K8s 集成成熟度评估线。

图 3: AI 加速芯片生态图谱：按芯片类型与 Kubernetes 集成成熟度分类

芯片类型	核心特征	K8s 集成难度	典型玩家
通用 GPU	兼容 CUDA/ROCm，通用计算	低	NVIDIA、AMD、海光、沐曦、摩尔线程、壁仞、天数智芯
专用 AI 加速器	自研架构，针对推理/训练优化	中	华为昇腾、寒武纪、燧原、算能、昆仑芯、Google TPU、Qualcomm
云厂商自研芯片	起于自用，部分已外销	视云而定	平头哥 PPU、AWS Trainium、Microsoft Maia、Meta MTIA、腾讯紫霄
垂直场景芯片	面向特定终端或场景	高（或不适用）	地平线征程、黑芝麻、爱芯元智、Apple Neural Engine

表 5: AI 加速芯片四象限分类

通用 GPU 阵营

NVIDIA 仍然占据绝对主导地位。Blackwell Ultra（B300/GB300）是当前量产主力，Rubin（Vera Rubin NVL72）自 2026 年年中起进入量产爬坡，CUDA 生态的护城河不是一年两年能填平的。Kubernetes 生态中 NVIDIA 提供了最完整的工具链：官方 Container Toolkit、Device Plugin、MIG 多实例支持，并且已经在推进 DRA 驱动。HAMi 对 NVIDIA GPU 的支持也最完善。选 NVIDIA 意味着最低的集成风险，代价是硬件成本和供应商锁定。

AMD 是最有力的替代选项。MI350 系列（MI355X）已规模出货，在性能上与 Blackwell Ultra 接近、性价比更有竞争力，ROCm 软件栈进步明显，PyTorch 官方支持已经比较完善，官方 Device Plugin 与 ROCm 容器运行时齐备，DRA 驱动开发中。主要短板在 CUDA 兼容性：HIP 转换工具能用，但大型项目的迁移成本不可忽视。

中国通用 GPU 厂商近几年进步很快，但工程成熟度和 NVIDIA 仍有明显差距。海光（Hygon）的 DCU（深算系列）是中国 GPGPU 中部署规模最大的路线之一，类 ROCm 生态（DTK）兼容主流 AI 框架，深算三号已在信创（信息技术应用创新，中国推动关键行业 IT 供应链本土化的政策体系）数据中心规模化落地，K8s 侧经自有插件与 HAMi 接入。摩尔线程是少数同时具备桌面和数据中心产品线的全功能 GPU 公司，MUSA 架构兼容主流图形和计算 API，K8s 集成通过自有 Device Plugin 和 HAMi 接入。沐曦走对标 AMD 的路线，曦云 C500/C550 强调 CUDA 兼容性。壁仞的 BR100 采用 Chiplet 架构，峰值参数亮眼但交付与软件栈成熟度还有距离。天数智芯是中国较早研发 7nm 通用 GPU 的企业。它们的共同挑战是 CUDA 生态兼容性；K8s 集成主要靠自有插件（基础调度）或 HAMi（共享调度），DRA 方案基本空白。

专用 AI 加速器阵营

华为昇腾是中国专用 AI 加速器中部署规模最大的。910 系列已迭代多代，CANN 加 MindSpore 构成完整软件体系，从芯片到服务器到云服务全栈覆盖，在信创和超算领域大量部署。K8s 集成提供专用 Device Plugin，支持静态和动态虚拟化，HAMi 已支持共享调度。主要限制是不兼容 CUDA、迁移成本高，DRA 驱动尚未公开。

寒武纪是中国 AI 芯片的先行者，思元 590 已在大模型训练场景规模化落地。官方 Device Plugin 齐备，HAMi 已集成细粒度共享调度。燧原专注训练与推理，云燧与雨霁系列已迭代三代，获得腾讯投资。算能（Sophgo，比特大陆系）的 BM1684X/BM1688 推理芯片在视频结构化、边缘推理场景保有大量部署。昆仑芯是百度自研云端 AI 芯片，实际使用高度绑定百度生态。Google TPU 是国际阵营的代表：不对外售卖硬件，只通过 Google Cloud 提供服务，GKE 提供原生 TPU 支持，但社区标准的 Device Plugin 与 DRA 方案不适用。

国际阵营还有两个值得记录的变化：Qualcomm 以 Cloud AI 系列进入数据中心推理市场，AI200 计划 2026 年上市；Intel Gaudi 系列则在 2025 年后逐步退出，成为“收购造芯”路线的注脚。Cerebras（晶圆级）与 SambaNova（RDU）等新架构目前以专用系统形态交付，K8s 生态接入薄弱，暂不进入主流选型清单。

云厂商自研芯片阵营

云厂商自研芯片最初“不为卖而做，为己所用”，但 2025 到 2026 年出现了明确的外销转折，这个阵营的选型逻辑正在改写。

阿里巴巴平头哥是转折的标志。2019 年的推理芯片含光 800 只在阿里云内部部署；2026 年 1 月上线的 PPU 真武 810E（96GB HBM2e、700GB/s 片间互联）已对标 A800/H20 水平；2026 年 5 月发布的真武 M890 升级为训推一体（144GB HBM、800GB/s），并配套 128 卡超节点服务器与自研 ICN Switch 互联芯片。PPU 已从阿里云内供转向外销，出货达数十万片量级。腾讯紫霄仍服务于游戏 AI、内容审核与推荐等内部场景。百度昆仑芯横跨“自研”与“外销”两个象限，在推进外部商业化。

国际云厂商的自研芯片规模更大、K8s 生态也更成熟。AWS Trainium2 已随 Trn2 实例规模商用作训推，64 芯片 NeuronLink 互连的 Trn2 UltraServer 提供超节点形态；对本书读者最重要的是，EKS 同时提供 Neuron device plugin 与 Neuron DRA 驱动，是 NVIDIA 之外 DRA 落地最实的案例。Microsoft Maia 200（2026 年 1 月发布，3nm、216GB HBM3E）定位推理，正在 Azure 上线。Meta MTIA 公布了两年内四代（300 到 500）的路线图，覆盖排荐训练到 GenAI 推理。Tesla Dojo 经历了 2025 年 8 月解散与 2026 年初重启，转向车端与机器人推理，不建议纳入平台选型。Google TPU 横跨“专用加速器”与本阵营，是这条路线最早的产品化范本。

选型逻辑：深度使用某家云，可以评估其自研芯片经云服务使用的性价比；需要本地化部署的，平头哥 PPU 与昆仑芯已经开始外销，但软件栈成熟度需要按本书的验收方法自行验证。

垂直场景芯片阵营

地平线征程、黑芝麻的车载芯片服务于智能驾驶，爱芯元智（AXera）的推理 SoC 覆盖边缘视觉与智能汽车（已在港交所上市，下一代大算力芯片完成流片），Apple Neural Engine 内置于 iPhone 和 Mac。它们解决的是终端设备上的 AI 推理问题，部署形态是嵌入式系统或边缘设备，通常不需要也不适合接入 K8s 调度体系。另一条值得跟踪的新架构路线是存算一体：后摩智能已量产浮点存算一体芯片并用于端边大模型部署，它绕开了显存带宽瓶颈，但调度与切分语义与传统加速器不同，K8s 集成尚在早期。

Kubernetes 集成成熟度：一条横跨所有阵营的评估线

无论芯片属于哪个阵营，最实际的问题是：这块卡能不能跑通我现有的 K8s 体系？分三层评估。

基础调度层：Device Plugin 是否可用。 驱动能否在容器内正常工作、插件能否向调度器报告设备、Pod 能否拿到正确的设备可见性。NVIDIA 最好，AMD 基本可用，昇腾和寒武纪有官方插件，其余中国厂商主要通过自有插件或 HAMi 接入。

共享与隔离层：是否支持细粒度资源切分。 NVIDIA 有 MIG 硬件隔离、vGPU 软件虚拟化和时间片复用，HAMi 提供统一共享调度框架。昇腾有静态/动态虚拟化两条路径，其他中国厂商大多只有整卡分配。

控制面集成层：是否支持 DRA。 DRA 把设备分配从 kubelet 本地的 Allocate 黑盒提升到控制面可见的 ResourceClaim，详见 DRA 一章。NVIDIA 的 CDI-based DRA 驱动已进入 beta 阶段，AWS 在 EKS 上提供了 Neuron DRA 驱动，其他厂商基本处于观望或早期开发状态。

厂商	Device Plugin	共享/隔离	DRA 驱动	HAMi 支持
NVIDIA	官方，成熟	MIG/vGPU/时间片	Beta（CDI-based）	完善
AMD	官方，可用	SRIOV 部分支持	开发中	有限
Intel	官方，可用	整卡直通为主	探索中	有限
华为昇腾	官方，可用	静态/动态虚拟化	未公开	已支持
寒武纪	官方，可用	HAMi 集成	待推进	已支持
海光	自有插件	HAMi 接入	未公开	已支持
摩尔线程	自有插件	HAMi 接入	未公开	部分支持
沐曦/壁仞/天数智芯	自有插件	HAMi 接入	未公开	有限
Google TPU	GKE 原生	拓扑切分	云托管路径	不适用
AWS Trainium/Inferentia	EKS 原生	按 NeuronCore 粒度	已提供（EKS）	不适用

表 6: 各厂商 Kubernetes 集成成熟度速查

选型框架

把两个坐标系合起来，决策其实很直接：

预算充足且要最低集成风险：NVIDIA 仍是默认选项，代价是成本与锁定。
降低对 NVIDIA 的依赖：AMD 是当前最现实的替代，迁移成本主要在 CUDA 到 HIP 的适配。
信创或政策要求采用中国厂商方案：通用 GPU 看摩尔线程与沐曦，专用加速器看昇腾（部署规模最大）与寒武纪。做好投入更多工程力量处理兼容性与稳定性的准备。
深度绑定某家云厂商：评估其自研芯片经云服务使用的性价比（AWS、Azure、Google 皆是此模式）。确需本地化部署的，平头哥 PPU 与昆仑芯已开始外销，按本书的验收方法自行验证其软件栈成熟度。
按工作负载选类别：训练优先 GPU；大规模云训练评估 TPU；端侧产品优先 NPU；超大规模集群必须考虑 DPU；单机微调看统一内存 APU；低延迟对话评估 LPU；CPU 永远在场。
多芯片混合部署：这是最有挑战也最有价值的场景。未来的竞争不是谁 GPU 最多，而是谁最会调度异构芯片；DRA 的成熟、HAMi 的扩展、Volcano/Kueue 的异构支持都在为这个方向铺路。

调度异构芯片是云原生的下一阶段

过去 Kubernetes 调度的是 CPU 和 Memory，后来加上了 GPU，未来会扩展到 GPU memory、topology、NUMA、tokens/sec、latency SLA、NPU slots 和 power budget。这意味着 Kubernetes 正在从容器编排器进化为 AI Control Plane，而异构芯片时代，资源调度层会越来越重要。

最后，别再迷信单卡性能榜。纠结 H100 强还是 B300 强、TPU 值不值、NPU TOPS 高不高，这些问题有价值但都不是核心问题。真正的问题是：你的系统是否让正确的任务跑在正确的芯片上。未来赢家不是买最多卡的人，而是最会组织算力的人。

总结

异构加速器的认知需要两个坐标系：设备类别回答“这块芯片擅长什么”，厂商阵营回答“我能不能买到并跑进我的 K8s 体系”。类别上，从 CPU 到 LPU 各有明确的甜蜜点与常见误用，其中 NPU 同时覆盖端侧与数据中心是最容易被低估的一条；阵营上，NVIDIA 以最低集成风险主导，AMD 是最现实的替代，昇腾与寒武纪领跑中国厂商的专用路线，海光等中国 GPGPU 充实了通用计算选项，云厂商自研芯片（AWS Trainium、平头哥 PPU、Maia、MTIA）则从自用走向外销与超节点。对所有这些芯片，Kubernetes 集成成熟度（Device Plugin、共享隔离、DRA）是横跨的评估主线，也是未来一两年区分生态优劣的关键指标。

参考文献

AI 加速器的 Kubernetes 管理模型

Jimmy Song — Sat, 15 Aug 2026 07:53:32 +0000

Kubernetes 从来不关心你的加速器叫 GPU、NPU 还是 TPU。它只认扩展资源，而隔离与切分永远由厂商的数据平面决定。

本章要解决什么

上一章从设备类别与厂商阵营两个视角画完了加速器全景。本章换第三个视角：抽象掉厂商差异，看 Kubernetes 到底如何管理这些芯片。这有三个直接收益：

纠正一个常见误解：NPU 不是端侧专属。华为昇腾 910 系列是数据中心训练与推理主力，本书昇腾 vNPU一章分析的全部是机架级 NPU 服务器。
建立一个跨厂商的心智模型：换一颗芯片，控制面几乎不变，数据面全部重来。这个判断决定了本书的结构，也决定了平台团队的技能投资方向。
为中国厂商加速卡的选型与落地提供工程视角的补充。

统一管理模型：四步抽象

把谱系抽象掉，Kubernetes 眼中的加速器只有一个统一模型：

上报：device plugin 把设备以扩展资源的形式注册到节点（nvidia.com/gpu、huawei.com/Ascend310P、google.com/tpu 名字不同，语义相同）。
调度：调度器只看资源数量（DRA 之后升级为可推理的设备属性与声明，见 DRA 一章），不关心设备的隔离与切分细节。
分配：kubelet 调用插件的 Allocate，把设备、驱动库、注入配置装进容器。
隔离：完全由厂商数据平面决定。MIG 分区、昇腾驱动模板、HAMi 拦截库都在这一层生效，Kubernetes 本身对此一无所知。HAMi 2.10 进一步扩展了支持的设备范围，包括 AMD MI300X 和 Biren 加速器，并通过与 KAI Scheduler 的集成提供调度与隔离的对应关系。

这个模型解释了本书的结构安排：控制面的队列、配额、gang 调度（Volcano、Kueue）对所有加速器一视同仁；数据平面的切分与隔离（数据平面各章）则要逐厂商逐技术地分析。

厂商之间的差异都藏在第 1 步和第 4 步的细节里：TPU 需要额外的拓扑感知（芯片组合必须对得上互连结构），昇腾需要 Ascend Docker Runtime 做设备与库注入，GPU 生态则有 Operator 把驱动、监控、设备插件整体容器化。各家接入 Kubernetes 的方式高度趋同，这是上一章厂商版图背后的一致性。

切分能力的不对称

上一章的集成成熟度速查表里，“共享/隔离”一列值得单独展开，因为它决定了数据平面能做什么：

NVIDIA 与昇腾是唯二同时具备硬切分与软切分两条路线的生态（MIG 加 HAMi/时间片；驱动模板加 vCANN-RT/HAMi）。HAMi 2.10 新增 Flexible MIG 功能，支持动态 MIG 实例分配，无需排空节点。
TPU 只有芯片粒度的拓扑切分，属于硬切分的一种特殊形态。
AMD 与多数中国厂商加速卡目前依赖整卡分配加软件共享，没有硬件级分区。

这就是为什么本书的深度技术章集中在 GPU 与昇腾，不是偏心，而是机制丰富度使然。两条路线的完整对比见硬切分与软切分一章。

中国厂商加速卡的工程现实

对于在中国厂商算力上做平台的工程师，厂商版图之外还有三个工程事实值得记住：

生态成熟度差异大。昇腾的软件栈（CANN、mind-cluster）完整度最接近 NVIDIA，但版本配套严格（驱动、CANN、框架、容器镜像常要求成对匹配，本书昇腾实验中 libvnpu 与驱动版本必须匹配就是同一逻辑的缩影）；多数中国厂商加速卡的算子覆盖仍需逐模型验证。
共享治理高度依赖 HAMi。HAMi 是唯一一个用统一模型治理大部分中国厂商加速卡的 CNCF 项目，支持 NVIDIA、华为昇腾、寒武纪、海光 DCU、壁仞、燧原、MetaX、昆仑、摩尔线程、AWS Neuron、Vastai 和 AMD MI300X 等十多种异构加速器，这也是它在这本书里反复出现的原因。
超节点是新变量。昇腾 910C 的 CloudMatrix 384、NVIDIA 的 NVL72 与平头哥 PPU 的 128 卡超节点（自研 ICN Switch 互连）把“多卡紧耦合成一个逻辑节点”作为扩展路线，这类系统的调度单位已经不是单卡，Kubernetes 侧需要新的拓扑与亲和模型（Topology Manager 与 DRA 的持续演进都在回应这一点）。

总结

抽象掉厂商差异后，Kubernetes 管理加速器的模型只有四步：插件上报扩展资源、调度器按数量（或按 DRA 声明）分配、kubelet 完成设备注入、厂商数据平面负责隔离。控制面跨芯片通用，数据面逐厂商重来；切分能力的不对称（NVIDIA 与昇腾双路线齐备，TPU 仅拓扑切分，多数中国厂商加速卡靠软件共享）决定了各生态在数据平面上的可选项。对所有这些芯片，同一套方法都成立：用决策轴比较，用数据平面谱系归类，用可复现实验验收。

参考资料

Kubernetes 的设备资源抽象与演进

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

真正理解 Kubernetes 设备模型的边界，才能为 GPU 平台的可扩展性和治理能力打下坚实基础。

本章将解释 Kubernetes 的设备资源语义为何天然倾向于“整卡分配”，以及更细粒度表达在工程上意味着什么。重点聚焦“边界与责任”，为后续 MIG/HAMi 的数据平面讨论与 Volcano/Kueue 的控制面讨论提供共同前提。

结论先行：Kubernetes 并非“缺少 GPU 调度能力”，而是其资源抽象天然偏向“离散设备”

Kubernetes 的核心资源模型是为 CPU/内存这类“可分割、可约束、可度量”的资源设计的；而 GPU、FPGA、NIC 这类 设备资源（Device Resource） 更接近“离散、稀缺、强状态”。因此，Kubernetes 对设备资源的主流抽象是：

以 Extended Resource 的形式做“整数计数”调度（例如 nvidia.com/gpu: 1），调度器只负责把 Pod 放到“具备足够整数设备”的节点上。
把“具体哪一块设备、如何准备/挂载/注入”下沉到 kubelet 侧的 Device Manager + Device Plugin，在 Allocate 阶段完成。

这意味着，后续讨论 MIG、HAMi、GPUStack 时，必须先明确“责任边界”：Kubernetes 默认只提供离散资源的声明与调度，不承诺更细粒度共享与 QoS。细粒度能力要么靠数据平面扩展，要么依赖新一代资源 API（DRA, Dynamic Resource Allocation）。

设备资源在 Kubernetes 里的基本表达：Extended Resources（标量、整数、不可超卖）

在 Kubernetes 中，设备资源的表达方式有其独特之处，主要体现在 Extended Resource 的使用上。

为什么 GPU 看起来总是“整卡整数”

Kubernetes 调度器擅长处理“标量资源（Scalar Resource）”，设备资源通过 Extended Resource 被当作一个标量计数：节点上有多少、Pod 要多少。以 GPU 为例，官方任务文档直接将 GPU 作为一种可被调度的节点资源，强调其依赖 device plugin，并同时指出实现存在限制。

这解释了为什么“资源请求”在 Pod spec 里几乎总是 nvidia.com/gpu: 1/2/…：这并非 GPU 的全部能力，而是 Kubernetes 资源模型对设备的主流折中。

为什么设备资源通常只放在 `limits`（并且要求 requests=limits）

Kubernetes 对设备资源的调度依赖于“你要用多少设备”，但设备本身无法像 CPU 一样被 cgroup 精确限流。因此，设备资源通常只在 limits 中声明，并被实现要求“requests == limits”才能获得确定的调度与分配语义（这也是 GPU 相关文档里常见的写法）。

Device Plugin 机制：控制面只做“放哪”，数据平面负责“给什么”

Device Plugin 是 Kubernetes 官方为“非核心硬件资源”提供的标准扩展机制。厂商或项目实现一个 plugin，kubelet 通过 gRPC 注册并与之交互。官方文档给出了 registration gRPC 的接口形态，并描述了注册与后续交互流程。

在 kubelet 内部，由 Device Manager 负责与 device plugins 通信并完成设备发现、广告与分配。Kubernetes 官方博客总结了其工作方式：device plugin 通过 Unix socket 与 kubelet 通信，负责设备发现/广告（作为 extended resources）与 allocation。

整个链路可抽象为三步（对后续排障极其关键）：

Advertise：device plugin 发现设备并让 kubelet 将其作为 Extended Resource 暴露给调度器。
Bind：调度器完成 Pod→Node 绑定。
Allocate：kubelet 调用 device plugin 的 Allocate，把“具体设备 ID”交付给容器运行时（并做必要的 mount/环境变量/设备文件准备）。

下图展示了 Device Manager 的完整工作流程：

图 1: Device Manager 工作流程

这意味着：调度器并不知道你最终拿到的是哪块 GPU，更不知道你希望的是 MIG profile、时间片还是显存配额。 这些都属于数据平面“兑现层”的事情。

三个关键 gRPC 调用与完整生命周期

把上面三步展开到 gRPC 层面（以 NVIDIA 设备插件为例）：

**ListAndWatch（流式）：**kubelet 调用一次，插件先发来全部设备的初始清单（设备 ID + Healthy/Unhealthy 健康状态），此后每当健康变化就推送更新。kubelet 聚合计数并以 nvidia.com/gpu: N PATCH 节点的 status.capacity/status.allocatable，这是调度器读取的数字。
**Allocate：**Pod 落到节点后，kubelet 携带设备 ID 列表调用，插件返回环境变量（关键是 NVIDIA_VISIBLE_DEVICES=GPU-uuid）、挂载与设备文件，交给容器运行时。Container Toolkit 钩子正是读这个环境变量决定注入哪块 GPU（见NVIDIA Container Toolkit）。
GetPreferredAllocation（可选）：让插件基于拓扑返回优先设备组合，例如优先 NVLink 互连的 GPU 对。

# NVIDIA 设备插件完整生命周期
# 1. DaemonSet 启动 → NVML 发现 GPU → 创建 socket
# 2. 调 kubelet 的 Register 宣告资源名 nvidia.com/gpu
# 3. kubelet 回连，ListAndWatch 流式上报设备清单
# 4. kubelet PATCH 节点容量
# 5. Pod 调度 → GetPreferredAllocation（可选）→ Allocate
# 6. 注入 NVIDIA_VISIBLE_DEVICES → 容器拿到独占 GPU
# 7. 持续健康监控：故障 GPU 标记 Unhealthy，容量减一

设备资源抽象的天然边界：为什么“更细粒度 GPU”在 Kubernetes 里并不自然

当你把 GPU 视作整数计数时，会立刻出现三类不可避免的缺口：

连续资源与多维约束无法表达
显存、带宽、拓扑、干扰都不是一个整数能表达的。调度阶段只有“有/没有、够/不够”的判断，难以对 P99、抖动与干扰建立承诺。
“共享”不是 Kubernetes 资源模型的一等公民
Device Plugin 的语义是“把一个离散设备交付给容器”。如果你想让多个 Pod 共享一块 GPU，本质是在做“超卖/分时/切分”的资源复用，这会越过原生模型边界，必须由数据平面实现并自行承担 QoS、隔离与计量责任。
拓扑与可用性由节点侧决定，控制面很难推理
设备的健康、驱动兼容、MIG 重配置、CUDA runtime 差异，都可能在 Allocate 阶段才暴露。你看到的可能是“调度成功但运行失败”，而这种失败不能靠调度算法本身解决。下图清晰地展示了 Kubernetes 设备资源的抽象层次与各层的责任边界：

图 2: Kubernetes 设备资源抽象层次

“演进”发生在哪里：从 Device Manager GA 到 DRA

Kubernetes 对设备资源的演进路线，本质是在回答一个问题：如何让设备的“选择、参数化、共享与生命周期”变成可声明、可推理、可自动化的 API，而不仅仅是 kubelet 本地的 Allocate 黑盒。

Device Manager / Device Plugin 的成熟：把“接入异构设备”标准化

Device Plugin 让厂商无需修改 Kubernetes 核心代码就能接入设备；Device Manager 在 kubelet 内部承接交互并成为标准通道。官方对 Device Manager 的总结强调它通过 gRPC 与 plugin 完成设备发现、广告与分配，是设备接入的关键基础设施。这条路线解决的是“接得进来”，但对“怎么选、怎么共享、怎么治理”支持有限。

DRA（Dynamic Resource Allocation）：把设备选择从“节点本地黑盒”推进到“可声明的资源 API”

DRA（Dynamic Resource Allocation）机制让 Pod 能请求并共享（尤其是硬件加速器等附加设备）资源。管理员定义 device classes，Kubernetes 为 claim 分配匹配设备，并把 Pod 放到能访问已分配设备的节点上。对应的 KEP 也明确：Resource driver 负责 ResourceClaim 的分配/回收等与设备相关的操作。

从“GPU 平台化”的视角看，DRA 解决的关键问题是：

参数化请求：不再只能声明“1 块 GPU”，而是声明“某类设备 + 某组参数”的 claim。
可推理的分配对象：设备分配从 kubelet 的 Allocate 走向控制面可见、可审计的资源对象。
为生态扩展预留接口：驱动/厂商/平台可以通过 DRA driver 实现设备分配逻辑，而不是把所有策略塞进 scheduler extender 或私有实现。

DRA 的核心 API 已在 Kubernetes v1.35 进入 GA；它与调度语义的深度整合（如与 PodGroup 的协同）仍在后续版本中持续演进。

把“更细粒度 GPU”放回正确的层：MIG、时间片与资源命名

有了上述边界，你就能更清晰地理解“细粒度”的两种典型落点：

MIG：把“细粒度”变成新的离散设备单位
MIG（Multi-Instance GPU）的工程化路径通常是：在节点上把一张 GPU 切出多个 MIG 实例，然后通过 device plugin 把这些实例作为可调度资源暴露出来。NVIDIA 的 device plugin 甚至会在 mixed 策略下暴露形如 nvidia.com/mig-<slice_count>g.<memory_size>gb 的资源名供 Pod 精确申请。 NVIDIA 官方文档也专门描述了在 Kubernetes 中启用 MIG 的软件栈与前置条件，以及通过 GPU Operator 管理 MIG 配置的方式。本质上，MIG 是把“连续资源问题”重新离散化，让它重新适配 Kubernetes 的整数模型。
时间片/共享：用数据平面扩展把“共享”强行塞进整数模型
NVIDIA 在其生态中提供了 GPU time-slicing 等共享机制，并通过 device plugin/operator 提供相关能力与文档。这条路线的本质是：控制面依然只看到整数资源，但数据平面在交付阶段用时间片复用同一物理设备。其优点是弹性与利用率，代价是隔离、可预测性与计量口径需要你在平台层补齐。

本章对后续章节的“共同前提”：边界与责任

到这里，你应当得到三条可直接复用的判断准则（后续对比 HAMi、GPUStack、Volcano、Kueue 时都用得上）：

凡是解决“谁先用、谁等、配额怎么承诺”的，属于控制面问题（典型是 Kueue / Volcano 的队列与策略语义）。
凡是解决“GPU 如何切、如何共享、如何隔离、如何交付”的，属于数据平面问题（MIG / time-slicing / 各类虚拟化与 device plugin 扩展）。
Kubernetes 原生设备模型默认只保证“离散设备的声明与交付”，不保证共享 QoS。你想要“可治理共享”，就必须引入数据平面机制与观测/计量闭环，或者走向 DRA 这类更强的资源 API。

下一章“决策轴”会把这些抽象落到可评审的矩阵上：粒度、隔离、干扰、可观测、运维成本与兼容性，让你可以用同一套语言比较 MIG、HAMi、时间片共享，以及它们与 Volcano/Kueue 的组合方式。

总结

本章梳理了 Kubernetes 设备资源模型的天然边界与责任划分，明确了控制面与数据平面的分工。理解这些基础，有助于后续在平台治理、资源共享、隔离与扩展性等方面做出更合理的架构决策。

参考文献

GPU 资源治理为什么难

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

GPU 资源治理的难点并非算力本身，而在于多维资源属性与平台治理之间的天然张力。理解这些根因，是实现高效共享与隔离的前提。

图 1: 为什么 GPU 资源治理难

本章将从资源属性出发，系统解释 GPU 为什么天然不能“像 CPU 一样好调度”：显存成为第一约束、拓扑影响真实吞吐、共享带来不可预测干扰，尤其是在推理场景下，P99 尾延迟问题尤为突出。我们将通过一组典型事故模式建立直觉，并明确本书后续章节要解决的核心矛盾：如何把共享从“能跑”升级为“可声明、可治理、可验收”。

GPU 之难，不在“算力不够”，而在“资源形态不服从平台治理”

在 Kubernetes 平台中，CPU 和内存之所以易于调度，本质在于它们更接近“可拆分、可抢占、可度量、可隔离”的理想资源形态：

CPU 时间片天然可复用；
内存可通过 cgroup 做硬约束，且 OOM（Out Of Memory，内存溢出）是清晰的失效方式；
资源消耗与 QoS（Quality of Service，服务质量）问题在平台侧有成熟的治理语义（requests/limits、优先级、抢占、配额）。

相比之下，GPU 的核心挑战在于同时具备 强状态（stateful）、强耦合（coupled）、强多维（multi-dimensional） 三个特征，导致平台难以仅靠“声明式配额”获得确定性治理结果。下图展示了 GPU 资源治理的三个核心维度及其带来的后果：

图 2: GPU 资源治理的三个核心挑战

GPU 是多维资源：显存、算力、带宽、缓存、拓扑缺一不可

GPU 的可用性并非单一标量。实际场景中，你会遇到如下典型问题：

显存先耗尽：尤其在大语言模型（LLM）推理的 KV cache（键值缓存）场景下，显存会随请求数与上下文长度动态增长。显存不仅要“够用”，还要“连续可复用”。例如，vLLM 的 PagedAttention 机制正是为了解决 KV cache 的浪费与碎片化问题，通过类似“分页”的方式降低碎片与冗余。相关论文报告显示，在相同延迟水平下可显著提升吞吐（如相较 FasterTransformer/Orca 可提升 2–4 倍）。(见 Efficient Memory Management for Large Language Model Serving with PagedAttention)
算力并不等价于性能：即使分配了相同的 TFLOPS（万亿次浮点运算每秒），在不同并发、不同 kernel 组合、不同 stream 行为下，实际性能可能完全不同。
拓扑决定上限：从单机 PCIe/NVLink 到多机网络（以及 NUMA, Non-Uniform Memory Access，非一致性内存访问亲和性），都会让“同样的 GPU 数量”对应完全不同的有效吞吐。

因此，GPU 资源治理不能简单地将其视为“一个整数”，而必须明确治理目标与资源单位。以下是 GPU 多维资源属性与它们在共享时带来的核心问题：

图 3: GPU 多维资源及其共享挑战

GPU 共享的核心矛盾：利用率 vs 隔离性 vs 可预测性

在实际集群中，GPU 共享带来的挑战主要体现在利用率、隔离性和可预测性三者之间的权衡。

“共享能跑”不等于“共享可控”

许多集群采用“整卡独占”作为默认做法：每个 Pod 申请 nvidia.com/gpu: 1，调度器仅做整数匹配，设备插件负责分配设备给容器。(见 Kubernetes Device Plugin 文档)

这种方式实现简单，但会造成显著资源碎片：大量推理、小模型或轻量任务无法充分利用整卡，却被迫独占。

因此，业界自然追求 GPU 共享。但一旦共享发生，随之而来的问题包括：

干扰（interference）：多个工作负载在同一 GPU 上争抢 SM（Streaming Multiprocessor）、显存带宽、缓存，性能波动呈现“非线性”，尤其体现在尾延迟（P99）。
可预测性缺失：难以保证“某租户获得 30% GPU 就一定能达到 X QPS / Y P99”。
计量困难：CPU 可用 cgroup + 时间计量，GPU 的“算力占用”缺乏同等简单且一致的度量方式，尤其跨框架、跨运行时。

两条典型路径：强隔离的空间切分 vs 协作式共享

针对 GPU 共享，业界主要有两条典型技术路径：

MIG（Multi-Instance GPU，空间切分，强隔离）

在 A100 等支持 MIG 的 GPU 上，可将一个物理 GPU 切分为多个彼此隔离的实例，每个实例拥有专属的计算与内存资源，并在系统视角表现为独立 GPU 设备。官方文档强调其“专用 compute 与 memory”，最多可切分为多个实例以供不同应用同时使用。(见 NVIDIA MIG User Guide)
代价在于资源单位离散、重配置有运维成本，并且平台调度与设备形态耦合更紧。

MPS（Multi-Process Service，协作式共享，降低上下文成本）

NVIDIA MPS 允许多个进程共享 CUDA 上下文与调度资源，从而提升并发与利用率，并减少上下文切换成本。(见 NVIDIA Multi-Process Service)
但 MPS 并非强隔离方案，更像“协作并发加速器”，对多租户 QoS、强隔离与严格配额的支撑有限。

本书后续将以这两条路径为“数据平面谱系”的关键锚点，进一步探讨更细粒度、更平台化的共享方式（如 HAMi 方向）。下表总结了三种典型方案的权衡关系，帮助你理解为什么没有“完美方案”，只有适合特定场景的选择：

图 4: GPU 共享方案的权衡关系

Kubernetes 语义层面的限制：调度器看不到“GPU 的真实形态”

Kubernetes 的 device plugin 框架，旨在“将设备作为资源广告出来，并让 kubelet 能分配设备给容器”。这是扩展硬件资源的标准机制，但其资源表达天然偏向“可分配的离散资源”。

这带来如下直接后果：

资源单位倾向于整数：最典型如 nvidia.com/gpu: 1；即便引入 MIG，通常也表现为不同 profile 的离散资源（如 nvidia.com/mig-*）。
调度阶段缺少连续约束：调度器难以基于“显存剩余”“带宽压力”“推理 KV cache 形态”等连续变量做全局决策。
QoS 难以端到端闭环：即使多个 Pod 被调度到同一张卡，平台仍缺乏标准化机制来保证它们的性能边界与相互影响上限。

因此，真正的平台化 GPU 管理通常需要将能力拆解为两部分：

控制面（Control Plane）：决定谁能用、何时用、用多少，包括排队、配额、优先级、公平性、准入等。
数据平面（Data Plane）：负责如何切分、隔离、计量与兑现，包括虚拟化/切分、隔离、资源分配与观测。

这正是本书结构设计的出发点。下图展示了平台化 GPU 管理的整体架构，其中控制面与数据平面通过闭环反馈协同工作：

图 5: 平台 GPU 管理的控制面与数据平面架构

一组“事故模式”帮助你快速识别问题本质

在真实集群中，以下事故模式频繁出现（它们往往不是偶发 bug，而是机制边界被触发）：

平均值很好，P99 崩溃：共享引入争用，尾延迟放大，尤其在推理服务并发上升时。
显存看似够，但还是 OOM：KV cache 动态增长与碎片化导致“不可用的剩余”。
同配额不同性能：所谓“30% GPU”在不同 workload 组合下对应完全不同的真实吞吐。
调度成功≠可用：Pod 虽然调度成功，但实际吞吐低到不可接受，最终只能人工迁移或隔离。
运维重配置触发连锁反应：如 MIG profile 调整导致设备集合变化，需要平台具备更强的“资源形态变更”承受能力。

这些现象将贯穿你对 MIG、HAMi、Volcano、Kueue 以及 vLLM/PyTorch 行为的理解。

以下是这些常见事故模式的详细分类，每一种都代表了平台治理的某个薄弱环节：

图 6: GPU 集群中的常见事故模式

总结

GPU 资源治理的真正目标，不是“把 GPU 塞满”，而是实现可治理性：

让共享成为一种可声明、可审计、可验收的能力；
让隔离与利用率在可比较的决策轴上权衡；
让控制面与数据平面协同，形成端到端闭环（准入/配额 → 分配/隔离 → 观测/计量 → 验收/迭代）。

问题的出路先收敛为两条基本路线：下一章硬切分与软切分给出一阶解空间模型：隔离边界放在硬件里，还是放在软件里；随后数据平面与控制面两大部分将分别展开这两侧的具体机制与治理体系。

参考文献

硬切分与软切分：加速器共享的两条基本路线

Jimmy Song — Sat, 15 Aug 2026 00:00:00 +0000

所有加速器共享方案，最终都要回答同一个问题：隔离边界放在硬件里，还是放在软件里。这个选择决定了其余一切。

本章要解决什么

后续数据平面各章会逐个分析 MIG、HAMi、DRA、昇腾 vNPU 等具体技术。但在逐个陷入细节之前，值得先退一步，用一个一阶模型把所有这些技术归类。这个模型只有两条路线：

硬切分（hard slicing）：由硬件或驱动把物理设备划分成若干静态分区，每个分区拿到独占的硬件份额（计算单元、显存、缓存乃至专用引擎），边界由硬件强制执行。
软切分（soft slicing）：物理设备保持完整，由运行时软件（通常是预加载的拦截库或驱动层调度器）在每个容器面前呈现一个受限的设备视图，并对算力、显存的使用按配额强制执行。

两条路线不是厂商之争，而是同一物理约束下的两种取舍。NVIDIA 的 MIG 与昇腾的 vNPU 模板同属硬切分；HAMi 的 libvgpu、昇腾生态的 libvnpu 与 vCANN-RT 同属软切分。理解了这一点，跨厂商的技术评估就可以用同一把尺子。

硬切分：把边界写进硬件

硬切分的本质是静态分区表。以三个典型实现为例：

NVIDIA MIG：把一颗 GPU 按 profile 划分成最多 7 个实例，每个实例独占 SM、L2 缓存与显存带宽份额。
昇腾 vNPU 模板：驱动按模板（如 vir04_3c_ndvpp）把 AI Core、AI CPU、显存与 DVPP 编解码引擎一次性分区。
Google TPU 的拓扑切分：TPU v4 及之后世代按芯片数量以矩形拓扑切分（Pod 级拓扑感知），粒度是整颗 TPU 芯片。

硬切分的共同特征：

隔离强度高。分区边界由硬件或驱动强制，一个分区的负载很难侵占另一个分区的资源，故障域也更小。
资源单位离散。只能从预定义的模板或拓扑组合里选，不能申请“8192MB 加 37% 算力”这种任意组合。
重配置昂贵。调整分区布局是驱动级乃至集群级的破坏性操作，通常要求设备上没有业务负载。
对应用透明。容器拿到的就是一个“小号设备”，不需要任何配合。

软切分：把边界写进运行时

软切分的本质是软件强制配额。同样三个典型实现：

HAMi 的 libvgpu/libvnpu/libamvgpu：预加载进容器，拦截 CUDA/ACL/HIP 分配与查询调用，把显存与算力限制在申请值内。HAMi 2.10 新增 AMD MI300X（通过 libamvgpu.so）和 Biren 支持，并提供与 KAI Scheduler 的集成。
昇腾生态的拦截库：华为 vCANN-RT 的 libvruntime 与 HAMi 的 libvnpu，拦截 CANN/DCMI 调用，机制同构（时间片算力调度加显存配额）。HAMi 2.10 新增异构模式，允许模板 vNPU 与 HAMi-core 软切分节点共存在同一集群。
驱动层时间片：NVIDIA 与 AMD 的时间片共享，按时间轮转整个设备，粒度粗但无需拦截库。

软切分的共同特征：

隔离靠软件。拦截点在用户态 API 或驱动调度层，强度低于硬件分区，但远好于“不设防”的混部。
粒度连续。显存可以精确到 MB，算力可以按百分比，适配任意大小的负载。
重配置廉价。改配额就是改一个 Pod 申请，秒级生效。
依赖栈敏感。拦截库必须与驱动、runtime 版本配套（HAMi 在昇腾上 libvnpu 与驱动不匹配时 npu-smi 会直接卡死），且通常有平台限制（如仅 ARM）。

软切分技术的最新演进（HAMi 2.10）

软切分技术在 HAMi 2.10（2026 年 8 月）中迎来了重要突破，解决了传统软切分方案的几个关键限制：

Flexible MIG：支持动态 MIG 实例分配，无需排空或封锁节点即可更改 MIG 配置，通过 NVML 动态发现拓扑和预留实例。
异构调度策略组合：新的 mutex 策略保证独占设备访问，修复 NUMA 排序错误，支持可组合的调度策略链（如 mutex,binpack,numa）。
更广泛的设备支持：新增 AMD MI300X（通过 libamvgpu.so）和 Biren 加速器支持，扩展到十多种异构设备。
昇腾深度管理：支持同一集群内模板 vNPU 硬切分与 HAMi-core 软切分共存，新增 vNPU HAMi-core 监控。
调度器生态集成：通过 KAI Resource Isolator 实现 KAI Scheduler 与 HAMi-core 的集成，让调度决策与运行时隔离首次能可验证地对应。

两条路线的决策轴

把特征放回本书通用的决策轴，得到这张最小对比表（完整版含队列、配额等控制面维度，见数据平面谱系）：

决策轴	硬切分	软切分
隔离边界	硬件或驱动强制	运行时软件强制
资源粒度	离散（模板或拓扑组合）	连续（MB 与百分比级）
重配置成本	高，需空载操作	低，改申请即可
性能可预测性	高，受邻居干扰小	中，时间片策略下依赖邻居负载
故障域	分区级	设备级或进程级
版本耦合	随驱动发布	拦截库与驱动必须配套
典型代表	MIG、昇腾 vNPU 模板、TPU 拓扑切分	HAMi libvgpu/libvnpu、vCANN-RT、时间片

没有哪条轴上两条路线同时取胜，这就是为什么生产系统里两者长期并存：付费多租户流量倾向硬切分换隔离与可预测性，内部弹性与开发测试倾向软切分换利用率与灵活性。混合部署（同一集群不同节点池各走一条路线）是常见且合理的选择。

一个容易忽略的推论

隔离边界的摆放位置还决定了验收方法：硬切分的隔离可以直接从设备拓扑观察到（容器看到的就是分区设备），软切分的隔离则必须通过行为验证（容器内设备视图被改写到配额、越界分配被拒绝、监控指标与申请值一致）。读者评估任何共享方案时也应如此：不要相信宣传材料，去验证容器看到什么、越界时发生什么、指标说了什么。

总结

硬切分与软切分是加速器虚拟化的一阶模型：前者把隔离边界写进硬件或驱动，换来强隔离与可预测性，代价是离散粒度与昂贵的重配置；后者把边界写进运行时软件，换来连续粒度与灵活性，代价是软件级隔离与版本耦合。后续章节的所有具体技术，MIG、HAMi、昇腾 vNPU 的三条路径、乃至 DRA 之上的共享策略，都是这两条路线在不同厂商生态里的实例化。带着这个模型去读，跨厂商的对比就不再是一堆名词，而是同一组权衡的反复出现。