生态图谱与趋势：设备抽象、异构与资源运营化

生态图谱不是项目清单，而是帮助你持续判断趋势的分析坐标系。

本章结论：你需要的不是“项目清单”，而是一套坐标系

在 GPU 基础设施领域，单纯罗列项目的“生态图谱”很快会被热点淘汰。真正可持续的方法，是将项目纳入一套稳定的分析坐标系：

• 新硬件出现时，你能判断它改变的是哪条决策轴。
• 新调度器或新框架出现时，你能判断它属于控制面、数据平面还是工作负载层。
• 新方案声称“提升利用率/降低成本/更强隔离”时，你能用同一套验收口径进行验证。

本章提出一套长期可维护的框架：控制面地图 + 决策轴矩阵 + 运营化闭环。未来新增任何项目，都可以按同样方式对齐，避免内容随热度失效。

本节将详细介绍该框架的结构与应用方法。

三段式生态视角：控制面、数据平面、工作负载面

理解 GPU 平台的整体结构，可以将其划分为三层协同系统。下面分别介绍每一层的核心问题与关注重点。

该图展示了 GPU 平台的三层架构：控制面负责资源治理与策略承诺（配额、队列、优先级等），数据平面负责设备抽象与隔离兑现（设备发现、资源切分、隔离限制等），工作负载面负责模型系统与运行时管理（推理并发、训练拓扑、算子融合等）。三层之间通过明确的边界和职责分离，形成完整的资源治理闭环。

控制面（Control Plane）：治理与承诺

控制面关注资源治理与策略承诺。其核心问题包括：

• 谁可以用、用多少、在什么约束下、优先级如何、何时排队或抢占。

典型能力包括配额、队列、优先级、公平性、准入控制、审计与策略。你最关心的输出是可解释的调度决策、SLO 约束、资源承诺与兑现。

数据平面（Data Plane）：设备抽象与隔离兑现

数据平面负责将抽象的资源请求落实为可隔离、可共享、可对账的设备使用权。其核心问题是：

• 如何将“抽象的资源请求”兑现为“可隔离/可共享/可对账”的设备使用权。

典型能力包括设备发现、资源切分（如 MIG、vGPU）、隔离与限制、同卡共址策略、运行时注入。关注点在于 allocated 与 used 的对账、干扰可控性、隔离边界的真实性。

工作负载面（Workload Plane）：模型系统与运行时形状

工作负载面聚焦于模型或框架如何消费 GPU，以及它们制造的资源形状与抖动。其核心问题是：

• 模型/框架如何消费 GPU，以及它们制造什么样的资源形状与抖动。

典型能力包括推理并发与 KV cache、训练通信拓扑、算子融合、显存峰值、冷启动与弹性。关注输出为吞吐、P99、显存峰值、稳定性与故障模式。

需要注意的是，这三层的边界非常关键。许多“平台问题”其实源于工作负载形状，许多“共享可用”问题则是数据平面未能兑现隔离，许多“调度不公平”则是控制面策略缺失或不可审计。

决策轴矩阵：把任何项目放进同一张二维表

为了让生态分析具备可持续性，本书将所有项目纳入一组稳定的决策轴。你可以将其视为选型与路线图的统一语言。

该图展示了四个关键决策轴：资源单位轴（从整卡到更高层抽象）、隔离轴（从软隔离到可验证隔离）、形状匹配轴（分析碎片化来源）和治理轴（可解释、可审计、可结算、可交付）。通过这四个维度，可以将任何 GPU 基础设施项目纳入统一的分析坐标系，避免被单一特性或宣传语误导。底部还列出了关键的验收指标（干扰系数、P99 抖动、配额兑现等），强调关注可量化的指标而非宣传语。

资源单位轴：你调度的到底是什么？

资源单位的不同，直接影响治理复杂度与利用率。常见的资源单位包括：

• 整卡（GPU-as-a-whole）：最简单，隔离强，但容易产生碎片化。
• MIG（slice as unit）：强隔离且为离散单位，碎片形状固定。
• vGPU/配额（quota as unit）：弹性更强，但对隔离兑现与可审计要求更高。
• 更高层抽象（model/replica/job as unit）：贴近业务，但需要更强的控制面与编排系统。

资源单位越细，治理复杂度越高；资源单位越粗，利用率天花板越低。

隔离轴：你为多租户提供什么级别的“可预测性”？

隔离级别决定了多租户环境下的可预测性。常见隔离方式有：

• 软隔离：共享但尽量减少冲突，依赖调度与约束。
• 强隔离：硬件或驱动级隔离（如 MIG 更接近此侧）。
• 可验证隔离：必须能通过基准与观测证明隔离兑现。

判断隔离效果时，建议直接关注干扰系数、P99 抖动、配额兑现等指标，而非宣传语。

形状匹配轴：碎片化的来源在哪里？

碎片化的来源主要有三类：

• 离散单位导致碎片（MIG 典型）：资源切分形状固定。
• 请求形状导致碎片（vGPU 典型）：用户请求与实际使用存在差异。
• 拓扑导致碎片（多 GPU/多节点训练）：通信与亲和性约束将资源池切碎。

碎片率应被视为系统属性，而非某个组件的责任。

治理轴：系统能否被组织运营？

治理能力决定了系统能否规模化运营。主要能力包括：

• 可解释：为什么 Pending、为什么被拒绝、为何抢占。
• 可审计：谁批准、谁消耗、是否穿透。
• 可结算：allocated/used 的成本归因。
• 可交付：以 SLO 为中心定义容量与承诺。

当 GPU 从“稀缺硬件”转变为“共享基础设施”时，治理轴的重要性甚至超过性能轴。

设备抽象趋势：从“设备插件”到“资源语义层”

设备抽象的演进趋势，决定了平台治理能力的上限。

从 Device Plugin 到 Device Semantics

Kubernetes 原生 device plugin 机制解决了“让 Pod 看见设备”的问题，但尚未覆盖以下方面：

• 多租户共享的定义与兑现。
• 资源的计量、审计与结算。
• 控制面策略如何作用到数据平面。

未来趋势是出现更上层的“设备语义层”，将 GPU 从“节点上的设备”提升为“可治理资源”。

从“资源分配”到“资源承诺”

仅仅分配 GPU 已无法满足需求，平台需要承诺：

• 推理服务的 P99。
• 训练作业的完成时间与失败率。
• 队列等待上限与抢占规则。

这意味着平台必须将“基准与验收”内建为产品能力，而非一次性的性能测试。

从“单一 GPU”到“异构加速器”

异构化已经成为现实：不同 GPU（显存、带宽、算力）、不同互联（PCIe、NVLink、RDMA）、甚至非 GPU 加速器。异构化带来的直接后果是，调度从“能用就行”转变为“要匹配形状与拓扑”。

因此，生态将更像“硬件能力市场 + 调度策略语言 + 运营体系”，而非单点技术。

调度生态趋势：从“调度”到“队列治理 + 资源运营”

调度生态的演进，推动了平台治理能力的提升。

队列化（Queue-first）成为默认形态

训练与批处理天然队列化，推理也越来越需要“准入 + 限流 + 弹性扩缩”。这推动控制面从“调度一个 Pod”升级为“治理一个资源池”。

调度器不再是唯一中心：策略会被拆分与组合

你会看到越来越多“组合式体系”：

• 控制面：队列、配额、优先级（准入、抢占、公平）。
• 数据平面：设备抽象、隔离兑现、共享策略。
• 工作负载：运行时（如 vLLM、Ray、训练栈）自身也具备调度与并行策略。

最终形态不是“一统天下的调度器”，而是多层协作的调度与治理体系。

SLO 驱动的资源运营化

当平台开始承诺 SLO（P99、吞吐、等待上限）时，自然进入资源运营阶段：

• 需要可观测与计量。
• 需要验收与容量规划。
• 需要排障与可用性保障。

这三者组成运营闭环：指标 → 断言 → 动作。

如何持续更新“生态图谱”：一个可复用的评估模板

为了让生态图谱具备长期可维护性，建议为每个新项目或新硬件按如下模板进行评估：

归属层

• 控制面 / 数据平面 / 工作负载面 / 跨层

改变的决策轴

• 资源单位：整卡/MIG/vGPU/更高层
• 隔离级别：软隔离/强隔离/可验证隔离
• 碎片来源：离散单位/请求形状/拓扑
• 治理能力：可解释/可审计/可结算/可交付

需要回答的验收问题

• 对吞吐的影响是什么？
• 对 P99 的影响是什么？
• 干扰系数如何变化？
• 碎片率如何变化？
• 配额兑现与穿透风险如何？
• 运维复杂度与故障模式增加了什么？

在你的两台 A100 环境上的最小验证

• 独占基线对照
• 共享干扰对照
• 失败/回归用例（可复现）

通过上述模板，你可以将“生态更新”变成可持续工程，而非一次性的文章。

本章小结

生态会变，硬件会变，热点会变，但只要你坚持用“控制面地图 + 决策轴矩阵 + 运营闭环”来组织内容：

• 你就能把任何新项目放进统一语义。
• 你就能把讨论从“宣传口号”拉回“可验收标准”。
• 你就能把技术趋势解释成平台路线图与组织能力建设。

下一章将把这些趋势收敛为一份可执行的路线图与贡献指南：如何用最小的投入，把这本书、你的 demo 与你的生态工作一起滚动起来。