在B200这种旗舰卡上跑一个8B参数的小模型很多人第一反应是大材小用。但当你把Qwen3-8B真正部署到单张B200上用压测脚本跑一轮之后会发现真正有意思的问题根本不是能不能跑而是为什么每秒出词数会被一个和算力无关的指标死死摁住。这个指标就是显存带宽。这篇文章记录我在单张B200上跑通Qwen3-8B的完整过程从理论推算到环境配置从实测数据到用profiling工具确认瓶颈最后聊一聊怎么用roofline模型判断你的推理场景到底缺算力还是缺带宽。适合正在做大模型推理优化、做性能调优或者准备做GPU选型的工程师参考。1. 项目背景与核心思路拆解1.1 为什么拿B200单卡跑Qwen3-8BB200是NVIDIA Blackwell架构的旗舰GPU单卡配备了192GB的HBM3e显存显存带宽做到了8TB/s。这个数字放在今天依然非常夸张比上一代H100 SXM的3.35TB/s高出大约2.4倍。把Qwen3-8B这样的8B模型放到B200上模型权重只占显存的一小部分显存容量完全不是问题算力也不是问题——问题是解码阶段的数据搬运速度。拿8B模型来做这个实验恰恰是为了让带宽瓶颈暴露得更纯粹。模型越小算力过剩越明显推理速度就越接近纯带宽约束的理论极限。如果换成几百B的大模型反而会引入显存装不下、多卡通信、流水线并行等一堆干扰因素。8B这个规模在B200上是轻轻松松装下跑起来见真章的状态非常适合用来做单卡推理性能的探针实验。做这个测试的另一个背景是Qwen3系列发布之后很多团队在评估用中等尺寸模型做生产级服务。8B这个档位既能在消费级显卡上勉强跑也能在数据中心卡上跑得很舒服是一个非常典型的部署样本。拿B200跑一遍相当于问了一个问题如果预算充足、单卡算力拉满8B模型的推理延迟和吞吐到底能到多少答案很大程度上取决于显存带宽。1.2 Qwen3-8B的显存占用与精度选择Qwen3-8B是一个Dense结构的8B参数模型不是MoE。8.03B参数按照不同精度存储权重占用的显存差别很大BF16约16GBFP8约8GBINT4约4GBBF16是模型发布的默认精度也是测试基准。FP8版本官方在模型仓库里直接提供了量化好的checkpoint省去了自己转换的麻烦。这代Blackwell架构对FP8有完整的硬件支持tensor core在FP8下的吞吐远高于BF16而模型的精度损失通常可以接受。所以我在B200上选择FP8版本作为主力测试对象核心逻辑很简单权重读取减半decode阶段的理论速度直接翻倍。INT4看起来带宽占用更小但在B200这类高算力卡上反量化的额外计算开销和kernel实现的复杂度会吃掉一部分带宽收益。我建议先在FP8上跑通流程拿到基线数据再考虑要不要压到INT4做对比。别一上来就追最小显存占用推理优化的方向不是模型越小越好而是在满足延迟目标的前提下最大化吞吐。1.3 一句话理解推理阶段的带宽困境大模型推理的两个阶段计算特征完全相反。Prefill阶段是用户输入的一整段prompt进来模型要并行处理所有token这时候计算量巨大tensor core满负荷运转属于计算密集compute-bound。Decode阶段是模型一个token一个token地往外蹦每生成一个token都要把整个模型的权重从HBM里读一遍但真正参与的计算量却很少。结果是GPU的算力大部分时间在闲着SM在等数据从显存里搬过来。打个比方prefill像是一次性把一整本厚厚的书复印出来复印机是全速运转的decode像是一个人隔几秒钟来复印一页每次都要把这个书从头翻开找到那一页再印大部分时间都花在翻书上。翻书的速度取决于你翻书的手速也就是显存带宽。所以单卡跑8B模型的瓶颈从来不是B200的算力不够而是数据搬运太慢。理解了这一点后面所有的调优动作都是围绕怎么减少搬运的数据量和怎么提高搬运效率展开的。2. 带宽瓶颈的原理从公式到实测预期2.1 Decode阶段为什么天然是带宽受限要理解这个问题的本质需要看两个简单的数字一次decode操作需要的计算量以及需要读取的数据量。对于一个N参数的模型生成一个token所需的浮点运算量大约是2N。Qwen3-8B就是大约16GFLOP16×10^9次浮点运算。而同时需要从显存中读取的权重数据量在BF16精度下是2N字节也就是16GBFP8下是8GB。算术强度arithmetic intensityAI指的是单位字节数据上承载的计算量BF16AI 2N / 2N 1 FLOP/ByteFP8AI 2N / N 2 FLOP/Byte再看B200这台机器的算力带宽比——假设FP8稠密算力按4.5 PFLOPS4.5×10^15估算带宽是8TB/s8×10^12两者的比值是562 FLOP/Byte。也就是说只有当程序每一步都要做超过562次浮点运算、才读取一个字节的数据时算力才是瓶颈。decode的算术强度只有1到2这个数字和562之间差了两三个数量级。结论非常明确decode阶段的运行时间由权重字节数 ÷ 显存带宽决定跟算力几乎无关。这就是带宽瓶颈的数学本质。2.2 理论速度计算不同精度下的token速度有了上面的公式理论速度很好算。令牌生成时间 单token需要读取的字节数 ÷ 显存带宽。以B200的8TB/s带宽为基准Qwen3-8B在不同精度下的理论极限速度如下精度单token读取字节数理论耗时/token理论速度BF1616GB2.0ms500 token/sFP88GB1.0ms1000 token/sINT44GB0.5ms2000 token/s这几个数字是纯权重读取的理论上限。实际运行时还要叠加KV cache读写、激活值传输、kernel启动和调度器的开销所以实测单流速度通常是理论值的60%到80%。FP8版本在B200上跑到700到900 token/s是合理预期。这里要提醒一句所谓跑得快要看你是关心单请求延迟还是系统总吞吐。单流测试反映的是带宽上限多并发测试总吞吐时权重会被多个请求复用同一个token生成阶段读取一次权重可以服务一批请求情况会复杂一些。后面第4节会专门讨论。2.3 从H100到B2002.4倍带宽到底改变什么如果没有对比带宽这个数字很容易被忽略。把Qwen3-8B-FP8放到不同GPU上单流理论速度差异非常直观GPU显存带宽单token读取8GB耗时的理论值理论速度B2008.0TB/s1.0ms1000 token/sH100 SXM3.35TB/s2.4ms417 token/sA100 80G2.0TB/s4.0ms250 token/sRTX 4090约1.0TB/s8.0ms125 token/s同样一个模型B200的单流decode速度是H100的2.4倍是RTX 4090的8倍。这个差距完全由显存带宽决定跟算力关系不大。你在A100上跑Qwen3-8B感觉还行换到B200上感觉起飞本质就是HBM3e带宽翻倍带来的。这也解释了为什么B200的192GB显存除了用来装大模型还有一个隐藏价值在数据并行场景下更大的显存可以支撑更大的batch、更多的并发请求数让权重读取成本被更多请求摊薄。带宽决定了单流延迟的下限显存容量则决定了你能在多大并发下维持这个延迟。2.4 实际损耗项KV cache、激活值和调度开销理论归理论跑起来之后你会发现实际速度总是比理论低一截。B200这种卡显存带宽8TB/s是理论峰值实际能达到的HBM有效带宽一般要打个折扣。更关键的是decode阶段读取的不仅仅是权重。KV cache是最大的隐形对手。每生成一个token都要把新的key和value写入KV cache同时注意读取时用的是页面式的PagedAttention数据在显存中的分布不是连续的访存效率天然会比线性读取权重低一些。上下文越长、并发请求数越多KV cache占用的带宽份额就越大。我实测在32K上下文、高并发场景下KV cache相关的读写至少会吃掉20%到30%的带宽预算。激活值activation也不容忽视。虽然单个token的激活值不大但在FlashAttention实现中计算过程中的中间tensor读写还是很频繁。另外vLLM这类推理引擎的scheduler和采样器会引入CPU与GPU之间的同步开销CUDA kernel的启动延迟在小数据量请求下也会显出来。所以做性能评估时不要把理论值当预期值。我在后面的实操中会给出更贴近实际的数据。3. 实操在B200单卡上跑通Qwen3-8B并测速3.1 环境准备与依赖安装B200是Blackwell架构对软件栈有硬性要求。驱动版本至少要570以上CUDA toolkit建议12.8或更高PyTorch建议用2.7以上的版本因为早期的PyTorch对Blackwell的kernel支持不完整。vLLM也建议直接装最新release旧版本可能没有针对HBM3e和FP8做专门的调度优化。我的测试环境如下操作系统Ubuntu 22.04GPUNVIDIA B200 192GB驱动570.xxCUDA12.8Python3.11PyTorch2.7vLLM0.8.x安装阶段没什么特别的操作按官方文档走就行pip install vllm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128唯一需要提醒的是B200功耗不低满负载运行时散热是非常现实的问题。官方整机通常是液冷或者重型风冷如果你在自建机架上测试注意nvidia-smi里的温度。实测中HBM3e温度过高会触发降频显存带宽会肉眼可见地掉。3.2 加载模型与vLLM服务启动Qwen3-8B的FP8 checkpoints已经由官方发布不用自己做量化。直接拉起服务vllm serve Qwen/Qwen3-8B-FP8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --enable-chunked-prefill \ --max-num-seqs 64几个参数的考量--max-model-len 32768把最大上下文设定为32K。Qwen3-8B本身能支持这个长度的上下文同时32K也是目前很多线上推理服务的标准配置。理论上拉到更大会让KV cache占用显著上升对于带宽测试不是好事。--gpu-memory-utilization 0.9给KV cache预留90%的显存。B200是192GB模型权重才8GB剩余空间几乎都分给KV cache这样可以避免因为KV cache不够而频繁做显存交换或淘汰。但预留太多也有代价KV cache本身也会参与带宽竞争所以需要根据实际并发目标调整。--enable-chunked-prefill把prefill阶段的长prompt切成小块。这个选项可以避免一个长prompt的prefill阻塞后面请求的decode在混合负载下对稳定TPOT很有帮助。--max-num-seqs 64限制一个batch最多容纳的序列数。这个值和并发压测的请求数要配合好。启动成功后会看到vLLM打印模型加载时间、显存占用和运行配置。B200加载8B模型非常快权重只有8GB几乎在半分钟内就能完成。3.3 用压测脚本量化TTFT和TPOTvLLM自带了一套benchmark脚本直接从GitHub clone下来使用git clone https://github.com/vllm-project/vllm.git cd vllm/benchmarks python benchmark_serving.py \ --model Qwen/Qwen3-8B-FP8 \ --backend vllm \ --dataset sharegpt \ --num-prompts 100 \ --max-num-seqs 64这个脚本会统计三个关键指标TTFT首token延迟反映prefill速度、TPOT每输出token延迟的平均值反映decode速度、吞吐每秒完成的请求数量和token数量。我在B200上测试单请求、输入约300字符、输出约200字符的场景实测数据如下TTFT约40msTPOT约1.3ms对应decode速度约750 token/s吞吐视并发而定64并发下系统总吞吐能到20000 token/s以上这个TPOT和我前面测算的FP8理论值1.0ms很接近说明vLLM在B200上的带宽利用率做得相当不错。但从单请求到并发TPOT会缓慢上升这是正常的权重读取虽然被摊薄了但KV cache的总体读写量也在同比例增加。当64个请求塞进一个batch时KV cache的带宽争抢会把TPOT从1.3ms拉到2ms以上。3.4 用NVIDIA工具确认带宽瓶颈光看测速结果还不够想确认瓶颈到底在带宽还是算力直接用profiler抓数据最直观。最常用的是nsys和ncu。nsys看kernel耗时分布nsys profile --statstrue -t cuda --cuda-memory-usage true \ python run_inference_client.py跑完看CUDA kernel统计decode阶段的kernel主要是decode attention和MLP的gemm应该占掉90%以上的GPU时间。再看ncu的内存分析ncu --set full --section MemoryWorkloadAnalysis \ python run_inference_client.py输出里有个关键指标叫Memory Throughput内存吞吐利用率。如果这个值在70%到80%以上说明显存带宽确实是被吃满了瓶颈就是带宽。如果连50%都不到那问题就变成了调度开销、kernel启动或者平台本身的效率问题。我实测B200上Qwen3-8B-FP8的decode kernel内存吞吐利用率大概在75%左右。这个数字意味着vLLM的kernel调度已经把HBM3e用得相当充分。如果换用默认BF16权重同样的kernel内存吞吐利用率会更高因为读取数据量更大但绝对TPOT反而更慢。利用率高不等于速度快要在带宽和延迟之间找平衡。4. 常见问题、性能排查与调优实录4.1 实测速度为什么低于理论值很多人在B200这种顶级卡上跑模型测出来速度和自己算的理论值差了一大截就开始怀疑哪里配错了。其实差距基本来自几个固定的损耗项损耗来源影响机制经验占比HBM有效带宽低于峰值访存模式无法100%饱和10%~20%KV cache读写PagedAttention的非连续访存10%~30%CUDA kernel启动与调度小batch下启动开销大5%~15%采样器和输出解码CPU同步、采样计算2%~5%这里特别要提一个新手容易翻车的地方做profiling测试时不要把服务器端的vLLM进程和压测客户端跑在同一张卡上。B200虽然显存大、带宽高但profiling工具本身会占用一部分GPU资源尤其是ncu这种深度插桩工具会让kernel执行时间显著变长测出来的数据完全不可信。正确做法是服务端在B200上正常跑压测脚本和profiling工具放在另一台机器上通过网络访问或者至少用--target-processes精确指定采集进程。4.2 并发、batch size与连续批处理的权衡单流测试只能暴露硬件上限生产环境更关心的是并发下的吞吐。vLLM的continuous batching会在一个iteration内动态调度多个请求batch越大权重读取的成本越被摊薄但每个请求要额外处理KV cache的竞争和调度器的开销。实测数据可以作为参考--max-num-seqs从1调到64系统总吞吐token/s会增加十几倍但单个请求的TPOT会从1.3ms涨到2ms以上。如果你的业务是聊天助手这种低延迟场景建议并发控制在16到32之间TPOT能够稳定在1.5ms以内。如果业务是批量摘要、离线分析这种高吞吐场景直接把并发拉满牺牲单请求延迟换取总吞吐。一个实用的调参技巧先把--gpu-memory-utilization调低到0.6减少KV cache预分配然后观察显存空闲和OOM情况逐步调到0.95。不同业务模型的KV cache用量差别很大别照搬别人的配置。4.3 用roofline模型判断你的场景缺什么离开B200这个特定场景更通用的排查方法是roofline模型。这个方法很简单画一张以算术强度为横轴、性能为纵轴的图硬件会给出两条限速线——算力线和带宽线合起来就是一个屋顶的形状。你的程序在哪条线下方瓶颈就在哪。对B200来讲峰值算力约4.5 PFLOPS带宽8TB/s屋顶交点大约在562 FLOP/Byte。decode的算术强度1~2远远落在带宽线那边。而prefill阶段如果输入很长算术强度可能达到几百甚至上千这就可能落在算力线那一侧。所以同一个模型prefill慢可能是算力不够decode慢基本上是带宽不够。判断方法很直接算一下你的实际算术强度或者直接跑两个测试——把模型换成量化版本看速度是否线性提升。如果int4比fp8快接近一倍说明你纯带宽受限如果速度几乎不变说明瓶颈在算力或别的环节。4.4 通过nano-vllm搞懂推理引擎的调度如果看完这篇文章你还觉得推理引擎是个黑盒想从代码层面彻底搞懂带宽为什么关键、调度器是怎么凑batch的强烈推荐去读nano-vllm这个项目。它用几千行代码实现了vLLM的核心机制包括PagedAttention、continuous batching、chunked prefill。核心的scheduler逻辑就几百行仔细读一遍你会看到GPU每轮迭代是怎么把多个请求的token拼成一个大batch怎么复用权重读取、减少HBM访问次数。这些内容在你用手写模型服务时感觉不明显但读源码时会非常有画面感每次从显存读权重的开销都决定了下一轮decode的延迟上限。我的建议阅读顺序先看attention kernel的paged实现再看scheduler怎么分配sequence slot最后自己改一改batch拼装逻辑对比一下性能变化。走完这一遍你对带宽瓶颈的理解会比看十篇博客都深。5. 带宽视角下的硬件选型与部署思路5.1 单卡跑小模型 vs 多卡跑大模型的权衡B200单卡192GB显存理论上可以装下很多几百B参数的模型但实际推理性能要分情况讨论。如果模型大到必须分片到多卡单卡带宽8TB/s的优势就变成了每张卡只能读到自己的那部分权重跨卡通信又要走NVLINK或者PCIe带宽瓶颈转移到了通信上。以8B模型为例B200单卡是带宽奢侈算力过剩适合追求极致单流延迟或高并发吞吐的场景。但如果你只是需要一个8B模型服务预算有限完全可以用4张带宽相对较低的卡做数据并行总吞吐差不多甚至因为总带宽叠加而更高。B200单卡的王炸场景是单卡跑得下且需要极低延迟的模型或者显存容量刚需的大模型推理。个人建议如果你的8B模型服务QPS目标是几千先算一下多张中端卡的总带宽和B200比谁高再做决定。别被单卡的名头迷惑带宽是总线型资源算总账比看单卡指标更重要。5.2 精度选择的实战建议在B200上跑Qwen3-8B这种规模的模型精度选择的优先级应该是FP8 BF16 INT4/INT8。FP8是甜点。权重体积减半硬件原生支持vLLM和TensorRT-LLM的kernel已经足够成熟。Qwen官方FP8 checkpoint的精度损失可以忽略直接商用。INT4虽然权重体积再减半理论带宽占用更小但实际推理速度不一定更快。原因在于INT4权重往往需要反量化回更高精度再送入tensor core反量化操作本身也占算力和带宽。在算力本来就不是瓶颈的decode阶段INT4引入的额外kernel开销很容易抵消权重减半的收益。我在其他模型上测试过GPTQ的INT4和原生FP8在相同并发下FP8的TPOT反而更稳定。一个建议如果一定要用INT4做一次A/B测试对比同一批prompt在FP8和INT4下的TPOT和吞吐用数据决定不要凭直觉。5.3 后续扩展方向这篇文章是单卡跑通瓶颈拆解的起点。基于这个测试后续可以往下走几个方向PD分离部署。在大并发场景下prefill和decode的计算特征差异太大混在一起时调度器需要做很多妥协。把prefill和decode分别部署到不同的实例上可以让prefill专用卡吃满算力、decode专用卡吃满带宽综合吞吐还能再涨不少。KV cache offload实验。B200显存大但KV cache也不是无限的尤其是处理超长上下文时。可以试试把冷session的KV cache挪到CPU内存给热session腾带宽资源。这个方向对带宽价值的理解会有更直观的感受。小模型蒸馏与带宽的关系也值得研究。既然带宽决定decode速度那在相同精度下参数量减半速度线性提升一倍。有些场景下把一个专业小模型蒸馏到4B比把一个8B模型做极致调优更划算。实测下来我对这代硬件的感受是算力已经不是首要焦虑点显存带宽才是。B200的8TB/s带宽让8B模型的单流decode跑进了1ms级别这个体验是上一代硬件给不了的。做推理优化先算清你的算术强度再选硬件和精度别盲目追求算力数字。最后分享一个小技巧在B200上测试时除了看token/s记得同时抓一下nvidia-smi里的GPU显存温度和功耗曲线。温度超过80度后HBM3e的带宽会明显下降这个指标比kernel统计更能反映真实运维环境下的性能边界。