GPU 调度与优化

• Time-Slicing 原理
• 工程价值与适用场景
• 局限与权衡

GPU Time-Slicing 让多个 Pod 共享同一物理 GPU，通过时间片轮转执行（MPS 或时间切片），在 K8s 中由 NVIDIA GPU Operator 的 Device Plugin 支持，把一个 GPU 的 capacity 虚拟成多个 unit。工程价值：提高 GPU 利用率——把显存需求小的推理/开发任务共享到同一卡，减少闲置；降低门槛——让更多小任务能用上 GPU 而不必整卡占用；低成本尝试。局限：时间片共享无显存隔离，一个任务 OOM 会影响共享者；无硬隔离，性能受干扰。

Time-Slicing 的价值是"共享 GPU 提升利用率"，适合显存小、可容忍性能干扰的任务。但无显存隔离与性能隔离是短板，与 MIG（硬隔离）对比使用。运维上对高显存/强隔离需求用 MIG 或整卡，小任务用 Time-Slicing。

• Device Plugin 机制
• 显存分配方式
• 整卡/分片/MIG 实现

Device Plugin 是 K8s 的插件机制，让节点向调度器上报扩展资源（如 nvidia.com/gpu），并负责把 GPU 资源分配给容器。显存分配：整卡——Pod 请求 nvidia.com/gpu:1 独占整卡；分片——通过 GPU Operator 的 vGPU/Time-Slicing 把卡分成多个 unit；MIG——硬件级切分，卡被切成多个 MIG 实例，每个实例作为独立资源上报。调度器基于上报的 capacity 分配。实现依赖 Device Plugin 上报的资源类型与数量。

Device Plugin 是"GPU 资源进入 K8s 调度"的桥梁。整卡最直接，分片（Time-Slicing/vGPU）靠虚拟化，MIG 靠硬件切分。运维上根据负载需求选择分配方式，并监控显存分配与利用率。NVIDIA 的 Device Plugin 支持 MIG 与 Time-Slicing 配置。

• MIG 原理
• 工程价值
• 适用场景

MIG 是 A100/H100 等 Ampere/Hopper 架构 GPU 的硬件级切分能力，将一张 GPU 切成多个独立 MIG 实例，每个实例具有独立的计算单元、显存与带宽（硬件隔离）。工程价值：硬隔离——多任务互不干扰，OOM/性能不受影响；灵活分配——按需把大卡切成不同规格（如 7x1g、3x2g）服务不同负载；提升利用率——让多个小任务共享大卡而不互相干扰。适合多租户、小模型推理、隔离性要求高的场景。

MIG 的价值核心是"硬件隔离 + 灵活切分"。比 Time-Slicing（软共享）隔离性强，比整卡利用更高。适合多模型/多租户同时跑不同任务。局限：MIG 实例数有限、需特定卡支持、统一内存受限。运维上按负载需求规划 MIG 配置。

• MPS 原理
• 工程价值
• 局限

MPS（Multi-Process Service）是 NVIDIA 的机制，让多个 CUDA 进程共享一个 GPU 的计算上下文，通过合并/重叠计算提升利用率，并支持按比例限制共享（MPS 的并发限制）。工程价值：提升利用率——多个非全负载进程共享 GPU，减少空闲；降低单进程显存/上下文开销；支持并发控制（如限制并发 max 数）。适用：多个小任务共享 GPU、推理服务的多进程。局限：无硬隔离（一个进程崩溃可能影响共享者）、显存不隔离、需精细配置。

MPS 的价值是"软共享 + 并发提升"，比 Time-Slicing 更高效（合并计算），但隔离性弱。与 MIG（硬隔离）互补。运维上对多进程共享场景用 MPS 提利用率，重要任务用 MIG。MPS 需注意配置与稳定性。

• 两者定位
• 功能差异
• 选型

NVIDIA GPU Operator 是官方组件，提供 GPU Device Plugin、驱动、MIG、Time-Slicing、Monitoring 等基础能力，让 K8s 原生调度 GPU；Run:ai 是商用的 GPU 编排/调度平台，在 operator 之上提供更高级的 GPU 调度（动态切分、优先级、队列、多租户配额、DRF 公平调度、GPU pooling）、可视化与工作负载编排。差异：GPU Operator 是"底层使能"，Run:ai 是"上层调度治理"。选型：基础 GPU 支持用 GPU Operator；需要精细 GPU 调度、多租户配额、利用率优化用 Run:ai（或 vGPU）。

GPU Operator 解决"GPU 能不能用"（驱动、资源、监控），Run:ai 解决"GPU 怎么用好"（调度、配额、利用率）。选型看需求复杂度：简单场景 operator 足够，复杂多租户/利用率优化上 Run:ai。运维上两者可结合。

• vGPU 与 GPU Sharing 概念
• 工程价值
• 适用场景

GPU Sharing（GPU 共享）指多任务共享一张 GPU，vGPU 是把 GPU 虚拟化为多个虚拟 GPU 实例（如 NVIDIA 的 vGPU 方案或开源 k8s-device-plugin 的 GPU sharing）。工程价值：提升利用率——把闲置 GPU 容量分给多个小任务；降低门槛——小任务无需整卡；灵活分配——按显存/算力比例分配。vGPU 提供比纯 Time-Slicing 更可控的分配（指定显存大小）。适用：显存需求小、可容忍共享的推理/开发负载。

vGPU/GPU Sharing 的价值是"把 GPU 用满"，用虚拟化/device-plugin 把容量按需切分。比整卡利用高，比 MIG 灵活但隔离弱。运维上按负载显存需求分配，监控共享下的性能与隔离。相比 MIG（硬隔离）与 Time-Slicing（纯时间），vGPU 是"显存维度"的共享。

• 各通信库定位
• 网络适配差异
• 选型依据

NCCL 是 NVIDIA 的高性能 GPU 通信库（AllReduce 等集合通信），深度优化 NVLink/NVSwitch 与 InfiniBand/RoCE，是大模型训练/推理的主流；GLOO 是 PyTorch 的通用通信库，支持 CPU/GPU 与 TCP，但性能弱于 NCCL，适合 CPU 或小规模；RCCL 是 AMD 的 ROCm 通信库，对应 NCCL，用于 AMD GPU。网络差异：NCCL 在 NVLink（卡间）与 InfiniBand/RoCE（跨机）上最优，RCCL 对应 AMD 的 Infinity Fabric。选型：NVIDIA GPU 用 NCCL，AMD GPU 用 RCCL，跨 CPU/小规模用 GLOO。

通信库选型与硬件生态绑定：NVIDIA→NCCL，AMD→RCCL，通用→GLOO。NCCL 对 NVLink/IB/RoCE 的优化使其在大规模训练成为标配。运维上配置 NCCL 的通信拓扑（NVLink/IB）与网络（RoCE 拥塞控制）以保证性能。

• RDMA 与 RoCE/IB 差异
• 拥塞控制与参数
• 调优实践

RDMA 网络调优：RoCE v2 依赖以太网的 PFC（优先级流控）与 ECN（显式拥塞通知）实现无损/低损传输，需配置 PFC 队列、ECN 阈值、DCQCN 拥塞控制；InfiniBand 天然提供无损与拥塞控制，参数更少。调优点：MTU（大 MTU 提升吞吐）、NUMA 亲和（HCA 与 GPU 同 NUMA）、流量隔离（存储/计算分流）、bandwidth 测试（ib_write_bw）、NCCL 的算法与拓扑配置。目标：低延迟、高带宽、无拥塞丢包。

RoCE 调优复杂（依赖 PFC/ECN/DCQCN），IB 相对简单（硬件拥塞控制）。AI 集群网络是训练瓶颈，调优核心是"无损、低延迟、高带宽、NUMA 亲和"。运维上建立网络基准测试与监控，发现拥塞丢包即调优。

• CUDA Graph 收益
• stream 优先级
• cudaMallocAsync 显存管理

CUDA Graph 把内核序列捕获为图，减少启动开销，降低推理延迟与抖动（对短序列明显）；stream 优先级让关键计算（如 decode）优先于非关键任务，减少调度延迟；cudaMallocAsync 用异步内存池降低 cudaMalloc/cudaFree 的同步开销，提升显存分配效率。代价：CUDA Graph 需静态 shape 或捕获，动态 shape 受限；stream 优先级需精细设计；cudaMallocAsync 需管理池大小。收益在推理延迟与吞吐上，需实测。

这些是 CUDA 层的延迟优化，收益源于"减少启动开销、调度机会、同步开销"。推理服务中 CUDA Graph 常配合连续批处理（捕获固定 shape）。运维上通过 A/B 压测验证收益，注意动态 shape 兼容性。

• 存储层次差异
• 带宽/延迟梯度
• 算子优化意义

GPU 存储层次由快到慢：寄存器（最快）→ 共享内存（SM 内，快）→ L1/L2 缓存 → HBM 显存（最慢，带宽有限）。算术强度（compute:memory）决定性能瓶颈：数据复用度高用共享内存缓存，减少访问 HBM；FlashAttention 等算子通过把计算分块到共享内存，避免反复读写 HBM，显著提速。推理算子优化意义：提高数据局部性、减少 HBM 访问次数（HBM 带宽是瓶颈），用共享内存/寄存器做分块复用。

理解存储层次是优化的根本——HBM 带宽有限，推理瓶颈常在"内存带宽"而非算力。优化方向是"增加数据复用、减少 HBM 访问"。FlashAttention 是典型（分块到共享内存）。运维上选型/评估算子实现时关注其内存访问模式。

• 故障检测
• 隔离机制
• 自动重启

检测——用 DCGM 采集 GPU 健康指标（ECC 错误、温度、Xid 错误、功耗、利用率），检测到 ECC 不可纠正错误、Xid 错误、温度异常等即判定故障。隔离——故障 GPU 标记为不可调度（taint/device-plugin 剔除），摘除其上 Pod，避免继续分配。自动重启——Pod 重启/重调度到健康 GPU，节点故障 GPU 较多时剔除节点。结合健康检查（如 DCGM 暴露的 health）与自动处理（自愈）。设计上故障检测要快（分钟级）、隔离要及时、重启要自动并记录。

GPU 故障是 AI 集群常见问题，设计核心是"检测→隔离→重启"闭环。检测用 DCGM 硬件指标，隔离用调度器剔除，重启用 K8s 自愈。运维上监控故障率与恢复时长，区分可纠正（ECC 单次）与不可纠正（需更换）故障。

• 各加速单元用途
• 卸载策略
• 适用场景

Tensor Core 用于矩阵乘（GEMM）的混合精度加速，是 LLM 训练/推理的核心加速单元（FP16/BF16/FP8）；RT Core 用于光线追踪（图形渲染），与 AI 推理无关；稀疏计算单元加速稀疏矩阵运算（如 2:4 结构化稀疏），可减少计算量。卸载策略：训练/推理把矩阵乘运算落到 Tensor Core（用 FP16/FP8 混合精度）；稀疏模型用稀疏单元（需结构化稀疏权重）；RT Core 用于图形负载。运维上评估算子是否利用 Tensor Core（用 FP16）与稀疏化收益。

Tensor Core 是 AI 的核心加速单元，性能提升靠"混合精度 + 算子落到 Tensor Core"。稀疏化是额外收益（需模型支持）。RT Core 与 AI 无关。运维上优化精度策略（FP16/FP8）以利用 Tensor Core，稀疏模型评估稀疏单元收益。

• 各生态定位
• 生态成熟度
• 迁移成本

CUDA 是 NVIDIA 的闭源生态，抽象层次低、性能最强、生态最成熟（PyTorch/TensorFlow 深度优化），但仅 NVIDIA 可用；ROCm 是 AMD 的开源生态，API 类 CUDA，适配 AMD GPU，生态较新；SYCL 是跨厂商的开放标准（Kernel 用 C++ 写），抽象较高、可移植（support NVIDIA/AMD/Intel），但性能与生态弱于 CUDA；OpenCL 是通用开放标准，抽象高、可移植但性能与生态最弱。迁移成本：CUDA→ROCm 有工具（HIP）降低，→SYCL 需重写 kernel，CUDA 生态迁移成本最高（依赖 CUDA 库）。

选型是"性能 vs 可移植性"的权衡。CUDA 性能生态最优但绑定 NVIDIA；SYCL/OpenCL 可移植但性能弱；ROCm 面向 AMD。迁移成本与生态绑定度相关。运维上国产化/异构场景评估迁移成本，主流仍 CUDA。

• 三种方案特性
• 隔离性对比
• 选型依据

MIG：硬件级切分，隔离性最强（独立的计算/显存/带宽），性能有保证，调度上作为独立资源（每个 MIG 实例单独分配），适合多租户强隔离；MPS：软件共享，多进程并发计算，隔离性弱（一个进程崩溃影响他人），性能共享提升利用率，调度上整卡分配后多进程共享；Time-Slicing：时间片轮转，隔离性弱（无显存隔离），性能受干扰，调度上把卡虚拟成多个 unit。隔离性：MIG > MPS > Time-Slicing；性能保证：MIG > MPS > Time-Slicing；利用率：共享都提升。

三方案是"隔离性 vs 利用率"的权衡。MIG 隔离最强但实例数有限，MPS/Time-Slicing 提利用率但隔离弱。选型看需求：强隔离+性能保障用 MIG，提升利用率可容忍共享用 MPS/Time-Slicing。运维上按负载隔离需求选择。

• Ray 定位与价值
• Kubeflow 定位与价值
• 选型

Ray 是通用分布式计算框架，提供任务调度、Actor、分布式数据处理与 Ray Train（分布式训练）、Ray Serve（推理），灵活、弹性，适合训练/推理/调参一体化，生态（RLlib、Tune）丰富；Kubeflow 是 K8s 原生的 ML 平台，提供 Kubeflow Pipelines、Training Operator（TFJob/PyTorchJob）、Notebook、Katib（超参）、KFServing，端到端 ML 工作流，与 K8s 深度集成。价值：Ray 灵活高效做分布式训练/服务，Kubeflow 提供标准化 ML 平台与工作流编排。选型：快速分布式训练用 Ray，需完整 ML 平台/工作流用 Kubeflow。

Ray 偏"计算框架"（灵活、做训练/服务），Kubeflow 偏"平台/工作流"（K8s 原生、端到端）。二者可结合（Ray 跑在 Kubeflow 上）。运维上按团队需求选型：训练密集型用 Ray，平台化用 Kubeflow。

• 利用率度量指标
• 优化手段
• 平衡

度量：GPU 利用率（SM 利用率）、显存利用率、tokens/sec/GPU、吞吐与延迟。优化：batch——增大 batch 提升利用率（连续批处理），但受 KV cache 显存限制；KV cache——用 PagedAttention/前缀缓存降低 KV 占用，提升可承载并发；并发——提高并发序列数填满 GPU，但注意显存与延迟。优化目标是"高 SM 利用率 + 高 tokens/sec/GPU + 可接受延迟"。平衡并发/上下文/显存/延迟。

利用率优化的核心是"把 GPU 填满且高效产出"。batch、KV cache、并发三者联动：batch 受 KV cache 显存约束，KV cache 优化放大并发，并发提升利用率。运维上用 tokens/sec/GPU 与 SM 利用率评估，调 vLLM 参数（max_num_seqs、gpu-memory-utilization）。

• 各框架定位
• 并行策略
• 选型

DeepSpeed（微软）提供 ZeRO（Zero Redundancy Optimizer）优化，解决大模型显存不足，支持 ZeRO-1/2/3、Offload、并行策略，是与 PyTorch 集成的优化库；Megatron（NVIDIA）提供张量并行（Tensor Parallelism）与流水线并行（Pipeline Parallelism），适合超大模型、与 DeepSpeed 结合（Megatron-DeepSpeed）；FSDP（PyTorch 的原生 Fully Sharded Data Parallel）把参数/梯度/优化器状态分片，易用、与 PyTorch 集成好。价值：三者都解决"模型太大放不下"——ZeRO/FSDP 分片优化器状态，Megatron 做张量/流水线并行。选型：PyTorch 生态用 FSDP，需要极致优化/超大模型用 DeepSpeed+Megatron。

三者是"显存分片 + 并行"的分布式训练方案。FSDP 易用原生，DeepSpeed 功能全（ZeRO+Offload），Megatron 适合超大模型张量/流水线并行。运维上按模型规模与生态选型，配合集群网络（NCCL/IB）。

• 异构 GPU 识别
• 混部调度
• 优先级设计

异构 GPU 混部调度：用标签/资源区分 GPU 类型（nvidia.com/gpu 与国产 GPU 的 vendor 资源），调度器按任务需求选择匹配的 GPU（如大模型用 H100、小任务用 A100/国产）。优先级设计：任务按优先级（如 SLA、离线/在线）排队，高优先级先调度；用 GPU 资源配额（namespace 级）与抢占（preemption）保证关键任务。异构混部需处理：不同 GPU 的性能差异（避免慢卡拖累）、驱动/生态差异（国产 GPU 需适配）、通信差异（跨厂商）。运维上建立 GPU 池分类与优先级队列。

异构混部的核心是"按需匹配 + 优先级保障"。用标签区分 GPU 类型，调度器按任务需求匹配，优先级队列保关键任务。挑战是性能差异与生态适配。运维上按 GPU 类型建池、配额隔离、优先级调度。