让每一分 GPU，不只是被使用，而是真正创造价值。
我们一直在追求 GPU 利用率
过去几年，不管是 Kubernetes 的 GPU 调度、vGPU、MIG，还是 HAMi，大家其实都在做同一件事，就是把一个指标往上推：
GPU Utilization这很合理。GPU 太贵了，一张 H100 一小时的成本可以到几美元到十几美元不等，谁也受不了 GPU 在那儿空转。所以整个 AI Infra 社区过去几年的叙事基本就一句话：
提升 GPU 利用率。
我自己长期参与 HAMi 社区，写过的几篇文章，比如 《Kubernetes 正在成为 AI 时代的 GPU Control Plane》 和 《从 GPU 到 Token：AI 基础设施的八层可观测性体系》，其实也都在讲这件事，怎么把 GPU 切得更细、共享得更彻底、调度得更合理。
但最近读到 Arjun Kaarat 在 Towards Data Science 上发表的 When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI，我开始重新想一个问题：
GPU 利用率，真的是我们该优化的目标吗？
文章里有一句话，我第一次读到时停了几秒：
“GPUs can be busy without being productive.”
Arjun Kaarat
这句话点破了一层窗户纸。我们过去花那么多精力去推高的那个数字，可能从一开始就回答错了问题。
GPU Busy 不等于 Productive
Kaarat 在文章里讲了一个特别有代表性的故事。
凌晨 2 点，一个基础设施团队被报警，推理延迟突然飙升了 60%。大家打开监控大盘一看，GPU 利用率一切正常：
GPU: 79%
GPU: 82%
GPU: 84%看起来很健康。于是常规套路上来，触发自动扩容、加节点、加 GPU。云账单一路上涨，但延迟几乎没改善。
一个小时之后才发现根因：有三个节点悄悄进入了 RAID 重建状态，存储吞吐被严重拖慢，把附近的推理任务饿得半死。调度器一直把这几个节点当成“还够健康”，因为 GPU 和内存指标看起来都没问题，可底层磁盘性能已经塌了。
这个故事最打动我的地方在于，它不是一个罕见的边缘 case，而是一个正在变得普遍的故障模式。
很多团队看到监控上：
GPU: 82%
GPU: 84%
GPU: 79%觉得“我们集群很忙、很健康”。但与此同时：
Latency ↑
Queue ↑
Throughput ↓
Cost ↑真正的问题是，GPU 在等待。
它在等什么？
- 检索流水线（Retrieval）把 embedding 喂过来；
- SSD 把上下文从存储里读出来；
- CPU 把数据 pipeline 准备好；
- KV Cache 有足够空间承接新的请求；
- 存储 I/O 不被后台任务挤占。
GPU 这一头是满的，可喂它的那条数据通路是空的、堵的、或者正在塌的。从仪表盘上看 GPU 是 84%，实际产出可能连一半都不到。Kaarat 在原文里把这种状态描述得很精准：
A GPU that appears active may still spend meaningful time waiting for the system around it.
这就是“忙碌”和“产出”之间那道被忽视的鸿沟。
GPU 利用率的“幻觉”
前面那个 RAID 的故事还只是“点状故障”。Kaarat 文章里更精彩的部分，是讲了一种系统性现象：Fragmentation，资源碎片化。
考虑一个集群里有三个节点，在跑完一波混合的 GenAI 任务之后：
| 节点 | GPU 算力 | HBM | 存储带宽 | I/O CPU |
|---|---|---|---|---|
| A | 可用 | 几乎占满 | 可用 | 可用 |
| B | 可用 | 可用 | 已饱和 | 可用 |
| C | 有限 | 可用 | 可用 | 已饱和 |
这时候来了一个新的推理任务，需求很普通：要一点 GPU、一点显存、像样的存储带宽、像样的 I/O 能力。
从总量上看，整个集群还有大把资源。A 有 GPU 和带宽，B 有显存，C 有带宽和 CPU。可是没有任何一个节点，能单独把这个任务接下来。
这就是资源碎片化。我把它画出来大概是这样：
集群不是空的，它只是被切成了无法再被有效利用的“边角料”。Kaarat 用一句话概括了这种现象，我觉得是全文最值得记住的一句：
The cluster is not empty. It is fragmented into leftovers that are difficult to use productively.
换一种说法：
集群不缺资源，缺的是“形状对的资源”。
这个判断对 HAMi 这类做 GPU 资源控制面的项目来说，其实非常关键。我们以前总以为“把卡切细、让多人共享”就是解决碎片化，但 Kaarat 指出了一个更深的问题：碎片化不只是 GPU 层面的事，它横跨 GPU、HBM、存储带宽、I/O CPU 多个维度。你把 GPU 切得再细，如果存储维度被堵死了，这个节点对下一个真正有用的任务来说，依然是不可用的。
HAMi 解决了什么
聊到这里，我想正面回答一个问题：HAMi 在这条链路里到底扮演什么角色？
HAMi 解决的是一个非常具体、也非常基础的问题：
GPU 能不能被更多人使用。
它做的事可以归纳成一句话：减少 GPU 层面的碎片化。具体形态包括：
- GPU Sharing：让多个 Pod 共享同一张卡，而不是一卡一 Pod；
- vGPU / HAMi-core：在用户态做显存隔离和算力限流，把一张卡切成 MB 级的虚拟设备；
- MIG 整合：用软件方式管理 NVIDIA MIG 硬件分区；
- 异构 GPU 统一抽象：把 NVIDIA、昇腾、寒武纪、海光、瀚博等十余种设备，抽象成调度器能统一消费的语义；
- DRA 兼容：跟上 Kubernetes 资源模型演进的脚步。
这是第一层效率。它回答的是“GPU 能不能用起来”的问题。
在这一层上，HAMi 的价值已经很清晰了：在国产与海外 GPU 混部、训练与推理混部、多租户共用的真实环境里，HAMi 让一张卡可以服务更多 workload，让集群不再因为“一卡一 Pod”这种粗粒度模型而被白白浪费。
但要注意，这只是效率故事的第一章。
HAMi 之后，我们还缺什么
如果我把视角拉高一点，会发现“提升 GPU 利用率”这件事，实际上是被分在三个不同层次里解决的。
第一层：GPU 能不能被切分、共享、分配？
这是 HAMi 这类项目在解决的问题，对应 GPU 资源控制面。
第二层：谁来使用 GPU？谁先跑、谁排队、谁优先？
这是 Volcano、Kueue、KAI Scheduler 这批调度器在解决的问题，对应作业排队、公平共享、优先级、gang scheduling。
第三层：GPU 真的能跑起来吗？数据通路、存储 I/O、KV Cache 这些东西跟得上吗？
这就是 Kaarat 那篇文章在敲响警钟的地方。当一个节点 RAID 在重建、SSD 队列爆炸、I/O CPU 被后台任务吃光的时候，你分给它再多 GPU、调度器把任务排得再优雅，它也产不出有效算力。
把这三层画在一起，就是下一代 AI 基础设施真正应该长成的样子：
这张图我觉得是理解整件事最关键的一张图。
过去几年，行业几乎所有的注意力都压在最下面两层：Kubernetes + HAMi。这两层把“GPU 能不能被用起来”的问题基本解决了。Volcano、Kueue、KAI 在第二层也很成熟，解决了排队和优先级的问题。
但第三层，Storage / I/O-aware Scheduling，目前几乎是个空白。 而这恰恰是 Kaarat 文章里反复强调的、现代 GenAI 系统里越来越值钱的那一层。因为 RAG、长上下文、多模态这些工作负载，瓶颈早就从“GPU 够不够”转移到了“喂 GPU 的那条数据通路通不通”。
说白了，HAMi 把 GPU 切细了，Volcano 把队列排好了，但如果一个被分到任务的节点根本喂不饱 GPU，那前面所有努力都是在给一个空转的末端供血。
下一代 AI 基础设施该优化什么
基于上面的分层，我想表达一个明确的观点：我们应该把优化目标从“GPU 利用率”升级到“Productive GPU-Hours”。
这不是文字游戏，而是一个能直接换算成钱的转变。
Kaarat 在文章里算过一笔账。一个 1000 张 H100 的集群，按 3 美元每卡每小时混合成本算，一年大约是 2600 万美元。如果碎片化和 I/O stall 偷偷浪费掉其中 10% 的有效 GPU 时间，那就是每年约 260 万美元的无效开销。不是因为 GPU 不见了，而是因为系统没能高效地使用它们。
这笔账可以翻译成一个简单的对照。
过去的目标：
Maximize GPU Utilization今天的目标：
Maximize Productive GPU-Hours未来的目标：
Maximize Productive Compute
Across Heterogeneous AI Clusters这个演进路径，正好对应前面那张分层图里讲的三层结构。最后那个“Across Heterogeneous AI Clusters”，正是 HAMi 一直在推进的异构叙事，未来你不会只优化一种 GPU，你要在 NVIDIA、昇腾、寒武纪、海光这些完全不同的卡之间，统一地最大化有效算力。
换句话说，HAMi 的长期价值，不应该被框死在“提升 GPU 利用率”这个旧叙事里。它的真正方向是：为异构 AI 集群提供一个能让 Productive GPU-Hours 最大化的资源控制面。
从 Utilization 到 Productive GPU-Hours
如果让我用一句话总结这次思考，我会这么说：
HAMi 解决的是“如何让更多 GPU 被使用”，而下一代 AI 基础设施要解决的，是“如何让每一分 GPU 真正创造价值”。
这正是 Kaarat 那篇文章留给我的最深的一句话：
The real question is no longer “Are the GPUs busy?”
It is: “Are they productively busy?”
这也让我开始重新看待 HAMi 社区下一阶段的口号。过去我们说“让 GPU 被更多人共享”，接下来或许应该往这个方向走：
Turn GPU utilization into productive GPU-hours.
让每一分 GPU，不只是被使用，而是真正创造价值。
GPU 利用率从来不是终点，它只是效率故事的第一章。当我们开始谈论 Productive GPU-Hours，开始关心存储、I/O、数据通路和异构集群的整体产出，AI 基础设施才真正进入它的第二章。
致谢与参考
本文部分观点受 Arjun Kaarat 在 Towards Data Science 发表的 When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI 一文启发，并引用其公开发表的论文与文章观点，特此致谢。文中两幅示意图（资源碎片化、效率分层架构）均为作者基于原文观点重新绘制，非原图搬运。
- Arjun Kaarat. When GPU Utilization Lies: The Hidden Systems Problem Slowing Modern AI. Towards Data Science, 2026.
- Kaarat, A., Batthula, V. J. R., & Segall, R. Fitting the Void: Residual-Aware Geometric Packing for GenAI Workloads. IEEE, 2025.
相关阅读：
