Kimi K3 在部署圈里被反复讨论不是因为它的推理效果而是因为显存需求太夸张网上流传的部署方案里16 张 NVIDIA B200 才能按较高精度跑起来8 张 AMD 大显存加速卡却可以在更低精度下把同一模型装进显存。这个对比很容易被解读成“AMD 打赢了 B200”但从工程角度看不完全是那么回事——背后是显存总量、量化精度和推理框架三者共同决定的结果。这篇文章会围绕三个问题展开Kimi K3 这种模型为什么显存需求那么高16 张 B200 和 8 张 AMD 大显存卡在容量上的差异究竟是什么如果你自己有一台 AMD GPU 工作站或服务器想跑 7B、32B 甚至更大的模型环境应该怎么搭、Ollama 怎么调用 AMD GPU、多卡推理怎么切分。最后会整理一份从 NVIDIA 迁移到 AMD 时最容易踩到的坑以及一套部署前检查清单。如果你只是想在普通笔记本上跑一个试验模型这篇文章里的多卡和量化章节也可以当前置知识看如果你已经有 AMD 显卡、想在 WSL2 或 Linux 下把 GPU 用起来那么从第 3 节开始可以直接照着操作。1. Kimi K3 这类 MoE 模型显存需求到底由什么决定1.1 MoE 模型的总参数量与激活参数量的区别Kimi K3 之所以会被拿来当作“大模型显存焦虑”的典型例子是因为它属于 MoE 架构。MoE 的完整说法是 Mixture of Experts也就是混合专家模型。这种模型里每次推理并不会让所有参数都参与计算而是由路由网络挑选一部分专家来处理当前 token。所以“参数量很大”和“计算量很大”并不是一回事。网上关于 K3 的讨论里有一个经常被提到的数字是接近 2.8T 参数。为了方便后文估算这里直接采用这个数字。需要先说明的是这是开发社区流传的部署讨论口径不是官方教程里的确定参数但作为显存估算的例子足够说明问题。MoE 模型最大的认知陷阱就在这里因为激活参数少很多人以为运行时占用的显存也会少。实际上只要模型权重被加载到显存中就必须把全部参数放进去哪怕一次推理只用到了其中一小部分专家。也就是说显存的第一个下限由“总参数量 x 每个参数的字节数”决定和单次激活多少参数没有直接关系。如果把“参数量大但激活参数少”和“参数量中等但激活参数多”两种模型放在同一块 GPU 上比较前者虽然推理速度快但显存占用依然很高。这也是为什么 Kimi K3 需要几十张 192GB 显存的加速卡才能跑而不是靠一张大显存消费级显卡就能搞定。1.2 显存 参数体积 KV Cache 中间激活一张表算清部署一个模型时显存占用并不是只有模型权重这一项。完整来说推理过程中的显存至少包括三部分模型权重KV Cache中间激活值和临时张量模型权重是最固定的部分只要模型加载完毕就常驻显存。KV Cache 是推理时为了复用历史 token 的 key 和 value 而保存的缓存它随上下文长度增长。中间激活值则在每次 forward 过程中产生虽然生命周期短但峰值可能很高尤其是 batch size 较大时。如果只算权重部分可以用一个很简单的公式显存占用字节 参数量 × 每个参数需要的字节数不同精度下2.8T 参数模型的权重体积如下表精度每个参数字节数2.8T 参数权重体积约典型用途FP16 / BF162 字节5.1 TiB高精度训练、推理基准FP81 字节2.55 TiB高性能推理精度损失可控INT4 量化0.5 字节1.27 TiB社区常用的显存优化部署INT8 量化1 字节2.55 TiB推理部署兼容性较好注意这里用的是 TiB1 TiB 约等于 1.1 TB。因为很多显卡标称容量用的是 GB十进制计算总显存时经常出现“标称 192GB实际能用的寻址空间在系统里按 GiB 显示”的差异。这只是权重部分。如果要跑 32K 或更长的上下文KV Cache 可能会增加几十甚至上百 GB。因此评估一张卡能不能跑某个模型不能只盯着模型文件大小还要把上下文长度和 batch 大小一起算进去。1.3 为什么网上会有“16 张 B200 才能跑”的说法B200 是 NVIDIA 的高端加速卡公开资料里常见的显存配置是 192GB HBM3e。16 张 B200 的总显存约等于 3.0 TB按十进制算约 3.2 TB按 2 的幂次算约 2.8 TiB。如果 Kimi K3 需要按 FP8 或更高精度部署2.8T 参数权重就占掉 2.55 TiB。再加上 KV Cache、中间激活值、框架预留的通信缓冲16 张 B200 的总显存被全部吃掉并不奇怪。换句话说“16 张 B200 才能跑”更像是在说在较高精度下显存被模型权重撑满了所以需要这么多卡来摊分。而“8 张 AMD 就装下了”这个说法通常建立在 INT4 量化基础上。8 张 192GB 显存的 AMD 加速卡总显存约为 1.4 TiB4bit 量化后的 2.8T 参数权重约 1.27 TiB。如果不追求太长上下文、不把 KV Cache 开到极端值理论上确实可以放进 8 张卡。这就是标题里“8 张 AMD 装下”的工程原因不是 AMD 单卡比 B200 强而是量化精度把显存需求压到了 8 卡容量以内。2. 16 张 B200 和 8 张 AMD 多卡方案对比不是简单的“A 胜 B”2.1 从单卡显存开始算B200 与 AMD 旗舰卡的规格差异做硬件对比时不能只看显存容量还要看显存带宽、互联带宽、功耗和软件生态。下面表格列出了常见的两大类参数实际采购时以官方规格书为准项目NVIDIA B200AMD MI300X常见旗舰显存容量192GB HBM3e192GB HBM3显存带宽约 8 TB/s约 5.2 TB/s单卡互联NVLinkInfinity Fabric软件生态CUDA 生态最完整ROCm 生态逐步完善对 PyTorch 的支持非常成熟需要 ROCm 版本 PyTorch从单卡显存看两者都是 192GB 这个级别。因此 16 张 B200 和 8 张 MI300X 的对比本质上不是“单卡谁更强”而是“总显存谁更多、软件优化谁更好”。如果只比较显存总量16 张 B200 显然更高因为卡数多一倍。但大模型部署的另一个关键指标是单卡能否装下足够多的层和权重。8 张 192GB 和 16 张 192GB 的区别在于前者需要让每张卡承担更多层数通信压力更小后者每张卡分到的层数少但卡间通信路径更长。选择什么硬件取决于模型切分方式和框架支持。2.2 量化精度如何改变总显存需求量化是让“8 张卡装下超大模型”成为可能的核心手段。它的原理很简单原本用 2 个字节表示一个权重现在用 4bit 甚至更少 bit 来表示牺牲一定精度来换取更小的显存占用。我们以 2.8T 参数为例看看不同精度的总显存需求精度权重体积加上 KV Cache 和激活的粗略需求需要的 192GB 卡数约FP165.1 TiB约 5.6 TiB 以上需要约 20 张FP82.55 TiB约 3.0 TiB 以上需要约 11 到 16 张INT41.27 TiB约 1.6 到 2.0 TiB需要约 8 到 12 张所以“8 张 AMD 装下了”并不是“AMD 显存利用率更高”而是“INT4 量化把模型体积压到了 8 卡总显存以内”。你在网上看到的很多宣称“XX 张卡跑大模型”的帖子第一步都应该先确认它用的是 FP16、FP8还是 4bit 量化这个前提不说明对比就没有意义。2.3 AMD 方案更适合哪些场景B200 方案又赢在哪里AMD 大显存方案的现实价值在于当资金有限、又想跑大参数量模型时8 张 192GB 卡明显比 16 张 B200 更容易获得。成本、功耗、机柜空间、散热都是需要考虑的现实因素。但 AMD 方案并不总是更好。B200 的优势在于软件兼容性、显存带宽和框架优化。NVIDIA 生态下PyTorch 的 CUDA 版本、vLLM、Triton 等工具链更成熟遇到问题能找到的现成资料更多。AMD 的 ROCm 虽然已经能跑很多主流模型但版本更新快部分框架的兼容性需要额外验证。所以理性判断是如果项目对推理精度要求高上下文很长需要大规模并行B200 或 NVIDIA 高端卡更稳如果主要目标是“用最少卡数把大模型放进显存跑起来”AMD 大显存卡配合 4bit 量化是一个成本敏感场景下的可行方案。3. AMD GPU 本地部署大模型的准备工作从驱动到 ROCm3.1 Linux 环境下的 ROCm 安装与校验AMD GPU 在 Linux 下跑深度学习首先要装好 ROCm 运行时。ROCm 是 AMD 对标的 CUDA 软件栈它负责让 PyTorch、Ollama 等框架能够识别 GPU 并执行计算。安装前先确认硬件是否被系统识别。打开终端执行lspci | grep -i amd如果输出里能看到带有 Display controller 或 VGA compatible controller 的 AMD 设备说明系统已经发现了显卡。接着需要安装 ROCm。AMD 官方提供两种方式使用发行版仓库安装预先编译好的 ROCm或者从 AMD 官网下载安装包。下面是一个常见 Ubuntu 环境的示例命令sudo apt update sudo apt install rocm这里要注意不同 Linux 发行版、不同内核版本对应的 ROCm 版本不一样。安装前最好先确认当前系统版本和 GPU 架构属于 ROCm 支持列表否则装完之后rocm-smi可能找不到设备。安装完成后用两个命令校验rocm-smi rocminforocm-smi能显示 GPU 温度、功耗、显存使用率rocminfo能输出更详细的 GPU 架构信息。如果这两个命令能正确列出 AMD GPU说明驱动层基本正常。3.2 Windows 下通过 WSL2 使用 AMD GPU 的关键配置很多开发者的主力机器是 Windows但深度学习工具链在 Linux 下更顺手。AMD 提供了 WSL2 支持也就是说在 Windows 上安装好 AMD 驱动WSL2 内部可以直接使用 GPU。首先确保 Windows 开启了 WSL2wsl --install -d Ubuntu-22.04然后在 Windows 侧安装 AMD Adrenalin 显卡驱动。这里有一个容易忽略的点安装的 Windows 驱动必须包含 WSL 支持否则 WSL2 内部看不到/dev/kfd设备。安装完成后进入 WSL2 Ubuntu检查设备文件ls -l /dev/kfd /dev/dri/render*如果文件存在说明 Windows 驱动已经成功把 GPU 暴露给了 WSL2。接下来在 WSL2 内安装 ROCm 用户态库方式与 Linux 环境类似。一个常见的坑是WSL2 里面不需要单独安装 AMD 内核模块因为内核模块由 Windows 驱动提供。如果你在 WSL2 里重复安装完整 ROCm反而可能造成版本冲突。3.3 检查 AMD GPU 是否被 PyTorch 正确识别驱动装好之后还需要装一个 ROCm 版本的 PyTorch。很多人默认执行pip install torch但这样安装的版本通常是 CUDA 版在 AMD GPU 上完全无法工作。正确方式是安装 ROCm 版的 torch。以 ROCm 6.2 为例可以执行pip install torch --index-url https://download.pytorch.org/whl/rocm6.2版本号会随 PyTorch 发布节奏变化安装前最好去 PyTorch 官方查看当前推荐的 ROCm 版本。安装完成后用下面这段 Python 代码验证import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0))在 ROCm 版本中PyTorch 依然使用torch.cuda作为设备接口底层实际走的是 HIP/ROCm。如果torch.cuda.is_available()返回 True说明 GPU 已经被 PyTorch 正确识别。一个小提示如果输出是 False首先不要怀疑代码优先检查 PyTorch 版本是否带 ROCm 标志以及/dev/kfd是否存在。4. 用 Ollama 在 AMD GPU 上跑模型最小可复现流程4.1 安装支持 ROCm 的 OllamaOllama 是目前最简单的本地模型运行时它把模型下载、加载、推理接口封装成了一个命令。Ollama 在 Linux 下会自动检测 ROCm 环境只要驱动和 ROCm 库正常它就能把模型加载到 AMD GPU 上。安装命令可以直接从官网获取最新脚本一般是这样curl -fsSL https://ollama.com/install.sh | sh安装完成后启动服务ollama serve然后拉一个体积较小的模型做测试比如 7B 级别的 Qwen 模型ollama run qwen2.5:7b这里不要一上来就尝试跑几百 GB 的大模型先用小模型验证链路再逐步增加模型规模。4.2 设置环境变量并启动模型部分 AMD GPU 型号在新版本 ROCm 中可能没有被原生识别社区常用的一个临时解决方式是设置HSA_OVERRIDE_GFX_VERSION环境变量。比如对某些 RDNA3 架构显卡可以这样设置export HSA_OVERRIDE_GFX_VERSION11.0.0 ollama serveHSA_OVERRIDE_GFX_VERSION本来是为了让较新显卡能够兼容旧版 ROCm 而设计的它可以在驱动不识别时强制指定计算单元版本。但生产环境不建议随意使用因为它会改变编译器生成的指令集可能导致不稳定。启动模型时可以先观察日志。Ollama 会输出类似inference compute id 0的信息表示模型已经加载到 GPU。如果日志里出现 CPU 字样说明 GPU 没有生效。运行模型后可以用另外两个命令验证ollama ps watch -n1 rocm-smi --showmeminfo vramollama ps会列出当前已加载的模型和物理设备类型rocm-smi能实时显示显存使用情况。4.3 验证显存占用和推理速度当模型运行时rocm-smi的显存使用率会明显上升。如果显存没有变化大概率模型被 CPU 加载了需要回到环境变量和驱动层面排查。推理速度可以从响应时间来判断。如果一句话要等十几秒甚至更久可能是 GPU 未生效也可能是模型量化等级太高。更精确的做法是用ollama接口自行计时time curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话解释什么是显存 }多次执行取平均值能大致判断当前硬件是否正常发挥。如果首次加载慢不一定代表推理性能差因为模型权重需要从磁盘加载到显存之后第二次请求才会明显变快。5. 多卡推理与量化如何让 2.8T 参数模型装进 8 张卡5.1 按 Q4 量化估算 8 卡是否可以放下回到标题里的问题8 张 AMD 192GB 卡为什么能装下 2.8T 参数模型。下面做一个保守估算。假设 2.8T 参数模型使用 4bit 量化权重体积约 1.27 TiB。8 张 192GB 卡在十进制下总显存约 1.4 TiB按二进制约 1.28 TiB。看起来权重刚够放但推理时还有 KV Cache 和激活值。如果我们把上下文长度限制在 8K 到 16KKV Cache 可能控制在几十 GB 到一百多 GB。这意味着 8 卡方案“装得下”的前提是必须使用 4bit 或更低精度量化上下文长度不能开太大单次并发请求不能太多KV Cache 也要尽量量化或优化。所以“8 张 AMD 装下了”更准确的说法是“在显存容量按 INT4 推理配置规划时8 张 192GB 卡刚好放得下”。如果追求 FP8 精度8 张卡远远不够。5.2 张量并行与数据并行的取舍多卡推理不能简单把所有请求平均分发到每张卡上。对于超大单模型常用的是张量并行把模型的每一层切分成多块分别放在不同 GPU 上一次推理需要多卡协同完成。vLLM 的--tensor-parallel-size就是用来控制这个切分的。比如在 ROCm 版本的 vLLM 中启动一个量化后的模型python -m vllm.entrypoints.openai.api_server \ --model /path/to/quantized_model \ --tensor-parallel-size 8 \ --dtype bfloat16张量并行能解决“单卡放不下”的问题但代价是卡间通信开销。每做一次前向传播多张卡之间都要同步数据因此卡间互联带宽直接影响可扩展性。数据并行则适合并发请求高的场景每张卡放一份完整模型不同请求分发到不同卡。但数据并行有两个前提一是单卡显存必须能放下完整模型二是模型文件副本会占用多倍显存。对于 2.8T 参数模型这种方案基本上不现实。5.3 KV Cache 和上下文长度对显存的实际影响KV Cache 的大小和模型结构、上下文长度直接相关。一个简化的估算公式是KV Cache 大小 ≈ 2 × 层数 × KV 头数 × 头维度 × token 数 × 字节数公式里的 2 表示 key 和 value 各一份。不同模型的层数、头数差异很大因此 KV Cache 不能只靠参数量估算。例如某个 70B 模型当上下文长度从 4K 增加到 32K 时KV Cache 可能从几个 GB 涨到几十 GB。对 2.8T 参数的 MoE 模型来说即使 KV Cache 设计得比较高效长上下文依然会显著挤占显存。在多卡部署规划时建议先按最大上下文长度估算 KV Cache然后再决定 weight 部分能用多少显存。如果预留不足运行到一半会触发 OOM表现可能是进程崩溃、请求失败甚至显卡驱动复位。6. 从 NVIDIA 迁移到 AMD 最常见的五个坑6.1 驱动版本不匹配识别失败、卡死、Ollama 不加载 GPU最常见的现象是驱动装好了但rocm-smi什么都看不到或者 Ollama 日志里只有“no compatible GPUs”。原因通常是 ROCm 版本与内核版本 / GPU 架构不匹配。排查顺序运行rocminfo看是否报错。运行dmesg | grep -i amd看内核日志。确认 GPU 架构是否在 ROCm 支持列表里。解决方式一般是更换到官方推荐的 ROCm 版本或者升级内核。如果驱动一直不稳定可以尝试在 BIOS 中关闭快速启动避免 Windows 快速启动带来的硬件状态残留。6.2 PyTorch 的 CUDA 习惯在这里会失效从 NVIDIA 迁移过来的人最容易犯的错是用习惯了pip install torch然后在 AMD 上发现torch.cuda.is_available()一直返回 False。这不是代码问题而是安装的 PyTorch 是 CUDA 版本。AMD GPU 必须安装 ROCm 版 PyTorch。安装前先确认版本python -c import torch; print(torch.version.hip)如果输出为空说明当前 torch 不是 HIP/ROCm 版本。执行升级时不要混装最好在干净虚拟环境中重新安装。6.3 WSL2 里看不到显卡优先检查 /dev/kfdWSL2 和 Windows 驱动配合时GPU 设备会以虚拟文件形式暴露给 Linux。如果 WSL2 里执行ls /dev/kfd没有结果说明 Windows 侧驱动没有安装完整或者 WSL 版本太老。建议按顺序检查wsl --version ls -l /dev/kfd ls -l /dev/dri/render*如果/dev/dri/render*存在但/dev/kfd不存在说明 AMD GPU 的 WSL 支持没有启用。重新安装 AMD Adrenalin 驱动并通过wsl --shutdown重启 WSL2通常可以解决。6.4 “虚拟内存不足”和系统冻结其实是显存交换问题大模型推理时如果显存不够系统会把部分显存交换到主机内存。AMD GPU 的 GTT 机制允许这样做但当主机内存也被耗尽时Windows 就会报虚拟内存不足甚至出现界面卡死。解决思路不是关掉虚拟内存而是增大系统 swap 或页面文件降低模型量化等级减小上下文长度使用多卡分散显存。如果物理内存只有 64GB却想跑一个需要 120GB 显存的大模型主机内存大概率会成为瓶颈。生产环境建议显存容量和主机内存比例至少做到 1:1最好更充裕。6.5 双系统与 BIOS 设置对 AMD GPU 的影响很多开发者在同一台机器上装了 Windows 和 Linux 双系统。AMD 显卡在高性能场景下BIOS 里的几个选项会直接影响稳定性。推荐检查以下设置开启 Above 4G Decoding开启 Re-Size BAR Support如果多卡确认 PCIe 插槽速率是否为 x16 / x8关闭 Windows 快速启动避免 Linux 启动时硬件状态异常。这些设置不会提升单卡的上限但能避免很多莫名其妙的识别问题和卡死现象。如果你在 Linux 下加载 ROCm 驱动后频繁死机先把 Windows 快速启动关掉再试。下表总结了几个典型故障现象和排查方向现象常见原因检查方式处理建议rocm-smi找不到 GPUROCm 未安装或版本不匹配执行rocminfo安装匹配内核的 ROCm 版本PyTorch 不识别 GPU安装的是 CUDA 版 torch检查torch.version.hip安装 ROCm 版 PyTorchOllama 不加载 GPU驱动或环境变量问题查看/dev/kfd、Ollama 日志重装驱动、设置HSA_OVERRIDE_GFX_VERSION运行大模型时卡死显存交换到内存内存不足查看rocm-smi显存占用增大 swap、降低量化、减小上下文WSL2 看不到 GPUWindows 驱动缺少 WSL 支持ls /dev/kfd安装含 WSL 支持的 AMD 驱动7. 部署选型实践建议与检查清单7.1 学习环境与生产环境的分层建议学习环境重点是快速跑通链路。如果你只有一张 16GB 或 24GB 的 AMD 消费级显卡建议先跑 7B 到 14B 的量化模型。Ollama 是首选因为它对底层 ROCm 的封装足够简单能让你先确认驱动和推理链路没问题再深入底层。生产环境则要考虑稳定性和并发。建议使用 vLLM 或 SGLang 这类专门做服务化推理的框架它们对连续批处理、KV Cache 管理和多卡并行有更成熟的实现。生产环境建议至少做到配置外置化不把 ROCm 版本和模型路径写在脚本里记录 GPU 温度、显存使用率、请求延迟和失败率对量化模型做评测确认精度损失在可接受范围准备回滚方案例如保留上一版权重和旧驱动版本明确超时、重试和异常日志规范。对于 2.8T 参数这种级别即便用 8 张 AMD 卡量化部署运维复杂度也比普通模型高得多。不建议在没有完整监控体系的条件下直接上生产。7.2 部署前检查清单开始部署前可以按下面这个清单逐项检查GPU 型号和架构是否在 ROCm 支持列表中Linux 内核版本是否满足 ROCm 要求是安装完整 ROCm还是只需要运行时PyTorch 版本是否为 ROCm/HIP 版本模型量化精度是 FP16、FP8 还是 INT4最大上下文长度会占用多少 KV Cache主机内存和 swap 是否足够支撑显存交换Windows 快速启动是否关闭BIOS 是否开启 Above 4G Decoding 和 Re-Size BAR多卡通信协议是 PCIe 还是 Infinity Fabric带宽是否满足张量并行rocm-smi、rocminfo和torch.cuda.is_available()是否全部正常。这套清单不仅适用于 AMD 环境也适用于 NVIDIA。区别只在于 AMD 多了驱动版本和 ROCm 兼容性两个变量。7.3 下一步可以继续深挖的方向如果你看完这篇文章并且已经在 AMD GPU 上成功跑通了一个小模型下一步可以往三个方向深入第一量化方向。理解 GPTQ、AWQ、GGUF 的区别以及为什么 4bit 量化能大幅降低显存需求。第二推理框架方向。学习 vLLM 的张量并行、paged attention 和 continuous batching这些正是生产环境需要的机制。第三ROCm 调优方向。从rocminfo的架构信息出发了解HSA_OVERRIDE_GFX_VERSION的适用边界再逐步接触内核驱动日志和性能分析工具。超大模型部署从来不是单一硬件能解决的问题。你需要同时考虑模型结构、精度策略、显存容量、框架支持和运维成本。理解了这些变量之后再回看标题里的对比就不会简单得出“谁比谁强”的结论——更能看清“为什么 8 张 AMD 能装下而 16 张 B200 才能跑”背后的工程逻辑。