企业官网建设流程全解析

大模型推理这件事，真正上手跑过几轮的人都会有一个共同的感受：算力清单上写着几百 TFLOPS 的峰值，实际跑起来却连零头都摸不到。尤其是把 Qwen3-8B 这种量级的模型塞进单张 B200 上做推理时，你会发现 GPU 利用率曲线像心电图一样忽高忽低，显存带宽的占用却一直贴着天花板。这篇内容就围绕"B200 单卡跑 Qwen3-8B"这个具体场景，把大模型推理里最容易被忽视、又最致命的带宽瓶颈拆开讲清楚——它是什么、为什么卡在这里、怎么定位、怎么优化。不管你是刚接触推理部署的新手，还是已经在调 vLLM、TensorRT-LLM 的老手，都能从这套拆解思路里拿到可以直接复用的方法。

1. 为什么单卡跑 Qwen3-8B 会先撞上带宽墙

1.1 从"算力过剩、带宽饥饿"这个反直觉现象说起

很多人第一次在 B200 上跑 Qwen3-8B，看到的现象是：GPU 计算单元（SM）的占用率只有百分之二三十，但推理吞吐就是上不去，延迟也压不下来。直觉上会以为是模型没优化好、kernel 写得烂，于是拼命去调 batch size、换 attention 实现，结果收效甚微。真正的原因往往不在算力，而在显存带宽。

大模型推理（尤其是 decode 阶段）的本质，是一个访存密集型任务，而不是计算密集型任务。每生成一个 token，模型都要把参与计算的权重从显存里读一遍。Qwen3-8B 是 80 亿参数规模，即便用 FP16/BF16 存储，权重也有大约 16GB。decode 阶段每生成一个 token，理论上要把这 16GB 权重完整读一遍（实际因为 batch 内共享，会摊薄，但单请求场景下就是接近全量读取）。B200 的 HBM3e 带宽在 8TB/s 量级，听起来很夸张，但算一下：16GB ÷ 8TB/s ≈ 2ms。也就是说，光是把权重读一遍，单 token 的物理下限就在 2ms 左右，对应单请求理论极限约 500 tokens/s。而实际中因为 kernel 效率、访存模式、KV Cache 读写等因素，能跑到理论值的 50%~70% 就已经很不错了。

这就是"算力过剩、带宽饥饿"的由来：B200 的 FP16 算力是千 TFLOPS 级别，但 decode 阶段根本喂不饱它，计算单元大部分时间在等数据从显存搬过来。

1.2 算术强度：判断一个阶段是算力瓶颈还是带宽瓶颈的标尺

要系统性地判断瓶颈，得引入一个核心概念——算术强度（Arithmetic Intensity），也就是每读取一字节数据能完成多少次浮点运算（FLOPs/Byte）。

对于 decode 阶段，每生成一个 token、处理一个请求，大致需要 2 × 参数量 次浮点运算（一次乘、一次加），同时要读取约 2 × 参数量 字节的权重（FP16 每参数 2 字节）。所以算术强度大约是：

算术强度 ≈ (2 × N) FLOPs / (2 × N) Bytes = 1 FLOP/Byte

而 B200 的算力带宽比（Ops:Bandwidth Ratio）大约是 1000 TFLOPS ÷ 8 TB/s ≈ 125 FLOPs/Byte。也就是说，只有当算术强度超过 125 时，算力才会成为瓶颈；而 decode 阶段的算术强度只有 1 左右，远远落在带宽瓶颈区。

相比之下，prefill 阶段（处理输入 prompt）因为可以并行处理整个序列，算术强度会高得多，通常能进入算力瓶颈区。这就解释了为什么同一个模型，prefill 快、decode 慢，而且 decode 阶段 GPU 利用率上不去。

1.3 Qwen3-8B 在 B200 上的理论性能天花板估算

把上面的逻辑量化一下，就能算出 Qwen3-8B 在 B200 单卡上的理论天花板。这里给一个粗略但实用的估算框架：

这个表的意义在于：当你调优时，如果单请求吞吐已经接近 300 tokens/s，那基本已经摸到带宽墙了，再怎么调 kernel 收益都有限，这时候正确的方向是提高 batch size 来摊薄权重读取成本，而不是继续抠单请求延迟。

提示：这个估算假设权重只读一遍。实际中因为 KV Cache 的读写、中间激活值的搬运，真实带宽占用会更高，所以实际天花板往往比理论值更低。

2. 拆解 decode 阶段的访存路径：钱到底花在哪了

2.1 权重读取：占大头的固定开销

decode 阶段每生成一个 token，最重的访存开销就是读取全部权重。以 Qwen3-8B 为例，它由若干层 Transformer 组成，每层包含 attention 的 Q/K/V/O 投影矩阵和 FFN 的 gate/up/down 矩阵。这些矩阵在 decode 时都要被完整读取一遍。

关键点在于：这部分开销是"固定"的，不随 batch size 线性增长。也就是说，batch size 从 1 涨到 32，权重读取量几乎不变（因为同一份权重可以服务 batch 内所有请求），但计算量涨了 32 倍。这就是为什么增大 batch 能显著提升吞吐——它把固定的权重读取成本摊薄到了更多请求上。

用一个生活化的类比：权重读取就像开一辆大卡车去送货，不管车上装 1 件还是 32 件货，油费（权重读取）基本一样。单请求时每件货分摊的油费极高，batch 大了之后每件货分摊的油费就降下来了。

2.2 KV Cache 读写：随序列长度和 batch 增长的变量开销

KV Cache 是 decode 阶段另一个重要的访存来源。每生成一个新 token，都要把当前 token 的 K、V 追加进缓存，同时读取历史所有 token 的 K、V 来做 attention 计算。

KV Cache 的大小和访存量和这几个因素成正比：

• 序列长度：序列越长，历史 KV 越多，读取量越大
• batch size：并发请求越多，KV Cache 总量越大
• 层数 × 头数 × head_dim：模型结构决定

对于 Qwen3-8B，假设用 GQA（分组查询注意力），KV 头数比 Q 头数少，能显著降低 KV Cache 体积。但即便如此，在长上下文（比如 32K tokens）场景下，KV Cache 的访存量会变得非常可观，甚至在某些配置下超过权重读取成为主要瓶颈。

这里有个容易踩的坑：很多人只盯着权重，忽略了 KV Cache。实测中，当序列长度超过 8K、batch size 又比较大时，KV Cache 的带宽占用会快速上升，成为新的瓶颈点。

2.3 中间激活值与 kernel 间的数据搬运

除了权重和 KV Cache，还有一类容易被忽视的访存开销：中间激活值的读写和kernel 之间的数据搬运。

decode 阶段每层计算会产生中间激活值（比如 attention 输出、FFN 中间结果），这些值要写回显存再被下一个 kernel 读取。如果 kernel 融合做得不好，每个算子都要"读—算—写"一轮显存，累积起来就是巨大的带宽浪费。

举个具体的例子：一个标准的 FFN 层包含 gate 投影、激活函数、up 投影、down 投影等多个步骤。如果每个步骤都是独立的 kernel，那中间结果就要反复进出显存。而如果做 kernel 融合（比如把 gate + 激活 + up 融合成一个 kernel），就能省掉大量中间读写。这也是为什么 FlashAttention、融合 FFN 这类优化对 decode 性能提升明显——它们本质上是在减少访存，而不是减少计算。

3. 用实测数据定位瓶颈：从 ncu 到带宽利用率曲线

3.1 先建立基线：单请求、单 batch 的裸跑数据

定位瓶颈的第一步是建立基线。不要一上来就开各种优化，先用最朴素的配置跑一遍，记录关键指标：

• 单请求 decode 吞吐（tokens/s）
• 首 token 延迟（TTFT）
• GPU SM 利用率
• 显存带宽利用率
• 显存占用

在 B200 上跑 Qwen3-8B，用 BF16、batch size = 1、序列长度 512 的配置，典型数据大概是：单请求吞吐 150~250 tokens/s，SM 利用率 20%~35%，显存带宽利用率 60%~80%。这个"SM 低、带宽高"的组合，就是带宽瓶颈的典型特征。

如果反过来看到 SM 利用率很高、带宽利用率不高，那说明是算力瓶颈，方向就要转向算子优化。所以第一步永远是先看清楚是哪种瓶颈，别盲目优化。

3.2 用 Nsight Compute 抓关键 kernel 的访存指标

要更精细地定位，就得用 Nsight Compute（ncu）抓具体 kernel 的指标。重点关注这几个：

• DRAM Throughput：显存带宽实际利用率，接近峰值说明带宽打满
• Memory Throughput：整体访存吞吐
• Compute (SM) Throughput：计算单元利用率
• Achieved Occupancy：实际占用率

对于 decode 阶段的 GEMM（矩阵乘）kernel，如果看到 DRAM Throughput 在 80% 以上、Compute Throughput 只有 20%~30%，那基本可以确认是带宽瓶颈。这时候优化方向就是减少访存，而不是提升计算效率。

一个实操技巧：ncu 抓 kernel 时，用--kernel-name过滤出耗时最长的几个 kernel，逐个分析。decode 阶段耗时大头通常是 attention kernel 和 FFN 的 GEMM kernel，优先看这两个。

# 抓取耗时最长的 kernel，输出关键访存指标 ncu --set full --kernel-name regex:"gemm|attention" \ --launch-count 10 \ python infer.py

3.3 带宽利用率曲线的解读：什么时候该换优化方向

把不同 batch size 下的带宽利用率和吞吐画成曲线，能看出很多门道。

• batch size 从 1 涨到 8：吞吐快速上升，带宽利用率也上升，说明权重读取被有效摊薄
• batch size 从 8 涨到 32：吞吐继续上升但增速放缓，带宽利用率接近饱和
• batch size 超过 32：吞吐趋于平缓，带宽利用率打满，此时再增大 batch 收益很小，甚至因为 KV Cache 膨胀而下降

这条曲线的拐点，就是"带宽墙"的位置。到了拐点之后，继续增大 batch 不再有效，正确的方向是：降低权重精度（量化）、优化 KV Cache（PagedAttention、量化 KV）、或者做 kernel 融合减少中间访存。

注意：不同序列长度下拐点位置不同。短序列（<2K）拐点靠后，长序列（>8K）拐点明显前移，因为 KV Cache 开销占比上升。

4. 针对带宽瓶颈的四类优化手段与实测效果

4.1 量化：把权重从 BF16 压到 FP8/INT8 直接砍半带宽

既然瓶颈是权重读取，那最直接的办法就是让权重变小。把 BF16（2 字节/参数）量化到 FP8（1 字节/参数），权重体积直接砍半，理论带宽需求也砍半，单请求吞吐理论上能翻倍。

B200 对 FP8 有原生支持，这是它相比上一代的一个明显优势。用 FP8 跑 Qwen3-8B，实测单请求吞吐能从 200 tokens/s 左右提升到 350~400 tokens/s，提升幅度接近 80%。如果进一步用 INT8 或 INT4 量化，带宽还能再降，但精度损失需要评估。

量化的坑在于：不是所有层都适合量化。attention 的 Q/K/V 投影和 FFN 的 down 投影对精度比较敏感，量化后容易出现输出质量下降。实践中常用混合精度策略——大部分层用 FP8，敏感层保留 BF16。具体哪些层敏感，得靠实测对比困惑度（perplexity）来确定。

4.2 KV Cache 优化：PagedAttention 与 KV 量化

KV Cache 的优化有两个方向：

第一是内存管理层面，用 PagedAttention 把 KV Cache 分页管理，减少显存碎片，提升显存利用率。这在长序列、大 batch 场景下效果明显，能让同样的显存装下更多并发请求。

第二是精度层面，把 KV Cache 也量化到 FP8 甚至 INT8。KV Cache 量化对精度的影响通常比权重量化小，因为 attention 对 KV 的数值精度相对宽容。实测中，KV Cache 用 FP8 量化，长序列场景下带宽占用能降 40% 左右，吞吐提升 20%~30%。

这里有个经验：KV Cache 量化的收益随序列长度增长而增大。短序列下收益不明显，长序列（>8K）下收益显著。所以如果你的场景是长上下文，KV Cache 量化优先级很高。

4.3 kernel 融合与算子优化：减少中间激活值的往返

前面提到，中间激活值的反复读写是隐形的带宽杀手。kernel 融合就是把这些往返省掉。

几个高价值的融合点：

• FFN 融合：把 gate 投影、激活、up 投影融合成一个 kernel，省掉中间结果写回
• Attention 融合：FlashAttention 系列把 QK^T、softmax、PV 融合，避免中间矩阵进出显存
• LayerNorm + 投影融合：把归一化和后续投影合并

这些融合在 decode 阶段收益尤其大，因为 decode 阶段计算量小、访存占比高，减少访存直接转化为性能提升。实测中，做好 FFN 和 attention 融合，decode 吞吐能再提升 15%~25%。

4.4 增大 batch 与连续批处理：把固定成本摊薄

最后但同样重要的是批处理策略。前面反复强调，权重读取是固定成本，增大 batch 能摊薄它。但简单的静态 batch 不够灵活，因为不同请求的序列长度不同，会浪费计算。

连续批处理（Continuous Batching）是更优的方案：不等一个 batch 里所有请求都结束，而是动态地把新请求插入、把完成的请求移出。这样能保持 GPU 始终有活干，带宽利用率维持在高位。vLLM、TensorRT-LLM 都内置了这个机制。

实测对比：静态 batch size = 8 时，吞吐约 800 tokens/s；换成连续批处理后，同样显存下吞吐能到 1500~2000 tokens/s。差距主要来自显存利用率和调度效率的提升。

5. 单卡部署 Qwen3-8B 的实操配置与调参心得

5.1 显存预算分配：权重、KV Cache、激活值怎么分

在 B200 单卡上部署 Qwen3-8B，显存分配是个需要精打细算的事。B200 的显存容量在 180GB 量级（HBM3e），看起来充裕，但要做高并发，还是得规划好。

一个实用的分配思路：

• 权重：BF16 约 16GB，FP8 约 8GB
• KV Cache：这是大头，取决于并发数和序列长度。用 PagedAttention 后，可以按需分配，但要预留足够空间
• 激活值和临时缓冲：几 GB 量级
• 框架开销：vLLM 等框架本身有开销，预留 5~10GB

实操中，把gpu_memory_utilization设成 0.9 左右，让框架自动管理 KV Cache 的分配。如果显存不够，优先降 KV Cache 精度或限制最大并发数，而不是降权重精度（权重精度对输出质量影响更大）。

5.2 关键参数调优：max_num_seqs、max_model_len 的取舍

几个关键参数的调优逻辑：

• max_num_seqs：最大并发序列数。设得越大，吞吐越高，但 KV Cache 占用越大。要根据显存和序列长度权衡。短序列可以设大（如 256），长序列要设小（如 32）。
• max_model_len：最大序列长度。设得越大，KV Cache 预留越多。如果实际用不到那么长，设小一点能省显存。
• block_size：PagedAttention 的块大小。默认 16，一般不用改，特殊场景可以调。

调参的核心原则是：先保证不 OOM，再追求吞吐。很多人一上来就把 max_num_seqs 拉满，结果跑一会儿就 OOM，反而影响稳定性。

5.3 实测踩坑：那些文档里不会写的细节

分享几个实际踩过的坑：

坑一：FP8 量化后首 token 延迟反而变高。原因是量化模型的加载和反量化有额外开销，prefill 阶段受影响。解决办法是 prefill 用 BF16、decode 用 FP8 的混合策略，或者接受这个 trade-off。

坑二：连续批处理下长请求会拖累短请求。一个超长序列的请求会占用大量 KV Cache 和计算资源，导致短请求延迟上升。解决办法是设置请求优先级或做长度分桶。

坑三：带宽利用率看着高，但吞吐上不去。这种情况往往是 kernel 效率问题，不是纯带宽问题。要用 ncu 看具体 kernel 的访存效率，可能是访存模式不连续、bank conflict 等问题。

坑四：显存够但吞吐上不去。检查是不是被 max_num_seqs 或调度策略限制了。有时候框架的默认调度偏保守，需要手动调。

6. 从 nano-vllm 看推理框架的带宽优化设计

6.1 为什么值得读 nano-vllm 的源码

如果你想真正理解推理框架是怎么和带宽瓶颈搏斗的，nano-vllm 是个很好的学习材料。它把 vLLM 的核心机制（PagedAttention、连续批处理、KV Cache 管理）用精简的代码实现了一遍，去掉了工程上的复杂包装，逻辑清晰。

读它的价值在于：你能看到每一个设计决策背后的带宽考量。比如为什么 KV Cache 要分页、为什么调度要动态、为什么 attention 要融合。这些不是拍脑袋定的，都是被带宽瓶颈逼出来的。

6.2 PagedAttention 的内存管理逻辑

PagedAttention 的核心思想借鉴了操作系统的虚拟内存分页：把 KV Cache 切成固定大小的 block，用 block table 做逻辑到物理的映射。这样做的好处是：

• 消除显存碎片：不用为每个请求预留连续的大块显存
• 支持共享：相同前缀的请求可以共享 block（prefix caching）
• 灵活扩容：序列变长时按需分配新 block

从带宽角度看，PagedAttention 本身不直接降低带宽占用，但它提升了显存利用率，让你能在同样显存下跑更多并发，从而摊薄权重读取成本。这是间接的带宽优化。

6.3 连续批处理的调度实现要点

连续批处理的调度逻辑，核心是维护一个"运行队列"和"等待队列"。每个 decode step 结束后，检查哪些请求完成了，把它们移出；同时从等待队列里取新请求补进来。

实现要点：

• 调度粒度：每个 decode step 调度一次，保证 GPU 不空转
• 显存检查：插入新请求前要检查 KV Cache 是否有足够 block
• 抢占机制：显存不够时，可以抢占低优先级请求，把它们的 KV Cache 换出

这套机制的价值在于让 GPU 的带宽利用率始终维持在高位。没有连续批处理，GPU 会在请求切换的间隙空转，带宽利用率掉下来，吞吐自然上不去。

7. 带宽瓶颈之外：还有哪些隐藏的性能陷阱

7.1 通信开销：单卡场景下也不能忽视

单卡场景下没有卡间通信，但卡内通信（比如 kernel launch 开销、host-device 数据传输）依然存在。尤其是小 batch、短序列场景，kernel launch 开销占比会上升。

解决办法是减少 kernel 数量（kernel 融合）、用 CUDA Graph 把多个 kernel 打包成一次 launch。CUDA Graph 在 decode 阶段效果明显，能把 launch 开销降低一个数量级。

7.2 精度与性能的平衡点怎么找

量化能降带宽，但会损失精度。平衡点怎么找？我的经验是：

• 先用 FP8 权重 + BF16 KV Cache，测困惑度，如果和 BF16 基线差距在 1% 以内，就可以接受
• 如果差距大，把敏感层（通常是 attention 的 V 投影和 FFN 的 down 投影）保留 BF16
• KV Cache 量化对精度影响小，可以更激进

最终目标是：在可接受的精度损失下，拿到最大的带宽收益。这个平衡点因任务而异，生成任务对精度更敏感，分类任务相对宽容。

7.3 不同序列长度下的瓶颈迁移

最后强调一个动态视角：瓶颈会随序列长度迁移。

• 短序列（<2K）：权重读取主导，优化重点是权重量化和 batch 摊薄
• 中序列（2K~8K）：权重和 KV Cache 并重，两者都要优化
• 长序列（>8K）：KV Cache 主导，优化重点是 KV 量化和 PagedAttention

所以不存在一劳永逸的优化方案，得根据你的实际场景（序列长度分布、并发量）来定策略。我一般会先统计线上请求的序列长度分布，再针对性地调优，而不是盲目套用别人的配置。

这套拆解思路，从算术强度判断瓶颈类型，到访存路径分析，再到量化、KV 优化、kernel 融合、批处理四类手段，最后落到具体参数和踩坑经验，基本覆盖了单卡跑 Qwen3-8B 会遇到的核心问题。真正上手时，建议先用 ncu 把瓶颈定位清楚，再对症下药，别一上来就堆优化手段——很多时候，找准瓶颈比优化本身更重要。