部署一个大模型，最怕听到的不是“模型效果不好”，而是“显存不够”。最近有组讨论让我印象很深：一个叫 Kimi K3 的模型，16 张 NVIDIA B200 才跑得动，换成 8 张 AMD 的卡就装下了。这不是简单的数字替换，而是把大模型部署的硬件选型问题重新摆到了桌面上。

我第一次看到这个说法时，第一反应是“真的假的”。毕竟 B200 是目前加速卡里非常高端的型号，单卡显存就有 192GB，16 张加起来接近 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 参数，会下意识觉得计算量也大得可怕。但如果它采用的是 MoE（Mixture 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 的成熟度明显提升，但在实际使用中，版本匹配仍然是最容易出问题的环节。

通常建议的顺序是：

1. 先确定你的 AMD 显卡型号对应的 ROCm 版本。不同显卡架构需要不同版本的驱动和运行时。
2. 安装对应版本的 PyTorch。注意 PyTorch 有很多个编译分支，必须选择支持 ROCm 的版本，而不是带 CUDA 的版本。
3. 验证 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，多半是这里没算清楚。

建议用一个小脚本先记录模型加载后的剩余显存，再分别测试 batch=1、batch=4、batch=8 的峰值显存。不要一上来就把 batch 拉满，否则会直接触发显卡驱动超时。

3.3 可观测性：没有监控的部署等于盲跑

8 张卡和 16 张卡相比，表面上是省了硬件成本，但多卡环境天然需要更细的观测能力。你至少要能回答这几个问题：

• 每一张卡的显存占用分别是多少？是否均匀？
• 每次推理结束后，显存有没有残留？
• 长时间运行后，温度是否稳定？有没有降频？
• 某张卡出现错误或者被驱动重置，应用能不能自动恢复？

如果你打算长期跑，建议先把日志、监控和告警体系搭起来。不需要多复杂的平台，只要能在终端看到每张卡的实时状态，能让关键信息写进日志，当出现异常时能定位到是哪一张卡出错。这一步很多新手会忽略，等真正出了事故才发现毫无头绪。

4. 显存不够、报错、崩溃的综合排查链路

在 AMD 平台上部署大模型，你大概率会遇到几个经典问题。下面给出一条比较实用的排查链路，按优先级从高到低走，很多问题都能在第二步或第三步找到原因。

4.1 从模型侧排查：权重格式、量化精度和峰值显存

第一个要看的是模型权重本身。

先确认你的权重是什么精度。如果是 FP16，2.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 方案，可以先做一轮自检，避免后面踩坑：

1. 环境是否固化 ：把 ROCm 版本、PyTorch 版本、显卡驱动版本全部记录在案，并用配置文件管理，不要手动改来改去。
2. 显存和温度是否有监控 ：至少能在终端实时看到 8 张卡的显存、温度和功率，能自动记录异常日志。
3. 量化后是否有质量评测 ：不要只看显存降低了，还要对比量化前后的输出质量，确认业务可接受。
4. 是否有失败重试机制 ：单卡报错或驱动重置时，任务能否自动恢复，还是一个报错就导致整个 batch 报废。
5. 是否定期跑基准测试 ：用同一份 prompt 集，定期测试延迟和吞吐，如果发现性能下降，可以尽早定位是驱动、环境还是模型变化导致。

这五条听起来简单，但实际能做全的团队并不多。尤其是第 4 条，很多方案在演示时一切正常，一旦跑上 7×24 小时，就会因为偶发的单卡故障导致整个服务挂掉。

回到最初那个标题。16 张 B200 能跑，8 张 AMD 能装下，这个对比真正值得讨论的不是输赢，而是大模型部署的硬件选择开始出现分岔口：不再是“必须用某一家”，而是开始有容量、带宽、成本和软件栈之间的权衡空间。如果你刚好在规划下一台模型服务器，我的建议是：别急着看最高参数，先把你要装的模型权重、量化精度、KV Cache 预算和运行时间要求算清楚，再决定该买几张卡、买谁的卡。