最近在折腾超大参数模型的本地部署Kimi K3 这个 2.8T 参数的 MoE 模型讨论度很高。看到“16 张 B200 才能跑8 张 AMD 就装下了”这个说法时我第一反应不是争论谁强谁弱而是想搞清楚背后的显存账到底怎么算。顺着这个问题我整理了从模型权重体积、量化策略、AMD GPU 的 ROCm/Ollama 部署链路到常见驱动与显存问题的完整实操笔记。这篇文章不只聊标题里的参数对比更希望帮你建立一套可复用的超大 MoE 模型本地部署与排错思路。1. 背景与核心概念1.1 Kimi K3 是什么为什么部署门槛高Kimi K3 是月之暗面推出的新一代大语言模型对外讨论最多的是它采用了MoEMixture of Experts混合专家架构总参数量达到 2.8T。MoE 架构的特点是虽然总参数非常多但每次推理只会激活其中一部分专家从而降低单次推理的计算量。这也是它能在效果和性能之间取得平衡的关键。但这并不意味着部署门槛变低了。一个很容易被忽略的事实是不管模型激活多少参数模型权重本身必须完整加载到显存或内存当中。Kimi K3 总参数 2.8T如果以 BF16 精度保存权重文件大小大约是2.8T * 2 Byte ≈ 5.6TB这个体积有多大NVIDIA B200 单卡 HBM3e 显存为 192GB16 张 B200 总显存约 3TB依然无法以 BF16 精度完整放下一份 5.6TB 的权重。因此“16 张 B200 才能跑”通常不是指裸权重全部装进显存而是指在特定量化精度、上下文长度、KV Cache 和激活值约束下16 张 B200 的总显存能满足端到端推理需求。换句话说本地部署大模型的瓶颈首先是显存容量其次才是算力和带宽。理解这一点就理解了 Kimi K3 这类超大 MoE 模型“吃硬件”的本质。1.2 B200 与 AMD 旗舰加速卡的差异为了讲清楚“8 张 AMD 就装下了”这个说法我们需要对比几个常见加速卡的显存规格。注意这里对比的是当前已经发布或广泛讨论的加速卡具体型号和显存容量可能随产品迭代变化。加速卡显存类型单卡显存8 卡总显存16 卡总显存NVIDIA A100HBM2e80GB640GB1.28TBNVIDIA H100HBM380GB640GB1.28TBNVIDIA B200HBM3e192GB1.5TB3TBAMD MI300XHBM3192GB1.5TB3TBAMD MI325XHBM3e256GB2TB4TB从表格中可以看到单看总显存8 张 AMD MI325X2TB已经接近 16 张 B2003TB的三分之二如果配合 4bit 量化Kimi K3 权重可以压缩到约 1.4TB再加上 KV Cache 和激活值8 张 AMD 大显存卡确实有机会在单机内跑起来。而 16 张 B200 的方案更多是为了保留更高精度、更长上下文或更大并发而不是单纯因为“装不下”。所以标题里的说法并不是简单的“AMD 比 NVIDIA 强”而是显存容量、量化策略、模型架构共同作用的结果。这篇文章后续的实战部分会围绕 AMD GPU 的部署链路展开。2. 环境准备与版本说明在开始部署之前先明确实验环境。Kimi K3 这类 2.8T 参数模型普通单卡 RTX 4090 是跑不起来的至少需要多卡服务器级别 GPU。下面以 AMD MI300X 多卡环境为例同时也会提到消费级 AMD 显卡的注意事项。2.1 硬件环境服务器2U/4U 多卡 GPU 服务器至少 8 张 AMD MI300X 或 MI325XCPU支持 PCIe 5.0 的服务器 CPU如 AMD EPYC 9004 系列内存至少 512GB推荐 1TB 以上用于 CPU offload 和 KV Cache 缓冲硬盘NVMe SSD建议预留 2TB 以上空间存放模型权重如果你的环境只有一块 AMD 消费级显卡如 RX 7900 XTX24GB可以先用小规模 MoE 模型验证 ROCm 和 Ollama 是否正常工作再根据显存情况评估是否能运行量化后的超大模型。2.2 软件环境操作系统Ubuntu 22.04 LTS服务器推荐或 Windows 11 WSL2GPU 驱动AMD ROCm 6.x 及以上版本推理框架Ollama 最新版或 vLLMROCm 版本容器Docker ROCm 容器镜像rocm/pytorchPython3.10 或更高版本vLLM 需要由于 AMD 的 ROCm 版本和内核驱动迭代很快这里不写死具体版本号。实际部署时请以官方文档和当前系统环境为准。2.3 验证显卡是否被系统识别安装好系统后先用两条命令确认 AMD GPU 是否被正确识别。# 查看 PCIe 设备中的 AMD 显卡 lspci | grep -i amd # 查看 ROCm 是否能枚举到 GPU rocm-smi正常情况下rocm-smi会列出每张显卡的型号、温度、显存使用量等信息。如果这里无法识别后面的推理框架也大概率用不了 GPU。3. 核心原理显存占用到底怎么算很多人把“模型能不能跑”简单等同于“显存够不够装权重”但实际部署过程中显存占用由四部分组成缺一不可。3.1 模型权重体积这是最基础的部分。不同精度下参数量与显存占用关系如下BF16/FP161 个参数占 2 字节2.8T 参数约 5.6TBINT81 个参数占 1 字节2.8T 参数约 2.8TBINT4/NF41 个参数占 0.5 字节2.8T 参数约 1.4TB量化是降低权重大小的最直接手段。但量化不是无损的尤其对 MoE 模型专家层的精度敏感性需要单独评估。简单说每降低一档位精度显存需求几乎减半但推理效果可能下降。3.2 KV Cache自回归模型在推理时要缓存历史 token 的 Key 和 Value这个缓存叫 KV Cache。它的体积和序列长度、层数、注意力头数、batch size 都有关系。Kimi K3 这类支持超长上下文的模型如果上下文长度设置为 128K 甚至 256KKV Cache 会非常可观。即使权重量化到 1.4TBKV Cache 也可能需要数百 GB 显存。因此部署时需要根据业务场景动态调整max-model-len参数而不是一味追求长上下文。3.3 激活值推理过程中中间层的激活值也会占用显存。虽然 MoE 每次只激活部分专家但 attention 部分的激活值依然和序列长度、batch size 强相关。在长上下文场景激活值可能成为显存瓶颈。3.4 为什么“8 张 AMD 就装下了”成立我们做一个粗略估算。假设使用 8 张 AMD MI325X单卡 256GB总显存 2TB。Kimi K3 权重用 INT4 量化后约 1.4TB剩余约 600GB 空间给 KV Cache 和激活值。对于单用户、中等上下文32K、batch size1 的推理场景600GB 是够用的。而 16 张 B200 总显存 3TB如果同样使用 INT4 量化它能以更高精度比如 FP8运行同一模型或者支持更大的 batch size 和更长的上下文。所以“16 张 B200 才能跑”更像一种保守配置“8 张 AMD 就装下了”则是量化与显存容量博弈后的结果。理解这层关系后我们就可以开始部署实操了。4. 在 AMD GPU 上部署 Kimi K3 的完整实战接下来进入实操环节。由于 Kimi K3 可能存在不同开放程度我会以通用 MoE 大模型的部署流程为例覆盖 Ollama 和 vLLM 两条路线。如果你手上的模型是 GGUF 格式用 Ollama 更简单如果是 Safetensors 权重建议走 vLLM。4.1 安装 ROCm 运行环境在 Ubuntu 22.04 上安装 ROCm 有多种方式最常见的是通过 AMD 官方 apt 仓库安装。下面是一个典型流程具体版本号以官方文档为准。# 更新系统 sudo apt update sudo apt upgrade -y # 安装基础编译工具 sudo apt install -y wget gnupg # 添加 ROCm apt 仓库并安装此处以 6.x 为例 wget https://repo.radeon.com/amdgpu-install/6.2.3/ubuntu/jammy/amdgpu-install_6.2.60303-1_all.deb sudo dpkg -i amdgpu-install_*.deb sudo amdgpu-install --usecaserocm安装完成后执行rocm-smi确认 GPU 可见。如果系统里有多个 AMD GPU你会看到类似下面这样的输出 ROCm System Management Interface GPU Temp AvgPwr SCLK MCLK Fan Perf PwrCap VRAM% GPU% 0 45.0c 120.0W 1500Mhz 1000Mhz 20% auto 300.0W 0% 0% 1 44.0c 118.0W 1500Mhz 1000Mhz 20% auto 300.0W 0% 0%只有看到 GPU 列表才能继续后续步骤。4.2 通过 Docker 使用 AMD GPU多卡环境下Docker 可以很好地隔离依赖。AMD 官方提供了rocm/pytorch镜像我们可以基于它运行 Ollama 或 vLLM。# 拉取 ROCm 版 PyTorch 镜像 docker pull rocm/pytorch:latest # 运行容器并挂载 GPU docker run -it --name k3-deploy \ --device/dev/kfd --device/dev/dri \ --group-addvideo --ipchost --cap-addSYS_PTRACE \ --security-opt seccompunconfined \ -v /data/models:/models \ rocm/pytorch:latest bash参数说明--device/dev/kfd和--device/dev/dri把 AMD GPU 设备节点映射进容器。--group-addvideo视频用户组权限ROCm 运行需要。--ipchost共享内存多卡通信时更稳定。-v /data/models:/models把宿主机模型目录映射到容器方便管理权重。进入容器后先确认 GPU 可用python3 -c import torch; print(torch.cuda.is_available())在 ROCm 环境下torch.cuda.is_available()也会返回True因为 ROCm 的 PyTorch 构建会兼容 CUDA API 调用。如果返回False说明 ROCm 安装有问题需要回到上一步排查。4.3 使用 Ollama 导入 GGUF 权重Ollama 对 AMD GPU 的支持已经越来越完善。如果是 GGUF 格式的 Kimi K3 权重可以利用 Ollama 的 Modelfile 机制快速部署。首先安装 Ollama。Linux 下可以使用官方脚本curl -fsSL https://ollama.com/install.sh | sh安装完成后启动 Ollama 服务systemctl start ollama systemctl enable ollama接着创建模型。假设我们已经把 Kimi K3 的 GGUF 文件下载到/data/models/kimi-k3-q4_k_m.gguf然后写一个 Modelfile# 文件路径/data/models/Modelfile.kimi-k3 FROM /data/models/kimi-k3-q4_k_m.gguf # 可选设置上下文长度 PARAMETER num_ctx 32768 # 可选设置温度等生成参数 PARAMETER temperature 0.6通过 Ollama 创建并运行模型cd /data/models ollama create kimi-k3 -f Modelfile.kimi-k3 # 查看模型是否创建成功 ollama list # 启动交互式对话 ollama run kimi-k3 你好请简单介绍你自己如果一切正常Ollama 会加载模型到 GPU 显存并开始对话。可以通过另一个终端查看显存占用ollama ps输出会显示模型名称、已用显存、处理器类型GPU/CPU等信息。4.4 使用 vLLM 部署 Safetensors 权重如果 Kimi K3 开放的是 Safetensors 权重推荐使用 vLLM 进行部署。vLLM 支持张量并行tensor parallelism能够把模型权重切分到多张 GPU 上。先安装 ROCm 版 vLLM。由于 vLLM 的 ROCm 安装方式会随版本变化这里给出一个常见命令pip install vllm如果安装后无法识别 AMD GPU可以尝试从源码安装或者使用官方 ROCm Docker 镜像。启动 OpenAI 兼容 API 服务的命令如下python -m vllm.entrypoints.openai.api_server \ --model /data/models/kimi-k3 \ --tensor-parallel-size 8 \ --dtype float16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.95参数说明--tensor-parallel-size 8使用 8 张 GPU 并行切分模型。--dtype float16以半精度加载权重。如果显存不足可改为--quantization awq或--quantization gptq。--max-model-len 32768最大序列长度。长上下文会增加 KV Cache 占用先设置 32K 起步。--gpu-memory-utilization 0.95允许使用 95% 的显存预留一部分给 CUDA context。启动后服务默认监听http://localhost:8000。我们可以用curl做一个简单验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/kimi-k3, messages: [{role: user, content: 你好介绍一下 MoE 架构}], max_tokens: 512 }如果返回正常的 JSON 响应说明部署成功。4.5 运行与验证无论使用 Ollama 还是 vLLM都需要关注两个核心指标是否使用了 GPU 而不是 CPU 兜底显存占用是否在合理范围内在 Ollama 中用ollama ps查看。在 vLLM 中服务启动日志会打印每张 GPU 的显存占用和模型加载情况。还可以用rocm-smi实时查看所有 GPU 的利用率。watch -n 1 rocm-smi通过watch每秒刷新一次可以清晰看到多卡推理时各 GPU 的负载是否均衡。正常情况下8 张卡的显存占用和利用率应该比较接近差异过大则说明张量并行切分不均匀。5. 常见问题与排查思路AMD GPU 部署大模型的坑很多不在模型本身而在驱动、容器和推理框架的兼容性。下面列出几个高频问题。问题现象常见原因解决思路rocm-smi看不到 GPU驱动未安装或内核模块未加载重装 ROCm确认重启后 lsmodOllama 无法识别 AMD GPU未安装 ROCm或 GPU 架构不在支持列表安装 ROCm设置HSA_OVERRIDE_GFX_VERSION绕过架构检查Docker 容器内无法访问 GPU缺少设备映射或用户组权限添加--device/dev/kfd --device/dev/dri --group-addvideovLLM 启动报显存不足上下文过长或并行切分不合理调低--max-model-len或使用量化模型WSL2 中 Ollama 无法使用 AMD GPUWSL2 不支持直接透传所有 AMD 设备在 WSL2 中使用 Windows 版 Ollama或安装 AMD WSL 驱动Windows 下 AMD Software 提示驱动问题驱动版本与系统冲突升级或回退驱动关闭 Crash Defender 误报检测AMD Software 检测到不受支持的图形硬件老的显卡被新驱动移出支持列表安装对应老版本驱动或使用开源驱动这里单独说一下HSA_OVERRIDE_GFX_VERSION。有些 AMD 消费级显卡的架构版本未被 Ollama 或 PyTorch 默认支持需要手动指定一个相近的 gfx 版本才能加载。比如 RX 7900 XTX 的用户有时需要设置export HSA_OVERRIDE_GFX_VERSION11.0.0但要注意这个环境变量只适用于兼容性验证不推荐在生产环境长期使用。它会绕过硬件能力检测可能导致内核态驱动不稳定。另一个容易出现的问题是多卡通信。在纯 PCIe 环境下8 卡张量并行的通信开销很大推理速度可能不升反降。AMD 的服务器级 GPU 通常支持 Infinity Fabric 或 PCIe Switch实际部署时需要用rocm-smi或amd-smi检查拓扑尽量把同一块 CPU 下的 GPU 分到一组。6. 最佳实践与工程建议在 AMD GPU 上部署超大 MoE 模型除了“能跑”还要考虑稳定性、性能和安全性。这里分享几条工程实践经验。6.1 先做单卡小规模验证不要一上来就在 8 卡环境跑 Kimi K3。先用一张卡加载一个 1B 或 7B 的小模型验证 ROCm、Ollama/vLLM、Docker 链路是否全部正常。确认无误后再切换到多卡环境。这样能快速定位问题。6.2 统一模型目录管理多份量化权重MoE 模型的量化版本可能很多比如 Q4_K_M、Q5_K_M、Q8_0 等。建议按模型名和量化方式分目录存放/data/models/kimi-k3/ ├── original/ │ ├── config.json │ ├── model.safetensors │ └── tokenizer.json ├── quantized/ │ ├── kimi-k3-q4_k_m.gguf │ └── kimi-k3-q8_0.gguf这样在 Ollama 的 Modelfile 和 vLLM 的命令行参数中路径一目了然也方便版本回退。6.3 显存监控与告警8 卡服务器的显存、温度和功耗直接影响推理稳定性。建议使用rocm-smi --showuse --showtemp --showpower定期采样或接入 Prometheus Grafana 监控。至少也要在启动服务前确认风扇散热正常避免长时间峰值负载导致降频。6.4 量化选择要结合任务验证不是所有任务都能接受 INT4 精度。代码生成、数学推理等任务对精度更敏感建议先用 Q8 或 FP8 跑一批业务测试样本比较结果后再决定是否降低量化级别。如果效果差距在可接受范围内再选用 INT4 换取显存空间。6.5 注意 API 服务安全使用 vLLM 启动 OpenAI 兼容 API 后默认没有鉴权。如果服务器有公网 IP必须加一层反向代理和 Token 校验。最简单的做法是在本地监听内网访问通过 Nginx 转发并配置Authorization校验。生产环境不建议直接把 8000 端口暴露到外网。# /etc/nginx/sites-available/kimi-k3 server { listen 8001; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header Authorization $http_authorization; } }同时在 vLLM 启动参数中加上 API Key 校验如果版本支持或者通过 Nginx 层校验。这样可以避免模型被未授权调用。6.6 多卡并行时先检查互联拓扑大模型张量并行需要高频通信。如果 8 张卡分布在不同的 PCIe Switch 域通信延迟会明显增加。建议在部署前用以下命令查看 GPU 拓扑rocm-smi --showtopo把通信频繁的 GPU 组限制在同一个 NUMA 节点下通常能减少跨节点通信瓶颈。如果条件允许优先选择支持 AMD Infinity Fabric 的机型和主板。7. 总结与后续学习回到最初的问题“16 张 B200 才能跑的 Kimi K38 张 AMD 就装下了”。这个说法的本质是显存容量和量化策略的组合结果。Kimi K3 的 2.8T 参数决定了它必然需要 TB 级显存16 张 B200 提供了更充裕的 3TB 总显存而 8 张 AMD MI325X 在 2TB 总显存配合 4bit 量化的情况下也能满足单用户推理需求。这篇文章从显存计算、环境准备、Ollama/vLLM 部署、常见问题到工程实践覆盖了一套完整的 AMD GPU 超大 MoE 模型部署流程。如果你正在计划部署 Kimi K3 或类似规模的模型最关键的不是纠结哪家 GPU 更便宜而是先明确自己的业务场景需要多长上下文并发量多少允许什么精度这些参数直接决定你需要几卡、什么卡。接下来可以继续深入研究 ROCm 的多卡通信优化、MoE 模型的 KV Cache 缓存机制以及 AWQ/GPTQ 等量化算法对推理效果的具体影响。我在折腾过程中也踩了不少坑欢迎在评论区交流你的部署配置和遇到的问题。