Harry Chen’s Blog

wg-vanity：（又一个）Rust 实现的 WireGuard 地址生成器

2026-08-25T21:45:00+08:00

众所周知，WireGuard 的公私钥是 base64 编码后的 X25519 密钥对，每个 peer 唯一对应一组密钥。为了更方便识别客户端，很多人都会想生成“好看”的公钥地址，也就是在中间包含特定的字符串或者前缀。很明显这是一种类似于挖矿的暴力搜索，除了反复生成密钥之外别无他法。

几年前，我在 GitHub 上翻到了 wireguard-vanity-address 这个项目：它用 Rust 实现了简单的地址生成器，并且支持 Rayon 做单机并行。虽然功能非常简单，但也确实非常好用。在它和 7742 服务器的帮助下，我这几年生成了不少个人使用的密钥对（公钥基本都以 harry 开头）。

然而，在想要搜索更长的前缀时，单机就不够用了；此外，GPU 显然也很擅长这种尴尬并行的计算任务，但项目并不支持。我原本想给作者提交一些 PR，但发现项目已经有五年多没有活动了。于是我就 fork 了一份，再加上一些并不复杂的许愿，在 crates 上发布了一个新的包：wg-vanity。

wg-vanity 相比于原来的版本，升级了 Rust 语言和各种依赖到最新的版本，并增加了可选的 CUDA、MPI 的支持（二者可独立启用），也有简单的 CI 测试。于是，我现在就可以：

$ srun -n 12 -N 12 --gres=gpu:8 wg-vanity-cuda harrych
expected work: about 8.590e9 candidates (case-insensitive estimate) to find one match
using 8 CUDA device(s) per MPI rank (12)
measured 9.011e8 keys/s; estimated time to a match: 9.5 s
private dK6VdXSO2Y0Nc/yjbavbvA9g//fmUVVWosUkGcsGKhc=  public harRYCh9czEQgKxrRjT3V/PJZT9Ow+mfubF3xcZ+/ic=
MPI: 12 ranks, 4069523456 candidates in 4.431s (9.185e8 keys/s)

我还打算增加更多的功能，比如正则 pattern、支持更多的 key 类型等。也欢迎帮我许愿，然后提出 PR！

RTX 5090 的细粒度温度传感器与物理 SM / TPC 映射探测

2026-07-24T06:30:00+08:00

七月初，超频爱好者们又给老黄带来了新的惊喜：RTX 5090 的若干非公开的温度传感器的 PCIe BAR 地址被逆向了出来： [1][2][3]。这些传感器包含了四个热点（hotspot）CH0 到 CH3，以及每一片 GDDR7 显存模块的温度（根据型号不同，可能有 8 或者 16 个传感器）。这些热点传感器比公开 API（比如 nvidia-smi 或者 NVML）能读到的信息更丰富，更接近芯片的实际温度（比如结温），刷新率也更高，自然能给超频玩家更多的玩法。但我并不超频，它还有什么用呢？有的，这两天，在 GPT-5.6 Sol 的帮助下，我还是做了一些有趣的探究。

注：以下大部分实验是 AI 做的，结果数据、图表由 AI 收集生成，我已尽力进行审阅。

背景：传感器信息

5090 的 PCIe BAR 中，如下的地址有六个核心温度寄存器：

0xAD0A90..0xAD0A9C：四个独立通道 CH0-CH3
0xAD0AA0：硬件聚合最大值（Hotspot）
0xAD0AA4：硬件聚合平均值

它们都使用低 16 位，以 1/256 摄氏度为单位的定点数表示温度。此外，还有 8 或者 16 个寄存器保存了当前的显存颗粒温度，格式和地址范围都比较复杂。这些寄存器具体的读取逻辑都可以参见 gpuwatch 项目。此外还需注意，还需要打开 iomem=relaxed 内核命令行选项，才能从用户态映射 PCIe BAR 空间。

实验：负载与温度变化

一些简单的 CUDA 负载测试结果：

负载	功耗 W	Hotspot C	硬件平均 C	CH0	CH1	CH2	CH3	显存最高
空闲基线	22	26.4	24.1	26.3	22.1	23.4	26.4	32.0
FP32，1 block	102	37.9	33.2	37.9	30.9	29.4	33.2	33.7
FP32，22 blocks	137	57.2	37.6	57.2	33.6	33.1	36.2	35.0
FP32，44 blocks	188	71.3	42.8	71.3	36.3	36.2	40.6	37.0
FP32，88 blocks	284	84.0	54.4	84.0	44.4	40.7	55.7	40.1
FP32，170 blocks	421	104.2	61.9	104.2	48.6	42.7	60.6	44.2
FP32，680 blocks	414	104.2	61.9	104.2	48.6	42.9	60.5	44.8
INT32，全负载	414	104.0	61.9	104.0	48.4	42.7	60.1	44.8
L2，32 MiB	328	71.4	55.9	71.4	45.6	42.2	54.8	43.8
GDDR7，2 GiB	319	65.1	51.7	65.1	44.4	40.8	49.3	51.5
Tensor Core	449	93.0	62.9	93.0	51.0	45.3	59.5	51.5

简单观察这些 CH 传感器的变化，可以得到如下结果：

Hotspot 是各通道最大值，而计算负载几乎总会使 CH0 成为最大值（远超平均温度，甚至超过 100 度）。
几乎总是有 CH0 > CH1 > CH3 > CH2。
读到的 “平均温度”并不是四个通道的简单平均，但是与功耗的相关性更高，可能是某种加权平均。

接着进行了一些脉冲测试，也就是启动较短时间的 kernel，观察温度变化，结果如下：

脉冲长度	Hotspot 增量 C	硬件平均增量 C	Hotspot 峰值时间中位数
50 ms	13.9	8.6	27 ms
100 ms	25.5	13.5	90 ms
200 ms	36.0	18.3	197 ms
500 ms	50.0	24.7	508 ms
1 s	59.8	29.5	981 ms
2 s	64.9	30.4	1.994 s
5 s	75.7	33.8	4.916 s
10 s	74.6	31.2	5.032 s

看起来 Hotspot 的测量非常灵敏。在 kernel 结束后，其下降也非常快。通过更多的测试，可以确定这些传感器的更新频率在 50Hz 左右。

接下来，在单个固定的 SM 上，测试了 32-1024 个线程、1-6 个 256 线程 block，以及 32x8、64x4、128x2 等 warp 总数相同的配置。单 warp 场景消耗 99.6 W；其他所有场景约为 100.6-102.5 W。除第一个、温度最低的冷态实验以外，每种配置扣除基线后的 CH0 增量都是 8.89-9.04 C。其他通道同样几乎不变。也就是说，空闲功耗以上约 80 W 的大部分增量都来自使整个设备进入高性能时钟/功耗状态。只改变 170 个 SM 中一个 SM 的工作量，影响太小，几乎无法通过温度传感器区分。

注：此处的“单个 SM”并不是说我们能控制 CUDA 程序运行在某个物理 SM 上。事实上，我们总是可以占满 GPU，并通过读到的 SM ID 决定来哪些 SM 实际运行负载，让剩下的 SM 处于空闲状态。下面的实验均使用了类似的方法：

smid = read_special_register("%smid");
if (!active_sms[smid])
    return;
selected = atomicAdd(&per_sm_counter[smid], 1) < 4;
if (!selected)
    return;
while (globaltimer < deadline) {
    // 大量寄存器内 FP32 FMA
}

也就是说，最先抵达这个 SM 的四个 block（每个 256 线程，已经能足够打满 SM 的功耗）会一直执行，直到全局计时器到达截止时间。

实验：温度与降频

可以确定的是，CH0 的温度参与了 GPU 对温度降频（thermal throttling）的决策。在一个持续 90 s、使用 170 个 block 的 FP32 负载中，第一次报告硬件温度降频事件是在 kernel 启动 6.50 s 后可观察到：

隐藏 hotspot：99.94 C
硬件平均值：59.69 C
驱动 GPU 温度：59 C
板卡功耗：446 W
图形时钟：2775 MHz

此时驱动温度还比较低，只有 60 度，但 GPU 已经开始报告温度降频事件发生。随后过一段时间，hotspot 保持在约 104.5 C，而负载的三个三等分区间变化如下：

区间	Hotspot 平均 C	硬件平均 C	功耗 W	图形时钟 MHz
前 30 s	103.3	61.2	421.6	2719
中间 30 s	104.6	63.0	399.0	2597
后 30 s	104.6	63.5	391.6	2570

可以推测，当 hotspot 超过 100 度后，就可能触发降频保护机制。此时 GPU 整体（或者说外界可见）温度和功耗都远远没有达到极限。

我还尝试了基于 hotspot 温度的简单计算控制，也就是在温度即将到达阈值时暂停计算，来试图避免降频，获得更高的计算性能。然而由于同步和调度等开销，这种“占空比”的控制方法并没有获得太好的效果。

实验：温度与 SM 映射

由于单活动 SM 的实验没有什么效果（背景温升盖过了单个 SM），我选择用一组 42 个 SM 来测试（这个数字是随便选的，大致是 170 个 SM / 4 个传感器），每次只在一组上施加负载。除了连续的四组 SM 之外，还有一个实验，是每隔四个 SM 选一个，同样有 42 个。结果如下：

SM ID 集合	稳态功耗 W	CH0 温升 C	CH1 温升 C	CH2 温升 C	CH3 温升 C	平均温升 C
q0，0-41	188.24	50.80	13.75	11.76	12.88	18.98
q1，42-83	191.15	33.95	12.23	9.38	19.86	19.72
q2，84-125	191.34	44.83	12.96	9.57	14.21	18.86
q3，126-167	189.45	29.76	11.15	8.94	23.19	19.59
条纹，0,4,…,164	189.92	36.60	13.40	9.23	18.41	18.24

很明显，不同的活跃 SM 集合对不同的传感器影响不同。因此我猜测这些传感器在物理上的分布并不一致。

实验：温度传感器对少量 SM 负载的响应

我让 Codex 用不同的组大小进行了充分的扫描，发现在组大小为 1 或者 2 的时候，对传感器的影响最为显著。

需要注意的是，这张图里的线代表了“传感器的温度变化减去基线温度变化”的值，也就是说，纵轴的零点代表了某个传感器在负载开始前的温度均值。从图中可以看到，CH0 对某几个 SM 的响应非常明显，CH3 也有一些点比较明显，并且这些点的编号似乎有某种周期性。这些信号都增强了我的猜测，即这些温升的变化，和传感器与 SM 的物理距离有关系。

然而，想要直接弄明白传感器的位置，还需要先知道 SM 的物理位置，这还需要更多的实验。

实验：SM ID 到 GPC/TPC 的映射

根据如下图中 5090 的 die shot，它由 12 个 GPC 组成，每个 GPC 上有 8 个 TPC，每个 TPC 上又有两个 SM。虽然总共有 192 个 SM，但由于良率或者其他原因，实际只启用了 170 个。根据分析，其中有 3 个 GPC 只启用了 7 个 TPC，有 8 个 GPC 启用了全部的 8 个 TPC，还有一个 GPC 完全被禁用。

因此，第一步是把 SM ID 映射到 GPC 中，才能对应到 die shot。这一步并用不到温度传感器。

CUDA 编程模型保证，thread-block cluster 中所有 block 会同时调度在同一个 GPC。因此只要让 cluster 内每个 block 读取 %smid，就可以把这些对应的 SM ID 归类到同一个 GPC 中。经过充分的数据获取和处理处理（一些简单的图上连通分量分析），可以获得 11 个逻辑 GPC 对应的 SM ID 集合：

逻辑 GPC	TPC 数	SM 数	每个 TPC 的 SM ID 对
0	7	14	0/1, 22/23, 44/45, 66/67, 88/89, 110/111, 132/133
1	7	14	2/3, 24/25, 46/47, 68/69, 90/91, 112/113, 134/135
2	7	14	4/5, 26/27, 48/49, 70/71, 92/93, 114/115, 136/137
3	8	16	6/7, 28/29, 50/51, 72/73, 94/95, 116/117, 138/139, 154/155
4	8	16	8/9, 30/31, 52/53, 74/75, 96/97, 118/119, 140/141, 156/157
5	8	16	10/11, 32/33, 54/55, 76/77, 98/99, 120/121, 142/143, 158/159
6	8	16	12/13, 34/35, 56/57, 78/79, 100/101, 122/123, 144/145, 160/161
7	8	16	14/15, 36/37, 58/59, 80/81, 102/103, 124/125, 146/147, 162/163
8	8	16	16/17, 38/39, 60/61, 82/83, 104/105, 126/127, 148/149, 164/165
9	8	16	18/19, 40/41, 62/63, 84/85, 106/107, 128/129, 150/151, 166/167
10	8	16	20/21, 42/43, 64/65, 86/87, 108/109, 130/131, 152/153, 168/169

之所以称为“逻辑 GPC”，是因为我们依旧不知道它的物理位置，只是赋予了一个唯一编号（按照 SM ID 排列）。这与上面的 die shot、以及温度传感器对 SM 的响应分析能互相验证：编号相邻的两个 SM 对温度的影响几乎是相同的，因此应当确实属于同一个 TPC。

我们将每个 TPC 中的两个 SM 视作一个整体，用上述的逻辑 GPC、TPC 编号，绘制所有温度传感器对不同 SM 的响应图示：

显然，从这张图中，我们已经能获得很多有用的信息，甚至已经可以进行一些基于人工智能（指人脑）的重新排布。但为了让结论更有说服力，我们还需要进行一些定量的分析。

分析：GPC/TPC/SM ID 到物理位置的映射

现在就剩下了最后的两个问题：

8 个 TPC 在 GPC 中的物理排布是怎么样的？
12 个 GPC 在整个 die 上的物理排布是怎么样的？

为了解决这个问题，我们可以先进行一些符合直觉的假设来缩小搜索空间：

GPC 的编号应当在物理上连续；不同的 GPC 中，TPC 的排布方式应当相同；
TPC 在 GPC 中的排布应该使得 SM 编号遵循一定的顺序：如从左到右、从上到下递增，相邻两个编号连续或者有固定的 stride。注：规定一种排列方向会消除很多种可能的镜像排布，我们将它们视作相同的方案。
由物理定律可知：离热源越远的地方，温升越小，并且会形成连续的温度梯度。

我们不妨假设温度传感器就位于响应最高的 SM 附近（ID=96，GPC=4，TPC=4）。接着，尝试枚举所有遵循上述编号方式约束的可能 TPC、GPC 排布方式，并对以下的指标进行优化：

每个热点附近的温度梯度，也就是温升与物理距离（曼哈顿距离，单位为 SM 单位格）的相关性（Spearman 相关系数）
热点附近其他 SM 诱发的 1 秒内的温升比例（温度升高值与稳态温度的比例）与物理距离的相关性。

最终，可以获得如下的“镜像列主序”的排列方案，满足所有约束，并且在上述指标上表现良好：

也就是说，12 个 GPC 很可能是从左到右、从上到下依次编号。每个 GPC 中的八个 TPC 编号方式可能是：

TPC4  TPC0
TPC5  TPC1
TPC6  TPC2
TPC7  TPC3

如上所述，还有几种全局镜像的排布方式，我们视同等价。从这张按位置映射重绘的热力图上，我们能获得以下的观察：

CH0、CH2、CH3 都有比较直观的温度梯度，因此我们的排布应当是基本合理的。
图上的几个标记是我推测的传感器可能的位置（CH1 无法判断）。然而这几个传感器的响应绝对幅度并不相同，因此一定还有其他的差异（比如垂直距离区别）。
每个传感器对 SM0/1 对应的 TPC 都有明显高于其所在位置的响应，这意味着 SM0/1 对于这四个传感器都有更高的升温作用。目前我对此尚没有合理的解释。

事实上，还有一种更符合温度梯度的方案，是 [4,0] [5,1] [6,2] [3,7]；但是这样的编号实在太扭曲，再考虑到温度测量可能带有不确定的噪音，我最终舍弃了这种方案。

总结

在 GPT-5.6 的帮助下，我（基本）成功从高精度的温度传感器读数中，推测出了 5090 的一种可能的物理 SM 排布方式。尽管这些信息或许可以从其他渠道简单地获得，也很可能还有错误，对日常使用也没有太多的帮助，但依旧是个非常有趣的过程。

附录

实验过程中还进行了一些可能有用的测试，摘录如下。

负载	稳态功耗 W	Hotspot 峰值 C	硬件温度事件占比
FP32 FMA	452	107.6	1.7%
INT32 MAD	431	109.2	31.1%
FP64 FMA	167	55.8	0%
SFU sine	323	90.2	0%
共享内存	363	97.4	0%
全局原子操作	162	51.5	0%
L2 读写	324	71.5	0%
GDDR7 读写	318	65.4	0%
FP16 Tensor GEMM	446	94.0	0%

6000 端口占用导致 SLURM 卡死诊断一例

2026-06-10T07:15:00+08:00

今天在组里的某个 GPU 集群上部署了一套 SLURM，方便多人使用。我本以为只是从已有集群复制配置、启动服务，十分钟之内就能搞定，没想到因为一个玄学的问题整整卡了一个多小时。

问题现象：各个节点上的 slurmctld、slurmd、slurmdbd 都能正常启动，然而只要试图提交任务，机器上的 slurmd 和派生的 slurmstepd 就会卡死（任务并没有开始运行），不再有任何响应（slurmctld 也无法联系它），只能靠 SIGKILL 杀死后重新启动。各个进程的日志中都看不出什么异常；能看到的只有超过一定时间后，slurmctld 认为 slurmd 超时没有响应而产生的抱怨。

考虑到我也在 SLURM 上踩过各种各样的坑，我花了半个多小时，排除了以下问题：

文件系统问题：就算没有共享文件系统，whoami 之类的命令还是会工作的。并且我们的 NFS 看起来非常正常。
hostname 问题：如果机器名称和 IP 的解析/反向解析有误，会导致各个 daemon 之间通信异常：机器上都有正确的 hosts，并且我额外还配置了 NodeAddr。而且只要不提交任务，其他的一切都正常。
slurmdbd / 数据库问题：注释掉相应部分，故障依旧。
cgroups 问题：都 6202 年了，不可能还有 cgroups v1 的问题了；并且关闭相应部分，故障依旧。

并且最关键的一点是，相同的配置文件，在同样的系统、硬件上（我也是从这里复制的），是完全能工作的。那到底是怎么回事呢？

在 Claude 的提示下，我用 gdb 对卡死的 slurmstepd 进程打印了调用栈，结果还真有惊奇的发现：

$ gdb -p $(pgrep slurmstepd) -batch \
  -ex "set pagination 0" \
  -ex "thread apply all bt"

Thread 1 (Thread 0x151e80a3fc00 (LWP 261104) "slurmstepd"):
#0  0x0000151e806a59ee in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000151e8069a668 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000151e8069a6ad in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x0000151e8070e9c6 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x0000151e7fa7928b in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#5  0x0000151e7fa76b8e in xcb_connect_to_fd () from /lib/x86_64-linux-gnu/libxcb.so.1
#6  0x0000151e7fa7b279 in xcb_connect_to_display_with_auth_info () from /lib/x86_64-linux-gnu/libxcb.so.1
#7  0x0000151e7eaf20c2 in _XConnectXCB () from /lib/x86_64-linux-gnu/libX11.so.6
#8  0x0000151e7eae1b45 in XOpenDisplay () from /lib/x86_64-linux-gnu/libX11.so.6
#9  0x0000151e8036437b in ?? () from /usr/lib/x86_64-linux-gnu/hwloc/hwloc_gl.so
#10 0x0000151e80bba58e in ?? () from /lib/x86_64-linux-gnu/libhwloc.so.15
#11 0x0000151e80bc1c31 in hwloc_topology_load () from /lib/x86_64-linux-gnu/libhwloc.so.15
#12 0x0000151e80379047 in pmixp_libpmix_job_set () from /usr/lib/x86_64-linux-gnu/slurm-wlm/mpi_pmix_v5.so
#13 0x0000151e8037d3d9 in pmixp_stepd_init () from /usr/lib/x86_64-linux-gnu/slurm-wlm/mpi_pmix_v5.so
#14 0x0000151e80375dbb in mpi_p_slurmstepd_prefork () from /usr/lib/x86_64-linux-gnu/slurm-wlm/mpi_pmix_v5.so
#15 0x0000561857a128df in job_manager ()
#16 0x0000561857a06eb9 in main ()

这 poll 是在干啥？为啥会有 xcb_connect_to_fd 这种奇怪的函数？我又不是在图形界面上运行 SLURM，怎么会有 X11 的调用？

又经过一番调研，原来是 SLURM 的任务管理插件 PMIx 会使用 libhwloc 来探测硬件相关信息，而其中一个插件是 hwloc_gl，它会尝试连接 X11 来获取 GPU 的信息。在我的机器上，这个连接不知道为什么就卡住了，陷入了无限的等待（poll）。在发现是 hwloc 问题后，我意识到完全不需要 SLURM 这么复杂，直接使用 lstopo 工具就能复现问题。

hwloc 的文档说，用 HWLOC_COMPONENTS=-gl 环境变量可以禁用掉这个插件。果然，加上之后 lstopo 就能工作了，而将它写入 /etc/default/slurmd 之后，重启 slurmd，任务就可以正常提交了。

但是，巧夺麻袋，这确实能解决问题，然而我还是没搞明白，为什么别的机器上没有这个问题？我给 lstopo 挂上了 strace，发现它做了如下的尝试：

[pid 266805] connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = -1 ECONNREFUSED (Connection refused)
[pid 266805] connect(3, {sa_family=AF_UNIX, sun_path="/tmp/.X11-unix/X0"}, 110) = -1 ENOENT (No such file or directory)
[pid 266805] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
[pid 266805] poll([{fd=3264130315]>, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
[pid 266805] connect(3, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 266805] connect(3, {sa_family=AF_INET6, sin6_port=htons(6000), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
[pid 266805] connect(3, {sa_family=AF_INET6, sin6_port=htons(6000), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0
[pid 266805] poll([{fd=3[::1]:6000]>, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
[pid 266805] poll([{fd=3[::1]:6000]>, events=POLLIN}], 1, -1 
[pid 266805] <... poll resumed>)        = ? ERESTART_RESTARTBLOCK (Interrupted by signal)

看起来是非常标准的流程：先尝试连接 abstract socket，再尝试普通 socket，最后才是 TCP 连接。前两者都失败了，可在一个 headless 服务器上，6000 端口上怎么会有程序在监听？我到处 ss 了一番，发现居然是组里其他同学在上面跑的 Megatron-LM 训练脚本把它作为 MASTER_PORT 了。于是，整个流程就非常明确了（这一段由 Claude 生成）：

Megatron 用 MASTER_PORT=6000 起 TCPStore，rank0 监听 [::]:6000
        ↓
这台是无头节点，没有 /tmp/.X11-unix/X0
        ↓
slurmstepd 起新 PMIx 任务 → PMIx 调 hwloc_topology_load → hwloc_gl 探测 :0
        ↓
:0 的 Unix socket 不存在 → xcb fallback 到 TCP localhost:6000
        ↓
connect([::1]:6000) 成功 —— 连进了 TCPStore！
        ↓
xcb 发 12 字节 X11 握手，TCPStore 看不懂 X 协议、不回应
        ↓
hwloc 永久卡在 poll(POLLIN)

这下终于明白了！在对相关同学进行殴打之后，我了解到这个端口来自 Megatron-LM 的样例脚本。在相关仓库中搜索 6000，能得到非常惊人的结果：几乎所有脚本都默认使用 6000 作为 MASTER_PORT；如果把搜索范围扩大到整个 GitHub，能看到无数的脚本已经被传染了。老黄，真有你的。我去给 Megatron 开了个 issue #5232，建议他们还是换个默认端口。

那为什么在其他机器上没有这个问题呢？因为：

我并没有在集群被已有作业占用的时候部署 SLURM，也没有在这个情况下测试提交。
同学往现有的 SLURM 集群提交使用 6000 端口的任务时，不会影响到 slurmstepd 的启动流程。
我们通常占用全机训练，所以也不会出现这个端口正在被占用时，slurmstepd 又开始启动的情况。

更新：在我写完博客后，@taoky 去研读了一下 hwloc 的代码，来搞明白为什么它在没有 DISPLAY 环境变量的情况下，还要尝试打开到 X11 的连接。结果令人昏厥，简要逻辑摘要如下：

for (i = 0; i < HWLOC_GL_SERVER_MAX; ++i) {
  snprintf(displayName, sizeof(displayName), ":%u", i);
  display = XOpenDisplay(displayName);
  if (!display)
    continue;
}

也就是说它不分青红皂白，直接从 0 开始遍历 10 个可能的显示器，直到找到一个能连接上的为止。那我还能说什么？它和 Megatron 在对这次事故的贡献中，确实是卧龙凤雏、难分伯仲。

在 RTX 5090 上启用 GPUDirect RDMA 通信支持

2026-05-20T01:00:00+08:00

免责声明： 本文涉及对 GPU 驱动的修改，作者不对任何因此产生的后果负责。

两个月前，我通过安装打补丁的驱动，成功为 RTX 5090 启用了 PCIe P2P 支持。就像我在那篇博客最后说的，另一个美好的愿望是，让 5090 这类消费级 GPU 也支持 GPUDirect RDMA，进一步减少跨机通信需要的 CPU 参与。而今天借助 Codex，我居然把这个愿望实现了。

技术背景

GPUDirect RDMA 的核心思想就是让 GPU 可以和网卡直接通信，绕过 CPU 和系统内存进行数据传输。既然驱动已经提供了 GPU 之间互相通信的能力，那么让网卡用上应该没有本质的困难。NVIDIA 也有专门的文档描述如何使用此功能：Developing a Linux Kernel Module using GPUDirect RDMA，看起来第三方的硬件也是可以用上这个特性的，更何况是同属 NV 产品线的 IB 网卡。与此对应的是，IB 卡与其他设备直接进行通信的特性称为 Peer Direct，GPUDirect RDMA 就是其中很常见的用途；此外 IB 卡也可以与 NVMe SSD、FPGA 等 PCIe 设备进行点对点直接通信，不在本文的讨论范围内。

从 CUDA 11.4 开始，NVIDIA 提供了内核模块 nvidia-peermem（最早叫作 nv-peer-mem，甚至不和驱动一起分发）来提供 GPUDirect RDMA 的支持。它的原理是，当构建 NVIDIA DKMS 模块时，如果系统中已经安装了 OFED 驱动，则 peermem 模块就能接入 RDMA 内核栈，让网卡驱动把 GPU 内存注册成 RDMA 可访问的内存区域。这里就产生了一些隐式的依赖，也给我这个运维带来了不少麻烦（如果安装的顺序不正确，或者中途升级了 OFED，那么就可能导致 peermem 模块无法加载，GPUDirect 功能静默失效）。

Linux 对于此类能将自己的内存共享给其他设备的外设，其实有自己的解决方案：dma-buf 子系统。根据 2020 年提出的 RDMA WITH GPU MEMORY VIA DMA-BUF 的设想，和 The Evolution and Implementation of GPUDirect RDMA 中的时间轴，2021 年内核的 RDMA 子系统以及 Mellanox 设备驱动都增加了对 dma-buf 的支持。从此不同的设备驱动不再需要互相耦合，而可以通过统一的接口进行注册、映射地址，最终发起 IO。近年来的 NVIDIA 开源驱动（主要是 12.8 以后）在较新的内核上，已经支持通过 dma-buf 来映射 GPU 显存，供 GPUDirect RDMA 通信使用。此外，目前 Intel 显卡（i915 / xe 模块）和 AMD 显卡（amdgpu 模块）都也已经支持了 dma-buf。

由于 dma-buf 子系统中传递的都是 buffer 的 fd，CUDA API 中提供了 cuMemGetHandleForAddressRange 来将 GPU 上的内存（指针）转换为可用的文件描述符。然而，即使在启用了 P2P 的 5090 上，调用此 API 也会直接返回 CUDA_ERROR_NOT_SUPPORTED。此外，使用文档中的 CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED 对设备进行查询，也会得到 0。

考虑到和 5090 同源的 RTX Pro 6000 是支持 GPUDirect RDMA 的，我猜想 GPU 的硬件上可能并没有缺失功能（也没有必要做这个限制），而又是老黄的刀法。也就是说，软件链路上（用户态 libcuda 或者内核态 nvidia 模块）一定有地方拦住了这个功能。

最终结论（TL;DR）

让 5090 用上 GPUDirect RDMA 的关键不在内核态驱动，而在用户态的 libcuda.so。在我的环境下，最小可工作的 patch 是复制 libcuda.so.590.48.01，并修改一个字节：

file offset: 0x42d69b
old:    0x40
new:    0x60

即对应的 X86 反汇编从 or $0x40,%edx 变成 or $0x60,%edx。

这会在 libcuda 的私有 device structure 里多设置一个 0x20 bit。这个 bit 会影响：

CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_SUPPORTED
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_WITH_CUDA_VMM_SUPPORTED
cuMemGetHandleForAddressRange(... DMA_BUF_FD, flags=0)
cuMemCreate(... CU_MEM_CREATE_USAGE_GPU_DIRECT_RDMA ...)

此后，使用 LD_LIBRARY_PATH 加载这个修改过的 libcuda.so 即可。如果使用 NCCL，则可能还需要根据机器拓扑（nvidia-smi topo -m）对应调整环境变量：

NCCL_NET_GDR_LEVEL=SYS

端到端验证中，24 卡（三台机器，每机一张 400Gbps NDR IB 卡）进行 allreduce 的性能（busbw），从约 8.87 GB/s 提升到了 19.93 GB/s。并且可以从日志中看到如下的信息，证明 NCCL 确实检测到并且在使用 GPUDirect RDMA 功能：

node1:496222:496276 [7] NCCL INFO DMA-BUF is available on GPU device 7
node1:496222:496272 [3] NCCL INFO DMA-BUF is available on GPU device 3
node1:496222:496270 [1] NCCL INFO DMA-BUF is available on GPU device 1
...
node1:496222:496297   [6] NCCL INFO Channel 01/0 : 6[6] -> 14[6] [send] via NET/IB/0/GDRDMA
node2:2686390:2686463 [7] NCCL INFO Channel 01/0 : 15[7] -> 14[6] via P2P/direct pointer
node1:496222:496297   [6] NCCL INFO Channel 01/0 : 14[6] -> 6[6] [receive] via NET/IB/0/GDRDMA
node3:2526722:2526797 [6] NCCL INFO Channel 01/0 : 22[6] -> 7[7] [send] via NET/IB/0/GDRDMA
node1:496222:496297   [6] NCCL INFO Channel 00/0 : 6[6] -> 22[6] [send] via NET/IB/0/GDRDMA
node2:2686390:2686464 [6] NCCL INFO Channel 00/0 : 14[6] -> 23[7] [send] via NET/IB/2/GDRDMA
node3:2526722:2526801 [2] NCCL INFO Channel 00/0 : 18[2] -> 23[7] via P2P/direct pointer
node1:496222:496298   [5] NCCL INFO Channel 00/0 : 5[5] -> 0[0] via P2P/direct pointer
node3:2526722:2526801 [2] NCCL INFO Channel 01/0 : 18[2] -> 23[7] via P2P/direct pointer
node3:2526722:2526798 [5] NCCL INFO Channel 00/0 : 21[5] -> 16[0] via P2P/direct pointer
node3:2526722:2526798 [5] NCCL INFO Channel 01/0 : 21[5] -> 16[0] via P2P/direct pointer
...
node2:2686390:2686476 [3] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node2:2686390:2686474 [5] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node2:2686390:2686475 [4] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node2:2686390:2686473 [6] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node3:2526722:2526813 [0] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node3:2526722:2526812 [1] NCCL INFO Connected all rings, use ring PXN 0 GDR 1
node2:2686390:2686472 [7] NCCL INFO Connected all rings, use ring PXN 0 GDR 1

注：此修改只适用于 dma-buf 相关 API，而不能让老的 nvidia-peermem 模块也工作起来。我并无兴趣对此进行更多探索。

调试过程

下面的内容几乎都是 Codex 生成的，调试也是它独立完成的，大概消耗了一个小时。

我在其中唯一的作用，是在它每次想要 sudo 的时候，检查一下命令内容，并决定是不是批准。过程基于驱动 NVIDIA 590.48.01、CUDA 13.1 进行。

背景：为什么一开始看 kernel driver

RTX 5090 在官方驱动里本来不暴露 CUDA DMA-BUF / GPUDirect RDMA capability。IB perftest 里如果使用：

--use_cuda_dmabuf

它会走 CUDA driver API 检查 dma-buf 可用性：

cuDeviceGetAttribute(&is_supported,
                     CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED,
                     cuda_ctx->cuDevice)

把这段检查硬注释掉继续跑，后面仍然失败：

cuMemGetHandleForAddressRange error=801

801 是 CUDA_ERROR_NOT_SUPPORTED。这说明问题不是 perftest 自己的前置检查，而是 CUDA driver API 真的拒绝了 dma-buf export。

当时的初始假设是：open GPU kernel module 里某个 capability 没打开，导致用户态 CUDA 判断 RTX 5090 不支持 dma-buf。

第一阶段：在 kernel driver 里强行打开 DMABUF capability

先从 kernel module 里能看到的 DMABUF capability 入手。

关键位置包括：

osinit.c
subdevice_ctrl_gpu_kernel.c
rmapi_cache.c
control.c
nv-dmabuf.c

做过的实验包括：

在 osinit.c 里打印并强制：

nv->dma_buf_supported = NV_TRUE;

dmesg 能看到：

DMABUF osinit: status=0x0 raw_cap=1 dma_buf_supported=1 before force
DMABUF osinit: forced dma_buf_supported=1

在 subdevice_ctrl_gpu_kernel.c 里对：

NV2080_CTRL_GPU_INFO_INDEX_DMABUF_CAPABILITY

强制返回：

NV2080_CTRL_GPU_INFO_INDEX_DMABUF_CAPABILITY_YES

在 rmapi_cache.c 里避免 RM cache 把这个 capability 缓存成 NO。
在 control.c 里打印 RM control 调用，确认用户态请求和 kernel 返回。
在 nv-dmabuf.c 里打印 nv_dma_buf_create()，用于确认最终有没有进入 dma-buf export 路径。

结果：kernel 里看起来已经是 YES，但 CUDA API 仍然报告：

CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED = 0
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_SUPPORTED = 0
cuMemGetHandleForAddressRange(...) = CUDA_ERROR_NOT_SUPPORTED

这一步非常关键：它说明 kernel 侧 NV2080_CTRL_GPU_INFO_INDEX_DMABUF_CAPABILITY 不是唯一 gate，甚至不是最后那个决定 CUDA API 行为的 gate。

第二阶段：写 CUDA probe，把问题缩小到 libcuda

写了一个很小的 CUDA driver API probe，检查这些 attribute：

CU_DEVICE_ATTRIBUTE_POSIX_FILE_DESCRIPTOR_SUPPORTED
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_WITH_CUDA_VMM_SUPPORTED
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_SUPPORTED
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_FLUSH_WRITES_OPTIONS
CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_WRITES_ORDERING
CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED
CU_DEVICE_ATTRIBUTE_HOST_ALLOC_DMA_BUF_SUPPORTED

原始结果大概是：

POSIX_FD_SUPPORTED                         = 1
GPU_DIRECT_RDMA_WITH_CUDA_VMM              = 0
GPU_DIRECT_RDMA_SUPPORTED                  = 0
GPU_DIRECT_RDMA_FLUSH_WRITES_OPTIONS       = 1
GPU_DIRECT_RDMA_WRITES_ORDERING            = 100
DMA_BUF_SUPPORTED                          = 0
HOST_ALLOC_DMA_BUF_SUPPORTED               = 0

cuMemGetHandleForAddressRange flags=0      = CUDA_ERROR_NOT_SUPPORTED

注意这里 POSIX_FD_SUPPORTED=1，说明 CUDA VMM 普通 fd export 能力和 dma-buf / GPUDirect RDMA gate 不是同一个东西。

这时继续只改 kernel 没有效果，所以开始反汇编 libcuda.so.590.48.01。

第三阶段：反汇编 cuDeviceGetAttribute

先找 cuDeviceGetAttribute：

public wrapper: 0x30ca40
real target:    0x31bef0
attribute read: 0x25ce00

cuDeviceGetAttribute 内部有一个 attribute jump table。关键分支包括：

attr 103 POSIX_FD_SUPPORTED                  -> 0x25d676
attr 110 GPU_DIRECT_RDMA_WITH_CUDA_VMM       -> 0x25d6f6
attr 116 GPU_DIRECT_RDMA_SUPPORTED           -> 0x25d604
attr 124 DMA_BUF_SUPPORTED                   -> 0x25cf91

其中 attr 116 的逻辑很直接：

xor    %eax,%eax
testb  $0x20,0x5f14(%rdi)
je     ...
cmpb   $0x0,global_gdr_enabled
setne  %al

也就是说，GPU_DIRECT_RDMA_SUPPORTED 至少要满足：

dev_struct[0x5f14] & 0x20 != 0
global_gdr_enabled != 0

attr 124 也会检查类似条件：

testb $0x8,0x5e80(...)
testb $0x20,0x5f14(...)
cmpb  $0x0,global_gdr_enabled

所以问题逐渐变成：RTX 5090 的 libcuda device structure 里，为什么缺了 0x5f14 的 0x20 bit？

第四阶段：直接 poke `libcuda` 的私有 device structure

为了验证这个猜想，没有马上 patch 文件，而是写了一个进程内 poke 程序。它通过 dladdr(cuDeviceGetAttribute) 找到当前进程加载的 libcuda base，然后定位 libcuda 的 device table：

device_slot = base + 0x5e32260 + 0x328 + dev * 8
device_struct = *(uintptr_t *)device_slot

再临时改三个位置：

dev_struct[0x5f14] |= 0x20;
dev_struct[0x5e80] |= 0x08;
*(base + 0x5e38650) = 1;

这些 magic number 的定位过程是这样的：

先从 cuDeviceGetAttribute 反汇编看 attribute 逻辑

比如 CU_DEVICE_ATTRIBUTE_GPU_DIRECT_RDMA_SUPPORTED 分支里有：

testb  $0x20,0x5f14(%rdi)
cmpb   $0x0,0x5e38650(...)

这说明它在检查某个 device struct 的 0x5f14 偏移，bit 是 0x20，还检查一个全局 byte。

DMA_BUF_SUPPORTED 分支里也有：

testb $0x8,0x5e80(...)
testb $0x20,0x5f14(...)
cmpb  $0x0,0x5e38650(...)

所以 0x5f14 bit 0x20 和 0x5e80 bit 0x08 是从 attribute 分支直接读出来的。

device table 是从 API wrapper 里推出来的

cuDeviceGetAttribute 的真实实现里有多处：

lea ... # 0x5e32260

然后根据 CUdevice dev ordinal 去索引一个指针表。结合运行时观察，实际是：

device_slot = base + 0x5e32260 + 0x328 + dev * 8;
device_struct = *(uintptr_t *)device_slot;

这个不是符号告诉我的，是看它怎么从 dev ordinal 找内部对象，再用 poke 程序验证出来的。

改之前，RTX 5090 上 dev+0x5f14 是 0x58，改之后变成 0x78，测试结果立刻变成：

GPU_DIRECT_RDMA_WITH_CUDA_VMM = 1
GPU_DIRECT_RDMA_SUPPORTED     = 1
DMA_BUF_SUPPORTED             = 1

cuMemGetHandleForAddressRange(flags=0) = CUDA_SUCCESS

同时 dmesg 开始出现：

nv_dma_buf_create: dma_buf_supported=1 ... mappingType=0 ...

这一步证明了两件事：

kernel 的 dma-buf export 路径本身能被走到；
CUDA API 失败的主要原因是 libcuda 用户态私有 flag 没设置。

第五阶段：做 shim，只作为调试工具

接着写了一个 libcuda.so shim，它会加载真实的 libcuda.so.590.48.01，然后在这些调用前后 patch 私有 device structure：

cuInit
cuDeviceGet
cuDeviceGetAttribute
cuMemGetHandleForAddressRange
cuMemCreate

shim 能让 probe 成功，也能让 perftest 走到：

Calling ibv_reg_mr_ex with dmabuf(offset=0, size=..., addr=..., fd=...)

但是 shim 后来被放弃作为最终方案，原因是：

CUDA runtime 和 NCCL 通过 cuGetProcAddress() 使用很多 driver API；
一个不完整的 libcuda forwarding shim 很容易漏函数；

漏函数时 CUDA runtime / NCCL 会报：

API call is not supported in the installed CUDA driver

所以 shim 只适合作为 reverse engineering / probe 工具，不适合作为 NCCL 性能测试方案。

第六阶段：寻找真正的初始化代码

poke 证明了要改 dev+0x5f14 的 0x20 bit。下一步是找这个字段在哪里初始化。

在 libcuda.so.590.48.01 里搜索对 0x5f14 的引用，最终找到一个非常关键的 device initialization 片段：

0x42d690: movzbl 0x5f14(%rdi),%eax
0x42d697: mov    %eax,%edx
0x42d699: or     $0x40,%edx
0x42d69c: cmpl   $0x8,0xc60(%rdi)
0x42d6a3: mov    %dl,0x5f14(%rdi)

这段代码的意思是：

flags = dev->field_5f14;
flags |= 0x40;
if (dev->field_c60 <= 8) {
    dev->field_5f14 = flags;
    ...
}

RTX 5090 的这个字段本来会被初始化成含 0x40，但不含 0x20。而暴露我们需要的 CUDA attribute 分支需要的是 0x20。

因此最小 patch 很自然：把 or $0x40 改成 or $0x60。也就是保留原来的 0x40，再额外加上 0x20。机器码上：

83 ca 40   ->   83 ca 60

只改中间那个 immediate byte：

file offset 0x42d69b: 0x40 -> 0x60

第七阶段：用 patched libcuda 副本验证

没有直接改系统 libcuda，而是复制了一份：

libcuda-onebyte-patch/libcuda.so.590.48.01
libcuda-onebyte-patch/libcuda.so.1 -> libcuda.so.590.48.01
libcuda-onebyte-patch/libcuda.so   -> libcuda.so.590.48.01

使用方式：

export LD_LIBRARY_PATH=/path/to/libcuda-onebyte-patch:${LD_LIBRARY_PATH:-}

CUDA probe 结果：

GPU_DIRECT_RDMA_WITH_CUDA_VMM = 1
GPU_DIRECT_RDMA_SUPPORTED     = 1
DMA_BUF_SUPPORTED             = 1
cuMemGetHandleForAddressRange(flags=0) = CUDA_SUCCESS

这个 patched copy 比 shim 更适合 NCCL，因为它仍然是完整的官方 libcuda，只是改了一个初始化 immediate。

方法迁移

如果 CUDA 版本变了，显然这个静态 patch 不能假定仍然可用。不过上面 Codex 的分析流程其实足够通用：寻找 cuDeviceGetAttribute 中，某个特定的 attribute 的检查逻辑，找到对应的 bit flag 和全局变量，然后反过来在 libcuda 里搜索这个 bit flag 的初始化位置，最后根据需要修改控制流。

我还让 Codex 帮我生成了一个扫描某些 pattern 并尝试自动 patch 的脚本：auto_patch_libcuda_dmabuf.py。欢迎尝试，但请务必先备份原始 libcuda.so，并且在测试环境中多加验证。

总结

基于 GPT-5.5 的 Codex 在本次调试过程中，呈现出了非常强的分析和调试能力，特别是对于二进制中控制流的理解。我原本完全没有预期它能在一个小时内解决此问题；当然这也要归因于 NVIDIA 没有真的砍掉硬件功能，也没有尝试在驱动里设置什么复杂的障碍。

PERC RAID5 阵列离线后数据救援一例

2026-05-15T18:00:00+08:00

TL;DR:

我不是神仙，RAID5 真坏两块盘是很难救回来的。坏了要及时换盘。
记得备份，备份，备份！
ZFS 在数据恢复中是好文明，压缩、快照、克隆等功能都非常有用。

前两天学校停电倒闸后，杰哥告诉我机房有一台 Dell 服务器的 RAID5 VD 坏了一块盘，让我有空的时候换掉（注：其实它两年前已经开始报告错误了）。但当我今天再登录这台服务器的时候，却发现这个 RAID5 对应的目录已经开始报告 Input/output error 了。再随手一看：

harry@raid-server:~$ mount | grep sda
/dev/sda1 on /data type ext4 (rw,relatime,errors=remount-ro)

harry@raid-server:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       366G  233G  115G  68% /
/dev/sda1        11T  1.6T  8.8T  15% /data

harry@raid-server:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb      8:16   0 446.6G  0 disk
├─sdb1   8:17   0 372.6G  0 part /
├─sdb2   8:18   0     1K  0 part
└─sdb5   8:21   0    74G  0 part
sdc      8:32   0  10.9T  0 disk

原本的 sda 已经从系统中消失，变成了同样大小的 sdc（访问也报 EIO），但挂载的文件系统还有残留。dmesg 中有大量的 megaraid_sas 和 ata 报告的硬盘 IO 错误，还有 ext4 报告的文件系统错误。这个文件系统里有一些比较有价值的数据，这下麻烦了。

数据恢复过程

强制上线 RAID 并导出磁盘镜像

使用 perccli（也就是 storcli 的 Dell OEM 版本）检查硬盘（截取了一些输出），发现了非常坏的消息：

harry@raid-server:~$ sudo perccli64 /call/eall/sall show all
...
----------------------------------------------------------------
DG/VD TYPE    State Access Consist Cache Cac sCC       Size Name
----------------------------------------------------------------
0/0    RAID1  OptL   RW    No      NRWTD -   0FF 446.625 GB
1/1    RAID5  OfLn   RW    No      NRWTD -   0FF  10.914 TB
----------------------------------------------------------------
...
------------------------------------------------------------------------------
EID:Slt DID State DG      Size Intf Med SED PI SeSz           Model    Sp Type
------------------------------------------------------------------------------
32:0    0 Onln    0 446.625 GB SATA SSD N    N  512B SSDSC2KB480G8R      U -
32:1    1 Onln    0 446.625 GB SATA SSD N    N  512B SSDSC2KB480G8R      U -
32:4    4 Onln    1   3.637 TB SATA HDD N    N  512B ST4000NM0033-9ZM170 U -
32:5    5 Failed  1   3.637 TB SATA HDD N    N  512B ST4000NM0033-9ZM170 U -
32:6    6 Failed  1   3.637 TB SATA HDD N    N  512B ST4000NM0033-9ZM170 U -
32:7    7 Onln    1   3.637 TB SATA HDD N    N  512B ST4000NM0033-9ZM170 U -
------------------------------------------------------------------------------

这下大事不妙了，四盘 RAID5 有两块盘（槽位 5 和 6）被控制器标记为了 Failed。正当我觉得已经彻底完蛋，决定开始手工从别的地方恢复一些数据的时候，SMART 数据给了我一些希望：

harry@raid-server:~$ sudo smartctl -a /dev/sdc -d megaraid,5
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
Raw_Read_Error_Rate     0x010f   061   061   ---    Pre-fail  Always       -       7418009
Spin_Up_Time            0x0103   092   092   ---    Pre-fail  Always       -       0
Start_Stop_Count        0x0032   100   100   ---    Old_age   Always       -       138
Reallocated_Sector_Ct   0x0133   021   021   ---    Pre-fail  Always       -       13048
Seek_Error_Rate         0x000f   090   061   ---    Pre-fail  Always       -       1116579259
Power_On_Hours          0x0032   027   027   ---    Old_age   Always       -       64444
Spin_Retry_Count        0x0013   100   100   ---    Pre-fail  Always       -       0
Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       138
End-to-End_Error        0x0032   100   100   ---    Old_age   Always       -       0
Reported_Uncorrect      0x0032   095   095   ---    Old_age   Always       -       5
Command_Timeout         0x0032   100   095   ---    Old_age   Always       -       4295032838
High_Fly_Writes         0x003a   100   100   ---    Old_age   Always       -       0
Airflow_Temperature_Cel 0x0022   069   052   ---    Old_age   Always       -       31 (Min/Max 30/36)
G-Sense_Error_Rate      0x0032   100   100   ---    Old_age   Always       -       0
Power-Off_Retract_Count 0x0032   100   100   ---    Old_age   Always       -       132
Load_Cycle_Count        0x0032   056   056   ---    Old_age   Always       -       89153
Temperature_Celsius     0x0022   031   048   ---    Old_age   Always       -       31 (0 14 0 0 0)
Hardware_ECC_Recovered  0x001a   015   005   ---    Old_age   Always       -       7418009
Reallocated_Event_Count 0x0032   000   000   ---    Old_age   Always       -       13113
Current_Pending_Sector  0x0012   080   080   ---    Old_age   Always       -       3336
Offline_Uncorrectable   0x0010   100   100   ---    Old_age   Offline      -       0
UDMA_CRC_Error_Count    0x003e   200   200   ---    Old_age   Always       -       0
Head_Flying_Hours       0x0000   100   253   ---    Old_age   Offline      -       39850 (101 109 0)
Total_LBAs_Written      0x0000   100   253   ---    Old_age   Offline      -       5038718942
Total_LBAs_Read         0x0000   100   253   ---    Old_age   Offline      -       1089162748411

harry@raid-server:~$ sudo smartctl -a /dev/sdc -d megaraid,6
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
Raw_Read_Error_Rate     0x010f   081   063   ---    Pre-fail  Always       -       143337086
Spin_Up_Time            0x0103   093   092   ---    Pre-fail  Always       -       0
Start_Stop_Count        0x0032   100   100   ---    Old_age   Always       -       102
Reallocated_Sector_Ct   0x0133   100   100   ---    Pre-fail  Always       -       0
Seek_Error_Rate         0x000f   091   060   ---    Pre-fail  Always       -       1395588958
Power_On_Hours          0x0032   018   018   ---    Old_age   Always       -       72016
Spin_Retry_Count        0x0013   100   100   ---    Pre-fail  Always       -       0
Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       100
End-to-End_Error        0x0032   100   100   ---    Old_age   Always       -       0
Reported_Uncorrect      0x0032   094   094   ---    Old_age   Always       -       6
Command_Timeout         0x0032   100   100   ---    Old_age   Always       -       0
High_Fly_Writes         0x003a   100   100   ---    Old_age   Always       -       0
Airflow_Temperature_Cel 0x0022   068   052   ---    Old_age   Always       -       32 (Min/Max 31/37)
G-Sense_Error_Rate      0x0032   100   100   ---    Old_age   Always       -       0
Power-Off_Retract_Count 0x0032   100   100   ---    Old_age   Always       -       97
Load_Cycle_Count        0x0032   041   041   ---    Old_age   Always       -       119629
Temperature_Celsius     0x0022   032   048   ---    Old_age   Always       -       32 (0 16 0 0 0)
Hardware_ECC_Recovered  0x001a   021   003   ---    Old_age   Always       -       143337086
Reallocated_Event_Count 0x0032   000   000   ---    Old_age   Always       -       21845
Current_Pending_Sector  0x0012   100   100   ---    Old_age   Always       -       0
Offline_Uncorrectable   0x0010   100   100   ---    Old_age   Offline      -       0
UDMA_CRC_Error_Count    0x003e   200   200   ---    Old_age   Always       -       0
Head_Flying_Hours       0x0000   100   253   ---    Old_age   Offline      -       39054 (140 124 0)
Total_LBAs_Written      0x0000   100   253   ---    Old_age   Offline      -       5257600282
Total_LBAs_Read         0x0000   100   253   ---    Old_age   Offline      -       1497495161858

虽说这两块硬盘的数据都已经非常糟糕了（除了上面的数据，还有一大堆 error log），但至少看起来 6 号盘还有救（Reallocated_Sector_Ct 和 Current_Pending_Sector 都是 0）。于是我强制让 6 号盘上线：

harry@raid-server:~$ sudo perccli64 /c0/e32/s6 set online

幸好命令成功了，此时 sdc 变成了可读的状态！这已经非常幸运了，如果阵列无法上线，我将不得不对每块物理磁盘分别镜像，并在拯救文件系统之前先尝试组装 RAID。

话虽如此，我当然是不敢挂载文件系统的，只读也不敢。我立刻找了另一台空间足够的 ZFS 的服务器，新建了一个 dataset 用 NFS 挂到这台服务器上。然后使用 ddrescue 来对 sdc 进行镜像：

ddrescue -d -D -n -r0 -v --ask -S -c 2048 /dev/sdc /mnt/backup/data/raid.img /mnt/backup/data/raid.map

其中：

img 文件是获得的镜像，map 文件是读取状态的记录文件，方便中断后继续。
-d, -D：对于源和目的都使用直接 IO（O_DIRECT），绕过内核缓存。生成镜像时读写都是一次性的，没必要污染缓存；有缓存还会导致速度统计不准确。
-n, -r0：跳过 scrape 阶段，不对坏块进行重试，先把容易读出的数据复制出来。
-v, --ask：显示详细的进度信息，并且在开始之前确认参数。
-S：写入稀疏文件，一定要打开，否则会导致非常大的空间浪费。
-c 2048：把 IO 的粒度改成 2048 扇区，即 1MB。

ddrescue 在顺利地读取了大概 6TB 的数据后（没有遇到坏块），就卡住再也不动了。这时我从 dmesg 中又看到了新的、极其大量的错误：

[  +0.011405] megaraid_sas 0000:e1:00.0: 252132 (832085413s/0x0002/FATAL) - Unrecoverable medium error during recovery on PD 04(e0x20/s4) at e8d85fbe
[  +0.011081] megaraid_sas 0000:e1:00.0: 252133 (832085413s/0x0002/FATAL) - Unrecoverable medium error during recovery on PD 04(e0x20/s4) at e8d85fbe
[  +0.011220] megaraid_sas 0000:e1:00.0: 252134 (832085413s/0x0002/FATAL) - Unrecoverable medium error during recovery on PD 04(e0x20/s4) at e8d85fbe

晴天霹雳！本来状态良好的 4 号盘也出现了问题。我再尝试读取它的 SMART 信息，已经完全得不到任何响应（但 perccli 还显示它正常）。看来，要么控制器进入了某些不正确的状态，要么就是这块盘也彻底坏了。在尝试重启机器继续之前，我首先进行了一些恢复的尝试。

从不完整的磁盘镜像恢复文件

在接收备份侧，我们已经能看到大小不完整的 raid.img 文件了，它是稀疏的（全 0 部分不实际分配空间），并且我的 ZFS 还开启了压缩，因此实际占用的空间要小得多。RAID 的大小是大概 10TB，我们已经复制出了 6TB，在稀疏化后，它的体积是 1.54TB（此为 ZFS 报告的 logical used），经过 ZSTD 压缩后，实际占用只有 1.3TB（此为 ZFS 的 used）。

保险起见，在做任何事情之前，我先 snapshot 并 clone 了一份新的数据集，这样就能随便进行写入操作来尝试恢复，而如果有问题就可以直接回滚；并且如果原始 RAID5 能恢复，我也可以在这个 snapshot 上继续进行写入。

由于磁盘上的分区是 GPT 的，可以尝试用 gdisk 来分析：

# gdisk raid.img
GPT fdisk (gdisk) version 1.0.10

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): p
Disk raid.img: 23438819295 sectors, 10.9 TiB
Sector size (logical): 512 bytes
Disk identifier (GUID): [REDACTED]
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 23438819294
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     23438819294   10.9 TiB    8300

毫无意外地是损坏的，因为镜像并不完整，但还是能看到分区。于是尝试从分区起始处挂载：

# losetup -o 1048576 -r /dev/loop1 raid.img
# mount -o ro /dev/loop1 /mnt/recovery

但挂不上，日志说：

[May14 22:23] loop1: detected capacity change from 0 to 11719479296
[  +3.289364] mount: attempt to access beyond end of device
[May14 22:24] EXT4-fs (loop1): bad geometry: block count 2929852155 exceeds size of device (1464934912 blocks)

这比较好解决，我 truncate -s 了一下这个镜像，让它的大小延伸到分区末尾对应的位置（这也是稀疏的，因此瞬间就能完成）。然后再重新尝试，这次能挂上了！但是尝试 ls 根目录时，获得了一大堆错误：

# ls -alih /mnt/recovery
ls: cannot access 'harry': Bad message
ls: cannot access 'docker': Bad message
...
total 121G
        2 drwxrwxrwx 24 root root 4.0K May 30  2025 .
  1831425 drwxr-xr-x  5 root root 4.0K May 14 22:18 ..
        ? d?????????  ? ?    ?       ?            ? docker
151519233 drwx--x--x 14 root root 4.0K Mar 26  2021 docker.old
        ? d?????????  ? ?    ?       ?            ? harry
 31195137 drwxr-xr-x 10 root root 4.0K Nov  2  2020 k8s
       11 drwxrw-rw-  2 root root  16K Aug  3  2020 lost+found
  5439489 drwxr-xr-x 10 1006 1006 4.0K Jul 26  2024 static

# dmesg -H 
[May14 22:31] loop1: detected capacity change from 0 to 23438817247
[May14 22:32] EXT4-fs (loop1): mounted filesystem [REDACTED] ro without journal. Quota mode: none.
[  +2.797028] EXT4-fs error (device loop1): ext4_lookup:1819: inode #229244929: comm ls: iget: checksum invalid
[  +0.001432] EXT4-fs error (device loop1): ext4_lookup:1819: inode #335085569: comm ls: iget: checksum invalid
[  +0.001535] EXT4-fs error (device loop1): ext4_lookup:1819: inode #252116993: comm ls: iget: checksum invalid
[  +0.099194] EXT4-fs error (device loop1): ext4_lookup:1819: inode #262864897: comm ls: iget: checksum invalid
[  +0.017124] EXT4-fs error (device loop1): ext4_lookup:1819: inode #342818817: comm ls: iget: checksum invalid
[  +0.023974] EXT4-fs error (device loop1): ext4_lookup:1819: inode #187039745: comm ls: iget: checksum invalid
[  +0.019762] EXT4-fs error (device loop1): ext4_lookup:1819: inode #265945089: comm ls: iget: checksum invalid

似乎这些目录项指向的 inode 或相关元数据没有在复制过来的镜像范围中，因此无法访问了。很不幸的是，我的目录（harry）也在其中。Claude 教我用 debugfs 的 inode_dump 来查看 inode 的内容，然而：

# debugfs /dev/loop1
debugfs 1.47.2 (1-Jan-2025)
/dev/loop1: Block bitmap checksum does not match bitmap while reading allocation bitmaps
debugfs:  inode_dump 229244929
inode_dump: Filesystem not open

看来并不奏效。我尝试对着镜像运行了 e2fsck -fy，它确实修理了大量的问题。再次 mount 时，EXT4 就不再报那些错误了，然而这些文件夹同样再也找不回来了；对应地，文件系统使用的空间缩小到了 1TB 不到，说明 fsck 真的删掉了很多东西。

从几乎完整的磁盘镜像恢复文件

那怎么办？在我准备掏出 photorec 作为最后手段前，抱着死马当活马医的心态，我强制重启了一下这台有 RAID5 磁盘的服务器。没想到重启完之后，阵列状态又变成了可用（当然，磁盘 5 依旧是坏的）。于是我继续开始运行 ddrescue，静候花开。

我原本决定在第一次运行结束之后，去掉 -n -r0 重新运行一遍 ddrescue，让它对原本读取不成功的部分再尝试一下。然而第二天起床时，发现它卡在了 backwards pass，并且又触发了类似的 megaraid_sas 错误。此时它有 1MB 多的 non-trimmed 数据，和 53MB 的 non-tried 数据，剩下都已经成功读取了，大小也能对上了。考虑到我们的磁盘其实非常稀疏，我直接挂上了这个镜像，没想到一点错误也没有，连 e2fsck 也没有发现任何问题。于是这次数据救援就宣告结束了。我们把其中有用的数据复制出来，恢复了大部分的服务；其他数据也就留在了这个 RAID1 ZFS 上作为存档（和最后的备份）。

其他

ZFS 异常性能诊断

在我一开始用 ddrescue 从 RAID 设备读出镜像到远端 NFS 时，IO 性能非常差：zpool iostat 报告只有 40MB/s 左右。考虑到这个 pool 是两块盘的镜像，每块盘上的 IO 应该和 pool 一致。虽说 HDD 的 IOPS 比较差，但 ddrescue 原理上在大部分时间产生的 IO 都应该是连续的，完全没道理会这么慢。

于是我进行了如下的尝试：

zfs set sync=disabled：zpool 写入速度变成了 50MB/s；
ddrescue -c 2048（把 IO 的粒度改成 2048 扇区，即 1MB）：写入速度变成了 60MB/s；
zfs set recordsize=1M 并且给 NFS 设置挂载选项 rsize=1048576,wsize=1048576：速度上升到 75MB/s（然而收益可能并非来自于此，见下）。

尽管确实获得了一些提升，但依旧离我期待的性能（基本打满目标硬盘的带宽）相差甚远。

首先看一下 ddrescue 是不是真的在连续写入：

# strace -p $(pgrep ddrescue) -e t=write
write(4, "[REDACTED]"..., 1048576) = 1048576
write(1, "\r\33[A\33[A\33[A\33[A\33[A\33[A     ipos:   "..., 95) = 95
write(1, "     opos:    7974 GB, non-scrap"..., 76) = 76
write(1, "non-tried:    4026 GB,  bad-sect"..., 76) = 76
write(1, "  rescued:    7973 GB,   bad are"..., 76) = 76
write(1, "pct rescued:   66.44%, read erro"..., 76) = 76

看起来没问题。然而到 ZFS 这一侧，IO 模式就变成了：

# zpool iostat 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
mypool      2.88T  13.5T    172    587   692K  42.8M
mypool      2.88T  13.5T    239    643   959K  81.2M
mypool      2.88T  13.5T    210    560   842K  70.1M
mypool      2.88T  13.5T    237    582   949K  72.9M
mypool      2.88T  13.5T    204    532   819K  70.0M
（省略若干行大概 75 MB/s 左右的写入）
mypool      2.88T  13.5T    231    596   925K  76.7M
mypool      2.88T  13.5T    240    656   961K  83.2M
mypool      2.88T  13.5T    212    535   849K  67.3M
mypool      2.88T  13.5T    214    599   857K  79.2M
mypool      2.88T  13.5T    220    635   881K  80.0M
mypool      2.88T  13.5T    130    427   622K  39.7M
mypool      2.88T  13.5T      0  12.2K      0   295M
mypool      2.88T  13.5T      0  11.5K      0   282M
mypool      2.88T  13.5T    205    709   822K  72.3M
mypool      2.88T  13.5T    282    778  1.10M  97.3M
mypool      2.88T  13.5T    269    744  1.05M  94.1M
mypool      2.88T  13.5T    238    643   955K  81.3M
mypool      2.88T  13.5T    215    551   863K  71.8M
mypool      2.88T  13.5T    230    610   923K  79.0M
mypool      2.88T  13.5T    205    559   822K  71.9M
mypool      2.88T  13.5T    237    639   950K  81.8M
...（重复以上模式）

我把这些内容复制给 Claude 分析，它说 recordsize=1M 其实没有生效：

正常行: 227 read / 674 write / 910K / 84.9M

Read  IO size: 910K / 227  ≈ 4.0 KB   ← 和之前完全一样
Write IO size: 84.9M / 674 ≈ 126 KB   ← 还是 128K，不是 1MB！

写入一个 128KB 数据块的完整流程：

1. 从磁盘读取父级 indirect block（~4KB）   ← 你看到的 read IOPS
2. 在 ARC 中更新 block pointer
3. COW 写新的数据块（128KB）               ← 你看到的 write IOPS
4. COW 写新的 indirect block（~4KB）        ← 计入 write IOPS

损失去哪了？
每次写 128KB 数据，还要额外做一次 4KB 随机读
HDD 随机读：~100-150 IOPS ≈ 约 200-230 IOPS 的 overhead
这些随机读直接消耗了磁盘的寻道时间

这确实很有道理。但其实此时的读写比例（略高于 1:3）还要远高于它描述的场景（每写 132K 读 4K），那么多出来的这么多 4K 读 IO 是在做什么呢？这次我没有问 LLM 就意识到了问题：接收镜像的 dataset 继承了原本用于节省 home 目录空间占用的 dedup 开关，这些 IO 其实是写入之前在读取 pool 的 DDT 哈希表。然而在我们的场景下（要尽快完成镜像），dedup 的意义并不大。

于是我暂时停止传输，关闭 dedup，并进行了 zfs send | zfs recv 来重新创建整个 dataset。然后再继续进行传输：

              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
mypool      3.27T  13.1T      0  12.3K      0   302M
mypool      3.27T  13.1T      0  12.5K      0   308M
mypool      3.27T  13.1T      0  12.6K      0   312M
mypool      3.27T  13.1T      0  12.5K      0   309M
mypool      3.27T  13.1T      0  12.5K      0   310M
mypool      3.27T  13.1T      0  12.5K      0   308M
mypool      3.27T  13.1T      0  12.2K      0   298M

这看起来正常多了！虽然此时的每个写 IO 大小也只有 24K 左右，但很明显它们已经是连续的了，因此能比较充分地利用 HDD 的带宽。果然 dedup 总是影响 ZFS 性能的万恶之源，尤其是在机械硬盘上。

在 RTX 5090 (SM120) 上补全 NVFP4 量化相关 kernel

2026-04-14T00:45:00+08:00

本文部分内容由 GPT 5.4 根据大纲写成，我进行了校对和风格修改。如仍有生硬之处，敬请谅解。本文中的 vibe coding 过程使用 GPT 5.4 / Claude Opus 4.6 完成，使用了 Cursor 和 Claude Code 作为不同阶段的辅助工具。

最近组里同学在折腾 5090 上的原生低精度预训练，换句话说，不是用 BF16 训练完再量化，而是在训练时就是用更低精度的格式（如 FP8 甚至 FP4，不过 attention 层还是 BF16）。英伟达的 Transformer Engine 提供了许多不同数据格式的 recipe 的支持，也就是对于每一层的前向、反向，究竟是用什么数据格式，并为此提供了优化过的 kernel。然而虽然它声称为 Blackwell 优化，但其实指的是 SM100 家族，也就是 B200 / GB200 这类数据中心卡；而 RTX 5090 这样的消费级卡（SM120 家族，还包括 RTX Pro 专业卡、DGX Spark 等），并不存在开箱即用的体验。

MXFP8 的部分似乎还好，只需修改编译选项，为 SM120 编译 kernel 就能工作。但一到 Blackwell 专属的 NVFP4 部分，我们立刻就遭遇了老黄精准的刀法。受到老板的感召，我花了不到两天的时间，几乎完全靠 vibe coding，补全了 TE 2.12 在 SM120 家族上的 NVFP4 kernel 支持，主要包括两个技术：stochastic rounding（随机舍入）和 Random Hadamard Transform GEMM（随机 Hadamard 变换矩阵乘）。

所有的代码都已经在 fp4_sm120 开源。本文简单记录过程和一些心得。

FP4 量化技术

显然，FP4 的动态范围和精度都很小。以 NVFP4 用的 E2M1 为例，能表示的数（绝对值）只有 0, 0.5, 1, 1.5, 2, 3, 4, 6。除了常见的 block-wise scale 以外，Transformer Engine 在 NVFP4 的训练 recipe 里增加了以下的两个技术，来提供更高的训练稳定性和更好的精度。

随机舍入

目前硬件上进行量化时，舍入方法（也是 IEEE 754 规定的）通常是 round-to-nearest，也就是把一个值 x 量化成离它最近的可表示值。然而，当可表示的值只有这么几个，并且间距并不相同时，这样很可能引入系统性的误差。比如 1.6 和 2.4 都会被量化成 2，

而随机舍入（stochastic rounding）的做法是，如果一个值 x 落在两个可表示值 a 和 b 之间，那么应该按比例随机地向上或向下取：

P(round to b) = (x - a) / (b - a)

这样做的好处是，量化的行为在期望上是无偏的。在 SM100 上，NVIDIA 提供了 cvt.rs.satfinite.e2m1x4.f32 这条指令来实现硬件级别的随机舍入，它的格式是 cvt.rs.satfinite.e2m1x4.f32 %0, {%1, %2, %3, %4}, %5，其中 %1 到 %4 是四个输入的 FP32 值，%5 是一个随机 32 位整数，输出 %0 是四个值量化成 NVFP4 后 pack 成一个 16-bit 寄存器的结果。这条指令一次性能对四个数进行量化；当然，所有输入值需要事先经过 block-wise scale 处理，本身不能超出 NVFP4 的表示范围。在 Transformer Engine 的 ptx.cuh 中，如下的函数使用内联 PTX 汇编的方式，调用此指令实现了量化：

mul_cvt_bf16_to_fp4_4x_with_stochastic_rounding
mul_cvt_fp32_to_fp4_4x_with_stochastic_rounding
mul_cvt_bf16_to_fp4_8x_stochastic_rounding

随机 Hadamard 变换

随机 Hadamard 变换（Random Hadamard Transform，RHT）是一种在量化前对数据进行随机旋转的技术。它的主要作用是将原本集中在少数通道上的异常值（outlier）打散，使得后续的 block-wise scale 更容易工作。虽然形式上它能写成一个很大的矩阵乘法 $G_{\text{rht}} = GH$（被称为 RHT GEMM），但实际实现上 $H$ 是一个很小（如 $16 \times 16$）Hadamard 矩阵（元素均为 +1 或 -1 的正交矩阵），作用在沿着最后一个维度分块后的 $G$ 上。换句话说，相当于沿着最后一维把 $G$ 切成许多个 16 元素的小块，每个小块都被一个（每次迭代随机生成的）Hadamard 矩阵所打散。这使得 RHT GEMM 并非一个真正 $O(mnk)$ 的 GEMM 操作，而是降低到了 $O(\vert G \vert)$ 的复杂度，因此它是个 memory bound 的算子。

Transformer Engine 在 SM100 上为 RHT 提供了专门的 kernel，叫做 rht_gemm_ntt_w_sfc。它的输入是高精度（如 BF16）的矩阵，输出是 NVFP4 的矩阵；在这个 kernel 里，随机旋转和量化被融合了。也就是说，输入值在被乘以 Hadamard 矩阵打散以后，会直接调用前面提到的 cvt.rs 指令进行随机舍入量化。因此，RHT kernel 的实现除了 GEMM 本身，也依赖于 cvt.rs 的支持。而这里的乘法使用的是 WGEMM，也就是基于 warp-group 的矩阵乘法，依赖于 SM100 上的 tcgen05 指令。

RTX 5090 (SM120) 现状

虽然 SM120 支持 NVFP4 矩阵乘法（由 CUTLASS / cublas 提供），但要用上完整的 NVFP4 recipe，还有以下的问题：

SM120 架构不存在 cvt.rs.satfinite.e2m1x4.f32 指令。事实上，它完全不支持 .rs 指令后缀。
SM120 架构虽然配备了第五代 Tensor Core，但不支持 SM100 上的 tcgen05 指令 / UMMA / TMEM 路径，shared memory 也更小（99KB vs 232KB）。因此 Transformer Engine 现有的 RHT kernel 完全无法使用，只能改走 Hopper WMMA 的实现。

但这些并不是不可逾越的障碍。前者完全可以通过软件来模拟，而后者也可以 fallback 到更古老的实现。考虑到这两个 kernel 都是 memory bound 的，大概也不会有什么性能损失。

随机舍入指令：（半）软件模拟

通过多次尝试，我（通过古法）发现 SM120 上最接近 cvt.rs.satfinite.e2m1x4.f32 的指令是 cvt.rn.satfinite.e2m1x2.f32，它一次只能处理两个输入值，并且不支持随机舍入。这并不困难，因为随机舍入的核心其实就是在输入值上加一个小噪声，使得它在两个可表示值之间随机变化，而后依然可以使用 round-to-nearest 的指令来实现随机舍入的效果。具体地，先根据 E2M1 的 ULP 给每个输入值加上一个对称的小噪声，再调用两次 cvt.rn.satfinite.e2m1x2.f32，最后手工把结果 pack 成原来 e2m1x4 的布局。这样虽然底层不是原生 cvt.rs，但最终满足的概率分布是一致的。

除了依赖 SM120 指令的版本，我还要求 Claude 生成了一个纯软件版本（不使用任何 cvt 指令），方便在别的架构（如果还有的话）上验证语义。我同时也增加了 SM100 的原生实现来对拍，结果是：

SM120 polyfill 和原生 cvt.rs 可以做到 bit-exact（控制提供的随机 bit 一致）；
纯软件版本在统计意义上和 cvt.rs 等价；

在这过程中，我被各种细节坑过，特别是指令的输入、输出顺序反复修改了好几遍。最终是通过在 SM100 上对拍了几组数据，才确保了实现的正确性。令我震惊的是，一个有错误输出顺序的实现，居然能让真实训练的 loss 曲线在前几个 iteration 上下降不少，到后面才暴露出问题。

在接入 RS 支持后，NVFP4 的训练稳定性有了显著的提升，并且性能只有非常轻微的下降。毕竟它是个 element-wise 的算子，这也是预期之内的。

RHT GEMM：从头重写

接下来，需要把 Transformer Engine 的 rht_gemm_ntt_w_sfc 在 SM120 上重写。具体做法包括：

用 WMMA 分块做 16x16 Hadamard 矩阵乘法；
NVFP4 stochastic rounding 直接复用上一节提供的 polyfill；

在 RTX 5090 上，较大尺寸的测试能跑到大约 1270 GB/s，差不多是显存峰值带宽的 71%。我也把它拿到 SM100 上和 TE 做了二进制对拍；在 fast-math 模式下，数值对比只需要放宽到 $<0.1\%$ 的 FP4 差异容忍度就能通过。

当然这个过程也绝非一帆风顺：虽然 GEMM vibe 起来很轻松，但还是有不少细节经过了多次修复，尤其是对 NaN 的传播处理花费了不少时间。我也要求 Claude 自己通过 nsys 和 ncu 来分析性能表现，进行了多轮优化，才获得了目前的性能数据。

在 vibe 完成后，我们也把 RHT GEMM kernel 接入了 TE 的训练 recipe，然而它的表现却十分诡异：性能有符合预期的少许下降，然而 loss 并没有显著变好，反而是最后一层输出的范数剧烈飙升。我一开始以为是实现问题，就 PUA AI 反复进行验证都没看出问题；直到后面我在 GB200 上用原版 TE 测试了一下，发现几乎完美复刻了 5090 上的曲线，才意识到大概不是 kernel 的问题。

Vibe Coding 过程

注：这一节基本也是 vibe 出来的，所以味比较冲。

其实本来我让 Claude 和 ChatGPT 各自实现了一个版本，仓库早期的提交里，甚至直接就有 cvt.chatgpt.cu 和 cvt.claude.cu 两个文件。我一开始做的事情非常朴素：把背景、目标指令和期望语义喂给模型，让它先给出一个能编译、能跑 benchmark、最好还能带上测试的初版。这个阶段 AI 的效率确实很高，尤其适合：

快速铺出大块 CUDA/C++ 样板代码；
把分散的 PTX 细节和 wrapper 函数拼起来；
顺手生成一堆测试和 benchmark 骨架。

但接下来就进入了传统工程阶段。很多 bug 其实都不是“算法错了”，而是非常 GPU、非常细碎的那种：

随机数取法有 bias；
cvt 的操作数顺序写反了；
pack 出来的 nibble 顺序不对；
Philox counter layout 和 TE 的实现并不一致；
fminf / fmaxf 会吞掉 NaN，而 reference 选择保留 NaN；
fast-math 模式下，本来就不该追求逐 bit 一致。

也就是说，AI 很适合先把 70 分的代码搭出来；但从 70 分到能真正替代原始 kernel，靠的还是对拍、读 PTX、看硬件行为，以及不断修正那些一眼看不出来的小坑。

时间线

从提交记录来看，这个项目的推进速度其实相当符合“先 vibe 出原型，再用测试把它打磨成工程”的模式：

时间	提交	发生了什么
03-24 14:43	`e4419c8`	初始提交，生成 `cvt.chatgpt.cu` 和 `cvt.claude.cu` 两个版本。
03-24 15:48	`1a53719`	修掉 `rand_byte` 的 bias，说明问题已经从“能跑”进入“语义是否正确”。
03-24 21:30	`9c5ba8a` / `d162a57`	一边修 PTX 操作数顺序，一边开始加入 SM100 对拍测试。
03-25 00:47	`0e25ab8`	第一版能在 RTX 5090 上工作的 RHT GEMM 跑起来了。
03-25 01:03	`9cd64ab`	做了 multi-group-per-block 优化，把带宽推到约 `1270 GB/s`。
03-25 12:29	`1500443`	把自己的 kernel 和 TE reference 放进同一个 binary，在 SM100 上正面对拍。
03-25 23:21	`705eecc`	修 NaN 传播和 Philox RNG 布局，开始解决真正影响训练语义的细节。
03-25 23:49	`36de459`	给 fast-math 模式加上 `<0.1%` 容忍度，项目基本收尾。

如果把上面这些 commit 连起来看，会发现这次工作并不是“一句话让 AI 自动写完了 NVFP4 kernel”，而更像是：先让模型把原型和脚手架堆出来，然后人拿着真实硬件、reference kernel 和测试，一路把语义修到能用。

总结

这次 vibe coding 整体还算顺利，尤其是考虑到我对 NVFP4 相关的细节并不熟悉。现代 AI 模型在代码实现、性能分析方面的能力也让我比较满意。然而我也深刻感受到，（至少目前）在此类工程问题上，人类经验依旧是不可或缺的；否则，只会变成白白浪费 token 让模型在一些细节上反复纠结，生产出一坨又一坨的意大利面。

在 RTX 5090 上启用 PCIe P2P 通信支持

2026-03-22T22:45:00+08:00

免责声明： 本文涉及对 GPU 驱动的修改，作者不对任何因此产生的后果负责。

注：在写完之后，我在知乎上找到了一篇内容几乎一样的文章《(并非)破解驱动榨干4090(5090)的最后一丝性能》。如果早点读到，可能我就不重复造这个轮子了。

PCIe P2P 访问是 GPU 之间进行通信的重要途径。它使得不同设备间的通信无需经过内存中转，直接通过 PCIe 总线传输，在很多时候能显著提升通信性能。当然，现实中的 P2P 性能也受到很多因素影响：比如 AMD EPYC 7002 家族的 PCIe Root Complex 转发性能就比较差；而如果主板上有 PCIe Switch 芯片，那么很多情况下几乎就能打满线速。但总体来说，P2P 的性能几乎总是比经过 GPU-内存-GPU 的路径要好。

然而众所周知，老黄精准的刀法砍掉了所有家用级显卡的 PCIe P2P 通信支持。换句话说：

harry@gpu:~$ nvidia-smi topo -p2p r
        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7
 GPU0   X       GNS     GNS     GNS     GNS     GNS     GNS     GNS
 GPU1   GNS     X       GNS     GNS     GNS     GNS     GNS     GNS
 GPU2   GNS     GNS     X       GNS     GNS     GNS     GNS     GNS
 GPU3   GNS     GNS     GNS     X       GNS     GNS     GNS     GNS
 GPU4   GNS     GNS     GNS     GNS     X       GNS     GNS     GNS
 GPU5   GNS     GNS     GNS     GNS     GNS     X       GNS     GNS
 GPU6   GNS     GNS     GNS     GNS     GNS     GNS     X       GNS
 GPU7   GNS     GNS     GNS     GNS     GNS     GNS     GNS     X

这里的 GNS 表示 GPU Not Supported。但真的是硬件不支持吗？似乎并不是这样。

前置工作

在计划使用 P2P 通信之前，首先要确认一些前置条件是否具备：

硬件拓扑：通常来说，同一个服务器 CPU Socket 上安装的 GPU 之间共享同一个 Root Complex，一般都能支持 P2P；跨 socket 通常也是可行的。而如果有 PCIe Switch，则可能有更复杂的拓扑（比如特定 GPU 之间有更高的带宽）。nvidia-smi topo -m 输出的结果可能受很多因素的影响：如在我的 AMD EPYC 9354 上，给出的所有结果都是 SYS，这和 CPU 配置成了 NPS4 有关；如果启用 NPS2，那么相邻的两个 GPU 之间会就变成 NODE；可以类推如果使用 NPS1，那么同一个 socket 上的四个 GPU 应当都是 NODE。
BIOS 配置：
- 关闭 PCIe ACS (Access Control Service)，建议关闭 IOMMU（可在内核选项中配置 iommu=pt 绕过）和虚拟化。这些功能虽然能提供更高的安全性，但也会让 PCIe 上的通信变得更复杂，很可能导致 P2P 性能急剧下降或者完全不可用。
- 启用 PCIe Resizable BAR (ReBAR) 支持。

魔改驱动

著名 iPhone 越狱黑客 Geohot 在几年前发起了一个精简的深度学习框架 tinygrad，力争通过最小的软件 overhead 实现深度学习框架。而这个框架的一个副产品就是，魔改过的 NVIDIA 的开源 GPU 驱动（tinygrad/open-gpu-kernel-modules），在不少家用级显卡上启用了 PCIe P2P 通信支持。所有的修改只有不到一百行的改动，大部分都是关掉判断，或者 patch 掉某些函数虚表，使用对应的数据中心卡的实现。所以可以推断，很大程度上，这些限制完全是来自于软件。真有你的，老黄。

虽说这个仓库的最新版本只到 565，另有高人搞出了基于 585 和 595 的版本（aikitoria/open-gpu-kernel-modules），顺便也就支持了 RTX 5090，其实核心改动基本还是差不多。

作者给出的安装脚本有些简单粗暴，直接当场构建模块并 insmod。这显然有点脏了。考虑到目前的模块都是 dkms 安装的，最好的办法其实是解包 NVIDIA 提供的 nvidia-kernel-open-dkms 包并替换文件。如果不打算频繁更新驱动的话，也可以采用一种略微少脏一些的办法：

# 安装官方驱动
apt install nvidia-driver-pinning-590.48.01
apt install nvidia-open=590.48.01-1 nvidia-kernel-open-dkms=590.48.01-1
# 卸载模块
rmmod nvidia_drm nvidia_modeset nvidia_uvm nvidia
# 下载魔改驱动
git clone git@github.com:aikitoria/open-gpu-kernel-modules.git
# 备份原有的驱动源代码
cd /usr/src/nvidia-590.48.01/
mkdir backup
mv kernel-open src backup/
# 打补丁
cd ~/open-gpu-kernel-modules/
cp -r kernel-open src /usr/src/nvidia-590.48.01/
# 重新构建驱动并安装
dkms build -m nvidia/590.48.01 --force
dkms install -m nvidia/590.48.01 --force
# 重新加载模块
modprobe nvidia

此时可以再次测试，是否已经化腐朽为神奇：

harry@gpu:~$ nvidia-smi topo -p2p r
        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7
 GPU0   X       OK      OK      OK      OK      OK      OK      OK
 GPU1   OK      X       OK      OK      OK      OK      OK      OK
 GPU2   OK      OK      X       OK      OK      OK      OK      OK
 GPU3   OK      OK      OK      X       OK      OK      OK      OK
 GPU4   OK      OK      OK      OK      X       OK      OK      OK
 GPU5   OK      OK      OK      OK      OK      X       OK      OK
 GPU6   OK      OK      OK      OK      OK      OK      X       OK
 GPU7   OK      OK      OK      OK      OK      OK      OK      X

此外，从 lspci 的输出也可以看到，此时 5090 映射了所有显存到 BAR（如下的 Region 1）：

01:00.0 VGA compatible controller: NVIDIA Corporation GB202 [GeForce RTX 5090] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: NVIDIA Corporation Device 2059
        Physical Slot: 5
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 



性能测试

带宽延迟测试

CUDA Samples 中的 p2pBandwidthLatencyTest 可以测试 GPU 之间的通信带宽和延迟。启用 P2P 前：

Unidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4      5      6      7
     0 1528.86  31.57  31.12  30.91  28.82  29.39  29.51  29.86
     1  30.66 1556.32  31.00  30.29  29.12  29.57  29.39  29.87
     2  30.69  31.64 1556.27  30.29  31.22  31.26  31.37  31.14
     3  31.12  31.58  30.96 1550.15  29.04  29.55  29.41  29.69
     4  29.99  31.49  31.22  29.60 1553.28  31.22  31.44  31.13
     5  30.18  31.72  31.42  29.80  30.61 1559.38  31.42  29.78
     6  30.31  31.72  31.55  29.96  30.47  31.38 1559.38  30.73
     7  30.03  31.39  31.04  29.63  30.83  31.05  31.41 1553.18

Bidirectional P2P=Disabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4      5      6      7
     0 1528.82  32.56  32.29  32.40  31.64  31.93  31.88  31.96
     1  32.53 1540.88  32.61  32.53  31.77  32.06  32.08  31.68
     2  32.28  32.52 1539.34  32.18  32.21  32.29  32.23  32.23
     3  32.47  32.46  32.08 1540.88  31.50  31.80  31.89  31.83
     4  31.54  32.03  32.36  31.41 1537.82  32.26  32.53  32.22
     5  31.66  32.23  32.38  31.81  32.16 1539.36  32.52  32.07
     6  31.80  32.19  32.53  31.78  32.34  32.65 1539.36  32.29
     7  31.76  32.30  32.39  31.81  32.44  32.16  32.66 1540.88

P2P=Disabled Latency Matrix (us)
   GPU     0      1      2      3      4      5      6      7
     0   2.07  14.25  14.34  12.65  14.08  14.30  14.30  14.30
     1  14.30   2.07  13.91  12.45  14.25  14.16  14.25  14.25
     2  14.19  14.26   2.07  14.33  14.33  14.31  14.33  14.33
     3  14.32  14.32  13.81   2.07  14.25  14.26  14.16  14.32
     4  14.34  14.32  14.33  14.31   2.07  14.32  14.32  14.32
     5  14.31  14.31  14.33  14.33  14.33   2.07  14.33  14.33
     6  14.32  14.32  14.35  14.32  14.33  14.34   2.07  14.33
     7  14.32  14.31  14.34  14.31  14.32  14.31  14.35   2.07


启用 P2P 后：

Unidirectional P2P=Enabled Bandwidth (P2P Writes) Matrix (GB/s)
   D\D     0      1      2      3      4      5      6      7
     0 1516.99  48.54  48.50  48.53  48.45  48.54  48.56  48.48
     1  48.76 1543.97  48.64  48.61  48.62  48.58  48.62  48.57
     2  48.75  48.74 1537.89  48.76  48.76  48.76  48.76  48.76
     3  48.75  48.76  48.74 1543.97  48.76  48.74  48.76  48.74
     4  48.75  48.76  48.76  48.76 1540.93  48.74  48.74  48.76
     5  48.74  48.76  48.76  48.76  48.76 1547.03  48.76  48.74
     6  48.73  48.65  48.64  48.64  48.64  48.65 1547.03  48.66
     7  48.75  48.69  48.55  48.64  48.61  48.61  48.60 1544.02

Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
   D\D     0      1      2      3      4      5      6      7
     0 1530.32  97.42  97.44  97.46  97.41  97.45  97.44  97.44
     1  97.43 1540.88  97.44  97.44  97.45  97.45  97.44  97.44
     2  97.43  97.44 1539.34  97.44  97.45  97.44  97.44  97.45
     3  97.44  97.44  97.41 1539.34  97.44  97.45  97.45  97.45
     4  97.45  97.45  97.47  97.44 1537.82  97.45  97.46  97.47
     5  97.46  97.45  97.45  97.44  97.44 1540.88  97.46  97.46
     6  97.43  87.75  97.44  97.44  97.44  97.44 1540.86  97.45
     7  97.44  97.45  97.45  97.45  97.46  97.44  97.44 1540.86

P2P=Enabled Latency (P2P Writes) Matrix (us)
   GPU     0      1      2      3      4      5      6      7
     0   2.07   0.37   0.35   0.37   0.43   0.37   0.36   0.36
     1   0.36   2.07   0.35   0.37   0.36   0.43   0.43   0.42
     2   0.38   0.43   2.07   0.38   0.38   0.44   0.37   0.38
     3   0.38   0.43   0.37   2.07   0.36   0.36   0.37   0.37
     4   0.45   0.37   0.44   0.38   2.07   0.45   0.37   0.43
     5   0.36   0.35   0.36   0.36   0.37   2.07   0.43   0.35
     6   0.43   0.42   0.43   0.36   0.36   0.43   2.07   0.43
     7   0.36   0.44   0.36   0.36   0.36   0.36   0.36   2.07


也就是说，在启用 P2P 前后，各个指标都有了显著提升：


  单向带宽：31.5 GB/s（由于需要经过内存，产生两次拷贝，理论上限为 PCIe 5.0 x16 带宽的一半即 32 GB/s）-> 48.5 GB/s（理论上限为 64 GB/s）；
  双向带宽：32 GB/s（理论值为 64 GB/s）-> 97.4 GB/s（理论值为 128 GB/s）；注意到表格中有一个异常值（GPU 1 <-> GPU 6），应该是偶发情况。
  通信延迟：14.3 us -> 0.4 us。


如果修改 BIOS 把 NPS4 切换成 NPS2，那么还能获得进一步的提升。同一个 NUMA Node 上的两个 GPU 之间，单向带宽变成了 56 GB/s，双向带宽 111 GB/s，延迟没有太大的变化。

集合通信测试

下面用 NCCL 来测试对多卡深度学习影响非常显著的 AllReduce 性能。

八卡启用 P2P 前：

#                                                              out-of-place                       in-place
#       size         count      type   redop    root     time   algbw   busbw  #wrong     time   algbw   busbw  #wrong
#        (B)    (elements)                               (us)  (GB/s)  (GB/s)             (us)  (GB/s)  (GB/s)
        4096          1024     float     sum      -1    51.03    0.08    0.14       0    50.82    0.08    0.14       0
        8192          2048     float     sum      -1    51.58    0.16    0.28       0    51.36    0.16    0.28       0
       16384          4096     float     sum      -1    52.67    0.31    0.54       0    52.63    0.31    0.54       0
       32768          8192     float     sum      -1    54.57    0.60    1.05       0    54.74    0.60    1.05       0
       65536         16384     float     sum      -1    59.77    1.10    1.92       0    60.10    1.09    1.91       0
      131072         32768     float     sum      -1    62.38    2.10    3.68       0    62.12    2.11    3.69       0
      262144         65536     float     sum      -1    71.12    3.69    6.45       0    70.86    3.70    6.47       0
      524288        131072     float     sum      -1   104.97    4.99    8.74       0   104.45    5.02    8.78       0
     1048576        262144     float     sum      -1   163.53    6.41   11.22       0   161.47    6.49   11.36       0
     2097152        524288     float     sum      -1   275.28    7.62   13.33       0   273.02    7.68   13.44       0
     4194304       1048576     float     sum      -1   534.66    7.84   13.73       0   537.23    7.81   13.66       0
     8388608       2097152     float     sum      -1  1015.74    8.26   14.45       0  1010.40    8.30   14.53       0
    16777216       4194304     float     sum      -1  1999.61    8.39   14.68       0  2002.71    8.38   14.66       0
    33554432       8388608     float     sum      -1  4011.43    8.36   14.64       0  4013.64    8.36   14.63       0
    67108864      16777216     float     sum      -1  7972.72    8.42   14.73       0  7970.34    8.42   14.73       0
   134217728      33554432     float     sum      -1  15721.4    8.54   14.94       0  15733.6    8.53   14.93       0
   268435456      67108864     float     sum      -1  31422.7    8.54   14.95       0  31431.6    8.54   14.95       0
   536870912     134217728     float     sum      -1  62893.2    8.54   14.94       0  62859.7    8.54   14.95       0
  1073741824     268435456     float     sum      -1   128117    8.38   14.67       0   127351    8.43   14.75       0


由于 NCCL 默认并不愿意为 SYS 连接的 GPU 启用 P2P，因此需要通过 NCCL_P2P_LEVEL=SYS 强制打开。判断是否真的启用了 P2P 的方法是，设置 NCCL_DEBUG=INFO 后，查看日志中是否出现了类似的字样：

[0] NCCL INFO Channel 00/0 : 0[0] -> 1[1] via P2P/direct pointer
[5] NCCL INFO Channel 01/0 : 1[5] -> 0[4] via P2P/direct pointer
[1] NCCL INFO Channel 00/0 : 1[1] -> 0[0] via P2P/direct pointer
[0] NCCL INFO Channel 01/0 : 0[0] -> 1[1] via P2P/direct pointer
[4] NCCL INFO Channel 01/0 : 0[4] -> 1[5] via P2P/direct pointer
[1] NCCL INFO Channel 01/0 : 1[1] -> 0[0] via P2P/direct pointer
[7] NCCL INFO Channel 00/0 : 1[7] -> 0[6] via P2P/direct pointer
[7] NCCL INFO Channel 01/0 : 1[7] -> 0[6] via P2P/direct pointer


此时性能结果为：

#                                                              out-of-place                       in-place
#       size         count      type   redop    root     time   algbw   busbw  #wrong     time   algbw   busbw  #wrong
#        (B)    (elements)                               (us)  (GB/s)  (GB/s)             (us)  (GB/s)  (GB/s)
        4096          1024     float     sum      -1    38.81    0.11    0.18       0    36.53    0.11    0.20       0
        8192          2048     float     sum      -1    38.20    0.21    0.38       0    37.00    0.22    0.39       0
       16384          4096     float     sum      -1    39.47    0.42    0.73       0    38.28    0.43    0.75       0
       32768          8192     float     sum      -1    40.94    0.80    1.40       0    39.82    0.82    1.44       0
       65536         16384     float     sum      -1    42.48    1.54    2.70       0    41.36    1.58    2.77       0
      131072         32768     float     sum      -1    43.65    3.00    5.25       0    42.99    3.05    5.34       0
      262144         65536     float     sum      -1    49.97    5.25    9.18       0    47.18    5.56    9.72       0
      524288        131072     float     sum      -1    63.10    8.31   14.54       0    62.07    8.45   14.78       0
     1048576        262144     float     sum      -1    84.45   12.42   21.73       0    85.24   12.30   21.53       0
     2097152        524288     float     sum      -1   149.68   14.01   24.52       0   149.70   14.01   24.52       0
     4194304       1048576     float     sum      -1   280.51   14.95   26.17       0   278.13   15.08   26.39       0
     8388608       2097152     float     sum      -1   545.43   15.38   26.91       0   552.92   15.17   26.55       0
    16777216       4194304     float     sum      -1  1091.57   15.37   26.90       0  1090.04   15.39   26.93       0
    33554432       8388608     float     sum      -1  2169.79   15.46   27.06       0  2162.90   15.51   27.15       0
    67108864      16777216     float     sum      -1  4336.85   15.47   27.08       0  4327.66   15.51   27.14       0
   134217728      33554432     float     sum      -1  8640.99   15.53   27.18       0  8627.71   15.56   27.22       0
   268435456      67108864     float     sum      -1  17226.8   15.58   27.27       0  17207.1   15.60   27.30       0
   536870912     134217728     float     sum      -1  34359.1   15.63   27.34       0  34359.3   15.63   27.34       0
  1073741824     268435456     float     sum      -1  68660.4   15.64   27.37       0  68652.1   15.64   27.37       0


也就是说，八卡 AllReduce 在 PCIe 上的带宽（busbw）从 14.75 GB/s 提升到了 27.34 GB/s。如果在一个 Socket 的四张 GPU 上测试，则提升会更明显，从 16.33 GB/s 提升到了 46.31 GB/s，大概是原来的 2.8 倍。

需要注意，设置 NCCL_P2P_LEVEL=SYS 也可能会导致 NCCL 过分激进地使用这些 P2P 连接，在复杂的应用中（如多维并行的分布式深度学习），未必能带来性能收益。如果可能，建议修改 NPS 配置，使得 NCCL 在默认配置下也能使用 P2P 连接，并合理分配不同并行方式的维度。如对于 NPS2 的八卡机集群，可以考虑 TP=2, PP=4, DP=N 的配置，其中 N 为机器的总数。

神秘修复

那么这些性能提升是完全免费的吗？是，也不是。我发现在魔改驱动后，一旦进程使用了 P2P 功能，那么有概率存在部分 GPU，在所有进程均退出后依旧维持 100% 的利用率和相当高的功耗。但只要再次在这些 GPU 上创建 CUDA Context，什么都不做并立刻销毁，就能使得它恢复正常静息状态。可以合理推测，魔改后的驱动应该存在一定的资源泄露问题。

为了缓解此问题，我在系统中增加了一个 systemd timer，定期检查是否有 GPU 无进程但高占用的情况，如果有则运行上述的简单修复程序。虽然方法比较土，但可以有效地缓解这个问题。

One More Thing

虽然目前的驱动已经支持 P2P，但是还是不能使用 GPUDirect RDMA 功能，而这是提升跨机通信性能的关键。既然 GPU 之间能互相通信，那么理论上 IB 卡和 GPU 通信应该也不困难。此外，从 580 开始， NVIDIA 驱动已经切换到了 Linux 官方支持的 dma-buf 来提供此支持，而不需要 nvidia-peermem 模块了。但很遗憾，这个魔改的驱动还没有打开此支持，而已经有人许下了良好的愿望。此外，GPUDirect Storage 也有着相同的原理，但它也还是一个愿望。

此外，近日我在小红书上还刷到了国内的神人通过 Claude 魔改驱动，还给 5090 增加了 NVLink 支持，甚至涉及到了关于 BAR 相关逻辑的修改。虽说确实 5090 的 PCB 上有此物理接口，但真的要支持并且用起来，又是另一个级别的工作了。如果此事真的可行，那只能说老黄的刀在当前的 vibe coding 时代，可能要再磨一磨了。



在 Kubernetes 上部署 JupyterHub 的经验记录
2026-03-16T15:45:00+08:00
为了方便各类课程给学生提供开箱即用的 Python 环境，我在教学实验室的 Kubernetes 上（由杰哥强力驱动）部署了一套 JupyterHub，并进行了一些必要的自定义。本文介绍整个部署过程，并记录一些经验和踩过的坑。

JupyterHub 官方提供了一个比较成熟的 Helm chart：Zero to JupyterHub with Kubernetes，文档写得比较好，基本上照着做就能跑起来。

服务基本配置

首先安装 Helm Chart：

helm repo add jupyterhub https://jupyterhub.github.io/helm-chart/
helm repo update


然后新建 config.yaml，文件由以下的部分拼接（以及合并）而成。

OAuth 认证

我们已有一个统一的 OAuth 认证门户（感谢喵喵！），JupyterHub 通过 GenericOAuthenticator 接入：

hub:
  baseUrl: /jupyterhub
  config:
    Authenticator:
      admin_users:
        - admin1
        - admin2
      auto_login: true
      allow_all: true
    JupyterHub:
      authenticator_class: generic-oauth
    GenericOAuthenticator:
      client_id: jupyterhub
      client_secret: 
      oauth_callback_url: https://example.com/jupyterhub/hub/oauth_callback
      authorize_url: https://example.com/portal/api/authorize
      token_url: https://example.com/portal/api/token
      userdata_url: https://example.com/portal/api/self
      username_key: user_name


部分需要注意的点：


  baseUrl 设为 /jupyterhub 可以与其他服务共享域名。
  auto_login: true 配合 allow_all: true，用户访问时会自动跳转 OAuth 登录，登录成功即可创建新用户，无需手动维护白名单（注：JupyterHub 5.0 开始必须有 allow_all，否则新用户无法登录）。
  username_key 需要根据 OAuth Provider 返回的用户信息字段来设置。


网络与 Ingress

由于我们的 JupyterHub 在子路径下，需要把 proxy 的 Service 类型设为 ClusterIP（而不是默认的 LoadBalancer），然后通过公共的 Ingress 暴露：

proxy:
  service:
    type: ClusterIP


对应的 Ingress 资源 jupyterhub-ingress.yaml：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: jupyterhub-ingress
  labels:
    app: jupyterhub-ingress
spec:
  rules:
  - http:
      paths:
      - path: /jupyterhub
        pathType: Prefix
        backend:
          service:
            name: proxy-public
            port:
              number: 80


这里的 proxy-public 是 Helm chart 中自动创建的服务名称，通常不需要更改。

用户环境与 Profile

JupyterHub 的一大优势就是可以提供多种预配置环境供用户选择，通过 profileList 定义和覆盖：

singleuser:
  image:
    name: quay.io/jupyter/scipy-notebook
    tag: python-3.13
  profileList:
    - display_name: "数据分析环境 (Python 3.13)"
      description: "安装了常用的数据分析包，如 numpy, scipy, sklearn, statsmodel, sympy, matplotlib, pandas"
      default: true
    - display_name: "最小环境 (Python 3.13)"
      description: "仅包含 Python 和必要的工具"
      kubespawner_override:
        image: quay.io/jupyter/minimal-notebook:python-3.13


默认使用 scipy-notebook 镜像，对于大多数数据分析相关的课程场景已经够用。

资源限制与调度

由于服务器资源有限（甚至 k8s 是跑在 VMware 上的），我给每个用户 Pod 设了比较宽松的 limit 和较低的 guarantee，适合教学场景下大量用户同时在线，但不会持续高负载的情况：

singleuser:
  cpu:
    limit: 4
    guarantee: 0.05
  memory:
    limit: 3G
    guarantee: 512M


调度方面，启用了 userPlaceholder 来预热节点，这样用户启动 Pod 时不用等节点调度和拉取镜像：

scheduling:
  userScheduler:
    enabled: false
  podPriority:
    enabled: true
  userPlaceholder:
    enabled: true
    replicas: 5
  userPods:
    nodeAffinity:
      matchNodePurpose: prefer


关闭了 userScheduler 是因为我们集群的默认调度器已经足够。matchNodePurpose: prefer 则是让用户 Pod 优先调度到标记了 purpose: user 的节点上，但在资源不足时，也允许调度到其他节点。

存储选择

用户的持久化存储使用我们自建的 rook-cephfs，每人 5GB 空间：

singleuser:
  storage:
    capacity: 5Gi
    dynamic:
      storageClass: rook-cephfs


选择 CephFS 而不是 RBD 的原因是 CephFS 支持 ReadWriteMany，在需要共享数据时更灵活。实际上我们也用到了这一特性：下文的共享字体就是通过一个 ReadWriteMany 的 PVC 挂载到所有用户 Pod 中的。

资源回收

为了避免用户忘记关闭 Notebook（真的有人会记得吗？）导致资源浪费，启用了 culler：

cull:
  enabled: true
  timeout: 3600
  every: 300


空闲 1 小时后自动关闭用户 Pod，每 5 分钟检查一次。

Hacks

额外依赖

由于某些课程需要额外的 Python 依赖，而我并不想维护额外的镜像。经过多次测试，可以通过覆盖启动命令，在容器启动时 pip install 额外的包，然后再启动镜像中给 JupyterHub 用的 single-user server。这样做的代价是启动总要装包，慢一两分钟，好处是不用跟着主镜像版本升级而重新构建镜像。毕竟维护镜像的活最后还是会落到我头上。

singleuser:
  profileList:
    - display_name: "XXXX 课程环境 (Python 3.13)"
      description: "在数据分析环境基础上安装了课程所需依赖(可能需要 1-2 分钟启动)"
      kubespawner_override:
        cmd:
          - /bin/bash
          - "-c"
          - "pip install jupyterlab_rise jupyter-archive ipywebrtc 'ipywidgets<8'; jupyterhub-singleuser"


注：不像下面一样使用 postStart hook 的原因是，容器是没有状态的，每次启动都是空的；而部分包必须在 Jupyter 本身启动之前安装（比如 jupyterlab_rise），因此只能覆盖启动命令。

中文字体

官方的 JupyterLab 镜像里不包含中文字体，用 matplotlib 画图时中文会变成方块。当然，重新打镜像也能解决此问题，但我显然还是不想这么做。

偷懒问了一下 Claude，解决方案是创建一个共享的字体 PVC，挂载到每个用户 Pod 中：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: jupyterhub-fonts
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: rook-cephfs
  resources:
    requests:
      storage: 1Gi


使用 kubectl apply -f 应用此文件，然后在配置中把这个 PVC 挂载到用户 Pod，并通过 postStart hook 刷新字体缓存和 matplotlib 的字体管理器缓存（matplotlib 有自己的缓存，如果不刷新还是看不到新安装的字体，不知为何有这么糟糕的设计）：

singleuser:
  storage:
    extraVolumes:
      1-extra-fonts:
        name: extra-fonts
        persistentVolumeClaim:
          claimName: jupyterhub-fonts
          readOnly: true
    extraVolumeMounts:
      1-extra-fonts:
        name: extra-fonts
        mountPath: /usr/share/fonts/extra
        readOnly: true
  lifecycleHooks:
    postStart:
      exec:
        command:
          - "sh"
          - "-c"
          - "fc-cache -f /usr/share/fonts/extra && python -c \"import matplotlib.font_manager; matplotlib.font_manager._load_fontmanager(try_read_cache=False)\" || true"


末尾的 || true 是为了防止在 matplotlib 未安装的环境（如最小环境）中，容器因为找不到包而启动失败。

往 PVC 里增加字体的方式比较朴素——启动一个临时 Pod 挂载这个 PVC，然后用 kubectl cp 把字体文件拷进去。临时 Pod 资源描述 temp-font-pod.yaml 如下：

apiVersion: v1
kind: Pod
metadata:
  name: font-loader
spec:
  containers:
  - name: loader
    image: busybox
    command: ["sleep", 3600]
    volumeMounts:
    - name: fonts
      mountPath: /fonts
  volumes:
  - name: fonts
    persistentVolumeClaim:
      claimName: jupyterhub-fonts


执行完后记得删除：

kubectl -n jupyterhub apply -f temp-font-pod.yaml
kubectl -n jupyterhub cp /path/to/your/fonts font-loader:/fonts/
kubectl -n jupyterhub delete pod font-loader


部署脚本

上文的所有配置可以写成一个部署脚本，方便后续升级和回滚：

#!/bin/bash

set -x
set -e

NAMESPACE=jupyterhub

helm upgrade --cleanup-on-fail \
  --install jupyterhub jupyterhub/jupyterhub \
  --namespace $NAMESPACE \
  --create-namespace \
  --version=4.3.2 \
  --values config.yaml

kubectl -n $NAMESPACE apply -f shared-fonts-pvc.yaml
kubectl -n $NAMESPACE apply -f jupyterhub-ingress.yaml


小结

总体来说，Zero to JupyterHub 这个 Helm chart 做得还不错，上课用起来体验比较好。当然，为了实现额外需求还是需要一些 hack，也需要在文档缺乏的地方自己摸索。


IPMI SDR 和坑爹的 BMC 电源读数一例
2026-03-10T21:30:00+08:00
最近组里新购入了一些杂牌 GPU 服务器，为了监控功耗，我部署了 Prometheus 社区的 ipmi_exporter 从 BMC 读取带外数据，并使用 Grafana 制作了 Dashboard。然而很快我就发现了奇怪的现象：



从图中可以看到，17:30 左右我向 GPU 施加了一些负载，使其温度上升到了 70 度以上。然而，整机的功耗曲线就像一潭死水，完全没有可见的变化。在 18:08 左右我又重启了 exporter，此时功耗读数有了一些变化，然而还是在此后的时间中维持不变。这是我用了这么多年的 IPMI，第一次遇到如此诡异的事情。

问题复现

我首先怀疑是 BMC 本身有故障，但从网页上能获得正确的读数和曲线（尽管采样率比较低）。于是我又怀疑是 IPMI SDR 有问题，但我用 ipmitool 能正确读取实际的功率数字。最后怀疑对象就来到了 ipmi_exporter 上，它使用的是 FreeIPMI 工具中的 ipmi-sensors 来读取数据。果然，用它就能复现问题：

root@foo# ipmi-sensors -D LAN_2_0 -h ipmi_host -u root -p FOO -r 105
Caching SDR repository information: /root/.freeipmi/sdr-cache/sdr-cache-foo.ipmi_host
Caching SDR record 157 of 157 (current record ID 352)
ID  | Name        | Type                     | Reading    | Units | Event
105 | Total_Power | Other Units Based Sensor | 670.00     | W     | 'OK'

(启动重型 GPU 负载并等待几秒钟)

root@foo# ipmitool -I lanplus -H ipmi_host -U root -P FOO sdr get 'Total_Power'
Sensor ID              : Total_Power (0x69)
 Entity ID             : 21.0 (Power Management)
 Sensor Type (Threshold)  : Other (0x0b)
 Sensor Reading        : 4500 (+/- 0) Watts
 Status                : ok

root@foo# ipmi-sensors -D LAN_2_0 -h ipmi_host -u root -p FOO -r 105
ID  | Name        | Type                     | Reading    | Units | Event
105 | Total_Power | Other Units Based Sensor | 670.00     | W     | 'OK'

root@foo# ipmi-sensors -D LAN_2_0 -h ipmi_host -u root -p FOO -r 105
ID  | Name        | Type                     | Reading    | Units | Event
105 | Total_Power | Other Units Based Sensor | 667.32     | W     | 'OK'



我拿着这个现象去问了 Claude，它提醒我这很可能和 IPMI SDR 的读取方式有问题，于是我就趁机进行了一些学习。

IPMI SDR 格式与读取命令

SDR (Sensor Data Record) 是 IPMI 1.5 标准中定义的用于描述传感器信息的数据结构，BMC 会将这些记录存储在一个 SDR Repository 中。每个记录都有一个唯一的 ID，可以通过 IPMI 命令来读取。

可以用如下的命令读取 SDR Repository：

root@foo# ipmitool -I lanplus -H ipmi_host -U root -P FOO sdr info
SDR Version                         : 0x51
Record Count                        : 157
Free Space                          : unspecified
Most recent Addition                : NA
Most recent Erase                   : NA
SDR overflow                        : no
SDR Repository Update Support       : unspecified
Delete SDR supported                : no
Partial Add SDR supported           : no
Reserve SDR repository supported    : no
SDR Repository Alloc info supported : no

这其实等价于直接发送 Get SDR Repository Info 命令:

root@foo# ipmitool -I lanplus -H ipmi_host -U root -P FOO raw 0x0a 0x20
 51 f5 00 58 13 ff ff ff ff ff ff ff ff 42


可以看到 SDR Repository 中有 157 条记录。而从上面可以看到 Total_Power 的编号是 0x69 (105)。使用 Get SDR 命令可以读取：

root@foo# ipmitool -I lanplus -H ipmi_host -U root -P FOO raw 0x0a 0x23 0x00 0x00 0x69 0x00 0x00 0xFF
 6a 00 69 00 51 01 3b 20 00 69 15 00 00 00 0b 01
 00 00 00 00 00 00 00 06 00 00 0d 40 00 00 00 e0
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 0b 54 6f 74 61 6c 5f 50 6f 77 65 72 00 00 00
 00 00


或者使用 ipmitool sdr dump，也可以获得完整的 SDR 记录。其中与上面对应的是（截掉了一些末尾的 0）：

00001a40: 6900 5101 3b20 0069 1500 0000 0b01 0000  i.Q.; .i........
00001a50: 0000 0000 0006 0000 0d40 0000 00e0 0000  .........@......
00001a60: 0000 0000 0000 0000 0000 0000 0000 000b  ................
00001a70: 546f 7461 6c5f 506f 7765 7200 0000 0000  Total_Power.....


其中第一个字节 0x69 对应了 ID，第四个字节 0x01 说明这是 Full Sensor Record。各种字段的详细定义在此略去，也可参见 OpenIPMC 提供的头文件。这条记录中的重要字段包括：


  
    
      偏移
      长度
      值
      字段名
      说明
       
    
  
  
    
      0x00
      2
      0x69 0x00
      Record ID
       
       
    
    
      0x02
      1
      0x51
      SDR Version
       
       
    
    
      0x03
      1
      0x01
      Record Type
       
       
    
    
      0x04
      1
      0x3b
      Record Length
      59
       
    
    
      0x15
      1
      0x06
      Base Unit
      Watt
       
    
    
      0x17
      1
      0x00
      Linearization
      0
      Linear
    
    
      0x18
      1
      0x0d
      M[7:0]
      系数
       
    
    
      0x19
      1
      0x40
      {M[9:8], Tolerance}
       
       
    
    
      0x1a
      1
      0x00
      B[7:0]
      系数
       
    
    
      0x1b
      1
      0x00
      {B[9:8], Accuracy LSB}
       
       
    
    
      0x1c
      1
      0x00
      Accuracy
       
       
    
    
      0x1d
      1
      0xe0
      {Rexp[3:0], Bexp[3:0]}
       
       
    
  


也就是说，这个 SDR 定义了一个带线性系数的传感器。当读出数字是 raw，其真实值为：

y = (M * raw + B * 10^Bexp) × 10^Rexp，其中：
M = (0b01 << 8) | 0x0D = 256 + 13 = 269, B = 0
Rexp = (uint4_t) 0b1110 = -2, Bexp = 0


代入后，可知当前真实值是读出值的 2.69 倍。而是用以下命令可以读取传感器原始值：

root@foo# ipmitool -I lanplus -H ipmi_host -U root -P FOO raw 0x04 0x2d 0x69
 f9 c0 00 00


因此当前的功率是 0xf9 * 2.69 = 670W。与 ipmi-sensors 读出的值基本一致。

我多次在不同负载下进行读取测试，发现传感器的原始值几乎不发生变化，总是 250 左右，而 SDR 中的系数却总是在变化。我又让 Claude 给我 vibe 了一个脚本同时检测 SDR 记录和传感器原始值，记录如下：


  
    
      Timestamp
      M
      R_exp
      B
      B_exp
      Raw
      Converted
    
  
  
    
      20:40:11
      291
      -2
      0
      0
      249
      724.59
    
    
      20:40:17
      27
      -1
      0
      0
      249
      672.30
    
    
      20:40:22
      267
      -2
      0
      0
      250
      667.50
    
    
      20:40:28
      268
      -2
      0
      0
      250
      670.00
    
    
      20:40:34
      265
      -2
      0
      0
      249
      659.85
    
    
      20:40:41
      413
      -2
      0
      0
      249
      1028.37
    
    
      20:40:46
      419
      -2
      0
      0
      249
      1043.31
    
    
      20:40:52
      267
      -2
      0
      0
      250
      667.50
    
    
      20:40:58
      268
      -2
      0
      0
      250
      670.00
    
  


到这里，答案基本上已经水落石出。

问题根因

观察 ipmi-sensors 的代码（或者帮助文档），甚至是直接运行一下，都可以发现它维护了一个 SDR 的 cache（还记得上面的 Caching SDR repository information 吗？）。这个 cache 只在 SDR repository 的时间戳发生变化时，才会被工具认为失效并重新获取。

不巧的是，这台服务器的 BMC 选择了修改 SDR 记录中的线性系数（M、Rexp 等）来达成修改最终读数的目的，而不是直接修改传感器的原始值（这真的对吗？）。这样一来，ipmi-sensors 就一直在使用第一次缓存的系数与读出的原始值进行计算，导致最终结果几乎不变。而 ipmitool 则每次都重新读取 SDR 与原始值，得到的结果自然是正确的。

解决方案

由于 ipmi_exporter 和 FreeIPMI 耦合比较紧，而 ipmi-sensors 命令也没有选项允许跳过或者禁用 SDR cache，于是我对 exporter 的代码进行了一些 dirty fix：

--- a/collector.go
+++ b/collector.go
@@ -114,7 +114,8 @@ func (c metaCollector) Collect(ch chan<- prometheus.Metric) {
                        }
                        args := collector.Args()
                        cfg := config.GetFreeipmiConfig()
-
+                       // remove all cache
+                       freeipmi.Execute(fqcmd, []string{"--flush-cache"}, cfg, target.host, logger)
                        result = freeipmi.Execute(fqcmd, args, cfg, target.host, logger)
                }


考虑到功率读取的频率不高（每 15s 一次），这么做虽然简单粗暴，但也不至于有太大的影响。这样一来，我的 Grafana 上终于有了正确的功率曲线。


用于提供现代 PyPI 镜像的 NGINX 配置
2025-11-26T01:00:00+08:00
众所周知，在镜像站界，PyPI 是个难伺候的主：大量的硬盘占用、巨大的流量、频繁的更新，还有不靠谱的同步工具 bandersnatch。你说为什么不靠谱？听说过其他 没有能力 删除上游删掉了的文件的同步工具吗？

好在，伟大的 taoky 在去年写出了一个科学的同步工具 shadowmire，其中一大重要功能，就是能移除上游已经消失的版本和相关文件，为广大教育网镜像站节省了不少硬盘空间，也缓解了供应链攻击的风险。

然而，提供用户可用的 PyPI 镜像依旧没有那么简单。任何 HTTP 站点要被视作有效的 Python 仓库，需要遵守 Simple repository API 或者称为 Index API 的要求。具体来说，两种类型的 API：列出仓库所有的项目（包），以及列出每个包的信息；而每种 API 又需要提供 JSON 和 HTML 两种格式，根据客户端的 Accept 请求头来决定返回哪种格式。当然，这些规范并不是一蹴而就的，最早 PEP503 定义了所谓的“简单”格式（Simple API），PEP691 则在此基础上添加了 JSON 格式的支持，最终形成了现在的标准。

而 PyPI 本身的复杂程度不止如此，它又提供了 XMLRPC API，以及更现代的 JSON API。pip 或者 uv 等工具并不会用到这些 API，但镜像站的同步需要用到它们来获取包的元数据（比如最重要的：最后更新时间）。因此，我们也可以提供力所能及的服务。

考虑到镜像站一般只提供静态文件服务，因此需要同步工具与 NGINX 配合，才能满足上述要求。目前 Shadowmire 对于一个包 foo，会生成如下的文件夹结构：

packages/ # 存放实际的 wheel 文件，略去
simple/ # Simple API
- index.html -> index.v1_html
- index.v1_html
- index.v1_json
- foo/
  - index.html -> index.v1_html
  - index.v1_html
  - index.v1_json
json/ # JSON API
- foo # 包 foo 的 JSON API 内容（如果能从上游获取）


首先，对于 Simple API 的目录，我们需要配置 NGINX 根据 HTTP 请求头来返回不同的文件：

# 放置在 server block 外
map $http_accept $pypi_mirror_suffix {
    default ".html";
    "~*application/vnd\.pypi\.simple\.v1\+json" ".v1_json";
    "~*application/vnd\.pypi\.simple\.v1\+html" ".v1_html";
    "~*text/html" ".html"; # 老旧的 pip 或者第三方工具可能使用
}

# 放置在 server block 内
# 此处 /pypi/web/simple/ 是 TUNA 长期使用的路径前缀，可以根据需要修改
location ~ ^/pypi/web/simple/[^/]* { # match simple/ and simple/foo
    index index$pypi_mirror_suffix index.html;
    types {
        application/vnd.pypi.simple.v1+json v1_json;
        application/vnd.pypi.simple.v1+html v1_html;
        text/html html;
    }
    default_type "text/html";
    try_files $uri$pypi_mirror_suffix $uri $uri/ =404;
}


其次，对于 JSON API（/pypi//json），我们需要倒转路径中的包名和 json 两部分，以适应 Shadowmire 下载的目录结构（/pypi/json/）：

# PyPI JSON API: https://docs.pypi.org/api/json/
# pattern: /pypi//json
location ~ ^/pypi/[^/]+/json$ {
    rewrite ^/pypi/([^/]+)/json$ /pypi/web/json/$1 break;
    types { }
    default_type "application/json; charset=utf-8";
}


然而，事情到这里还没有结束。PyPI 还额外要求，路径中所有的包名都要进行“正规化”（normalization），即将大写字母转换为小写字母，并将 -_. 这三个字符都替换为连字符 -。Shadowmire 在下载时会自动处理这个问题，但在 NGINX 配置中，我们也需要确保用户请求路径被正确地正规化。因此，需要通过 njs 脚本来处理这些路径转换：

// pypi.njs

function canonicalizeName(n) {
  let l = n.toLowerCase();
  // njs < 0.7.10 does not have `String.replaceAll`
  for (let i = 0; i < l.length; i++) {
    if (l[i] === '_' || l[i] === '.') {
      l = l.substring(0, i) + '-' + l.substring(i + 1);
    }
  }
  return l;
}

/// 
/**
 * @param {NginxHTTPRequest} r
 */
function redirectToCanonicalizedName(r) {

  const uri = r.uri.trim();
  r.log(`pypi.njs: original URI to canonicalize: ${uri}`);

  const parts = uri.split('/');
  let matched = false;

  if (parts.length >= 5) {
    // match `/pypi/web/simple/`
    if (parts[1] === 'pypi' && parts[2] === 'web' && parts[3] === 'simple') {
      parts[4] = canonicalizeName(parts[4]);
      matched = true;
    }
  } 
  
  if (!matched && parts.length >= 4) {
    // match `/pypi//json`
    if (parts[1] === 'pypi' && parts[3] === 'json') {
      parts[2] = canonicalizeName(parts[2]);
      matched = true;
    }
  }

  if (!matched) {
    r.warn(`pypi.njs: unknown redirection for URL ${uri}`);
    r.return(500);
  } else {
    const newUri = parts.join('/');
    r.log(`pypi.njs: redirecting to new URI: ${newUri}`);
    r.return(302, newUri);
  }

}

export default { redirectToCanonicalizedName }


继续增加 NGINX 配置处理这些路径（要放置在上面配置之前，以优先处理）：

js_import pypi from pypi.njs;
# explicitly disable canonicalization of these URLs with dots
location = /pypi/web/simple/index.html {}
location = /pypi/web/simple/index.v1_html {}
location = /pypi/web/simple/index.v1_json {}
# match urls with unnormalized names and handle to js
location ~ ^/pypi/web/simple/[^/]*[A-Z_.][^/]* {
    js_content pypi.redirectToCanonicalizedName;
}
location ~ ^/pypi/[^/]*[A-Z_.][^/]*/json {
    js_content pypi.redirectToCanonicalizedName;
}


为了减少 JS 的调用量，上述配置里只匹配了“未正规化”的 URL，即包含大写字母或者 _. 字符的。然而，这样写就会把 /pypi/web/simple/index.html 之类的 URL 也匹配进去，产生非预期的错误（如 pip 请求 /simple/ 的 JSON 格式，首先被 NGINX 重写为 /simple/index.v1_json，又被上述规则命中重写成 /simple/index-v1-json，最终导致 404）。考虑到 simple/ 目录下目前只有这几个文件名可能被访问，因此我们可以通过 location =  的精确匹配来显式禁用这些 URL 的特殊处理，避免误伤。

最后，为了用户体验（是的，我的 Chrome 被卡死过若干次），也为了降低服务器负担，还可以增加规则禁用一些路径的浏览器访问（依旧需要插入到在上述规则的更前面，使其最早生效）：

# server block 外
map $http_user_agent $is_browser {
  default 0;
  "~*validation server" 0;
  "~*mozilla" 1;
}

# server block 内
# disable browser viewing of some too large directories / files in PyPI
location ~ ^/pypi/web/simple/(index\.(html|v1_html)|json/|pypi/)$ {
    default_type 'text/html';
    if ($is_browser) {
        return 413 "This page is too large for browsers.";
    }
}


这样，终于可以提供一个比较完整的“现代” PyPI 镜像服务了。如果你也在尝试搭建 PyPI 镜像站，希望能有所帮助。

偏移	长度	值	字段名	说明
0x00	2	0x69 0x00	Record ID
0x02	1	0x51	SDR Version
0x03	1	0x01	Record Type
0x04	1	0x3b	Record Length	59
0x15	1	0x06	Base Unit	Watt
0x17	1	0x00	Linearization	0	Linear
0x18	1	0x0d	M[7:0]	系数
0x19	1	0x40	{M[9:8], Tolerance}
0x1a	1	0x00	B[7:0]	系数
0x1b	1	0x00	{B[9:8], Accuracy LSB}
0x1c	1	0x00	Accuracy
0x1d	1	0xe0	{Rexp[3:0], Bexp[3:0]}

Timestamp	M	R_exp	Raw	Converted
20:40:11	291	-2	249	724.59
20:40:17	27	-1	249	672.30
20:40:22	267	-2	250	667.50
20:40:28	268	-2	250	670.00
20:40:34	265	-2	249	659.85
20:40:41	413	-2	249	1028.37
20:40:46	419	-2	249	1043.31
20:40:52	267	-2	250	667.50
20:40:58	268	-2	250	670.00

Harry Chen’s Blog

wg-vanity：（又一个）Rust 实现的 WireGuard 地址生成器

RTX 5090 的细粒度温度传感器与物理 SM / TPC 映射探测

背景：传感器信息

实验：负载与温度变化

实验：温度与降频

实验：温度与 SM 映射

实验：温度传感器对少量 SM 负载的响应

实验：SM ID 到 GPC/TPC 的映射

分析：GPC/TPC/SM ID 到物理位置的映射

总结

附录

6000 端口占用导致 SLURM 卡死诊断一例

在 RTX 5090 上启用 GPUDirect RDMA 通信支持

技术背景

最终结论（TL;DR）

调试过程

背景：为什么一开始看 kernel driver

第一阶段：在 kernel driver 里强行打开 DMABUF capability

第二阶段：写 CUDA probe，把问题缩小到 libcuda

第三阶段：反汇编 cuDeviceGetAttribute

第四阶段：直接 poke libcuda 的私有 device structure

第五阶段：做 shim，只作为调试工具

第六阶段：寻找真正的初始化代码

第七阶段：用 patched libcuda 副本验证

方法迁移

总结

PERC RAID5 阵列离线后数据救援一例

数据恢复过程

强制上线 RAID 并导出磁盘镜像

从不完整的磁盘镜像恢复文件

从几乎完整的磁盘镜像恢复文件

其他

ZFS 异常性能诊断

在 RTX 5090 (SM120) 上补全 NVFP4 量化相关 kernel

FP4 量化技术

随机舍入

随机 Hadamard 变换

RTX 5090 (SM120) 现状

随机舍入指令：（半）软件模拟

RHT GEMM：从头重写

Vibe Coding 过程

时间线

总结

在 RTX 5090 上启用 PCIe P2P 通信支持

前置工作

魔改驱动

性能测试

带宽延迟测试

集合通信测试

神秘修复

One More Thing

在 Kubernetes 上部署 JupyterHub 的经验记录

服务基本配置

OAuth 认证

网络与 Ingress

用户环境与 Profile

资源限制与调度

存储选择

资源回收

Hacks

额外依赖

中文字体

部署脚本

小结

IPMI SDR 和坑爹的 BMC 电源读数一例

问题复现

IPMI SDR 格式与读取命令

问题根因

解决方案

用于提供现代 PyPI 镜像的 NGINX 配置

第四阶段：直接 poke `libcuda` 的私有 device structure