GPU资源池化与异构调度：实验室AI算力集群搭建实践

1. 实验室GPU的真实处境：算力蛮荒与资源孤岛

我们这个项目叫NebulaGrid，起因其实是实验室里一件再普通不过的事：组里陆陆续续攒了二十多张不同型号的卡，分布在四五台机器上，有人用PyTorch跑训练，有人用vLLM起推理服务，还有人拿ComfyUI做生成实验。表面上硬件不少，实际用起来却特别别扭。

最典型的场景是这样的：A同学在跑一个微调任务，把一张卡的显存占满了，但GPU利用率只有30%左右；B同学想跑实验，发现手头那张卡被占了，只能排队等。与此同时，另一台机器上的两张卡可能已经连续几天没人碰过，风扇都不转。你说把任务迁过去？迁移环境要半天，数据要拷，CUDA版本还对不上，最后大家宁可排队也不折腾。

1.1 我们实验室踩到的三个现实问题

第一个问题是发现难。每台机器上到底有没有空闲卡、显存还剩多少、算力是否紧张，全靠群里的口头询问和一张手写的Excel表。等你去确认的时候，状态早就变了。

第二个问题是共享难。一张24GB显存的卡跑一个显存只要8GB的小模型，剩下16GB就白瞎了。Grid上的任务调度器通常按整卡分配，或者靠人工手动设置CUDA_VISIBLE_DEVICES来切分，没有统一机制。时间一长，资源的浪费是肉眼可见的。

第三个问题是环境隔离难。同一个CUDA版本、同一个PyTorch版本要同时满足训练、推理、生成类任务，几乎不可能。每个人都在自己的conda环境里折腾，一旦涉及到不同容器或不同驱动版本，场面就比较混乱。

1.2 单机多卡与多机多卡的本质差异

很多人觉得，把几台机器用网线连起来，装个分布式训练框架，就算"集群"了。这是对计算集群非常普遍的误解。

单机多卡的时候，GPU之间的数据交换走的是NVLink或PCIe，带宽从几十GB/s到几百GB/s不等。多机多卡一上网络，交换带宽直接掉到万兆网卡的1.25GB/s甚至千兆的0.125GB/s数量级，完全是另一个量级。这意味着做集群调度时，不能只考虑"哪张卡有空"，还得考虑通信拓扑。

NebulaGrid最开始设计时，我就想清楚了一件事：我们不是要做一个功能完整的超算调度平台，而是要解决实验室场景里"把闲置算力用起来、把异构环境管起来、把分布式训练跑起来"这三个实际问题。这也是整个项目所有技术决策的出发点。

1.3 NebulaGrid要解决的核心矛盾

实验室集群和大型数据中心有一个本质区别：数据中心追求的是极致的资源利用率，而实验室更看重灵活、好用、能折腾。所以NebulaGrid从第一天起就定了几条原则：

• 不强制用容器跑所有任务。你有conda环境，直接提交python train.py也行。
• 不追求把所有GPU虚拟化成细小切片。显存小于4GB的碎片宁可不用，也不硬切，因为日常训练任务根本用不上。
• 调度延迟不能高。一个微调任务从提交到开始跑，两分钟内算正常，超过五分钟基本没人愿意用。
• 用户上手成本要低。只要会写一行nebula-ctl submit就能用，不需要理解K8s那一套复杂概念。

项目名字叫NebulaGrid，是"星云网格"的意思。GPU分布在多台机器上，像星云一样离散，但通过网格化的调度让它有统一的对外形态。核心思路可以概括为一句话：用控制面把异构算力聚合成虚拟资源池，按任务实际需求做动态分配，让实验室里的每块GPU都真正流动起来。

2. NebulaGrid的整体架构：把"设备"变成"资源池"

NebulaGrid的架构并不复杂，核心分三层：节点代理层、调度控制层、用户入口层。三层各司其职，组成一个逻辑闭环。

2.1 控制面与数据面的划分

最早做技术选型时，我考虑过两条路：一是完全自研一套调度系统，二是站在K8s生态上做扩展。最后选了后者，但做了一层很关键的抽象。原因很简单：实验室集群的节点变动频繁，今天加一张卡，明天挪一台机器，如果用自研方案，节点注册、状态同步、失败重试这一套全要自己写，工作量巨大且容易出bug。K8s天然提供了节点管理、状态同步和声明式API的能力，我只需要把精力集中在GPU资源模型上。

NebulaGrid的节点代理跑在每台GPU服务器上，负责三件事：收集GPU的实时状态（利用率、显存、温度、功耗、NVML事件）、执行调度器下发的任务拉起指令、上报任务运行日志。

控制面（调度器）是整个系统的核心，维护了全局资源视图，接收用户提交的任务，进行资源匹配、调度决策、任务生命周期管理。用户侧则是命令行工具nebula-ctl，负责提交任务、查询状态、查看日志。

2.2 资源池的核心模型：以"切片"为单位的GPU资源描述

NebulaGrid里最核心的数据结构是GPU切片（Slice）描述。每张物理GPU进入集群后，会先做一次"画像"，生成一个JSON描述：

{ "uuid": "gpu-7ab3c91d", "node": "node03", "model": "NVIDIA GeForce RTX 4090", "total_memory_mb": 24564, "compute_capability": "8.9", "pci_bus_id": "0000:3b:00.0", "nvlink": false, "status": "idle", "slices": [ { "id": "s-0001", "memory_mb": 8192, "state": "free" }, { "id": "s-0002", "memory_mb": 8192, "state": "free" }, { "id": "s-0003", "memory_mb": 8192, "state": "free" } ] }

这里有一个关键设计：切片不是物理划分，而是逻辑上的划分。显存是GPU上最硬性的资源约束，所以我选择了按显存切；算力（SM数量）通常不硬切，因为MPS（Multi-Process Service）或时间片切分的开销和复杂度都不低，在实验室场景下性价比不高。

用户提交任务时声明需要的显存量：

nebula-ctl submit --gpu-mem 8G --gpu-count 2 -- python train.py

调度器会在全局资源视图里找满足条件的空闲切片组合，然后分配。如果不满足就进入等待队列，并在任务信息里注明缺少什么资源，用户能直观看到。

2.3 为什么选K8s生态而不是自研调度器

为了给不同GPU虚拟化方案留出扩展接口，NebulaGrid的资源模型基于K8s的Extended Resource机制实现。熟悉K8s的人知道，默认不支持将GPU作为可调度资源，因为GPU抽象太特殊。NVIDIA官方有device plugin方案，但那种方案有一个对实验室场景极不友好的点：默认只能整卡分配。

NebulaGrid写了一个自定义的device plugin，把每张卡注册成带显存属性的Extended Resource。同时在调度器里实现了一个预选和优选策略，预选阶段根据显存需求过滤掉不满足条件的节点，优选阶段根据卡片的当前负载、温度、PCIe位置打分。权重最高的是"温度低且负载轻"，因为同型号卡在满载时核心频率会降，用温度低的卡往往实际训练速度更快。

提示：节点上跑NebulaGrid的Agent，都需要额外开启GPU拓扑感知模式，否则两张卡明明在同一个PCIe Switch下可能被当成普通网络邻居处理，导致多卡任务出现不必要的数据传输开销。

3. 异构GPU纳管：从NVIDIA到Intel再到昇腾的接入实践

实验室的现实是：不可能全部清一色用同品牌同型号GPU。我们集群里就混杂着NVIDIA RTX 4060 Laptop GPU、RTX 4090、Intel核显、甚至还有一块昇腾卡。NebulaGrid如果只支持NVIDIA，那就解决不了实际问题。

3.1 统一硬件抽象层：NVML、zesapi与ACL的封装

NVIDIA卡的状态获取走NVML（NVIDIA Management Library），Intel GPU走Level Zero（通过zesapi接口），昇腾则通过ACL（Ascend Computing Language）暴露能力。三种接口的侧重点差异很大：

能力项	NVIDIA（NVML）	Intel（Level Zero）	昇腾（ACL）
显存状态	支持	支持	支持
利用率	支持	支持，粒度较粗	支持
温度/功耗	支持	部分型号支持	支持
进程级追踪	支持	有限	有限
资源虚拟化	vGPU/MPS	无统一方案	昇腾有自己的方案

所以Agent内部实现了一个HardwareBackend接口，每种卡写一个Backend。核心抽象是四个方法：GetStatus()、GetProcessList()、Initialize()、Cleanup()。

写Intel GPU Backend是常见的难点。当时我发现zesapi取利用率时会偶发返回一个极大值（比如200%），后来排查确认是驱动版本对某些频率档位的解析异常。这类问题只能靠在实际节点上反复压测来踩平，文档里基本找不到答案。

3.2 驱动兼容性排查：4060 Laptop、5070 Laptop与新老CUDA的坑

异构纳管最难的不是代码，而是驱动兼容。我在部署过程中遇到的一个典型问题是RTX 4060 Laptop GPU在Windows节点上的错误代码43。这块卡在设备管理器里直接就报错不可用，Agent探活时始终拿不到实际显存。

排查下来原因很典型：NVIDIA驱动在Windows上有时会因为TCC模式（Tesla Compute Cluster）和WDDM模式（Windows Display Driver Model）切换不彻底，导致显卡核心与驱动通信异常。解决方法是进NVIDIA控制面板把该GPU的Compute Mode从"默认"切换为"仅计算"，然后完全卸载驱动后重装Studio版驱动。这个坑在台式卡上不常见，但在笔记本卡的实验室场景里出现频率极高，因为笔记本GPU经常要被Display输出占用，WDDM模式下显存分配和计算模式差异很大。

另外还遇到过RTX 5070 Laptop GPU的CUDA兼容问题——卡的Compute Capability是sm_120，但节点上的CUDA Toolkit还是11.x，跑任何PyTorch版本都会报"not compatible"。这种问题跟NebulaGrid本身无关，但Agent在调度时会通过nvidia-smi --query-gpu=compute_cap拿到能力值，把它作为注册信息的一部分。这样用户提交任务时如果指定了CUDA版本，调度器能自动过滤掉跑不了的节点。

3.3 节点代理Agent的探活与心跳设计

Agent的探活逻辑是NebulaGrid稳定性的关键。GPU是很敏感的硬件，一个不稳定的探活机制会造成两种恶果：要么漏报（卡已经挂了还继续分配任务），要么误报（卡活着但被标记为不可用，白白浪费资源）。

我们最终采用了两级探活机制。第一级是常规心跳，每5秒上报一次/healthz，如果连续三次没有响应，控制面标记该节点为Unknown，暂时不分配新任务，但不回收已运行的任务。第二级是NVML事件监听，然后结合xid错误事件来判断GPU是否真的发生了硬件级故障。

XID错误是NVIDIA驱动上报给操作系统的错误码，常见的包括：

XID错误码	常见含义	处理策略
79	GPU has fallen off the bus	节点隔离，人工介入
43	驱动与设备通信异常	尝试复位一次
13	显存ECC错误	记录日志并触发GPU内存自检
31	程序非法访问显存	记录任务日志，任务失败但不隔离

如果检测到xid 79，Agent会主动把GPU标记为MaintenanceNeeded，NebulaGrid控制面会把已分配到该GPU的任务平滑迁移或重启后重新调度。

有一个很坑的细节：某些情况下xid 79并不代表硬件故障，而是PCIe链路瞬时抖动。直接隔离会误伤，我们加了"短期内连续两次才隔离"的策略，实测能把误隔离率降低约七成。

4. 调度器设计：从排队到拓扑感知分配

NebulaGrid的调度器是Python写的，采用了"事件驱动+周期扫描"混合模式。用户提交任务的时间点不可预测，所以我用事件驱动保证低延迟；但为了处理节点掉线、GPU释放等异步事件，又保留了一个3秒一次的定时扫描循环做兜底。

4.1 任务排队的公平性策略

调度器刚上线时，团队几个人都优先提交自己的任务，队列里的任务权重全靠抢占，很快就有人不满。后来引入了简单但实用的加权公平队列：

• 每个用户有一个初始权重1.0。
• 每完成一个任务，用户的实际权重加上0.1；每长时间占用资源，实际权重加上0.02/小时。
• 排队时按实际权重降序排列，权重低的人优先被调度。

这个策略本质上偏向"一直在线等待的人"，而不是"一口气提交很多任务的人"。训练场景下，任务时常跑十几个小时，如果某个人连续提交大批任务，他的权重增长是线性的，随着时间推移会自然让位给其他用户。

4.2 显存切片与算力分配的取舍

NebulaGrid的显存辅助切割逻辑在实验场景下需要额外谨慎。单一物理GPU上最多切成4个逻辑切片。为什么不是更多？因为切片越多，PCIe带宽竞争越激烈，而且显存虽被切了，SM和L2 Cache仍然是整个GPU共享的。一个训练任务如果占用了12GB显存但只用了10%的SM，另一个任务用剩下2GB显存却要把SM拉满，两者都会受影响。

实际使用里，我们对--gpu-mem参数做了归一化处理：如果请求的显存超过单卡物理容量的一半，调度器默认按整卡分配；如果小于一半，才会考虑切片共存。这也是为了避免"显存看起来够用，但性能互相干扰严重"的情况。

4.3 PCIe/NVLink拓扑感知的分配逻辑

前面提到多卡通信的重要性。NebulaGrid启动时会扫描每台机器上GPU之间的nvidia-smi topo -m信息，构建一张拓扑图。调度时优先选择满足以下条件的组合：

1. 同一个PCIe Switch下的卡，优先于跨Switch的卡。
2. 有NVLink连接的卡，优先于只有PCIe连接的卡。
3. 同型号的卡，优先于混合型号的卡。

这一步原因很直接：异构卡混跑分布式训练时，通信速度会被最慢的那张卡的接口带宽拖住。比如一张4090接到PCIe 4.0 x16，另一张4060 Laptop走的是PCIe 4.0 x8，两者做AllReduce时，实际吞吐会被限制在x8带宽附近。

如果你用NebulaGrid跑torchrun，调度器会自动生成一组NCCL_SOCKET_IFNAME和NCCL_IB_DISABLE=1的环境变量注入到任务进程里，避免NCCL选错网络接口。

5. 任务提交实战：从小模型微调到vLLM服务化部署

架构和调度说了一堆，最终用户感受到的其实只有命令行那几个子命令。下面写一下日常最常用的操作流程，让大家感受下NebulaGrid用起来是什么样的。

5.1 命令行工具与SDK的用法

首次使用先注册集群访问凭证：

nebula-ctl login --endpoint https://nebula-grid.lab.local --token xxxxx

然后查看集群的全局资源情况：

nebula-ctl status Cluster Overview: Nodes: 5 GPUs: 19 (12 idle, 5 busy, 2 maintenance) Total VRAM: 398 GB (free: 214 GB) Node Details: node01: RTX 4090 x2, RTX 4060 Laptop x1, load 42% node02: Intel Arc A770 x1, load 10% ...

这个视图很重要，它直接解决了"发现难"的问题。用户不再需要问别人"哪张卡空闲"，看一眼输出心里就有数。

提交训练任务时，用--gpu-count指定卡数，用--gpu-mem指定单卡显存需求：

nebula-ctl submit \ --name "llama-ft-001" \ --image pytorch/pytorch:2.1.0-cuda12.1-cudnn8 \ --gpu-count 2 \ --gpu-mem 24G \ --workdir /workspace \ --command "python train.py --config configs/llama-ft.yaml" \ --data-mount /data/llama-dataset:/workspace/data

这里要注意--gpu-mem和--gpu-count是协调工作的：如果你指定了--gpu-count 4，调度器会自动在各节点之间搜索4张显存均大于等于24GB的卡，然后按拓扑优先级排序返回分配结果；如果找不到满足条件组合，任务会进入Waiting状态并提示缺什么资源。

5.2 PyTorch训练任务的接入改造

用NebulaGrid跑单卡任务，几乎不需要改代码。任务进程启动后能看到一个自动注入的环境变量NEBULA_GPU_LIST，里面是按调度结果排列的GPU UUID列表：

echo $NEBULA_GPU_LIST gpu-7ab3c91d,gpu-8f2ae813

PyTorch侧只需要把可见设备设置成对应的CUDA index序列即可：

import os import torch gpu_ids = os.environ.get("NEBULA_GPU_LIST", "").split(",") if not gpu_ids: raise RuntimeError("No GPU assigned by NebulaGrid") # 映射到CUDA visible devices os.environ["CUDA_DEVICE_ORDER"] = "PCI_BUS_ID" os.environ["CUDA_VISIBLE_DEVICES"] = ",".join( [f"{uuid_to_index[g]}" for g in gpu_ids] ) device = torch.device("cuda" if torch.cuda.is_available() else "cpu") print(f"Using {torch.cuda.device_count()} GPUs: {torch.cuda.get_device_name(0)}")

多机任务时，NebulaGrid还会自动生成torchrun需要的--master_addr、--master_port、--nnodes等参数。关键点在于：MASTER_ADDR是调度器在任务之间建立的内网地址，不需要用户自己手动去查IP。

我测试下来感受比较深的是：接入改造不应该让用户去适配调度器，而是调度器去适配用户的习惯。大部分PyTorch训练代码对分布式部分是不关心的，NebulaGrid要做的是提供一个合理的默认值。

5.3 推理服务与训练任务混合调度的资源隔离

推理服务和训练任务的资源模型完全不同。训练是短期高强度占用，推理是长期稳定低延迟。NebulaGrid为推理服务设置了"最小显存预留"策略：为每个vLLM服务保留至少2GB显存作为KV Cache的余量，且不允许训练任务把推理服务的卡整卡抢走。

实际压测过的场景：一张A100 80GB上跑一个7B量级的vLLM服务，设置max_num_seqs=32，KV Cache约占20GB。剩余60GB可以再起一个显存需求较小的微调任务，两者并发时，vLLM的TTFT（首Token延迟）波动实测在10%以内，这在实验室场景完全可以接受。

6. 可观测性与故障自愈：GPU Crash不只靠人肉盯

实验室里显卡出故障的频率，比大多数人想的要高得多。尤其是并行跑多个任务时，显存ECC错误、掉卡、驱动崩溃，各种奇怪现象都冒出来。

6.1 硬件层监控：温度、频率、掉卡事件

NebulaGrid的节点Agent默认每30秒采集一次温度、利用率、显存占用、功耗、风扇转速、核心/显存频率。这些数据直接写入时序数据库，并在Web面板上画曲线。

监控指标里有一个经常被忽略但非常关键的参数：核心频率。如果你发现GPU利用率不高但温度很高（比如75度以上），同时核心频率掉到了基础频率以下，大概率是散热或供电不稳。NebulaGrid的调度器会把这种情况视为一次"潜在降频事件"，写入节点的健康评分。长期健康评分过低的节点，在调度优选阶段会被扣分，逐渐减少其承接新任务的概率。

现场还遇到过一次很典型的故障排查：某节点上的卡利用率固定在97%但loss曲线一直在震荡，查监控发现显存频率始终在405MHz上不去，而正常卡应该在5001MHz左右。后来定位到原因是显卡的电源管理策略被驱动锁成了低功耗模式，用nvidia-smi -pm 1强制持久化模式后恢复。这类问题不监控频率曲线的话，只看利用率很容易漏掉。

6.2 日志与指标链路：从XID事件到自动隔离节点

NebulaGrid把故障处理设计成了流水线，核心思路是"让机器先处理，人再复查"。

1. Agent通过NVML监听XID事件，同时解析dmesg里的NVRM错误日志。
2. 一旦发现xid 79或xid 13这类明确故障码，立刻给GPU打上HealthCheckFailed标签。
3. 控制面发送一个"隔离请求"给节点，节点上的任务管理器把该GPU上正在运行的进程发SIGTERM信号，然后重新调度。
4. 隔离之后，Agent自动跑一轮显存自检和温度循环测试，全部通过后恢复可用。

这里有一个实际执行的细节：直接给进程发SIGTERM可能会导致训练状态丢失，用户会不满。所以NebulaGrid默认先发SIGUSR1，给任务进程里的信号处理钩子一点时间保存checkpoint，如果15秒内没有正常退出，再升级为SIGKILL。

很多调度系统做"自动隔离"时都太过粗暴，NebulaGrid的妥协是：宁可多等15秒，也要尽量保住任务的现场。这对做科研的人来说非常重要，因为这个机制能有效避免因硬件不稳定而浪费十几个小时的训练进度。

6.3 用户视角的配额与账单

实验室场景通常不涉及真实计费，但如果你管理着一批不自律的用户，配额机制还是很有用的。NebulaGrid的配额模型参考了核时的概念——定义成"GPU卡时"（GPU-hour），以"整卡小时数"为单位。

每个用户默认配额是2000 GPU-hours/月，超了就不能再提交新任务，需要管理员手动审批扩容。这套机制上线之后，集群资源的整体利用率从40%左右提到了70%以上，有几个原因：

• 用户会主动清理不再使用的僵尸任务。
• 调试任务大家更倾向于先用CPU跑通，再提交GPU。
• 用户对"资源是稀缺的"有了直观感受，不再无限地驻留任务。

7. 部署实录与避坑清单

最后一部分，讲讲从零开始搭NebulaGrid的实际步骤、踩过的坑和一些能让部署少走弯路的建议。

7.1 从零搭建NebulaGrid的最小集群

如果你也想在实验室里搭这样一个GPU集群，最小规模是三台机器：一台作为控制面（不需要GPU，2核4GB内存就够），两台作为计算节点。我们在实测环境下用了一台4核8GB的旧服务器跑控制面，完全够用，控制面不是性能瓶颈。

搭建步骤大致如下：

1. 每台计算节点上安装NVIDIA驱动（如果跨品牌，还需要装对应的Intel/昇腾驱动），确认nvidia-smi输出正常。
2. 在控制面上安装K8s（可以用kubeadm最简配置），然后安装NebulaGrid的controller和scheduler组件。
3. 每台计算节点上运行Agent安装脚本：

curl -fsSL https://nebula-grid.example.com/install.sh | sudo bash -s -- \ --controller-endpoint https://nebula-grid.example.com \ --token xxxxx

4. 执行nebula-ctl node add注册节点，再执行nebula-ctl status确认所有GPU已被纳管。
5. 从一台GPU机器上运行一次冒烟测试：

nebula-ctl submit --gpu-mem 4G --command "nvidia-smi"

等两分钟，看任务日志里能否正常打印显卡信息，能打印就说明链路是通的。

部署过程中最实用的建议：先把Agent部署到一台"备用"机器上，不要一上来就接生产卡。因为Agent和驱动的兼容性问题（尤其是不同驱动版本的NVML API差异）是部署时最容易出错的地方，先用闲置卡调试能避免影响正常使用。

7.2 踩坑实录：错误代码43、xid 79、SM_120不兼容

这三个问题在热搜词里出现了，我也确实都在实际部署中分别遇到过，重点展开说一下排查思路。

错误代码43：主要在Windows节点上遇到，表现为NVIDIA控制面板里GPU显示黄色感叹号，设备状态代码43。核心排查步骤：

1. 看Windows事件查看器里NVIDIA相关的错误日志，确认是驱动版本问题还是硬件冲突。
2. 把GPU从"同时负责显示输出"改成"仅计算模式"，可以绕过WDDM的部分限制。
3. 完全卸载驱动后用DDU（Display Driver Uninstaller）清干净，再安装Studio版驱动。

这一步的关键不是"装哪个版本驱动"，而是理解43的本质是"驱动已经加载但无法正常与该设备通信"。只要驱动版本和GPU架构有代差，这个问题就会出现。NebulaGrid的Agent在Windows节点上默认禁用TCC模式检测，因为实验室里很多Windows机器还要同时做显示输出，强制切TCC会导致显示器黑屏。

xid 79：这个我在前面已经提过。实际场景里它并不总是硬件故障，偶尔是电源管理导致的PCIe链路瞬时中断。我们的排查思路是：

1. 检查dmesg里是否伴随有NVRM: GPU at PCI:0000:3b:00.0 has fallen off the bus的记录。
2. 看同一时间节点的电源日志，确认是否有瞬时过流保护触发。
3. 如果短时间内只出现一次且后续自检通过，可以标记为瞬态事件，不隔离。连续出现两次，则必须隔离并检查物理插槽和电源线。

SM_120不兼容：这是比较新出现的问题。RTX 50系显卡的架构（Blackwell）计算能力是sm_120，但很多现有的PyTorch wheel还停留在适配sm_90（Hopper）甚至sm_86（Ampere）的阶段。如果你的任务使用了编译期的cuda extension（比如某些自定义算子），老版本工具链编译出来的二进制是跑不起来的。

在NebulaGrid里，调度器通过注册信息知道哪张卡是sm_120，哪张是sm_89，然后在任务描述里加上--arch参数做过滤。对用户来说，提交任务时显式指定--arch sm_120能有效避免被调度到不支持该架构的节点上。

7.3 与K8s原生device plugin / HAMI虚拟化方案的对比

很多人会问：既然NebulaGrid基于K8s，为什么不直接用NVIDIA官方device plugin，或者上HAMI这样的GPU虚拟化方案？我在这里做个简单的对比：

方案	对实验室的友好度	主要问题
NVIDIA官方device plugin	低	默认整卡分配，无法切分显存
K8s + HAMI虚拟化	中	功能强，但调度策略偏数据中心，学习成本高
NebulaGrid	高	侧重于实验室场景的易用性和容错性

NebulaGrid核心的问题是它把GPU的资源分成"整卡、切片、多卡"三种粒度，并将对用户隐藏了大部分底层概念。HAMI这类专业虚拟化方案确实更强大，但对一个只有几台机器、几十个用户的实验室来说，运维成本偏高。NebulaGrid的定位就是在"够用"和"好用"之间取一个平衡。

不过我也坦诚地讲，NebulaGrid并非适合所有场景。如果你的实验室要做大规模推理服务，每天几千个请求量，那GPU虚拟化的精细程度直接决定成本，你应该选择HAMI或专业的vGPU方案，而不是用NebulaGrid。它解决的是"如何让GPU利用率合理提升"的问题，不是"如何把每一块GPU的价值榨干"的问题。

最后说两句实在话

项目跑了大半年，我最深的体会是：实验室GPU集群的核心难点，从来不是调度算法有多巧妙，而是如何让每个环节都符合实验室人的使用习惯。

说实话，让实验室里的一堆异构GPU真正变成"一个可以随时提交任务的集群"，NebulaGrid用了并不复杂的架构和算法。深度学习、CUDA、PyTorch这些重框架底层，往往在很多细节上会超出你的预期——比如一张显卡在长期低负载下会进入P8状态，唤醒到P0需要几百毫秒，如果调度器在任务启动时不做预热，整体启动时间会莫名其妙多出好几秒。后来我们在任务拉起过程中加了一步轻量级的显存预申请，实测效果很好。

我还想提醒一点：给GPU集群做监控时，"温度"是最应该关注的指标之一——它比利用率更早反映一个节点的健康状态。有两次节点上的卡片长期满载跑训练，感觉利用率都正常，但温度曲线持续爬升，最终任务训练速度骤降。温度监控帮我们提前做了干预。

如果你想在自己的实验室里复刻类似的东西，我建议从最小闭环开始：先把所有GPU的实时状态汇总到一个页面（哪怕只是用一个脚本轮询nvidia-smi写入数据库），再考虑调度。资源可见是资源调度的前提，也是所有优化的起点。

NebulaGrid还在持续演进。目前的方向是让调度器更好地感知GPU的实时功耗和温度，在任务分配时自动做"功耗均衡"，避免多卡任务全挤在同一台电源负载较高的节点上。这个功能做完之后，再分享更详细的路由与调优策略。