如果只看显存数字288GB听起来也就是个更大一点的硬盘。但放在AI模型部署语境里这个容量直接决定了你能碰多大的模型、多长的上下文、多少并发请求。我接触的很多朋友拿着这个参数来问能不能跑70B其实背后真正想知道的是我的场景到底该选哪块卡。这篇文章不堆参数表我把从显存换算、模型参数量到KV Cache、MOE架构这些环节一次性算清楚看完你也能自己估出答案。1. 显存和模型参数的换算账一张图看懂288GB能装什么1.1 先记住这个基础公式参数量乘上精度字节数模型能不能塞进显存本质是一道乘法题。Step 1确认模型参数量比如7B就是70亿参数70B就是700亿参数。Step 2确认存储精度FP16半精度每个参数占2字节FP8占1字节INT8也是1字节INT4占0.5字节。Step 3相乘得到模型权重的显存占用。举个例子70B模型用FP16加载权重部分就是 70 × 10^9 × 2字节 ≈ 140GB。FP8加载则约70GBINT4量化后约35GB。这是纯权重还不算推理时额外开销。所以显存能装多大模型这个问题至少要先回应答精度否则72B模型在不同精度下需要36GB到144GB不等差了4倍。1.2 推理不是加载完就完事KV Cache和激活值会吃掉第二份空间很多人以为显存 模型文件大小这是最常见的误解。模型跑起来后前向计算过程会持续产生两类额外占用一是KV Cache键值缓存用于保存注意力机制里已计算过的Key和Value二是激活值Activations即每一层计算过程中的中间结果。KV Cache的估算可以粗算为2 × 层数 × 注意力头数 × 序列长度 × 批量大小 × 精度字节数。实际感受是一个7B模型在4096序列长度下KV Cache大概占用1~2GB如果把序列拉到128KKV Cache能做到几十GB。激活值在推理阶段相对较小但长序列、大并发时也会明显增长。框架自身还会留一些bufferCUDA context这部分就要占几百MB到几GB。所以部署时用的估算公式应该是总显存 ≈ 参数量 × 精度字节数 KV Cache占用 激活值 框架开销约1~3GB看起来有点复杂但落到实际选型就可以简化成两条经验线密集模型按参数量的2倍FP16或1倍FP8粗估权重再给KV Cache留20%~40%余量MOE模型按总参数量算权重占用但计算量和KV Cache的增速相对温和。1.3 B300的288GB具体能装什么规模的模型拿288GB去套上面的公式场景就清晰了。以下几个都是实际部署中常见的模型量级我按不同精度列了一张比较实用的速查表模型规模FP16权重占用FP8权重占用INT4量化权重占用288GB能否直接装下14B~28GB~14GB~7GB轻松还能跑长上下文大并发32B~64GB~32GB~16GB轻松70B~140GB~70GB~35GB很宽裕留大量空间给KV Cache130B~260GB~130GB~65GBFP16贴近极限FP8/INT4宽裕200B~400GB~200GB~100GBFP8可装需要控制KV Cache405B~810GB~405GB~200GBFP8不够INT4刚够但上下文受限注意上面说的是密集Transformer模型。单张B300在FP8精度下能跑的密集模型上限大约在200~250B参数如果上INT4量化405B级别也有机会塞进去只是序列长度和并发数量会被KV Cache压得很紧。这些结果和很多人直觉中的288GB应该能装500B相差不小——因为权重之外的开销确实占着规模的三四成。2. B300不只是显存变大这代产品改了什么才值钱2.1 从Blackwell到Blackwell Ultra显存、带宽、算力同步提升B300属于Blackwell Ultra这一代和之前的Blackwell比如B200相比显存从192GB提升到288GB提升幅度50%。很多文章只盯着容量但显存升级如果没有带宽跟上就像一个水库建得很大但引水渠很窄水根本送不进去。B300搭载的是HBM3e高带宽内存整体带宽达到8TB/s量级。这是什么概念一张消费级RTX 4090的显存带宽是1TB/s左右也就是说B300的带宽接近它的8倍。对大模型推理而言带宽和显存容量同等重要因为每个token生成都要把全部权重从显存读一遍带宽越高每个token的生成速度越快。算力方面B300的FP4算力比B200又上了一个台阶大概在20~30 PFLOPS量级。放到实际场景就是同样是跑一个70B模型的FP8推理B300的吞吐能比上一代H100约80GB HBM高出数倍其中一部分来自显存更大不用频繁调度另一部分来自算力和带宽同步提升。所以说288GB不是孤立参数它是容量、带宽和算力三者在同一个平台上互相配合的结果。2.2 双芯设计和高带宽内存背后的工程取舍B300延续了Blackwell的双die封装思路即一块物理芯片内部包含两个计算核心。两个die之间通过高带宽互联整合成一张卡对外表现为统一的显存池和算力池。这种设计的好处不用多说显存容量、带宽和算力都翻倍但代价是功耗也上来了B300的TDP已经到1400W上下散热方案、服务器供电、数据中心暖通工程都要跟着改。这也是为什么B300越来越多出现在整机柜方案里而不是单卡插到老服务器里用。对于个人用户来说这个功耗意味着什么它基本宣告了B300不是一块插上就能用的消费级显卡它需要对应的整机配套液冷或者高规格风冷、2000W级别的电源模块、CPU平台对PCIe Gen5和NVLink的支持等等。很多人以为买一张卡就完事了实际上配套成本可能比卡本身还高。这块后面选型章节会细说。2.3 NVLink与显存池化单卡装不下互联来凑单张B300有288GB但如果你想跑的模型需要400GB甚至700GB权重怎么办答案是走NVLink互联。B300支持第五代NVLink单卡双向带宽约1.8TB/s多卡之间可以把显存池化成一个大的显存空间。举个典型配置两张B300通过NVLink连接显存池化后约576GBFP8精度下跑405B模型就非常从容了4张B300则是1.1TB级别显存配合NVLink带宽做流水线并行或张量并行都绰绰有余。这里要注意显存池化不等于显存容量简单相加那么美好跨卡的通信开销会因为并行策略不同有很大差异。比如张量并行Tensor Parallelism对卡间带宽极度敏感NVLink的高带宽在这里是刚需如果全是PCIe通信性能会明显下降。所以多卡方案里卡间互联协议的重要性不亚于显存容量本身。3. MOE架构的甜点区为什么288GB遇到稀疏激活反而更香3.1 一个高频问题MOE部署是不是总参数必须全部进显存最近MoEMixture of Experts混合专家架构很火从Mixtral到DeepSeek系列再到MiniMax H3这类新模型几乎都在用MOE。一个77亿参数的模型实际总参数量能做到200多亿而激活参数可能只有一半甚至更少。很多人因此产生一个误解MOE模型既然是稀疏激活部署时是不是可以只加载一部分专家进显存答案是推理时通常不能只加载部分专家。MOE的路由机制是动态的不同token会被路由到不同的专家上你无法提前预测哪个专家会被用到。所以权重部分仍然要把全部专家加载到显存里否则路由到未加载的专家时就会出现换入换出延迟高到不可用。MOE降低的是计算量FLOPs不是显存占用。在显存规划时MOE模型依然按总参数量计算权重占用。3.2 为什么B300的288GB特别适合跑MOE模型MOE模型总参数量大 激活参数量相对小这正好落在B300的优势区间。一个典型的例子某个总参数量400B的MOE模型激活参数可能只有10B左右FP8权重加载约400GB单卡B300装不下但计算本身非常轻。这时候可以用NVLink多卡并行或者Offload部分专家到CPU内存推理性价比会非常高。更典型的场景是DeepSeek这类总参数670B量级的MOE模型。FP8权重大约670GB一张288GB的B300装不下但如果用INT4量化把权重压到350GB上下然后再叠一张卡或者用CPU offload兜底就能跑得动。很多团队的实际部署方案就是多卡量化CPU Offload投机解码三板斧把B300的显存压榨到极致。如果全用FP16加载这种规模的MOE模型的显存需求会直接翻倍到1.3TB以上预算差距是百万级的。3.3 KV Cache在MOE模型里反而更友好MOE模型的KV Cache占用一般只与模型的总层数、注意力头数和序列长度相关和专家数量关系不大。总参数量大但KV Cache占用增长相对平缓这意味着给长上下文和并发请求留下的空间比同等总参数量密集模型要大得多。也就是说B300跑MOE模型时288GB里真正紧张的是权重KV Cache的余地反而比预期宽裕。这也反过来解释了为什么很多大模型服务商越来越倾向MOE架构部署成本中计算资源算力被稀疏激活显著压低而显存容量成为了主要约束。B300这种大显存高带宽高算力的组合恰好是MOE模型推理的基础设施甜点。4. 带宽和KV Cache才是真正的隐形天花板4.1 KV Cache算起来比模型权重更快失控模型权重是一次性的静态占用跑起来几乎不变。但KV Cache是动态增长的序列越长、并发越高KV Cache增长得越快。经验值是序列长度从4K涨到128KKV Cache能膨胀30倍以上。以一个70B密集模型FP8部署为例模型权重占70GB288GB的显存还剩218GB。如果每条请求的上下文是32K每个token的KV Cache约0.2MB这个数值因模型结构而异那么并发数稍微拉上去比如64路并发KV Cache就可能吃掉数十GB。很多人部署时觉得模型装得下就行了结果一压测就OOM问题几乎都出在被忽略的KV Cache上。4.2 HBM带宽决定每秒吐多少个字显存带宽决定了模型推理时的实际速度。预填充Prefill阶段要读大量权重逐token生成Decode阶段每生成一个token都要重新读一遍全部权重。带宽越大单位时间能喂给计算核心的参数越多。用实际数字感受一下假设一个70B模型FP8权重为70GB如果显存带宽是8TB/s理论上每秒钟能把全部权重读约114遍对应每秒能生成110多个token极其理想化的估算实际还要受限于算力和访存效率。如果换成带宽仅1TB/s的消费级显卡同样场景每秒只能读14遍生成速度会直线下滑。所以做部署时不能只看装得下还要看跑得快。B300这类数据中心的显存带宽是消费级卡的8~9倍这才是它贵得多的核心原因之一。如果你的需求只是离线批量处理、对延迟和吞吐不敏感那么用低带宽的大容量显存方案可能更划算如果要服务高并发在线推理带宽比容量更容易成为瓶颈。4.3 长上下文场景的显存规划实操部署长上下文模型比如128K、256K甚至1M时我给一个可复用的估算思路Step 1算权重占用 参数量 × 精度字节数Step 2估算KV Cache 单token KV Cache大小 × 序列长度 × 并发数Step 3把激活值和框架开销加上约1~5GB取决于batch大小和优化程度Step 4对比目标显存容量留出至少10%余量单token KV Cache大小不会在模型卡上直接标出但可以通过实际测试来量先用目标模型加载一个短序列看看显存占用再加载长序列两者之差除以序列长度差就能得到单token的KV Cache占用。这个方法在部署实测中很实用比按公式推算更贴合实际。5. 显存不够时的降级打法量化、逐层卸载与投机解码5.1 量化优先级FP8是平衡点INT4是极限压榨模型量化是解决显存不足最直接的手段。FP8几乎是无损替代感知不到质量差异显存直接减半INT8同理INT4能把显存压到FP16的四分之一但质量下降在部分任务上能感知尤其是推理、数学、代码这类对精度敏感的生成。我的建议推理服务优先上FP8兼顾质量和吞吐离线批量处理可以用INT4换取速度但需要做质量回归。另外很多新模型原生发布GGUF格式里面有各种量化等级Q4_K_M、Q5_K_M、Q8_0等建议用progressive方式选从Q8_0开始质量没明显坍缩就保持不行再降。5.2 逐层卸载把不常用的部分放到CPU内存当模型比显存大又不想牺牲太多精度时Offload逐层卸载是一个务实选择。原理很简单把部分层的权重放到CPU内存用到时再往显存搬运。代价是速度因为PCIe带宽即便PCIe 5.0也就是几十GB/s比显存带宽低一两个数量级。长序列生成时每生成一个token都要搬运权重CPU Offload的延迟会明显拉高。实际部署中的经验在B300这类卡上Offload主要用来兜底而不是常规方案。比如2卡B300跑700GB的MOE模型时可以把10%~20%的专家Offload到CPU内存配合计算调度性能损失可以控制在可接受范围内。如果这个比例超过40%就得认真考虑能不能通过更低位宽的量化来降低需求。5.3 投机解码用零成本的方式把吞吐拉起来当你辛辛苦苦把模型塞进288GB后会发现新的约束变成生成速度。投机解码Speculative Decoding是一个很实用的优化用一个很小的草稿模型Draft Model先快速生成一串token再由大模型一次性验证。因为小模型成本低、验证是并行的整体吞吐可以提升1.5~3倍。这个方案在B300上效果尤其好因为大模型算力强验证阶段几乎不吃亏而草稿模型又占不了多少显存相当于在288GB里抽出一小块换数倍吞吐。很多推理框架vLLM、TensorRT-LLM等已经把投机解码做成开箱功能强烈建议优先打开。另外一个同类的优化叫vLLM的continuous batching把多个请求动态拼到一个batch里显存利用率会大幅提升对高并发场景效果立竿见影。6. 从288GB回看你的实际需求选卡前的三笔账6.1 不同显存档位适合跑什么模型一张速查表不是所有人都需要B300但不同显存大小决定了你能跑什么模型。整理了一份速查表方便按自己手上的预算和模型需求定位显存容量适合部署的模型规模典型使用场景8~12GB3B~7B模型量化后上下文受限个人电脑跑小模型、AI编程助手16~24GB7B~14B模型量化后更宽裕中型上下文本地文档分析、代码补全、数字人原型48~80GB14B~70B模型FP8/量化较长上下文多路推理、中型Agent、调优环境192~288GBB300级别70B~250B密级模型、400B量化MOE模型大规模服务、长上下文Agent、企业级推理多卡NVLink池化250B密集模型、700B量化MOE模型多租户大模型服务、全参数微调验证6.2 选卡看三个维度训练还是推理、在线还是离线、量级多大第一笔账训练和推理的需求完全不同。训练时显存不仅要放权重还要放优化器状态、梯度和激活值通常比推理多2~4倍。一个70B模型做全参数微调FP16权重140GB 优化器状态AdamW一般每个参数占12字节约840GB 梯度140GB轻松超过1TB单卡B300想都不要想。所以训练场景真正需要的是多卡并行加显存池化。如果只是推理或LoRA这类参数高效微调单卡288GB则非常舒适。第二笔账在线和离线的差别。离线批量任务对延迟不敏感可以通过调大batch、降低并发数量来压榨显存利用率在线服务则必须有稳定P99延迟KV Cache预留和并发上限要严格设计。同一个288GB离线可能跑200B模型在线服务可能只能跑到130B差距就在这里。第三笔账规模再往上的长期演进。如果你明确知道自己未来半年要跑的模型会从70B涨到200B甚至400B那就要提前考虑多卡NVLink方案而不是买一堆单卡在PCIe交换机上互相拖后腿。B300的高带宽互联特性让它在这条路径上很有优势。6.3 从实操角度的最后建议如果你在评估B300或类似288GB显存的卡我最想强调的不是参数而是配套系统。700W级别的H100还能用风冷勉强压住1400W级别的B300则需要认真规划散热和供电。很多项目死在部署阶段不是模型装不下而是机房环境扛不住。建议在方案里把液冷模组、供电冗余、NVLink拓扑一并设计好有条件就用官方整机柜或者认证合作伙伴的方案。对个人开发者如果你现在的需求只是跑跑7B、14B模型B300完全是杀鸡用牛刀。24GB的消费卡配合好量化策略就能解决大部分问题。所以最终答案是288GB能装下的模型上限确实吓人但真正决定你该不该买它的是你的业务需求、并发规模和配套成本三件事参数本身反而不是决定性因素。我第一次在实验室看到B300的满载功耗时第一反应不是这卡太强了而是机房空调要加几台。显存从192GB涨到288GB背后是整个配套体系的升级。如果你正在做选型建议先回答自己三个问题要跑多大模型、服务多少并发、机房扛不扛得住。答案都明确了显卡选型自然水落石出。
288GB显存能装多大模型？B300部署显存计算与选型指南
如果只看显存数字288GB听起来也就是个更大一点的硬盘。但放在AI模型部署语境里这个容量直接决定了你能碰多大的模型、多长的上下文、多少并发请求。我接触的很多朋友拿着这个参数来问能不能跑70B其实背后真正想知道的是我的场景到底该选哪块卡。这篇文章不堆参数表我把从显存换算、模型参数量到KV Cache、MOE架构这些环节一次性算清楚看完你也能自己估出答案。1. 显存和模型参数的换算账一张图看懂288GB能装什么1.1 先记住这个基础公式参数量乘上精度字节数模型能不能塞进显存本质是一道乘法题。Step 1确认模型参数量比如7B就是70亿参数70B就是700亿参数。Step 2确认存储精度FP16半精度每个参数占2字节FP8占1字节INT8也是1字节INT4占0.5字节。Step 3相乘得到模型权重的显存占用。举个例子70B模型用FP16加载权重部分就是 70 × 10^9 × 2字节 ≈ 140GB。FP8加载则约70GBINT4量化后约35GB。这是纯权重还不算推理时额外开销。所以显存能装多大模型这个问题至少要先回应答精度否则72B模型在不同精度下需要36GB到144GB不等差了4倍。1.2 推理不是加载完就完事KV Cache和激活值会吃掉第二份空间很多人以为显存 模型文件大小这是最常见的误解。模型跑起来后前向计算过程会持续产生两类额外占用一是KV Cache键值缓存用于保存注意力机制里已计算过的Key和Value二是激活值Activations即每一层计算过程中的中间结果。KV Cache的估算可以粗算为2 × 层数 × 注意力头数 × 序列长度 × 批量大小 × 精度字节数。实际感受是一个7B模型在4096序列长度下KV Cache大概占用1~2GB如果把序列拉到128KKV Cache能做到几十GB。激活值在推理阶段相对较小但长序列、大并发时也会明显增长。框架自身还会留一些bufferCUDA context这部分就要占几百MB到几GB。所以部署时用的估算公式应该是总显存 ≈ 参数量 × 精度字节数 KV Cache占用 激活值 框架开销约1~3GB看起来有点复杂但落到实际选型就可以简化成两条经验线密集模型按参数量的2倍FP16或1倍FP8粗估权重再给KV Cache留20%~40%余量MOE模型按总参数量算权重占用但计算量和KV Cache的增速相对温和。1.3 B300的288GB具体能装什么规模的模型拿288GB去套上面的公式场景就清晰了。以下几个都是实际部署中常见的模型量级我按不同精度列了一张比较实用的速查表模型规模FP16权重占用FP8权重占用INT4量化权重占用288GB能否直接装下14B~28GB~14GB~7GB轻松还能跑长上下文大并发32B~64GB~32GB~16GB轻松70B~140GB~70GB~35GB很宽裕留大量空间给KV Cache130B~260GB~130GB~65GBFP16贴近极限FP8/INT4宽裕200B~400GB~200GB~100GBFP8可装需要控制KV Cache405B~810GB~405GB~200GBFP8不够INT4刚够但上下文受限注意上面说的是密集Transformer模型。单张B300在FP8精度下能跑的密集模型上限大约在200~250B参数如果上INT4量化405B级别也有机会塞进去只是序列长度和并发数量会被KV Cache压得很紧。这些结果和很多人直觉中的288GB应该能装500B相差不小——因为权重之外的开销确实占着规模的三四成。2. B300不只是显存变大这代产品改了什么才值钱2.1 从Blackwell到Blackwell Ultra显存、带宽、算力同步提升B300属于Blackwell Ultra这一代和之前的Blackwell比如B200相比显存从192GB提升到288GB提升幅度50%。很多文章只盯着容量但显存升级如果没有带宽跟上就像一个水库建得很大但引水渠很窄水根本送不进去。B300搭载的是HBM3e高带宽内存整体带宽达到8TB/s量级。这是什么概念一张消费级RTX 4090的显存带宽是1TB/s左右也就是说B300的带宽接近它的8倍。对大模型推理而言带宽和显存容量同等重要因为每个token生成都要把全部权重从显存读一遍带宽越高每个token的生成速度越快。算力方面B300的FP4算力比B200又上了一个台阶大概在20~30 PFLOPS量级。放到实际场景就是同样是跑一个70B模型的FP8推理B300的吞吐能比上一代H100约80GB HBM高出数倍其中一部分来自显存更大不用频繁调度另一部分来自算力和带宽同步提升。所以说288GB不是孤立参数它是容量、带宽和算力三者在同一个平台上互相配合的结果。2.2 双芯设计和高带宽内存背后的工程取舍B300延续了Blackwell的双die封装思路即一块物理芯片内部包含两个计算核心。两个die之间通过高带宽互联整合成一张卡对外表现为统一的显存池和算力池。这种设计的好处不用多说显存容量、带宽和算力都翻倍但代价是功耗也上来了B300的TDP已经到1400W上下散热方案、服务器供电、数据中心暖通工程都要跟着改。这也是为什么B300越来越多出现在整机柜方案里而不是单卡插到老服务器里用。对于个人用户来说这个功耗意味着什么它基本宣告了B300不是一块插上就能用的消费级显卡它需要对应的整机配套液冷或者高规格风冷、2000W级别的电源模块、CPU平台对PCIe Gen5和NVLink的支持等等。很多人以为买一张卡就完事了实际上配套成本可能比卡本身还高。这块后面选型章节会细说。2.3 NVLink与显存池化单卡装不下互联来凑单张B300有288GB但如果你想跑的模型需要400GB甚至700GB权重怎么办答案是走NVLink互联。B300支持第五代NVLink单卡双向带宽约1.8TB/s多卡之间可以把显存池化成一个大的显存空间。举个典型配置两张B300通过NVLink连接显存池化后约576GBFP8精度下跑405B模型就非常从容了4张B300则是1.1TB级别显存配合NVLink带宽做流水线并行或张量并行都绰绰有余。这里要注意显存池化不等于显存容量简单相加那么美好跨卡的通信开销会因为并行策略不同有很大差异。比如张量并行Tensor Parallelism对卡间带宽极度敏感NVLink的高带宽在这里是刚需如果全是PCIe通信性能会明显下降。所以多卡方案里卡间互联协议的重要性不亚于显存容量本身。3. MOE架构的甜点区为什么288GB遇到稀疏激活反而更香3.1 一个高频问题MOE部署是不是总参数必须全部进显存最近MoEMixture of Experts混合专家架构很火从Mixtral到DeepSeek系列再到MiniMax H3这类新模型几乎都在用MOE。一个77亿参数的模型实际总参数量能做到200多亿而激活参数可能只有一半甚至更少。很多人因此产生一个误解MOE模型既然是稀疏激活部署时是不是可以只加载一部分专家进显存答案是推理时通常不能只加载部分专家。MOE的路由机制是动态的不同token会被路由到不同的专家上你无法提前预测哪个专家会被用到。所以权重部分仍然要把全部专家加载到显存里否则路由到未加载的专家时就会出现换入换出延迟高到不可用。MOE降低的是计算量FLOPs不是显存占用。在显存规划时MOE模型依然按总参数量计算权重占用。3.2 为什么B300的288GB特别适合跑MOE模型MOE模型总参数量大 激活参数量相对小这正好落在B300的优势区间。一个典型的例子某个总参数量400B的MOE模型激活参数可能只有10B左右FP8权重加载约400GB单卡B300装不下但计算本身非常轻。这时候可以用NVLink多卡并行或者Offload部分专家到CPU内存推理性价比会非常高。更典型的场景是DeepSeek这类总参数670B量级的MOE模型。FP8权重大约670GB一张288GB的B300装不下但如果用INT4量化把权重压到350GB上下然后再叠一张卡或者用CPU offload兜底就能跑得动。很多团队的实际部署方案就是多卡量化CPU Offload投机解码三板斧把B300的显存压榨到极致。如果全用FP16加载这种规模的MOE模型的显存需求会直接翻倍到1.3TB以上预算差距是百万级的。3.3 KV Cache在MOE模型里反而更友好MOE模型的KV Cache占用一般只与模型的总层数、注意力头数和序列长度相关和专家数量关系不大。总参数量大但KV Cache占用增长相对平缓这意味着给长上下文和并发请求留下的空间比同等总参数量密集模型要大得多。也就是说B300跑MOE模型时288GB里真正紧张的是权重KV Cache的余地反而比预期宽裕。这也反过来解释了为什么很多大模型服务商越来越倾向MOE架构部署成本中计算资源算力被稀疏激活显著压低而显存容量成为了主要约束。B300这种大显存高带宽高算力的组合恰好是MOE模型推理的基础设施甜点。4. 带宽和KV Cache才是真正的隐形天花板4.1 KV Cache算起来比模型权重更快失控模型权重是一次性的静态占用跑起来几乎不变。但KV Cache是动态增长的序列越长、并发越高KV Cache增长得越快。经验值是序列长度从4K涨到128KKV Cache能膨胀30倍以上。以一个70B密集模型FP8部署为例模型权重占70GB288GB的显存还剩218GB。如果每条请求的上下文是32K每个token的KV Cache约0.2MB这个数值因模型结构而异那么并发数稍微拉上去比如64路并发KV Cache就可能吃掉数十GB。很多人部署时觉得模型装得下就行了结果一压测就OOM问题几乎都出在被忽略的KV Cache上。4.2 HBM带宽决定每秒吐多少个字显存带宽决定了模型推理时的实际速度。预填充Prefill阶段要读大量权重逐token生成Decode阶段每生成一个token都要重新读一遍全部权重。带宽越大单位时间能喂给计算核心的参数越多。用实际数字感受一下假设一个70B模型FP8权重为70GB如果显存带宽是8TB/s理论上每秒钟能把全部权重读约114遍对应每秒能生成110多个token极其理想化的估算实际还要受限于算力和访存效率。如果换成带宽仅1TB/s的消费级显卡同样场景每秒只能读14遍生成速度会直线下滑。所以做部署时不能只看装得下还要看跑得快。B300这类数据中心的显存带宽是消费级卡的8~9倍这才是它贵得多的核心原因之一。如果你的需求只是离线批量处理、对延迟和吞吐不敏感那么用低带宽的大容量显存方案可能更划算如果要服务高并发在线推理带宽比容量更容易成为瓶颈。4.3 长上下文场景的显存规划实操部署长上下文模型比如128K、256K甚至1M时我给一个可复用的估算思路Step 1算权重占用 参数量 × 精度字节数Step 2估算KV Cache 单token KV Cache大小 × 序列长度 × 并发数Step 3把激活值和框架开销加上约1~5GB取决于batch大小和优化程度Step 4对比目标显存容量留出至少10%余量单token KV Cache大小不会在模型卡上直接标出但可以通过实际测试来量先用目标模型加载一个短序列看看显存占用再加载长序列两者之差除以序列长度差就能得到单token的KV Cache占用。这个方法在部署实测中很实用比按公式推算更贴合实际。5. 显存不够时的降级打法量化、逐层卸载与投机解码5.1 量化优先级FP8是平衡点INT4是极限压榨模型量化是解决显存不足最直接的手段。FP8几乎是无损替代感知不到质量差异显存直接减半INT8同理INT4能把显存压到FP16的四分之一但质量下降在部分任务上能感知尤其是推理、数学、代码这类对精度敏感的生成。我的建议推理服务优先上FP8兼顾质量和吞吐离线批量处理可以用INT4换取速度但需要做质量回归。另外很多新模型原生发布GGUF格式里面有各种量化等级Q4_K_M、Q5_K_M、Q8_0等建议用progressive方式选从Q8_0开始质量没明显坍缩就保持不行再降。5.2 逐层卸载把不常用的部分放到CPU内存当模型比显存大又不想牺牲太多精度时Offload逐层卸载是一个务实选择。原理很简单把部分层的权重放到CPU内存用到时再往显存搬运。代价是速度因为PCIe带宽即便PCIe 5.0也就是几十GB/s比显存带宽低一两个数量级。长序列生成时每生成一个token都要搬运权重CPU Offload的延迟会明显拉高。实际部署中的经验在B300这类卡上Offload主要用来兜底而不是常规方案。比如2卡B300跑700GB的MOE模型时可以把10%~20%的专家Offload到CPU内存配合计算调度性能损失可以控制在可接受范围内。如果这个比例超过40%就得认真考虑能不能通过更低位宽的量化来降低需求。5.3 投机解码用零成本的方式把吞吐拉起来当你辛辛苦苦把模型塞进288GB后会发现新的约束变成生成速度。投机解码Speculative Decoding是一个很实用的优化用一个很小的草稿模型Draft Model先快速生成一串token再由大模型一次性验证。因为小模型成本低、验证是并行的整体吞吐可以提升1.5~3倍。这个方案在B300上效果尤其好因为大模型算力强验证阶段几乎不吃亏而草稿模型又占不了多少显存相当于在288GB里抽出一小块换数倍吞吐。很多推理框架vLLM、TensorRT-LLM等已经把投机解码做成开箱功能强烈建议优先打开。另外一个同类的优化叫vLLM的continuous batching把多个请求动态拼到一个batch里显存利用率会大幅提升对高并发场景效果立竿见影。6. 从288GB回看你的实际需求选卡前的三笔账6.1 不同显存档位适合跑什么模型一张速查表不是所有人都需要B300但不同显存大小决定了你能跑什么模型。整理了一份速查表方便按自己手上的预算和模型需求定位显存容量适合部署的模型规模典型使用场景8~12GB3B~7B模型量化后上下文受限个人电脑跑小模型、AI编程助手16~24GB7B~14B模型量化后更宽裕中型上下文本地文档分析、代码补全、数字人原型48~80GB14B~70B模型FP8/量化较长上下文多路推理、中型Agent、调优环境192~288GBB300级别70B~250B密级模型、400B量化MOE模型大规模服务、长上下文Agent、企业级推理多卡NVLink池化250B密集模型、700B量化MOE模型多租户大模型服务、全参数微调验证6.2 选卡看三个维度训练还是推理、在线还是离线、量级多大第一笔账训练和推理的需求完全不同。训练时显存不仅要放权重还要放优化器状态、梯度和激活值通常比推理多2~4倍。一个70B模型做全参数微调FP16权重140GB 优化器状态AdamW一般每个参数占12字节约840GB 梯度140GB轻松超过1TB单卡B300想都不要想。所以训练场景真正需要的是多卡并行加显存池化。如果只是推理或LoRA这类参数高效微调单卡288GB则非常舒适。第二笔账在线和离线的差别。离线批量任务对延迟不敏感可以通过调大batch、降低并发数量来压榨显存利用率在线服务则必须有稳定P99延迟KV Cache预留和并发上限要严格设计。同一个288GB离线可能跑200B模型在线服务可能只能跑到130B差距就在这里。第三笔账规模再往上的长期演进。如果你明确知道自己未来半年要跑的模型会从70B涨到200B甚至400B那就要提前考虑多卡NVLink方案而不是买一堆单卡在PCIe交换机上互相拖后腿。B300的高带宽互联特性让它在这条路径上很有优势。6.3 从实操角度的最后建议如果你在评估B300或类似288GB显存的卡我最想强调的不是参数而是配套系统。700W级别的H100还能用风冷勉强压住1400W级别的B300则需要认真规划散热和供电。很多项目死在部署阶段不是模型装不下而是机房环境扛不住。建议在方案里把液冷模组、供电冗余、NVLink拓扑一并设计好有条件就用官方整机柜或者认证合作伙伴的方案。对个人开发者如果你现在的需求只是跑跑7B、14B模型B300完全是杀鸡用牛刀。24GB的消费卡配合好量化策略就能解决大部分问题。所以最终答案是288GB能装下的模型上限确实吓人但真正决定你该不该买它的是你的业务需求、并发规模和配套成本三件事参数本身反而不是决定性因素。我第一次在实验室看到B300的满载功耗时第一反应不是这卡太强了而是机房空调要加几台。显存从192GB涨到288GB背后是整个配套体系的升级。如果你正在做选型建议先回答自己三个问题要跑多大模型、服务多少并发、机房扛不扛得住。答案都明确了显卡选型自然水落石出。
