GPU 基础认知：从硬件到 Kubernetes 的完整视角
GPU 不是“更快的 CPU”，而是吞吐型计算的工程范式转变。理解它，才能用好它。
本文旨在为“第一次被 GPU 项目拖进深水区”的工程师建立一个稳定、可复用的 GPU 心智模型。你需要理解的不是某个 API，而是 GPU 作为一种硬件与运行时栈，在资源形态、约束、可治理边界上的本质差异。后续关于异构生态、共享隔离、控制面/数据面、平台能力模型与选型决策轴，都会回到这里的基本事实。
在下文中，将从硬件到 Kubernetes，梳理 GPU 的工程全景，帮助你建立系统性认知。
一页总图：从硬件到 Kubernetes
下方流程图将 GPU 的物理层级与 Kubernetes 使用路径整合在一张图中。阅读后续章节时，你可以随时定位问题发生的层级：是硬件约束、驱动/运行时、容器栈，还是 Kubernetes 的资源模型边界。
GPU 是什么：工程视角的一句话定义
GPU 是为大规模数据并行计算设计的专用计算设备，通过牺牲控制流灵活性换取极高的吞吐密度。与 CPU 相比，GPU 更像“吞吐型计算平台”，而不是“通用计算资源”。
为了让后续讨论更直接，下表用最小必要对照建立直觉。
这是 CPU 与 GPU 的工程特性对比表：
| 维度 | CPU | GPU |
|---|---|---|
| 设计目标 | 低延迟、强控制流 | 高吞吐、弱控制流 |
| 并行模型 | 少量复杂核心（十级） | 大量简单核心（千级） |
| 主要瓶颈 | 指令路径 / Cache | 显存容量与带宽 |
| 调度主体 | OS（CFS 等） | 驱动 + Runtime（CUDA） |
| 虚拟化成熟度 | 极高 | 天然较弱，需要专门方案补齐 |
这组差异决定了一个后续反复出现的事实：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）更强调大模型训练与推理并发形态
你不需要记住每一代的细节，但要记住一条方法论：代际差异会直接影响资源形态（显存大小、互联拓扑、分区能力、观测接口），而资源形态会反过来决定治理与调度策略。
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 放到“有该资源的节点上”
这里需要明确一个关键边界：
这正是后续章节（尤其是“为什么 GPU 资源治理难”“控制面地图”“能力模型”“设备资源模型边界”）要深入展开的原因。
单节点 Kubernetes 与多节点 Kubernetes 的差异
为避免将“单机使用 GPU”和“Kubernetes 使用 GPU”混为一谈，下表给出最小对比：
| 场景 | 主要调度变量 | 复杂性来源 |
|---|---|---|
| 单节点 Kubernetes | 这张卡在不在这台节点上 | 资源分配、容器注入 |
| 多节点 Kubernetes | 节点间拓扑与网络条件，作业形态更复杂 | 分布式训练、推理集群、拓扑 |
因此，多节点场景下更容易出现“资源看似满足但性能不稳定”的现象，根因往往不是调度本身，而是拓扑与干扰问题在系统层被放大。
总结
本文以工程师视角梳理了 GPU 从硬件到 Kubernetes 的全链路知识脉络，强调了显存与算力的本质差异、NVIDIA 生态的工程现实、以及资源治理的关键边界。理解这些基础事实，是后续深入异构调度、共享隔离、平台能力模型等议题的前提。