最近被一个选型问题反复拉到同一条工作线上GLM5.2 这种新模型私有化部署到底该买 AMD MI355X 还是 NVIDIA B200问的人一多连带着“豆包2.1 Pro 对比 GLM5.2”的长文本话题也开始往我这边涌。模型之间谁强谁弱是一回事私有化部署时能不能用有限的算力把模型潜力接住是另一回事。这两张卡的对比本质上就是一场“显存容量路线”和“算力生态路线”的对决。先交代背景。GLM 系列走到 5.2 这代模型形态已经从早期纯 Dense 演变成大规模 MoE也就是混合专家架构。拿开源口径看总参数量已经冲到千亿级别但每次推理只激活其中一小部分参数。这个特性对推理侧的影响是巨大的峰值算力不再是唯一坐标显存容量和显存带宽的权重被无限拉高。而业界能同时给到“大显存、高带宽、新一代架构”的推理加速卡现阶段真正能打的就这两张NVIDIA B200以及 AMD Instinct MI355X。这篇文章不打算停在厂商 PPT 的数字层面。我会按真实部署的逻辑来拆——先用显存和互联把边界画清楚再分 prefill 和 decode 两阶段看性能瓶颈然后算每 token 成本最后回到软件生态——把两张卡在 GLM5.2 负载上的真实表现掰开讨论。如果你正在做私有化推理选型这篇应该能帮你省下至少两周的踩坑时间。1. 这组对比为什么绕不开GLM5.2成了新的推理负载标尺1.1 GLM5.2把长上下文需求推到了部署痛点GLM5.2 这代模型有个很容易被忽略的部署特性它对“张量并行切分”和“KV Cache 余量”的敏感度比前代模型高得多。官方和开源社区经常拿它跑超长上下文测试从 128K 到 512K 都有。长上下文意味着什么意味着一次推理过程中KV Cache 会随着输入长度线性增长几十万 token 的上下文光缓存就可能占用几十 GB 显存。如果模型权重再吃掉大头显存压力立刻变成部署的第一约束。更微妙的是最近“豆包2.1 Pro 对比 GLM5.2”的实测视频和文章越来越多很多人的注意力还停在“谁的回答更好”上但我看到的是另一件事同一个 GLM5.2 模型在不同硬件后端上跑出来的长文本速度能差好几倍。模型竞争越激烈后端硬件差异就越容易被放大。换句话说GLM5.2 正在变成一块很硬的试金石专门用来测新一代推理加速卡的成色。1.2 为什么对标的是 B200不是 H100 和 MI300X很多人会问为什么不拿 H100 或者 MI300X 出来比答案很直接显存容量不够。H100 的 80GB 显存跑小参数模型没问题放 GLM5.2 这种千亿级 MoE 权重再加上长上下文 KV Cache基本连 batch 都开不起来更不用说高并发。MI300X 虽然已经有 192GB HBM3 和 5.2TB/s 带宽但那是 CDNA3 时代的产品放到 GLM5.2 这个推理负载上峰值算力和 FP8 支持的完整度都差了一代。所以第一轮筛选之后线上能扛起 GLM5.2 规模化推理的消费级数据中心卡主要就是 B200 和 MI355X。B200 是 Blackwell 架构的主力192GB HBM3e、8TB/s 带宽、NVLink 全互联CUDA 生态还是最省心的那一档MI355X 是 AMD CDNA4 架构的旗舰最大卖点是 288GB HBM3E 和同样 8TB/s 级别的带宽。再加上 AMD 一贯的价格策略这两张卡的对比注定绕不开。2. 显存与互联带宽先把部署边界画清楚2.1 288GB对192GB模型切分和KV Cache的分配差异部署 GLM5.2 这种大模型第一件事永远不是比算力而是看模型能不能高效塞进显存。假设一个开源版 GLM5.2 总参数约 700B用 FP8 存储每参数大约 1 字节那权重就要占 700GB 左右。不管是 B200 的 192GB 还是 MI355X 的 288GB单卡都放不下张量并行切分是躲不掉的。区别在于切完还剩多少空间给 KV Cache。以 8 卡整机为例B200 的 8 卡总显存是 1536GBMI355X 是 2304GB整整多出 768GB。这 768GB 落到 GLM5.2 的长上下文场景里可能是几十万 token 的额外 KV Cache 空间也可能是三倍以上的并发 batch 余量。用一句直白的话说容量上 MI355X 有先发优势而且这个优势在长上下文场景里会被持续放大。2.2 互联带宽张量并行通信才是多卡性能的隐形天花板显存容量大不等于实际吞吐就高多卡并行时互联带宽往往才是瓶颈。MoE 模型的通信模式很“吃”互联每次前向都要做路由把 token 分发到不同专家再收集结果这个过程会产生大量点对点通信。专家如果分布在多张卡上通信量还会翻倍。NVIDIA B200 的 NVLink 全互联方案双向带宽能做到 1.8TB/s 级别8 卡之间任意通信都走高速路径MI355X 这边如果只是用标准 PCIe Gen5 x16单条链路只有 128GB/s 左右必须走 AMD 的私有互联方案才能把带宽顶上去但全互联拓扑的成熟度、驱动支持和主板设计都比 NVLink 环境更考验厂商功底。实际部署中MoE 模型在互联带宽不够宽的环境下多卡扩展效率可能从线性掉到百分之七八十甚至更低。所以整机吞吐的差距从来不是单卡参数简单相加。2.3 先给结论部署边界基本决定了下文性能差距这里我想先把结论抛出来免得后面算了一大堆数字读者反而迷失。如果你的业务一定要跑 512K 超长上下文而且每天要扛高并发MI355X 的显存余量是必须优先考虑的因素如果你的业务主要是几十 K 以内的上下文追求低延迟和 high concurrencyB200 在算力和互联上的优势更值钱。这个粗颗粒度的判断比一开始就盯着某个算子的快慢更有指导意义。因为 GLM5.2 的推理负载不是孤立的算子竞速而是显存、带宽、通信、调度四者的综合博弈。边界画清楚之后prefill 和 decode 两个阶段的性能差距才有讨论意义。3. prefill阶段B200算力优势的兑现与折扣3.1 prefill为什么是算力密集型大模型推理通常分成两个阶段先用用户输入做一次完整前向计算叫 prefill也叫预填充然后逐 token 生成回复叫 decode。prefill 阶段要同时计算整段输入序列的注意力矩阵本质上是高密度矩阵乘法所以对算力的要求极高。B200 的 FP8 峰值算力在厂商口径下明显高于 MI355X大致高出三到五成。在理想状态下这意味着 B200 的 prefill 吞吐应该有压倒性优势。实际跑 GLM5.2 时这个优势确实存在但存在一个前提你把模型放在单卡或者极少数卡上跑。一旦进入多卡张量并行互联带宽和调度效率会立刻介入高算力不一定能完全转换成为有效吞吐。3.2 FP8与长上下文会让差距更明显还是缩小FP8 是 GLM5.2 时代最主流的推理加速选项两张卡都支持。用 FP8 之后权重读取的字节数直接减半但 prefill 的算术运算量基本不变所以 B200 的算力优势依然成立。问题在于长上下文场景中prefill 的瓶颈经常不是算力而是注意力计算产生的中间状态写不回显存。上下文一长prefill 阶段产生的 attention 中间结果也会变大显存不够就只能做 chunked prefill把长输入切成小块重复计算。这种时候MI355X 的 288GB 大显存就变成了缓冲垫能让框架少切块、少重算。于是 B200 的算力优势被长上下文的显存瓶颈稀释了一部分。短文本上可能赢 20% 以上长文本上差距可能缩小到个位数。3.3 多卡通信在prefill里的实际影响做压测时我还发现一个容易忽略的点prefill 阶段的多卡通信尤其是 MoE 模型的 all-to-all 通信对互联带宽非常敏感。B200 的 NVLink 全互联延迟更低所以四卡或八卡并行时长序列的专家路由合并更顺畅MI355X 如果互联拓扑没调好prefill 吞吐和单卡标称会产生明显落差。但要注意社区里 vLLM 和 SGLang 对 MoE 的张量并行调度已经做了大量优化比如通信计算重叠实际差距未必像理论分析那么夸张。我给团队做评测时的经验是短文本、小 batch、对首 token 时延敏感的场景B200 能赢出 20% 以上大 batch、长输入、离线批处理为主的场景两者的差距会收窄到 10% 以内。4. decode阶段带宽为王MI355X并不吃亏4.1 一个公式看懂decode瓶颈decode 阶段每生成一个 token都要重新读一遍模型权重和当前 KV Cache 相关数据算术强度相对低显存带宽几乎决定了生成速度的上限。估算公式很简单每秒生成 token 数约等于显存带宽除以每 token 需要读取的字节数。拿 GLM5.2 举例假设激活参数量约 50B用 FP8 存储每生成一个 token 至少要读大约 50GB 的权重再加上 KV Cache 读取。两张卡的带宽都在 8TB/s 量级算下来单请求的 decode 上限大概在 100 到 160 token/s。这个公式一摆结论就很清楚了单卡单请求的 decode 速度两张卡不会有代差真正的变量是显存容量能撑住多大的 batch。4.2 大显存容量如何在decode阶段反哺吞吐decode 阶段最怕的是显存不够装下更多并发请求。并发一高显存不够就只能降 batch或者不停地在显存和 CPU 内存之间搬数据。数据一搬生成速度立刻拉胯这种损失比算力差还难补。MI355X 的 288GB 比 B200 多 96GB在同等权重占用下能容纳更大的 batch。batch 大了虽然每个请求的速度会略微下降但整卡单位时间产出的 token 总数会明显上升。这个特性让 MI355X 在高并发长上下文场景下有机会反超 B200。打个比方高速路限速差不多但 MI355X 车道更多能同时跑的车更多。4.3 单卡生成速率的估算对比给一个参考范围GLM5.2 用 FP8 部署单卡单请求的情况下两张卡都可能跑在 90 到 130 token/s 左右当 batch 从 1 涨到 32 时B200 靠更高的算力能在计算侧多扛一点MI355X 则靠更大的 KV Cache 空间把 batch 撑起来单位时间总产出同样不低。两者整体差距通常在 10% 以内远没有 prefill 阶段那么悬殊。这也是为什么很多只测生成速度的评测最后得出结论“这两张卡差不多”——单看 decode确实就是差不多。5. 长上下文与并发场景下的吞吐推演5.1 测试口径和配置说明接下来这组数字不是实验室精确实测而是按公开参数和主流推理框架配置推演的参考区间目的是把场景差异说清楚。统一假设GLM5.2 开源版本按 FP8 存储张量并行 8 卡KV Cache 不量化输入长度 8K输出长度 1Kbatch 大小由显存余量自动调整。这个配置比较接近真实私有化部署也方便观察趋势。必须提醒一句任何数值都会因模型版本、框架版本、驱动版本而变化所以别把表格里的数字当圣旨重点看相对关系和瓶颈迁移。5.2 四个典型场景的估算结果场景并发/批次主要瓶颈B200系统吞吐估MI355X系统吞吐估短文本办公问答64并发prefill算力高中低32K上下文客服128并发显存带宽中高高128K长文档分析64并发KV Cache容量中高512K超长上下文8并发KV Cache容量低/易OOM中等/稳定最值得关注的是 512K 那一行。B200 的 192GB 显存在极端长上下文下很容易被 KV Cache 撑爆哪怕算力再高模型也跑不起来MI355X 的 288GB 至少多了一层缓冲能让极端场景有生存空间。短文本高并发时B200 的优势非常明显一旦上下文长度拉长MI355X 的翻盘不是靠算力而是靠“装得下”。5.3 场景越极端结论越不同这也是我反复和团队强调的硬件评测不能脱离负载看结论。拿 GLM5.2 去测短文本场景的结论是“B200 更强”把输入拉到百 K 以上结论就变成“MI355X 更合适”。两个结论都不错但它们适用的场景完全不同。所以看到网上有人拿一张卡测了一组数据就下结论我都会先去看它的上下文长度、batch 设置和量化方式再决定要不要信。尤其是长上下文模型显存容量才是第一生命线很多评测为了跑分好看把 batch 压得很低等于主动放弃了容量维度。6. 成本账本别只看单价要看每token成本6.1 采购价、功耗和机房摊销价格这件事最容易踩坑。按当前能打听到的渠道行情B200 单卡价格仍然高出同代 AMD 旗舰不少MI355X 在板卡采购价上大约能便宜三到四成有些渠道折扣拉满甚至更多。但只比采购价没有任何意义因为功耗、散热、机房改造的成本都要算进去。两张卡 TDP 都站在 900W 到 1200W 附近整机功耗差距不会太大真正的差异在于 B200 能用同样的电力预算换来更高的 prefill 吞吐等于把电费花得更“出活”。6.2 每token成本怎么算我建议所有选型团队统一口径每 token 成本 硬件折旧 电力成本 机房摊销/ 生命周期内可产出 tokens。以 3 年折旧、每天跑满 16 小时、平均使用率 70% 来算一张 B200 和一张 MI355X 各自的年产 tokens 取决于业务负载类型。简单说短文本高并发场景B200 的每 token 成本可能反而更低长文本高并发场景MI355X 因为大显存带来的吞吐优势每 token 成本会显著胜出。指标B200方案MI355X方案单卡参考采购价高约低30%-40%单卡HBM容量192GB288GB互联方式NVLink 约1.8TB/sAMD私有互联或PCIe短文本每token成本推演偏低中等长上下文每token成本推演偏高偏低软件踩坑风险低中高6.3 空闲率对真实成本的杀伤力比单价和每 token 成本更重要的其实是利用率。如果买 MI355X 是为了省钱结果因为 ROCm 适配问题、框架 bug 或者团队没人会调卡跑不满那省下的三成卡价会在几个月内被闲置时间吃掉。反过来如果计划里大部分流量都是短文本高并发B200 的每 token 成本优势又会被高采购价抵消一大部分。所以成本分析永远应该是“先定负载再定卡”而不是先选卡再分析负载。很多团队选型翻车都翻在把“便宜”当成“划算”没把业务负载结构算清楚。7. 软件生态和框架适配决定理论性能能不能落地7.1 vLLM/SGLang的适配成熟度差异NVIDIA 的 CUDA 生态让 B200 在 vLLM、SGLang、TensorRT-LLM 这些框架里几乎开箱即用。GLM5.2 这种热门模型算子优化通常一两周内就有人提交 PR社区踩坑记录也丰富出问题很容易搜到解决方案。MI355X 在 ROCm 体系里虽然比 MI300X 早期要成熟不少vLLM 的 ROCm 后端、AMD 官方工具链都能跑但如果你想用 SGLang 最新版本的一些激进调度特性可能就要自己编译或等适配周期。这里我强调一下采购前一定要去框架的 GitHub issue 里搜一下目标框架对 MI355X 的支持状态别默认“MI300X 能跑就代表 MI355X 也能跑”。7.2 ROCm至今的处境能跑但你要多花时间用一个类比CUDA 像成熟的手机系统装 App 就完事ROCm 更像 Linux 桌面发行版能高度定制但默认配置总需要折腾。对于 GLM5.2 的 FP8 推理ROCm 上能跑通但要调 FlashAttention 后端选择、KV Cache 量化开关、通信库绑定这些细节。在 NVIDIA 卡上这些环节默认优化基本到位在 AMD 卡上可能每一步都要亲手验证一遍。团队里如果有一两个能啃源码的工程师MI355X 的性价比优势才能兑现如果团队全是业务开发没有专门做推理加速的人选 MI355X 之前一定要慎之又慎。软件层面的隐性成本比卡价便宜的那部分要大得多。7.3 一套可落地的部署检查清单如果决定用任意一张卡跑 GLM5.2建议先过一遍这份清单第一确认部署框架是否支持 FP8 权重和 KV Cache 量化第二确认通信后端是否正确绑定 RDMA 和拓扑检测第三用小权重先跑通再切全量模型第四把长上下文的显存余量做成监控指标别等 OOM 才处理第五MI355X 要提前锁死 ROCm 版本和 PyTorch 版本的匹配组合能复现的配置比新版本更重要。这套清单能避免大部分翻车场景。8. 选型建议不同预算和业务阶段怎么下手8.1 三个典型场景的决策矩阵场景 A在线客服、办公助手类输入只有几百字要求首 token 快并发高且预算充足。选 B200CUDA 生态成熟、prefill 算力足时延和吞吐都有保障。场景 B报告总结、长文分析、离线批处理上下文动辄几十 K 到上百 K成本敏感。选 MI355X288GB 显存带来的 KV Cache 余量是关键成本优势也明显。场景 C混合业务长短文本都有团队规模不大。建议先用 B200 搭建主线再用 MI355X 做长文本专用池或容灾。如果预算只够买一种卡先看模型权重能不能量化、上下文长度是否还会继续增长再决定买谁。8.2 我的个人体会先算online/offline混合比再决定买谁我自己的选型流程很简单先把所有业务按 online首 token 敏感、短文本和 offline批处理、长文本分类统计每天各自占用的 token 量再按两种卡的估算吞吐算总成本。这个流程跑下来很多结论会自动浮出来一上来就想“AMD 便宜买 AMD”的团队往往忽略了在线业务占比其实很高无脑上 B200 的决定也会在长文本批处理上浪费不少预算。最后分享一条经验新卡刚出来时最贵的是时间成本不是卡本身。MI355X 参数确实能打但生态和框架的成熟度曲线要认真评估B200 贵一点但它能让你把更多精力留给业务。把时间成本算进选型答案通常会清晰很多。