部署一个大模型最怕听到的不是“模型效果不好”而是“显存不够”。最近有组讨论让我印象很深一个叫 Kimi K3 的模型16 张 NVIDIA B200 才跑得动换成 8 张 AMD 的卡就装下了。这不是简单的数字替换而是把大模型部署的硬件选型问题重新摆到了桌面上。我第一次看到这个说法时第一反应是“真的假的”。毕竟 B200 是目前加速卡里非常高端的型号单卡显存就有 192GB16 张加起来接近 3TB。8 张 AMD 就能装下意味着要么单张 AMD 卡的平均可用显存比 B200 大不少要么这个模型的权重被压到了足够小。无论是哪种背后都有值得拆解的工程逻辑。这篇不打算吹某个硬件也不打算贬低另一个硬件。我更想借这个案例聊聊大模型部署里“装下 / 跑得动 / 用得好”三个层次的问题以及如果你也想在 AMD 平台上部署大参数模型会遇到哪些真正要命的坎。1. 先理解这个标题里藏的两层信号一个标题能在技术圈传开通常不是因为参数本身而是因为参数背后指向了一种新的可能。16 张 B200 和 8 张 AMD 的区别表面上只是显卡数量不同实际上藏着两层信号第一Kimi K3 这个级别的模型不再只属于几千亿参数以下的“常规部署”领域而是进入了可以用“单机多卡”去讨论的范畴第二AMD 在这个场景里不再只是替补而是开始成为一种可选的容量方案。1.1 从显存容量看为什么“16张B200”不是夸张先算一笔账。B200 的单卡显存通常按 192GB HBM3e 来理解16 张就是 3072GB约 3TB。如果 Kimi K3 是一个总参数达到 2.8T 规模的稀疏 MoE 模型那么仅模型权重在 FP8 精度下就需要约 2.8TB 的存储空间。加上推理过程中必须存在的激活值、KV Cache 以及计算中间态3TB 的显存并不是富裕配置而是刚刚好的底线。所以“16 张 B200 才能跑”这句话并没有夸张。它的核心瓶颈不是算力而是显存容量。当模型权重本身已经逼近整台机器的显存上限时少一张卡都不一定能加载进显存。AMD 这边如果 8 张就能装下最直接的推断就是单卡显存更大。公开市场上确实已经出现了单卡 256GB 甚至更高显存的加速卡如果按 8 张、每张 256GB 计算大约是 2TB理论上仍不能完全放下 2.8T 参数的 FP8 权重。所以这里要么使用了进一步的量化比如 INT8 甚至 INT4要么通过 CPU 内存卸载和显存分层加载来补充容量。更合理的推测是这个案例中的“装下”并非单纯把权重一次性全放显存而是通过混合精度和动态加载让模型可以在较小显存池里完成推理。不管具体实现是哪一种这个现象说明一件事万亿参数模型的部署门槛正在被拆掉而拆掉门槛的主要力量之一就是把显存容量做大、做便宜。1.2 从稀疏激活看2.8T参数的模型为什么能“装进”更少的卡很多人一听到 2.8T 参数会下意识觉得计算量也大得可怕。但如果它采用的是 MoEMixture of Experts架构情况就不一样。MoE 模型的特点是虽然总参数多但每个 token 只激活一部分专家网络。实际参与计算的参数可能只有总参数的几十分之一比如 2.8T 总参里激活参数只有 40B 或 80B。这样带来的好处是推理时的计算量并没有和总参数等比例膨胀真正吃掉的还是显存带宽和权重存储空间。这里就有个关键点MoE 模型在推理时虽然只计算部分专家但所有专家权重仍然必须被加载到显存里。因为你不知道当前 token 会命中哪些专家所以不能只把“可能用到的那部分”放进显存。这导致 2.8T 参数的权重存储是刚性的不太会被稀疏激活省下来。那 8 张 AMD 为什么能装下可能的解释是AMD 方案在显存容量上刚好跨过了这道刚性门槛或者通过更激进的量化把权重压缩到一个可接受的区间。这也给想做本地部署的人提了个醒稀疏模型并不能直接降低显存需求但能显著降低推理时的计算压力。所以只要容量解决计算层面反而不一定会成为瓶颈。2. “装下”不等于“跑得动”真正决定推理体验的还有带宽与互联很多人看到“8 张 AMD 就装下了”会自然以为“8 张 AMD 比 16 张 B200 更好”。但工程问题从来不是一道简单的算术题。能装下只说明显存容量满足要求能不能跑得动、跑得快还要看显存带宽、卡间互联、软件栈和框架优化程度。2.1 显存带宽模型读取速度会直接卡住生成速度大模型推理有一个特点每生成一个 token都要把相关权重从显存里读出来。虽然 MoE 模型只读取激活的那部分专家权重但权重文件本身依然很大。比如一个 70B 模型在 FP16 下权重约 140GB单次读取若分到多张卡并行也需要极高的带宽。当模型参数规模到万亿级即使只读取部分专家权重单 token 的权重读取量也可能达到几十 GB。显存带宽如果不给力计算单元就会时刻处于“等数据”的状态最终表现为生成速度极慢。B200 的 HBM3e 带宽在高端卡里是第一梯队而 AMD 的大显存卡带宽也不低但具体到某个型号可能仍有差异。所以更准确的判断方式是先看容量再看带宽最后看互联带宽。如果容量解决了但带宽跟不上那么“8 张能装下”可能只是“能启动”而不是“能可用地推理”。2.2 卡间互联和集群拓扑张量并行不是免费的把一个大模型切成多块放进多张卡里常见做法是张量并行或流水线并行。张量并行需要频繁地在 GPU 之间交换中间激活值卡间通信带宽直接决定了并行效率。NVIDIA 的优势在于 NVLink 和 NVSwitch 形成了非常成熟的互联矩阵8 卡甚至 16 卡的通信延迟能做到很低。AMD 这边虽然有 Infinity Fabric 作为跨卡互联方案但不同主板的 P2P 支持程度、PCIe 带宽和拓扑结构都可能成为瓶颈。如果你用的是消费级 AMD 显卡而不是数据中心级加速卡它们之间通常没有高速互联接口只能走 PCIe这种情况下把模型切到 8 张卡上做张量并行可能比单卡更慢。所以“8 张 AMD 装下了”这句话只有在“卡间互联带宽足够”的前提下才有实际意义。如果只是把 8 张各自独立的 GPU 用软件拼起来那么跑通可以跑快很难。3. 在8张AMD上部署大模型不是插上显卡就行无论你是因为手里已经有 AMD 显卡还是被“更少卡数”吸引真要复现一个类似的部署流程你都会发现难点不在模型本身而在环境、配置和运维这几个容易被低估的环节。3.1 环境准备ROCm与PyTorch的版本匹配是第一道坎AMD 的 GPU 生态不像 NVIDIA 那样默认走 CUDA你需要接触 ROCm。虽然这几年 ROCm 的成熟度明显提升但在实际使用中版本匹配仍然是最容易出问题的环节。通常建议的顺序是先确定你的 AMD 显卡型号对应的 ROCm 版本。不同显卡架构需要不同版本的驱动和运行时。安装对应版本的 PyTorch。注意 PyTorch 有很多个编译分支必须选择支持 ROCm 的版本而不是带 CUDA 的版本。验证 GPU 是否被 PyTorch 正确识别。如果用的是 Linux 容器还需要把设备映射进容器并设置好HSA_OVERRIDE_GFX_VERSION这类环境变量。很多人在这一步就直接被劝退了。因为报错信息可能非常不直观比如“no kernel image available”“device-side assert triggered”之类其实背后都是驱动和 ROCm 版本不匹配。注意如果你平时习惯用 Ollama 这类工具先跑一个 7B 的小模型确认 GPU 真的被用上了再考虑大规模部署。不要让大小模型共用同一套未经验证的环境。3.2 推理配置并行策略、batch 和 KV Cache 需要一起调当模型能加载到显存后第二步就是配置推理参数。对于 8 卡场景常见的并行策略是张量并行。你需要把 tensor parallel 的规模设置为 8让模型权重在 8 张卡之间进行切分。但切分方式不止一种不同框架的切分结果可能不同。比如有的框架切分 attention 的 qkv 权重有的框架切分 expert 权重切法不同会导致显存占用和通信量不同。接下来是 batch size 和上下文长度。batch 越大吞吐越高但 KV Cache 占用也越高。如果上下文长度是 32K加上并发请求KV Cache 可能单独占掉几百 GB 显存。很多人加载模型时没有爆显存一跑推理就 OOM多半是这里没算清楚。建议用一个小脚本先记录模型加载后的剩余显存再分别测试 batch1、batch4、batch8 的峰值显存。不要一上来就把 batch 拉满否则会直接触发显卡驱动超时。3.3 可观测性没有监控的部署等于盲跑8 张卡和 16 张卡相比表面上是省了硬件成本但多卡环境天然需要更细的观测能力。你至少要能回答这几个问题每一张卡的显存占用分别是多少是否均匀每次推理结束后显存有没有残留长时间运行后温度是否稳定有没有降频某张卡出现错误或者被驱动重置应用能不能自动恢复如果你打算长期跑建议先把日志、监控和告警体系搭起来。不需要多复杂的平台只要能在终端看到每张卡的实时状态能让关键信息写进日志当出现异常时能定位到是哪一张卡出错。这一步很多新手会忽略等真正出了事故才发现毫无头绪。4. 显存不够、报错、崩溃的综合排查链路在 AMD 平台上部署大模型你大概率会遇到几个经典问题。下面给出一条比较实用的排查链路按优先级从高到低走很多问题都能在第二步或第三步找到原因。4.1 从模型侧排查权重格式、量化精度和峰值显存第一个要看的是模型权重本身。先确认你的权重是什么精度。如果是 FP162.8T 参数需要约 5.6TB 显存这在 8 张卡上很难实现。所以能在 8 张 AMD 上跑的大概率是 FP8 或 INT8 甚至更低位宽的版本。但量化不是免费的你需要确认推理框架是否支持这种量化格式以及是否会因为量化导致精度下降严重。其次要看实际峰值显存。有些模型加载时会申请比权重文件更大的显存因为在初始化阶段会把部分参数临时扩到 FP16 或 BF16。你可以在推理启动前和运行中分别记录torch.cuda.max_memory_reserved()如果发现显存峰值远超权重文件大小那就说明不是显卡数量的问题而是项目本身用了高精度初始化。4.2 从环境侧排查驱动、依赖、GPU 可见性和 gfx 标识如果模型本身没问题下一步查环境。在 AMD 平台上rocm-smi应该能看到所有显卡的型号、温度和显存。如果看不到某张卡先查供电、PCIe 插槽和系统是否识别了设备。然后用 PyTorch 的torch.cuda.is_available()检查运行时是否可用。如果返回 False多半是 PyTorch 版本没有编译对应 ROCm 支持或者缺少某些动态库。还有一个很隐晦的点ROCm 驱动下的 GPU 架构标识。有些新卡需要设置HSA_OVERRIDE_GFX_VERSION才能运行在较老版本的 ROCm 上。这个变量改错会导致 kernel 无法加载但报错信息可能是一个通用的非法指令或内存错误很容易误导你往代码层面排查。4.3 从并行侧排查切分配置是否让显存负载均衡如果你已经用张量并行把模型跑起来了但某张卡显存爆掉其他卡还有大量剩余那大概率是切分策略有问题。张量并行会把权重按列或按行切成多份如果切分的维度不是模型定义预期的维度就可能出现某些 rank 拿到额外权重。也可以用环境变量或框架日志查看每个 rank 的显存分配情况。如果 rank 0 明显高于其他 rank先检查是否有额外的 offload 任务或者中间缓存落在 rank 0 上。另一种可能是不小心把数据并行和张量并行混用了。如果只是单纯复制多份模型到多张卡来做数据并行那模型会被重复加载显存自然不够用。这里没有通用的“最优解”只能结合模型结构和框架文档去调整。4.4 从资源侧排查批次大小、上下文长度和 KV Cache很多崩溃发生在推理过程中段比如跑了几百条 prompt 后突然 OOM。最常见的原因是 KV Cache 没有随着请求数量增长而自动缩放过。你可以在配置里显式设置最大上下文长度、最大 batch 数并限制 KV Cache 的容量。如果框架支持enable_chunked_prefill推荐打开它能把预填充阶段的长输入拆成小块避免峰值显存过高。如果所有参数都调小了还是崩溃再检查系统层面是否存在其他程序占用显存比如显存泄漏的旧进程。每次跑完任务后都看一下rocm-smi确认显存已经释放。5. 这类“8卡方案”究竟适合谁不适合谁“16 张 B200”和“8 张 AMD”的讨论很容易走向两个极端要么觉得 AMD 马上要翻身要么觉得这只是一次偶然的优化。作为做工程的人我更倾向于把它看成一个边界条件的具体案例。它适合一部分场景但不适合所有生产环境。5.1 适合的尝试方向实验、离线推理、对成本敏感的场景如果你的目标是验证“万亿参数模型能不能在较小的 GPU 集群里跑起来”那么 8 张 AMD 方案非常值得尝试。它把硬件门槛从“顶级 NVIDIA 集群”拉到了“有一定规格的 AMD 集群”对研究机构和预算有限的团队来说这是一个新的实验空间。同样适合离线推理场景。比如批量生成评测数据、后台跑分析任务对单个 token 延迟不敏感只要求吞吐和成本可控。这类任务即使因为软件栈优化不足导致速度偏慢也还在可接受范围内。另外如果你已经有一批 AMD 显卡闲置用它来部署大模型做技术验证成本几乎为零。这时候不纠结“能不能替代 B200”只看“能不能让现有资源产出价值”。5.2 不适合的生产边界低延迟服务、成熟生态依赖和长期维护如果你的业务是面向用户的在线对话服务要求首 token 延迟很低、并发波动大那我不建议把核心服务押注在“8 张 AMD 能装下”这套方案上。原因不是 AMD 不行而是整个软件生态的成熟度仍然有差距。比如主流推理框架对 ROCm 的支持版本、FlashAttention 的 AMD 移植程度、算子库的覆盖范围都会影响你在遇到瓶颈时能不能快速找到解决方案。相比之下NVIDIA 生态已经沉淀了大量可直接复用的容器、镜像和参数最优解。团队如果只有 CUDA 经验突然切到 ROCm排障成本会比想象中高。还有一个容易被低估的点是长期维护。8 张卡跑起来了不代表三个月后还能稳定跑。驱动迭代、PyTorch 更新、模型版本升级、任务量增长都可能让原有的配置失效。如果没有专门的运维投入这类方案更适合短期实验不太适合无脑上生产。5.3 想长期用下去先做这五个检查如果你决定长期使用 AMD 方案可以先做一轮自检避免后面踩坑环境是否固化把 ROCm 版本、PyTorch 版本、显卡驱动版本全部记录在案并用配置文件管理不要手动改来改去。显存和温度是否有监控至少能在终端实时看到 8 张卡的显存、温度和功率能自动记录异常日志。量化后是否有质量评测不要只看显存降低了还要对比量化前后的输出质量确认业务可接受。是否有失败重试机制单卡报错或驱动重置时任务能否自动恢复还是一个报错就导致整个 batch 报废。是否定期跑基准测试用同一份 prompt 集定期测试延迟和吞吐如果发现性能下降可以尽早定位是驱动、环境还是模型变化导致。这五条听起来简单但实际能做全的团队并不多。尤其是第 4 条很多方案在演示时一切正常一旦跑上 7×24 小时就会因为偶发的单卡故障导致整个服务挂掉。回到最初那个标题。16 张 B200 能跑8 张 AMD 能装下这个对比真正值得讨论的不是输赢而是大模型部署的硬件选择开始出现分岔口不再是“必须用某一家”而是开始有容量、带宽、成本和软件栈之间的权衡空间。如果你刚好在规划下一台模型服务器我的建议是别急着看最高参数先把你要装的模型权重、量化精度、KV Cache 预算和运行时间要求算清楚再决定该买几张卡、买谁的卡。 
长河君 · 2026/8/28 10:51:34 · 阅读 1.2k 8张AMD装下万亿参数模型？大模型部署的显存、带宽与工程权衡
部署一个大模型最怕听到的不是“模型效果不好”而是“显存不够”。最近有组讨论让我印象很深一个叫 Kimi K3 的模型16 张 NVIDIA B200 才跑得动换成 8 张 AMD 的卡就装下了。这不是简单的数字替换而是把大模型部署的硬件选型问题重新摆到了桌面上。我第一次看到这个说法时第一反应是“真的假的”。毕竟 B200 是目前加速卡里非常高端的型号单卡显存就有 192GB16 张加起来接近 3TB。8 张 AMD 就能装下意味着要么单张 AMD 卡的平均可用显存比 B200 大不少要么这个模型的权重被压到了足够小。无论是哪种背后都有值得拆解的工程逻辑。这篇不打算吹某个硬件也不打算贬低另一个硬件。我更想借这个案例聊聊大模型部署里“装下 / 跑得动 / 用得好”三个层次的问题以及如果你也想在 AMD 平台上部署大参数模型会遇到哪些真正要命的坎。1. 先理解这个标题里藏的两层信号一个标题能在技术圈传开通常不是因为参数本身而是因为参数背后指向了一种新的可能。16 张 B200 和 8 张 AMD 的区别表面上只是显卡数量不同实际上藏着两层信号第一Kimi K3 这个级别的模型不再只属于几千亿参数以下的“常规部署”领域而是进入了可以用“单机多卡”去讨论的范畴第二AMD 在这个场景里不再只是替补而是开始成为一种可选的容量方案。1.1 从显存容量看为什么“16张B200”不是夸张先算一笔账。B200 的单卡显存通常按 192GB HBM3e 来理解16 张就是 3072GB约 3TB。如果 Kimi K3 是一个总参数达到 2.8T 规模的稀疏 MoE 模型那么仅模型权重在 FP8 精度下就需要约 2.8TB 的存储空间。加上推理过程中必须存在的激活值、KV Cache 以及计算中间态3TB 的显存并不是富裕配置而是刚刚好的底线。所以“16 张 B200 才能跑”这句话并没有夸张。它的核心瓶颈不是算力而是显存容量。当模型权重本身已经逼近整台机器的显存上限时少一张卡都不一定能加载进显存。AMD 这边如果 8 张就能装下最直接的推断就是单卡显存更大。公开市场上确实已经出现了单卡 256GB 甚至更高显存的加速卡如果按 8 张、每张 256GB 计算大约是 2TB理论上仍不能完全放下 2.8T 参数的 FP8 权重。所以这里要么使用了进一步的量化比如 INT8 甚至 INT4要么通过 CPU 内存卸载和显存分层加载来补充容量。更合理的推测是这个案例中的“装下”并非单纯把权重一次性全放显存而是通过混合精度和动态加载让模型可以在较小显存池里完成推理。不管具体实现是哪一种这个现象说明一件事万亿参数模型的部署门槛正在被拆掉而拆掉门槛的主要力量之一就是把显存容量做大、做便宜。1.2 从稀疏激活看2.8T参数的模型为什么能“装进”更少的卡很多人一听到 2.8T 参数会下意识觉得计算量也大得可怕。但如果它采用的是 MoEMixture of Experts架构情况就不一样。MoE 模型的特点是虽然总参数多但每个 token 只激活一部分专家网络。实际参与计算的参数可能只有总参数的几十分之一比如 2.8T 总参里激活参数只有 40B 或 80B。这样带来的好处是推理时的计算量并没有和总参数等比例膨胀真正吃掉的还是显存带宽和权重存储空间。这里就有个关键点MoE 模型在推理时虽然只计算部分专家但所有专家权重仍然必须被加载到显存里。因为你不知道当前 token 会命中哪些专家所以不能只把“可能用到的那部分”放进显存。这导致 2.8T 参数的权重存储是刚性的不太会被稀疏激活省下来。那 8 张 AMD 为什么能装下可能的解释是AMD 方案在显存容量上刚好跨过了这道刚性门槛或者通过更激进的量化把权重压缩到一个可接受的区间。这也给想做本地部署的人提了个醒稀疏模型并不能直接降低显存需求但能显著降低推理时的计算压力。所以只要容量解决计算层面反而不一定会成为瓶颈。2. “装下”不等于“跑得动”真正决定推理体验的还有带宽与互联很多人看到“8 张 AMD 就装下了”会自然以为“8 张 AMD 比 16 张 B200 更好”。但工程问题从来不是一道简单的算术题。能装下只说明显存容量满足要求能不能跑得动、跑得快还要看显存带宽、卡间互联、软件栈和框架优化程度。2.1 显存带宽模型读取速度会直接卡住生成速度大模型推理有一个特点每生成一个 token都要把相关权重从显存里读出来。虽然 MoE 模型只读取激活的那部分专家权重但权重文件本身依然很大。比如一个 70B 模型在 FP16 下权重约 140GB单次读取若分到多张卡并行也需要极高的带宽。当模型参数规模到万亿级即使只读取部分专家权重单 token 的权重读取量也可能达到几十 GB。显存带宽如果不给力计算单元就会时刻处于“等数据”的状态最终表现为生成速度极慢。B200 的 HBM3e 带宽在高端卡里是第一梯队而 AMD 的大显存卡带宽也不低但具体到某个型号可能仍有差异。所以更准确的判断方式是先看容量再看带宽最后看互联带宽。如果容量解决了但带宽跟不上那么“8 张能装下”可能只是“能启动”而不是“能可用地推理”。2.2 卡间互联和集群拓扑张量并行不是免费的把一个大模型切成多块放进多张卡里常见做法是张量并行或流水线并行。张量并行需要频繁地在 GPU 之间交换中间激活值卡间通信带宽直接决定了并行效率。NVIDIA 的优势在于 NVLink 和 NVSwitch 形成了非常成熟的互联矩阵8 卡甚至 16 卡的通信延迟能做到很低。AMD 这边虽然有 Infinity Fabric 作为跨卡互联方案但不同主板的 P2P 支持程度、PCIe 带宽和拓扑结构都可能成为瓶颈。如果你用的是消费级 AMD 显卡而不是数据中心级加速卡它们之间通常没有高速互联接口只能走 PCIe这种情况下把模型切到 8 张卡上做张量并行可能比单卡更慢。所以“8 张 AMD 装下了”这句话只有在“卡间互联带宽足够”的前提下才有实际意义。如果只是把 8 张各自独立的 GPU 用软件拼起来那么跑通可以跑快很难。3. 在8张AMD上部署大模型不是插上显卡就行无论你是因为手里已经有 AMD 显卡还是被“更少卡数”吸引真要复现一个类似的部署流程你都会发现难点不在模型本身而在环境、配置和运维这几个容易被低估的环节。3.1 环境准备ROCm与PyTorch的版本匹配是第一道坎AMD 的 GPU 生态不像 NVIDIA 那样默认走 CUDA你需要接触 ROCm。虽然这几年 ROCm 的成熟度明显提升但在实际使用中版本匹配仍然是最容易出问题的环节。通常建议的顺序是先确定你的 AMD 显卡型号对应的 ROCm 版本。不同显卡架构需要不同版本的驱动和运行时。安装对应版本的 PyTorch。注意 PyTorch 有很多个编译分支必须选择支持 ROCm 的版本而不是带 CUDA 的版本。验证 GPU 是否被 PyTorch 正确识别。如果用的是 Linux 容器还需要把设备映射进容器并设置好HSA_OVERRIDE_GFX_VERSION这类环境变量。很多人在这一步就直接被劝退了。因为报错信息可能非常不直观比如“no kernel image available”“device-side assert triggered”之类其实背后都是驱动和 ROCm 版本不匹配。注意如果你平时习惯用 Ollama 这类工具先跑一个 7B 的小模型确认 GPU 真的被用上了再考虑大规模部署。不要让大小模型共用同一套未经验证的环境。3.2 推理配置并行策略、batch 和 KV Cache 需要一起调当模型能加载到显存后第二步就是配置推理参数。对于 8 卡场景常见的并行策略是张量并行。你需要把 tensor parallel 的规模设置为 8让模型权重在 8 张卡之间进行切分。但切分方式不止一种不同框架的切分结果可能不同。比如有的框架切分 attention 的 qkv 权重有的框架切分 expert 权重切法不同会导致显存占用和通信量不同。接下来是 batch size 和上下文长度。batch 越大吞吐越高但 KV Cache 占用也越高。如果上下文长度是 32K加上并发请求KV Cache 可能单独占掉几百 GB 显存。很多人加载模型时没有爆显存一跑推理就 OOM多半是这里没算清楚。建议用一个小脚本先记录模型加载后的剩余显存再分别测试 batch1、batch4、batch8 的峰值显存。不要一上来就把 batch 拉满否则会直接触发显卡驱动超时。3.3 可观测性没有监控的部署等于盲跑8 张卡和 16 张卡相比表面上是省了硬件成本但多卡环境天然需要更细的观测能力。你至少要能回答这几个问题每一张卡的显存占用分别是多少是否均匀每次推理结束后显存有没有残留长时间运行后温度是否稳定有没有降频某张卡出现错误或者被驱动重置应用能不能自动恢复如果你打算长期跑建议先把日志、监控和告警体系搭起来。不需要多复杂的平台只要能在终端看到每张卡的实时状态能让关键信息写进日志当出现异常时能定位到是哪一张卡出错。这一步很多新手会忽略等真正出了事故才发现毫无头绪。4. 显存不够、报错、崩溃的综合排查链路在 AMD 平台上部署大模型你大概率会遇到几个经典问题。下面给出一条比较实用的排查链路按优先级从高到低走很多问题都能在第二步或第三步找到原因。4.1 从模型侧排查权重格式、量化精度和峰值显存第一个要看的是模型权重本身。先确认你的权重是什么精度。如果是 FP162.8T 参数需要约 5.6TB 显存这在 8 张卡上很难实现。所以能在 8 张 AMD 上跑的大概率是 FP8 或 INT8 甚至更低位宽的版本。但量化不是免费的你需要确认推理框架是否支持这种量化格式以及是否会因为量化导致精度下降严重。其次要看实际峰值显存。有些模型加载时会申请比权重文件更大的显存因为在初始化阶段会把部分参数临时扩到 FP16 或 BF16。你可以在推理启动前和运行中分别记录torch.cuda.max_memory_reserved()如果发现显存峰值远超权重文件大小那就说明不是显卡数量的问题而是项目本身用了高精度初始化。4.2 从环境侧排查驱动、依赖、GPU 可见性和 gfx 标识如果模型本身没问题下一步查环境。在 AMD 平台上rocm-smi应该能看到所有显卡的型号、温度和显存。如果看不到某张卡先查供电、PCIe 插槽和系统是否识别了设备。然后用 PyTorch 的torch.cuda.is_available()检查运行时是否可用。如果返回 False多半是 PyTorch 版本没有编译对应 ROCm 支持或者缺少某些动态库。还有一个很隐晦的点ROCm 驱动下的 GPU 架构标识。有些新卡需要设置HSA_OVERRIDE_GFX_VERSION才能运行在较老版本的 ROCm 上。这个变量改错会导致 kernel 无法加载但报错信息可能是一个通用的非法指令或内存错误很容易误导你往代码层面排查。4.3 从并行侧排查切分配置是否让显存负载均衡如果你已经用张量并行把模型跑起来了但某张卡显存爆掉其他卡还有大量剩余那大概率是切分策略有问题。张量并行会把权重按列或按行切成多份如果切分的维度不是模型定义预期的维度就可能出现某些 rank 拿到额外权重。也可以用环境变量或框架日志查看每个 rank 的显存分配情况。如果 rank 0 明显高于其他 rank先检查是否有额外的 offload 任务或者中间缓存落在 rank 0 上。另一种可能是不小心把数据并行和张量并行混用了。如果只是单纯复制多份模型到多张卡来做数据并行那模型会被重复加载显存自然不够用。这里没有通用的“最优解”只能结合模型结构和框架文档去调整。4.4 从资源侧排查批次大小、上下文长度和 KV Cache很多崩溃发生在推理过程中段比如跑了几百条 prompt 后突然 OOM。最常见的原因是 KV Cache 没有随着请求数量增长而自动缩放过。你可以在配置里显式设置最大上下文长度、最大 batch 数并限制 KV Cache 的容量。如果框架支持enable_chunked_prefill推荐打开它能把预填充阶段的长输入拆成小块避免峰值显存过高。如果所有参数都调小了还是崩溃再检查系统层面是否存在其他程序占用显存比如显存泄漏的旧进程。每次跑完任务后都看一下rocm-smi确认显存已经释放。5. 这类“8卡方案”究竟适合谁不适合谁“16 张 B200”和“8 张 AMD”的讨论很容易走向两个极端要么觉得 AMD 马上要翻身要么觉得这只是一次偶然的优化。作为做工程的人我更倾向于把它看成一个边界条件的具体案例。它适合一部分场景但不适合所有生产环境。5.1 适合的尝试方向实验、离线推理、对成本敏感的场景如果你的目标是验证“万亿参数模型能不能在较小的 GPU 集群里跑起来”那么 8 张 AMD 方案非常值得尝试。它把硬件门槛从“顶级 NVIDIA 集群”拉到了“有一定规格的 AMD 集群”对研究机构和预算有限的团队来说这是一个新的实验空间。同样适合离线推理场景。比如批量生成评测数据、后台跑分析任务对单个 token 延迟不敏感只要求吞吐和成本可控。这类任务即使因为软件栈优化不足导致速度偏慢也还在可接受范围内。另外如果你已经有一批 AMD 显卡闲置用它来部署大模型做技术验证成本几乎为零。这时候不纠结“能不能替代 B200”只看“能不能让现有资源产出价值”。5.2 不适合的生产边界低延迟服务、成熟生态依赖和长期维护如果你的业务是面向用户的在线对话服务要求首 token 延迟很低、并发波动大那我不建议把核心服务押注在“8 张 AMD 能装下”这套方案上。原因不是 AMD 不行而是整个软件生态的成熟度仍然有差距。比如主流推理框架对 ROCm 的支持版本、FlashAttention 的 AMD 移植程度、算子库的覆盖范围都会影响你在遇到瓶颈时能不能快速找到解决方案。相比之下NVIDIA 生态已经沉淀了大量可直接复用的容器、镜像和参数最优解。团队如果只有 CUDA 经验突然切到 ROCm排障成本会比想象中高。还有一个容易被低估的点是长期维护。8 张卡跑起来了不代表三个月后还能稳定跑。驱动迭代、PyTorch 更新、模型版本升级、任务量增长都可能让原有的配置失效。如果没有专门的运维投入这类方案更适合短期实验不太适合无脑上生产。5.3 想长期用下去先做这五个检查如果你决定长期使用 AMD 方案可以先做一轮自检避免后面踩坑环境是否固化把 ROCm 版本、PyTorch 版本、显卡驱动版本全部记录在案并用配置文件管理不要手动改来改去。显存和温度是否有监控至少能在终端实时看到 8 张卡的显存、温度和功率能自动记录异常日志。量化后是否有质量评测不要只看显存降低了还要对比量化前后的输出质量确认业务可接受。是否有失败重试机制单卡报错或驱动重置时任务能否自动恢复还是一个报错就导致整个 batch 报废。是否定期跑基准测试用同一份 prompt 集定期测试延迟和吞吐如果发现性能下降可以尽早定位是驱动、环境还是模型变化导致。这五条听起来简单但实际能做全的团队并不多。尤其是第 4 条很多方案在演示时一切正常一旦跑上 7×24 小时就会因为偶发的单卡故障导致整个服务挂掉。回到最初那个标题。16 张 B200 能跑8 张 AMD 能装下这个对比真正值得讨论的不是输赢而是大模型部署的硬件选择开始出现分岔口不再是“必须用某一家”而是开始有容量、带宽、成本和软件栈之间的权衡空间。如果你刚好在规划下一台模型服务器我的建议是别急着看最高参数先把你要装的模型权重、量化精度、KV Cache 预算和运行时间要求算清楚再决定该买几张卡、买谁的卡。