前几天群里有人甩出一句话“16张B200才能跑的Kimi K38张AMD就装下了。”看到这句话第一反应可能是“AMD终于翻身了”也可能是“又在制造对立”。但我更想先把问题拆开为什么同一个模型会在两种硬件上的“卡数”相差一倍这个差异背后真正值得关注的并不是哪家显卡更强而是大模型推理资源分配的一个关键事实——卡数不直接等于模型大小真正决定“能不能跑起来”的是显存容量、推理精度和部署策略这三者的组合。把这句话想通了你会对“跑大模型到底需要多少算力”这件事有完全不同的判断。1. 先别争论哪家显卡强先看模型跑起来卡在什么环节1.1 为什么一张卡装不下和显卡“算力”反而关系不大很多人一听说某个模型要16张B200第一反应是“这个模型太吃算力了”。实际上大模型推理时最容易被卡住的不是算力而是显存容量。模型权重必须放进显存里才能被 GPU 读取并参与计算。你的显卡算力再高如果显存装不下权重和中间状态程序根本不会启动。B200 这类加速卡通常单卡显存做到百GB级别算力也明显领先上一代。但Kimi K3如果真如讨论中所说是2.8T参数规模、MoE结构的大模型那么它的权重本身就非常庞大。这里可以做一个粗算如果按BF16精度存储1万亿参数大约占2TB显存2.8T参数就接近5.6TB。如果按INT8量化大约需要2.8TB如果按INT4量化大约需要1.4TB。16张B200如果单卡192GB总显存约3TB正好可以承载INT8甚至更高精度的权重。而8张AMD加速卡如果单卡也是192GB总显存约1.5TB那大概率只能承载INT4量化后的权重。所以“16张B200才能跑”和“8张AMD就装下了”之间很可能不是同一份配置也不一定是同一档精度和上下文长度。更准确的说法是两者各自采用了不同的显存预算策略。关注点应该是“为什么有人愿意用更多卡换更高精度和更长上下文”以及“为什么有人可以用更少卡把模型塞进去”。1.2 推理时还要给KV Cache留位置不只是权重权重只是显存占用的一部分。模型在生成每个token时需要把已生成的历史信息写成KV Cache用来加速注意力计算。KV Cache的大小和上下文长度、层数、注意力头数、batch size直接相关。上下文越长KV Cache增长得越快。在一些长上下文场景里KV Cache甚至可能比模型权重更占显存。这就能解释一个常见现象同样的模型有人用4张卡就能跑有人怎么都OOM。差异往往不在权重本身而在上下文窗口长度和并发请求数。比如一个支持128K上下文的服务KV Cache预留就要比8K上下文大非常多。如果你把上下文长度从128K砍到8K显存占用立刻会降下一大截。标题里的“8张AMD就装下了”很可能就是这种“优化后的部署”使用INT4量化、限制上下文长度、保持低并发甚至把部分计算放到CPU或内存里做卸载。这样做的代价是单请求吞吐下降、多用户并发能力减弱、长文本场景受限。也就是说“装下了”不假但“装下之后跑成什么样”是另一回事。为了更清楚看到显存占用的构成可以做一个简单的估算表显存需求项主要影响因素备注模型权重参数量、量化精度最大的一项尤其是万亿级MoEKV Cache上下文长度、batch size、层数、头数长上下文中增速极快激活值batch size、序列长度推理阶段通常低于训练阶段框架与运行时开销CUDA/ROCm context、中间缓冲区可能占几个GB到几十GB看到这个表你就明白“卡数”只是个表象。真正影响部署难度的是参数多少、量化到多少位、上下文开多长、同时服务多少人。2. 一个“少一半卡”的方案真正改了什么2.1 省卡主要靠四个手段不是凭空优化从16张B200到8张AMD不会是因为AMD有什么神秘魔力。更常见的解释是下面四类手段的组合权重量化。把BF16/FP16换成INT8或INT4直接减少权重占用。INT4量化后的模型权重约是BF16的1/4所以原本需要5.6TB的权重可能只需1.4TB。上下文与并发压缩。限制最大上下文长度、降低batch size甚至关闭并行采样让KV Cache和激活值保持在一个很低的水平。推理引擎专门适配。AMD的ROCm生态相对NVIDIA更“新”很多框架在AMD上运行时反而会避免一些NVIDIA生态里常见的显存预留行为尽量只保留必需显存。这个差异会让AMD方案的显存占用“更紧”但也可能带来兼容性风险。CPU Offload或异构调度。把部分权重放在CPU内存GPU只放当前激活的专家层。MoE模型每次推理只激活一小部分参数这种设计很适合做层间或专家卸载。这四种手段都很常见并不是AMD专属。如果NVIDIA平台同样使用INT4、限制上下文、优化引擎和CPU卸载也可以减少卡数。所以“AMD卡少”不一定来自硬件优势更可能来自部署团队对显存的压榨程度。2.2 B200为什么显得“费卡”因为它的默认目标不是省卡NVIDIA生态太成熟软件栈默认做了很多“保性能”的设计。很多推理框架在NVIDIA卡上为了兼容各种模型结构会预留显存、缓存空间甚至维护多份中间表示。尤其在用TensorRT、FasterTransformer、vLLM这类框架时默认配置往往追求高并发、低延迟而不是“刚好塞进显存”。一旦你要求高吞吐、大batch、长上下文16张B200真不一定够用。AMD生态相对新一些能跑通大模型推理的框架本来就不多社区里能用的案例基本都是“为了跑通而优化”。这种背景下部署者会花大量精力抠显存、调量化、砍上下文。结果是“能用更少卡跑起来”但稳定性和通用性往往还达不到生产级。所以这两个方案不是“谁更好”的关系而是目标不同对比维度16×B200典型方案8×AMD典型优化方案精度BF16/INT8质量保留更完整INT4可能出现质量损失上下文支持长上下文显存预留充足可能加长受限或需要特殊优化并发高batch适合对外服务低并发适合验证或私有化部署核心目标吞吐、稳定、兼容在有限显存里把模型塞进去工程复杂度生态成熟部署路径清晰需要更多手动配置和验证从这个角度看标题里的“8张AMD就装下了”其实是一个“极限部署”的例子。它证明了“这个模型用8张大显存卡可以放下”但没有证明“在同样的精度和负载下AMD只需要8张”。3. 如果也想在AMD GPU上跑这类超大模型建议按什么顺序落地3.1 第一步先把显存账算清楚任何部署开始前都应该先算一笔显存账。否则很容易出现“代码写好了一启动就OOM”的情况。一个简单的框架是确认模型参数量。例如2.8T。选择精度。BF16是2字节INT8是1字节INT4是0.5字节。估算权重显存参数量×每参数字节数。估算KV Cache根据最大上下文长度、层数、注意力头数估算可以先去框架日志里看实际占用。给框架和运行时留出余量通常是显存总容量的10%到20%。用2.8T参数模型举例权重显存大致如下精度每参数字节2.8T模型权重约为BF16/FP162字节5.6TBINT81字节2.8TBINT40.5字节1.4TB如果8张AMD卡单卡192GB总显存约1.5TB那只能勉强放下INT4权重的2.8T模型还要从KV Cache和运行时里抠空间。如果把上下文开得很长或者同时跑多个请求1.5TB很快会被吃满。这也是为什么很多“省卡案例”会选择短上下文、低并发。所以落地前先问自己几个问题模型是稠密还是MoE推理时会激活多少专家精度能不能接受量化需要多长的上下文并发量是多少这些问题远比“B200还是AMD”更重要。3.2 第二步环境与推理框架的常见选择AMD GPU 跑大模型的典型路径和NVIDIA不太一样核心是ROCm软件栈。常见做法包括安装对应显卡型号和操作系统的ROCm驱动。安装基于ROCm的PyTorch或直接使用支持ROCm的推理框架。下载已量化的模型权重例如GGUF、GPTQ、AWQ、EXL2等格式。启动服务时选择正确的量化参数、张量并行数、设备列表和上下文长度。用vLLM这类框架时可以先用小模型验证GPU设备。启动命令大致像下面这样参数需要按实际环境调整# 这是一个通用示例请先查阅框架版本对AMD的支持情况 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --quantization awq \ --tensor-parallel-size 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里有几个容易踩坑的点tensor-parallel-size要小于等于实际GPU数且显存分配时按多卡预算。gpu-memory-utilization不要直接拉满要留出KV Cache和框架开销的空间。量化格式必须和模型匹配AWQ模型就不能用GPTQ参数启动。AMD平台需要确认框架是否支持该GPU架构有些新卡需要设置环境变量来指定目标架构否则可能直接报错或性能极低。如果你的目标不是Kimi K3这种超大模型而是日常小模型可以先从Ollama开始。Ollama在AMD GPU上的支持和安装方式官方文档和社区都有说明。在WSL2里使用Ollama时重点检查ROCm版本、驱动透传、HIP_VISIBLE_DEVICES是否正确。如果设备列表没设置好Ollama会“看到”GPU但调用不了或者直接回退到CPU速度会慢到怀疑人生。4. 真正容易踩的坑别让“省卡”变成“省了质量”4.1 量化后的模型必须做输出质量回归很多人把模型部署起来后第一件事是看能不能正常生成。能生成就认为成功了。但对于量化模型尤其是INT4这种压缩比较高的方案输出质量可能已经发生变化。代码任务、数学题、逻辑推理、长文本信息抽取这些场景对量化非常敏感。一个模型在原版高精度下能答对量化后可能开始出错而且错误方式比较隐蔽不一定明显低劣。建议准备一组固定测试集最好覆盖下面几类事实问答需要从知识库里调取准确信息。数学计算简单算术到中等复杂推理题。代码生成函数实现、报错修复。长文本抽取给定长文提取指定实体或摘要。在NVIDIA高精度方案和AMD量化方案上各跑一遍逐条对比。如果差太多就要考虑提高量化精度或者增加几张卡。记住“能跑”和“能用”之间的距离往往就是这些看不见的质量损失。4.2 排查链路卡住了先按层级查AMD GPU 跑大模型的报错信息五花八门最常见的包括OOM、驱动初始化失败、设备不可见、速度极慢、无输出等。遇到问题不要急着搜错误码按下面的链路排查更高效看现象是OOM、启动失败、卡住、无输出还是输出乱码看输入模型路径、tokenizer路径、提示词格式、上下文长度是否异常。看环境ROCm版本、PyTorch版本、内核版本、WSL版本、容器是否挂载GPU。看权限设备节点是否可见用户是否有访问GPU的权限HIP_VISIBLE_DEVICES是否设置。看参数量化格式是否匹配tensor-parallel-size是否过大gpu-memory-utilization是否超过实际可用显存KV Cache是否把显存挤爆。看工具边界框架是否完整支持AMD是否有已知的架构兼容问题。有些框架在NVIDIA上很稳定在AMD上就是“不支持”或“部分支持”。一个实际建议先跑一个7B或13B小模型确认GPU设备能被框架正确调用再切换成更大的模型。如果小模型可以跑起来大模型启动时OOM那基本就是显存预算的问题。如果小模型也报错那问题大概率出在驱动或框架兼容层。排查时可以用类似下面的表格记录层级检查内容常见坑现象报错信息、是否卡死、输出为空容易忽略日志末尾输入模型格式、路径、提示词混用不同量化格式环境驱动、ROCm、内核、WSL版本不匹配权限设备可见性、容器挂载忘记设置GPU设备列表参数张量并行、显存利用率、上下文长度显存预留不足工具框架支持度的边界某些算子没有ROCm实现这个思路不只适用于AMD也适用于NVIDIA平台。先定位坏在哪一层再决定修哪里比反复重装驱动有用得多。5. “少一半卡”的讨论真正值得关注的是底层趋势5.1 省卡不是目的可复用、可监控的推理服务才是“8张AMD就装下了”这类信息很容易让人产生一种错觉用更少的卡就能以更低成本跑同样的模型。但对工程团队来说真正要紧的是能不能长期稳定运行。一次性启动成功和能够持续对外提供服务是两个完全不同的概念。生产级推理服务至少要考虑并发请求时延迟会不会剧烈抖动。长上下文场景下KV Cache会不会把显存挤爆。单卡或单进程故障后怎么自动恢复。模型更新后量化效果和输出质量如何回归。日志、监控、指标采集是否完整。一个只能跑单请求、需要手动重启、还不能记录日志的部署即使“只用8张卡”也很难直接用在实际业务里。反过来如果业务本身不追求高并发只是内部验证或私有化小规模使用那么极限省卡的方案确实能大幅降低硬件门槛。5.2 大模型部署正在从“堆卡”走向“按显存和带宽做配置”Kimi K3这种超大MoE模型本身就是一个很好的例子。MoE结构的特点是参数量很大但推理时只激活一部分专家。这意味着如果把所有专家权重都放在显存里成本很高但如果能精准调度让每次推理只加载需要的专家那么显存压力就能被大幅缓解。这给硬件选择带来的变化是单纯比较“FP16算力”已经不够了还要看显存容量、显存带宽、卡间互联、对不同量化格式的适配效率。AMD能在这个话题里占据一席之地不一定是算力超越了NVIDIA而是它的部分大显存卡在“塞下大模型”这件事上确实有天然优势。再加上社区对ROCm的持续适配越来越多模型可以在AMD上跑通。对普通开发者来说这里面最实用的收获不是“哪家卡更强”而是一个更底层的判断方法拿到一个新模型先算权重显存再看推理框架支持然后再决定用几张卡、什么精度、开多长上下文。这套方法比跟风标题更有价值。未来模型参数还会继续涨但从“堆卡”到“按显存和带宽做配置”的路径会越来越清楚。最后回到开头那句话16张B200才能跑的Kimi K38张AMD就装下了。这句标题真正的意义不在于证明AMD取代了NVIDIA而在于提醒我们决定大模型部署方案的因素从来不是单卡的“名字”而是显存容量、量化策略、上下文长度、并发能力和工程成本之间的平衡。下次再看到类似说法你可以先算一笔显存账再判断它值不值得信。