生态放置法：把竞品与相关项目放进同一张地图
GPU 方案的争论，往往不是“谁更强”，而是“谁解决的是同一层的问题”。用分层视角，才能让比较变得专业和可复用。
很多 GPU 方案争论的根源，并不在“谁更强”，而在“谁解决的是同一层的问题”。把数据平面、控制面、平台层混在一起比较，结论往往会失真：你以为在选“调度器”，对方其实在提供“虚拟化与隔离”；你以为在选“共享方案”，对方其实在做“驱动与生命周期交付”。所以本章给出一套可复用的“生态放置法”：先放对层，再决定比较口径与可组合方式。
三层两界：GPU 生态的分层地图
在实际评估 GPU 相关项目时，建议先用分层地图明确各自职责。下面介绍三大层级及其典型问题。
数据平面：资源的呈现、隔离与观测
数据平面关注 GPU 在节点上的实际使用方式。典型问题包括：
- 设备发现与资源呈现：如何把 GPU 能力（整卡 / 分片 / 共享）以 Kubernetes 可理解的资源形式暴露出来（device plugin 是典型入口）。
- 切分与虚拟化：MIG、vGPU、时间切片等把一张卡拆成更细单位，换取更高利用率。
- 隔离与干扰控制：多租户/多任务并发时的性能抖动、显存争用、上下文切换开销。
- 观测与计量：能否把“谁用了多少、影响了谁、P99 变成什么”变成可运营指标。
你可以把数据平面理解为：把“能跑”变成“可声明共享 + 可验证干扰”。
控制面：资源供给的治理与策略
控制面不直接改变 GPU 在节点上的运行方式，它解决的是“谁先用、用多少、用多久、能不能进来”。
- 队列与准入：工作负载进集群前是否被准入（Admission）与分流到哪个队列（Queue）。
- 配额与公平性：按团队/租户/项目做 quota、fair sharing。
- 优先级与抢占：在线推理与离线训练如何共存，谁能抢谁。
- 批处理语义：gang scheduling / co-scheduling、job 级别的调度策略（如 Volcano）。
你可以把控制面理解为：把“能调度”变成“可治理的资源制度”。
平台层：能力组合与产品化体验
平台层通常不发明新的资源语义，而是把数据平面与控制面能力包装成可用体系：
- 驱动/运行时/插件的生命周期交付与升级（常与 Operator 形态绑定）
- 多集群、权限、计费、审计、资源可视化与自助申请
- SRE 视角的标准化与故障处理路径
平台层的价值是：把"单点能力"变成"端到端可运营"。
下图展示了 GPU 生态系统的三层架构（数据平面、控制面、平台层）及其职责边界。数据平面负责资源的呈现、隔离与观测（如设备发现、MIG/vGPU 虚拟化、干扰控制、计量）；控制面负责资源供给的治理与策略（如队列管理、配额分配、优先级抢占、批处理语义）；平台层负责能力组合与产品化体验（如驱动生命周期交付、多集群管理、SRE 标准化）。图中明确了同层比较和跨层组合的基本规则，为后续的生态放置流程提供理论基础。
生态放置流程：四步定位项目职责
生态放置法建议按下面 4 步走，每一步都在缩小比较范围。
固定目标工作负载与 SLO
在开始比较前，需明确目标负载类型和服务级别目标（SLO）。例如：
- 目标：训练吞吐优先？还是推理 P99 优先？
- SLO：要不要强隔离？能容忍多少抖动？失败是“降级”还是“事故”？
没有这个前提，后面所有比较都容易滑向口水战。
明确资源单位（Resource Unit）
先把方案的资源单位写出来：整卡 / MIG 分片 / vGPU / 时间切片 / “显存配额 + 计算共享”等。资源单位决定了：
- 调度器能“看见”的最小颗粒度
- 隔离强度的上限
- 重配置成本与运维耦合方式
例如时间切片通常更灵活，但隔离依赖实现与负载行为；它更像“共享策略”而非“硬切分”。
定位执行点（Enforcement Point）
关键问题：这个方案靠什么把规则落到现实里？
- 落在驱动/内核/硬件（强但重）
- 落在运行时与拦截层（灵活但需要工程兜底）
- 落在 Kubernetes 调度器/准入控制（治理强但不改变节点内争用）
- 落在平台编排与运维（体验强但可能依赖下层能力）
执行点决定了它属于哪一层，也决定了它能解决什么、解决不了什么。
写清责任边界（Boundary of Responsibility）
用一句话描述：我负责什么，我不负责什么。
- 数据平面方案通常负责：资源单位的呈现、隔离实现、节点侧的观测计量。
- 控制面方案通常负责：队列/配额/优先级/准入与策略落地，但不承诺节点内干扰归零。
- 平台层负责：交付与规模化运维，但它往往“依赖”下层，不“替代”下层。
按同层同单位比较，跨层只比接口契约
- 同层比较：在同一层、同一资源单位下，才比较隔离强度、性能损耗、观测计量、重配置成本等。
- 跨层比较：只比较接口与组合方式，比如"控制面是否能表达某种资源单位"“数据平面是否提供足够的可观测与计量信号”。
下图展示从问题识别到方案拼装的完整决策流程。第一步：识别问题域（在线推理 vs 离线训练、多租户 vs 单租户、尾延迟敏感 vs 吞吐优先）；第二步：确定优先级（隔离强度、成本目标、可观测性、兼容性）；第三步：选数据平面（MIG/vGPU/HAMi/时间片）；第四步：配控制面（Volcano/Kueue/Koordinator）。图中还展示了三种典型端到端方案（方案 A：离线训练优先用 MIG+Volcano、方案 B：在线推理优先用 HAMi+Kueue、方案 C：混合负载用 MIG+ 时间片+Volcano），以及常见错误和最佳实践，帮助快速定位项目职责。
常见误判：组合≠竞品
实际评估时，容易出现以下误判：
- 数据平面 vs 控制面：很多不是竞品，是上下游。例如把某个共享/虚拟化方案与 Volcano 直接对比，往往是维度错位。正确口径是：数据平面提供资源单位与可测信号，控制面基于这些信号做治理。二者组合起来才构成“可运营的 GPU 体系”。
- device plugin vs 调度器扩展：不要把“资源呈现”当成“调度策略”。NVIDIA 的 device plugin 解决的是“把 GPU 资源以 K8s 可理解方式暴露/分配”，本质上属于资源呈现与节点侧能力。而 scheduler-plugins、以及各类调度扩展，是在 Kubernetes 调度框架上做策略扩展。两者的边界不同：一个回答“资源是什么”，一个回答“谁拿到资源”。
- 平台层 vs 基础能力：不要用“产品体验”去压“机制边界”。以 GPUStack 这类项目为例，它更容易被用户感知为“平台”，因为它提供更完整的交付与可视化体验；但做生态放置时，仍应回到“资源单位/执行点/责任边界”去拆解它到底依赖了哪些数据平面与控制面能力，避免用“体验”去替代“机制评估”。
组合方式：三种典型端到端方案形态
下面介绍三种常见的端到端 GPU 方案形态，帮助理解不同场景下的组合策略。
下图详细展示方案 A（离线训练优先）、方案 B（在线推理优先）、方案 C（混合负载）的典型场景、技术选型和关键能力。方案 A 采用 MIG + Volcano 组合，提供硬件隔离和 Gang Scheduling，适合深度学习训练和批量模型训练；方案 B 采用 HAMi + Kueue 组合，提供可声明共享和配额管理，适合多租户推理服务和在线模型预测；方案 C 采用 MIG + HAMi + Volcano 混合组合，提供分池管理和优先级抢占，适合训练推理混合场景。图中还包含对比维度表（负载类型、优先级、核心挑战、隔离方式、调度器），帮助快速选择适合的方案组合。
形态 A：离线训练/批处理优先
- 控制面：队列 + 配额 + gang scheduling（如 Volcano 类）
- 数据平面：整卡或硬切分资源池；观测与计量用于容量规划
- 关键验收：吞吐、作业等待时间、抢占策略对成功率的影响
形态 B：在线推理/多租户优先
- 数据平面：强隔离或至少可证明的隔离；需要可观测的 P99 与干扰信号
- 控制面：优先级、准入与配额避免“推理被训练挤爆”
- 关键验收：P99、抖动半径（blast radius）、故障隔离与回滚路径
形态 C：混合负载（训练 + 推理 + 交互式开发）
- 先把资源池按“隔离等级/单位/成本”分层（例如强隔离池 vs 共享池）
- 控制面用队列与配额把团队行为制度化
- 平台层提供自助申请、审计与成本可视化
一页模板：快速完成生态放置
你可以用下面这张表快速完成生态放置（建议每评估一个项目就填一行）。
- 项目/产品：
- 所属层：数据平面 / 控制面 / 平台层
- 资源单位：整卡 / MIG / vGPU / 时间切片 / 其他
- 执行点：驱动/硬件｜运行时｜调度器｜准入｜平台
- 主要承诺：解决什么问题（用一句话写清）
- 不承诺：明确不解决什么（避免误用）
- 关键代价：性能损耗、重配置成本、侵入性、兼容性
- 可观测与计量：有哪些信号能支撑运营（SLO/计费/审计）
- 组合依赖：上游/下游分别需要什么才能闭环
- 典型失败模式：最容易“看起来能跑但不可运营”的点
总结
通过分层视角和生态放置法，可以有效避免 GPU 方案评估中的维度错位和无效争论。明确每一层的职责、资源单位、执行点和责任边界，有助于专业、系统地比较和组合不同项目，最终实现端到端的可运营 GPU 体系。