组合架构：用一套拼装方式覆盖多数场景
组合架构的本质，是用“正交拼装”让资源治理与交付变得可控、可评审、可复现。
本章将系统梳理 GPU 资源平台的组合架构思路，帮助你根据实际需求灵活拼装数据平面与控制面，实现从“可用”到“高效”的演进。
定义“拼装件”：你能选的到底是什么？
在设计 GPU 资源平台时，首先要明确可选的“拼装件”有哪些。下面分别介绍数据平面和控制面的核心选项。
数据平面（决定资源单位与隔离/共享边界）
数据平面负责将 GPU 变成 Kubernetes 可消费的“资源单位”，并决定隔离强度、性能干扰与可观测性上限。
- 整卡（Whole GPU）：最简单、最稳定，隔离强（天然独占），但细粒度利用率有限。
- MIG（Multi-Instance GPU，硬切分）：强隔离、单位离散，适合多租户与在线推理/小训练，但重配置带来运维与调度耦合。
- 共享/虚拟化（以 HAMi 为代表的可声明共享）：资源更细粒度、更弹性，隔离与干扰取决于实现与负载行为，对治理与观测要求更高。
经验法则：
- 越追求“共享与弹性”，越需要更强的控制面治理与更严格的验收指标。
- 越追求“强隔离与确定性”，越需要面对“资源单位离散/重配置成本/碎片化”的现实。
控制面（决定谁能用、何时用、用多少、用得是否公平可预测）
控制面负责将 GPU 资源纳入队列、配额、准入与策略治理，提供可运营秩序。
- Kueue（治理/准入/配额/承诺/统计）：解决多团队多租户下的稳定秩序与可预测体验。
- Volcano（批处理语义/作业调度策略）：补齐训练、分布式、Gang/Queue 等批处理表达能力，偏重调度策略与作业语义。
经验法则：
- Kueue 更像资源治理框架（准入 + 配额 + 承诺 + 统计），是平台化的底座。
- Volcano 更像批处理调度引擎（训练/作业语义），是训练类负载的加速器。
- 两者可正交组合：数据平面负责资源单位与隔离，控制面负责秩序与策略。
下图展示 GPU 平台的拼装件组成，包括数据平面和控制面的核心选项。数据平面（蓝色区域）决定资源单位与隔离边界，包含三种选项：整卡（最简单、最稳定、隔离强但细粒度利用率有限）、MIG（硬切分、强隔离、单位离散但重配置带来运维成本）、共享/虚拟化 HAMi（可声明共享、资源更细粒度但隔离与干扰取决于实现）。控制面（黄色区域）决定谁能用、何时用、用多少，包含 Kueue（资源治理框架，提供准入配额统计）和 Volcano（批处理调度引擎，补齐训练作业语义）。底部强调核心理念：用正交拼装让资源治理与交付变得可控、可评审、可复现。
拼装原则：先定边界，再做组合
在实际架构设计中，遵循以下拼装原则有助于降低风险、提升可控性。
原则 A：先用最小可用闭环而不是最大功能集
优先保证可用、可测、可回滚、可计量，再逐步扩展共享与复杂调度。原则 B：资源单位越细，验收越严格
整卡的失败多来自调度与容量，共享的失败多来自干扰、计量、隔离语义不一致。原则 C：重配置是“变更”，必须被流程化
尤其是 MIG，重配置会影响可用资源形态，必须纳入变更窗口、容量预留及调度策略。原则 D：把平台责任写进架构
明确哪些责任属于数据平面（隔离/共享/设备暴露），哪些属于控制面（准入/配额/队列/公平），哪些属于平台层（交付体验、SLO、计量与成本）。
参考架构目录：6 种组合覆盖多数场景
为方便评审，下面给出 6 套可直接落地的参考架构，从简单到复杂递进。你可以将它们作为“标准套餐”，再按组织与负载微调。
- A. 单队列整卡：最小闭环（入门/小团队）
- B. 多队列整卡 + Kueue：治理先行（多团队/公平性）
- C. MIG 池化 + Kueue：强隔离的细粒度（在线推理/多租户）
- D. HAMi 共享 + Kueue：可声明共享（混部/高利用率）
- E. 训练增强：Volcano（可选）叠加：训练语义补齐（分布式/批处理）
- F. 双池/双域：在线与离线分治：稳定性优先（生产平台）
你不需要一次性上全套。推荐路线：A → B（治理）→ C/D（细粒度）→ E/F（平台化）。
下图展示 6 种参考架构从简单到复杂的演进路径。A（单队列整卡）是最小闭环，适合小团队先跑稳；B（多队列整卡+Kueue）引入治理，实现多团队公平；从 B 可以演进到 C（MIG 池化+Kueue）追求强隔离，或 D（HAMi 共享+Kueue）追求高利用率；进一步可演进到 E（训练增强 Volcano 叠加）或 F（双池/双域分治）。右侧图例说明不同颜色代表复杂度等级（绿色入门、黄色中级、红色高级、蓝紫色平台级）。底部展示推荐演进路径：A → B（治理先行）→ C/D（细粒度）→ E/F（平台化）。核心思想：根据组织成熟度和负载形态逐步演进，不需要一次性上全套。
参考架构 A：单队列整卡（最小闭环）
本方案适用于团队规模较小、GPU 数量有限、负载以训练/推理为主但不复杂的场景，目标是“先跑稳”。
架构要素：
- 节点：GPU Node（整卡暴露）
- 调度：原生 Kubernetes Scheduler（或简单扩展）
- 控制：无额外治理（最多 namespace 限制）
复杂度与风险点：
- 复杂度低
- 风险包括多团队抢占、缺乏公平性、无准入与配额、平台体验不可预测、容量规划依赖人工
建议验收指标（最小集）：
- 可用性：单节点/单卡故障不会导致集群级连锁故障（至少能隔离影响范围）
- 调度：GPU 请求的 Pod 成功调度率、平均等待时间（P50/P95）
- 资源：GPU 利用率基线（按业务定义：训练/推理分别统计）
参考架构 B：多队列整卡 + Kueue（治理先行）
当多团队/多租户出现，需要“谁能用、能用多少”的治理时，推荐采用本方案。
架构要素：
- 数据平面：整卡
- 控制面：Kueue（Queue/Quota/Admission）
- 平台层：团队/项目维度的配额策略与报表
复杂度与风险点：
- 复杂度中等（引入治理对象与策略）
- 风险包括配额与优先级策略设计不当导致“看似公平、实际饥饿”，治理对象边界不清导致运维负担上升
建议验收指标：
- 公平性：各队列的等待时间分布与资源兑现率（承诺->实际）
- 可预测性：配额下的吞吐（jobs/day）与违约率（超配/抢占/回收）
- 可运营：资源统计可按队列/团队归因（至少月度/周度可对账）
参考架构 C：MIG 池化 + Kueue（强隔离的细粒度）
适用于多租户在线推理、希望强隔离和单位更细（如 1g/2g 等）的场景，能接受 MIG 单位离散与重配置成本。
架构要素：
- 节点：GPU Node（开启 MIG）
- 数据平面：MIG 实例作为可调度资源单位
- 控制面：Kueue 负责队列、准入、配额与承诺
- 运维：MIG Profile 作为“容量形态”，由变更流程管理
复杂度与风险点：
- 复杂度中高
- 风险包括重配置耦合调度、碎片化、运维窗口需求
建议验收指标（必须更严格）：
- 隔离：并发租户压测下的性能抖动（P95/P99）在可接受阈值内
- 形态：Profile 变更的成功率、回滚时间、对在跑作业影响面
- 碎片：无法调度的原因分类中，“形态不匹配”占比可度量并可优化
- 治理：队列维度的兑现率与超卖风险可观测
参考架构 D：HAMi 共享 + Kueue（可声明共享的高利用率）
当 GPU 需求呈现碎片化小请求、目标是显著提高利用率时，推荐采用本方案。适合具备较强 SRE/平台能力的组织。
架构要素：
- 节点：GPU Node
- 数据平面：HAMi 提供“可声明共享”的资源表达
- 控制面：Kueue 提供准入、配额、承诺、统计（避免共享导致的无序竞争）
- 平台层：SLO（延迟/吞吐/错误率）与计量（用量归因）纳入运营
复杂度与风险点：
- 复杂度高
- 风险包括干扰与噪声、语义一致性、计量与归因难题
建议验收指标（共享必备）：
- 干扰：并发下关键 SLO 指标（延迟/吞吐）变化曲线、抖动上界
- 计量：用量可归因到队列/租户（至少支持审计与对账）
- 超分策略：超卖比例、违约率、回收策略触发频率可观测
- 故障隔离：异常租户不会拖垮整机/整节点的稳定性
参考架构 E：训练增强（Volcano 叠加，按需启用）
本方案不是替代 Kueue，而是补齐训练/批处理语义。Kueue 负责治理与准入，Volcano 负责训练作业语义与调度策略。
适用场景：
- 分布式训练、Gang 调度、批处理队列策略需求强
- 需要训练作业更丰富的调度能力（如队列、优先级、抢占等语义）
架构要素：
- 数据平面：整卡 / MIG / HAMi（任选其一）
- 控制面：Kueue（准入/配额/承诺）、Volcano（训练作业语义/调度策略）
- 平台层：训练作业生命周期管理（模板、重试策略、产物管理）
复杂度与风险点：
- 复杂度中高（两个控制面组件协同）
- 风险包括策略重复、观测复杂
建议验收指标：
- 训练吞吐：jobs/day、平均排队时间、失败重试成本
- Gang 成功率：分布式作业成功启动率、资源聚合耗时
- 公平性：队列间训练资源分配符合预期（可回放/可解释）
参考架构 F：双池/双域（在线与离线分治，稳定性优先）
适用于生产平台，在线推理与离线训练/批处理并存，在线 SLO 严格，需要隔离训练波动/抢占/噪声。
架构要素：
- 资源池 1（Online Pool）：偏强隔离（整卡或 MIG），严格准入与优先级
- 资源池 2（Offline Pool）：偏吞吐（整卡或共享），容忍更大波动
- 控制面：Kueue 统一治理（跨池配额/承诺/统计），训练侧可选 Volcano
- 平台层：统一门户与用量归因（按池/队列/项目）
复杂度与风险点：
- 复杂度高（资源池治理、容量规划、跨池策略）
- 风险包括容量割裂、策略复杂
建议验收指标：
- 在线 SLO：延迟 P95/P99、错误率、抖动边界
- 离线吞吐：训练/批处理吞吐、排队时间
- 跨池效率：借用比例、回收时延、在线被影响事件数
组合对照表：按“组织成熟度 × 负载形态 × 运维约束”选套餐
为帮助快速选型，下面给出常见约束下的推荐组合。
这是选型建议表：
| 约束/目标 | 首选组合 | 次选组合 | 不推荐（除非你很清楚为什么） |
|---|---|---|---|
| 小团队、先跑稳 | A（整卡） | B（整卡+Kueue） | 直接上 D（共享） |
| 多团队、要公平可预测 | B（整卡+Kueue） | C（MIG+Kueue） | 只靠 namespace 约束 |
| 在线推理、多租户、要强隔离 | C（MIG+Kueue） | F（双池分治） | D（共享）作为默认 |
| 追求高利用率、碎片化请求多 | D（共享+Kueue） | F（双池分治） | 只上 A/B 且长期不治理 |
| 分布式训练/批处理语义强 | E（Kueue+Volcano） | B/C + E | 仅 A（会“能跑但难管”） |
下面是复杂度与风险等级对照表：
| 架构 | 复杂度 | 主要风险 | 主要收益 |
|---|---|---|---|
| A | 低 | 无治理、不可预测 | 最快上线、最少组件 |
| B | 中 | 策略设计不当导致饥饿 | 公平与可预测、可运营 |
| C | 中高 | 重配置/碎片化/变更耦合 | 强隔离 + 更细粒度 |
| D | 高 | 干扰/计量/语义一致性 | 高利用率 + 细粒度弹性 |
| E | 中高 | 多控制面协同复杂 | 训练语义与吞吐提升 |
| F | 高 | 容量割裂/跨池策略复杂 | 在线稳定 + 离线吞吐 |
评审模板：让方案“可评审、可实施、可验收”
为提升架构评审效率，建议使用如下模板：
必答问题（评审清单）：
- 资源单位是什么？（整卡 / MIG / 共享）为什么？
- 隔离强度目标是什么？（强隔离/中等/可接受干扰）如何验证？
- 谁是治理对象？（团队/项目/租户/队列）边界是否清晰？
- 准入与配额如何定义？资源承诺如何统计与归还？
- 重配置是否存在？（尤其 MIG）谁能改？何时改？如何回滚？
- 观测与计量口径是什么？（至少能回答“谁用了多少、影响了谁”）
- 故障域是什么？（单 Pod/单节点/单池/全局）应急预案是什么？
验收指标建议（三层指标）：
- 调度层：排队时间、调度成功率、抢占/回收事件
- 性能层：关键 workload 的吞吐/延迟（P50/P95/P99）、抖动上界
- 运营层：用量归因、兑现率、超卖违约率、成本可解释性
推荐落地路径：从"可控"走向"高效"
平台演进建议分为三个阶段：
下图展示从可控到高效的三阶段落地路径。Phase 1（建立秩序 A → B）：先用整卡跑稳，再引入 Kueue 做队列/配额/准入，目标是公平、可预测、可统计，验收标准包括多团队配额与公平性、等待时间可预测、资源使用可归因。Phase 2（引入细粒度 B → C 或 B → D）：如果优先隔离上 MIG（架构 C），如果优先利用率上 HAMi（架构 D），必须同步加强验收与观测，验收标准 C 侧重隔离强度/P95 抖动/碎片率，D 侧重干扰控制/计量归因/超卖违约率。Phase 3（平台化分治 → E/F）：训练复杂就叠加 Volcano（架构 E），在线/离线冲突强就做双池分治（架构 F），验收标准 E 侧重训练吞吐/Gang 成功率/公平性，F 侧重在线 SLO/离线吞吐/跨池效率。底部强调核心理念：每阶段都要有清晰的验收指标和回滚路径，避免技术债务累积。
总结
- 数据平面决定你交付的资源单位与隔离上限。
- 控制面决定多租户下的秩序、治理与可预测体验。
- 组合架构不是简单堆组件，而是把边界写清、把验收做实，实现能交付、能运营、能复现的平台能力。