一个GitHub仓库最近被翻出来讨论:作者在单张AMD MI300X上跑通了一个304B参数的模型,单流解码中位168.6 tok/s,调优后预填充冲到7.9–8.5K tok/s,64路并发突发聚合830 tok/s不炸显存,权重占用156.67 GiB,不量化不offload整模型塞进显卡。文档写得极专业:SHA256校验、AITER调优表、逐条补丁diff,像一份内部运维手册。
问题是,这个叫DeepSeek-V4-Flash-0731的模型,查遍DeepSeek官方渠道,找不到它存在的证据。
这些数字是什么
先把仓库摆出来的核心数字看一眼,这是它给自己贴的成绩单。
这些数字不是随手写的。文档把MI300X用的FP8 fnuz变体和MI325X起用的OCP标准FP8区分得很清楚——两者混用会在scale上差出一倍,这是社区之前已经踩过的坑。它还列出了九项补丁,每一条都对应具体的上游issue号,比如vLLM的#47282和未合并的PR #47291。工程投入这部分,看起来是真的。
但那个模型,没人见过
MI300X本身没问题,192GB HBM3、5.3TB/s带宽,是AMD官方公开的规格,比H100 SXM5多2.4倍显存容量,这也是AMD对抗Nvidia叙事时最拿得出手的一张牌。真正让人卡住的是模型本身。
DeepSeek目前公开发布过的旗舰是V3/R1系列,671B总参数、37B激活参数,128K上下文,用DeepSeekMoE加MLA加MTP架构。这份报告说的"V4-Flash-0731"是304B参数、架构上声称支持1M上下文,跟已知谱系完全对不上——DeepSeek官方渠道没有这个checkpoint的model card,也没有对应的发布记录。
数字本身也有点拧巴。304B参数,哪怕全用FP8存,权重体量按理该逼近300GB量级,可文档说的是"156.67 GiB就装完全模型,不量化不offload"。如果这是标准稠密模型,这两个数字凑不到一起;如果它是稀疏MoE结构,激活参数可能远低于304B,但仓库没交代清楚这层区别,读者也就没法核实。
- 风险.如果把这套基准数字当成DeepSeek或AMD官方性能指标转发,等于把一份未经验证的第三方claim当成了行业标准来用。
为什么这种帖子容易被当真
AMD现在最缺的就是一个打得响的单卡大模型案例。H100显存有限,跑大模型经常得多卡分摊,MI300X理论上一张卡能装下更大的模型,这个叙事缺口太明显,任何一份"单卡跑通300B级模型"的详细报告都容易被顺手转发,不管模型本身经不经得起查。ROCm生态这几年也一直靠社区补丁拼可用性,这次的仓库作者不是AMD官方也不是DeepSeek官方,只是个人开发者,一个fork、十几个star,却写出了和官方发布同等细致的文档格式——这种格式上的权威感,恰恰是判断力最容易松懈的地方。古人说"名不正则言不顺",模型的名分立不住,后面一整套基准数字就都悬着。
眼下能做的核实很简单:去看DeepSeek官方仓库或Hugging Face有没有对应的checkpoint更新记录,看是否有第三方能独立复现这份基准。查不到,这份报告就只能算社区自制或误传的产物,不该被当成MI300X真实能力的证据,更不该进企业采购决策者的选型参考表。工程细节的可信度,从来替代不了源头的可信度。