Moore Threads MTT S5000 product page - the ONLY three TFLOPS figures on it are footnoted COMPETITOR baselines; the S5000's own compute, memory and power are never printed

VERBATIM 2026-10-05 via web_extract of BOTH language versions. Recorded because data/accelerators/moore-threads-s5000 carried a single flops row (fp8 989, basis vendor-spec-sheet, vendor_claim false) on the strength of this page, and that row does not describe this card. THE FOOTNOTE, VERBATIM (identical on https://www.mthreads.com/product/S5000 and https://en.mthreads.com/product/S5000): '① 参考基准 1：稠密 FP16 算力 989 TFLOPS，显存带宽 3.35TB/s；② 参考基准 2：稠密 FP16 算力 148 TFLOPS，显存带宽 4.0TB/s；③ 参考基准 3：稠密 FP16 算力 312 TFLOPS，显存带宽 2.0TB/s。' English: 'Baseline 1: Dense FP16 compute 989 TFLOPs, memory bandwidth 3.35 TB/s; Baseline 2: Dense FP16 compute 148 TFLOPs, memory bandwidth 4.0 TB/s; Baseline 3: Dense FP16 compute 312 TFLOPs, memory bandwidth 2.0 TB/s.' FOUR DEFECTS IN THE STORED ROW, THREE OF THEM SERIOUS: (a) WRONG PRECISION. The stored row is precision 'fp8', tflops 989. The footnote says 989 is a DENSE FP16 figure. Nothing on the page attributes 989 to FP8, or to any S5000 precision. The row misstates both the precision and the provenance. (b) WRONG BASIS. basis was 'vendor-spec-sheet' on a row that transcribes no S5000 specification at all. basis_detail even conceded 'Second-hand figure, not a first-party spec' while keeping the vendor basis, which is the documented way a record ends up looking sourced when it is not. (c) vendor_claim false was CORRECT and is preserved - but it was the only thing standing between this row and a false vendor claim, and it is not sufficient on its own. (d) The other two baselines (148 TFLOPS at 4.0 TB/s, 312 TFLOPS at 2.0 TB/s) were recorded in the record's memory_bandwidth_basis as if they were calibration data about Moore Threads' marketing; they are unnamed COMPETITOR parts. 148 TFLOPS dense FP16 at 4.0 TB/s is the H20 profile and 312/2.0 TB/s is an A100-class profile. Storing them in a card's bandwidth field is how a competitor's spec becomes indistinguishable from the subject's. THE S5000'S OWN FIGURES, VERBATIM - what the page does print, none of it a compute number: '基于“平湖”架构' / '核心搭载了摩尔线程全新一代 PH100 芯片' - PH100 chip, Pinghu architecture. '提供从 FP8 到 FP64 的全精度算力支持' - full-precision compute support from FP8 to FP64. A precision RANGE, no number. '训练性能提升超 30%' - training performance improved by over 30% (vs the unnamed international flagship). '在 16k 长序列输入测试中，MTT S5000 单卡 Prefill 吞吐量是国际旗舰产品② 的 2.5 倍' - single-card prefill throughput 2.5x Baseline 2. '≥4000 Tokens/s 单卡 Prefill 吞吐, ISL 为 4K，mean TTFT<=4s；MTP on；方案为 PD 分离推理，基于 2P4D 的集群配置方案，硬件为 6 台 S5000 8 卡服务器，软件为硅基流动的高性能推理引擎和摩尔线程底层软件栈，测试基于原生 FP8 计算精度，测试条件和高负载生产环境保持一致。' '≥1000 Tokens/s 单卡 Decode 吞吐, ISL/OSL 为 1K/2K；mean TPOT<=100ms；MTP on' - same configuration. 'Llama3-70B 训练：模型算力利用率 (MFU) 突破 60%；DeepSeek-236B 训练：MFU 超过 40%'; 16k-step DeepSeek-236B loss-curve relative error vs Baseline 1 of 0.6%; 10k-card training success rate up over 30%; '单机性能达到国际旗舰产品① 的 64%-79%'. '在 2 节点 16 卡配置下，MTT S5000 实现了高达 61.83 samples/s 的训练吞吐量，模型算力利用率（MFU）达到 51%' (Wan2.1 video generation, FSDP2). '160 路 1080P30 视频解码' and '40 路 4K30' decode. NEGATIVE FINDING, CONFIRMED TWICE BY INDEPENDENT METHODS (both language versions of the same page, extracted separately): the page publishes NO absolute TFLOPS figure for the S5000, NO TOPS figure, NO memory capacity, NO memory type, NO memory bandwidth, NO bus width and NO TDP. A third check on the driver's own introduction page (https://docs.mthreads.com/driver-linux-server/driver-linux-server-doc-online/MTT_S5000/introduction/) likewise prints only positioning prose - 'MTT S5000 是面向生成式 AI 训练、推理和高性能计算的训推一体全功能 GPU 智算卡，基于第四代 MUSA 全栈平台，核心搭载 PH100 芯片' plus four bullet features, with no specification table of any kind. So an EMPTY flops array is the correct state for this record, and the honest headline is that this vendor publishes a full methodology for throughput (ISL/OSL, TTFT, TPOT, MTP on/off, PD-disaggregated 2P4D across 6 x 8-card servers, named third-party inference engine, native FP8) while declining to publish the peak number that throughput would be divided by to get an efficiency.