Fedora 社区最近上演了一幕戏剧性投票：一项关于改善 NVIDIA CUDA 开发者体验的提案先获全票通过，随后又被否决。这场翻转不是简单的流程失误，而是传统开源社区在 AI 浪潮下的一次集体焦虑发作——当 GPU 算力几乎等于 NVIDIA，拥抱 CUDA 就是背叛开源吗？
全票通过，然后全票否决
提案的核心诉求并不激进：让 Fedora 更好地支持 CUDA 工具链的安装与运行，改善 AI 开发者在 Fedora 上的体验。初轮投票毫无悬念地通过了——委员会成员自己也用 CUDA 写模型，谁不想要更顺手的开发环境？
但否决来得同样干脆。反对者提出的理由直指身份认同：Fedora 的根基是自由软件，CUDA 是闭源驱动之上的闭源工具链。官方支持 CUDA，等于在社区准则里开了一个"闭源也可以"的口子。更现实的担忧是——一旦开了口，下一步是不是就该把 NVIDIA 闭源驱动也纳入官方仓库？
翻转背后不是技术判断的变化，而是政治压力的介入。全票通过说明每个人心里都知道 CUDA 是实际需求；全票否决说明每个人也都知道承认这一点会动摇社区的自我叙事。
"英伟达羞耻"：一个结构性困境
所谓"英伟达羞耻"，不是某个人的道德瑕疵，而是整个开源生态的结构性困局：
- 硬件垄断：AI 训练和推理的 GPU 市场，NVIDIA 占据超过 80% 的份额。CUDA 不是"一个可选平台"，而是事实标准。
- 工具链闭源：从驱动到 CUDA Toolkit 到 cuDNN 到 TensorRT，关键路径上每一环都是闭源软件。开源社区没有替代品可以推荐。
- 社区准则冲突：Fedora、Debian 等发行版的核心准则要求优先支持自由软件。但 AI 开发者需要的恰恰是非自由软件。
这不是"要不要用闭源"的二元选择，而是"准则写在纸上，工作落在 GPU 上"的日常撕裂。开发者白天用 CUDA 训练模型，晚上在社区邮件列表里捍卫自由软件原则——同一个人，两套逻辑。
开源替代品的现实差距
AMD 的 ROCm 和 Intel 的 oneAPI 是社区最常提到的两条"正道"。但它们的可用性差距是硬伤：
| 维度 | CUDA | ROCm | oneAPI |
|---|---|---|---|
| GPU 覆盖 | NVIDIA 全线 | 仅部分 AMD GPU | Intel GPU（市场占比极低） |
| 框架支持 | PyTorch/TF/JAX 一等公民 | PyTorch 有官方支持但迭代慢 | 依赖 SYCL 转译层 |
| 文档与社区 | 丰富、成熟 | 稀疏、频繁踩坑 | 更稀疏 |
| 安装体验 | 一条命令 | 需要内核版本匹配、固件对齐 | 仍在早期 |
一个想用 ROCm 训练模型的开发者，往往要先花两天时间解决内核兼容和固件版本问题。这不是"态度问题"，是"能不能按时交付"的问题。
在撕裂中务实前行：开发者的实际策略
与其等社区投票决定立场，不如在自己的项目里做出可复用的分层方案。核心思路：把 GPU 后端选择从"信仰问题"变成"配置问题"。
用 Docker 容器隔离 GPU 后端依赖
下面是一个可直接复制改造的 Docker Compose 配置，让同一个项目在 CUDA 和 ROCm 之间切换只需改一行：
# docker-compose.yml — GPU 后端可切换的 AI 开发环境
services:
ai-dev:
# 默认使用 CUDA 镜像；切换 ROCm 只需改 image 行
image: pytorch/pytorch:2.4.0-cuda12.4-cudnn9-devel
# ROCm 替代镜像：rocm/pytorch:latest
build:
context: .
dockerfile: Dockerfile
volumes:
- ./src:/workspace/src
- ./data:/workspace/data
environment:
- GPU_BACKEND=cuda # 改为 rocm 即切换
- PYTHONPATH=/workspace/src
# NVIDIA GPU 分配
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
# AMD GPU 替代配置（切换时替换整个 deploy 块）：
# deploy:
# resources:
# reservations:
# devices:
# - driver: amd
# count: 1
# capabilities: [gpu]
working_dir: /workspace
command: python src/train.py
使用前确保已安装对应容器运行时：
# NVIDIA：安装 nvidia-container-toolkit
sudo apt install nvidia-container-toolkit
sudo systemctl restart docker
# AMD：安装 ROCm container runtime
# 参考 https://rocm.docs.amd.com/projects/install_on_linux/en/latest/
在代码层做后端抽象
PyTorch 本身已经提供了设备抽象，但项目里散落的硬编码 cuda 字符串是切换后端时的隐患。用一个统一入口管理：
# device.py — 项目级 GPU 后端抽象
import torch
import os
def get_device() -> torch.device:
"""根据环境变量选择 GPU 后端，fallback 到 CPU"""
backend = os.getenv("GPU_BACKEND", "cuda").lower()
if backend == "cuda":
if torch.cuda.is_available():
return torch.device("cuda")
print("[warn] CUDA 不可用，回退到 CPU")
elif backend == "rocm":
# ROCm 在 PyTorch 中也通过 cuda API 访问（HIP 兼容层）
if torch.cuda.is_available():
return torch.device("cuda") # HIP 模式下 cuda 即 rocm
print("[warn] ROCm 不可用，回退到 CPU")
return torch.device("cpu")
# 使用示例
device = get_device()
model = model.to(device)
tensor = torch.randn(128, 512, device=device)
这样切换后端只需改环境变量，不用翻遍整个项目找 cuda 硬编码。
Fedora 上的 CUDA 安装：不官方支持，但可以自保
Fedora 否决了官方支持，不代表你不能用。RPM Fusion 仍然是可行路径：
# 启用 RPM Fusion free 和 nonfree 仓库
sudo dnf install \
https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
# 安装 NVIDIA 闭源驱动
sudo dnf install xorg-x11-drv-nvidia akmod-nvidia
# 安装 CUDA Toolkit（从 NVIDIA 官方 RPM 仓库）
sudo dnf config-manager --add-repo \
https://developer.download.nvidia.com/compute/cuda/repos/fedora$(rpm -E %fedora)/x86_64/cuda-fedora$(rpm -E %fedora).repo
sudo dnf install cuda
这是"社区不背书，但技术上可行"的典型状态。安装后建议把 CUDA 路径加入环境：
# ~/.bashrc 或 ~/.zshrc
export PATH=/usr/local/cuda/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
投票翻转教会我们什么
Fedora 这场投票的价值不在结果，在于它把一个大家心照不宣的矛盾摆到了台面。几条值得每个开源参与者思考的判断：
-
准则不是装饰，但准则需要分层。把"官方仓库不含闭源包"和"发行版不阻碍用户安装闭源包"分开，前者是身份底线，后者是实用底线。Fedora 否决的是前者级别的改变，但后者级别的改善（文档、路径配置）仍然可以做。
-
替代品需要投资，不是喊口号。如果社区真心不想依赖 CUDA，最有效的行动不是投票否决提案，而是把钱和人力投进 ROCm/oneAPI 的集成测试、文档翻译和 bug 修复。没有投入的替代方案只是道德安慰剂。
-
容器化是当前的务实解。在发行版立场和开发者需求之间，容器是一道干净的边界——发行版保持自由软件准则，开发者通过容器获取 CUDA 环境，互不侵犯。
-
承认矛盾比假装一致更健康。全票通过再全票否决，说明社区还没找到诚实的表述。与其维持"我们只用自由软件"的表面叙事，不如公开承认"我们的准则与我们的实践之间存在张力，正在寻找出路"。
开源社区在 AI 时代的身份不会靠一次投票确定。它会在每一次 CUDA 安装、每一次 ROCm 踩坑、每一次容器配置中被反复重塑。能做的，是让每一次选择都带着清醒，而不是带着羞耻。