Token 背后的 GPU：Kubernetes 如何把算力用满

演讲备注： 本页约 45 秒。 大家好，我是宋净超，Jimmy Song，现在负责密瓜智能的开源生态。今天分享的题目叫《Token 背后的 GPU：Kubernetes 如何把算力用满》。 我先说明一下，这不是一场大模型算法课，也不是推理框架调优课。我们今天讲的是更靠近平台工程的问题：当大家都开始用大模型、用智能问答、用各种 Token 服务以后，背后的 GPU 资源怎么管理？GPU 很贵，但在真实环境里又经常出现“有人排队等卡，已经分出去的卡却没有真正用满”的情况。 今天，我想用最终用户能听懂的方式，讲清楚 Kubernetes 默认管理 GPU 为什么会比较粗，HAMi 想补上的能力是什么，以及顺丰、招商银行这些最终用户为什么会关心这件事。

演讲备注： 本页约 35 秒。 今天我会按三个问题展开。 第一个问题，Kubernetes 为什么管 CPU、内存很顺手，但一到 GPU 就有点别扭。第二个问题，站在最终用户和平台团队角度，GPU 共享会带来哪些真实问题，比如不够用、用不满、互相影响、缺乏可观测性。第三个问题，再回到 HAMi，它到底解决了什么。 大家不需要有很深的大模型背景。只要知道 Pod、request、limit、namespace 这些 Kubernetes 基本概念，就可以跟上。我的目标不是把每个实现细节讲完，而是让大家了解一个基本判断框架：什么时候需要把 GPU 管得更细，HAMi 在里面处于什么位置。

演讲备注： 本页约 45 秒。 我们先从一个简单问题开始：为什么大家都想把 GPU 放进 Kubernetes？ 原因不是 Kubernetes 天然懂 GPU。Kubernetes 一开始更擅长的是应用编排、服务发布、弹性伸缩、故障恢复这些事情。真正的原因是，团队已经习惯用 Kubernetes 交付应用了。今天一个业务团队做智能客服，明天一个研发团队做内部知识问答，后天一个平台团队跑批处理任务，大家都希望沿用同一套发布、监控、权限和审计流程。 从最终用户视角，其实不想关心机器在哪里、驱动是谁装的、节点是谁维护的。用户只希望提交一个应用，然后平台告诉他能不能跑、用了多少资源、有没有超预算。这就是把 GPU 纳入 Kubernetes 资源池的动力。

演讲备注： 本页约 50 秒。 在讲 GPU 之前，我们先看 CPU 和内存。Kubernetes 管 CPU、内存为什么相对顺手？因为它背后有 Linux 内核机制兜底。 比如我在 YAML 里写 500m CPU、1Gi 内存，这不只是写给调度器看的。调度器会用 request 做放置决策，运行时也可以通过 cgroup 等机制限制资源使用。CPU 可以按时间片调度，内存可以按容量限制，超了限制，系统有相对明确的处理方式。 所以对用户来说，CPU 和内存是可以细分的。我不需要一整台机器，我可以要半个 CPU、1Gi 内存。平台也能把很多小应用装进同一个资源池里，这是 Kubernetes 多租户能力成立的基础。

演讲备注： 本页约 50 秒。 GPU 一进来，模型就变了。Kubernetes 当然可以通过 NVIDIA Device Plugin 看到 GPU，也可以让 Pod 申请 `nvidia.com/gpu: 1`。但这个 1 通常表示一整块 GPU。 这就和 CPU、内存很不一样。用户可能只是需要 4GB 显存，或者只需要一部分算力，但 Kubernetes 默认并不知道这些细节。它看到的是“这个 Pod 要一块 GPU”，而不是“这个 Pod 要 4GB 显存、30% 左右算力”。 所以问题不在于 Kubernetes 不能运行 GPU Pod。它能跑。问题在于默认模型太粗：不知道我要多少显存，不知道我要多少算力，也不知道多个 Pod 在一张卡上应该怎么公平共享。

演讲备注： 本页约 45 秒。 这就是最常见的用户抱怨：卡不够，但又没用满。 比如一个 Pod 只是做开发测试，或者跑一个轻量推理服务，它实际只用了 2GB 显存。但因为资源声明是整卡，Kubernetes 可能给它分配了一整张 24GB GPU。结果是什么？这张卡被锁住了，其他 Pod 继续 Pending。 可以把它想象成会议室预订：一个人只需要会议室里一张桌子，但系统把整间会议室都锁给他了。门外的人看起来是在排队等资源，但房间里面其实空着很多位置。GPU 成本很高，这种浪费很快就会变成预算问题，也会变成平台团队被追问的问题。

演讲备注： 本页约 50 秒。 当只有一个团队用 GPU 时，这个问题可能还不明显。一旦变成多团队共享，问题会被放大。 第一是不公平。一个任务多占显存，或者长时间占着 GPU，其他任务的体验就会变差。第二是不透明。Kubernetes 看到的是分配了几块 GPU，但平台团队真正关心的是显存用了多少、利用率是多少、卡上有哪些进程、有没有异常占用。第三是不放心。很多人会说我们有 namespace、有 RBAC，但这些解决的是 API 层面的权限问题，不会自动变成 GPU 运行时的资源隔离。 所以共享 GPU 不是简单地把几个 Pod 放到同一张卡上，而是要回答：怎么分、怎么限、怎么看、出了问题怎么治理。

演讲备注： 本页约 60 秒。 在 HAMi 之前，社区和厂商已经有很多方案，各自解决了一部分问题。这里我不想把它们讲成谁替代谁，它们关注的层面不一样。 NVIDIA Device Plugin 解决的是“让 Kubernetes 能发现和分配 GPU”，这是基础能力。但默认还是整卡、整数资源。时间分片可以让一张 GPU 看起来像多张，但这个名字容易让人误解，它并不等于显存、算力和公平性都解决了。MIG 是硬件级切分，隔离很强，但只适用于部分 GPU，而且规格不一定灵活。还有一些调度器编排方案，可以把多个任务安排到同一张卡上，但很多时候只能解决“放在哪里”，不能真正限制运行时行为。 HAMi 试图补上的，就是细粒度资源表达、调度和运行时约束这一段。

演讲备注： 本页约 45 秒。 所以 HAMi 要解决的核心问题，可以浓缩成这一句话：让 Kubernetes 不只是“分配一块 GPU”，而是能表达和管理“一部分 GPU”。 这里有三个关键词。第一个是显存，我需要 2GB、4GB、8GB，而不是永远只能要一整张卡。第二个是算力，我希望不同任务按比例使用，而不是谁先跑起来谁就抢得更多。第三个是调度，平台要能把小任务装箱到合适的 GPU 上，减少碎片和浪费。 HAMi 的意义不是让 GPU 第一次能跑在 Kubernetes 上，而是让 GPU 更像 Kubernetes 世界里的资源：可以声明、可以调度、可以限制、可以观察。

演讲备注： 本页约 50 秒。 那 HAMi 是什么？简单说，它是一个面向 Kubernetes 的 GPU 和异构算力虚拟化与调度中间件，也是 CNCF Sandbox 开源项目。 这里要特别强调“中间件”三个字。HAMi 不是训练框架，不是推理框架，也不是一个替代 Kubernetes 的平台。它工作在 Kubernetes 和底层 GPU 运行时之间，帮助平台把 GPU 表达得更细。 对用户来说，最直接的变化是：过去只能写 `nvidia.com/gpu: 1`，现在可以进一步表达显存和算力，比如我要多少 `gpumem`，我要多少 `gpucores`。应用代码通常不需要因为这件事而重写，资源申请方式仍然走 Kubernetes 的声明式模型。

演讲备注： 本页约 50 秒。 这张 Before / After 图很适合给最终用户看。 左边是比较原生的方式：一个 Pod 申请 1 张 GPU，平台就把一整张卡给它。哪怕它只用了一点显存，其他 Pod 也很难再进去。右边是 HAMi 之后的方式：一张物理 GPU 可以按照显存和算力被多个 Pod 共享。 这里我建议大家不要把注意力放在具体实现细节上，而是先记住用户体验的变化。用户仍然通过 Kubernetes 资源声明来申请资源，但平台终于可以表达“我要一部分 GPU”。这对开发测试、轻量推理、内部知识问答这类负载特别有价值，因为它们经常不是持续打满整张卡。

演讲备注： 本页约 60 秒。 这张架构图信息比较多，我们不用逐个解释箭头。大家只抓三层能力就可以。 第一层是调度。Scheduler 要解决的是“放哪儿”：这个 Pod 需要多少显存、多少算力、适合放在哪个节点、哪张卡上。第二层是设备发现和资源暴露。Device Plugin 让 Kubernetes 能看到 GPU 或其他加速器，并把资源暴露给集群。第三层是运行时约束。HAMi Core 关注的是 Pod 真正跑起来之后，怎么尽量限制它使用的显存和计算资源。 所以 HAMi 不是训练框架，也不是业务框架，它做的是把调度、设备发现、运行时限制串起来，让平台不仅能把任务放上去，还能更细地控制它怎么用 GPU。

演讲备注： 本页约 45 秒。 HAMi 很容易被理解成一个 NVIDIA GPU 共享项目，但它更长期的方向是异构算力调度和虚拟化。 为什么这点重要？因为企业真实环境里不会永远只有一种 GPU。今天可能是 NVIDIA，明天可能还有昇腾、寒武纪、海光 DCU、沐曦、摩尔线程，云上还可能碰到 AWS Neuron。平台团队不希望每一种设备都单独建设一套管理入口。 同时，Kubernetes 生态里也不只有一个调度器或一个资源模型。Volcano、Kueue、Koordinator、DRA、CDI、GPU Operator 等组件都可能出现在企业环境里。HAMi 的价值之一，就是尽量把加速器资源纳入云原生生态，而不是做成孤岛。

演讲备注： 本页约 35 秒。 这一页主要想说明，HAMi 不是一个只停留在实验室里的项目，它已经有比较活跃的采用者和开发者生态。 图里的 logo 不需要逐个念，大家只要知道这是部分公开采用者。下面这几个数字也可以快速扫一下：社区贡献者、公开采用者、GitHub Stars、镜像下载量都在增长。 对一个基础设施项目来说，这些信号很重要。因为平台团队选型时不只看功能，还会看社区是否活跃、有没有真实用户、遇到问题时能不能找到经验。HAMi 的发展阶段，已经从“能不能做”进入到“怎么在更多企业里稳定落地”。

演讲备注： 本页约 40 秒。 这一页补充一个很现实的问题：平台能力不能只停留在 YAML 和调度日志里，最终还要被平台团队看见、解释和运营。 GPU 为什么难管？除了资源贵，还有一个原因是信息不透明。谁用了哪张卡、用了多少显存、有没有虚拟 GPU、哪些任务在共享、哪些节点比较空，这些都需要被看见。 WebUI 不是今天的重点，但它能帮助大家把 HAMi 从“底层插件”联想到日常资源管理。平台团队最后要面对的是配额、利用率、容量规划和问题排查。能调度只是第一步，能治理才是生产环境真正需要的能力。

演讲备注： 本页约 55 秒。 这页是最适合给最终用户看的。以前申请 GPU，基本就是 `nvidia.com/gpu: 1`，意思是我要一整张卡。现在使用 HAMi 之后，可以继续写 `nvidia.com/gpu: 1`，同时再声明 `gpumem` 和 `gpucores`。 这里的 `gpumem: 4096` 可以理解为我需要 4GB 显存，`gpucores: 30` 可以理解为我希望获得一部分算力。具体实现大家不用在这里展开，只要记住：资源表达从“整卡”变成了“更细粒度”。 这对最终用户非常重要。因为用户不一定关心底层插件怎么工作，他只关心能不能用熟悉的 Kubernetes 方式，申请到刚好够用的 GPU 资源，而不是每次都被迫占一整张卡。

演讲备注： 本页约 55 秒。 那这件事和 Token 有什么关系？ 大家今天听到 Token，可能会想到大模型计费、上下文长度、推理延迟。但从平台角度看，每一次问答、每一次客服机器人回复、每一次内部知识库检索增强，背后最终都要消耗算力，其中很多场景会用到 GPU。 问题是，很多 Token 服务并不需要独占一整张 GPU。客服机器人有明显峰谷，内部知识问答可能是多个部门共用，开发测试环境每个人只需要一点显存。如果这些服务都按整卡申请，GPU 很快就会看起来“不够”，但真实利用率又不高。 HAMi 关注的就是这些服务背后的 GPU 怎么分、怎么省、怎么管。它不解决模型算法问题，但它解决平台资源效率问题。

演讲备注： 本页约 55 秒。 接下来用两个国内最终用户案例来帮助大家理解。第一个是顺丰科技。 这里我想强调，顺丰不是在做一个演示环境，而是在真实业务里面对多云、多集群、多团队的 GPU 管理问题。他们有 5 个私有云 Kubernetes 集群，还对接 4 家公有云。这样的环境里，GPU 型号多，团队多，需求变化也很快。 右边这些数字可以看到，HAMi 帮助他们做到更高的显存超配能力，并且在生产测试集群里最高节省 57% GPU。我们不需要深入顺丰具体模型，只要理解平台问题：客服、问答、识别、沙盒、工作流这些 AI 相关服务背后都有波动，平台要能把 GPU 灵活供给出去。

演讲备注： 本页约 45 秒。 顺丰这个案例的启发是：很多任务不应该都按整卡锁资源。 开发测试环境可能只需要一点显存，轻量推理服务也不一定持续打满 GPU，批处理任务和在线服务还有峰谷差异。如果它们都用整卡方式申请，平台会很快变得紧张。 HAMi 在这里做的事情，就是把 GPU 的分配粒度降下来，让低负载任务可以按显存和算力比例申请，让不同类型任务有机会混部共享。再配合调度器的队列和优先级管理，平台就可以更接近真实使用情况来供给资源。 所以最终用户感受到的不是“多了一个插件”，而是 GPU 像水电一样，可以被平台按需分配。

演讲备注： 本页约 55 秒。 第二个案例是招商银行。这个案例和顺丰不太一样，它更能体现大型金融企业自己建设算力底座时遇到的约束。 金融场景里，GPU/NPU 型号可能更多，业务线差异也更大，对稳定性、安全隔离、运维可控性的要求会更高。这里有几个数字值得看：超节点双芯模组适配后 GPU 入池率达到 100%，vNPU-Core 软切分粒度可以做到 1G 显存和 1% 算力级别，三层拓扑感知调度降低跨机调度概率。 这些数字背后的重点不是模型有多复杂，而是平台能力更细了。异构设备要统一入池，超节点硬件要避免调度踩坑，中小任务不能动不动就占整卡。

演讲备注： 本页约 45 秒。 这页想说明，HAMi 不是只做“切卡”。 在招商银行这样的环境里，首先要解决的是设备能不能稳定入池。不同硬件模组、不同拓扑关系，如果调度器完全不知道，可能会把任务放到不合适的位置，带来性能问题甚至驱动异常。其次是软切分，中小任务可以按 1G 显存、1% 算力级别获得资源。最后是拓扑感知，尽量同节点、同 LEAF 调度，减少跨机通信和碎片化。 这对 Token 服务也有启发。很多 AI 服务并不是一个长期独占大卡的大训练任务，而是大量中小负载。它们最怕的就是整卡浪费和不合理调度。

演讲备注： 本页约 45 秒。 我们把两个案例放在一起看，不是为了展示客户名单，而是为了看共同问题。 顺丰面对的是多云、多集群、多团队共享 GPU，HAMi 帮它做 GPU 切分、混部、显存超分，提升资源效率。招商银行面对的是异构设备、超节点拓扑和金融级稳定性，HAMi 帮它做入池、软切分和拓扑感知调度。 行业不同，但底层诉求很相似：AI 应用越来越碎片化，Token 服务越来越多，企业不可能无限买卡。更现实的做法是，先把已有 GPU 管细、管稳、管起来。这也引出下一页：HAMi 适合什么，不适合什么。

演讲备注： 本页约 55 秒。 这里我想讲得坦诚一点。HAMi 很实用，但它不是魔法，也不是所有 GPU 隔离问题的唯一答案。 它特别适合可信团队之间共享 GPU，比如同一个企业内部的不同业务线、开发测试环境、轻量推理服务、批处理任务。也适合已有 GPU 型号不支持 MIG，但平台又希望做更细粒度管理的场景。 但如果你的场景是强对抗的恶意租户，或者所有业务都要求硬件级性能隔离，那就不能只依赖 HAMi。MIG、独立节点、严格的网络和权限隔离仍然重要。还有一种情况也不适合：完全不做监控和配额的盲共享。共享不是放任，HAMi 最好和配额、监控、告警、审计一起用，才能成为生产能力。

演讲备注： 本页约 45 秒。 最后顺带说一下从开源 HAMi 到商业版本的关系。 如果大家只是学习、验证、做 PoC，开源 HAMi 就可以开始。它提供核心的 GPU 虚拟化、调度、显存和算力控制能力。 但企业真正放到生产环境时，通常还会关心更多工程问题：能不能离线安装，升级有没有保障，SLA 怎么做，多厂商设备怎么适配，监控、审计、配额、计量计费、多集群管理怎么落地。这些就属于企业版和平台版更关注的范围。 所以密瓜智能提供商业版本，不是为了替代开源，而是为了让企业能把开源能力稳定地放进生产环境。

演讲备注： 本页约 50 秒。 最后我希望大家带走三句话。 第一，GPU 接入 Kubernetes 不难，难的是共享之后还能公平、可控、可观测。能跑一个 GPU Pod，只是起点。 第二，HAMi 的价值，是把 GPU 从“整卡”变成更细粒度的 Kubernetes 资源。它让平台能够表达显存、算力和调度约束，而不是只有一块卡、两块卡这种整数概念。 第三，对最终用户来说，关键不是每个人都懂模型，而是平台能更好地分配昂贵 GPU。Token 服务越多，AI 应用越碎片化，这个问题就越现实。 如果大家记住这三句话，今天这 20 分钟就达到了目的。

演讲备注： 本页约 25 秒。 今天的内容就先到这里。 如果大家后面想进一步了解 HAMi，可以看 `project-hami.io` 和 GitHub 上的 Project-HAMi/HAMi。如果大家关心企业里的 Kubernetes GPU 多租户、异构算力调度，或者想了解密瓜智能的 HAMi 企业版、平台版，也可以访问 `dynamia.ai`。 最后这里是我的微信，欢迎会后继续交流。谢谢大家。