Hygon DCU：设备配置与峰值性能

申请一张 Hygon DCU

集群通过 Slurm GRES 暴露 Hygon DCU。申请单卡交互环境：

srun -p normal -N 1 -n 1 --gres=dcu:Hygon:1 --pty bash

也可以先申请资源：

salloc -p normal -N 1 --gres=dcu:Hygon:1

查看空闲 Hygon 节点：

sinfo -t idle -o "%P %N %G" | grep Hygon

加载 DTK：

module load compiler/rocm/dtk-26.04

当前测试节点为 a02r2n07。

当前已确认配置

当前设备是 海光 Hygon DCU，通过 DTK / ROCm 兼容接口暴露设备信息。

项目	值
ISA target	gfx906
Target ID	amdgcn-amd-amdhsa--gfx906:sramecc-:xnack-
Compute Units	64 CU
Wavefront Size	64 threads
Max Waves / CU	40
Max Workgroup Size	1024 threads
Max SCLK	1700 MHz
Max MCLK	1000 MHz
Memory bus width	512 Bytes / 4096 bit
VRAM	17.2 GB reported by rocBLAS
LDS / Local Memory	约 64 KiB
Power Cap	300 W
Marketing Name	Device 66a1

gfx906 和 Device 66a1 是这张海光 DCU 对 DTK/ROCm 暴露的兼容标识，不应因此直接把设备等同于 AMD MI50/MI60。

rocblas-bench 实际查询设备时输出：

Device ID 0 : Device 66a1 gfx906:sramecc-:xnack-
with 17.2 GB memory, max. SCLK 1700 MHz, max. MCLK 1000 MHz,
memoryBusWidth 512 Bytes, compute capability 9.0
maxGridDimX 2147483647, sharedMemPerBlock 65.5 KB,
maxThreadsPerBlock 1024, warpSize 64

查看设备

rocm-smi

单卡作业中看到的 HCU 0 就是当前可见的第 0 张海光计算设备。

查看架构：

rocminfo | grep gfx

当前设备会返回 gfx906，因此 HIP kernel 可以显式指定：

hipcc kernel.cpp -O3 --offload-arch=gfx906

查看关键属性：

rocminfo | grep -E 'Compute Unit|Max Waves|Wavefront|Workgroup Max|Size:|Clock'

当前 DCU 的关键结果是：

Max Clock Freq. (MHz): 1700
Compute Unit:          64
Wavefront Size:        64
Workgroup Max Size:    1024
Max Waves Per CU:      40
VRAM:                  ~16-17 GiB
LDS:                   64 KiB

注意 rocminfo 还会列出 Hygon CPU 的 HSA Agent，不要把 CPU Agent 的 Compute Unit: 8 当成 DCU。

理论 FP32 峰值估算

基本公式：

Peak FLOPS = CU × 每 CU 每周期浮点运算数 × Clock

FMA 通常按两次浮点运算计数：

a = b * c + d  =>  2 FLOPs

若暂时假设该 gfx906 执行模型下每个 CU 每周期完成 64 个 FP32 FMA，则：

FP32 Peak
= 64 CU × 64 lanes × 2 FLOP/FMA × 1.7 GHz
= 13.9264 TFLOPS

所以当前可先把：

Estimated FP32 Peak ≈ 13.93 TFLOPS

作为假设性的理论上界，不能当作海光官方额定峰值。尤其是“每 CU 每周期 64 个 FP32 FMA”这一执行吞吐假设仍需要厂商资料或微基准确认。

使用 DTK 自带 rocBLAS benchmark

DTK 26.04 自带 benchmark，但文件没有 executable bit：

/public/software/compiler/rocm/dtk-26.04/dtk-26.04/lib/rocblas/benchmark_tool/rocblas-bench

原文件权限为：

-rw-r--r-- 1 root root ... rocblas-bench

因此复制到 home 后补执行权限：

cp /public/software/compiler/rocm/dtk-26.04/dtk-26.04/lib/rocblas/benchmark_tool/rocblas-bench ~/rocblas-bench
chmod +x ~/rocblas-bench

FP32 SGEMM 实测

测试命令：

for N in 4096 8192 12288 16384; do
    echo "========== N=$N =========="
    ~/rocblas-bench \
      -f gemm -r s \
      --transposeA N --transposeB N \
      -m $N -n $N -k $N \
      --alpha 1 --beta 0 \
      --lda $N --ldb $N --ldc $N
done

2026-09-03 在 a02r2n07 单卡实测：

N	rocBLAS GFLOPS	TFLOPS	时间
4096	8754.41	8.754	15.699 ms
8192	8924.78	8.925	123.198 ms
12288	8966.05	8.966	413.878 ms
16384	8969.95	8.970	980.618 ms

从 N=12288 到 N=16384 基本不再增长，因此当前 rocBLAS FP32 SGEMM 的实测平台值可记为：

Measured rocBLAS FP32 SGEMM ≈ 8.97 TFLOPS

若与上面的 13.9264 TFLOPS 假设峰值比较：

8.96995 / 13.9264 ≈ 64.4%

SGEMM 运行时实际时钟

在 SGEMM 测试期间通过 SMI 观察到：

HCU[0] : fclk   = 1225 MHz
HCU[0] : mclk   = 1000 MHz
HCU[0] : sclk   = 1700 MHz
HCU[0] : socclk = 971 MHz
HCU[0] : dcefclk = 1133 MHz
HCU[0] : PCIe = 8.0 GT/s, x16

其中核心 sclk 已达到设备报告的最大值 1700 MHz。因此此前“SGEMM 只有约 8.97 TFLOPS 是因为核心频率只跑到约 1.1 GHz”的解释可以排除。

当前更合理的结论是：

• rocBLAS FP32 SGEMM 在该设备上稳定约 8.97 TFLOPS；
• 测试时核心频率确实达到 1.7 GHz；
• 相对于 13.93 TFLOPS 假设上界约为 64.4%；
• 但这仍不能直接称为“64.4% 硬件峰值利用率”，因为 13.93 TFLOPS 本身依赖尚未验证的每 CU 每周期 FP32 吞吐假设。

下一步需要用指令级 FP32 FMA microbenchmark 或海光官方资料确认真实 FP32 理论峰值，再判断 rocBLAS kernel 的实际效率。

FP16 / 半精度支持与实测

当前 rocblas-bench --help 明确暴露半精度数据类型：

--precision |-r <value>
Options: h,s,d,c,z,f8_r,bf8_r,f16_r,f32_r,f64_r,bf16_r,...

并且 a_type、b_type、c_type、d_type、compute_type 都支持 f16_r，因此 DTK/rocBLAS 软件栈支持 FP16 路径。

纯 FP16 HGEMM 测试命令：

~/rocblas-bench \
  -f gemm \
  -r h \
  --transposeA N \
  --transposeB N \
  -m 16384 -n 16384 -k 16384 \
  --alpha 1 \
  --lda 16384 \
  --ldb 16384 \
  --beta 0 \
  --ldc 16384

2026-09-03 在 a02r2n07 单卡实测：

Precision	N	rocBLAS GFLOPS	TFLOPS	时间
FP16	16384	17545.5	17.546	501.332 ms
FP32	16384	8969.95	8.970	980.618 ms

因此同尺寸下：

FP16 / FP32 = 17.5455 / 8.96995 ≈ 1.956×

也就是 FP16 rocBLAS GEMM 吞吐约为 FP32 的 1.96×，非常接近 2×。这表明该设备不仅在软件栈层面接受 FP16 数据类型，而且实际半精度 GEMM 路径确实提供了近似双倍吞吐。

当前可把 rocBLAS 实测平台值记为：

FP32 SGEMM ≈ 8.97 TFLOPS
FP16 HGEMM ≈ 17.55 TFLOPS
FP16:FP32 ≈ 1.96×

这里仍然应区分“rocBLAS 实测平台值”和“硬件官方理论峰值”；后者仍需海光官方资料或更底层的指令级 microbenchmark 确认。

GEMM TFLOPS 计算

对于：

C = A × B
A: M×K, B: K×N

GEMM 的计算量近似为：

FLOPs = 2 × M × N × K

因此：

TFLOPS = 2 × M × N × K / time_seconds / 1e12

对 kernel 优化最重要的参数

Architecture : gfx906
CU           : 64
Wavefront    : 64
Max waves/CU : 40
LDS          : 64 KiB
VRAM         : 17.2 GB reported
SCLK         : 1.7 GHz observed under SGEMM
MCLK         : 1.0 GHz observed under SGEMM
FCLK         : 1.225 GHz observed under SGEMM
Memory bus   : 512 Bytes / 4096 bit
Power cap    : 300 W
FP32 SGEMM   : ~8.97 TFLOPS measured
FP16 HGEMM   : ~17.55 TFLOPS measured
FP16:FP32    : ~1.96x measured

尤其注意：这里是 Wave64，CUDA kernel 移植时不能无条件假设 warpSize == 32。Reduction、shuffle、lane mapping 和 warp-specialized 设计都要重新检查。

下一步

接下来建议继续确认：

1. SGEMM / HGEMM 满载时的功耗和 HCU 利用率；
2. FP32 / FP16 指令级 FMA microbenchmark，确认真实硬件理论峰值；
3. DGEMM 峰值以及 FP64:FP32 吞吐比例；
4. 实测显存带宽并验证 512 Bytes bus / 1000 MHz 的含义；
5. 建立 Roofline Model。

这样后续优化 GEMM、QR、FlashAttention 时，可以判断 kernel 是 compute bound、memory bound、LDS bound 还是 occupancy bound。