AI 研究的门槛正在被算力成本重新定义。当工业界动辄囤积上万块 H100 组建集群时，高校实验室却常常为几块 A100 的租用费精打细算。5 月 13 日路透社报道的一笔捐赠，直接把这个问题推到了台前：黄仁勋与妻子 Lori 共同创立的慈善基金会，向 GPU 云服务商 CoreWeave 购买了价值 1.083 亿美元的 AI 算力，捐赠给大学和非营利研究机构。这是该基金会迄今最大规模的公开捐赠，也是少见的"捐算力而非捐现金"模式。
CoreWeave：从以太矿场到 GPU 云
CoreWeave 2017 年成立，起步于以太坊挖矿的 GPU 集群运营。加密货币热度退潮后，团队把同一批基础设施转向了 AI 训练和推理市场。它的差异化定位很明确——只做 GPU 密集型工作负载，不做通用云。
这意味着几件事：
- 裸金属 GPU 实例：用户可以直接拿到整块 GPU，没有虚拟化层的性能损耗，适合大模型训练的显存和带宽需求。
- Kubernetes 原生调度：CoreWeave 的底层编排基于 K8s，研究者可以用标准的 Pod / Job 描述文件提交任务，不需要学一套新 API。
- 网络与存储配套：RDMA 高速互联、NVMe 本地缓存、对象存储，这些在通用云上往往要额外配置，在 GPU 专用云上默认提供。
对高校研究者来说，这套架构的好处是：拿到算力后不需要从零搭建集群运维，用熟悉的 K8s 工具链就能跑实验。
捐算力而非捐现金：为什么这个路径不同
传统基金会向高校捐赠，走的是现金→设备采购→部署的路线。周期长、议价空间有限，而且设备到手后折旧和维护成本全靠学校自己扛。
黄仁勋基金会这次选择了另一条路：直接向云服务商购买算力额度，再把额度分配给受捐方。相当于把"买服务器"变成了"买服务"。对研究者而言：
- 即时可用：拿到额度后几小时内就能启动 GPU 实例，不用等采购审批和机房上架。
- 弹性伸缩：小实验用 1 块 GPU，大训练拉 32 块，用完即释放，不需要为峰值配置常驻硬件。
- 版本跟随：云平台会持续更新 GPU 型号（A100 → H100 → B200），研究者不会被困在旧硬件上。
但这条路也有代价——算力额度有有效期，用不完就作废；云服务的单价长期累加可能高于自建；数据出境和合规问题对国内高校尤其敏感。
实践：拿到 GPU 云额度后怎么跑起第一个训练任务
假设你的实验室刚获得一批 GPU 云算力额度，下面展示如何用 Kubernetes Job 描述文件提交一个 PyTorch 分布式训练任务。这段 YAML 和脚本适用于 CoreWeave 及任何 K8s 原生 GPU 云平台。
第一步：编写训练脚本 train.py
import os
import torch
import torch.nn as nn
import torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
def setup():
# K8s 会注入 WORLD_SIZE 与 RANK 环境变量
rank = int(os.environ.get("RANK", 0))
world_size = int(os.environ.get("WORLD_SIZE", 1))
dist.init_process_group("nccl", rank=rank, world_size=world_size)
torch.cuda.set_device(rank)
def cleanup():
dist.destroy_process_group()
def main():
setup()
# 示例：一个简单的分类模型，实际替换为你的研究模型
model = nn.Sequential(
nn.Linear(1024, 512),
nn.ReLU(),
nn.Linear(512, 10)
).to(torch.cuda.current_device())
model = DDP(model, device_ids=[torch.cuda.current_device()])
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)
# 模拟 1000 步训练——替换为真实数据加载
for step in range(1000):
x = torch.randn(64, 1024, device=torch.cuda.current_device())
y = torch.randint(0, 10, (64,), device=torch.cuda.current_device())
loss = nn.CrossEntropyLoss()(model(x), y)
optimizer.zero_grad()
loss.backward()
optimizer.step()
if step % 100 == 0 and dist.get_rank() == 0:
print(f"step {step} loss={loss.item():.4f}")
cleanup()
if __name__ == "__main__":
main()
第二步：编写 Kubernetes Job YAML gpu-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: ddp-training-demo
spec:
# 多副本对应多块 GPU
completions: 4
parallelism: 4
template:
metadata:
labels:
app: ddp-training
spec:
restartPolicy: OnFailure
# 关键：请求 GPU 资源
containers:
- name: trainer
image: pytorch/pytorch:2.4.0-cuda12.4-cudnn9-runtime
command:
- python
- train.py
resources:
limits:
nvidia.com/gpu: 1 # 每个 Pod 占一块 GPU
requests:
nvidia.com/gpu: 1
cpu: "8"
memory: "32Gi"
env:
- name: MASTER_ADDR
value: "ddp-training-demo-master"
- name: MASTER_PORT
value: "29500"
- name: WORLD_SIZE
value: "4"
- name: RANK
valueFrom:
fieldRef:
fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index']
第三步：提交任务
# 先把训练脚本打包进镜像，或用 initContainer 拉取
# 最简方式：创建 ConfigMap 挂载脚本
kubectl create configmap train-script --from-file=train.py
# 然后在 YAML 的 volumes 段加上挂载（需自行补充）
# 提交 Job
kubectl apply -f gpu-job.yaml
# 查看任务状态
kubectl get jobs
kubectl logs -f job/ddp-training-demo -c trainer
注意：实际使用时需要将
train.py通过 ConfigMap、PV 或镜像打包注入 Pod。上面的 YAML 是最小骨架，生产级部署还需补充 PVC 挂载数据集、日志收集、Master Service 发现等配置。
算力捐赠的现实边界与 Checklist
这笔 1.08 亿美元的捐赠规模惊人，但落地时仍要面对几个现实问题：
| 维度 | 需要确认的事项 |
|---|---|
| 额度有效期 | 捐赠算力是否有使用期限？过期后是否可续期或转为现金？ |
| GPU 型号 | 额度覆盖的是 A100 还是 H100？不同型号对大模型训练的可行性影响极大 |
| 数据合规 | 研究数据能否合法出境到云端？国内高校需评估数据安全法约束 |
| 网络带宽 | 数据集上传和模型下载的带宽成本是否包含在额度内？ |
| 技术支持 | 云平台是否提供 K8s 部署指导？高校团队往往缺乏云原生运维经验 |
| 分配机制 | 谁决定额度在不同课题组之间的分配？是否需要申请和评审流程？ |
对国内研究者而言，最值得借鉴的不是捐赠金额，而是"捐服务而非捐设备"这个思路。国内 GPU 云厂商（如 AutoDL、趋动科技等）同样提供 K8s 原生调度和裸金属 GPU 实例，高校基金会或科研资助机构完全可以复制这一模式——购买云算力额度，定向分配给课题组，用完释放，避免设备闲置折旧。
算力正在从"谁拥有硬件"转向"谁能高效调度资源"。黄仁勋基金会这笔捐赠，恰好踩在了这个转折点上。