inference/research
verifiedhigh · 0.85updated 2026-10-08

Cambricon MLU370 (Siyuan 370) AIDC accelerators

cambricon mluarch03 2021

Fields

id
accelerators/cambricon-mlu370
Vendor
cambricon
Architecture
mluarch03
Release year
2021
Process (nm)
7
Form factors
pcie
VRAM (GB)
48
Memory type
lpddr5
Memory bandwidth (GB/s)
307.2
Bandwidth basis
Vendor-published for the S4/S8 card: 307.2 GB/s on LPDDR5. Cambricon states memory bandwidth is 3x the previous generation and 1.5x the energy efficiency of GDDR6, but gives no bus width or pin speed, so the figure cannot be re-derived.
Peak FLOPS
precisionint8tflops192denseyesvendor_claimyessource_idasic-cambricon-mlu370-s4basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own int8 for Cambricon MLU370 (Siyuan 370) AIDC accelerators (source of record: 'Cambricon AIDC MLU370-S4/S8 product page', kind: spec-sheet). Recorded dense:true as printed.precisionint4tflops192denseyesvendor_claimnosource_idasic-cambricon-mlu370-s4basisvendor-spec-sheetbasis_detailSecond-hand figure, not a first-party spec: the source of record is 'Cambricon AIDC MLU370-S4/S8 product page' (kind: spec-sheet). Recorded dense:true as printed.precisionfp16tflops72denseyesvendor_claimyessource_idasic-cambricon-mlu370-s4basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own fp16 for Cambricon MLU370 (Siyuan 370) AIDC accelerators (source of record: 'Cambricon AIDC MLU370-S4/S8 product page', kind: spec-sheet). Recorded dense:true as printed.precisionbf16tflops72denseyesvendor_claimyessource_idasic-cambricon-mlu370-s4basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own bf16 for Cambricon MLU370 (Siyuan 370) AIDC accelerators (source of record: 'Cambricon AIDC MLU370-S4/S8 product page', kind: spec-sheet). Recorded dense:true as printed.precisionfp32tflops18denseyesvendor_claimyessource_idasic-cambricon-mlu370-s4basisvendor-spec-sheetbasis_detailTranscribed from the vendor's own fp32 for Cambricon MLU370 (Siyuan 370) AIDC accelerators (source of record: 'Cambricon AIDC MLU370-S4/S8 product page', kind: spec-sheet). Recorded dense:true as printed.
TDP (W)
75
Unified memory
no
Consumer part
no
notes
THE HIERARCHY POINT, and the reason this part is in a memory-bound inference study at all: MLU370 is LPDDR5 with NO HBM. At 48 GB and 307.2 GB/s the arithmetic intensity ceiling is 234 FLOP/byte even at INT8, which is roughly a third of what a same-generation HBM GPU offers. So the roofline for this part sits far left of every other record here: weight streaming dominates, the usable batch size for large models is small, and the part is realistically a high-density inference card (S4 is half-height, half-length, single-slot, 75 W passive, designed for maximum cards per server) rather than a large-model serving part. The die-level 256 TOPS INT8 quoted by the chip overview is a die figure for the 2-chiplet configuration and is 2x the S4/S8 card number, so card and die figures must not be compared. Variants: S4/S8 are inference-oriented (192 TOPS INT8 card); X4 and X8 are dual-die train+infer parts using MLU-Link. The INT4 row is flagged vendor_claim false: the vendor lists INT4 as a supported precision but publishes no separate INT4 throughput, so the 192 TOPS INT8 figure is carried over as an upper bound and must not be read as an INT4 measurement. MLU-Link provides 200 GB/s of chip-to-chip bandwidth per chip - respectable relative to its HBM-less position, and the ratio of scale-up to local bandwidth is inverted versus GPUs. Software is NeuWare plus the MagicMind MLIR-based inference engine, integrated with PyTorch and TensorFlow. 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, and the reason this part is in a memory-bound inference study at all: MLU370 is LPDDR5 with NO HBM. At 48 GB and 307.2 GB/s the arithmetic intensity ceiling is 234 FLOP/byte even at INT8, which is roughly a third of what a same-generation HBM GPU offers. So the roofline for this part sits far left of every other record here: weight streaming dominates, the usable batch size for large models is small, and the part is realistically a high-density inference card (S4 is half-height, half-length, single-slot, 75 W passive, designed for maximum cards per server) rather than a large-model serving part. The die-level 256 TOPS INT8 quoted by the chip overview is a die figure for the 2-chiplet configuration and is 2x the S4/S8 card number, so card and die figures must not be compared. Variants: S4/S8 are inference-oriented (192 TOPS INT8 card); X4 and X8 are dual-die train+infer parts using MLU-Link. The INT4 row is flagged vendor_claim false: the vendor lists INT4 as a supported precision but publishes no separate INT4 throughput, so the 192 TOPS INT8 figure is carried over as an upper bound and must not be read as an INT4 measurement. MLU-Link provides 200 GB/s of chip-to-chip bandwidth per chip - respectable relative to its HBM-less position, and the ratio of scale-up to local bandwidth is inverted versus GPUs. Software is NeuWare plus the MagicMind MLIR-based inference engine, integrated with PyTorch and TensorFlow. 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