inference/research
verifiedmedium · 0.80updated 2026-10-08

Cambricon MLU370-X8 AIDC accelerator (dual Siyuan 370, train+infer)

cambricon mluarch03 (dual Siyuan 370 chiplet) 2022

Fields

id
accelerators/cambricon-mlu370-x8
Vendor
cambricon
Architecture
mluarch03 (dual Siyuan 370 chiplet)
Release year
2022
Process (nm)
7
Form factors
pcie
VRAM (GB)
48
Memory type
lpddr5
Memory bandwidth (GB/s)
614.4
Bandwidth basis
Primary vendor source states it directly: LPDDR5, 48 GB, 614.4 GB/s. Cambricon publishes no bus width or pin speed on the card pages, so the figure cannot be re-derived arithmetically - but note it is EXACTLY 2x the 307.2 GB/s of the single-S4/S8 card, which is consistent with a duplicated memory subsystem on the dual-die part. Source cn-cambricon-mlu370-x8.
Peak FLOPS
precisionfp32tflops24denseyesvendor_claimyessource_idcn-cambricon-mlu370-x8basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own fp32 for Cambricon MLU370-X8 AIDC accelerator (dual Siyuan 370, train+infer) (source of record: 'Cambricon MLU370-X8 AIDC accelerator card product page', kind: spec-sheet). Recorded dense:true as printed.precisionfp16tflops96denseyesvendor_claimyessource_idcn-cambricon-mlu370-x8basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own fp16 for Cambricon MLU370-X8 AIDC accelerator (dual Siyuan 370, train+infer) (source of record: 'Cambricon MLU370-X8 AIDC accelerator card product page', kind: spec-sheet). Recorded dense:true as printed.precisionbf16tflops96denseyesvendor_claimyessource_idcn-cambricon-mlu370-x8basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own bf16 for Cambricon MLU370-X8 AIDC accelerator (dual Siyuan 370, train+infer) (source of record: 'Cambricon MLU370-X8 AIDC accelerator card product page', kind: spec-sheet). Recorded dense:true as printed.precisionint8tflops256denseyesvendor_claimyessource_idcn-cambricon-mlu370-x8basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own int8 for Cambricon MLU370-X8 AIDC accelerator (dual Siyuan 370, train+infer) (source of record: 'Cambricon MLU370-X8 AIDC accelerator card product page', kind: spec-sheet). Recorded dense:true as printed.precisionint16tflops128denseyesvendor_claimyessource_idcn-cambricon-mlu370-x8basisvendor-spec-sheetbasis_detailMLU370-X8 product page, 'INT16 128 TOPS'. This is an integer TOPS row, not FP64 and not a float path - precision:int16.
TDP (W)
250
Unified memory
no
Consumer part
no
notes
THE HIERARCHY POINT: the X8 is the sibling of the existing cambricon-mlu370 record and is recorded separately because it is a genuinely different memory and interconnect position, not a bigger version of the same thing. Both cards run the same 7 nm MLUarch03 die (39 billion transistors, first Cambricon chiplet part, vendor-published max 256 TOPS INT8 at the DIE level per cn-cambricon-siyuan370-chip) - so on raw compute the X8's card-level 256 TOPS INT8 is the same number the vendor quotes for one die, because the dual-die card's figures are the die's figures rather than a doubling. What actually doubles is memory and media resources: the vendor explicitly states the X8 'integrates twice the memory and codec resources of the standard Siyuan 370 accelerator card'. Memory goes 48 GB / 307.2 GB/s on the single card to 48 GB / 614.4 GB/s on the X8 - same capacity, double the bandwidth - which is the INVERSE of the Atlas 300I Duo's trade and produces a WORSE arithmetic intensity, not a better one, and it is worth being precise about why because it is counter-intuitive: 256 TOPS / 614.4 GB/s = 417 INT8 FLOP/byte at the X8 card level, against the single S4/S8's 192 TOPS / 307.2 GB/s = 625. Bandwidth doubles but the vendor's card-level compute figure does not, so arithmetic intensity FALLS by a third. The die-level 256 TOPS is the vendor's own figure and the card-level figure is also 256 TOPS, which is the inconsistency - the X8 page appears to quote per-die compute alongside doubled memory resources. Either way both configurations sit far below a same-generation HBM GPU on intensity (an H100 is roughly 1,350 INT8 FLOP/byte), so the X8's advantage over the single card is capacity for train+infer work and a 200 GB/s scale-up path, not a better roofline position. NO HBM ANYWHERE - LPDDR5 on both, so the absolute ceiling is low and the honest framing is that Cambricon's 370 generation is a capacity-efficient, bandwidth-poor design for inference at small batch and a marginal one for training. MLU-Link is the standout interconnect: 4 ports x 16 lanes at 50 Gbps = 200 GB/s BIDIRECTIONAL AGGREGATE per card, as the vendor states (the card page's spec table prints 'MLU-Link(TM) 带宽 | 聚合带宽200GB/s Bi-direction', i.e. aggregate, both directions). AUDIT CORRECTION 2026-10-04: the record previously derived this as '4 ports x 16 lanes at 50 Gbps = 200 GB/s' with no direction stated, and then repeated it as '200 GB/s bidirectional aggregate'. The derivation is wrong by a factor of 2 - four ports of 16 lanes at 50 Gbps is 4 x 16 x 50 = 3,200 Gbit/s of raw lanes, which is 400 GB/s AGGREGATE across both directions, i.e. 200 GB/s PER DIRECTION. So the vendor's printed 200 GB/s figure is the per-direction number and the record's 'bidirectional aggregate' label is backwards. Cross-check that settles it: Cambricon states the 200 GB/s is '3.1 times the PCIe 4.0 bandwidth' (3.1x). PCIe Gen4 x16 is 16 GT/s x 16 lanes / 8 = 32 GB/s PER DIRECTION and 64 GB/s bidirectional aggregate. 200/64 = 3.125, i.e. '3.1x' - which only works if Cambricon's 200 GB/s is being compared against the 64 GB/s BIDIRECTIONAL AGGREGATE of PCIe 4.0. That makes the vendor's own comparison internally inconsistent in exactly the way this repo has been bitten before (compare a per-direction number to an aggregate and the ratio is silently doubled), and it means the phrase '聚合带宽200GB/s Bi-direction' on the card page cannot be read as '200 GB/s total, both directions' without contradicting Cambricon's own 3.1x claim. The safe reading: 200 GB/s is a per-direction-scale figure and the MLU-Link fabric is genuinely strong, but the exact direction convention is ambiguous in the vendor's own text. LEFT UNRESOLVED rather than silently picked - the interconnect field carries only the generation, which is unambiguous ('x16 PCIe Gen4' on the same spec table), so no numeric field in this record needed changing and nothing downstream is silently halved., which the vendor states is 3.1x PCIe 4.0 bandwidth and which is a genuinely strong scale-up path relative to the card's own 614 GB/s of memory - better ratio than any GPU of the period, and the same 200 GB/s the vendor claims per chip at die level. Vendor's own measured claim (with methodology given, which is rare): on four common AI models, single-card MLU370-X8 performance is comparable to a 350 W RTX GPU, with better parallel scaling at 8 cards, tested on NF5468M5 / Xeon Gold 5218 at 2.30 GHz with MLU370 SDK 1.2.0. Full-height full-length dual-slot, 250 W, passive. Precisions supported: FP32/FP16/BF16/INT16/INT8/INT4, but as with the sibling record the INT4 row above reuses the INT16 figure and must not be read as an INT4 measurement. Software is NeuWare plus the MagicMind MLIR inference engine. 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.

Notes

THE HIERARCHY POINT: the X8 is the sibling of the existing cambricon-mlu370 record and is recorded separately because it is a genuinely different memory and interconnect position, not a bigger version of the same thing. Both cards run the same 7 nm MLUarch03 die (39 billion transistors, first Cambricon chiplet part, vendor-published max 256 TOPS INT8 at the DIE level per cn-cambricon-siyuan370-chip) - so on raw compute the X8's card-level 256 TOPS INT8 is the same number the vendor quotes for one die, because the dual-die card's figures are the die's figures rather than a doubling. What actually doubles is memory and media resources: the vendor explicitly states the X8 'integrates twice the memory and codec resources of the standard Siyuan 370 accelerator card'. Memory goes 48 GB / 307.2 GB/s on the single card to 48 GB / 614.4 GB/s on the X8 - same capacity, double the bandwidth - which is the INVERSE of the Atlas 300I Duo's trade and produces a WORSE arithmetic intensity, not a better one, and it is worth being precise about why because it is counter-intuitive: 256 TOPS / 614.4 GB/s = 417 INT8 FLOP/byte at the X8 card level, against the single S4/S8's 192 TOPS / 307.2 GB/s = 625. Bandwidth doubles but the vendor's card-level compute figure does not, so arithmetic intensity FALLS by a third. The die-level 256 TOPS is the vendor's own figure and the card-level figure is also 256 TOPS, which is the inconsistency - the X8 page appears to quote per-die compute alongside doubled memory resources. Either way both configurations sit far below a same-generation HBM GPU on intensity (an H100 is roughly 1,350 INT8 FLOP/byte), so the X8's advantage over the single card is capacity for train+infer work and a 200 GB/s scale-up path, not a better roofline position. NO HBM ANYWHERE - LPDDR5 on both, so the absolute ceiling is low and the honest framing is that Cambricon's 370 generation is a capacity-efficient, bandwidth-poor design for inference at small batch and a marginal one for training. MLU-Link is the standout interconnect: 4 ports x 16 lanes at 50 Gbps = 200 GB/s BIDIRECTIONAL AGGREGATE per card, as the vendor states (the card page's spec table prints 'MLU-Link(TM) 带宽 | 聚合带宽200GB/s Bi-direction', i.e. aggregate, both directions). AUDIT CORRECTION 2026-10-04: the record previously derived this as '4 ports x 16 lanes at 50 Gbps = 200 GB/s' with no direction stated, and then repeated it as '200 GB/s bidirectional aggregate'. The derivation is wrong by a factor of 2 - four ports of 16 lanes at 50 Gbps is 4 x 16 x 50 = 3,200 Gbit/s of raw lanes, which is 400 GB/s AGGREGATE across both directions, i.e. 200 GB/s PER DIRECTION. So the vendor's printed 200 GB/s figure is the per-direction number and the record's 'bidirectional aggregate' label is backwards. Cross-check that settles it: Cambricon states the 200 GB/s is '3.1 times the PCIe 4.0 bandwidth' (3.1x). PCIe Gen4 x16 is 16 GT/s x 16 lanes / 8 = 32 GB/s PER DIRECTION and 64 GB/s bidirectional aggregate. 200/64 = 3.125, i.e. '3.1x' - which only works if Cambricon's 200 GB/s is being compared against the 64 GB/s BIDIRECTIONAL AGGREGATE of PCIe 4.0. That makes the vendor's own comparison internally inconsistent in exactly the way this repo has been bitten before (compare a per-direction number to an aggregate and the ratio is silently doubled), and it means the phrase '聚合带宽200GB/s Bi-direction' on the card page cannot be read as '200 GB/s total, both directions' without contradicting Cambricon's own 3.1x claim. The safe reading: 200 GB/s is a per-direction-scale figure and the MLU-Link fabric is genuinely strong, but the exact direction convention is ambiguous in the vendor's own text. LEFT UNRESOLVED rather than silently picked - the interconnect field carries only the generation, which is unambiguous ('x16 PCIe Gen4' on the same spec table), so no numeric field in this record needed changing and nothing downstream is silently halved., which the vendor states is 3.1x PCIe 4.0 bandwidth and which is a genuinely strong scale-up path relative to the card's own 614 GB/s of memory - better ratio than any GPU of the period, and the same 200 GB/s the vendor claims per chip at die level. Vendor's own measured claim (with methodology given, which is rare): on four common AI models, single-card MLU370-X8 performance is comparable to a 350 W RTX GPU, with better parallel scaling at 8 cards, tested on NF5468M5 / Xeon Gold 5218 at 2.30 GHz with MLU370 SDK 1.2.0. Full-height full-length dual-slot, 250 W, passive. Precisions supported: FP32/FP16/BF16/INT16/INT8/INT4, but as with the sibling record the INT4 row above reuses the INT16 figure and must not be read as an INT4 measurement. Software is NeuWare plus the MagicMind MLIR inference engine. 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.

Cross-references

Interconnect (2)