inference/research
draftlow · 0.60updated 2026-10-05

Moore Threads MTT S5000 (PH100, Pinghu architecture)

asic-other MUSA (4th gen) / Pinghu 2026
This record is a draft. Not yet verified. Provisional. Treat every number on this page as provisional.

Fields

id
accelerators/moore-threads-s5000
Vendor
asic-other
Architecture
MUSA (4th gen) / Pinghu
Release year
2026
Form factors
oam
Bandwidth basis
None recorded, and this is a verified absence rather than a reading failure: TWO INDEPENDENT READS of the vendor product page (the Chinese https://www.mthreads.com/product/S5000 and the English https://en.mthreads.com/product/S5000, extracted separately) publish no memory capacity, no memory type, no bandwidth, no bus width and no TDP, and a third read of the driver's own introduction page on docs.mthreads.com is equally silent on specifications. THE THREE TFLOPS FIGURES ON THE PAGE ARE NOT THIS CARD'S AND HAVE NOW BEEN REMOVED FROM THIS RECORD'S FIELDS. They are footnoted COMPETITOR baselines, verbatim: '① 参考基准 1：稠密 FP16 算力 989 TFLOPS，显存带宽 3.35TB/s；② 参考基准 2：稠密 FP16 算力 148 TFLOPS，显存带宽 4.0TB/s；③ 参考基准 3：稠密 FP16 算力 312 TFLOPS，显存带宽 2.0TB/s' (/ 'Baseline 1: Dense FP16 compute 989 TFLOPs, memory bandwidth 3.35 TB/s; ... 2: 148 TFLOPs, 4.0 TB/s; ... 3: 312 TFLOPs, 2.0 TB/s'). Source w5a-mthreads-s5000-page-989-is-competitor-baseline-not-this-card.
Unified memory
no
Consumer part
no
notes
CORRECTION 2026-10-05: THE SINGLE flops ROW WAS DELETED. It read fp8 989 TFLOPS, basis 'vendor-spec-sheet', vendor_claim false, and it did not describe this card. Three separate defects, any one of which would justify removal: (1) WRONG PRECISION - the row said fp8, but the page attributes 989 to a DENSE FP16 competitor baseline; nothing on the page ties 989 to FP8 or to any S5000 precision. (2) WRONG BASIS - 'vendor-spec-sheet' on a row that transcribes no S5000 specification at all; its own basis_detail conceded 'Second-hand figure, not a first-party spec' while keeping the vendor basis, which is precisely how a record ends up looking sourced when it is not. (3) IT COMPETED WITH THE HONEST NEGATIVE - vendor_claim false is the correct flag but is not sufficient on its own, because a row in flops[] is a claim that the figure describes the part, and here it does not. THE OTHER TWO BASELINES WERE ALSO REMOVED FROM memory_bandwidth_basis, where they had been recorded as 'the best available calibration of what flagship means in Moore Threads marketing'. They are unnamed COMPETITOR parts: 148 TFLOPS dense FP16 at 4.0 TB/s is the H20 profile, 312 TFLOPS at 2.0 TB/s an A100-class profile, 989 at 3.35 TB/s the B200 profile. Storing a competitor's spec in a field of this card is how the two become indistinguishable to a later reader. flops IS NOW EMPTY AND THAT IS CORRECT, confirmed by two independent methods (both language versions of the product page) plus a third (the driver-doc introduction page). WHAT THE VENDOR DOES PUBLISH IS THROUGHPUT UNDER FULL METHODOLOGY, which is more useful for a serving study than a TFLOPS number: >=4000 tok/s per-card prefill at ISL 4K with mean TTFT <=4 s, MTP on, native FP8; >=1000 tok/s per-card decode at ISL/OSL 1K/2K with mean TPOT <=100 ms, MTP on, native FP8 - both from a PD-disaggregated 2P4D configuration across 6 x 8-card S5000 servers using SiliconFlow's third-party high-performance inference engine plus Moore Threads' stack, under production-like load. The observation worth keeping is that this vendor publishes every input needed to compute an efficiency (ISL/OSL, TTFT, TPOT, MTP on/off, topology, engine, precision) while declining to publish the peak number you would divide by to get one. Other vendor figures, all relative and all against the unnamed 'international flagship': training performance up over 30% from the native FP8 engine; single-card prefill 2.5x the flagship at 16k sequence length; Llama3-70B MFU above 60% and DeepSeek-236B MFU above 40%; loss-curve relative error of 0.6% versus the flagship over the first 30,000 steps of a 10,000-card DeepSeek-236B run; 10k-card training success rate up over 30%; single-node performance at 64%-79% of the flagship; and 61.83 samples/s at 51% MFU training Wan2.1 video generation on 2 nodes x 16 cards under FSDP2. Decode capability 160x 1080P30 or 40x 4K30. PRECISION STORY: the Pinghu engine brings NATIVE FP8 with a 24-bit accumulation mantissa against the flagship's 14-bit, in E4M3 and E5M2 with multiple scaling modes, plus hardware W4A16 and W8A16 weight dequantization; the card also claims native FP64, making it one of the few parts in this repo with a first-party FP64 story at all, and it markets that for science computing (1.7x the flagship in SPONGE, 8.1x in DSDP docking). SOFTWARE: fourth-generation MUSA natively targets PyTorch, Megatron-LM, vLLM and SGLang, with MUSIFY claiming to cut weeks of adaptation to hours. Form factor OAM, air-cooled and liquid-cooled, on the MGX 8-GPU platform and the SGX5000 server. Do not compare this FP8/FP64 story to the Ascend 950DT's: 950DT has a 3.7x FP16-to-FP4 spread while Pinghu's headline is FP8 with a wide accumulator, which is a different bet. PROCESS NODE AND TDP REMAIN NULL - the vendor publishes neither. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-05). No Moore Threads document located publishes a memory-bus width for the S5000 - not the product page in either language, not the driver-doc introduction page, and there is no S5000 equivalent of the S4000 doc-centre spec table that would carry 显存位宽. 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 inference is wrong the record looks populated while being wrong. Worth contrasting with the S4000, where the vendor DOES publish 384 bits and 16 Gbps and the record can therefore state a re-derivable width instead of a null: the absence here is the vendor's, and it is a different fact from the absence there, which was ours.

Notes

CORRECTION 2026-10-05: THE SINGLE flops ROW WAS DELETED. It read fp8 989 TFLOPS, basis 'vendor-spec-sheet', vendor_claim false, and it did not describe this card. Three separate defects, any one of which would justify removal: (1) WRONG PRECISION - the row said fp8, but the page attributes 989 to a DENSE FP16 competitor baseline; nothing on the page ties 989 to FP8 or to any S5000 precision. (2) WRONG BASIS - 'vendor-spec-sheet' on a row that transcribes no S5000 specification at all; its own basis_detail conceded 'Second-hand figure, not a first-party spec' while keeping the vendor basis, which is precisely how a record ends up looking sourced when it is not. (3) IT COMPETED WITH THE HONEST NEGATIVE - vendor_claim false is the correct flag but is not sufficient on its own, because a row in flops[] is a claim that the figure describes the part, and here it does not. THE OTHER TWO BASELINES WERE ALSO REMOVED FROM memory_bandwidth_basis, where they had been recorded as 'the best available calibration of what flagship means in Moore Threads marketing'. They are unnamed COMPETITOR parts: 148 TFLOPS dense FP16 at 4.0 TB/s is the H20 profile, 312 TFLOPS at 2.0 TB/s an A100-class profile, 989 at 3.35 TB/s the B200 profile. Storing a competitor's spec in a field of this card is how the two become indistinguishable to a later reader. flops IS NOW EMPTY AND THAT IS CORRECT, confirmed by two independent methods (both language versions of the product page) plus a third (the driver-doc introduction page). WHAT THE VENDOR DOES PUBLISH IS THROUGHPUT UNDER FULL METHODOLOGY, which is more useful for a serving study than a TFLOPS number: >=4000 tok/s per-card prefill at ISL 4K with mean TTFT <=4 s, MTP on, native FP8; >=1000 tok/s per-card decode at ISL/OSL 1K/2K with mean TPOT <=100 ms, MTP on, native FP8 - both from a PD-disaggregated 2P4D configuration across 6 x 8-card S5000 servers using SiliconFlow's third-party high-performance inference engine plus Moore Threads' stack, under production-like load. The observation worth keeping is that this vendor publishes every input needed to compute an efficiency (ISL/OSL, TTFT, TPOT, MTP on/off, topology, engine, precision) while declining to publish the peak number you would divide by to get one. Other vendor figures, all relative and all against the unnamed 'international flagship': training performance up over 30% from the native FP8 engine; single-card prefill 2.5x the flagship at 16k sequence length; Llama3-70B MFU above 60% and DeepSeek-236B MFU above 40%; loss-curve relative error of 0.6% versus the flagship over the first 30,000 steps of a 10,000-card DeepSeek-236B run; 10k-card training success rate up over 30%; single-node performance at 64%-79% of the flagship; and 61.83 samples/s at 51% MFU training Wan2.1 video generation on 2 nodes x 16 cards under FSDP2. Decode capability 160x 1080P30 or 40x 4K30. PRECISION STORY: the Pinghu engine brings NATIVE FP8 with a 24-bit accumulation mantissa against the flagship's 14-bit, in E4M3 and E5M2 with multiple scaling modes, plus hardware W4A16 and W8A16 weight dequantization; the card also claims native FP64, making it one of the few parts in this repo with a first-party FP64 story at all, and it markets that for science computing (1.7x the flagship in SPONGE, 8.1x in DSDP docking). SOFTWARE: fourth-generation MUSA natively targets PyTorch, Megatron-LM, vLLM and SGLang, with MUSIFY claiming to cut weeks of adaptation to hours. Form factor OAM, air-cooled and liquid-cooled, on the MGX 8-GPU platform and the SGX5000 server. Do not compare this FP8/FP64 story to the Ascend 950DT's: 950DT has a 3.7x FP16-to-FP4 spread while Pinghu's headline is FP8 with a wide accumulator, which is a different bet. PROCESS NODE AND TDP REMAIN NULL - the vendor publishes neither. MEMORY_BUS_WIDTH: STILL NULL, AND HERE IS PRECISELY WHAT WAS LOOKED FOR (2026-10-05). No Moore Threads document located publishes a memory-bus width for the S5000 - not the product page in either language, not the driver-doc introduction page, and there is no S5000 equivalent of the S4000 doc-centre spec table that would carry 显存位宽. 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 inference is wrong the record looks populated while being wrong. Worth contrasting with the S4000, where the vendor DOES publish 384 bits and 16 Gbps and the record can therefore state a re-derivable width instead of a null: the absence here is the vendor's, and it is a different fact from the absence there, which was ours.

Cross-references

Interconnect (2)