当 AI 进入产业化深水区，真正决定模型能否稳定、高效运行的，往往不只是模型本身，更是隐藏在底层的算力调度能力。尤其在一个数据中心同时部署多款国产 GPU 的情况下，如何让 Kubernetes 识别、调度并统一服务这些异构资源，已经成为基础设施团队绕不开的问题。
在 2026 GTLC 硅谷站上，博伦智汇 CTO杨光围绕国产 GPU 的异构调度实践，分享了团队从 Device Plugin、DRA 到模型分发与推理引擎适配的一系列探索。这不仅是一场技术路径的复盘，也呈现了开源标准与产业协作如何推动国产算力生态加速向前。
01 国产 GPU 的“战国时代”
在今天的国内算力市场上，GPU 领域呈现出百花齐放的局面。与硅谷相对集中的生态不同，国内 GPU 厂商数量众多，每一家都有自己的技术路线和产品定位。
我们经常可以看到，在一个大型数据中心里，往往同时存在两到三款不同厂商的 GPU 卡。这种异构环境，对上层调度平台提出了很高的要求。我们的平台正是构建在这些国产 GPU 之上，通过一层智能调度，为用户提供统一的 Token 服务。
而要将这些各不相同的 GPU 纳入同一个 Kubernetes 体系中管理，其挑战远超想象。
演讲 PPT：将不同模型与 GPU 纳入 Kubernetes 体系
02 从云计算到 AI 调度
在进入 AI 行业之前，我从事云计算和中间件领域。当被问到如何调度这些 GPU 时，我的第一反应是利用 Kubernetes——这是云原生领域最成熟的调度方案。
然而，三年前，用 Kubernetes 调度 AI 工作负载（workload）还是一件困难的事。当时社区推出的开源平台，大多为互联网流量场景设计，难以满足 AI 计算的独特需求。
03 Device Plugin 与 GPU 识别
在 Kubernetes 原生状态下，CPU 和内存是最基础的可调度资源。要让 Kubernetes 识别异构 GPU，需要为每款 GPU 开发专门的 Device Plugin，让调度平台能够识别不同的 GPU 型号。
通过 Device Plugin，可以像申请其他 Kubernetes 资源一样，指定需要哪款 GPU、需要几块卡，从而完成任务。这是早期一种比较传统的方法：由于这套机制并非专为 GPU 设计，GPU 需要主动适配 Kubernetes 的资源体系。
演讲 PPT：Device Plugin 与 Dynamic Resource Allocation（DRA）
04 国产 GPU 的追赶之路
从行业现状来看，跑在前面的依然是某头部厂商，其他厂商都在积极追赶。目前，整个 Kubernetes 生态首先围绕主流 GPU 构建，其他厂商则在后面不断跟进，为适配付出了大量努力。
与此同时，Kubernetes 社区正在推进下一代资源调度框架 DRA（Dynamic Resource Allocation）。目前国内不少厂商还没有完成跟进实现，生态适配仍有很长的路要走。
演讲 PPT：Kubernetes 原生的统一 DRA
05 Mediator 层：异构 GPU 的桥梁
为了解决异构 GPU 的兼容问题，我们引入了一个转发层，可以称之为 Mediator 或 Proxy。
这层设计非常巧妙：对下，GPU 的 Device Plugin 以为它是 kubelet；对上，它与真正的 Kubernetes 集群交互。通过这种方式，实现异构 GPU 的统一调度，让不同型号的 GPU 能够协同工作。
演讲 PPT：通过 API 集成实现推理服务调度
06 API Exposure 与智能调度
当真正要调度 GPU 时，最终目标是把模型的 API 暴露出来供外部使用，这是一个典型的推理场景。
传统 Kubernetes 通过 Ingress 和 Service 实现 API 暴露，但这远远不够，我们需要更智能的调度能力。
Endpoint Picker Extension（EPP）这种可扩展机制，可以让 Kubernetes 和推理引擎互相交互：Kubernetes 读取推理引擎的监控指标，推理引擎向 Kubernetes 上报状态信息。这样在调度时，就能选择最合适的算力节点。
演讲 PPT：现有 API 暴露方式的能力与边界
07 异构 GPU 的版本碎片化挑战
异构调度场景下还有一个棘手问题：每款 GPU 的成熟度不同，底层推理引擎的版本和实现也各不相同。
更麻烦的是，这套体系会“挑”推理引擎。比如 GPU A 使用 vLLM 0.8，GPU B 可能使用完全不同版本的推理引擎，这就使得基于 EPP 框架的智能调度大打折扣。
如果能通过标准化方法，统一不同推理引擎的监控指标与能力上报机制，让它们共享同一套度量与交互方式，才有可能更接近理想的异构调度。
08 模型分发：推理引擎与模型的关系
在 Kubernetes 上运行 AI 任务，实际上运行的是模型。但 GPU 不能直接运行模型，中间必须有一层推理引擎或运行组件。
常见的相关组件包括 vLLM、SDXL、Llama.cpp 等。引擎本身通常就有 5—10GB，而模型往往更大，可能达到 80GB、100GB 甚至更多。
这就带来了模型分发的问题：如何高效地将大模型分发到各个算力节点？目前业界正在探索通过 P2P 能力在各节点间分发大模型，这条路径已经展现出很大的潜力。
09 OCI 镜像：模型分发的标准化方案
越来越多的开源项目开始提供原生支持：从 Hugging Face 或魔搭平台下载模型后，自动完成分发。这代表了模型分发领域的一个重要趋势。
另一种经典做法，是将模型打包成 OCI 标准镜像，再通过 P2P 助力 Registry 进行分发。这样既可以复用现有的容器镜像生态，也便于版本管理和回滚，还能支持多平台统一分发。
目前已有开源项目在做这方面的原生支持，通过命令行工具，让用户可以直接从模型平台下载模型并自动分发。
10 模型与推理引擎的智能适配
Day 0 支持某款新模型，并不意味着能够运行所有模型。通常的做法，是针对特定模型的算子做特殊优化。GPU 厂商为某款模型快速定制的推理引擎往往不具备通用性，换一个模型就可能出现问题。
为了解决这个问题，我们需要一个“决策矩阵”：系统能根据模型与 GPU 的组合，自动选择对应的推理引擎。
具体可以通过 Kubernetes 的 Custom Resource 实现：当申请运行某个模型时，系统根据它将要运行的 GPU 型号，自动选择匹配的推理引擎。这种智能适配可以大幅降低用户的使用门槛。
结语：写在最后
回顾整个分享，这不过是 AI 调度领域的沧海一粟。但有一点值得深思：正是 Kubernetes 这样的开源平台，使各种 GPU 都有能力接入开源生态，让最新技术能够更快适配到各类国产 GPU 上。
开放的心态带来开放的技术，开放的技术才能实现广泛的协作。
在国产 GPU 适配的过程中，我们也深刻体会到：国产 GPU 与英伟达之间的差距，正在以肉眼可见的速度缩小。这不是一件容易的事，但方向一定正确。
未来，博伦智汇提供的技术及方案，将把不同厂商、性能档位的GPU进行算力梯级编排，基于 TOLD （Token Oriented Large-scale Distributed architecture）的核心思路，以Token为度量，把从入门级到高性能的梯级算力，优化成按需获取、人人可及的普惠Token。