Jimmy Song – 生态与趋势

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

Jimmy Song — Sun, 04 Jan 2026 01:40:54 +0000

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

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

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

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

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

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

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

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

图 1: GPU 基础设施三层协同系统

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 2: GPU 基础设施决策轴矩阵

该图展示了四个关键决策轴：资源单位轴（从整卡到更高层抽象）、隔离轴（从软隔离到可验证隔离）、形状匹配轴（分析碎片化来源）和治理轴（可解释、可审计、可结算、可交付）。通过这四个维度，可以将任何 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 环境上的最小验证

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

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

AI 时代的延伸维度：平台正在变成资源与模型协调器

Kubernetes 起初是一个放置容器的系统；AI 工作负载正把它推向更广的角色：按属性分配设备（DRA，见数据平面）、协调多设备域（ComputeDomain）、缓存模型、构建引擎、自动伸缩推理，并把存储、网络、安全和可观测整合进同一个生命周期。边界在移动，但物理规律不变：工作负载声明越抽象，平台诚实地暴露内存、拓扑、精度、互连、功耗与恢复约束就越重要。

方向	为什么重要	需要验证什么
属性感知分配	异构 GPU 需要的不只是计数	声明、设备类、拓扑、成熟度
互连域	大模型依赖纵向扩展互连	ComputeDomain 语义与故障恢复
模型感知自动伸缩	GPU 利用率看不见排队与 token 行为	TTFT、ITL、缓存、队列、预热
分离式推理	预填充与解码的资源形态不同	网络、内存、调度、尾延迟
机密 AI	模型与数据需要更强隔离	TEE/I/O 支持、运行时、策略
能耗感知放置	功率与散热限制密度	机架遥测与有用工作能耗
Operator 生态	AI 栈由众多控制器组成	版本归属与回滚

表 1: AI 时代最可能变得更重要的方向

其中两个维度值得单独强调。其一是功耗正在成为调度维度：只看得见 GPU 的调度器可能把数学上合法的工作负载放进热学或电气上非法的机架，最有用的“绿色 AI”指标不是利用率百分比，而是每单位有用工作的能耗。其二是智能体（Agentic）AI 改变基础设施形态：一次用户请求可能调用多个模型、工具与检索系统，工作负载不再是单个静态推理容器，而是一张对延迟、内存、安全与加速器需求各异的调用图，这让准入控制、模型感知路由与可推理相关任务的调度器更值钱。

本章小结

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

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

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

持续更新路线图与读者参与机制

Jimmy Song — Sun, 04 Jan 2026 01:54:23 +0000

书的价值不在于章节堆叠，而在于持续沉淀可复用的验证资产和标准化的参与机制。

本章将介绍如何将写书过程转化为维护可复用验证资产库的系统方法，确保每一次内容更新都能沉淀为可复用的场景、对比表和实验记录，并通过标准化的贡献流程实现读者的高效参与。

本章结论：把“写书”变成“维护一个可复用的验证资产库”

要让本书长期保持价值，不能仅靠不断增加章节，而应依赖一套可持续演进的机制。具体来说：

每新增一篇内容，都能沉淀为可复用的 场景定义、对比表、实验记录、验收口径。
每新增一个项目、硬件或策略，都能快速纳入既有坐标系并完成最小验证。
读者的参与不只是“留言讨论”，而是以标准化格式提交 可复现证据，让知识持续增量累积。

本章将给出本书的“操作系统”：最小增量单元（MIU）、目录与版本节奏、贡献模板，以及如何将实验结果转化为可交付的验收标准。

最小增量单元（MIU）：场景 + 对比表 + 实验记录

本节介绍如何将内容生产统一为一个最小闭环，确保每次更新都具备可复用性。

场景（Scenario）
每个场景建议固定包含以下字段（可复制为模板）：

场景名称：一句话说明“要解决什么”
目标：要验证的承诺（例如配额兑现、隔离有效、P99 可控）
约束：硬件、MIG 状态、K8s 版本、工作负载形态
成功判据：可量化的通过/失败（不是“看起来还行”）
反例/边界：希望系统拒绝什么，或在哪些条件下必然失败

对比表（Comparison Table）
对比表的作用是将观点结构化为差异矩阵，便于决策。建议每个场景至少覆盖以下维度：

资源单位（整卡/MIG/vGPU/配额）
隔离等级（强隔离/软隔离/可验证）
干扰与抖动（P99、干扰系数）
碎片化（碎片率、可用形状）
治理能力（可解释/可审计/可结算/可交付）
运维复杂度（升级/变更/排障成本）

实验记录（Lab / Runbook）
实验记录需达到“他人 30 分钟能复现同结论”的标准，建议固定包含：

环境声明：节点、GPU、驱动、CUDA、MIG、组件版本
YAML/脚本入口：一条命令即可运行
观测点：需采集的指标、日志、事件
结果格式：用表格或结构化输出记录
验收结论：对照成功判据逐项打勾/失败

这三者合起来，构成长期可复用资产，便于演讲、Workshop 或客户评审直接复用。

图 1: 最小增量单元（MIU）结构：场景、对比表、实验记录三者相辅相成，共同构成长期可复用的验证资产库

内容演进策略：先“骨架稳定”，再“模块扩展”

为避免结构漂移，建议将内容演进分为三条并行流水线：

主线（Stable Track）
主线章节（如控制面地图、决策轴、验收与容量、排障、趋势）应保持框架与口径稳定，主要以补充例子和边界为主，不频繁改写结构。

实验线（Lab Track）
新增内容优先落在 Lab：

新硬件/新项目：先落一个最小验证 Lab
新结论/新观点：必须绑定一个可复现的对照实验

这样可以低成本持续更新，同时提升内容可信度。

生态线（Landscape Track） 生态更新遵循本书的“坐标系模板”，每新增一个项目，只要能回答“它改变了什么轴、用什么证据验证”，即可纳入。

图 2: 内容演进策略的三条并行流水线：主线保持框架稳定，实验线持续验证，生态线按模板扩展

版本节奏与发布机制：让读者知道“现在可信到什么程度”

为让读者理解内容成熟度，建议引入明确的状态与节奏。

章节成熟度标记（建议四级）

draft：结构在，但结论可能变化
validated：至少在你的两台 A100 环境完成对照实验
reproducible：读者按步骤可复现（你已验证一次“陌生环境复现”）
production-notes：加入真实生产经验与故障案例（可脱敏）

建议将此状态放在每章 front matter 的 status 字段，并在文首用 callout 显示。

发布节奏（建议以周为单位）

每周至少合并一批“可复现实验”PR（哪怕只有一个小实验）
主线章节只做小修小补，不追求一次性完善
每月做一次“路线图回顾”，将读者反馈与生态变化映射到下一阶段 Lab

读者参与机制：让贡献变成“可验收的证据”，而不是观点争论

本节介绍如何通过标准化格式降低维护成本，实现高效读者参与。

Issue 模板：新增场景 / 报告问题 / 请求对比

建议提供三类 issue，每类都有固定字段：

New Scenario / 新场景请求

场景描述
目标与成功判据
环境信息
期望对比对象（HAMi vs MIG vs …）
是否愿意提供实验结果

Bug / 文档或实验问题

复现步骤
实际结果 vs 期望结果
组件版本与环境
日志/事件（脱敏）
希望如何修复（可选）

Comparison Request / 希望新增对比表项

需要补齐的决策轴
为什么这个轴重要（业务动机）
可提供的证据来源（实验/生产数据/公开数据）

PR 模板：提交实验结果的标准格式

PR 不是“改一段文字”，而是提交“可复用资产”。建议 PR 至少包含：

新增或更新的 Lab YAML/脚本（可复现入口）
一份结果记录（固定表格字段）
一段结论与边界（对应成功判据）
必要的环境声明（版本、驱动、MIG、GPU 型号）

图 3: 读者参与机制：从 Issue 模板到 PR 模板，最终沉淀为可复用的验证资产，让贡献成为可验收的证据而非观点争论

结果格式标准化：用同一套表格承载不同实验

为便于不同贡献对齐，建议所有实验输出统一表格，字段如下：

Workload：vLLM / PyTorch / NCCL / 自定义
Mode：独占 / MIG / 共享（HAMi）
Request：请求形状（卡数/显存/核数/并发）
Throughput：吞吐（明确单位）
Latency P50/P95/P99：延迟
Interference Coef：干扰系数（相对独占）
Fragmentation：碎片率或可用形状变化
Stability：是否出现 OOM/Xid/掉卡
Notes：关键观察与推断

通过标准化表格，本书将逐步演进为“可查询的对照数据库”，而不仅仅是文章集合。

把内容沉淀为可复用工具：脚本、清单与验收标准

最终目标是交付三类“随书工具”，提升内容的可操作性和落地价值。

实验脚本库（scripts/）

一键部署/清理（install/uninstall）
一键采集结果（collect-metrics、export-result）
一键生成报告（将表格转为 Markdown/图表）

验收清单（acceptance/）

将“基准、验收与容量规划”章节定义的指标固化为清单：

推理：吞吐、P99、冷启动、并发上限
共享：干扰系数、配额兑现、穿透检测
运维：升级/回滚、故障注入、恢复时间

平台评审材料（workshop/demo-kit/）

将最具代表性的 3–5 个场景打包成 demo-kit：

讲清楚“为什么难”
演示“如何治理共享”
用证据链证明“可验收、可运营”

这些工具将直接服务于入职后的对外 demo、平台评审与生态建设。

路线图：未来 4 周的可执行计划（建议）

为帮助你高效推进，下面是一份适合当前节奏的路线图，可直接写进本章末尾。

Week 1：把“可复现闭环”跑通

固化 MIU 模板
完成 3 个核心 Lab 的结果表（独占、MIG、HAMi 共享）
输出第一版 demo-kit

Week 2：把“观测与计量”落到工具链

最小观测方案（nvidia-smi/日志）脚本化
引入 DCGM Exporter + Prometheus（可选，但要有落地路径）
结果表自动化生成

Week 3：补齐治理能力：队列/配额/准入的对照

Kueue/Volcano 至少各补一个“策略导致的可解释结果”Lab
将 Pending/准入/抢占写成可复现用例

Week 4：开始生态扩容

每周新增 1–2 个项目条目（按坐标系模板）
每新增条目至少配一个最小验证或公开证据链
开始收集读者贡献并维护榜单

图 4: 未来 4 周路线图：从基础可复现闭环到观测工具链，再到治理能力补齐，最后实现生态扩容的渐进式演进计划

总结

本章系统梳理了如何将写书过程转化为可持续的资产增长飞轮。通过“场景 + 对比表 + 实验记录”为最小单元，每次更新都沉淀为可复用资产；标准化 issue/PR 模板将读者参与转化为证据输入；统一的结果格式让不同项目、硬件、策略的差异回归同一套验收口径。这一机制将个人品牌从“写得好”升级为“能交付、能验证、能运营”。

附录：命令速查

Jimmy Song — Sun, 30 Aug 2026 00:00:00 +0000

把这一页放进跑脚手册：排障流程见故障模式与排障手册，验收流程见实施顺序。

硬件与拓扑

nvidia-smi
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi dmon
lspci -tv
lscpu -e=CPU,NODE,SOCKET,CORE
numactl --hardware
hwloc-ls

Kubernetes 与 Operator

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl describe node <node>
kubectl describe pod <pod> -n <namespace>
kubectl get events -A --sort-by=.lastTimestamp
kubectl get resourcequota -A
kubectl get priorityclass
kubectl get crd | grep -E 'gpu|nvidia|resourceclaim'

分布式工作负载

NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,GRAPH,NET
ip -br link
rdma link

总结

命令本身不产生结论，结论来自把输出放回决策轴与验收清单的框架里。这一页只是入口，语义与流程请回看对应章节。