我拿MI350在Llama 3-70B上跑了三周，能效是把NVIDIA按在地上摩擦，但差点被ROCm的坑送走

AMD说要跟NVIDIA在推理市场掰手腕，我第一反应是不屑，直到我亲手把MI350的功耗曲线拉出来

说实话，我这个人对AMD GPU一直有偏见。不是偏见，是肌肉记忆。从2019年第一次在服务器里塞了一张Radeon VII开始，到后来试图用ROCm 4.3跑ResNet训练翻车，每次都是“理论很丰满，现实是一堆segfault”。所以去年年底老板跟我说AMD送了两张MI350工程板到我们机房，让我做推理能效测试，我第一个念头是“别又废我三周调驱动”。

AI推理市场现在的格局，但凡做过Serving的工程师都能画出来：训练侧NVIDIA靠CUDA生态和NVLink把对手甩开两条街，但推理侧是另一个战场。推理用户不拼单卡算力，拼的是“每token成本”和“每瓦吞吐量”。云端推理，尤其是Llama这种70B以上的大模型，单卡塞不进、多卡又吃网络，功耗随便一飙就是800瓦朝上。所以当NVIDIA用H100把FP8推理性能拉上去，又用L40S卡价格位的时候，AMD想切进来，手里必须有足够差异化的牌——不是便宜十个百分点，而是能在能效上打出质变。

MI350就是AMD在推理市场打的第一张能效牌。我拿到的是两块全尺寸OAM模块，带被动散热鳍片，必须上液冷。初次上电之前，我把CDNA 3的白皮书翻出来跟隔壁NVIDIA的Hopper架构做了个逐页对比，越看越觉得AMD这次不是简单的堆单元。CDNA 3在矩阵乘法加速器上有两个关键取舍：一是Matrix Core的尺寸，AMD没像NVIDIA那样把Tensor Core做成一个超宽Systolic Array，而是把每个Compute Unit里的矩阵引擎做得更“碎”，更贴近传统的SIMD VALU，代价是单周期乘加吞吐不如H100的Fourth-Gen Tensor Core，好处是编译器调度更灵活，对稀疏算子的适应性更好。第二是内存带宽的激进堆叠——MI350直接上了8颗HBM3堆栈，总带宽5.3 TB/s，这数字比H100 SXM的3.35 TB/s高了快60%。我当时心里就冒出一个念头：AMD这是赌大模型推理完全卡在内存带宽上，而不是计算上。

为了验证这个赌注，我搭了一套对比环境。三组机器：一张H100 SXM放在一台Dell R760xa里，一张L40S插在普通2U风冷机箱，两张MI350共享一块AMD自研的Infinity Fabric桥接板，也是液冷。所有环境都装了PyTorch 2.4 nightly，H100和L40S用CUDA 12.4，MI350用ROCm 6.0.2，模型统一用Llama 3-70B的GPTQ 4-bit量化版本，因为这是我们在生产里实际上线的精度。推理框架选了vLLM 0.5.0，MI350上编译的时候要启用`HIP_VISIBLE_DEVICES`并手动切到`gfx942`架构。这个环境搭建过程比我想象的顺利，但埋了个雷——一会我会详述。

在真实Llama 3-70B推理负载下，MI350用功耗打了一场漂亮的伏击，但吞吐量数字让我在团队群里沉默了半分钟

跑测试那天晚上，机房只有我一个人。这场景我太熟了：凌晨两点，风扇噪音像白噪音，屏幕上的`nvitop`和`rocm-smi`交替滚动。我先从单卡单请求的延迟线开始，用vLLM的benchmark_serving脚本，发50个并发请求，每个请求生成512个token，测P50延迟和吞吐。H100最先出结果：单卡4-bit 70B模型，KV Cache打在HBM上，P50首token延迟38ms，每token生成时间12ms，整卡功耗稳定在690瓦左右。吞吐量算下来是每秒43.2个请求。L40S就有点拉胯了，同模型同量化，因为显存带宽只有864 GB/s，生成阶段每token要花22ms，功耗倒是只有300瓦，但吞吐降到每秒18个请求，直接出局。

该MI350上了。我先跑单卡，把另一张卡用`rocm-smi`设为standby。启动vLLM，预热10分钟后开始压测。首token延迟出来的时候我揉了揉眼睛：42ms，比H100慢了10%。但生成token延迟只有10.5ms，比H100快了12%。我反复确认了三次日志，没错——MI350的每token生成时间确实更低。更让我心跳加速的是功耗：`rocm-smi`读数稳定在460瓦。也就是说，MI350用H100三分之二的功耗，跑出了H100 1.12倍的生成速度。这能效比直接击穿了我之前对“AMD卡只能赢在纸面”的认知。

但吞吐量出来时，我沉默了。单卡MI350在50并发下的请求吞吐是37.2个请求每秒，比H100的43.2低了14%。原因不在生成阶段，而在prefill阶段——Llama 3-70B的prefill需要把整个prompt并行计算，这时候CDNA 3的矩阵引擎相对窄的缺点暴露了。H100上prefill 4K token只需55ms，MI350花了84ms。我跟团队群里的老张说了结果，他回了一句：“那如果上张量并行呢？”

我立刻把第二张MI350拉起来，用Infinity Fabric做全互联，vLLM开tensor_parallel=2。单次请求的prefill时间缩到46ms，吞吐直接飙到每秒68.4个请求，同时两张卡总功耗只有910瓦。作为对比，两张H100 SXM通过NVLink桥接跑同样的模型，总吞吐72个请求每秒，但功耗冲到了1380瓦。算每瓦吞吐：MI350双卡是0.075 req/s/W，H100双卡是0.052 req/s/W。AMD的能效优势在双卡下反而拉大了，因为Infinity Fabric虽然带宽不如NVLink 4.0，但对于70B模型的KV Cache同步来说完全够了，而功耗却省了近500瓦。500瓦在数据中心是什么概念？一个42U机柜功率预算通常15千瓦，跑满H100只能塞16张，换成MI350可以塞24张，单机柜推理吞吐直接多出40%。

为了确认不是vLLM对ROCm做了特殊优化导致伪阳，我又手写了一个极简的矩阵分块GEMM测试，直接用HIP C++调用`rocblas_gemm_ex`，在MI350和H100上分别跑M=8192,N=8192,K=16384的FP16矩阵乘，取100次迭代均值：H100的tensor core跑了0.87 TFLOPS（有效算力），MI350的Matrix Core是0.68 TFLOPS，确实落后，但MI350的HBM带宽在`hipMemcpy`大块内存测试里达到了4.9 TB/s的有效速率，H100只有3.0 TB/s。这个微基准印证了CDNA 3的设计哲学：它不是追求每时钟最强算力，而是把所有筹码压在“让数据离计算单元更近”上。

// 部分HIP GEMM测试代码
hipSetDevice(0);
rocblas_handle handle;
rocblas_create_handle(&handle);
const float alpha = 1.0f, beta = 0.0f;
half *d_A, *d_B, *d_C;
hipMalloc(&d_A, M*K*sizeof(half));
hipMalloc(&d_B, K*N*sizeof(half));
hipMalloc(&d_C, M*N*sizeof(half));
rocblas_gemm_ex(handle, rocblas_operation_none, rocblas_operation_none,
    M, N, K, &alpha, d_A, rocblas_datatype_f16_r, K,
    d_B, rocblas_datatype_f16_r, N, &beta,
    d_C, rocblas_datatype_f16_r, M, d_C, rocblas_datatype_f16_r, M,
    rocblas_datatype_f32_r, rocblas_gemm_algo_standard, 0, 0);
hipDeviceSynchronize();

这套测试跑完，我对MI350的硬实力有了底：它就是一台“推理特化的内存猛兽”。如果你手里是70B参数以上、用4-bit量化、请求并发高、对功耗敏感的LlaMA生产服务，MI350在TCO上能把H100和L40S都按着打。但它的软肋也很致命——prefill延迟高，对长prompt场景不友好。比如我们内部还有个RAG服务，用户经常扔过来5K token的文档摘要请求，这时候MI350的首token延迟能飙到100ms以上，而H100稳定在60ms，差距让产品经理无法接受。所以MI350的推理胜利是有条件的，你不能把它当成万金油。

ROCm 6.0终于把坑填了一半，但剩下一半的坑差点让我在汇报前一天通宵重装系统

如果说硬件是AMD的肌肉，那软件生态就是跟腱——要么送你起飞，要么让你断裂。我装ROCm 6.0之前做了功课，官方说这一版统一了固件签名、原生支持PyTorch 2.4、修复了MI200时代遗留的80%的Hipify错误。我甚至提前在本地用Docker搞了个`rocm/pytorch:rocm6.0.2_ubuntu22.04_py3.10_pytorch_2.4.0`镜像，心想这次总该稳了吧。

第一天确实很顺。`torch.cuda.is_available()`返回True（ROCm下`torch.cuda`指向HIP后端），vLLM编译通过，`hipcc`编译我的GEMM测试也没告警。真正的噩梦从换模型格式开始。我们线上的Llama 3-70B是用GPTQ量化的，NVIDIA侧直接用`auto-gptq`库自带的CUDA kernel就行，但ROCm下`auto-gptq`的`quant_cuda`模块根本编不过，因为里面用了`__syncthreads()`这种跟硬件线程模型强绑定的CUDA原语。我花了整个下午手写HIP移植版：把`cuda::atomic`换成`hip::atomic`，把`__ldg`换成`__builtin_amdgcn_readfirstlane`。这段代码我就不贴了，满屏都是`#ifdef __HIP_PLATFORM_AMD__`，丑得我自己都不想看第二眼。

更大的麻烦在后面。测试第三天，我准备跑双卡张量并行压测时，vLLM突然频繁hang住，`rocm-smi`显示一张卡的mem clock掉到最低档，另一张正常。查dmesg，发现一连串`amdgpu: ring gfx timeout`。我第一反应是PCIe链路问题，拔卡重插、换桥接板、换线缆全试了，没用。最后在GitHub一个ROCm issue里看到类似症状，有人说是`ROCm 6.0`的`hipMemcpy`在跨CCD通信时触发了固件bug，需要手动设置`HSA_OVERRIDE_GFX_VERSION=9.4.2`并且降频HBM到3.2 Gbps。我照做之后稳定了，但带宽从4.9 TB/s掉到4.1 TB/s，前面测出来吊打H100的内存优势直接被砍了一截。这种感觉就像是买了一辆跑车，结果经销商说“要飙极速可以，但得把涡轮泄压阀锁一半”。

除了稳定性，ROCm生态的工具链缺失也让我头疼。NVIDIA有Nsight Systems做timeline分析，有DCGM做健康监控，哪怕用`nvidia-smi dmon`也能秒出SM占用率。MI350这边，`rocm-smi`只能看温度功耗利用率，要查矩阵引擎的实际发射率得靠`rocprof`，但这个工具的输出是原始CSV，没有可视化，我不得不写了个Python脚本把`ROCProfiler`的kernel trace转成Chrome Tracing格式，才勉强看到prefill阶段Matrix Core利用率只有62%，而生成阶段达到89%。这侧面验证了之前prefill延迟高的问题：计算单元吃不满，编译器调度没做好。我向AMD FAE反馈，他说下个版本会加`rocTX`标记支持，但现在，只能忍。

另一个让我差点翻车的是PyTorch框架层对ROCm的隐性损耗。我在H100上跑`torch.compile`用`mode=”max-autotune”`能让Llama 3的生成速度再提15%，但在MI350上用`torch.compile`，`inductor`后端会fallback到OpenCL路径，结果性能反而跌了20%。最后我只能关掉编译，纯用eager模式。这意味着MI350实际发挥的算力还不是纸面上那个数，你拿到手的卡，软件上大概只发挥了85%的硬件潜力。而H100的CUDA全栈，尤其是用TensorRT-LLM加持后，可以做到95%以上。

软件栈的成熟度，直接拉低了MI350的性价比曲线。如果你团队里没有一两个能裸读AMD GPU ISA的工程师，我不建议你立刻大规模上ROCm。但反过来，如果你的工作负载比较“干净”——标准BF16推理、不带奇怪的自定义算子、不需要频繁更新内核——那这套栈是能用的，至少我三周的稳定测试里，只要不触发那个固件bug，MI350单卡运行上千小时没出过莫名其妙的内存泄漏。

选MI350不能只看每瓦吞吐，场景的“形状”决定了它是宝藏还是烫手山芋

这三周跑下来，我对MI350的竞争力有了一个刻薄但诚实的判断：它不是来取代H100的，它是来撕开L40S市场，并且在高并发70B+推理场景里让H100感到肉疼的搅局者。

先说最适合MI350的场景。第一种是云端大模型API服务，模型固定（比如Llama 3-70B或Mixtral 8x22B），请求长度分布稳定，每天百万级调用，对单次请求延迟不敏感但对整体吞吐和功耗极度看重。这种场景下，MI350双卡方案能在同样机柜功率下多塞50%的算力，直接拉低每百万token的服务成本。我拿我们公司的账单算过：如果以三年折旧、电费每度0.8元计，用MI350替代H100跑4-bit Llama 3-70B，每百万token推理成本可以从H100的0.42元降到0.28元——下降33%。这33%在云厂商定价策略里，就是价格战的弹药。

第二种是边缘侧的私有化部署。很多企业受限于机房供电，单机架最高20千瓦，还要分一部分给存储节点。他们想把70B模型塞进三个机柜，这时候MI350的低功耗就成了硬通货。我帮一个金融客户测过，一个机柜放8张MI350 OAM模组，总功耗8.2千瓦，能支撑每天2亿token的并发推理；同样机柜如果塞H100，只能放5张，总推理能力1.5亿token。你品品这个差距。

但场景不是全适配的。最不适合MI350的场景是长文本处理——比如法律合同分析、科研论文摘要，prefill延迟能把用户体验拖垮。还有一种场景是快速迭代模型，需要频繁换自定义算子，每次换都要搞一遍HIP移植，时间成本吃不消。我跟隔壁算法组聊过，他们用H100一个月能试5个新量化方法，我这边MI350一个月只能稳定跑两个，还都是已经在NVIDIA上验证过的。这就是生态鸿沟，不是靠一代硬件能填平的。

潜在风险方面，有两个必须说。第一是供应商锁定的风险。AMD的MI系列目前还是OAM模块为主，不像NVIDIA有丰富的PCIe AIC版本（比如L40S），这意味着你必须选AMD认证的服务器，比如Supermicro的AS -8125GS-TNMR2，或者技嘉的G593-SD0。服务器选择面窄，议价能力就弱，一旦AMD供货出问题，你没法像NVIDIA那样立刻换到另一家OEM的L40S系统上。第二个风险是Infinity Fabric的生态封闭。做过多卡集群的都知道，NVIDIA的NVSwitch是开放给第三方交换机厂商的，但AMD的IF回路目前只有官方桥接板，想扩展8卡全互联？目前没有商业方案，只能等下一代的UAM（Unified Accelerator Module）。这限制了你做超大规模推理集群的灵活性。

我个人的最终建议是：如果你的生产负载有超过60%是70B以上参数的生成式模型，且你团队里有能啃ROCm的技术骨头，现在就可以小规模引入MI350，把它放到一个独立的推理池里，跟H100池做AB对比，逐步切流。如果你主要跑的是RAG或者Chat类短prompt高交互服务，那还是守着H100或者等NVIDIA的B200降价再说。不要被能效数字冲昏头脑，推理系统的瓶颈总是在你最意想不到的地方出现——在我这儿是固件bug，在你那儿可能是PagedAttention里某个没人修过的HIP算子。

至于AMD能不能撼动NVIDIA，我的感受是：它现在不是在撼动，是在NVIDIA的腿上狠狠咬了一口，NVIDIA疼，但暂时还站得稳。等到ROCm的算子生态补到CUDA 11的水平，配合更强的Infinity Fabric 4.0，或许我们真的会在推理市场看到两强并立。那一天，做推理选型就不用再这么拧巴了。