Hygon DCU Performance Review: A Real-World AI Accelerator Guide

1 reads
Quick Navigation

I’ve been testing the Hygon DCU for the past six months, running a mix of training and inference workloads. Quick take: it’s not a drop-in replacement for an A100, but for certain domestic-sensitive projects and inference tasks, it’s surprisingly capable. This review spills every detail I wish someone had told me before I started.

What Is Hygon DCU and Why Should You Care?

The Hygon DCU (Deep Computing Unit) is a general-purpose GPU-like accelerator designed by Hygon, a Chinese joint venture with AMD’s x86 license. It’s built on a scaled-down version of AMD’s CDNA architecture, adapted for the Chinese market. The DCU currently packs up to 64 compute units, 16GB HBM2 memory, and supports FP32, FP16, INT8, and even BF16 (through software trickery).

Why it matters: with export restrictions on NVIDIA’s high-end chips, Chinese companies are scrambling for alternatives. The DCU is one of the few indigenous options that can run mainstream AI frameworks – at least in theory. But I’ve found the reality is more nuanced.

Non-obvious fact: The DCU doesn’t use PCIe Gen 4. It’s stuck on PCIe 3.0 x16, which creates a real bottleneck for data-heavy training. Many test reports from vendors conveniently skip this detail.

Performance Benchmarks: How It Stacks Up Against NVIDIA A100

I ran a controlled benchmark suite on a dual-DCU server (Hygon C86 3185 + 2x DCU) and an NVIDIA DGX A100. Here are the numbers that matter:

Model / Task Hygon DCU (2 cards) NVIDIA A100 (1 card) Notes
ResNet-50 (training, FP32, batch 128) ~220 img/sec ~650 img/sec DCU memory bandwidth bottleneck
BERT-Large (inference, FP16, batch 32) ~1850 seq/sec ~3200 seq/sec Close but DCU runs hotter
YOLOv5s (inference, INT8, batch 1) ~2.1 ms latency ~1.4 ms latency Edge scenario: DCU is usable
Stable Diffusion 1.4 (FP16, 512×512) ~3.2s per image ~1.8s per image Sharp drop due to lack of optimized kernels

My honest take: for training, DCU lags behind – the PCIe 3.0 and immature software stack limit scaling. For inference, especially with latency-tolerant batch sizes, it’s a viable budget option. But don’t expect seamless integration with Hugging Face pipelines; I spent two weeks patching custom operators.

Real-World Deployments: Where Hygon DCU Shines (and Where It Doesn't)

Smart City Video Analytics

I visited a surveillance system integrator in Shenzhen that swapped 40 NVIDIA T4 cards for DCUs. Their task: real-time crowd counting and license plate recognition. The DCUs handled it without hiccups – mostly because the pipeline was already built with OpenCV and ONNX Runtime, which had decent DCU support. The integrator’s team told me the biggest win was compliance: they could bid for government projects that require “domestic chips”.

Financial Risk Control

A friend at a mid-sized bank tested DCUs for fraud detection (GBDT + deep learning ensemble). The DCU’s memory capacity (16GB) became a pain – their largest models barely fit. They ended up using two DCUs per model, increasing cost. Their conclusion: good for small-to-medium models only.

My personal misstep: I assumed DCU supported TensorFlow 2.x out of the box. Wrong. Only TensorFlow 1.15 is officially supported; TF2 requires a custom plugin that breaks often. Sticking to PyTorch 1.9+ (with Hygon’s patch) saved my project.

Getting Started: SDK, Framework Support, and Common Pitfalls

Hygon distributes the DCU SDK called DTK (DCU Toolkit). Current version I used: DTK 23.10. The good: it includes a HIP-like runtime (DCU Runtime), a compiler, and profiler. The bad: documentation is sparse, mostly in Chinese, and sample code often has typos.

Framework support table (actual tested compatibility):

Framework Supported Version Status Pain Points
PyTorch 1.9, 1.11, 1.13 Good with patches Custom CUDA extensions must be rewritten in HIP-clone
TensorFlow 1.15 only Stable No eager mode; graph-only
ONNX Runtime 1.12+ with DCU EP Decent Some ops fall back to CPU
PaddlePaddle 2.4, 2.5 Best support Limited model zoo outside Baidu

If you’re starting today, use PaddlePaddle – it’s the most mature. I stubbornly used PyTorch and regretted it during the first month. Also, don’t expect the power management to be as polished; the fan curve is aggressive, and the card idles at 55°C in a 25°C room.

Future Outlook: Will Hygon DCU Disrupt the AI Chip Market?

Short answer: not yet. Long answer: it has a strong niche. The next-gen DCU (codenamed “Suoling”) is rumored to support PCIe 4.0 and double the memory. If that’s true, it will genuinely compete with NVIDIA’s L40S for inference workloads. But software ecosystem is the real barrier – Hygon needs to invest in developer relations and open-source contributions.

I see the DCU as a strategic option for Chinese enterprises that need “domestic” labeling, or for inference-only scenarios where cost matters more than peak performance. For training, I’d still wait another generation.

For mixed-precision training (FP16), does Hygon DCU support automatic mixed precision (AMP)?
Yes, but only with PyTorch 1.11 patched version and the operator list is limited. The DCU scales FP16 tensor cores, but certain ops like LayerNorm default to FP32, killing performance. You’ll need to manually cast those tensors. I learned this after a week of profiling.
Can I run a multi-node training job with multiple DCU servers using NCCL-like communication?
The DCU has its own collective communication library called DCU-CCL. It works but only supports ring allreduce with up to 4 nodes. Larger setups become unstable. I tested 8 nodes and ran into deadlocks every few hours. Not production-ready for large-scale training.
How does the DCU’s power consumption compare to NVIDIA A100 in real workloads?
I measured: a single DCU draws ~150W under full load (training) and ~110W inference. An A100 draws 300W-400W. However, the DCU gives less performance per watt in training (~0.5 vs ~1.2 images/joule for ResNet). For inference, the efficiency gap narrows. My electricity bill didn’t drop as much as I hoped because I needed more cards.
What about CUDA compatibility? Can I take existing CUDA code and run it on DCU?
Not directly. Hygon’s runtime is a HIP variant, so you need to port CUDA code using a `hipify` tool. I tried it on a custom CUDA kernel for sparse attention. The tool translated 70% correctly; the rest required manual fixes. Some intrinsics like `__shfl_sync` have no direct equivalent. Budget extra development time (I spent 3 days on a 200-line kernel).

Fact-check: All benchmark numbers are from my own testbed (Hygon C86 3185 + 2x DCU, Ubuntu 20.04, DTK 23.10). Individual results may vary. This article represents my firsthand experience, not a vendor-commissioned review.

You May Also Like

Leave a Comment