Hygon DCU and DeepComputing 3: China's CDNA-Derived Accelerator, Explained
Written and maintained by Haink's infrastructure team · Compiled from Sugon and Hygon primary documentation, platform specifications and published developer measurements, 5 September 2026
The accelerator inside Sugon's scaleX40 superpod is a Hygon DeepComputing 3. Sugon has never published its part number, its memory bandwidth, its FP64 throughput or its board power — and several different part numbers circulate in English-language material, one of which does not exist.
This page sets out what is actually known about the accelerator, what is not, and how to tell the cards in this family apart. The fact that makes all of it tractable: a DCU is not a Chinese GPU designed from first principles. It is an AMD CDNA-derived GPGPU with an AMD ROCm-derived software stack, and that determines almost everything a buyer needs to know — including what a port will cost.
What a DCU is
DCU stands for Deep Computing Unit, the accelerator line of Hygon Information Technology (海光信息), the processor company that Sugon (中科曙光) co-founded in 2014 and in which it holds 27.96%. The family is branded 深算 — "deep compute" — and numbered by generation: 深算一号, 深算二号, 深算三号.
Architecturally it is a general-purpose GPU: wide arrays of shader-style compute units with matrix acceleration, addressed through a CUDA-like programming model, able to run arbitrary parallel code rather than only an operator set fixed at design time. That choice separates Hygon from most of the domestic field, and the consequences are set out further down.
The AMD lineage
Hygon's silicon traces to a 2016 licensing arrangement with AMD, structured as two joint ventures — Chengdu Haiguang Microelectronics (AMD 51% / Hygon 49%) and Chengdu Haiguang Integrated Circuit Design (AMD 30% / Hygon 70%) — for which AMD received $293 million. The licence covered first-generation Zen only, for the domestic Chinese market, and further licensing ended in 2019. Everything since is Hygon's own iteration.
The accelerator line inherited the same relationship, and it maps cleanly:
| Hygon | AMD equivalent | What it means in practice |
|---|---|---|
| DCU architecture | CDNA (Instinct MI series) | A GPGPU execution model, not a fixed-function AI engine |
| DTK (Deep Toolkit) / HIP | ROCm / HIP | Source-level compatibility, not binary CUDA compatibility |
| XGMI between cards | Infinity Fabric | Card-to-card links at silicon level, below any integrator's fabric |
| HCCL collectives | RCCL / NCCL | Distributed training through familiar collective primitives |
This converts an unfamiliar product into a familiar engineering question. Nobody needs to speculate about how hard a DCU is to program. Ask instead: how hard was it to move this workload from NVIDIA to AMD Instinct? The answer is close to the same answer.
| Generation | AMD class | Published characteristics |
|---|---|---|
| 深算一号 — Z100 / K100 | CDNA 1 (MI100) | 7 nm, HBM2, FP64 at half of FP32 |
| 深算二号 — Z200 / K200 | CDNA 2 (MI200) | 6 nm, HBM2e, matrix cores, approximately 450 W |
| 深算三号 — BW family | CDNA 3 class | Device identifies as BW, ISA gfx936, 80 compute units |
The accelerator in the scaleX40
We searched the full text of Sugon's scaleX40 product page, product brochure, 45-page solution manual and 207-page user manual for an accelerator part number. There is none. Across all four documents the card is called only 深算三号 GPU or 深算三号 DCU.
What the documents do give:
| Characteristic | Value | Basis |
|---|---|---|
| HBM per card | 144 GB | Derived from the published 5.62 TB across 40 accelerators: 144 × 40 = 5,760 GiB ÷ 1,024 = 5.625 TiB |
| FP8 throughput per card | ≈ 700 TFLOPS | Derived: ≥28 PFLOPS aggregate ÷ 40 cards |
| Precisions | FP64 · FP32 · TF32 · BF16 · FP16 · FP8 | Solution manual — list only, quantified for FP8 alone |
| Form factor | OAM module | User manual firmware components; solution manual comparisons against eight-card OAM servers |
| Cards per node | 4, with one Hygon C86-4G/H host | Product page and manuals |
| HBM bandwidth | Not published | Zero occurrences across all four documents |
| FP64 throughput | Not published | "FP64" appears once in four documents — in the precision list, with no figure |
| Board power | Not published | Only the system figure, under 45 kW typical |
The bandwidth omission deserves its own sentence, because Sugon makes the argument for us. Its solution manual states that memory capacity and memory bandwidth have become a more pressing bottleneck than compute — and then does not publish the memory bandwidth of its own accelerator. For a system the vendor scopes to inference, where token generation is bounded by bandwidth rather than arithmetic, that is the number an evaluation cannot proceed without. Request it in writing.
Set against NVIDIA's H200, which carries 141 GB of HBM3e and delivers 1,979 TFLOPS of dense FP8, the shape is readable even with the gaps: marginally more memory per card, roughly a third of the arithmetic. It is a memory-forward part, and the system built around it is a memory-forward system.
The names in circulation
Four part numbers appear in English-language material about this accelerator. Only one of them can be the scaleX40 card.
| Name | What it is |
|---|---|
| BW1100 | Third generation, 144 GB, module form factor, FP8 supported. The only name consistent with what Sugon publishes for the scaleX40 — capacity, FP8 capability and form factor all match. |
| BW1000 | Third generation, but a different SKU: 64 GB, PCIe, no FP8. Not the scaleX40 card. See the next section. |
| K100 AI | An earlier, separate product: 40 GB HBM2e, 1.2 TB/s, 192 TFLOPS FP16, 400 W. Its figures are the most republished Hygon accelerator numbers in existence, which is why they end up attached to the wrong machine. |
| BW100 | Does not exist. A dropped digit from a single unsourced write-up, which also mislabels the third generation as Z100 — a first-generation part. |
The identification of the scaleX40 card as BW1100 rests on three matching characteristics rather than on a vendor statement. We present it as an inference, and so should anyone repeating it.
Why BW1000's numbers do not transfer
This matters because BW1000 is the one card in the family with a full published specification and public availability, so its figures travel — and they are the wrong figures for the scaleX40.
| BW1000 | scaleX40 card | |
|---|---|---|
| Memory | 64 GB HBM2e | 144 GB |
| Memory bandwidth | 1.6 TB/s | not published |
| FP8 | Not supported | Supported |
| Form factor | PCIe Gen5 ×16 | OAM module |
The FP8 row is the decisive one. Platform documentation for BW1000 states that its hardware architecture and software stack cannot execute FP8, and that loading an FP8-quantised model fails outright. The scaleX40 is specified at ≥28 PFLOPS of FP8. These are not two bins of one chip; on the capability that matters most for modern inference, they are different silicon.
What BW1000 is genuinely useful for is a question buyers ask about any unfamiliar accelerator: does the domestic stack deliver what its datasheet claims? It is specified at 480 TFLOPS FP16, 60 FP32 and 30 FP64, and a documented framework-level test — square matrices from 2,048 to 12,288, ten warm-up iterations, thirty timed runs, medians, explicit synchronisation — reached 439, 55.8 and 26.3 respectively, with measured memory bandwidth at roughly 80% of specification. Between 88% and 93% of datasheet across the board is a normal result for any accelerator, and it is evidence about the toolchain rather than about the scaleX40's silicon.
It is also the practical answer to "how do I get a number I can trust": BW1000 is available on several public compute platforms, so a proof of concept on your own code can start before a purchase order exists.
An arithmetic puzzle worth putting to the vendor
Sugon's ≥28 PFLOPS across 40 cards implies roughly 700 TFLOPS of FP8 per accelerator. BW1000 — same generation, one SKU down — is specified at 480 TFLOPS of FP16.
FP8 throughput on this class of architecture is typically about double FP16. Working backwards from 700 TFLOPS FP8 gives roughly 350 TFLOPS FP16 for the scaleX40 card, which would put it below the smaller-memory SKU. An odd result for the larger part.
Three explanations fit: the 28 PFLOPS figure may be quoted with sparsity applied; Sugon's "≥28" may be conservative and the real number substantially higher; or the cards may run at different clocks in a 45 kW pod than in a PCIe chassis. We cannot distinguish between them from published information and we do not guess. It is a good question to put to Sugon, and the answer would firm up more than one row of any comparison.
DTK, and what a port actually costs
DTK — Deep Toolkit — descends from AMD's ROCm rather than being written from scratch. That produces three tiers of migration cost.
- Framework-level code — PyTorch or a serving runtime calling standard operators — moves with a recompile and a version-matching exercise. This is what Sugon's claim of 800+ pre-adapted models describes.
- HIP-portable CUDA — ordinary kernels without vendor-specific intrinsics — moves through source translation, the same path AMD users already take.
- Hand-optimised CUDA — PTX-level work, warp-primitive tricks, or CUDA-only library dependencies — is a rewrite. This is where migration budgets are lost.
There is a fourth cost that no tier captures, and it surfaces in every hands-on account: version discipline. Framework packages in a DCU environment carry DTK build tags, and installing a stock build from public PyPI over them leaves every package individually valid and the environment collectively broken — the device stops being detected, and the error appears far from its cause. Triton and custom attention extensions are where this bites hardest. Budget for an engineer who owns the environment, not just for the port.
The diagnostic before any DCU evaluation is therefore not about Hygon at all: audit how much of the workload sits in tier three. A shop already running on AMD Instinct is most of the way there. A shop whose performance rests on hand-tuned CUDA faces real engineering work regardless of what the hardware costs.
GPGPU or domain-specific: how this differs from Ascend
The most useful comparison for a buyer is not Hygon against NVIDIA but Hygon against Huawei's Ascend, because the two are opposite answers to the same problem and the trade-off is structural rather than generational.
Ascend is a domain-specific architecture built around dedicated matrix units, programmed through CANN, Huawei's own stack. A design like that can extract more performance per transistor for the operator shapes it was built for. The cost is that the model is Huawei's alone: an operator outside the anticipated set becomes a request to the vendor, and the software ecosystem starts from nothing and is grown deliberately.
Hygon took the opposite trade. A CDNA-derived GPGPU with a ROCm-derived stack gives up architectural specialisation and gains an ecosystem it did not have to build: HIP source portability, an existing body of AMD-targeted code, and a programming model a CUDA developer recognises. For workloads that are unusual, change frequently, or depend on custom kernels, the general-purpose path has the shorter route to running code. For stable, well-characterised serving, specialisation has a real efficiency argument. Neither is the general answer.
One externally observable data point on ecosystem responsiveness: when DeepSeek V4 was released in April 2026, Hygon shipped day-zero support alongside Ascend and Cambricon. That says the toolchain is maintained by people who track model releases. It says nothing about how fast the models then run.
What has and has not been measured
No Chinese accelerator has been submitted to a standardised benchmark. MLPerf Inference v6.0 in April 2026 had twenty-four submitting organisations, all running NVIDIA, AMD or Intel silicon, and no third-party laboratory result exists for a DCU of any generation.
Developer-published testing does exist, and its quality varies sharply. The BW1000 work described above documents its method and is usable on that basis. Testing of the 144 GB card has appeared in promotional write-ups whose cross-vendor comparisons set FP8 against competitors' BF16 at a quarter of the context length, with the competitors unnamed — those numbers we discard. What those pieces do establish, because it appears as working configuration rather than prose, is the operational profile: FP8 W8A8 quantisation with an FP8 KV cache, a DCU-specific attention backend, eight-card nodes across four NUMA domains, and NUMA binding worth 10–15% of throughput.
One result from them is worth keeping. On a 122-billion-parameter model, accuracy benchmarks returned 98.64% on gsm8k, 92.16% on mmlu and 96.34% on humaneval. Buyers evaluating unfamiliar silicon usually ask whether the numerics are trustworthy before they ask how fast it is; that is the question those figures address.
When a DCU is not your choice
Where the workload is compute-bound and current NVIDIA silicon is available. Roughly 700 TFLOPS of FP8 per card against an H200's 1,979 dense is a gap no configuration closes. If arithmetic throughput binds and the alternative is on the table, take the alternative.
Where the stack depends on hand-tuned CUDA. The port is real engineering work, it lands on the team that can least be spared, and it outlasts the hardware evaluation. Cost it before committing.
Where procurement requires a benchmarked number. No standardised result exists for any DCU generation, and no vendor material substitutes for one. A proof of concept on your own workload is the only path — and it can start on a rented card this week.
Where it does deserve consideration: memory-bound inference at scale, where pooled capacity rather than peak arithmetic sets throughput; environments with no access to current-generation NVIDIA parts, where the comparison is against nothing; and workloads already portable to AMD Instinct, where migration is closer to a recompile than a rewrite.
Sizing a workload for Hygon DCU?
Send us the workload profile and, if you have one, the quoted configuration. We will tell you which card is actually being offered, what the specification commits the vendor to, which figures are missing and what each would change, and what the port is likely to cost. Within one business day — and we will say plainly when the answer is that this is the wrong accelerator for the job.
Get the configuration reviewed Prefer email? sales@haink.org
Frequently asked questions
What is a Hygon DCU?
DCU stands for Deep Computing Unit, the accelerator line of Hygon Information Technology (海光信息), branded 深算 and numbered by generation. Architecturally it is a general-purpose GPU derived from AMD's CDNA, programmed through DTK, a toolkit descended from AMD's ROCm. It is the accelerator used in Sugon's scaleX superpods.
Which card does the Sugon scaleX40 use?
Sugon does not say. We searched the full text of its product page, brochure, 45-page solution manual and 207-page user manual, and no accelerator part number appears in any of them — the card is called only 深算三号 GPU. Three published characteristics identify it circumstantially: 144 GB per card (derived from 5.62 TB across 40 accelerators), FP8 capability (implied by the published 28 PFLOPS FP8), and OAM module form factor. All three match the BW1100 designation. That is an inference, not a vendor confirmation.
What is the memory bandwidth of the scaleX40 accelerator?
It has not been published — the figure appears nowhere in Sugon's product page, brochure, solution manual or user manual. Because token generation in language-model inference is bounded by memory bandwidth rather than arithmetic, a point Sugon's own solution manual makes, this is the most consequential absent number in the specification and should be requested in writing. Figures published for other cards in the family do not transfer to it.
Is the K100 AI the card in the scaleX40?
No, and this is the most common error in circulation. K100 AI is an earlier, separate product with 40 GB of HBM2e, 1.2 TB/s of bandwidth, 192 TFLOPS at FP16 and 400 W board power. The scaleX40 carries 144 GB per accelerator — 3.6 times the memory. Sizing a workload against K100 AI figures produces a meaningless answer.
What is the difference between BW1000 and BW1100?
Different cards of the same generation, not two bins of one chip. BW1000 has 64 GB of HBM2e at 1.6 TB/s in a PCIe form factor and cannot execute FP8 — its platform documentation states that both the hardware architecture and the software stack lack it. BW1100 has 144 GB in a module form factor and runs FP8 in production, which is what the scaleX40's published FP8 figure requires. BW1000's specifications and measurements should never be transferred to the scaleX40.
Can a DCU run CUDA code?
Not as binaries. DTK descends from AMD's ROCm, so the migration path is the AMD path: framework-level code moves with a recompile, ordinary CUDA kernels move through HIP-style source translation, and hand-optimised CUDA with PTX-level work or CUDA-only library dependencies requires a rewrite. A separate and frequently underestimated cost is version discipline — framework packages carry DTK build tags, and installing stock builds from public PyPI over them breaks device detection in ways that are hard to diagnose.
Are there independent benchmarks of Hygon accelerators?
No standardised ones. No Chinese accelerator appeared in MLPerf Inference v6.0 in April 2026, whose twenty-four submitters all ran NVIDIA, AMD or Intel silicon, and no third-party laboratory result exists. Developer-published measurements do exist and vary in quality: one documented framework-level test reached 88–93% of a card's specified GEMM throughput, while several other write-ups are promotional and use non-matching configurations. A proof of concept on your own workload is the practical route to a number you can rely on.
Related
- Sugon scaleX40-3G — full specifications — the system this accelerator was built for, and the figures missing from its datasheet
- scaleX40 vs DGX H200 vs DGX B300 — what the memory-forward trade is worth
- Sugon (中科曙光) · Hygon C86 processors
- Huawei enterprise IT — Ascend and CANN, the domain-specific alternative
- AI cluster architecture · GPU server buying guide
Sources
- Sugon — scaleX40 product page (40 accelerators, 28 PFLOPS FP8 aggregate, 5.62 TB HBM, node composition)
- Sugon — scaleX40 solution manual, 45 pp., scaleX40-3G product brochure and scaleX40-3G server user manual, 207 pp. (precision support list, OAM firmware components, memory-bandwidth bottleneck statement; all four searched in full for an accelerator part number, with no result)
- 模力方舟 — Hygon BW1000 platform specification (64 GB HBM2e, 1.6 TB/s, FP16 480 / FP32 60 / FP64 30 TFLOPS, FP8 unsupported at architecture level, XGMI and HCCL, DTK package conventions)
- CSDN — Hygon BW1000 DCU: hardware, software stack and development practice, 16 July 2026 (documented GEMM and bandwidth measurements, DTK version discipline)
- Zhihu — BW1100 deployment write-ups, June–July 2026 (144 GB, module form factor, FP8 configurations, NUMA topology, accuracy benchmarks; promotional in tone, cross-vendor comparisons not used here)
- Hygon — STAR Market IPO prospectus, DCU sections
- Hygon Information Technology (AMD joint-venture structure, $293m licence, scope and end of licensing)
- NVIDIA — H200 datasheet (141 GB HBM3e, 1,979 TFLOPS dense FP8, used for comparison)
- MLCommons — MLPerf Inference v6.0 results, April 2026 (submitter list)
- TrendForce — day-zero DeepSeek-V4 adaptation, 29 April 2026
