最近社区里关于“16 张 B200 才能跑的 Kimi K38 张 AMD 就装下了”这个说法聊得很多。单看标题很容易被理解成“AMD 比 NVIDIA 更强”或者“B200 不行”但实际上这种对比忽略了超大规模 MoE 模型本地化部署里的好几个关键变量参数规模、显存容量与带宽、量化精度、卡间互联、推理框架优化程度。本文不替任何厂商站台也不做硬件评测而是把这个话题拆开讲清楚超大规模模型部署到底该怎么估算硬件、怎么验证环境以及 AMD GPU 上跑推理时的常见坑。如果你最近也在关注 Kimi K3、B200 和 AMD 加速卡或者正在纠结本地部署大模型时该买什么卡、怎么把 Ollama 跑在 AMD GPU 上这篇文章可以从硬件评估到环境搭建给你一条比较完整的路径。1. 背景Kimi K3、B200 与 AMD 的讨论到底在聊什么1.1 Kimi K3 为什么值得关注Kimi 是月之暗面推出的大语言模型系列在社区讨论中Kimi K3 经常被描述为超大规模 MoE 模型有人提到参数量在 2.8T 级别。不过目前官方公开的技术细节有限本文不把重点放在“Kimi K3 到底有多少参数”上而是把它当作一个典型的超大规模 MoE 模型案例来分析硬件部署的通用思路。MoE也就是混合专家模型和传统 Dense 模型最大的区别在于模型的总参数量很大但每次推理只会激活其中一部分专家网络。这种设计看似省算力但有一个容易被忽略的点不管激活多少专家所有专家的权重在推理时都必须能被访问到。也就是说模型总参数越大权重占用的存储空间和显存空间就越大。如果 Kimi K3 真的是一个参数规模在 2.8T 级别的 MoE 模型按照最朴素的 FP16 权重来估算光权重就需要 5.6TB 显存空间。这还没算 KV Cache、激活值和推理框架自身的开销。这也是为什么“16 张 B200”这种数字会出现——单卡显存再大模型规模到了 TB 级别就必须靠多卡横向扩展。1.2 B200 与 AMD 加速卡的核心差异NVIDIA B200 是 Blackwell 架构的旗舰加速卡公开资料显示它配备 HBM3e 高带宽显存单卡显存达到 192GB 级别并且支持通过 NVLink 进行卡间高速互联。AMD 这边Instinct 系列的 MI300X 同样走大显存、高带宽路线公开规格是 192GB HBM3 显存后续的 MI325X 甚至把显存推到了 256GB 级别。对于大模型推理来说单纯比“算力”没有意义真正决定能不能跑起来的核心指标是两件事一是显存容量够不够装下模型权重二是显存带宽跟不跟得上推理时的数据读取。B200 和 AMD 旗舰卡在设计思路上其实很像都是通过堆显存容量和显存带宽来适配大模型场景区别主要体现在软件生态、互联架构和工程成熟度上。所以当有人问“B200 和 AMD 哪个好”时标准答案永远是先看你的模型规模、精度、并发和网络拓扑再谈具体型号。脱离模型的硬件对比基本都是在耍流氓。1.3 卡数并不等于显存容量回到“16 张 B200 才能跑8 张 AMD 就装下了”这个说法。如果不看单卡显存直接看卡数结论会非常误导人。假设 B200 是 192GB 显存16 张就是 3072GB约 3TB假设 AMD 卡是 192GB 显存8 张只有 1536GB约 1.5TB。在同样权重、同样精度的前提下总显存少一半却要装下同样的模型从物理上讲是不成立的。所以这个标题背后必然藏着几个被省略的变量常见的可能性包括AMD 那 8 张卡的单卡显存更大比如 256GB 甚至更高总显存反而更多。AMD 环境跑的是量化权重比如 INT4、INT8而 B200 环境跑的是 FP16 或 BF16 原始权重。AMD 环境使用了 CPU 或 NVMe offload把部分专家权重放在内存或硬盘里用的时候再加载。两边使用的推理框架、并行策略、KV Cache 优化方式不同。两者对比的根本不是同一份模型权重而是“理论可跑”和“工程可用”的区别。这类对比在社区里很常见但看的人一定要有拆解意识不要看卡数要先看总显存、总带宽、互联拓扑、精度和框架优化。这五个变量搞清楚你也能自己判断一个模型到底需要什么硬件。2. 本地化部署超大规模模型前先搞懂四个硬指标2.1 显存容量权重的“居住面积”显存容量是第一位的它决定了模型能不能被装进显卡。最基础的计算公式是权重显存占用 模型参数量 × 每个参数占用的字节数假设一个 70B 模型使用 FP16 精度每个参数占 2 字节那么权重占用大约是70 × 10^9 × 2 / 1024^3 ≈ 130.4GB也就是说70B 的 Dense 模型单卡 192GB 勉强能放权重但加上 KV Cache 和推理开销单卡压力会非常大。如果把精度降到 INT4每个参数只占 0.5 字节权重占用就降到 32GB 左右反而在消费级显卡上也能跑起来。下面这个 Python 脚本可以帮助你快速估算不同参数量和精度下的显存需求def estimate_vram_gb(param_billions, dtype_bytes, kv_cache_gb0, overhead_ratio0.1): 估算模型权重与基础 KV Cache 的显存占用。 - param_billions: 模型参数量单位十亿 - dtype_bytes: 每参数字节数FP16/BF16 为 2INT8 为 1INT4 为 0.5 - kv_cache_gb: 预估的 KV Cache 显存 - overhead_ratio: 推理框架运行时的额外开销比例 weight_gb param_billions * 1e9 * dtype_bytes / (1024 ** 3) total_gb weight_gb kv_cache_gb total_gb * (1 overhead_ratio) return weight_gb, total_gb for params in [7, 70, 100, 400, 2800]: weight, total estimate_vram_gb(params, 2, kv_cache_gb16) print(f{params}B 模型FP16 权重约 {weight:.1f}GB含 KV Cache 与开销后约 {total:.1f}GB)输出结果大致会告诉你一件事当模型规模到 2.8T 这种级别时FP16 权重已经接近 5.6TB任何单卡方案都不现实只能靠多卡并行和量化压缩来解决问题。2.2 显存带宽推理速度的“水管粗细”显存容量决定“能不能跑”显存带宽决定“跑多快”。大模型推理时模型权重需要源源不断地从显存搬运到计算单元尤其是自回归生成阶段每一步都要把全部激活参数读一遍。显存带宽越低token 生成速度越慢。这也是为什么只看“TFLOPS 算力”没有意义很多消费级显卡纸面算力很高但显存带宽只有几百 GB/s跑大模型时会被带宽死死卡住。B200 和 MI300X 这类加速卡之所以适合大模型核心优势之一就是显存带宽达到 TB/s 级别能够在单位时间内搬运更多权重。如果你在 AMD GPU 上跑模型时发现“显存占用很低但速度很慢”优先怀疑的不是显卡算力而是推理框架没有正确启用 GPU、权重被 offload 到内存或者显存带宽成为瓶颈。2.3 卡间互联多卡并行的“桥梁质量”当单卡显存放不下模型时多卡并行是必然选择。但多卡并行不等于把几块显卡插在一起就能线性扩展卡间通信效率直接决定并行后的实际效果。NVIDIA 的 NVLink 和 AMD 的 Infinity Fabric 都是为了解决多卡通信问题而存在的。多卡推理通常有两种模式张量并行和专家并行。张量并行会把每一层权重切分到多张卡上每一步计算都需要卡间同步通信量非常大专家并行则会把不同专家分布在不同的卡上只有路由到对应专家时才跨卡通信。MoE 模型天然适合专家并行这也是超大规模 MoE 模型可以在多卡集群上运行的底层原因。2.4 量化与 MoE省显存的两种关键路径量化是压缩模型显存占用的最直接手段。FP16 转 INT8显存直接减半FP16 转 INT4显存降到四分之一。代价是精度损失但现在的量化算法已经能让绝大多数场景在 INT4 下保持不错的效果。MoE 模型的结构优势则体现在计算量上虽然总参数多但每次推理只激活一部分专家实际计算量远小于同规模 Dense 模型。不过需要注意MoE 的“稀疏激活”节省的是算力并不直接节省显存。除非做更细粒度的调度否则所有专家的权重仍然需要放在显存或高速存储中。理解了这四点再回头看“16 张 B200 vs 8 张 AMD”的讨论你就会发现单纯看卡数是没意义的关键要看这个“装下了”是在什么精度、什么 offload 策略、什么并行方式下达成的。3. AMD GPU 本地推理环境搭建Ollama ROCm 路线如果说前两部分是“硬件评估思维”从这一节开始就是可以动手操作的内容。我们以 AMD GPU 上跑 Ollama 模型为例讲清楚从驱动到框架的完整流程。3.1 先确认你的 AMD GPU 是否被 ROCm 支持Ollama 在 AMD GPU 上的推理依赖 ROCm也就是 AMD 的 GPU 计算平台。不同显卡对应的 gfx 版本不同支持的成熟度也不同。数据中心加速卡如 MI300X 基本是官方支持的主力消费级 RDNA 系列显卡一部分能原生支持一部分需要设置环境变量兼容运行。在开始之前先确认显卡型号和系统信息。Linux 下可以运行lspci | grep -i amd如果输出里能看到VGA compatible controller: Advanced Micro Devices或者Display controller: Advanced Micro Devices说明系统已经识别到 AMD 显卡。3.2 Windows 用户通过 WSL2 使用 AMD GPU在 Windows 上使用 Ollama 调用 AMD GPU最常见的方案是 WSL2 加 Ubuntu 发行版。原因很简单ROCm 在 Linux 下的支持远比 Windows 原生环境成熟Ollama 在 WSL2 里可以更自然地访问 GPU。先在 PowerShell 中以管理员身份执行wsl --install wsl --set-default-version 2安装完成后默认会进入 Ubuntu 环境。然后你需要安装 AMD 官方提供的 Windows 驱动Adrenalin 驱动中已经包含了面向 WSL2 的 ROCm 支持组件。安装驱动后在 WSL2 里检查 GPU 设备节点是否存在ls -l /dev/kfd /dev/dri/renderD128如果能看到/dev/kfd和/dev/dri/renderD128说明 AMD GPU 已经成功透传进 WSL2 环境。3.3 Ubuntu 下安装 Ollama 并启用 GPUWSL2 环境准备好后在 Ubuntu 终端里安装 Ollama。官方提供了一个安装脚本执行curl -fsSL https://ollama.com/install.sh | sh安装完成后先启动 Ollama 服务ollama serve为了让 Ollama 明确使用某张 AMD GPU可以设置HIP_VISIBLE_DEVICES环境变量。比如系统里有多张卡只想使用第一张export HIP_VISIBLE_DEVICES0如果 Ollama 以 systemd 服务方式运行推荐在服务配置中集中写入环境变量。编辑/etc/systemd/system/ollama.service或使用 override 文件[Service] EnvironmentHIP_VISIBLE_DEVICES0 EnvironmentHSA_OVERRIDE_GFX_VERSION10.3.0保存后执行sudo systemctl daemon-reload sudo systemctl restart ollama注意HSA_OVERRIDE_GFX_VERSION不是所有显卡都需要只有 ROCm 运行时没有正确识别你的显卡 gfx target 时才建议使用而且具体值需要根据显卡架构来定。不确定的情况下不要随便加这个配置。3.4 用 Docker 运行 Ollama 并透传 AMD GPU如果你更习惯用 Docker 统一管理推理服务Ollama 官方提供了支持 ROCm 的镜像版本。在 Linux 主机上可以使用以下 compose 配置services: ollama: image: ollama/ollama:rocm container_name: ollama-amd devices: - /dev/kfd:/dev/kfd - /dev/dri:/dev/dri volumes: - ollama_data:/root/.ollama environment: - HIP_VISIBLE_DEVICES0 restart: unless-stopped volumes: ollama_data:然后启动docker compose up -d进入容器验证 GPU 是否可用docker exec -it ollama-amd bash rocm-smiMySQL 里我们用 docker compose 是常见操作但在 Windows Docker Desktop WSL2 环境下设备透传的兼容性会比 Linux 原生环境差一些。如果容器里看不到/dev/kfd更推荐放弃 Docker直接在 WSL2 里安装 Ollama先把流程跑通再考虑容器化。4. 在 AMD GPU 上运行模型并验证4.1 检查 GPU 是否被 Ollama 正确识别启动 Ollama 后拉取一个小模型做验证比直接跑大模型要稳妥得多。推荐用参数较小的模型验证环境连通性例如ollama pull llama3.2:3b拉取完成后运行ollama run llama3.2:3b进入交互界面后随意问一个问题比如“你好请介绍一下你自己”。此时打开另一个终端查看模型加载情况ollama ps如果模型被加载到 GPU输出里能看到PROCESSOR列显示类似100% GPU的信息如果显示100% CPU说明 Ollama 没有正确调用 AMD GPU。再用rocm-smi确认 GPU 负载rocm-smi正常运行时显卡的显存使用率和温度都会有明显上升。4.2 查看 Ollama 的运行时日志如果是通过命令行启动的ollama serve终端日志里会直接打印推理设备信息。例如inference compute id: gfx1100其中gfx1100就是 AMD 显卡对应的架构标识。如果日志里只有 CPU 相关输出说明 Ollama 没有找到 ROCm 设备需要回到第 3 节的驱动和设备节点检查步骤。使用 systemd 运行 Ollama 时可以通过下面的命令查看日志journalctl -u ollama -f日志是判断 GPU 是否真正参与推理的第一手信息排查问题时优先级很高。4.3 验证小模型后再考虑更大模型的部署单卡环境验证通过后再根据实际显存规划更大模型的部署方式。比如你有一张 24GB 的 AMD 显卡原生 FP16 跑 7B 模型比较吃力就可以尝试带量化版本的模型。Ollama 对量化模型的支持方式是在模型标签中指定量化参数例如拉取带 q4_K_M 量化的模型ollama pull llama3.2:3b-q4_K_M量化后的模型体积更小对显存压力更小虽然有一定精度损失但在本地调试和验证环境中完全够用。4.4 多卡环境下如何指定 GPU如果你手头有多张 AMD 显卡可以通过HIP_VISIBLE_DEVICES控制 Ollama 使用的显卡编号。编号顺序通常和系统里显卡的 PCI 总线顺序有关可以先运行rocm-smi查看当前机器的 GPU 编号再通过环境变量指定export HIP_VISIBLE_DEVICES1 ollama serve如果要实现多卡并行Ollama 的部分版本实现了自动多 GPU 调度但不同模型和不同版本行为不完全一致。实际工作中多卡并行通常要依赖 vLLM、SGLang 这类更专业的推理框架Ollama 更适合单机快速验证。5. AMD GPU 推理环境的常见问题与排查思路问题现象常见原因解决思路Ollama 日志显示找不到 GPUROCm 驱动未安装或设备节点缺失检查 /dev/kfd 与 /dev/dri/renderD128重装或更新驱动模型加载后 ollama ps 显示 100% CPU显卡架构不受 ROCm 支持设置 HSA_OVERRIDE_GFX_VERSION 或换用 Docker ROCm 镜像Docker 容器里无法访问 GPU/dev/kfd 未透传或容器缺少权限在 compose 中配置 devices 映射并确认宿主机设备存在AMD Software 安装报错 182驱动版本与显卡型号不匹配确认显卡型号下载对应版本驱动清理旧驱动后重装Crash Defender 提示显示驱动异常驱动崩溃、超频不稳定或系统更新冲突回退或更新驱动关闭超频检查系统日志定位原因VMware 报错不支持虚拟化 AMD V/RVI虚拟机未开启 AMD-V 虚拟化在 BIOS 中开启 SVM Mode检查 VMware 虚拟化引擎设置核显独显混用时 Ollama 使用核显默认设备选择错误通过 HIP_VISIBLE_DEVICES 指定独立 GPU 编号下面针对几个高频问题展开说明。5.1 Ollama 只使用 CPU不使用 AMD GPU这是 AMD GPU 推理环境里最常见的问题。第一优先级检查设备节点是否存在ls -l /dev/kfd /dev/dri/renderD128如果设备节点不存在说明驱动没装好先解决驱动问题。如果设备节点存在但 Ollama 仍走 CPU再看显卡架构是否被 ROCm 运行时识别。部分 RDNA 架构消费卡需要设置兼容环境变量但要先通过日志确认显卡的实际 gfx 编号再决定是否设置以及设置成什么值。5.2 AMD Software 安装报错“检测到不受支持的 AMD 图形硬件”这个错误常见于笔记本双显卡环境、虚拟机环境或者系统里残留了不匹配的旧驱动。排查思路如下先确认电脑里的 GPU 到底是什么型号桌面右下角任务管理器里能看到显卡列表。如果同时有核显和独显确认安装的是对应独显架构的驱动包。卸载现有 AMD 驱动建议进入安全模式用 DDU 清理干净。重新下载对应显卡型号和系统版本的驱动再进行安装。有时候错误出现在“驱动更新到一半”的场景尤其是系统大版本更新后旧的驱动组件残留会导致新驱动安装失败DDU 清理往往能解决。5.3 VMware 提示“此平台不支持虚拟化的 AMD V/RVI”这个报错通常不是因为驱动有问题而是虚拟化嵌套的问题。如果你在 VMware Workstation 里运行另一个虚拟机并且想在虚拟机里使用 GPU 或嵌套虚拟化功能需要在主板 BIOS 中开启 SVM Mode然后在 VMware 虚拟机的处理器设置中勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”选项。改完配置后关机重启而不是直接重启虚拟机否则设置可能不生效。6. 生产环境的硬件选型与工程建议6.1 根据模型规格反推卡数假设你要在私有环境部署一个 MoE 大模型最稳妥的做法是先列出公式所需总显存 模型权重 KV Cache 激活值 推理框架开销前面几项都可以估算框架开销一般预留 10% 到 20%。然后用“总显存需求 / 单卡可用显存”得到理论卡数。注意这里的“单卡可用显存”不等于单卡总显存因为推理框架和系统驱动本身会占用一部分显存实际可用容量通常是总容量的 90% 左右。同时要考虑是否需要做量化。如果允许 INT4 量化总显存需求会大幅下降这是目前很多团队用更少卡数跑更大模型的关键手段。6.2 NVIDIA 与 AMD 的选型维度生产环境选型时除了价格和显存容量还要考虑软件生态成熟度NVIDIA 的 CUDA 生态最成熟vLLM、TensorRT-LLM 等框架的支持最完整AMD 的 ROCm 这几年进步很快但个别框架和算子还有兼容性问题。显存容量与带宽如果模型规模极大优先看总显存和卡间带宽而不是单卡算力。互联架构NVLink 域与 Infinity Fabric 在多卡推理时的表现差异很大需要结合模型并行方式判断。功耗与机房改造高功耗加速卡不是装上就能用供电、散热、机房承重都需要评估。供应链和成本不同型号的采购周期、价格、售后都不相同要结合项目周期决策。6.3 数据安全与合法授权本地化部署大模型的很大一部分价值在于数据不出域。在内网或私有云环境中运行模型可以避免敏感数据上传到外部服务。但需要注意模型权重本身也有许可证和授权范围尤其是开源模型要仔细核对商用条款。部署过程中涉及抓包、性能压测、权限管理等操作时务必在已经获得授权的测试环境里进行遵循最小权限原则不要在生产环境直接做破坏性实验。6.4 工程化建议从工程角度看推荐先做以下四步先在单卡或小规模环境跑通环境再用小模型验证 Ollama、ROCm、Docker 全链路。明确量化等级和推理框架使用 vLLM 或 SGLang 做压测记录吞吐与延迟。把 GPU 监控、日志、模型版本管理纳入日常运维不要等到出问题再猜。对模型、驱动、推理框架都做好版本锁定避免升级引发兼容性问题。如果只是快速验证Ollama 非常方便如果要做稳定的线上服务vLLM 这类框架在并发、批处理和 KV Cache 管理上更专业。AMD GPU 环境下先确认所选框架是否支持当前 ROCm 版本和显卡架构再投入开发。7. 总结与下一步这篇文章从“16 张 B200 才能跑的 Kimi K38 张 AMD 就装下了”这个社区话题出发拆解了大模型本地化部署的核心判断方法不看卡数而是看总显存、显存带宽、卡间互联、量化精度和并行策略。然后以 AMD GPU 跑 Ollama 为例给出了从 WSL2、ROCm、Ollama 到 Docker 的完整环境搭建步骤并整理了常见报错的排查思路。下一步你可以先做两件事第一用自己手头的 AMD 显卡跑一个 3B 或 7B 模型把 Ollama 调用 GPU 的链路打通第二根据实际模型参数量用文中的显存估算脚本算一下不同精度下的卡数需求。等你对单卡流程足够熟悉再去研究 vLLM 的多卡并行和量化部署会顺手很多。最后提醒一句任何“某张卡能跑、某张卡不能跑”的结论都必须带着精度、框架、并行策略和显存总量去看否则很容易被标题数字带偏。如果你正在规划一台大模型推理服务器先算显存再谈卡数。