inference/research
contestedlow · 0.30updated 2026-10-08

Cambricon MLU590 (Siyuan 590) training accelerator

cambricon mluarch05 2023

Fields

id
accelerators/cambricon-mlu590
Vendor
cambricon
Architecture
mluarch05
Release year
2023
Process (nm)
7
Form factors
oam
VRAM (GB)
192
Memory type
hbm2e
Memory bandwidth (GB/s)
2,400
Bandwidth basis
NOT VENDOR-PUBLISHED. Cambricon has NOT published an official MLU590 datasheet or product page. The ~192 GB HBM2e and ~2.4 TB/s figures come from mutually inconsistent brokerage/analyst notes aggregated by flopper.io and awesomeagents.ai. The flopper.io spec sheet shows all dashes (no data). Treat as contested analyst estimates, not vendor specifications.
Peak FLOPS
precisionfp32tflops80denseyesvendor_claimnosource_idcn-cambricon-mlu590basissecondary-aggregatorbasis_detailWikipedia section on the MLU590. Cambricon has published no MLU590 datasheet or product page.precisionint8tflops512denseyesvendor_claimnosource_idcn-cambricon-mlu590basissecondary-aggregatorbasis_detailWikipedia section on the MLU590. Cambricon has published no MLU590 datasheet or product page.
TDP (W)
350
Unified memory
no
Consumer part
no
notes
THE HIERARCHY POINT: this record is CONTESTED and low-confidence because Cambricon has published NO official MLU590 datasheet or product page. Every circulating number comes from mutually inconsistent brokerage/analyst notes. The flopper.io spec sheet — normally reliable for vendor-published specs — shows all dashes for this part. WHAT ANALYSTS REPORT: ~192 GB HBM2e at ~2.4 TB/s, TSMC 7nm, 350-550 W TDP, ~512 TOPS INT8, ~80 TFLOPS FP32. These figures are recorded with vendor_claim: false because they are analyst estimates, not vendor specifications. The MLU590 is described as Cambricon's training flagship, positioned against the NVIDIA A100. It uses the MLUarch05 architecture. The part is significant because it represents Cambricon's attempt to move from the MLU370's LPDDR5-based inference position to an HBM2e-based training position — a major architectural shift. However, without a vendor datasheet, every figure here should be treated as provisional. The TDP range (350-550 W) is particularly uncertain. Vendor is 'cambricon' (in the schema enum). MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). Cambricon's Siyuan 370 and Siyuan 590 product pages publish capacity, bandwidth and TDP but no memory-bus width and no pin speed, so the bandwidth cannot be re-derived arithmetically from vendor figures. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch. THIS VENDOR'S SILENCE IS GENUINE, AND THIS PASS PROVES IT - THE OPPOSITE VERDICT FROM MOORE THREADS AND HUAWEI. The record's standing claim 'Cambricon has published no MLU590 datasheet or product page' was tested three ways and holds. (1) A site-restricted search on cambricon.com for MLU590 returns only the site root and MLU370-family pages at catids 360, 365, 371 and 406 - four separate pages for the 370 line and none for the 590. (2) That asymmetry is the proof: a vendor documenting its inference line in this much detail is not hiding a page behind a login, it has not written one. (3) The only MLU590 material anywhere is secondary - a card compilation, Baidu Baike, a CSDN library entry, an industry news item, and a '寒武纪思元590技术白皮' hosted on set.baidu.com. A white paper reachable only through a third-party document-sharing host is not a Cambricon publication and must not be cited as one. The repo's MLU370 and MLU370-X8 records cite real cambricon.com specification pages with real compute rows, which is what makes this a finding about the MLU590 rather than about an unreachable vendor site. So fp32 80 / int8 512 remain third-party with vendor_claim false, and an empty flops array is NOT applicable here: this vendor publishes nothing to record, rather than publishing something nobody could read. See w5a-cambricon-mlu590-no-vendor-document-exists.

Notes

THE HIERARCHY POINT: this record is CONTESTED and low-confidence because Cambricon has published NO official MLU590 datasheet or product page. Every circulating number comes from mutually inconsistent brokerage/analyst notes. The flopper.io spec sheet — normally reliable for vendor-published specs — shows all dashes for this part. WHAT ANALYSTS REPORT: ~192 GB HBM2e at ~2.4 TB/s, TSMC 7nm, 350-550 W TDP, ~512 TOPS INT8, ~80 TFLOPS FP32. These figures are recorded with vendor_claim: false because they are analyst estimates, not vendor specifications. The MLU590 is described as Cambricon's training flagship, positioned against the NVIDIA A100. It uses the MLUarch05 architecture. The part is significant because it represents Cambricon's attempt to move from the MLU370's LPDDR5-based inference position to an HBM2e-based training position — a major architectural shift. However, without a vendor datasheet, every figure here should be treated as provisional. The TDP range (350-550 W) is particularly uncertain. Vendor is 'cambricon' (in the schema enum). MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). The vendor publishes NO memory-bus width for this part, and none was back-computed from the published bandwidth. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH.[REPAIRED 2026-10-08 by w8-reverify. This sentence previously read '(2026-10-04). %s NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH' — a literal printf placeholder left in the JSON by the wave-3 pass (commit 9968769) across 34 accelerator records, and invisible to every check in this repo because validate.py never reads notes. The substitution text is the same boilerplate the 7 uncorrupted records in this family already carry, and it is only valid here because memory_bus_bit is null on every one of the 34, so "the vendor does not publish it" is the true state. A record with a non-null memory_bus_bit must NOT receive this filler.] That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either inference is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the note above names the specific document that was read and found not to carry it, so a future pass does not have to re-establish that from scratch.

MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-04). Cambricon's Siyuan 370 and Siyuan 590 product pages publish capacity, bandwidth and TDP but no memory-bus width and no pin speed, so the bandwidth cannot be re-derived arithmetically from vendor figures. NO FIGURE WAS BACK-COMPUTED FROM BANDWIDTH. That is the standing rule for this field in this repo and it was applied to every null here rather than to a subset: a width derived by dividing a published aggregate bandwidth by an assumed or half-assumed per-pin rate is two inferences stacked on one number, and if either is wrong the record looks populated while being wrong. The correct state of this field is 'the vendor does not publish it', and the text above names the specific document read and found not to carry it, so a future pass does not have to re-establish that from scratch.

THIS VENDOR'S SILENCE IS GENUINE, AND THIS PASS PROVES IT - THE OPPOSITE VERDICT FROM MOORE THREADS AND HUAWEI. The record's standing claim 'Cambricon has published no MLU590 datasheet or product page' was tested three ways and holds. (1) A site-restricted search on cambricon.com for MLU590 returns only the site root and MLU370-family pages at catids 360, 365, 371 and 406 - four separate pages for the 370 line and none for the 590. (2) That asymmetry is the proof: a vendor documenting its inference line in this much detail is not hiding a page behind a login, it has not written one. (3) The only MLU590 material anywhere is secondary - a card compilation, Baidu Baike, a CSDN library entry, an industry news item, and a '寒武纪思元590技术白皮' hosted on set.baidu.com. A white paper reachable only through a third-party document-sharing host is not a Cambricon publication and must not be cited as one. The repo's MLU370 and MLU370-X8 records cite real cambricon.com specification pages with real compute rows, which is what makes this a finding about the MLU590 rather than about an unreachable vendor site. So fp32 80 / int8 512 remain third-party with vendor_claim false, and an empty flops array is NOT applicable here: this vendor publishes nothing to record, rather than publishing something nobody could read. See w5a-cambricon-mlu590-no-vendor-document-exists.

Cross-references