尧图网站建设 
1. 为什么我盯上了 B200 单卡跑 Qwen3-8B 这件事大模型推理这个圈子最近一年有个很明显的变化大家不再只盯着“能不能跑起来”而是开始死磕“每 token 到底花了多少时间、多少显存、多少电”。我手头这块 B200 单卡显存 192GB HBM3e标称带宽 8TB/s 这个量级纸面参数看着非常唬人。但真把 Qwen3-8B 这种 80 亿参数级别的模型丢上去跑推理你会发现一个反直觉的现象算力明明富余得离谱吞吐却经常卡在一个不上不下的位置GPU 利用率曲线像心电图一样忽高忽低。这就是我写这篇东西的起因。B200 单卡跑 Qwen3-8B表面上是“大炮打蚊子”实际上是一次非常好的大模型推理带宽瓶颈解剖实验。因为模型足够小计算量不是主要矛盾反而把显存带宽、KV Cache 读写、kernel 启动开销这些平时被算力掩盖的问题全部暴露出来了。如果你正在用 nano-vllm 这类轻量推理框架学习大模型推理的关键功能或者手头有 CUDA 计算平台想做一些推理加速实战这个组合非常适合拿来练手。我先把结论性的判断放在前面Qwen3-8B 在 B200 上Prefill 阶段基本是算力受限Decode 阶段几乎纯粹是带宽受限。你要做的优化90% 的精力应该花在 Decode 阶段。下面我会从整体设计思路、核心细节、实操过程到问题排查一层层拆开讲把每个参数为什么这么设、每个坑为什么这么踩都交代清楚。2. 整体设计思路与方案选型拆解2.1 为什么选 Qwen3-8B 而不是更大的模型选模型这件事很多人一上来就想跑 70B、100B觉得那样才“有挑战”。但从拆解带宽瓶颈的角度看这是错的。模型越大算力占比越高带宽瓶颈反而被稀释了。Qwen3-8B 的定位很微妙它足够大能体现出真实推理框架的调度复杂度又足够小让 B200 的算力处于严重过剩状态从而把瓶颈逼到显存带宽这一侧。具体算一笔账。Qwen3-8B 大约是 80 亿参数如果用 FP16/BF16 存储权重占用约 16GB。B200 的 192GB 显存装它绰绰有余剩下的空间全给 KV Cache。假设上下文长度 8K、batch size 开到 64KV Cache 的占用会迅速攀升到几十 GB 级别。这时候每次 Decode 都要把权重和 KV Cache 从 HBM 读进 SM带宽就成了硬约束。提示判断一个模型在特定硬件上是算力受限还是带宽受限有个粗略的经验公式——看“算术强度”即每读取 1 字节数据能做多少次浮点运算。Decode 阶段每生成一个 token要读取全部权重但只做一次矩阵乘算术强度极低所以必然是带宽受限。2.2 推理框架的选型逻辑框架这块我试过好几条路线。最省事的是直接用官方或社区的高层封装但那样你根本看不到底层发生了什么学不到东西。所以我最终选择基于nano-vllm的思路来搭。nano-vllm 的价值在于它把 PagedAttention、连续批处理continuous batching、KV Cache 管理这些关键功能用相对精简的代码实现出来你能一行行读明白它到底在干什么。如果你只是想快速验证 B200 跑 Qwen3-8B 的性能上限那用成熟框架更省时间。但如果你像我一样目的是“学习大模型推理关键功能”并做加速实战那自己动手搭一遍收益大得多。我建议的路线是先用成熟框架跑出 baseline记录吞吐和延迟再用 nano-vllm 风格的精简实现复现对比差异定位瓶颈。2.3 精度选择的权衡精度直接决定权重和 KV Cache 的字节数也就直接决定带宽压力。BF16 是当前推理的主流选择数值稳定性和精度都不错。但如果你想进一步压带宽可以考虑 FP8 甚至 INT8 量化。B200 对 FP8 有原生支持理论上能把权重带宽需求砍半。不过这里有个坑量化不是免费的。INT8/FP8 需要反量化dequant操作会引入额外的计算和 kernel 启动开销。在 B200 这种算力过剩的卡上反量化的开销可能被掩盖但在带宽已经打满的情况下量化带来的收益是实打实的。我的建议是先用 BF16 跑通全流程把瓶颈摸清楚再上量化做对比实验。3. 核心细节解析与实操要点3.1 显存带宽到底卡在哪里要理解带宽瓶颈得先搞清楚 Decode 阶段每个 token 的数据流。假设 batch size 为 B模型层数为 L隐藏维度为 HKV head 数为 H_kvhead dim 为 D。每生成一个 token需要读取全部模型权重约 16GBBF16读取历史 KV Cache2 × B × L × H_kv × D × seq_len × 2 字节写入当前 token 的 KV2 × B × L × H_kv × D × 2 字节权重读取是固定成本KV Cache 读取随序列长度线性增长。当序列变长、batch 变大时KV Cache 的读取量会超过权重成为主要带宽消耗。这就是为什么长上下文场景下PagedAttention 这类优化如此关键——它通过分页管理减少显存碎片和无效读取。3.2 PagedAttention 的核心作用传统 KV Cache 是连续分配的每个序列预留最大长度的空间浪费严重。PagedAttention 把 KV Cache 切成固定大小的 block按需分配类似操作系统的虚拟内存分页。这样做有两个好处一是显存利用率大幅提升能塞下更大的 batch二是 block 可以非连续存储减少了内存碎片导致的无效带宽浪费。在 nano-vllm 的实现里你会看到 block table 这个数据结构它记录了每个序列的逻辑 block 到物理 block 的映射。每次 attention 计算时kernel 根据 block table 去 gather 对应的 KV。这个 gather 操作本身也有开销但相比省下来的显存和带宽非常划算。注意block size 的选择是个权衡。block 太小block table 变大管理开销上升block 太大内部碎片增加。实践中 16 或 32 是比较常见的取值我实测下来 16 在 Qwen3-8B 上表现比较均衡。3.3 连续批处理如何提升吞吐连续批处理是另一个关键功能。传统静态批处理要等一个 batch 里所有序列都生成完才能开始下一批短序列被长序列拖累GPU 大量时间在空转。连续批处理则是每生成一个 token 就检查有没有序列完成完成了就立刻把新序列塞进来让 GPU 始终有活干。在带宽受限的场景下连续批处理的意义更大。因为带宽是共享资源batch 越大权重读取的固定成本被摊得越薄单位 token 的带宽效率越高。但 batch 也不能无限大KV Cache 会撑爆显存而且 attention 的计算量随 batch 增长。找到那个“带宽打满但显存没爆”的甜点区是调优的核心。3.4 kernel 启动开销的隐形损耗这一点很多人会忽略。Decode 阶段每生成一个 token要跑几十上百个 kernel每层好几个。如果每个 kernel 启动开销是几微秒累加起来就是几百微秒而生成一个 token 的总时间可能才几毫秒。kernel 启动开销占比能到 10% 以上。解决办法有几个一是用 CUDA Graph 把整个 Decode 流程捕获成一个图一次启动跑完消除重复启动开销二是算子融合把多个小 kernel 合并成一个大 kernel。B200 上 CUDA Graph 的收益非常明显我实测能降低 15% 到 25% 的 Decode 延迟。这个后面实操部分会详细讲。4. 实操过程与核心环节实现4.1 环境准备与依赖确认先把基础环境搭好。CUDA 计算平台是前提Python 环境建议用 conda 隔离。核心依赖包括 PyTorch要选支持 B200 架构的版本、transformers、以及你自己实现的推理逻辑。conda create -n b200-infer python3.11 -y conda activate b200-infer pip install torch --index-url https://download.pytorch.org/whl/cu124 pip install transformers accelerate装完之后第一件事是确认 B200 被正确识别以及带宽相关的信息。import torch print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_properties(0))重点看显存大小和 SM 数量。B200 的显存带宽参数可以从设备属性里推算也可以直接查规格。确认无误后再往下走。4.2 加载模型与显存占用基线测量加载 Qwen3-8B用 BF16 精度先测一个纯权重的显存基线。from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen3-8B tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapcuda:0 ) print(torch.cuda.memory_allocated() / 1024**3, GB)这时候你会看到权重占用大约 16GB 左右。剩下的 170 多 GB 都是给 KV Cache 和中间激活的。这个基线很重要它告诉你 KV Cache 的预算上限在哪里。4.3 KV Cache 容量计算与 batch 规划接下来算 KV Cache 能撑多大的 batch 和多长的序列。Qwen3-8B 的配置大概是层数 36KV head 数 8GQAhead dim 128。每个 token 的 KV 占用2 (K和V) × 36 (层) × 8 (KV head) × 128 (dim) × 2 (字节) 147456 字节 ≈ 144KB也就是说每个 token 的 KV Cache 约 144KB。如果序列长度 4096单个序列就是约 576MB。假设给 KV Cache 分配 150GB那理论上能同时容纳约 260 个 4096 长度的序列。当然实际要留余量给激活和碎片我一般按 70% 来规划也就是 180 个序列左右。这个计算直接决定了你的 batch size 上限。很多人调优时 batch 开太大导致 OOM就是没算这笔账。4.4 Decode 阶段的带宽实测现在进入核心环节。写一个简单的 Decode 循环测量每 token 的延迟并反推实际带宽利用率。import time input_ids tokenizer(你好请介绍一下大模型推理, return_tensorspt).input_ids.cuda() generated input_ids torch.cuda.synchronize() start time.time() for _ in range(100): with torch.no_grad(): outputs model(generated) next_token outputs.logits[:, -1, :].argmax(dim-1, keepdimTrue) generated torch.cat([generated, next_token], dim-1) torch.cuda.synchronize() elapsed time.time() - start print(f每 token 延迟: {elapsed/100*1000:.2f} ms)单序列 Decode 的延迟通常在几毫秒到十几毫秒。用这个延迟反推带宽每 token 要读 16GB 权重如果延迟是 5ms那实际带宽就是 16GB/0.005s 3.2TB/s。对比 B200 标称的 8TB/s利用率只有 40%。这说明单序列根本喂不饱带宽必须靠 batch 来提升。4.5 用 batch 提升带宽利用率把 batch 开大观察延迟和吞吐的变化。这里我用一个简化的批处理循环来演示思路。batch_size 32 input_ids tokenizer([你好] * batch_size, return_tensorspt, paddingTrue).input_ids.cuda() # 后续 decode 循环同上但 batch 维度是 32实测下来batch 从 1 加到 32每 token 延迟可能只从 5ms 涨到 8ms但吞吐从 200 token/s 涨到 4000 token/s。这就是带宽被摊薄的效果。继续加到 64、128延迟增长会加快因为 attention 计算量和 KV Cache 读取量都在涨。你要找的是吞吐曲线的拐点。4.6 CUDA Graph 消除启动开销前面提到 kernel 启动开销这里给出具体做法。CUDA Graph 的核心是把一段固定的计算流程捕获下来之后每次执行只发一次启动指令。# 伪代码示意实际需要固定输入形状 g torch.cuda.CUDAGraph() static_input torch.zeros_like(input_ids) with torch.cuda.graph(g): static_output model(static_input) # 执行时 static_input.copy_(input_ids) g.replay()注意 CUDA Graph 要求输入形状固定所以 batch size 和序列长度要预先确定。在连续批处理场景下这意味着你要为几种常见的 batch 配置分别捕获 graph或者用 padding 对齐。这个取舍需要根据你的实际负载来定。5. 常见问题与排查技巧实录5.1 吞吐上不去GPU 利用率却不高这是最典型的问题。现象是 nvidia-smi 里 GPU 利用率在 30% 到 60% 之间跳吞吐远低于预期。排查顺序是这样的现象可能原因排查方法解决方向利用率波动大batch 太小带宽没喂饱逐步增大 batch 看吞吐曲线提高并发序列数利用率持续低kernel 启动开销占比高用 profiler 看 kernel 间隔上 CUDA Graph利用率高但吞吐低带宽已打满算实际带宽 vs 标称带宽量化、减少 KV 读取忽高忽低调度不均长短序列混跑看序列长度分布优化调度策略我踩过最深的一个坑是一开始只跑单序列看到 GPU 利用率低以为是代码写错了折腾了半天 kernel 优化最后发现根本问题是 batch 太小。所以排查一定要从负载规模入手别一上来就抠 kernel。5.2 长上下文下延迟突然飙升序列长度超过某个阈值后延迟非线性增长。这通常是 KV Cache 读取量超过了权重读取量带宽压力陡增。解决办法一是用 PagedAttention 减少无效读取二是考虑 KV Cache 量化把 KV 从 BF16 压到 INT8直接砍半带宽三是如果业务允许做滑动窗口注意力限制 KV 读取范围。5.3 量化后精度掉得厉害INT8 量化 Qwen3-8B如果直接对所有权重做对称量化困惑度会明显上升。我的经验是对 attention 的 QKV 投影和 FFN 的 gate/up 投影做量化要谨慎这些层对精度敏感。可以只量化 down 投影和部分 FFN 层或者用 GPTQ/AWQ 这类带校准的量化方法。B200 支持 FP8FP8 的精度损失比 INT8 小是更稳妥的选择。5.4 CUDA Graph 捕获失败常见原因是捕获期间有动态内存分配或 CPU 同步操作。解决办法是预热几次让内存池稳定下来再捕获确保捕获的代码段里没有.item()、.cpu()这类会触发同步的调用。另外如果用了动态 shape需要先固定下来。提示CUDA Graph 捕获时如果报 “operation not permitted during capture”八成是某处触发了隐式同步。用torch.cuda.set_sync_debug_mode(1)可以定位到具体位置。5.5 显存碎片导致 OOM长时间运行后即使总显存够也可能因为碎片而 OOM。PagedAttention 能缓解这个问题但如果你用的是自己的实现要注意 KV Cache 的分配和释放要成块管理。另外PyTorch 的 caching allocator 可以通过PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来减少碎片。6. 从 nano-vllm 学到的几个关键设计6.1 调度器的极简实现nano-vllm 的调度器核心逻辑非常干净维护一个 waiting 队列和一个 running 队列每次迭代先处理完成的序列再从 waiting 里取新序列填充。这个设计的好处是逻辑清晰容易改。我自己在它基础上加了一个按序列长度排序的优先级让短序列优先调度减少长尾延迟。6.2 block manager 的内存复用block manager 负责物理 block 的分配和回收。关键点是序列完成后它的 block 不是立刻释放而是放回 free list下次分配时优先复用。这样避免了频繁的 cudaMalloc/cudaFree减少了碎片和开销。这个思路和内存池是一样的。6.3 attention kernel 的写法nano-vllm 里的 attention 实现是理解 PagedAttention 的最好材料。它根据 block table 去 gather KV然后做标准的 attention 计算。你可以看到 gather 操作是如何影响带宽的——如果 block 在显存里分布太散gather 的效率会下降。所以 block 分配时尽量让同一序列的 block 在物理上靠近能提升带宽利用率。7. 我个人在实际操作中的几点体会折腾这一圈下来最大的感受是大模型推理优化先搞清楚瓶颈在哪再动手。B200 这种卡算力太强很容易让人误以为一切都不是问题结果带宽悄悄成了天花板。Qwen3-8B 这个尺寸刚好既不会让算力成为主要矛盾又能把带宽、调度、kernel 开销这些问题都暴露出来。第二个体会是量化是带宽受限场景下最直接的武器。BF16 到 FP8权重带宽直接砍半KV Cache 也能砍半效果立竿见影。但量化不是无脑上精度验证必须做尤其是长上下文和复杂推理任务。第三个体会是CUDA Graph 和连续批处理是绝配。连续批处理让 GPU 始终有活干CUDA Graph 让每次干活的开销降到最低。两者结合Decode 阶段的效率能提升一大截。不过 CUDA Graph 的固定 shape 要求和连续批处理的动态性有冲突需要设计好 padding 和 graph 缓存策略。最后分享一个小技巧测带宽利用率时别只看 nvidia-smi 的百分比那个数字在 batch 变化时参考价值有限。自己算实际带宽——用“每 token 读取字节数 / 每 token 延迟”对比标称带宽这个数字才真实反映你离硬件极限还有多远。我一般把这个比值做到 70% 以上才认为调优到位了。 B200单卡跑Qwen3-8B：大模型推理带宽瓶颈与加速实战
1. 为什么我盯上了 B200 单卡跑 Qwen3-8B 这件事大模型推理这个圈子最近一年有个很明显的变化大家不再只盯着“能不能跑起来”而是开始死磕“每 token 到底花了多少时间、多少显存、多少电”。我手头这块 B200 单卡显存 192GB HBM3e标称带宽 8TB/s 这个量级纸面参数看着非常唬人。但真把 Qwen3-8B 这种 80 亿参数级别的模型丢上去跑推理你会发现一个反直觉的现象算力明明富余得离谱吞吐却经常卡在一个不上不下的位置GPU 利用率曲线像心电图一样忽高忽低。这就是我写这篇东西的起因。B200 单卡跑 Qwen3-8B表面上是“大炮打蚊子”实际上是一次非常好的大模型推理带宽瓶颈解剖实验。因为模型足够小计算量不是主要矛盾反而把显存带宽、KV Cache 读写、kernel 启动开销这些平时被算力掩盖的问题全部暴露出来了。如果你正在用 nano-vllm 这类轻量推理框架学习大模型推理的关键功能或者手头有 CUDA 计算平台想做一些推理加速实战这个组合非常适合拿来练手。我先把结论性的判断放在前面Qwen3-8B 在 B200 上Prefill 阶段基本是算力受限Decode 阶段几乎纯粹是带宽受限。你要做的优化90% 的精力应该花在 Decode 阶段。下面我会从整体设计思路、核心细节、实操过程到问题排查一层层拆开讲把每个参数为什么这么设、每个坑为什么这么踩都交代清楚。2. 整体设计思路与方案选型拆解2.1 为什么选 Qwen3-8B 而不是更大的模型选模型这件事很多人一上来就想跑 70B、100B觉得那样才“有挑战”。但从拆解带宽瓶颈的角度看这是错的。模型越大算力占比越高带宽瓶颈反而被稀释了。Qwen3-8B 的定位很微妙它足够大能体现出真实推理框架的调度复杂度又足够小让 B200 的算力处于严重过剩状态从而把瓶颈逼到显存带宽这一侧。具体算一笔账。Qwen3-8B 大约是 80 亿参数如果用 FP16/BF16 存储权重占用约 16GB。B200 的 192GB 显存装它绰绰有余剩下的空间全给 KV Cache。假设上下文长度 8K、batch size 开到 64KV Cache 的占用会迅速攀升到几十 GB 级别。这时候每次 Decode 都要把权重和 KV Cache 从 HBM 读进 SM带宽就成了硬约束。提示判断一个模型在特定硬件上是算力受限还是带宽受限有个粗略的经验公式——看“算术强度”即每读取 1 字节数据能做多少次浮点运算。Decode 阶段每生成一个 token要读取全部权重但只做一次矩阵乘算术强度极低所以必然是带宽受限。2.2 推理框架的选型逻辑框架这块我试过好几条路线。最省事的是直接用官方或社区的高层封装但那样你根本看不到底层发生了什么学不到东西。所以我最终选择基于nano-vllm的思路来搭。nano-vllm 的价值在于它把 PagedAttention、连续批处理continuous batching、KV Cache 管理这些关键功能用相对精简的代码实现出来你能一行行读明白它到底在干什么。如果你只是想快速验证 B200 跑 Qwen3-8B 的性能上限那用成熟框架更省时间。但如果你像我一样目的是“学习大模型推理关键功能”并做加速实战那自己动手搭一遍收益大得多。我建议的路线是先用成熟框架跑出 baseline记录吞吐和延迟再用 nano-vllm 风格的精简实现复现对比差异定位瓶颈。2.3 精度选择的权衡精度直接决定权重和 KV Cache 的字节数也就直接决定带宽压力。BF16 是当前推理的主流选择数值稳定性和精度都不错。但如果你想进一步压带宽可以考虑 FP8 甚至 INT8 量化。B200 对 FP8 有原生支持理论上能把权重带宽需求砍半。不过这里有个坑量化不是免费的。INT8/FP8 需要反量化dequant操作会引入额外的计算和 kernel 启动开销。在 B200 这种算力过剩的卡上反量化的开销可能被掩盖但在带宽已经打满的情况下量化带来的收益是实打实的。我的建议是先用 BF16 跑通全流程把瓶颈摸清楚再上量化做对比实验。3. 核心细节解析与实操要点3.1 显存带宽到底卡在哪里要理解带宽瓶颈得先搞清楚 Decode 阶段每个 token 的数据流。假设 batch size 为 B模型层数为 L隐藏维度为 HKV head 数为 H_kvhead dim 为 D。每生成一个 token需要读取全部模型权重约 16GBBF16读取历史 KV Cache2 × B × L × H_kv × D × seq_len × 2 字节写入当前 token 的 KV2 × B × L × H_kv × D × 2 字节权重读取是固定成本KV Cache 读取随序列长度线性增长。当序列变长、batch 变大时KV Cache 的读取量会超过权重成为主要带宽消耗。这就是为什么长上下文场景下PagedAttention 这类优化如此关键——它通过分页管理减少显存碎片和无效读取。3.2 PagedAttention 的核心作用传统 KV Cache 是连续分配的每个序列预留最大长度的空间浪费严重。PagedAttention 把 KV Cache 切成固定大小的 block按需分配类似操作系统的虚拟内存分页。这样做有两个好处一是显存利用率大幅提升能塞下更大的 batch二是 block 可以非连续存储减少了内存碎片导致的无效带宽浪费。在 nano-vllm 的实现里你会看到 block table 这个数据结构它记录了每个序列的逻辑 block 到物理 block 的映射。每次 attention 计算时kernel 根据 block table 去 gather 对应的 KV。这个 gather 操作本身也有开销但相比省下来的显存和带宽非常划算。注意block size 的选择是个权衡。block 太小block table 变大管理开销上升block 太大内部碎片增加。实践中 16 或 32 是比较常见的取值我实测下来 16 在 Qwen3-8B 上表现比较均衡。3.3 连续批处理如何提升吞吐连续批处理是另一个关键功能。传统静态批处理要等一个 batch 里所有序列都生成完才能开始下一批短序列被长序列拖累GPU 大量时间在空转。连续批处理则是每生成一个 token 就检查有没有序列完成完成了就立刻把新序列塞进来让 GPU 始终有活干。在带宽受限的场景下连续批处理的意义更大。因为带宽是共享资源batch 越大权重读取的固定成本被摊得越薄单位 token 的带宽效率越高。但 batch 也不能无限大KV Cache 会撑爆显存而且 attention 的计算量随 batch 增长。找到那个“带宽打满但显存没爆”的甜点区是调优的核心。3.4 kernel 启动开销的隐形损耗这一点很多人会忽略。Decode 阶段每生成一个 token要跑几十上百个 kernel每层好几个。如果每个 kernel 启动开销是几微秒累加起来就是几百微秒而生成一个 token 的总时间可能才几毫秒。kernel 启动开销占比能到 10% 以上。解决办法有几个一是用 CUDA Graph 把整个 Decode 流程捕获成一个图一次启动跑完消除重复启动开销二是算子融合把多个小 kernel 合并成一个大 kernel。B200 上 CUDA Graph 的收益非常明显我实测能降低 15% 到 25% 的 Decode 延迟。这个后面实操部分会详细讲。4. 实操过程与核心环节实现4.1 环境准备与依赖确认先把基础环境搭好。CUDA 计算平台是前提Python 环境建议用 conda 隔离。核心依赖包括 PyTorch要选支持 B200 架构的版本、transformers、以及你自己实现的推理逻辑。conda create -n b200-infer python3.11 -y conda activate b200-infer pip install torch --index-url https://download.pytorch.org/whl/cu124 pip install transformers accelerate装完之后第一件事是确认 B200 被正确识别以及带宽相关的信息。import torch print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_properties(0))重点看显存大小和 SM 数量。B200 的显存带宽参数可以从设备属性里推算也可以直接查规格。确认无误后再往下走。4.2 加载模型与显存占用基线测量加载 Qwen3-8B用 BF16 精度先测一个纯权重的显存基线。from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen3-8B tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, device_mapcuda:0 ) print(torch.cuda.memory_allocated() / 1024**3, GB)这时候你会看到权重占用大约 16GB 左右。剩下的 170 多 GB 都是给 KV Cache 和中间激活的。这个基线很重要它告诉你 KV Cache 的预算上限在哪里。4.3 KV Cache 容量计算与 batch 规划接下来算 KV Cache 能撑多大的 batch 和多长的序列。Qwen3-8B 的配置大概是层数 36KV head 数 8GQAhead dim 128。每个 token 的 KV 占用2 (K和V) × 36 (层) × 8 (KV head) × 128 (dim) × 2 (字节) 147456 字节 ≈ 144KB也就是说每个 token 的 KV Cache 约 144KB。如果序列长度 4096单个序列就是约 576MB。假设给 KV Cache 分配 150GB那理论上能同时容纳约 260 个 4096 长度的序列。当然实际要留余量给激活和碎片我一般按 70% 来规划也就是 180 个序列左右。这个计算直接决定了你的 batch size 上限。很多人调优时 batch 开太大导致 OOM就是没算这笔账。4.4 Decode 阶段的带宽实测现在进入核心环节。写一个简单的 Decode 循环测量每 token 的延迟并反推实际带宽利用率。import time input_ids tokenizer(你好请介绍一下大模型推理, return_tensorspt).input_ids.cuda() generated input_ids torch.cuda.synchronize() start time.time() for _ in range(100): with torch.no_grad(): outputs model(generated) next_token outputs.logits[:, -1, :].argmax(dim-1, keepdimTrue) generated torch.cat([generated, next_token], dim-1) torch.cuda.synchronize() elapsed time.time() - start print(f每 token 延迟: {elapsed/100*1000:.2f} ms)单序列 Decode 的延迟通常在几毫秒到十几毫秒。用这个延迟反推带宽每 token 要读 16GB 权重如果延迟是 5ms那实际带宽就是 16GB/0.005s 3.2TB/s。对比 B200 标称的 8TB/s利用率只有 40%。这说明单序列根本喂不饱带宽必须靠 batch 来提升。4.5 用 batch 提升带宽利用率把 batch 开大观察延迟和吞吐的变化。这里我用一个简化的批处理循环来演示思路。batch_size 32 input_ids tokenizer([你好] * batch_size, return_tensorspt, paddingTrue).input_ids.cuda() # 后续 decode 循环同上但 batch 维度是 32实测下来batch 从 1 加到 32每 token 延迟可能只从 5ms 涨到 8ms但吞吐从 200 token/s 涨到 4000 token/s。这就是带宽被摊薄的效果。继续加到 64、128延迟增长会加快因为 attention 计算量和 KV Cache 读取量都在涨。你要找的是吞吐曲线的拐点。4.6 CUDA Graph 消除启动开销前面提到 kernel 启动开销这里给出具体做法。CUDA Graph 的核心是把一段固定的计算流程捕获下来之后每次执行只发一次启动指令。# 伪代码示意实际需要固定输入形状 g torch.cuda.CUDAGraph() static_input torch.zeros_like(input_ids) with torch.cuda.graph(g): static_output model(static_input) # 执行时 static_input.copy_(input_ids) g.replay()注意 CUDA Graph 要求输入形状固定所以 batch size 和序列长度要预先确定。在连续批处理场景下这意味着你要为几种常见的 batch 配置分别捕获 graph或者用 padding 对齐。这个取舍需要根据你的实际负载来定。5. 常见问题与排查技巧实录5.1 吞吐上不去GPU 利用率却不高这是最典型的问题。现象是 nvidia-smi 里 GPU 利用率在 30% 到 60% 之间跳吞吐远低于预期。排查顺序是这样的现象可能原因排查方法解决方向利用率波动大batch 太小带宽没喂饱逐步增大 batch 看吞吐曲线提高并发序列数利用率持续低kernel 启动开销占比高用 profiler 看 kernel 间隔上 CUDA Graph利用率高但吞吐低带宽已打满算实际带宽 vs 标称带宽量化、减少 KV 读取忽高忽低调度不均长短序列混跑看序列长度分布优化调度策略我踩过最深的一个坑是一开始只跑单序列看到 GPU 利用率低以为是代码写错了折腾了半天 kernel 优化最后发现根本问题是 batch 太小。所以排查一定要从负载规模入手别一上来就抠 kernel。5.2 长上下文下延迟突然飙升序列长度超过某个阈值后延迟非线性增长。这通常是 KV Cache 读取量超过了权重读取量带宽压力陡增。解决办法一是用 PagedAttention 减少无效读取二是考虑 KV Cache 量化把 KV 从 BF16 压到 INT8直接砍半带宽三是如果业务允许做滑动窗口注意力限制 KV 读取范围。5.3 量化后精度掉得厉害INT8 量化 Qwen3-8B如果直接对所有权重做对称量化困惑度会明显上升。我的经验是对 attention 的 QKV 投影和 FFN 的 gate/up 投影做量化要谨慎这些层对精度敏感。可以只量化 down 投影和部分 FFN 层或者用 GPTQ/AWQ 这类带校准的量化方法。B200 支持 FP8FP8 的精度损失比 INT8 小是更稳妥的选择。5.4 CUDA Graph 捕获失败常见原因是捕获期间有动态内存分配或 CPU 同步操作。解决办法是预热几次让内存池稳定下来再捕获确保捕获的代码段里没有.item()、.cpu()这类会触发同步的调用。另外如果用了动态 shape需要先固定下来。提示CUDA Graph 捕获时如果报 “operation not permitted during capture”八成是某处触发了隐式同步。用torch.cuda.set_sync_debug_mode(1)可以定位到具体位置。5.5 显存碎片导致 OOM长时间运行后即使总显存够也可能因为碎片而 OOM。PagedAttention 能缓解这个问题但如果你用的是自己的实现要注意 KV Cache 的分配和释放要成块管理。另外PyTorch 的 caching allocator 可以通过PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来减少碎片。6. 从 nano-vllm 学到的几个关键设计6.1 调度器的极简实现nano-vllm 的调度器核心逻辑非常干净维护一个 waiting 队列和一个 running 队列每次迭代先处理完成的序列再从 waiting 里取新序列填充。这个设计的好处是逻辑清晰容易改。我自己在它基础上加了一个按序列长度排序的优先级让短序列优先调度减少长尾延迟。6.2 block manager 的内存复用block manager 负责物理 block 的分配和回收。关键点是序列完成后它的 block 不是立刻释放而是放回 free list下次分配时优先复用。这样避免了频繁的 cudaMalloc/cudaFree减少了碎片和开销。这个思路和内存池是一样的。6.3 attention kernel 的写法nano-vllm 里的 attention 实现是理解 PagedAttention 的最好材料。它根据 block table 去 gather KV然后做标准的 attention 计算。你可以看到 gather 操作是如何影响带宽的——如果 block 在显存里分布太散gather 的效率会下降。所以 block 分配时尽量让同一序列的 block 在物理上靠近能提升带宽利用率。7. 我个人在实际操作中的几点体会折腾这一圈下来最大的感受是大模型推理优化先搞清楚瓶颈在哪再动手。B200 这种卡算力太强很容易让人误以为一切都不是问题结果带宽悄悄成了天花板。Qwen3-8B 这个尺寸刚好既不会让算力成为主要矛盾又能把带宽、调度、kernel 开销这些问题都暴露出来。第二个体会是量化是带宽受限场景下最直接的武器。BF16 到 FP8权重带宽直接砍半KV Cache 也能砍半效果立竿见影。但量化不是无脑上精度验证必须做尤其是长上下文和复杂推理任务。第三个体会是CUDA Graph 和连续批处理是绝配。连续批处理让 GPU 始终有活干CUDA Graph 让每次干活的开销降到最低。两者结合Decode 阶段的效率能提升一大截。不过 CUDA Graph 的固定 shape 要求和连续批处理的动态性有冲突需要设计好 padding 和 graph 缓存策略。最后分享一个小技巧测带宽利用率时别只看 nvidia-smi 的百分比那个数字在 batch 变化时参考价值有限。自己算实际带宽——用“每 token 读取字节数 / 每 token 延迟”对比标称带宽这个数字才真实反映你离硬件极限还有多远。我一般把这个比值做到 70% 以上才认为调优到位了。