Kimi K3部署揭秘：16张B200与8张AMD大显存卡背后的显存与量化逻辑

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 + 中间激活，一张表算清

部署一个模型时，显存占用并不是只有模型权重这一项。完整来说，推理过程中的显存至少包括三部分：

1. 模型权重
2. KV Cache
3. 中间激活值和临时张量

模型权重是最固定的部分，只要模型加载完毕就常驻显存。KV Cache 是推理时为了复用历史 token 的 key 和 value 而保存的缓存，它随上下文长度增长。中间激活值则在每次 forward 过程中产生，虽然生命周期短，但峰值可能很高，尤其是 batch size 较大时。

如果只算权重部分，可以用一个很简单的公式：

显存占用（字节） = 参数量 × 每个参数需要的字节数

不同精度下，2.8T 参数模型的权重体积如下表：

注意这里用的是 TiB，1 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 TiB，4bit 量化后的 2.8T 参数权重约 1.27 TiB。如果不追求太长上下文、不把 KV Cache 开到极端值，理论上确实可以放进 8 张卡。这就是标题里“8 张 AMD 装下”的工程原因：不是 AMD 单卡比 B200 强，而是量化精度把显存需求压到了 8 卡容量以内。

2. 16 张 B200 和 8 张 AMD 多卡方案对比：不是简单的“A 胜 B”

2.1 从单卡显存开始算：B200 与 AMD 旗舰卡的规格差异

做硬件对比时，不能只看显存容量，还要看显存带宽、互联带宽、功耗和软件生态。下面表格列出了常见的两大类参数，实际采购时以官方规格书为准：

从单卡显存看，两者都是 192GB 这个级别。因此 16 张 B200 和 8 张 MI300X 的对比，本质上不是“单卡谁更强”，而是“总显存谁更多、软件优化谁更好”。

如果只比较显存总量，16 张 B200 显然更高，因为卡数多一倍。但大模型部署的另一个关键指标是单卡能否装下足够多的层和权重。8 张 192GB 和 16 张 192GB 的区别在于，前者需要让每张卡承担更多层数，通信压力更小；后者每张卡分到的层数少，但卡间通信路径更长。选择什么硬件，取决于模型切分方式和框架支持。

2.2 量化精度如何改变总显存需求

量化是让“8 张卡装下超大模型”成为可能的核心手段。它的原理很简单：原本用 2 个字节表示一个权重，现在用 4bit 甚至更少 bit 来表示，牺牲一定精度来换取更小的显存占用。

我们以 2.8T 参数为例，看看不同精度的总显存需求：

所以“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 本地部署大模型的准备工作：从驱动到 ROCm

3.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 rocminfo

rocm-smi能显示 GPU 温度、功耗、显存使用率；rocminfo能输出更详细的 GPU 架构信息。如果这两个命令能正确列出 AMD GPU，说明驱动层基本正常。

3.2 Windows 下通过 WSL2 使用 AMD GPU 的关键配置

很多开发者的主力机器是 Windows，但深度学习工具链在 Linux 下更顺手。AMD 提供了 WSL2 支持，也就是说在 Windows 上安装好 AMD 驱动，WSL2 内部可以直接使用 GPU。

首先确保 Windows 开启了 WSL2：

wsl --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 的 Ollama

Ollama 是目前最简单的本地模型运行时，它把模型下载、加载、推理接口封装成了一个命令。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_VERSION=11.0.0 ollama serve

HSA_OVERRIDE_GFX_VERSION本来是为了让较新显卡能够兼容旧版 ROCm 而设计的，它可以在驱动不识别时强制指定计算单元版本。但生产环境不建议随意使用，因为它会改变编译器生成的指令集，可能导致不稳定。

启动模型时，可以先观察日志。Ollama 会输出类似inference compute id 0的信息，表示模型已经加载到 GPU。如果日志里出现 CPU 字样，说明 GPU 没有生效。

运行模型后，可以用另外两个命令验证：

ollama ps watch -n1 rocm-smi --showmeminfo vram

ollama 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 到 16K，KV 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 架构不匹配。

排查顺序：

1. 运行rocminfo看是否报错。
2. 运行dmesg | grep -i amd看内核日志。
3. 确认 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/kfd

WSL2 和 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 快速启动关掉再试。

下表总结了几个典型故障现象和排查方向：

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 才能跑”背后的工程逻辑。