Haink KnowledgeCase StudiesAbout Contact sales
Home / Knowledge / Brands / Sugon / Hygon DCU

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:

HygonAMD equivalentWhat it means in practice
DCU architectureCDNA (Instinct MI series)A GPGPU execution model, not a fixed-function AI engine
DTK (Deep Toolkit) / HIPROCm / HIPSource-level compatibility, not binary CUDA compatibility
XGMI between cardsInfinity FabricCard-to-card links at silicon level, below any integrator's fabric
HCCL collectivesRCCL / NCCLDistributed 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.

GenerationAMD classPublished characteristics
深算一号 — Z100 / K100CDNA 1 (MI100)7 nm, HBM2, FP64 at half of FP32
深算二号 — Z200 / K200CDNA 2 (MI200)6 nm, HBM2e, matrix cores, approximately 450 W
深算三号 — BW familyCDNA 3 classDevice 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:

CharacteristicValueBasis
HBM per card144 GBDerived from the published 5.62 TB across 40 accelerators: 144 × 40 = 5,760 GiB ÷ 1,024 = 5.625 TiB
FP8 throughput per card≈ 700 TFLOPSDerived: ≥28 PFLOPS aggregate ÷ 40 cards
PrecisionsFP64 · FP32 · TF32 · BF16 · FP16 · FP8Solution manual — list only, quantified for FP8 alone
Form factorOAM moduleUser manual firmware components; solution manual comparisons against eight-card OAM servers
Cards per node4, with one Hygon C86-4G/H hostProduct page and manuals
HBM bandwidthNot publishedZero occurrences across all four documents
FP64 throughputNot published"FP64" appears once in four documents — in the precision list, with no figure
Board powerNot publishedOnly 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.

NameWhat it is
BW1100Third 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.
BW1000Third generation, but a different SKU: 64 GB, PCIe, no FP8. Not the scaleX40 card. See the next section.
K100 AIAn 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.
BW100Does 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.

 BW1000scaleX40 card
Memory64 GB HBM2e144 GB
Memory bandwidth1.6 TB/snot published
FP8Not supportedSupported
Form factorPCIe Gen5 ×16OAM 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.

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

Sources

Haink
info@haink.org

Winning House
72–76 Wing Lok Street
Sheung Wan, Hong Kong

© 2026 Haink. All rights reserved.  ·  Privacy Policy  ·  TermsHong Kong · Dubai · Singapore · Mainland China · Delaware (USA)