企业官网建设流程全解析

最近社区里流传一个说法：Kimi K3 这种超大模型，用 16 张 NVIDIA B200 才能部署，换成 AMD 显卡方案，8 张就装下了。这个说法大概率被简化了，但它引出的问题很实在：大模型本地部署到底在比什么，为什么 AMD 也能成为一条路线，驱动、推理框架、多卡并行又该怎么配。

如果你的关注点是“我手头有 AMD 显卡，想把大模型真正跑起来”，那这篇文章比单纯争论“Kimi K3 到底要几张卡”更有用。下面按实际部署顺序来拆：先算资源账，再过环境关，然后给一套可复现的流程，最后讲参数、边界和排查。

1. 先算账：16张B200和8张AMD到底在比什么

1.1 模型权重、KV cache 和推理引擎都在占显存

很多人看到“16 张 B200”会下意识觉得是 GPU 算力不够，其实更准确的说法是显存容量不够。大模型部署时，显存不是只装一份模型权重就完了，至少有三块开销：

• 模型权重：参数数量乘以每个参数占用的字节数。
• KV cache：生成过程中缓存的 Key 和 Value，跟序列长度、batch size、注意力头数直接相关。
• 推理引擎预留：CUDA/ROCm 上下文、激活值、临时缓冲区、碎片空间。

如果 Kimi K3 这类模型体量很大，FP16 精度下权重就可能需要数 TB 显存。这个量级放到单卡上肯定放不下，所以需要多卡把权重分片，再把 KV cache 也分散到各卡。B200 方案用 16 张，本质上是显存总量和卡间通信都被纳入考量。

AMD 方案说“8 张就装下了”，看起来是数量减半，但真正决定结果的是单卡显存、量化等级和推理框架。如果 8 张 AMD 专业卡单卡显存比 B200 更大，或者权重使用了 INT4/INT8 量化，那确实有可能在更少卡数下塞进同一个模型。

1.2 单卡显存、多卡互联与量化是三个独立变量

这里要把三个变量分开看：

• 单卡显存决定单卡能放多大分片。
• 多卡互联决定张量并行时通信是否成为瓶颈。
• 量化等级决定同样参数量的模型实际占用多少字节。

NVIDIA B200 系列属于高端加速卡，单卡显存和带宽都很强，但价格和供货也是门槛。AMD 的专业加速卡单卡显存也做到了很高水平，甚至有消费级和半专业卡通过统一内存访问系统内存。也就是说，如果只看“能不能把权重加载进去”，AMD 多卡方案在容量上的确有竞争力。

但“装下”不等于“跑好”。多卡之间如果走 PCIe 而不是高速互连，张量并行时的通信开销会明显拉低速度。这一点在 8 卡场景下尤其明显。所以标题里的说法，更适合理解为“容量上可能成立，性能上需要实测”。

1.3 为什么社区会认真讨论 AMD 方案

社区讨论 AMD 方案，不是因为 AMD 全面超过了 NVIDIA，而是因为大模型部署的成本敏感度变高了。很多开发者在寻找“显存大、单卡容量高、相对容易获得”的替代硬件。

同时，AMD 的软件栈比前几年完整了不少。ROCm 逐步覆盖推理场景，Ollama、vLLM、llama.cpp 对 AMD GPU 的支持也在推进。于是“16 张 B200 才能跑的模型，8 张 AMD 就装下了”这种话题就有了讨论土壤。

我个人的看法是：不要被“8 张”这种数字带偏。真正要验证的是你自己的显卡型号、驱动版本、量化格式和推理框架能不能协同工作。

2. AMD本地部署首先要过三关：驱动、框架、调用方式

2.1 ROCm 是 AMD GPU 跑 PyTorch 和 vLLM 的基础

AMD GPU 在 Linux 和 WSL2 下跑深度学习，主要依赖 ROCm。你可以把 ROCm 理解为 AMD 版的 CUDA 生态，包含了运行时、编译器、通信库和性能分析工具。

先要确认显卡是否受 ROCm 支持。这个不是所有 AMD 显卡都默认支持，尤其一些老卡和低端卡可能不在官方支持列表里。检查方法很直接：

rocminfo rocm-smi

rocminfo能列出 GPU 的 agent 信息，rocm-smi能查看当前 GPU 温度、频率、显存占用。如果这两个命令都看不到你的显卡，后面跑模型大概率也认不到 GPU。

还要注意驱动和 ROCm 版本的匹配问题。驱动不是越新越好，而是要跟 ROCm、PyTorch 的版本匹配。经常会遇到的情况是：显卡能用，但要跑某个新框架，必须升级到新版本 ROCm；一升级，系统里原来的 PyTorch 又对不上了。

2.2 推理框架选型：Ollama、vLLM 还是 llama.cpp

AMD GPU 上没有统一的“一键运行”工具，你得先选推理框架。

• Ollama：适合个人测试和快速体验，安装简单，但多卡调度和精度控制能力弱。
• vLLM：适合服务化部署，支持高并发、多卡张量并行，但对 ROCm 版本和显卡型号有要求。
• llama.cpp：适合量化 GGUF 模型，CPU/GPU 混合跑的玩法多，也能用 ROCm 后端。

如果你只是想把 Kimi K3 的量化版本跑起来看效果，Ollama 是最快的路径。如果你想做接口服务，或者让 8 张卡真正协同工作，vLLM 更合适。

选择依据不是“哪个流行”，而是你的最终使用场景。个人自测和内部工具，可以用 Ollama；要面向多人提供接口，建议直接上 vLLM。

2.3 Windows 用户先配好 WSL2，再谈 AMD GPU 调用

很多开发者的主力机器是 Windows，但 AMD 的深度学习生态在 Linux 下更完整。比较省事的方案是 Windows 侧装 WSL2，在 WSL2 里安装 Ubuntu，然后让 Windows 侧驱动把 GPU 透传给 Linux 子系统。

这样做的原因是：WSL2 中的 GPU 驱动由 Windows 侧统一管理，Linux 侧不需要再单独安装一套复杂驱动。AMD 新版驱动普遍已经支持 WSL2 的 DirectML 和 ROCm 路径。

基本流程：

# Windows PowerShell 管理员 wsl --install # 安装完成后进入 WSL2 wsl # 更新系统 sudo apt update && sudo apt upgrade -y

进入 WSL2 后，先执行rocminfo看 GPU 是否出现。如果看不到，优先检查 Windows 侧 AMD 驱动是否更新到支持 WSL2 的版本。这里最容易踩的坑是：Windows 驱动很旧，Linux 侧装再多 ROCm 组件也白搭。

也有很多人选择直接安装 Windows 和 Linux 双系统。好处是性能更直接，坏处是切换麻烦，驱动问题被放大。我的建议是先用 WSL2 跑通验证链路，再决定要不要上双系统。

3. 从单卡到八卡：一套能复现的部署流程

3.1 先用 7B/8B 小模型把链路跑通

第一次就在 8 张 AMD 卡上加载一个超大模型，风险很高。你分不清是权重没下全、量化格式不受支持、驱动有问题，还是并行配置写错。所以第一步永远是先跑小模型。

以 Ollama 为例：

ollama run qwen3:8b

在 AMD GPU 环境下，Ollama 如果配置正确，会在加载模型时打印 GPU 调用信息。你可以另开一个终端查看资源占用：

rocm-smi

如果rocm-smi里能明显看到 GPU 使用率上升，说明 ROCm、驱动、Ollama 这条路已经通了。这里要强调：不要只看程序不报错，还要看 GPU 是否真的在干活。

我一般会先跑一个长一点的 prompt，比如让模型写 2000 字内容，观察 GPU 利用率和耗时不至于在短文本上误判。

3.2 准备 Kimi K3 的权重与量化版本

跑通小模型后，再去准备 Kimi K3 的权重。大模型有几种形态：

• 原版权重：精度高，但体积大，对显存和部署环境要求高。
• 量化权重：如 GGUF、AWQ、GPTQ，体积小，加载快，适合本地部署。

如果标题里的“8 张 AMD 就装下了”成立，多半是因为使用了量化权重，而不是把原始精度完整装进显存。这里有个容易误解的点：量化后的模型还是同一个模型，但参数字节数下降了，显存占用自然变少。

下载模型建议先看文件体积和 SHA 校验信息。很多部署失败不是代码问题，而是模型权重下载不完整。对于超大模型，还要看是单个文件还是分片文件，目录结构是否符合推理框架要求。

如果你的模型文件是以 Hugging Face 格式存在，可以用 vLLM 或 Transformers 直接加载；如果只有 GGUF 格式，就需要用 llama.cpp 或支持 GGUF 的框架。

3.3 多卡并行启动 vLLM

要真正利用 8 张 AMD 卡，推荐用 vLLM 的张量并行。启动命令大致如下：

vllm serve /path/to/kimi-k3 \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --dtype float16

参数含义：

• --tensor-parallel-size 8：把模型按层内张量切分到 8 张卡上。
• --max-model-len 8192：限制最大序列长度，影响 KV cache 占用。
• --gpu-memory-utilization 0.9：限制开发框架最多使用 90% 显存，避免碎片导致 OOM。
• --dtype float16：指定推理精度，如果你的权重是量化格式，需要按框架要求调整。

为什么要从tensor-parallel-size 8而不是默认单卡开始？因为如果你不指定，vLLM 会把整个模型尝试加载到单卡上，超大规模模型会在加载阶段直接 OOM。

但这里也有个坑：8 卡张量并行对卡间通信要求很高。如果八张卡之间的连接走 PCIe，通信开销可能让速度比单卡更低。第一次跑建议先改成--tensor-parallel-size 2，看看两张卡能不能正常协作，再逐步扩展到 4 张、8 张。

3.4 验证输出和显存占用

服务启动后，不要只看“Web UI 能打开”就认为成功。真正要确认的是三层：

• 请求能不能正常返回内容。
• 输出质量是否符合预期。
• 显存占用是否在稳定区间，而不是缓慢上涨到 OOM。

可以用命令行接口简单测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"kimi-k3","messages":[{"role":"user","content":"你好"}],"max_tokens":128}'

同时在另一个终端观察：

rocm-smi --showmeminfo vram

如果vram使用率已经接近 100%，但程序还在生成新 token，说明显存可能一直处于危险水位。此时优先调低--max-model-len或--gpu-memory-utilization，而不是继续加压。

4. 参数怎么定，显存会不会爆，性能怎么判断

4.1 显存占用估算公式

大模型显存占用没有一个万能数字，但可以按公式做粗估：

• 权重显存 = 参数量 × 每参数字节数。
• KV cache 显存 = 层数 × 注意力头数 × 头维度 × 序列长度 × batch size × 2 × 每元素字节数。
• 推理预留 = 通常额外留 10% 到 20%。

举例：如果模型有 100B 参数，FP16 精度下权重大约需要 200GB。这还没算 KV cache，就已经超过很多单卡显存了。如果使用 INT8，权重变成 100GB；INT4 则约 50GB。这就是为什么量化是目前本地部署超大模型的必经之路。

但要注意：量化模型在推理时，某些算子可能仍然需要反量化到更高精度，导致实际显存比理论值高。所以不要卡着理论值去分配显存，至少留 10% 余量。

4.2 量化精度怎么选

量化精度直接影响显存占用和输出质量。常见选择如下：

如果第一次跑只是为了验证“8 张 AMD 能不能装下”，可以先试 INT4 版本。跑通后如果发现回答质量下降明显，再尝试 INT8 或 FP8。

不建议一上来就追求 FP16 原版权重。原因很简单：加载时间、显存占用、OOM 概率都会变高，而排查难度也变大。先用小模型确认环境，再用低精度大模型验证容量，最后再提升精度，是最稳的顺序。

4.3 并发、吞吐和稳定性判断

部署完之后，除了“能聊”，还要看能不能稳定服务。几个常用指标：

• 单请求时延：从发请求到首 token 返回的时间。
• 生成吞吐：每秒生成多少个 token。
• 并发请求数：同时向服务发请求的数量。
• 失败率：返回 500、超时、OOM 的比例。

其中 KV cache 和并发直接相关。并发越高，KV cache 占用越大。很多人部署时单请求没问题，一开并发就 OOM，就是没给并发预留 KV cache 空间。

我建议把并发压力测试放到最后做，而不是一开始就并发 32 路。先手动连续发 10 个请求，看显存曲线；再把并发从 4 调到 8、16，观察恢复时间。如果显存长时间不释放，就要检查框架是否限制了最大并发数。

5. 常见卡死、报错与排查顺序

5.1 GPU 识别不到：先看驱动和 ROCm

如果rocm-smi没有输出，或者rocminfo找不到 GPU，最优先检查的是驱动，不是代码。

排查顺序：

1. 显卡型号是否在 ROCm 支持列表里。
2. Windows 侧驱动是否更新到支持 WSL2 的版本。
3. Linux/WSL2 里是否安装了 ROCm 基础组件。
4. 是否插了多张卡但 BIOS 没有正确启用。
5. 是否有另一个进程占住了 GPU 设备。

如果是老显卡，很可能会遇到“AMD software 安装程序检测到不受支持的 AMD 图形硬件”之类的提示。这不是模型代码的问题，而是显卡本身不在当前驱动或 ROCm 支持范围内。这时候不要硬装新驱动，先查官方支持列表。

5.2 Ollama 不调用 AMD GPU：看日志和 GPU 可见性变量

Ollama 在 AMD GPU 上最常见的问题是“安装了，但默认跑 CPU”。你需要确认几件事：

• 安装的是支持 ROCm 的版本。
• 系统里能看到 ROCm 相关环境变量。
• Ollama 服务日志里有没有打印 GPU 信息。
• 有没有配置GPU_DEVICE_ORDINAL或 ROCm 的可见性变量。

可以设置：

export HIP_VISIBLE_DEVICES=0

这个变量用来指定让 ROCm 看到哪几张 GPU。如果只有一张卡，设为0；如果有多张卡，可以设成0,1,2,3。

调整后再启动 Ollama，执行：

ollama ps

如果ps里显示模型已经加载到 GPU，而不是 CPU，说明调用成功。如果还是 CPU，去journalctl -u ollama或者对应日志文件里看有没有 ROCm 初始化报错。

5.3 多卡并行报错：先降并行度再查通信

vLLM 多卡加载失败，常见报错来自 RCCL，也就是 AMD 的多卡通信库。这不代表 AMD 不能多卡，而是通信初始化没通过。

排查顺序：

1. 先用--tensor-parallel-size 2跑通两张卡。
2. 确认所有卡在同一个 NUMA 节点或至少能互相访问。
3. 检查共享内存大小，/dev/shm在某些容器里默认太小。
4. 查看 RCCL 日志变量。

如果是容器环境，启动时记得加：

--shm-size=8g

如果八张卡来自不同机器，那还涉及多机多卡配置，复杂度比单机八卡更高。建议先把单机八卡跑稳，再考虑跨机。

5.4 显存碎片与速度过慢

有时候没有 OOM，但模型生成速度越来越慢。这可能不是算力问题，而是显存碎片化。

推理框架会动态申请和释放 KV cache，显存被切成很多小块，后续请求找不到连续大块，只能反复等待或触发分配合并。解决办法是给框架预留足够余量，比如--gpu-memory-utilization 0.9，不要用 0.99。

速度慢还有一个常见原因：显卡处于低功耗状态，或者驱动自动降频。执行rocm-smi看当前核心频率。如果明显偏低，可以查一下电源模式或散热策略。还有，如果你用 APU 或统一内存方案跑超大模型，系统内存带宽远低于显存，生成速度会明显下降。

6. 什么环境适合这套方案，什么场景不要硬上

6.1 学习测试环境可以怎么配

如果你只是想验证“AMD 8 卡能不能装下 Kimi K3”，比较合适的配置是：

• Linux 或 WSL2 环境。
• 显卡型号在 ROCm 支持列表内。
• 使用量化权重，先 INT4，再逐步提升精度。
• 用 vLLM 或 llama.cpp，不建议一开始就上复杂推理引擎。
• 准备充足磁盘空间，大模型权重通常要按百 GB 甚至 TB 计。

这个阶段的目标是跑通，不是压满性能。哪怕生成速度慢一点，只要 GPU 被调用、显存没爆、输出正常，就已经完成了第一步验证。

6.2 不建议直接上生产的情况

以下情况不要急着把“8 张 AMD 方案”当作生产方案：

• 显卡型号不固定，从消费级到专业级混插。
• 驱动和 ROCm 版本不具备可重复安装性。
• 没有监控和自动重启机制。
• 需要高并发、低延迟的对外服务。
• 卡间通信走普通 PCIe，性能损耗不可控。

生产环境里，稳定和可维护比“装下”更重要。你能把模型加载进显存，只代表容量达标；如果跑 24 小时后开始 OOM、卡死、输出异常，那还是不能直接上生产。

6.3 我的落地顺序建议

如果按我的习惯，落地顺序是这样的：

1. 先用 7B/8B 小模型跑通 AMD GPU 链路。
2. 用目标模型的最低量化版本做容量测试。
3. 把tensor-parallel-size从 2 逐步升到目标值。
4. 用单请求验证输出质量，再用小并发压测。
5. 最后才考虑服务化、监控和调优。

这个顺序比“直接下载一个大模型，然后期望一次成功”要省时间得多。踩过一次驱动的坑之后你就会发现，很多问题不是模型本身不行，而是环境前置条件没有处理好。

最后留几个我自己排查时会优先看的点：先看rocm-smi认不认卡，再看框架日志里有没有 GPU 初始化记录，接着看权重文件完整性和量化格式，最后才动参数。只要这四步顺序不乱，大部分问题都能在比较短的时间内定位到。