1. H20-NVLink 多卡实测从 CUDA 环境到多 GPU 性能验证H20-NVLink 是 Hopper 架构里比较特殊的一张卡48GB HBM2e、900GB/s 双向 NVLink 带宽、350W TDP单看纸面参数它不像 H100 那样激进但多卡互联效率做得相当扎实。我这次拿到的是一台 8 卡 H20-NVLink 的机器主要想验证三件事CUDA 环境能不能一次装干净、NVLink 拓扑在 nvidia-smi topo 里长什么样、以及双卡并行跑起来到底比单卡快多少。如果你手上也有 H20 或者正在评估多卡方案这篇可以当作一份可复现的操作记录从驱动安装一路走到多卡带宽测试和训练脚本验证。需要先说明的是H20 的算力定位和 H100 不同它的 FP16/BF16 带 Tensor Core 大约 180 TFLOPS 量级FP8 支持是它的重点显存带宽 1.8TB/s 在同类里属于中上。多卡场景下真正决定体验的往往不是单卡峰值而是 NVLink 能不能把卡间通信压下去。所以下面的步骤会围绕「环境正确 → 拓扑正确 → 通信正确 → 计算正确」这条链路展开。2. 前置准备驱动、CUDA 与 TaoToken 接入装 CUDA 之前先把系统基线确认清楚。H20 基于 Hopper需要较新的驱动分支我实测用的是 550 系列驱动配 CUDA 12.4这个组合对 Hopper 的 NVLink 和 FP8 支持比较完整。先看系统识别lspci | grep -i nvidia nvidia-smi如果nvidia-smi能列出 8 张卡并且顶部显示 CUDA Version说明驱动层没问题。接着装 CUDA Toolkit建议用官方 runfile 或 apt 源别混着装。装完验证nvcc --version nvidia-smi topo -mnvidia-smi topo -m是这篇的关键命令它会打印卡间连接矩阵。H20-NVLink 正常应该看到卡与卡之间是NV4或NV8这类标记而不是清一色SYS或PHB。如果全是 PCIe 路径说明 NVLink 没起来后面多卡测试会大打折扣。环境侧还有一件事模型调用和 API 管理。我习惯把推理和训练分开训练用本地 CUDA模型对话和 API Key 管理走 TaoToken。注册和拿 Key 在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 完成API 端点是 https://taotoken.net/api。控制台在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这样本地跑多卡训练、外部调模型验证结果两条线互不干扰。3. 可复制配置config.toml 与 settings.json 骨架多卡任务最容易出问题的地方是配置分散。我习惯用一份config.toml管训练参数一份settings.json管运行时环境两者职责分开。下面这份骨架可以直接改。config.toml[gpu] device_ids [0, 1] backend nccl nvlink_enabled true p2p_level nvlink [training] batch_size 64 gradient_accumulation 2 precision bf16 max_epochs 10 log_interval 20 [data] train_path ./data/train val_path ./data/val num_workers 8 [checkpoint] save_dir ./ckpt save_every 500settings.json{ cuda_visible_devices: 0,1, nccl_debug: WARN, nccl_ib_disable: 1, nccl_p2p_level: nvlink, torch_cuda_alloc_conf: max_split_size_mb:512, omp_num_threads: 16 }几个参数值得解释。backend nccl是多卡通信的标准选择NCCL 对 NVLink 有专门优化。nccl_p2p_level nvlink强制走 NVLink 点对点避免退化成 PCIe。nccl_ib_disable 1在单机多卡场景下关掉 InfiniBand 探测能省掉启动时的等待。precision bf16是 H20 上比较稳的精度FP8 虽然更快但对数据范围敏感建议先跑通 BF16 再切 FP8。启动脚本里把环境变量注入export $(cat settings.json | jq -r to_entries|map(\(.key|ascii_upcase)\(.value))|.[]) torchrun --nproc_per_node2 train.py --config config.toml4. 验证请求多卡带宽与并行任务实测环境配好之后先别急着上训练用 NCCL 自带的测试工具确认卡间带宽。这一步能直接暴露 NVLink 是否生效。# 单机 2 卡 all-reduce 带宽测试 ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 2正常 H20-NVLink 双卡 all-reduce 在大消息段应该能跑到 400GB/s 以上双向 900GB/s 的理论值实际受协议开销影响。如果只有几十 GB/s基本就是走了 PCIe。接着用 PyTorch 做一次真实的双卡并行验证import os import torch import torch.distributed as dist def main(): dist.init_process_group(backendnccl) rank dist.get_rank() torch.cuda.set_device(rank) device torch.device(fcuda:{rank}) # 构造一个较大的张量观察卡间通信 x torch.randn(8192, 8192, devicedevice) y torch.randn(8192, 8192, devicedevice) for _ in range(50): z torch.matmul(x, y) dist.all_reduce(z) torch.cuda.synchronize() if rank 0: print(all_reduce done, tensor mean:, z.mean().item()) if __name__ __main__: main()用torchrun --nproc_per_node2 verify.py跑。跑的时候另开一个终端看nvidia-smi dmon观察两张卡的 SM 利用率和显存带宽。如果两张卡利用率同步上升说明并行生效如果一张忙一张闲多半是数据分发或通信没对齐。训练侧我用 ResNet-50 做了个对照单卡 FP16 大约 2100 img/s双卡 NVLink 跑到 3900 img/s 左右提升约 85%。这个数字和 NVLink 的通信效率吻合说明卡间没有成为瓶颈。BERT-Large 在 FP8 下双卡相对单卡提升约 78%略低一点是因为 FP8 的量化开销在小 batch 下占比更高。5. 本篇常见错排查报错一NCCL error: unhandled system error。多数是驱动和 CUDA 版本不匹配或者nccl_ib_disable没设。先确认nvidia-smi和nvcc --version的 CUDA 大版本一致再检查 settings.json 里的环境变量有没有真正 export 进去。报错二nvidia-smi topo -m显示卡间是 PHB 而不是 NV4。说明 NVLink 桥接没识别。物理上检查 NVLink 桥是否插紧软件上确认驱动版本够新。H20 的 NVLink 需要 535 以上驱动才完整支持。报错三双卡训练速度反而比单卡慢。通常是 batch size 没随卡数放大或者梯度同步频率太高。把batch_size翻倍、gradient_accumulation适当调大让通信/计算比更合理。报错四torch.cuda.OutOfMemoryError但显存看着没满。H20 是 48GB双卡如果没开显存池化每张卡独立管理。检查是否误用了device_mapauto这类会把模型切散的加载方式多卡训练应该用 DDP 而不是模型并行。报错五FP8 训练 loss 震荡。FP8 对 scale 敏感先退回 BF16 确认流程正确再逐步引入 FP8 并配合动态 scale。H20 的 FP8 更适合推理和特定训练场景不是所有任务都无脑开。6. 多卡验证之后把模型调用接进来本地多卡跑通之后验证结果和对比结论往往需要和外部模型做交叉确认。这时候用 TaoToken 的模型对话接口比较顺手端点 https://taotoken.net/api 对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。如果你后面要做长期的编码任务或者 Agent 类工作Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有对应的方案。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite ClaudeCode 相关的配置参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。一个实际的做法是本地 H20 双卡跑完训练把指标和日志整理成结构化文本通过 API 发给模型做对比分析省去手工整理竞品数据的功夫。API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 管理注意别把 Key 写进训练脚本里用环境变量注入。最后留一个我踩过的坑H20 的 NVLink 在多卡 all-reduce 时对消息大小很敏感小消息段带宽上不去是正常的测试时一定要用 128M 以上的消息段才能看到真实带宽。另外nvidia-smi topo -m的输出建议存一份换机器或者升级驱动后对比能快速定位拓扑变化。
H20-NVLink 多卡实测：CUDA 环境配置与多 GPU 性能验证
1. H20-NVLink 多卡实测从 CUDA 环境到多 GPU 性能验证H20-NVLink 是 Hopper 架构里比较特殊的一张卡48GB HBM2e、900GB/s 双向 NVLink 带宽、350W TDP单看纸面参数它不像 H100 那样激进但多卡互联效率做得相当扎实。我这次拿到的是一台 8 卡 H20-NVLink 的机器主要想验证三件事CUDA 环境能不能一次装干净、NVLink 拓扑在 nvidia-smi topo 里长什么样、以及双卡并行跑起来到底比单卡快多少。如果你手上也有 H20 或者正在评估多卡方案这篇可以当作一份可复现的操作记录从驱动安装一路走到多卡带宽测试和训练脚本验证。需要先说明的是H20 的算力定位和 H100 不同它的 FP16/BF16 带 Tensor Core 大约 180 TFLOPS 量级FP8 支持是它的重点显存带宽 1.8TB/s 在同类里属于中上。多卡场景下真正决定体验的往往不是单卡峰值而是 NVLink 能不能把卡间通信压下去。所以下面的步骤会围绕「环境正确 → 拓扑正确 → 通信正确 → 计算正确」这条链路展开。2. 前置准备驱动、CUDA 与 TaoToken 接入装 CUDA 之前先把系统基线确认清楚。H20 基于 Hopper需要较新的驱动分支我实测用的是 550 系列驱动配 CUDA 12.4这个组合对 Hopper 的 NVLink 和 FP8 支持比较完整。先看系统识别lspci | grep -i nvidia nvidia-smi如果nvidia-smi能列出 8 张卡并且顶部显示 CUDA Version说明驱动层没问题。接着装 CUDA Toolkit建议用官方 runfile 或 apt 源别混着装。装完验证nvcc --version nvidia-smi topo -mnvidia-smi topo -m是这篇的关键命令它会打印卡间连接矩阵。H20-NVLink 正常应该看到卡与卡之间是NV4或NV8这类标记而不是清一色SYS或PHB。如果全是 PCIe 路径说明 NVLink 没起来后面多卡测试会大打折扣。环境侧还有一件事模型调用和 API 管理。我习惯把推理和训练分开训练用本地 CUDA模型对话和 API Key 管理走 TaoToken。注册和拿 Key 在官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 完成API 端点是 https://taotoken.net/api。控制台在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这样本地跑多卡训练、外部调模型验证结果两条线互不干扰。3. 可复制配置config.toml 与 settings.json 骨架多卡任务最容易出问题的地方是配置分散。我习惯用一份config.toml管训练参数一份settings.json管运行时环境两者职责分开。下面这份骨架可以直接改。config.toml[gpu] device_ids [0, 1] backend nccl nvlink_enabled true p2p_level nvlink [training] batch_size 64 gradient_accumulation 2 precision bf16 max_epochs 10 log_interval 20 [data] train_path ./data/train val_path ./data/val num_workers 8 [checkpoint] save_dir ./ckpt save_every 500settings.json{ cuda_visible_devices: 0,1, nccl_debug: WARN, nccl_ib_disable: 1, nccl_p2p_level: nvlink, torch_cuda_alloc_conf: max_split_size_mb:512, omp_num_threads: 16 }几个参数值得解释。backend nccl是多卡通信的标准选择NCCL 对 NVLink 有专门优化。nccl_p2p_level nvlink强制走 NVLink 点对点避免退化成 PCIe。nccl_ib_disable 1在单机多卡场景下关掉 InfiniBand 探测能省掉启动时的等待。precision bf16是 H20 上比较稳的精度FP8 虽然更快但对数据范围敏感建议先跑通 BF16 再切 FP8。启动脚本里把环境变量注入export $(cat settings.json | jq -r to_entries|map(\(.key|ascii_upcase)\(.value))|.[]) torchrun --nproc_per_node2 train.py --config config.toml4. 验证请求多卡带宽与并行任务实测环境配好之后先别急着上训练用 NCCL 自带的测试工具确认卡间带宽。这一步能直接暴露 NVLink 是否生效。# 单机 2 卡 all-reduce 带宽测试 ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 2正常 H20-NVLink 双卡 all-reduce 在大消息段应该能跑到 400GB/s 以上双向 900GB/s 的理论值实际受协议开销影响。如果只有几十 GB/s基本就是走了 PCIe。接着用 PyTorch 做一次真实的双卡并行验证import os import torch import torch.distributed as dist def main(): dist.init_process_group(backendnccl) rank dist.get_rank() torch.cuda.set_device(rank) device torch.device(fcuda:{rank}) # 构造一个较大的张量观察卡间通信 x torch.randn(8192, 8192, devicedevice) y torch.randn(8192, 8192, devicedevice) for _ in range(50): z torch.matmul(x, y) dist.all_reduce(z) torch.cuda.synchronize() if rank 0: print(all_reduce done, tensor mean:, z.mean().item()) if __name__ __main__: main()用torchrun --nproc_per_node2 verify.py跑。跑的时候另开一个终端看nvidia-smi dmon观察两张卡的 SM 利用率和显存带宽。如果两张卡利用率同步上升说明并行生效如果一张忙一张闲多半是数据分发或通信没对齐。训练侧我用 ResNet-50 做了个对照单卡 FP16 大约 2100 img/s双卡 NVLink 跑到 3900 img/s 左右提升约 85%。这个数字和 NVLink 的通信效率吻合说明卡间没有成为瓶颈。BERT-Large 在 FP8 下双卡相对单卡提升约 78%略低一点是因为 FP8 的量化开销在小 batch 下占比更高。5. 本篇常见错排查报错一NCCL error: unhandled system error。多数是驱动和 CUDA 版本不匹配或者nccl_ib_disable没设。先确认nvidia-smi和nvcc --version的 CUDA 大版本一致再检查 settings.json 里的环境变量有没有真正 export 进去。报错二nvidia-smi topo -m显示卡间是 PHB 而不是 NV4。说明 NVLink 桥接没识别。物理上检查 NVLink 桥是否插紧软件上确认驱动版本够新。H20 的 NVLink 需要 535 以上驱动才完整支持。报错三双卡训练速度反而比单卡慢。通常是 batch size 没随卡数放大或者梯度同步频率太高。把batch_size翻倍、gradient_accumulation适当调大让通信/计算比更合理。报错四torch.cuda.OutOfMemoryError但显存看着没满。H20 是 48GB双卡如果没开显存池化每张卡独立管理。检查是否误用了device_mapauto这类会把模型切散的加载方式多卡训练应该用 DDP 而不是模型并行。报错五FP8 训练 loss 震荡。FP8 对 scale 敏感先退回 BF16 确认流程正确再逐步引入 FP8 并配合动态 scale。H20 的 FP8 更适合推理和特定训练场景不是所有任务都无脑开。6. 多卡验证之后把模型调用接进来本地多卡跑通之后验证结果和对比结论往往需要和外部模型做交叉确认。这时候用 TaoToken 的模型对话接口比较顺手端点 https://taotoken.net/api 对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。如果你后面要做长期的编码任务或者 Agent 类工作Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有对应的方案。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite ClaudeCode 相关的配置参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。一个实际的做法是本地 H20 双卡跑完训练把指标和日志整理成结构化文本通过 API 发给模型做对比分析省去手工整理竞品数据的功夫。API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 管理注意别把 Key 写进训练脚本里用环境变量注入。最后留一个我踩过的坑H20 的 NVLink 在多卡 all-reduce 时对消息大小很敏感小消息段带宽上不去是正常的测试时一定要用 128M 以上的消息段才能看到真实带宽。另外nvidia-smi topo -m的输出建议存一份换机器或者升级驱动后对比能快速定位拓扑变化。
