为什么 GPU 成了 AI 时代的基石？给 K8s 老兵的 GPU 科普

写在前面：一个云原生老兵，为什么来写 GPU

过去十年，我的主战场一直是容器和 Kubernetes。从服务网格到整个云原生生态，我几乎每天都在和调度、网络、存储、可观测这些事打交道，但专注点始终落在 CPU 侧的云原生上。去年我正式切到了 AI 基础设施（AI Infra）。

一头扎进去才发现，这个领域的概念密度高得离谱。Token、Transformer、Tensor Core、HBM、KV Cache 一个接一个砸过来，而绝大多数文档和文章都默认你已经懂，对没训过模型、没推过理的工程师很不友好。

不过我很快摸到一个窍门：别从头硬学，先用你已经烂熟的东西当翻译器。

Kubernetes 老兵脑子里的那套心智模型，调度、Job、Deployment、controller、缓存、利用率、多租户，再到微服务、服务网格、分布式系统、事件驱动、高可用架构，几乎每一样都能在 AI Infra 里找到对应物。一旦把这层映射建立起来，那些看着高深的概念就会变成“哦，原来就是某某的 GPU 版”。这套“用云原生视角翻译 AI”的方法，帮我自己快速上了手，也希望你帮我身边背景相似的朋友少走弯路，所以我决定把它整理出来。

这篇是这套翻译法的第一篇，先解决最底层那个问题：AI 为什么非 GPU 不可？ 后面我还会接着写 GPU 资源管理、调度、可观测这些 K8s 老兵更熟悉的话题。如果你也是从云原生切过来的，希望这篇能帮你省下几天翻资料的功夫。

你在屏幕前打出一句话，AI 一字一字吐出回答。对用过 K8s 的你来说，最自然的理解是：AI 就是跑在 GPU 上的一种“工作负载”，而 GPU 是一种专门给它用的“节点”。

先把黑话翻译成 K8s

AI 圈有一堆术语，对没做过训练推理的人像天书。先给你一张对照表，后面每个词我都会用你能懂的话再讲一遍。

记住这张表，下面正式开讲。

一个大多数人懒得问的问题

GPU 在 AI 里已经无处不在，以至于大家默认它就该如此。我们关心租哪张卡、用什么框架、部署哪个模型，却很少有人停下来问那个更根本的问题：

为什么是 GPU？

为什么不是更通用的 CPU？为什么一个本来用来渲染游戏画面的芯片，成了这一代最重要技术变革的地基？

答案不只是“它算得快”，而在于计算本身是怎么组织的，以及 AI 这个负载，为什么需要一种和过去五十年软件都不同的架构。

两种计算哲学：工匠与工厂

我们对 CPU 已经很熟悉了。K8s 的控制面、etcd、scheduler 都跑在 CPU 上，它擅长把复杂指令一条接一条地快速执行，核不多（8 到 128 个）但每个都很精。CPU 优化的是延迟：我多快能干完一件复杂的事。 像一个手艺精湛的工匠，一次精雕细琢一件活儿。

GPU 走的是相反的路：在海量数据上同时执行简单指令。一张现代数据中心 GPU 有几千个小核，它优化的是吞吐：我同一时刻能干完多少件简单的事。 像一条几千人的流水线，每个人同时干一模一样的一道工序。

单看任何一件复杂活儿，工匠（CPU）更快；但只要这活儿是整齐划一、可以并行的，工厂（GPU）每秒的总产出碾压工匠。过去几十年 CPU 统治一切，因为大多数软件（Web 服务、数据库、操作系统）本质上是串行的。然后深度学习来了。

AI 为什么打爆了 CPU

神经网络的核心，本质上是一大堆矩阵乘法（一种数学运算，把两组数字按规则批量相乘相加）。当模型处理一个 token 时，它要做几千、几万个这样的乘法，而这些乘法彼此不用等。

关键洞察一句话：这些运算天然可以并行。

一个 128 核的 CPU 看这种负载，只能一拨一拨顺序扫；一个几千核的 GPU 会把矩阵切块，分给各个小核同时算。同样的活儿，GPU 快出几个数量级，不是因为单个 GPU 核更快（其实更慢），而是问题本身是并行的，而 GPU 天生为这种形状的计算而造。

这就是 AI 跑在 GPU 上的真正原因，不是营销、不是历史包袱，是架构上的契合。

GPU 内部三件套，用 K8s 的话讲

1. Tensor Core：只会批量乘法的 sidecar

GPU 里有两类核。普通 CUDA 核像通用 worker，什么都能算；Tensor Core 是专用单元，它只会干一件事：把两小块矩阵一次乘完。但这一件事它快到离谱，一个周期算完普通核要算几千次的结果。

AI 的核心运算就是矩阵乘法，所以 Tensor Core 等于给 AI 量身定做。用 K8s 的话：普通 CUDA 核像 Deployment 里啥都干的通用 pod，Tensor Core 像一个只做“批量乘法”的高度专用 sidecar，单功能但吞吐碾压。

2. HBM：节点的高速本地内存

算得快还得拿得到数据。GPU 的内存和 CPU 节点一样是分层的，你理解 K8s 节点的 L1/L2 缓存、内存、本地盘，就理解 GPU 的：

最底下那层 HBM（高带宽内存）就是 GPU 的“主内存”，模型权重、中间结果和 KV Cache 都存放在这里。它的特点是容量大（单卡通常可达数百 GB）、带宽极高。

为什么要专门造 HBM？因为传统显存（GDDR）平铺在电路板上，连线铺不开，带宽撞墙。HBM 的解法是把内存芯片垂直堆叠（用硅通孔 TSV 连通），整摞紧贴 GPU 核心，接口宽到上千根线并行。打个比方：普通内存像把仓库平铺在停车场，搬运工跑不过来；HBM 像把仓库盖成几十层的高楼紧挨着车间，电梯（TSV）上下飞快。

这里有个反直觉的事实：现代 AI 更多被内存卡住，不是被算力卡住。 Tensor Core 算矩阵乘法的速度，比 HBM 喂数据的速度还快，GPU 经常在等数据。所以每一代新 GPU（H200 → Blackwell → Vera Rubin）最关键的升级不是算力，而是 HBM 带宽（4.8 → 8 → 22 TB/s，数据来源）。

既然搬运是瓶颈，NVIDIA 的另一手就是让数据绕开 CPU 直达 GPU，这三条“高速路”统称 GPUDirect：

• GPUDirect Storage：数据从 NVMe 硬盘直达 GPU 显存，不用先绕进主机内存、过一遍 CPU。
• GPUDirect RDMA：GPU 显存和网卡（InfiniBand）直接通信，跨机交换梯度不再 CPU 中转。
• NVLink：同一台机器里 GPU 之间直连，共享显存。

一句话：CPU 不再是每次数据搬运的交通管制员。用 K8s 的话理解，这就像让数据走“直连数据面”，而不是每个包都过一遍 apiserver。NVIDIA 的优势不只是算得快，而是把存储到 GPU、GPU 到 GPU、GPU 到网络整条数据高速公路都修直了。

3. Transformer + Token：逐字吐回答的程序

Transformer 不是硬件，是一种模型架构（程序结构）。GPT、Claude、LLaMA 这些大模型，底层都是它。它干的事其实很朴素：

读一段文本，预测下一个 token 是什么。

token 是文本被切成的小单元（一个字、半个词）。Transformer 把输入的 token 序列喂进去，吐出一个“最可能的下一个 token”，把它接上去，再把新序列喂回去，预测下下一个……如此循环，一个字一个字地生成整段回答。

用 K8s 的话：Transformer 是一种 controller，它的 reconcile 逻辑就是“看当前状态（已有的 token），输出下一个动作（下一个 token）”，然后不断循环。AI 助手那“一字一字蹦”的效果，就是这么来的。

训练 vs 推理：写菜谱 vs 上菜

这是入门最容易混、却最关键的一组概念。训练和推理是两码事，硬件需求完全不同。

• 训练（Training）：喂海量数据，反复调整那几十亿个参数，把模型“教”出来。它要跑几周到几个月，是离线批处理，关心吞吐，不关心单次延迟。用 K8s 的话，这像一个跑很久的 Job，目标是 build 出一个模型镜像。
• 推理（Inference）：模型训好后上线，接用户的每一句话，算出回答吐回去。用户在等，关心延迟；要同时服务上千用户，关心并发。这像一个接流量的 Deployment。

这一点直接影响你该关心哪些 GPU 指标。大众话题里霸榜的（Tensor Core 算力、NVLink 带宽、集群规模）主要是训练指标；而真正决定你用 AI 助手爽不爽的（HBM 容量、内存带宽、KV cache 管理）是推理指标，反而少有人谈。可推理才是大多数生产 AI 真正跑的地方。

多 GPU 协作：AI 集群就是一个分布式系统

讲完单卡，回到现实：最大的模型一张卡塞不下，训练动辄要几百、几千张卡一起算。这时候 GPU 集群本质上就是一个分布式系统，而你熟悉的云原生那套几乎全用得上。

多张 GPU = 微服务集群。 一张卡像一个服务实例，大模型被切开放在不同卡上，每张卡算一部分再把结果拼起来。这不就是微服务按职责拆分、分片承担负载的套路。

卡间通信 = 服务网格的数据面。 卡和卡之间要不停交换数据（尤其训练时同步梯度）。机柜内靠 NVLink（几 TB/s），跨机柜靠 InfiniBand。这就像微服务之间的东西向流量：同一节点内 pod 直连最快（NVLink），跨节点跨集群走网络（IB）。NVIDIA 把 GPU、交换机、DPU、RDMA 打包成整机柜（Vera Rubin NVL72），就等于服务网格把数据面、控制面、可观测打通成一整套。

分布式训练的 all-reduce = 分布式一致性。 训练每走一步，要把所有卡算出的梯度同步、求平均，这步叫 all-reduce。搞过 etcd、Raft 的人秒懂，这就是分布式系统里的共识与一致性，只不过这里同步的是梯度，不是状态机日志。

连续批处理 = 事件驱动。 推理时新请求随到随被塞进正在跑的批次，不用等整批跑完。请求像事件，批处理器像消费者，攒一批处理一批，这就是事件驱动、消息队列那套思路，目的是让 GPU 永远有活干、不空转。

分离式推理 = 微服务化。 把 prefill（吃输入，算力密集）和 decode（吐回答，内存密集）拆到不同 GPU 池，各自独立扩缩，KV cache 在它们之间靠 NVLink/RDMA 传递。这完全是微服务按职责拆分、独立扩缩容的玩法，KV cache 就像在服务间传递的会话上下文。

看出来了吧，AI 集群不是什么全新物种，它是把你烂熟的那套分布式系统、微服务、服务网格，搬到 GPU 这套硬件上重演一遍。你过去在 Istio、Envoy 上调流量、在 etcd 上调一致性攒下的经验，在这里照样值钱。

K8s 跑 GPU：训练用 Slurm，推理用 K8s

讲到这，作为 K8s 老兵你一定想问：那 GPU 集群到底用什么调度？答案有意思：训练和推理，常常是两套调度系统。

训练这一侧，HPC 世界的老大哥是 Slurm。 它管着全球 65% 的 TOP500 超算（NVIDIA），大型 AI 训练团队多年来积累了大量 Slurm 脚本、公平份额策略和计费流程。训练是长跑批任务，要的是拓扑感知（把通信频繁的 GPU 摆近点）、长时间独占、高吞吐，Slurm 在这上面打磨了十几年。

推理这一侧，主场是 Kubernetes。 推理是在线服务，要快速扩缩、按请求调度、和服务网格/可观测打通，这些正是 K8s 的强项。

问题来了：很多团队两套都要，难道维护两套环境？NVIDIA 开源了 Slinky 项目来解决这个，做法非常 K8s 原生：

• slurm-operator：把 Slurm 的各个守护进程（slurmctld 调度、slurmd 计算、slurmdbd 计费）做成 K8s 的 CRD 和 Pod，控制面靠 Pod 重生做高可用，不需要 Slurm 原生 HA 那套。配置变更通过 ConfigMap/Secret 自动同步，worker 用 HPA 弹性扩缩，缩容前先 drain 跑完任务，升级靠 PodDisruptionBudget 保护在跑任务。
• GPU Operator + DCGM Exporter：自动装驱动、设备插件，还能按 Slurm 作业 ID 打标，给你每个作业级别的 GPU 指标（Prometheus 抓）。
• ComputeDomains + DRA：像 GB200 NVL72 这种跨节点 NVLink 的机器，K8s 用 DRA（Dynamic Resource Allocation）动态管理跨节点 GPU 互联域，让分布式训练跨节点也能跑满 NVLink 带宽。

NVIDIA 自己已经在生产环境用 Slinky 跑到 8000+ GPU，NCCL 的 all-reduce/all-gather 性能和裸 Slurm 一致，K8s 这层几乎不损耗（NVIDIA 生产实践）。K8s 正在成为 GPU 计算的底座，Slurm 是跑在上面的调度层。

训练和推理对 GPU 调度的需求根本不同，不能用同一套思路管。这也是为什么 GPU 资源管理（后面会讲）要分场景，而 HAMi 这类方案要在 Slurm + K8s 混合环境里当统一的 GPU 资源管理层。

推理的真正大坑：KV Cache

如果只记一个把“GPU 理论”和“AI 推理现实”分开的概念，那就是 KV Cache。

Transformer 在生成每个 token 时，要参考前面所有 token 的关系（这叫“注意力”）。为了不每次都从头算，它把每个 token 的注意力状态存下来，这就是 KV Cache。

问题在于它会越长越大：

• 用户发来一万 token 的对话，模型给每个 token 存一条状态；
• 每生成下一个 token，它要把整份 KV Cache 读一遍；
• 一个 70B 模型在 32K 上下文下，单次请求的 KV Cache 就能到 8 到 16 GB，比模型本身还大；
• 50 个并发用户一上来，KV Cache 吃掉几百 GB 显存。

用 K8s 的话类比：KV Cache 像 Pod 本地的一本会话记事本。对话越长本子越厚，而且每说一个新字，都得把整本从头翻一遍。所以推理的显存，经常不是被模型吃掉的，而是被这本“本子”吃掉的。

这也是为什么会有 paged attention（把这本本子像虚拟内存页一样管，减少碎片，vLLM 把它带火）、NVIDIA Dynamo 的多级缓存（热页留 HBM，温的卸到 CPU 内存，冷的落到 NVMe）。推理工程师有一半精力在管这本本子。

GPU 利用率会撒谎

搞 K8s 的最懂“利用率骗人”：一个 pod 报 Running，不代表它在干活，可能只在 CPU steal 或等 IO。GPU 更严重。

监控里那个“GPU 利用率 %”通常只衡量“GPU 是否在执行某个核”，不衡量执行得多高效。一张卡可以报 90% 利用率，但 Tensor Core 真正忙的时间只有 30%，剩下都在等内存、做核启动开销、或干等数据。

更真实的指标叫 SM Efficiency（SM 活跃率）：它看的是每个时钟周期里，到底有多少 SM 在干有用的活。一张 nvidia-smi 显示 100% 利用率的卡，SM Efficiency 可能只有 20% 到 30%。很多企业以为自己“GPU 跑满了”，其实大量算力在空转。所以判断 GPU 是不是真在干活，别看利用率，看 SM Efficiency。

真正该看的指标（对应 K8s 里你看的 QPS、P99 延迟、资源水位）：

• Token 吞吐：每卡每秒生成多少 token，对应能服务多少用户（像 QPS）。
• TTFT（首 token 延迟）：从收到请求到吐出第一个 token 的时间，决定“响应感”（像冷启动时间）。
• TPOT（Time Per Output Token，每 token 输出时间，也叫 ITL / token 间延迟）：生成每个 token 平均要多久，决定流式流畅度（像 P99）。vLLM、TGI 这类推理框架普遍用 TPOT，NVIDIA 这边更常叫 ITL，指的是同一回事。
• 内存占用拆解：权重、KV cache、临时激活各占多少，告诉你是不是被内存卡住（像看 pod 的内存水位细分）。

为什么 NVIDIA 这么难撼动

聊 GPU 绕不开 NVIDIA 的统治地位。硬件确实强，但光硬件解释不了为什么 AMD、Intel、一堆创业公司的替代品始终难成气候。答案是生态深度。

CUDA 不只是并行计算平台，它是编程模型、编译器、运行时加一堆库，打磨了 18 年。几乎每个 AI 框架（PyTorch、TensorFlow、JAX）都先在 CUDA 上长出来，再移植到别处。用 K8s 的话：CUDA 之于 GPU，有点像 Linux 内核 + containerd + 一整套 CNCF 工具链之于容器生态，不是换一个内核就能替代的。

换一张别的卡，意味着重新验证推理栈的每一层（核、库、框架、serving、监控、运维）。切换成本不是买不同的硬件，而是重建一整套软件生态。这就是“CUDA 护城河”。

未来：AI 工厂

NVIDIA 现在不再用“GPU”甚至“数据中心”来描述生意，而是说“AI 工厂”：把电力、芯片、数据持续转化成智能的设施。这背后是真实的架构演进：

• 电力成了首要约束：单个 Vera Rubin 机柜功耗超 100 kW（数据来源），一个中型训练集群要 10 到 50 MW，相当于一个小镇。GPU 不再是最难搞的，搞到稳定供电才是。
• 散热离开风冷：液冷成了高密度 GPU 的标配。
• 网络决定 GPU 摆放：AI 集群设计现在是先定网络拓扑，再倒推 GPU 放哪，和传统数据中心正好反过来。
• 内存带宽仍是扩展前沿：每代加算力，但真正影响体验的是 HBM 带宽。
• 本质是高可用 + 机房运维：供电冗余、散热容灾、网络拓扑决定延迟、单点故障容灾，全是搞过分布式系统高可用的人熟悉的老问题。AI 工厂不是新魔法，是把你做高可用架构的那套功夫，搬到了一个功率和密度都高一个数量级的机房里。

别急着淘汰 CPU：Agentic AI 正在重塑 CPU:GPU 比例

讲了这么多 GPU 的好，你可能以为 CPU 在 AI 时代要靠边站了。恰恰相反，Agentic AI（智能体）正在把 CPU 请回 C 位。

传统的 LLM 推理，CPU 基本只负责给 GPU 压缩、搬运数据，所以 AI 数据中心的 CPU:GPU 配比一度低到 1:4 甚至 1:8。但智能体不一样：它要自主规划任务、调用工具、在子 Agent 之间路由数据、判断任务有没有完成，这一整套编排（Orchestration）逻辑几乎全压在 CPU 上。再加上智能体常靠强化学习训练，每个动作都要 CPU 评估，CPU 的负载更重。

有研究指出，智能体场景里 CPU 侧的工具处理（Python 解释、网页抓取、检索、数据库查询）能占到总延迟的九成。据 TrendForce 报道，Arm 估算，传统 AI 数据中心每 GW 大约需要 3000 万个 CPU 核，到了智能体时代会飙升到 1.2 亿核，4 倍；CPU:GPU 配比会从 1:41:8 往 **1:11:2** 走。这也是为什么 2026 年 NVIDIA 开始单独卖 Vera CPU、Arm 也亲自下场做 CPU。

对 K8s 老兵的信号很明确：未来的 AI 节点，是 CPU 和 GPU 一起算账的混合负载节点，调度和资源管理得同时管好这两类资源，而不是只盯着 GPU。

这和我（一个 K8s 老兵）有什么关系

讲了这么多硬件，落到我做的东西上：只有先理解 GPU 为什么是 AI 的基石，才能理解“GPU 资源管理”为什么是个真问题。

当一张卡动辄几十万元、整机柜上百千瓦，而生产里 GPU 却经常因为内存带宽、KV cache、批处理没调好而跑不满，“把卡分下去”就远远不够。怎么在一张卡上安全地跑多个租户（像 K8s 把多个 pod 调度到一个节点）、怎么在训练和推理两种截然不同的负载之间切分资源、怎么让利用率从“看起来满”变成“真的满”，这正是 GPU 虚拟化与共享（比如我做的工作）要解决的事。

这里有一组数据很扎心：据 ClearML 的 AI 基础设施调研，只有约 7% 的企业能在峰值时段把 GPU 利用率跑到 85% 以上，超过一半的企业卡在 51% 到 70%，还有 15% 低于 50%。也就是说，绝大多数企业花大价钱买的 GPU，有相当一部分算力在空转。这往往不是硬件不够，而是调度和管理没跟上。

我自己的判断是，GPU 资源管理正在经历三个阶段：Allocation（分配）→ Utilization（利用率）→ Efficiency（效率）。第一阶段只回答“这张卡分给谁”（device plugin、独占或时间片）；第二阶段追问“这张卡用满没”（动态批处理、弹性扩缩，多数企业卡在这）；第三阶段才问“这张卡的算力是不是在产生最大价值”（SM Efficiency、每瓦 token、带宽利用率）。真正的挑战在第三阶段，而未来的 GPU 调度器不该只是资源分配器，而要成为 GPU 内部资源的精细编排器，能看懂有多少 SM 在活跃、Tensor Core 利用率多少、KV cache 占了多少显存，再决定能不能再塞一个请求。

说白了，AI 时代正在重演一遍云原生的故事：从“单机独占”走向“多租户共享 + 调度 + 可观测”。而 GPU，就是这出新戏的主舞台。

这只是上半场：NVIDIA 之外，牌桌上还有谁

读到这你大概发现了，这篇基本只讲了 NVIDIA。没办法，它是当前绝对的主角，绕不开。但如果你以为 AI 加速器的世界只有 NVIDIA，那就大错特错了。

事实上，一场“反英伟达联盟”正在从四面八方集结：

• 云厂商自研：Google 的 TPU 已经迭代到第六代、支撑自家几乎全部 AI 业务；AWS 的 Trainium（训练）和 Inferentia（推理）越铺越广；Meta、微软也没闲着。
• 传统芯片巨头：AMD 用 Instinct 系列加 ROCm 死磕，Intel 拿 Gaudi 和 oneAPI 卡位。
• 中国异构算力生态：华为昇腾、海光 DCU、寒武纪、摩尔线程、燧原、昆仑芯、沐曦、壁仞……在国产替代的窗口里疯狂追赶，软件栈也一步步从“能用”往“好用”走。
• 开放生态的反扑：UXL 联盟、OpenAI Triton、PyTorch 原生的 AMD/TPU 后端，都在啃 CUDA 这条护城河的墙。

这对一个 K8s 老兵意味着什么？意味着未来的 AI 集群，几乎一定是异构的：机柜里可能同时躺着 NVIDIA、AMD、TPU 和国产卡，一张调度表要管好几种完全不同的硬件。

于是真正有意思的问题来了：

• 怎么在一套集群里混跑多种加速卡，还能统一调度、统一观测？
• K8s 的设备插件、DRA（动态资源分配）往哪演进，才能优雅地描述这些五花八门的硬件？
• CUDA 护城河会被开放生态攻破吗，还是说 NVIDIA 会像当年的 x86 一样长期统治？
• 国产异构算卡要真正进生产，还差哪几块拼图？

这些，我会在后面的文章里再讲。这篇只是把“为什么是 GPU”讲透，下一篇，我们聊聊“GPU 不止一种”之后，AI 基础设施该怎么调度这块大棋。

参考资料

• Ameen Alam, Why GPUs Became the Foundation of Modern AI（三部曲 Part 1）
• Ameen Alam, The Hidden Technology Behind Modern AI GPUs（Part 2）
• Ameen Alam, Real AI Infrastructure and the Future of GPUs（Part 3）
• TrendForce, The Great Rebalance: How Agentic AI Is Reshaping the CPU/GPU Ratio（CPU:GPU 比例再平衡）
• Anton Polyakov (NVIDIA), Running Large-Scale GPU Workloads on Kubernetes with Slurm（Slinky / Slurm on K8s）
• Kawonise, Why NVIDIA GPU Architecture Is Perfect for AI: GPU Data Path for a Single Node（GPUDirect 数据通路）
• Mirantis, GPU Infrastructure Automation and Strategy（GPU 基础设施自动化与利用率）