这次我们来看一个有点反常识但技术上很有意思的话题同样是跑大规模 MOE 模型NVIDIA B200 那边要 16 张卡起步AMD 这边却可以用 8 张卡“装下”。对应到 Kimi K3 这种 2.8T 参数级别的模型很多人第一反应是“不可能”但只要你把 MOE 权重加载方式、量化精度和显存规划算一遍会发现 AMD 8 卡方案并不是标题党它走的是另一条工程路径。这篇文章不是发布会总结而是按 CSDN 技术文章的习惯把这几件事讲清楚Kimi K3 到底是什么级别的模型、16 张 B200 为什么被认为“才能跑”、AMD 8 张是怎么“装下”的、如果你自己有一台多卡服务器该怎么做部署验证、看哪些指标、踩哪些坑。适合正在做企业级本地推理、MOE 大模型多卡部署、或者在做 AMD 与 NVIDIA 推理方案对比的工程师收藏。先说结论这个“装下”不等于 16 张 B200 和 8 张 AMD 的体验完全一致。它更多是“以量化换取显存容量、以 MOE 调度换取单卡压力下降”的部署策略差异。下面从模型规格开始拆。1. 核心能力速览能力项说明项目类型大规模 MOE 模型本地部署方案对比模型规模Kimi K3 总参数约 2.8TMOE 架构推理时只激活部分专家NVIDIA 参考配置16 张 B200单卡 192GB HBM3e总量约 3TB 显存AMD 参考配置8 张 Instinct 系列加速卡单卡 192GB 或 256GB总量约 1.5TB 至 2TB能否单卡运行不能2.8T 参数远超单卡显存需要多卡并行推理框架vLLM、SGLang 等支持 ROCm 后端的框架显存优化关键FP8/MXFP4/INT4 量化 MOE 专家并行 KV Cache 规划是否支持 API支持vLLM/SGLang 默认提供 OpenAI 兼容接口是否支持批量任务支持可走异步接口或任务队列适合场景企业内部推理、长文本处理、批量离线任务、大规模并发服务不适合场景单卡个人电脑离线运行、无授权商用需要强调的是以上表格中的“8 张 AMD”指的是数据中心级 Instinct 加速卡不是 Radeon 游戏卡。如果你手上只有一张 24GB 的消费级卡这个标题方案与你无关不要拿 Windows 游戏卡硬套多卡推理流程。2. Kimi K3 模型规格与本地部署关注点先看模型本身。Kimi K3 是 Kimi 系列里参数规模更大的一代公开信息里提到的核心规格包括总参数约 2.8T采用 MOEMixture of Experts结构。MOE 模型的特点是“总参数大、激活参数小”每个 token 只会激活一部分专家所以它的计算量并不完全等于总参数量但权重文件却要按全部参数来加载。这意味着什么对部署工程师来说最直接的问题是2.8T 参数完整 FP16 权重体积约 5.6TBFP8 权重体积约 2.8TBMXFP4/INT4 权重体积约 1.4TB实际部署时还要预留 KV Cache、中间激活、框架运行开销显存不可能刚好等于权重体积。所以“跑不跑得动”很多时候不是算力问题而是“显存装不装得下权重”的问题。B200 单卡 192GB 显存16 张一共 3072GBAMD Instinct MI300X 单卡也是 192GB8 张是 1536GB。如果直接把 FP8 权重全部压进显存8 张 MI300X 显然装不下 2.8TB。那标题为什么成立答案可能有两个方向AMD 侧使用了更高压缩比的量化精度例如 MXFP4 或 INT4把权重体积压到 1.4TB 级别8 张 256GB 的 MI325X 总量 2TB能装下并留出 KV Cache 空间。部署时采用了 CPU Offload、专家动态调度等策略让部分不活跃的专家临时驻留 CPU 内存或 SSD按需换入显存。所以“8 张 AMD 就装下了”更准确的说法是8 张 AMD 在量化与调度优化后能达到运行门槛而不是从头到尾保持与 16 张 B200 完全相同的精度和吞吐。这样理解这个标题才没有水分。从材料给出的热词来看本地部署是大家最关心的问题。但我要先给一部分读者降温如果你是在个人电脑上用 Ollama 跑模型Kimi K3 这类 2.8T 模型不是 Ollama 的常规使用场景。Ollama 更适合几百亿参数级别的中小模型2.8T 模型必须走多卡 多机 专业推理框架的路线。下面提到的部署流程也主要是面向企业级服务器。3. 为什么 NVIDIA 侧需要 16 张 B200“16 张 B200 才能跑”这句话很容易被理解成“模型必须要 16 卡”。实际拆开看它更多是生产环境配置的合理性选择。先算显存账。如果按 FP8 精度加载2.8T 参数权重大约占 2.8TB。16 张 B200 总显存 3TB减去权重后还剩约 200GB 给 KV Cache、CUDA Context、激活值。而对一个等效上下文很长的模型来说KV Cache 是非常大的开销尤其是上下文要拉到 256K 甚至更长时KV Cache 可以轻松再吃掉几百 GB 显存。然后看并行策略。2.8T 参数的 MOE 模型在 8 卡甚至 4 卡上也能做张量并行和专家并行但单卡要承载的权重和中间结果会非常大Batch Size 和并发能力会被显存卡死。16 卡的意义不仅在于“装得下”还在于“跑得快、并发得起”。再看生态因素。NVIDIA 生态里常见的部署路径是 vLLM、TensorRT-LLM、SGLang。TensorRT-LLM 对 B200 的 Blackwell 架构有专门优化官方推荐的模型并行组数、KV Cache 配置往往基于 8 卡或 16 卡节点设计。也就是说16 张 B200 是 NVIDIA 方案中一个“不需要做极限压缩就能稳定跑生产”的配置。总结一下16 张 B200 不是数学上唯一能跑的卡数而是工程上比较稳、并行度比较高、精度损失比较小、又留有足够 KV Cache 余量的配置。文章标题里的“才能跑”应当理解为“想跑得舒服、跑得稳NVIDIA 侧通常给 16 卡”。4. AMD 8 张是怎么“装下”的再回到 AMD 方案。8 张卡要装下 2.8T 参数核心手段是“压缩权重体积”和“优化显存布局”。4.1 量化精度决定体积这是最直观的一步。FP16 权重 5.6TBFP8 权重 2.8TBMXFP4/INT4 权重约 1.4TB。如果 AMD 侧使用 8 张 256GB 的 Instinct MI325X总显存 2TB那么必须把权重压到 2TB 以内才能塞得进去。1.4TB 到 1.5TB 的量化权重加上几十 GB 到几百 GB 的 KV Cache2TB 总显存是可以排布的。如果是 8 张 192GB 的 MI300X总显存 1.5TB就需要更激进的调度策略比如把部分不常激活的专家放到 CPU 内存或者使用更小精度的量化。所以“8 张 AMD 就装下了”的隐藏条件大概率是使用 MI325X 级别的大显存版本单卡 256GB权重精度至少降到 FP8更多可能是 MXFP4KV Cache 做量化或分页管理不让它无限制膨胀。4.2 MOE 模型的显存优化空间MOE 模型给 AMD 方案的“省卡”提供了结构基础。2.8T 参数全部加载但每个 token 推理时只激活一部分专家。这就带来两种优化思路第一专家并行。把不同专家分布在不同 GPU 上每个 token 通过 All-to-All 通信找到对应专家。这样单卡只需承载一部分专家权重而不是全部。第二动态调度 / Offload。把不太热门的专家权重放在 CPU 内存里GPU 显存只保留当前活跃的专家。虽然这会增加通信和内存换入换出成本但在显存不够时至少能把模型“跑起来”。这两条路都是工程上已经成熟的方案vLLM 和 SGLang 对 MOE 专家并行都有支持。因此AMD 8 卡方案的本质是更大的单卡显存 量化压缩 MOE 专家调度三者同时生效才把 2.8T 模型搬进 8 卡节点。4.3 需要付出的代价这不是白送的。AMD 8 卡方案通常要接受以下妥协权重精度下降极端量化下输出质量可能有波动专家 Offload 或更小的并行度会降低吞吐单请求延迟可能升高长上下文场景下 KV Cache 压力大并发能力不如 16 卡 B200 宽裕如果框架对 ROCm 的优化不到位通信效率和 CUDA 生态有差距。所以“装下了”是第一步后续的质量和性能需要单独验证。这也是这篇文章要带大家做部署测试的原因。5. 本地部署环境准备如果你已经有一台 8 卡 AMD Instinct 服务器想复现整个流程下面是一份通用环境准备清单。由于 Kimi K3 的公开模型仓库和官方启动脚本可能有调整我这里以 vLLM / SGLang 部署 MOE 大模型的通用流程为例具体路径和模型名需要按实际项目替换。5.1 硬件与系统项目建议GPUAMD Instinct MI300X / MI325X8 卡节点CPUx86 服务器建议 64 核以上内存建议 512GB 以上给 CPU Offload 留余量系统盘预留 200GB 以上模型盘预留 3TB 以上用于存放多份精度权重系统Ubuntu 22.04 / 24.04 或兼容 Linux 发行版驱动ROCm 6.x推荐与 PyTorch 版本配对5.2 ROCm 与驱动AMD GPU 在 Linux 下的计算栈是 ROCm。安装方式通常有两种官方 apt 源安装和 rock-dkms 安装。下面是一个基于官方仓库安装 ROCm 的通用示例实际版本号要以官方文档为准# 添加 ROCm 官方源具体源地址以 amd.com/rocm 文档为准 wget https://repo.radeon.com/amdgpu-install/latest/ubuntu/jammy/amdgpu-install_6.x.x_all.deb sudo apt update sudo apt install -y ./amdgpu-install_6.x.x_all.deb sudo amdgpu-install --usecaserocm安装完成后确认 ROCm 是否可用rocm-smi如果输出能看到 8 张显卡及温度、显存、性能等级信息说明驱动层正常。也可以使用 AMD 官方的amd-smi工具查看更细粒度的显存占用。5.3 PyTorch 与推理框架ROCm 版 PyTorch 可以从 PyTorch 官方安装命令中选择rocm版本。vLLM 和 SGLang 都在持续支持 ROCm 后端。以 PyTorch ROCm 为例通用安装命令类似pip install torch --index-url https://download.pytorch.org/whl/rocm6.2vLLM 对 AMD 的支持一般通过VLLM_USE_ROCM或直接安装带 ROCm 依赖的版本。具体安装命令会随版本变化请以 vLLM 官方文档为准。SGLang 同样提供了 AMD 支持安装时需要注意和 PyTorch / ROCm 的版本配对。5.4 端口与网络多卡推理服务默认会监听一个 HTTP 端口比如 8000 或 30000。部署前先确认端口是否被占用ss -lntp | grep 8000如果被占用可以在启动参数里换端口。6. 部署与启动流程这里演示的是“用 vLLM 启动一个 OpenAI 兼容 API 服务”的通用流程。假设你已经把 Kimi K3 的权重下载到一个本地目录例如/data/models/kimi-k3量化精度按你的显存规划选择。6.1 启动 vLLM 服务python -m vllm.entrypoints.openai.api_server \ --model /data/models/kimi-k3 \ --tensor-parallel-size 8 \ --dtype float8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --port 8000参数说明--tensor-parallel-size 88 卡张量并行--dtype float8以 FP8 精度加载实际精度选项需按模型支持情况选择--max-model-len最大上下文长度开始测试建议先调低降低 KV Cache 压力--gpu-memory-utilization允许框架使用的显存比例建议从 0.9 开始观察--portAPI 服务端口。如果你用的是 SGLang启动方式类似python -m sglang.launch_server \ --model-path /data/models/kimi-k3 \ --tp 8 \ --port 80006.2 验证服务是否启动启动后可以在本机用 curl 请求模型列表curl http://127.0.0.1:8000/v1/models如果能返回模型 ID 和元信息说明服务已经正常拉起。6.3 日志观察启动过程中重点看三部分日志模型权重加载是否完整有没有提示缺少分片文件每张 GPU 的显存分配是否均匀是否打印出 “Already started the model” 之类的就绪信息。第一次启动通常会比较慢因为需要加载数 TB 权重。如果模型文件在机械硬盘上加载时间会非常久建议放在 NVMe SSD 或高速并行文件系统上。6.4 显存不够时的调整方向如果你在启动阶段就报显存不足按这个顺序调整降低--max-model-len比如从 32768 降到 16384降低--gpu-memory-utilization不解决权重装不下的问题核心还是看精度改用更低精度的量化权重比如从 FP8 切到 INT4考虑启用 CPU Offload 参数让部分专家驻留 CPU 内存如果还不行就需要加节点或减模型规模。7. 功能测试与效果验证服务启动后按下面几个维度做功能验证。这里给出的都是通用测试方法不绑定特定模型。7.1 基础对话测试这步主要是验证模型能否生成连贯回答。用一个简单的 Python 请求做冒烟测试import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: /data/models/kimi-k3, messages: [ {role: user, content: 你好请用一句话介绍你自己。} ], temperature: 0.6, max_tokens: 256 } response requests.post(url, jsonpayload, timeout300) print(response.json()[choices][0][message][content])判断标准返回内容是否通顺、是否与模型定位一致首 token 返回间隔是否可接受是否出现CUDA out of memory错误。7.2 长文本处理测试Kimi 系列的核心优势之一就是长文本。建议构造一份长文档输入比如把一份 1 万字的测试文档分段拼接到 prompt 里观察上下文拉长后显存占用上升了多少是否因为 KV Cache 超限而报错长文本中的前后信息能否被正确关联。一个通用测法是“把答案放在文档中间让模型在结尾处复述”。如果模型能准确引用中间部分的内容说明长文本编码正常。不要一开始就拉满最大上下文先测 16K再逐步加到 32K、64K观察每个阶段的变化。7.3 批量任务测试批量场景一般不会用同步请求逐条调用而是开多个并发或走异步接口。vLLM 提供了 OpenAI 兼容接口可以用异步客户端做并发测试。import asyncio from openai import AsyncOpenAI client AsyncOpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keynot-needed) async def run_one(prompt: str): resp await client.chat.completions.create( model/data/models/kimi-k3, messages[{role: user, content: prompt}], max_tokens512 ) return resp.choices[0].message.content async def main(): prompts [ 请总结第一段文本。, 请总结第二段文本。, 请总结第三段文本。, ] results await asyncio.gather(*[run_one(p) for p in prompts]) for i, r in enumerate(results): print(f任务 {i1} 完成长度 {len(r)}) asyncio.run(main())批量测试时注意并发数不要一开始就拉满先 1、2、4、8 逐步加压观察请求失败率、超时时间、显存变化如果批量任务里有长文本和短文本混跑要注意长文本请求占用的 KV Cache 会挤压其他请求需要评估排队策略。7.4 判断部署是否成功一个部署流程跑通至少满足四个条件/v1/models接口能返回模型信息短文本对话能正常生成且连续多次不报错一定长度的长文本请求不会因为显存问题直接崩溃批量并发时没有大面积超时或乱码。如果这四个条件都满足说明这个“8 张 AMD 装下 Kimi K3”的方案在你的环境下是能用的。接下来才轮到性能和稳定性优化。8. 接口 API 与批量任务落地vLLM 和 SGLang 默认提供的就是 OpenAI 兼容 API这意味着你不需要自己写推理逻辑直接把它接入现有业务系统即可。8.1 接口地址服务启动后核心接口通常是接口用途/v1/models获取模型列表/v1/chat/completions对话补全/v1/completions文本补全8.2 curl 调用示例curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/kimi-k3, messages: [ {role: user, content: 请用三句话解释什么是 MOE 模型。} ], max_tokens: 256 }8.3 批量任务队列设计建议如果是离线批量任务不建议直接对 API 服务狂发并发请求。更稳的做法是准备输入文件每行一个 JSON 请求用一个脚本逐批读取并发送控制并发数记录每个任务的请求 ID、状态、token 数失败任务单独落盘支持断点重试批量跑完后合并结果。Python 伪代码思路如下import json import requests BASE_URL http://127.0.0.1:8000/v1/chat/completions MODEL /data/models/kimi-k3 with open(tasks.jsonl, r) as f: tasks [json.loads(line) for line in f if line.strip()] failed [] for i, task in enumerate(tasks): try: resp requests.post(BASE_URL, json{ model: MODEL, messages: task[messages], max_tokens: task.get(max_tokens, 512) }, timeout600) resp.raise_for_status() with open(results.jsonl, a) as out: out.write(json.dumps({index: i, result: resp.json()}) \n) except Exception as e: failed.append({index: i, error: str(e)}) with open(failed.json, w) as f: json.dump(failed, f, ensure_asciiFalse, indent2)批量任务最容易被忽略的是超时设置。大规模 MOE 模型在长文本场景下生成速度不稳定超时时间要放宽到请求完成而不是按固定秒数一刀切。9. 资源占用与性能观察部署不是“能启动”就结束还要能回答“这个方案在什么负载下会崩、什么负载下是舒服的”。9.1 显存占用观察方法AMD 平台下用rocm-smi或amd-smi持续观察watch -n 2 rocm-smi --showmeminfo vram如果你需要记录长时间变化可以把输出重定向到文件rocm-smi --showmeminfo vram --alldevices --interval 5 memory.log 观察重点空闲时显存占用多少主要是权重驻留请求进入后显存增长多少主要是 KV Cache 和激活值并发数升高后总显存是否逼近上限是否有某些卡的显存明显比别的卡高说明并行策略分配不均。9.2 吞吐与延迟建议先测单请求延迟再测并发吞吐。单请求延迟关注“首 token 延迟”并发吞吐关注“每秒生成的 token 数”。vLLM 服务端日志会打印吞吐、延迟、显存占用等指标可以直接从日志观察。9.3 影响性能的几个关键参数max-model-len越大KV Cache 预留越多能处理的并发越少量化精度越低显存越省但生成质量可能下降tensor-parallel-size太小会导致单卡权重压力大太大会增加通信开销Batch Size批量推理能提高吞吐但会推高显存占用。9.4 如何降低显存占用先检查哪些参数占用可以压缩权重 - 降量化精度 KV Cache - 降低 max-model-len 或开启 KV Cache 量化 激活值 - 减少 batch size 或并发数 专家权重 - 开启 CPU offload如果降到最低还不够那就是物理显存不够需要加卡或扩节点。10. 常见问题与排查方法问题现象可能原因排查方式解决方案rocm-smi看不到 8 张卡驱动未装好或卡未正确插槽检查lspci输出是否有 AMD 设备重新安装 amdgpu 驱动核对 ROCm 版本PyTorch 报找不到 ROCm 设备PyTorch 版本与 ROCm 不匹配python -c import torch; print(torch.cuda.is_available())安装匹配的 ROCm 版 PyTorch启动时显存不足量化精度过高或 max-model-len 过大查看单卡显存总量和权重体积估算降精度、改小上下文、启用 offload模型加载很慢权重放在机械硬盘或网络文件系统看 I/O 占用把权重放到 NVMe SSDAPI 请求超时长文本生成慢或并发过高看服务端日志和显存占用降低并发、放宽超时、启用流式输出服务能启动但回复乱码量化权重与推理精度不匹配检查 dtype 参数不同量化精度要对应不同推理参数多卡显存占用不均专家并行分布不均或请求切分不均用 rocm-smi 逐卡观察调整并行策略或换批大小端口被占用之前服务未退出ss -lntp | grep 8000换端口或 kill 旧进程请求内容涉及未授权素材使用边界不明确认数据来源和授权停止该请求建立合规审核流程排查大模型部署问题最基本的方法就是把日志打开。vLLM 和 SGLang 的日志都比较详细很多显存问题在启动阶段就会直接打出来不用等请求阶段才发现。11. 最佳实践与合规边界11.1 部署建议第一次跑通时不要一上来就追求最长上下文和最大并发。建议按下面的顺序推进先用 8192 或 16384 上下文启动确认服务正常用单请求验证对话质量和长文本能力逐步拉长上下文观察显存变化曲线确认单机单服务稳定后再接入批量任务队列批量任务加入日志、重试、失败落盘机制上线前做一次回归测试覆盖长、中、短文本和并发场景。另外模型权重、原始输入、输出结果建议分目录管理/data/models/ 模型权重 /data/inputs/ 原始输入 /data/outputs/ 推理结果 /logs/ 服务日志和任务日志分目录的最大好处是排查问题的时候能快速定位是权重问题、输入问题还是服务问题。11.2 安全与合规这类大规模模型部署涉及几个不能忽略的边界模型权重使用前确认 Moonshot 或模型发布方的开源协议与商用条款企业的私有数据尤其是涉及个人信息、客户数据、内部代码的内容不要直接发送到不受管控的外部服务本地部署本身就是为了解决数据出域问题但也要做好服务访问控制API 服务建议绑定内网地址不要直接暴露公网必要时加 API Key 和访问白名单如果后续要把模型能力接入人脸、声音、个人身份等敏感场景必须确认相应的肖像权、声音权和数据授权对生成结果要做复核机制大模型输出不总是可靠的不能把生成内容直接用于对外发布或决策。12. 总结与下一步这个“16 张 B200 才能跑8 张 AMD 就装下了”的标题真正值得琢磨的地方不在于谁强谁弱而是它把大规模 MOE 模型部署的核心矛盾摆了出来显存总量、量化精度、专家调度三者共同决定了你到底需要几张卡。如果你想尝试验证这套 AMD 8 卡方案第一步不是找 8 张卡而是先用模拟计算把权重体积和显存规划做一遍模型多少参数、权重用什么精度、KV Cache 按多长上下文预留、并行度是多少。算完这笔账你就会理解为什么有人会说 16 张 B200 是保守配置8 张 AMD 是优化过的极限配置。最容易踩的坑也简单一是拿游戏卡的显存思维来算数据中心卡二是忽略 KV Cache 的占用三是把“能启动”当成“能上生产”。这三个坑踩过之后你对大模型部署的理解会上一个台阶。后续可以继续扩展的方向给 8 卡 AMD 节点做完整的吞吐压测对比不同量化精度下的输出质量差异把批量任务队列接到自己的业务系统里或者进一步测试长上下文场景下的并发稳定性和失败恢复机制。这篇文章先帮你把路径打通剩下的优化工作本质上就是围绕显存账和通信账反复迭代。