KubeCon China 2026：从同一批硬件里找回来的算力

在上海举行的 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 围绕两条线索展开。第一条是负载的转移，开场主题演讲为它配上了分析机构的数字：AI 算力如今更多压在推理而不是训练上。而把推理跑起来，正在挤压 Kubernetes 赖以成立的那些抽象，这个抱怨贯穿了整个议程——Deployment 描述不了一个推理副本，TTFT 也不是请求速率。第二条线索是强制隔离，它位于第一条之下，而且基本不受其走向影响。HAMi 负责把 GPU 切分开，并把每个工作负载约束在自己的份额内；DRA 则让 Kubernetes 原生就能申请和核算这些切分出来的单位。工作负载是训练还是推理，都是一样的。两条线索交汇在花钱这件事上：需要更多算力的团队，靠的是改变分配的单位，而不是买硬件。

主题演讲定下的框架

主题演讲用数字说明了这一转移。按照台上引用的分析机构数据，推理占 AI 算力的 67%，训练占 33%，给出的原因是频次而非规模：训练是零星发生的，推理则在每一次提示时发生，而 Agent 类负载对推理的胃口很大。同一场主题演讲预测，到 2030 年推理的电力需求将达到 93.3 GW。它还把云原生的每个基本构件对应到 AI 时代的对应物上：用于隔离的容器加沙箱、微服务加 Agent、服务网格加 MCP 这类面向 Agent 的协议、声明式 API 加 model-as-a-service，以及不可变基础设施加具备 SLA 感知能力的基础设施。

PyTorch Foundation 的主题演讲提出，如今决定前沿位置的是团队迭代的速度。先训练一个模型、再把它交付出去的旧式线性流水线，已经被一个闭环取代：生产环境中的行为会反馈回权重里。作为佐证，vLLM 和 SGLang 对 Kimi K3、MiniMax M3 和 Qwen 3.8 都提供了 day-zero 支持。主题演讲举的例子是 Shopify，它在自家的电商 Agent 上每天跑这个闭环：生产环境里的失败成为训练数据，一个经过校准的评判器对轨迹做批评、修复和验证，PyTorch 用这些数据先做有监督微调再做强化学习完成再训练，更新后的权重由 vLLM 提供服务。在他们的 GraphQL 评测中，蒸馏后的模型在 46,000 到 61,000 条训练样本之间的某个位置超过了前沿参考基线。那个最醒目的数字——在每分钟最多 2,000 请求下约 96% 的服务成本下降——给出的是服务成本的建模对比，而不是包含训练在内的实测总成本。

HAMi 是这一底层正在成形的一个清楚例子。它让多个负载可以共享同一张 GPU 卡，每个负载都有自己的显存和算力配额。它作为一个开放的 GPU 资源层位于调度器之下而不是之旁，Volcano、Koordinator 和 Kueue 在它之上，KAI Scheduler 的集成则在它之下。现在，一个 DRA 驱动把同样的切分通过 Kubernetes 自己的 claim API 表达出来，它把原先的 device-plugin 请求翻译过去，而不是与之并排摆放；项目自己也明确说，这两种模式不应在同一个集群里同时运行。HAMi 在首日的五场议题里被提到，下文的生产案例中有三个真正在用它。

企业议题真正展示的内容

招商银行面对的是这个问题最朴素的形态：一个加速器资源池，一类要的是稳定容量的训练负载，一类要的是快速伸缩的推理负载，两者都在争同一批卡。他们没有增购加速器，而是把两类负载调度到同一个共享底座上。训练通过 Kueue 进入，由它负责准入和配额；推理跑 vLLM 或 SGLang，并用 KEDA 依据 Prometheus 指标伸缩。两者之下是带 HAMi 负责放置的 Kubernetes 调度器，以及负责数据集、检查点和缓存权重的 Fluid。关键在于那种潮汐式的行为：推理需求上来时 KEDA 扩容，训练任务自行保存检查点并交出卡，需求回落后再恢复。他们报告的结果是，加速器平均算力利用率从 35% 升至 60% 以上，每一百万输入加输出 token 的推理成本下降超过 60%，多租户训练密度提升五倍，从 Fluid 缓存的权重加载 Qwen3-14B 用时不到两秒，而生产环境的目标是 TTFT 不高于 5 秒、TPOT 不高于 50 毫秒。他们自己的总结是，价值来自跨层的协同，而不是某一个单独的组件。对于自己搭建而不是采购平台所要付出的代价，他们同样说得很清楚：持续的集成和兼容性测试。这项工作在会上的 CNCF End User Case Study Contest 中获奖。

做扫描全能王（CamScanner）的合合信息（INTSIG）在整个 GPU 资源池的规模上遇到了同样的问题：自建加多云、上万张卡的规模，并行承载着 1,000 多个在线推理服务和 1,000 多个离线训练任务，训练侧在 24 小时里保持 90% 以上的利用率。他们的约束不是放置，而是排队时间——真正卡住的是等卡的人。他们认可有效的做法是：先切分，同时把整卡留给重负载和大模型任务；用 binpack 放置去填满已经部分使用的 GPU，而不是撒出一堆半张卡的碎片；用亲和性搭配让两个高负载任务不会共用一张卡；一套监控闭环；以及弹性伸缩。这些合起来被认为带来了 GPU 利用率提升 50%、整体成本下降 30%，推理性能损失控制在 10% 以内。

Viettel 讲得最直白。这家越南运营商有大约 2,500 块不同世代的 GPU，都压在按团队分配的方式之下，而一张旗舰卡只跑一个推理服务、即便该服务本身已经打满，卡的利用率也只有 10% 左右。他们的判断是，瓶颈从来不是硬件，而是分配的单位。基于这个判断搭起来的四层技术栈，用 OpenStack Ironic 和 Nova 做裸金属供给，用 Kubernetes 加 HAMi 切分和 KEDA 做编排，用 vLLM、SGLang、KServe 和 llm-d 做服务，用 Envoy AI Gateway 计量 token。现在一个团队几分钟就能拿到 API key 和一个兼容 OpenAI 的端点，而不必等上几周要一台服务器。在一张生产卡上，同样的负载、同样的服务等级，利用率从 13% 升到了 59%。他们把这一项作为起点，另行列出随之而来的结果：单卡处理的工作量提升 3.5 倍，这和“在他们测量的那个负载上，要达到同样吞吐所需的 GPU 少了 71%”是同一个结果的两种说法。每瓦交付工作量 2.1 倍则是另外单列的一项。

更有用的是他们讲了什么时候不该这么做。在一个请求大小被上游限制住、始终没超过一张卡一成左右的预测服务上，共享带来了 3.3 倍的收益。而在一个引擎本来就在做 continuous batching 的模型上，性能反而只有基线的约六成；在算力受限的训练上，综合下来是 0.77 倍，只有出于隔离目的才值得做。他们的提醒是，这些数字只属于他们自己。真正可以迁移的是负载的形态：如果引擎已经把卡喂饱了，共享只是把它分掉而已。

阿里巴巴做的是同一笔交易，只是发生在集群层而不是卡这一层。Qwen 跨多个 Karmada 联邦提供服务，他们展示的那份迁移计划每次只搬动一个在线单元，每一轮都等待五分钟的稳定窗口，在搬动一个单元之前先在目标侧预留容量，并一直占着原来的槽位，好让失败的一轮可以回滚。一个再平衡器会随着竞价算力在集群之间流动而重新切分批量推理。他们报告的结果是分配率提高约 15%，竞价 GPU 利用率提高约 30%，原本要花几天的跨集群迁移在几分钟内完成。

副本变成了一个组

一个推理副本已经不再可靠地等于一个 Pod，而这正是这类负载难以调度的原因。由 DaoCloud 和华为云主持的 LeaderWorkerSet (LWS) maintainer 议题给出了一张模型规模表：Kimi K3 为 2.8 万亿参数，DeepSeek V4 Pro 为 1.6 万亿，GLM 5.3 约为 7,500 亿。他们的论点是，这种体量的模型权重已经超过单个节点的 HBM，因此一个副本就变成了一组跨机器分布的 Pod。Deployment 和 StatefulSet 都无法把一个 leader 加上它的 worker 表达为那样一个复制单位，而这正是 LWS 提供的东西：副本数乘以组大小、注入的 leader 地址，以及一个默认在某个 Pod 失败时重建整个组的重启策略。DisaggregatedSet 位于它之上，一份服务定义产出若干切片，每个切片都包含全部角色；每个子 LWS 按切片、修订版本和角色命名，因此滚动更新过程中不会出现新的 prefill 还在和旧的 decode 对话的情况。底下那个调度失败很具体：如果把这些 Pod 分别调度，GPU 槽位可能会被 leader 占满，而没有任何一个副本能变成 ready。Volcano 的答案是把一个 LWS 组做成一个 PodGroup，于是这个组要么作为一个整体被准入，要么根本不被准入；scheduler-plugins 的 coscheduler 用的是同一套做法，而 YuniKorn 则通过自己的 task group 达到同样的效果。

华为把同样的结构带到了一个面向消费者的助手上。支撑其小艺（Celia）助手的推理栈是三层嵌套：一个 ModelServing 容纳若干 serving group，每个 group 又容纳若干角色，因此一个多模态模型可以让 vit、prompt 和 decode 三个角色各自以不同的 Pod 形态运行，并维持一个可用的配比。Gang 策略会编译成 Volcano 的 PodGroup，拓扑策略把 prefill 和 decode 固定在同一个机架上，而比例约束在各角色依据自己的指标伸缩时，把 prefill 与 decode 的比例保持在 1 到 3 之间。值得记住的细节是驱逐保护：一个 validating webhook 会在 Kubernetes 原生的 disruption budget 检查之前，按逻辑单元逐个检查；如果某个单独的组持有某个角色的唯一实例，驱逐会被拒绝，直到运维介入或扩容之后才可能放行。NPU 利用率从 30.1% 提升到 40.7%，NPU 资源的运维自动化率从 63% 提升到 87%。Kthena 路由器并不是华为的项目，而是 Volcano 社区的项目；它与 llm-d 的 KV 缓存感知路由在七种配置上做了对比，并且把输的那些也一并展示了：两种配置在全部指标上都不如基线，两种只在 TTFT 上落后，最好的三种在六项上全部改善，其中最强的一种达到请求吞吐提升 25.1%、TTFT 降低 23.8%。

与 AI 无关的那一层

三星 SDS 把同一个问题带到了物理层。他们以服务的方式从 17 个云数据中心提供异构的裸金属与虚拟机基础设施，业务覆盖 40 个国家，而每一个新产品都落在同一个 underlay 集群上。真正的代价从来不是 Kubernetes 对象的数量，而是耦合。一个节点上最后同时跑着 Multus、Calico 和 OVN，两个 CSI 驱动和两种容器运行时，而隔离只做到命名空间为止。Kubernetes 和驱动的版本绑在一起，所以升一次版本就意味着一次全面回归验证，而某一个负载的数据面故障会把其他负载一起拖下水。他们的答案是把 underlay 拆成若干专用集群，并用 Cluster API 承担运维多个集群的成本。每个专用集群的控制面以 Pod 的形式跑在一个共享的控制集群上，etcd 也包括在内，两个互相没有路由的 overlay 网络之间由 Konnectivity 为 API server 流量打通隧道。这样一来，版本和 CNI 就可以按集群各自选择。把这件事和大会其余内容连起来的，是它换来了什么。因为节点组成是声明式的，一次提交就能把节点从空闲的集群挪到繁忙的集群。他们展示的用例是一个每日周期：工作时间把 GPU 向推理倾斜，夜间向训练倾斜。他们给出的经济账很直白：闲置的节点是已经付过钱却什么也没挣的硬件，而利用率就是利润率。

值得带回去借鉴的主题

值得真正动手的有四件事。第一，在增购之前，先测一下一张卡在生产负载下究竟能交付什么。台上的团队里有三家起步时在大约 10% 到 35% 之间，其中把话说得最直白的那一家，是没有增购任何东西就走出了这个区间。第二，先改分配的单位，再动预算——无论那是用 HAMi 切一张卡、用 LeaderWorkerSet 组一个 leader-worker 组、serving group 里的一个角色，还是在集群之间挪动的一个节点。第三，不要假设共享有用，去验证它。Viettel 的三个结果——在填不满一张卡的负载上 3.3 倍、在本来就能填满的负载上性能只有约六成、在算力受限的训练上综合 0.77 倍——是同一个问题被放到三种形态的负载上问了一遍，而决定答案的，是引擎是否已经把卡喂饱。第四，如果推理已经跨了不止一个节点，现在就转向以组为单位的工作负载 API 和 Gang 调度，而不要事后再补。因为把 prefill 和 decode 分开，已经在 DisaggregatedSet 和华为的 ModelServing 里、在 LeaderWorkerSet 所提供的东西之上，成为一个独立的 API 面。上海这场会上起作用的杠杆并不只有分配，缓存、压缩和路由各自也带来了可观的收益，但反复出现的是分配，而这一切之下的那份稀缺资源，是加速器的时间。