《算法是门脸，工程是命门》

为什么你的大模型训练总是卡在“等待资源”？为什么GPU买了一堆，利用率却不到30%？“我们买了20台A100，但模型跑起来还是慢得像蜗牛。”

这是我2025年听到最多的抱怨之一。很多企业在拥抱大模型的路上，把注意力都放在了模型本身——选哪个开源模型、怎么微调、怎么提升准确率。结果模型选好了，代码写好了，却在部署上线的那一刻，被基础设施卡住了脖子。

问题出在哪？答案只有一个：你没搞懂K8s的GPU调度。

今天，我们就从实战角度，拆解K8s调度GPU的完整技术栈，并给出三个可以直接参考的架构图，帮你彻底打通大模型落地的“最后一公里”。

一、 大模型落地，基础设施的三座大山

在深入调度之前，我们先看清问题本质。大模型在K8s上落地，面临三个独特的挑战：

1.1 资源稀缺性与独占性

大模型训练需要整卡、甚至整机（8卡）的独占资源。传统K8s调度器是按Pod为单位逐个调度的，无法感知“一个作业需要8张卡且卡间需要高速互联”这个事实。结果就是：明明集群有16张卡，但因为碎片化，一个8卡任务死活调度不上去。

1.2 通信拓扑敏感性

现代大模型训练依赖分布式并行策略（数据并行、张量并行、流水线并行）。不同并行策略对节点间通信带宽的要求天差地别。如果调度器不懂网络拓扑，把需要高频通信的Pod分散在不同机架，训练效率会断崖式下跌。

1.3 推理的弹性与延迟矛盾

推理服务要求毫秒级响应，但大模型动辄几十GB，加载到显存就需要几十秒。如何在保持弹性的同时，不让用户等待，是个两难问题。

二、 GPU调度的核心技术栈

2025年，成熟的K8s GPU调度解决方案已经形成了清晰的“三层架构”：

1. 底层（硬件抽象层）：NVIDIA GPU Operator、NVIDIA Device Plugin、MIG（多实例GPU）、MPS（多进程服务）。负责将物理GPU暴露给K8s，并支持切分共享。
2. 中层（调度增强层）：Volcano、Kueue、Scheduler Plugins。负责批量调度、队列管理、拓扑感知。
3. 上层（AI应用层）：KSer版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！ve、vLLM、Triton Infe版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！rence Server。负责模型部署、自动伸缩、推理优化。

下面，我们用三个流程图，把这三层如何协同工作讲清楚。

三、 流程图解析：从训练到推理的完整调度路径

3.1 大模型训练任务的完整调度流程（分布式并行）

描述：当提交一个分布式训练任务时，K8s调度器如何感知拓扑、分配资源、并保证卡间高速互联。

说明：

1. 资源发现：NVIDIA Dev版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！ice Plugin是基础。它负责发现每个节点的GPU数量、型号（A100/H100/昇腾）、显存大小，并上报给K8s API Server。
2. 拓扑感知：Volcano的拓扑感知能力是关键。它能读取节点的NVLink拓扑信息，知道哪些GPU卡在同一个PCIe Switch下、哪些节点之间有高速互联。
3. Pod组调度：这是解决“8卡任务调度不上去”的核心。Volcano的PodGroup机制保证一个作业的所有Pod要么全部调度成功，要么一个都不调度，避免部分Pod卡住导致的死锁。

3.2 GPU共享与碎片优化（MIG/MPS 调度策略）

描述：不是所有任务都需要整卡。推理任务和小型微调任务可以通过GPU共享技术，把一张卡切分成多个逻辑单元，大幅提升资源利用率。此图展示了如何根据任务类型，动态选择共享策略。

说明：

1. 整卡独占：对于大模型训练这种关键任务，性能第一，成本第二。直接绑定整卡，避免任何共享带来的性能抖动。
2. MIG切分：2025年，NVIDIA H100/A100的MIG技术已经非常成熟。一张A100 80GB可以切分成最多7个独立实例，每个实例有独立的显存和计算单元，硬件级隔离，互不干扰。适合中等规模的推理服务。
3. 动态调整：这是2025年调度器的新能力。当检测到某张卡的共享实例过多导致性能下降时，调度器可以主动驱逐部分低优先级任版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！务，重新平衡负载。

3.3 大模型推理服务（LLM）的端到端部署架构

描述：从模型加载到请求响应，完整的推理服务链路上，每个环节都可能成为瓶颈。此图展示了基于KServe的标准化推理架构，涵盖模型缓存、弹性伸缩、流量路由三大核心能力。

说明：

1. 推理网关：KServe作为统一入口，可以根据请求头（如model-version: v2）将流量路由到不同版本的模型，实现AB测试和金丝雀发布。
2. 模型缓存池：这是解决“冷启动慢”的关键。将常用模型预先加载到基于RDMA的高速共享存储中，新Pod启动时直接从缓存加载模型到显存，时间从分钟级降到秒级。
3. 弹性伸缩：KEDA基于GPU利用率或每秒请求数（RPS）触发伸缩。当流量高峰来临时，秒级拉起新推理Pod；低谷时缩容到零，但保留模型缓存，实现真正的Serverless体验。

四、 总结

大模型落地难，难的不是算法，而是工程。而工程中版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！最容易被低估的，就是K8s的GPU调度能力。

当你的训练任务不再卡在Pending状态，当你的推理服务能够丝滑伸缩，当你的GPU利用率从30%提升到80%，你会发现：大模型落地，其实没那么难。

K8s不是银弹，但搞懂了GPU调度的K8s，是你通向大模型生产化的最佳路径。