Hands-on 总览：两台 A100 的实验方法学

只改变一个变量，才能让实验结论真正可迁移、可复现、可验收。

本章将为全书 Hands-on 部分定义一套统一的实验设计方法。我们将在三种数据平面路径下，使用同一套负载与指标进行对照实验，帮助你在自己的集群中复刻结论，并将其转化为平台的资源模型、调度策略与验收标准。

实验的基本原则：只改变一个变量

为了将数据平面差异从其他噪声中剥离，所有实验遵循以下原则：

• 固定负载：相同模型、版本、参数（并发、batch、序列长度、warmup 策略等）。
• 固定集群与节点：同一批节点、相同驱动/固件/容器镜像、CPU/内存/网络配置一致。
• 固定控制面策略（除非该章专门讨论）：队列、配额、准入、优先级、抢占等策略保持不变。
• 只切换数据平面路径：共享 ↔ MIG ↔ HAMi。
• 重复与统计：每组实验至少重复 N 次（建议 N≥3），用中位数和分位数呈现，不用单次结果下结论。

经验提示：越想做“更真实的线上”，越要把变量写清楚。真实不是不控制变量，而是把控制变量变成显式契约。

实验环境：两台 A100 的最小可复现实验场

本书假定你拥有两台带有 A100 的节点（同型号最佳；如不同型号，需详细记录）。

在进行实验前，需详细记录硬件与拓扑信息，确保实验可复现。

硬件与拓扑信息（必须记录）

• 节点数量：2
• GPU：A100 ×（每节点 GPU 数量）
• GPU 显存：如 40GB/80GB（填实际）
• 互联：PCIe / NVLink（填实际）
• NUMA：单/双路，GPU 归属 NUMA（填实际）
• 网络：10/25/100GbE 或 IB（填实际）

记录拓扑信息的原因在于，实验规模扩大后，性能主导因素会从单卡竞争转向 NUMA、PCIe、NVLink、网络通信等。如果不记录拓扑，容易出现“可调度但不可用”的伪成功。

软件栊（必须记录）

• OS / Kernel：
• NVIDIA Driver：
• CUDA / NCCL（如涉及分布式）：
• 容器运行时：
• Kubernetes 版本：
• GPU 插件/组件版本（device plugin / MIG 管理器 / HAMi 组件等）：
• 监控与采集（Prometheus / DCGM exporter / 日志系统等）：

版本信息是可复现的第一要义。结论不怕“过期”，怕的是“无法定位差异来自哪里”。

三条路径：我们到底在对比什么

本节介绍三条数据平面路径的核心区别及实验切换方式。

• 共享：将 GPU 作为可并发使用的同一块设备，隔离依赖软件与习惯，容易受噪声邻居影响。
• MIG：将 GPU 切分为多个硬件隔离的实例，隔离强但资源单位离散，重配置与调度/运维耦合。
• HAMi：将共享能力以可声明的资源形式暴露给 Kubernetes（K8s, Kubernetes），调度器可治理共享，隔离强度与可观测性需体系化设计兜底。

下面分别介绍三条路径的实验关注点。

下图展示三条实验路径的对比：路径 1（蓝色）共享虚拟化（粗粒度），关键特性是多任务共享同一 GPU、显存时间片复用、适合低负载/开发测试，重点关注干扰隔离，条形图显示隔离粒度和管理开销较低但可观测性有限，成本效益高（低成本高利用率）。路径 2（黄色）MIG（中等粒度），关键特性是硬件级隔离实例化、固定显存与计算 slice、适合多租户生产环境，重点验证实例级性能，隔离粒度和管理开销中等，可观测性较好，成本效益中等（中等成本稳定隔离）。路径 3（绿色）HAMi（细粒度），关键特性是细粒度显存切片、深度监控与干扰检测、适合极致隔离需求，重点验证一致性 SLA，隔离粒度、管理开销和可观测性都很高，成本效益较低（高成本极致隔离）。条形长度表示指标强度（越长越好，除成本效益外）。底部说明实验设计原则：从粗到细逐步验证隔离能力、可观测性与成本效益的平衡点。

路径 A：无 MIG 的共享（干扰与尾延迟风险）

本路径不启用多实例 GPU（MIG, Multi-Instance GPU），将同一块物理 GPU 在多个工作负载间共享（如多 Pod 并发、MPS/时分等方式，具体实现需记录）。

关注点包括：

• 共享下吞吐是否提升？提升的代价是什么？
• 尾延迟（p95/p99/p999）是否被放大？是否出现抖动与长尾？
• 噪声邻居（noisy neighbor）引入后，干扰是否呈现非线性放大？

典型结论：

• 平均性能可能“还不错”，但尾延迟可能显著恶化。
• 当显存、带宽、SM 竞争进入某区间后，系统抖动会突然变得不可控。

路径 B：MIG（强隔离、离散资源单位、重配置成本）

本路径启用 MIG，将 A100 切分为多个 MIG 实例（如 1g/2g/3g/7g 等离散规格，具体以实际配置为准）。

关注点包括：

• 强隔离是否能显著改善尾延迟？改善幅度如何？
• 离散规格带来的碎片化与调度约束如何体现？
• 重配置（更改 MIG profile）带来的运维成本：节点 drain、重启、窗口期、不可用风险等。

典型结论：

• 隔离收益通常体现在尾延迟与抖动上。
• 资源利用率可能因离散切分与碎片化下降。
• 变更 MIG 配置往往涉及运维层的大动作，而非调度层的小改动。

路径 C：HAMi（可声明共享 → 可调度、可治理）

本路径启用 HAMi，将 GPU 共享能力以可声明的形式暴露给 Kubernetes，例如按份额、显存、算力权重等表达（具体以 HAMi 的实现与 CRD/资源模型为准）。

关注点包括：

• 资源请求是否可表达、可审计、可配额？
• 调度行为是否可预测？同样请求在同样供给下分配是否稳定？
• 可观测性是否足够支持计量与治理（谁在用、用多少、影响谁）？

典型结论：

• 共享能更细粒度地提升利用率。
• 必须配套准入、配额、观测、回收等机制，否则共享风险会放大到平台层面。

统一负载：用同一套工作负载打穿三条路径

为覆盖主要场景，负载分为三类，后续各章会详细展开。

• 在线推理负载（Inference）
  关注吞吐与尾延迟的矛盾、并发与显存行为、噪声邻居影响。代表如 vLLM 类服务（单实例/多实例，固定并发与请求分布）。

• 训练/微调负载（Training/Fine-tune）
  关注稳定吞吐、通信与拓扑约束、抢占/恢复成本。代表如 PyTorch 分布式或单机多卡作业。

• 干扰负载（Interference / Noisy Neighbor）
  用于可控制造资源争用（显存、带宽、SM、PCIe、CPU、IO），验证隔离/共享策略边界。代表如压力工具或自定义负载（需可开关、可调强度、可复现）。

关键：每次实验只允许“干扰负载强度”与“数据平面路径”变化，其他参数保持不变。

统一指标：把“体验”与“资源”放在同一张表里

所有实验至少收集三类指标，并按统一口径输出。

• 业务体验指标（面向用户/平台 SLA）
  吞吐（QPS / tokens/s）、时延（p50/p95/p99/p999）、首 token 时延（TTFT）、每 token 时延（TPOT）、错误率（超时、OOM、重试、失败比例）、稳定性（时延抖动、尾延迟放大倍数）。

• 资源行为指标（面向工程定位）
  GPU（SM 利用率、显存占用、显存带宽、功耗、时钟、温度）、互联（PCIe/NVLink 吞吐）、CPU/内存（CPU 利用率、内存占用、上下文切换、NUMA 远端访问）、调度与排队（Pending 时间、排队时长、重试次数、驱逐/抢占事件）。

• 隔离/干扰指标（面向"共享是否可控"） 干扰敏感度（引入同等强度噪声后，吞吐下降比例、p99 上升比例）、尾延迟放大（p99_with_noise / p99_baseline）、抖动窗口（长尾尖峰频率与持续时间）、资源争用证据（显存带宽/功耗/时钟下降与尾延迟尖峰的相关性）。

统一流程：每次实验都按同一张 checklist 走

建议将一次实验拆分为六个阶段，并每次都详细记录：

1. 准备（Prepare）
   清空历史 Pod/Job，确认节点与组件健康，无后台任务干扰。
2. 部署（Deploy）
   使用同一份 manifest，仅切换数据平面相关字段。
3. 预热（Warmup）
   固定时长或请求量预热，避免冷启动污染。
4. 采样（Run & Sample）
   固定运行时长（如 10–30 分钟）或请求量。
5. 收尾（Tear down）
   释放资源、导出日志与指标、记录异常事件。
6. 复位（Reset）
   若涉及 MIG/节点级变更，执行复位并记录耗时与风险点。

任何一次实验，只要"异常事件"没记录，就等于没做，因为无法解释离群点来源。

统一记录模板：让每次实验都像一次可审计的变更

建议每次实验输出两份记录：元数据卡片和结果摘要表，并将原始数据（监控导出、日志、配置）放到同一目录。

元数据卡片（Metadata Card）

• 实验编号
• 日期/时区
• 负责人
• 路径：共享 / MIG / HAMi
• 节点列表
• GPU 拓扑摘要
• 软件版本摘要
• 负载版本与参数
• 干扰负载：开/关 + 强度参数
• 运行时长
• 异常事件：OOM/重启/驱逐/超时/节点抖动等
• 备注

结果摘要表（Summary）

至少包含：

• 吞吐（中位数/分位数）
• p50/p95/p99/p999
• TTFT/TPOT（如适用）
• 错误率
• GPU 利用率/显存/功耗关键统计
• 干扰放大倍数（如开启噪声邻居）

模板统一后，“争论”会从观点变成证据，这正是平台工程所需的语言。

如何把实验结果变成“可验收”的平台指标

Hands-on 的终点不是论文式结论，而是平台可执行的验收标准。建议每章最后将结论落到三类验收：

• 功能验收：是否满足资源表达与调度正确性（能否分配、是否错分）。
• 性能验收：吞吐与时延是否达标（含尾延迟），并给出可重复的测试口径。
• 稳定性验收：引入噪声邻居后，尾延迟放大是否在阈值内，是否出现不可解释的抖动尖峰。

示例（阈值请按实际业务设定）：

• 固定并发下，p99 延迟 ≤ X ms；
• 开启噪声邻居（强度 Y）后，p99 放大倍数 ≤ Z；
• 资源回收/重调度的恢复时间 ≤ W 分钟。

本书 Hands-on 的章节组织方式

从下一章起，将以“控制面与数据平面解耦”为视角展开：

• 数据平面：MIG、HAMi —— 资源单位、隔离强度与共享边界
• 控制面：Volcano、Kueue —— 队列、配额、准入、策略与秩序
• 工作负载视角：vLLM、PyTorch、Ray/KubeRay —— 真实负载如何放大问题
• 组合架构：拼装数据平面与控制面，形成可交付能力，并给出验收与容量口径
• Labs：用统一模板复现关键结论，可作为平台验收的候选用例库

你应该从本章带走什么

• 一套只改变一个变量的对照实验方法
• 一份统一指标体系：体验指标 + 资源指标 + 干扰指标
• 一套统一记录模板，让结论可审计、可迁移、可验收
• 三条路径的清晰定位：共享 / MIG / HAMi 各自解决什么、牺牲什么

接下来进入 Lab 0：先用“无 MIG 的共享”跑出可复现的基线，再逐步引入 MIG 与 HAMi，观察隔离与共享如何在吞吐与尾延迟之间做权衡。

总结

本章系统梳理了 GPU 平台实验的统一设计方法，包括实验原则、环境记录、三条数据平面路径、统一负载与指标、标准化流程与记录模板，以及如何将实验结果转化为平台可验收标准。通过只改变一个变量、统一指标体系和记录模板，能够让实验结论具备可迁移性和可复现性，为后续章节的深入实验和平台建设打下坚实基础。