AMD 显卡在 Linux 上性能暴跌 42 倍？Ubuntu 官方紧急预警，你的系统中招了吗？

摘要：Ubuntu 内核团队 7 月 16 日发布官方预警，确认 Linux 7.0.0-28.28 内核存在严重的 AMDGPU 驱动回归问题——在 AI 计算负载下，AMD 显卡性能最高暴跌至原来的 1/42。SDXL 图像生成从 9 秒变成 388 秒。本文梳理事件全貌，分析技术根因，并给出三种应对方案。

阅读时长：约 6 分钟

先说结论：如果你在 Ubuntu 上用 AMD 显卡跑 Stable Diffusion、ROCm 或者任何 GPU 计算任务——先别急着 apt upgrade。

7 月 16 日，Ubuntu 内核团队在官方 Discourse 社区发了一则不太寻常的公告：主动告知用户，即将推送的内核更新里有已知的性能回归，部分用户最好先别升。

我翻了一下 Ubuntu 的安全公告历史，这种操作确实少见。平时内核更新 = 无脑 apt upgrade，安全补丁加性能改进，升就完了。这次官方居然自己踩了刹车。

一、到底发生了什么？

7 月 16 日早晨，Ubuntu 内核团队在 Discourse 社区发布公告[1]，确认即将推送的 Linux 7.0.0-28.28 内核 中的 AMDGPU 驱动存在严重性能回归：

「受影响用户可能会经历显著的性能下降，特别是在运行使用 ROCm 的计算密集型工作负载时，例如通过 ComfyUI 进行 Stable Diffusion XL（SDXL）推理。报告显示减速高达 42 倍——例如，从 9 秒延长到 388 秒。请注意，这是吞吐量退化而非系统死锁。」

Ubuntu 不是第一个发现这个问题的。实际上，这个 Bug 在社区里已经「潜伏」了一个多月。

最早的报告来自 Fedora 用户。6 月 14 日，一位 Fedora 44 用户在 AMD 官方的 ROCm Issue Tracker 上提交了 Bug 报告[2]：

SD1.5 几乎不受影响，但 SDXL 的推理时间从 9 秒直接飙升到 388 秒——翻了 42 倍。这意味着原本泡杯咖啡就能等到的结果，现在要等到咖啡凉透。

与此同时，CachyOS、openSUSE Tumbleweed、Arch Linux 等发行版的用户也陆续在 ComfyUI 的 Issue 区[3]验证了相同问题。

二、影响范围有多大？

受影响的 Ubuntu 版本

• • Ubuntu 26.04 LTS：默认使用 7.0 内核系列，直接受影响
• • Ubuntu 24.04 LTS（HWE 内核）：硬件启用栈计划从 6.17 迁移到 7.0，届时也会受影响

受影响的硬件

根据社区反馈，以下 AMD 显卡已在受影响之列：

从 RDNA 2 到最新的 RDNA 4，横跨三代架构全部中招。不过要注意，Strix Halo（统一内存架构）的表现与独立显卡有所不同——部分用户反馈 --disable-mmap 对其无效。

受影响的场景

重点：这不是图形/游戏性能下降，而是 GPU 计算负载的性能问题。

具体表现为：

• • Stable Diffusion 推理（ComfyUI / Automatic1111）：模型加载和推理极慢
• • ROCm 通用计算：任何通过 ROCm 进行 GPU 加速的应用
• • safetensors 模型加载：使用 mmap 方式的模型文件加载

如果你只是日常办公、浏览网页、看视频——不受影响。如果你偶尔玩 Steam 游戏——大概率也不受影响（Proton/DXVK 走的是图形管线，不是 ROCm 计算管线）。

但如果你是 AI 开发者、机器学习工程师、或者任何在 AMD 显卡上跑 PyTorch/TensorFlow 的用户——这个 Bug 几乎一定会打到你。

三、根因到底是什么？

在深入分析之前，先理解一个关键概念：HMM（异构内存管理）。

简单来说，HMM 是 Linux 内核中负责让 GPU 和 CPU 共享内存地址空间的机制。当 ROCm 需要把 CPU 内存中的模型数据搬到 GPU 显存时，AMDGPU 驱动会调用 amdgpu_hmm_range_get_pages() 函数来完成内存页的映射。

问题就出在这个函数里。

一个致命的「重试死循环」

上游内核的修复提交[4]（由 AMD 工程师 Huang Honglei 提交，AMD 内核团队负责人 Christian König 审查，AMD 图形部门副总裁 Alex Deucher 签署）详细解释了问题根因：

在 Linux 7.0.12 中，一个早期补丁（c08972f）将 mmu_interval_read_begin() 调用移出了循环体，但忘了同步更新重试逻辑。后果是：

1. 1. hmm_range_fault() 返回 -EBUSY，表示内存映射序列号已过期
2. 2. 代码进入 retry 标签，但此时存储的 notifier_seq已经过时
3. 3. 内核再次调用 hmm_range_fault()，检查到序列号不匹配，立即再次返回 -EBUSY
4. 4. 这个「检查→失败→重试」的循环在 HMM_RANGE_DEFAULT_TIMEOUT（约 1 秒）的超时窗口内空转，纯粹烧 CPU
5. 5. 最终超时返回 -EAGAIN，上层调用者重新发起操作

用大白话说：就像你打电话给客服，占线了就自动重拨，但重拨间隔是 0 秒，于是占线→秒重拨→占线→秒重拨……十分钟后才提示「请稍后再拨」。

为什么影响这么大？

问题不在于 GPU 本身的计算速度——bug 报告中的 btop 监控显示，GPU 利用率在模型加载期间几乎为零，磁盘 I/O 也极低。一旦模型加载完成，推理迭代速度（it/s）完全正常。

真正的杀手是 mmap 路径。

safetensors 库（AI 模型的主流存储格式）默认使用内存映射（mmap）方式打开模型文件。在正常内核上，每个张量从 mmap 内存区传输到 GPU 只需几毫秒。但在受影响的 7.0.12 内核上：

「safetensors 的 mmap 张量到 GPU 的 DMA 传输速度比堆分配张量慢约 1000 倍。」[2]

一个 6.94GB 的模型文件，用 mmap 方式加载需要 6 分多钟，而用 safetensors.load_file(device='cuda') 直接加载仅需 2.81 秒。

小结：GPU 计算没问题，问题出在「把数据喂给 GPU」这一步。

四、修复进展如何？

好消息是——修复已经完成。

AMD 工程师 Honglei Huang 在 6 月 19 日提交了上游修复补丁[4]，随后被合入 Linux 7.0.13。修复方案非常简洁：

• • 删除重试循环（8 行代码）
• • 让 -EBUSY 错误直接向上传播为 -EAGAIN
• • 由上层 KFD 恢复工作线程或用户空间自行重试

换句话说：之前的代码在「自己重试但永远失败」，修复后的代码选择「立即上报，让更上层决定怎么处理」。

那为什么 Ubuntu 还在推送有问题的内核？Ubuntu 内核团队的解释是[1]：

「Ubuntu 内核团队当前优先推送包含关键安全修复的内核版本，以确保用户安全。虽然这个回归问题会出现在 7.0.0-28.28 版本中，修复补丁已经排入下一个紧急更新批次。」

简单说：安全补丁不能等，性能回退可以下个版本修。

五、你现在应该怎么做？（三种方案）

方案一：暂缓升级（推荐）

如果你还没升级到 7.0.0-28.28：

# 查看当前内核版本
uname -r

# 如果显示 7.0.0-27 或更早版本，先别急着 apt upgrade
# 可以只更新安全补丁，暂不升级内核：
sudo apt-mark hold linux-image-generic linux-headers-generic

等 Ubuntu 推送包含修复的后续内核版本（预计在 7.0.0-28.28 之后的下一个更新），再解除锁定：

sudo apt-mark unhold linux-image-generic linux-headers-generic
sudo apt update && sudo apt upgrade

方案二：临时绕过（适用于已升级用户）

如果你已经升级到 7.0.0-28.28 且需要继续跑 AI 推理，--disable-mmap 标志是社区验证有效的临时方案：

ComfyUI 用户：

python main.py --disable-mmap

PyTorch 用户（直接使用 safetensors）：

# 避免使用 safe_open()（默认 mmap）
# 改用 load_file() 或指定 copy=True
import safetensors.torch as st

# 方案 A：直接加载到 GPU
tensors = st.load_file("model.safetensors", device="cuda")

# 方案 B：如果必须用 safe_open，强制拷贝
with st.safe_open("model.safetensors", framework="pt", device="cpu") as f:
    tensor = f.get_tensor("key").to("cuda", copy=True)

注意：部分用户反馈 Strix Halo（统一内存架构）上 --disable-mmap 可能无效[2]，这类用户建议选择方案一或方案三。

方案三：降级内核（适用于已升级且方案二无效的用户）

如果你的系统已经升级，且工作流无法绕过 mmap 路径：

# 1. 查看已安装的内核列表
dpkg --list | grep linux-image

# 2. 启动时在 GRUB 菜单中选择「Advanced options」→ 旧版本内核

# 3. 如果需要永久切换默认内核
sudo nano /etc/default/grub
# 修改 GRUB_DEFAULT 为旧内核的菜单项编号
sudo update-grub
sudo reboot

快速自查：我受影响吗？

# 一行命令自检
uname -r | grep -q "7.0.0-28" && echo "⚠️ 受影响的 7.0.0-28.28 内核，建议查看本文方案" || echo "✅ 不受影响的内核版本"

六、事件时间线

七、几点想法

说实话，看到 Ubuntu 官方主动发这种预警公告，第一反应是惊讶，第二反应是——挺好的。

过去遇到这种「已知性能回归但安全补丁更紧急」的情况，很多发行版的做法是假装不知道，让用户自己踩坑。Ubuntu 这次选择提前把话说清楚，给用户留出选择空间，这种坦诚值得一个赞。

但这次事件也暴露了一个老问题：AMD 在 Linux 上的 ROCm 生态还不够稳。

不是不能用——日常推理、模型微调、视频生成都正常。但内核层面的坑还是时不时冒出来。这次 c08972f 提交的初衷就是修 amdgpu_hmm_range_get_pages 里的另一个 bug，结果引入了一个更严重的问题。同行评审没拦住，CI 测试也没抓到——直到 Fedora 用户在 ComfyUI 里发现 SDXL 推理从 9 秒变成 388 秒。

NVIDIA 的 CUDA 栈花了十几年才磨到今天这个程度。AMD 的 ROCm 虽然追赶速度很快，但像 HMM 内存管理、mmap 路径这些内核驱动层面的边角，稳定性还需要时间积累。

最后说句实在的：如果你是 AMD GPU 的 AI 用户，养成 apt upgrade 前看一眼有哪些包要更新的习惯。特别是看到 linux-image 的时候，花半分钟搜一下 changelog，可能省掉你后面几个小时的排查。

参考资料