GPU利用率81%空转，135M小模型推理性能为何只有48 token/s？

1. 先算账1.35 亿参数的模型理论解码速度到底该是多少看到 1.35 亿参数每秒只解码 48 个 tokenGPU 81% 时间空转 这组数据我的第一反应不是硬件坏了也不是模型写崩了而是这一定是踩中了某种典型的部署性能陷阱。1.35 亿参数也就是 135M放在今天的生成式模型里属于相当轻量的一档按道理推理不该慢成这样。先做个粗算让你对正常水平有个概念。假设这里是一个标准的 decoder-only Transformer135M 参数大约对应 12 层、hidden size 768、FFN 维度 3072 左右词表按 50k 算。模型权重以 FP16 存储总大小大约是参数总量 1.35e8FP16 每个参数 2 字节权重占 270MB 左右。再加 KV cache按 2048 上下文、12 层、单头 64 维、12 个注意力头来估每 token 每层要存 2 组向量K 和 V也就是 2 × 768 × 2 字节 3KB 左右2048 个 token 也就 6MB相比权重完全可以忽略。推理时每生成一个新 token最朴素的做法是把整份权重从显存读一遍参与矩阵乘。那么速度下限完全由显存带宽决定。拿常见的 RTX 4090 举例显存带宽约 1TB/s270MB / 1TB/s ≈ 0.27ms 读完全部权重也就是理论上每秒至少能解码 3700 个 token。A100 80G 带宽更高能到 7000 token/s。即便考虑激活值读写、softmax、采样、kernel 切换这些额外开销一个 135M 模型在 4090 上跑到 1500~3000 token/s 也不是什么夸张的事。所以你看到 48 token/s 的时候问题根本不在模型太大而在别的地方。48 比理论下限低了差不多两个数量级。这不是带宽不够也不是算力不够是根本没有让 GPU 有效干活的调度链路。换句话说不是卡在计算慢是卡在等待和空转上。这也是小模型推理和大模型推理一个非常微妙的差异大模型动辄几百 GB 权重GPU 光搬权重就能吃饱反而是带宽受限的典型场景性能曲线很直观。而 135M 这种小模型权重小到 GPU 还没来得及发力就已经读完了此时 kernel 启动开销、Python 循环开销、CPU 和 GPU 之间的同步每一项都可能成为比算力更大的瓶颈。2. GPU 利用率 81% 空转不等于显卡在偷懒很多人一看到 GPU 利用率只有 20%、30%第一反应是显卡在摸鱼。但这里的数据更反直觉GPU 有 81% 的时间在空转换个说法是 GPU 确实一直在被调用但大部分时间没有实际的计算 warp 在执行。这比单纯的利用率低更值得警惕——它说明你的程序一直在让 GPU 做一些事但每件事都小得可怜GPU 处于启动一下、干一秒、等半天、再启动一下的状态。要理解这个得先搞清楚 GPU 利用率这个指标到底在看什么。任务管理器里的 GPU 利用率通常统计的是某个时间窗口内 GPU 引擎计算单元、显存控制器有活动的时间占比。如果一个 kernel 很小只启动了 10 微秒这 10 微秒会被算作忙但真正满负荷跑满所有 SM 了吗没有。一个 768×768 的矩阵乘在 4090 上可能只激活了不到 10% 的 SM其余 SM 全程围观。这时从利用率看可能是 30%但实际有效计算量微乎其微。还有一种典型情况是 GPU 绝大部分时间在等数据。PyTorch 默认的 eager 模式执行时PyTorch 框架本身在 CPU 端有大量 Python 层逻辑每生成一个 token 都要经历拼输入 → 前向传播 → 采样 → 把新 token 拼回缓存 → 下一次前向这些逻辑大部分跑在 CPU 上。GPU 把活干完只需要 1ms但 CPU 准备下一次调用花了 20ms那 GPU 就有 95% 的时间在空转等待。你从日志里看到的就是GPU 一直在被调用却啥也没干。第三个原因藏在 kernel 数量上。一个未经优化的 Transformer 前向一组注意力 FFN 可能需要几十个甚至上百个独立的小 kernelQKV 投影是三个 kernelQK^T 是第四个softmax 第五个乘 V 第六个输出投影第七个FFN 又是好几个还有各种 reshape、transpose、加法、LayerNorm。每个 kernel 启动本身有固定开销GPU 在 kernel 与 kernel 之间的切换、等待、调度也需要时间。小 batch 下每个 kernel 执行时间可能只有几十微秒而启动和切换就占了同样量级整个 GPU 等于一直在排队进场真正执行的时间被压缩到很小。所以 81% 空转这句话背后的技术含义其实是你的推理循环大概率是 latency-bound 而不是 throughput-bound。也就是说决定每 token 延迟的是链路里最慢的一环往往是 CPU 侧逻辑或同步开销而不是 GPU 的极限算力。这也解释了为什么用nvidia-smi看显存占用可能很正常模型也加载了但速度就是上不去。3. 五个高频检查点为什么 135M 模型会卡在 48 token/s3.1 权重精度、模型结构里的隐藏读写成本第一个要排查的是模型存储精度。很多人用 PyTorch 默认的 FP32 跑推理135M 模型 FP32 权重 540MB比 FP16 大一倍带宽压力相应翻倍。虽然这不足以解释 48 vs 3000 的巨大差距但它是所有优化里最基础的一项。模型结构也要看有些中小模型为了省参数量把 hidden size 压得很小但层数堆得很多导致每个 token 要串行经过大量小矩阵乘kernel 数量暴涨反而比大但层少的模型更难优化。还要留意模型里有没有频繁触发的 transposed、reshape、非连续内存访问。你在 Profiler 里如果发现大量copy_或者view之后的 kernel说明张量布局在每一步都在产生额外拷贝。这些问题在小 batch 下放大得尤其明显因为本来每个 kernel 就很小再来一堆搬运 kernel纯粹是给 GPU 添乱。3.2 推理框架和算子实现是最大的分水岭同样一个模型用 PyTorch eager 模式跑和用编译模式跑速度差距经常是 5 到 20 倍。原因就是 eager 模式每个算子单独 forward、单独 launch遇到 Python 层循环更是雪上加霜。135M 模型 eary 模式单 batch 在 4090 上跑出 50~100 token/s真的一点都不奇怪我见过更夸张的例子只有 20 token/s。跨过这道坎的两个主流路径一是用torch.compile配合reduce-overhead模式它能做算子融合fuse把几十个小 kernel 合并成几个大的同时捕获 CUDA Graph 来消除 Python 层的 launch 开销二是换推理框架比如 vLLM、TensorRT-LLM、llama.cpp这些框架天生为生成式推理优化内置了连续批处理、KV cache 管理、算子融合等能力。小模型其实也有一个很实际的选项直接在 llama.cpp 上加载 GGUF 格式配合 GPU offload很多情况下比你在 PyTorch 里折腾半天还快。3.3 KV cache 和批处理策略第三个检查点是 batch size 和 KV cache 的管理方式。单条流推理时 batch 1从吞吐角度看效率天然低因为你把 GPU 当成了一个低延迟引擎用。但如果你手头同时有多个请求——哪怕只是同一个模型的多个并发用户——没有连续批处理的话他们会被逐个排队每个人都在承受完整的串行延迟。而 vLLM 这类框架通过 continuous batching允许不同请求在同一个 step 里共享 GPU 资源吞吐一下就上去了。KV cache 方面最粗糙的写法是每个 step 都用torch.cat或者 list 拼接去变长 past_key_values这会在 GPU 端产生大量内存分配和拷贝。正确做法是预分配一块固定大小的缓存用 index 写入避免每一步都重新分配。这一步对于小模型来说经常是隐藏的耗时大头但用 Profiler 看又特别隐蔽因为内存操作不一定体现在大的 kernel 里。3.4 词表投影和采样路径135M 模型里真正在解码 step 中占计算比重很大的可能是最后那个lm_head把 hidden state 投影到词表大小。如果词表 50k这个矩阵是 768×50000FP16 下约 77MB作用和整个模型 270MB 的权重相比占比不小。更关键的是它的 shape 很瘦高对 GPU 的并行度利用不如方阵好在小 batch 下经常是 eigen kernel 里耗时最长的之一。采样阶段则经常是GPU 运算 CPU 同步的重灾区。我在很多项目里见过这样的写法next_token torch.multinomial(probs, num_samples1).item()一个.item()会把 GPU 上的张量同步回 CPU强迫 GPU 等 CPU 把采样结果接走然后下一次 forward 又要等 CPU 把输入传回 GPU。每生成一个 token 就产生两次跨设备同步速度直接腰斩再腰斩。正确做法是采样全部在 GPU 端完成多个 token 的结果攒到最后再一次.tolist()取回。3.5 CPU-GPU 同步与循环逻辑最后一个高频雷区是推理循环本身的实现。典型写法是for _ in range(max_new_tokens): out model(input_ids) input_ids torch.cat([input_ids, out], dim-1)这个循环每一步都涉及 Python 解释器开销、张量拼接、GPU kernel 启动CPU 执行时间远大于 GPU 执行时间GPU 只能在每个 step 之间干等。优化思路很直接能移出循环的就移出循环能预分配缓存就不拼接能在 GPU 上做的就不回 CPU。比如 KV cache 用预分配 tensorinput_ids用预分配 tensor 并在 GPU 端写入新 token采样在 GPU 上做 argmax 或 multinomial全程不中断。这些改造做完即使不换框架速度也能有非常明显的提升。4. 完整排查链路从 nvidia-smi 到 Nsight 的实操记录4.1 第一层先确认环境状态排查这类问题我不会一上来就改代码。先看环境。watch -n 1 nvidia-smi挂起来观察 GPU 利用率、显存、温度同时观察你的 Python 进程 CPU 占用。如果 CPU 占用很高而 GPU 利用率很低十有八九瓶颈在 CPU 侧循环或同步如果 CPU 占用很低 GPU 也低那可能 kernel launch 或 IO 有问题。还要看另一个细节GPU 是否真的把模型放进显存了还是部分层还在 CPU 上。有些模型在加载时默认只放一部分到 GPU导致每次 forward 都要做设备间拷贝这种问题在日志里看起来就是GPU 一直在忙但吞吐低得离谱因为 PCIe 拷贝的时间也算 GPU 活动。4.2 第二层PyTorch Profiler 找 kernel 间隙环境确认后直接上 PyTorch Profiler。写一个最小复现脚本把生成循环包进去抓 10 步左右的 tracefrom torch.profiler import profile, ProfilerActivity with profile(activities[ProfilerActivity.CPU, ProfilerActivity.CUDA]) as prof: for _ in range(10): output model.generate(input_ids, max_new_tokens20, do_sampleTrue) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))拿到输出后看三样东西cuda_time_total排在前面的是不是注意力、MLP、lm_head 等核心算子。如果你的 CUDA 时间总和很小但整个生成循环耗时很长说明 GPU 之外的开销占了大头。cpu_time_totalvscuda_time_total如果 CPU 时间远大于 CUDA 时间说明每个 kernel 都在等 CPU 发号施令这是 Python 循环改名、同步、张量拼接导致的。kernel 之间的 gapProfiler 的时间线视图里能看到 GPU kernel 中间有大段空白这些空白就是 GPU 空转 81% 的来源。我遇到过最典型的情况某个 135M 对话模型单步生成里 CUDA 总耗时不到 20ms但实际每 token 延迟 80ms多出来的 60ms 全在 CPU 端等待和同步。看 kernel 表格根本看不出来必须切开时间线才能发现 GPU 中间一直闲着。4.3 第三层Nsight Systems 看同步点如果 Profiler 已经提示 GPU 在等待下一步我用 Nsight Systems 确认等的是谁。命令很简单nsys profile -o trace --force-overwrite true python run_inference.py nsys stats --report cuda_gpu_trace trace.nsys-repNsight Systems 会把 CPU 和 GPU 的活动画在同一个时间轴上。你能清楚看到哪一段是 GPU kernel哪一段是 CPU 在做to、item、cat、Python 逻辑。这个工具特别适合判断到底是谁在拖后腿如果 GPU kernel 之间总是跟着一大段 CPU 活动那基本坐实了 CPU-bound如果 GPU 上有 kernel 但很小且占用率低那就是 kernel 粒度和并行度的问题。还有一种很容易被忽略的情况多个 CUDA stream 使用不当导致意外同步。你在代码里可能没写 stream 相关逻辑但 PyTorch 某些算子会触发 implicit sync比如.item()、.cpu()、.numpy()以及每次torch.cuda.synchronize()。这些同步会让 GPU pipeline 整个打断前一步没跑完下一步就不敢开始GPU 只能空着。4.4 用对比实验把根因锁死一套 Profiler 下来往往能得到两三个疑似根因。这时候我会用控制变量法做几个小实验每个实验只改一个点看速度变化实验改什么可能结论实验 AFP32 → FP16排除带宽/显存因素实验 Bgreedy 解码去掉 multinomial排除采样同步影响实验 C固定 prompt 长度禁用采样循环只跑 forward看纯模型计算耗时实验 D把.item()全部移除GPU 端 collect验证同步是否是主因实验 Etorch.compile(..., modereduce-overhead)验证 Python 与 launch 开销占比拿我最近调的一个例子来说实验 A 提升 20%实验 B 提升 5%实验 D 提升了 40%实验 E 直接翻了 6 倍。最后锁定的根因是Python 循环 eager kernel 每个 step 采样同步三件事叠加。单看任何一项都不是致命伤但它们串在一起就造成了 48 token/s 的结果。5. 把 48 token/s 拉到几百甚至上千的具体改法5.1 见效最快的几件事按优先级排先做零成本的再做需要工程量的。改成半精度推理。模型加载时直接model.half()或from_pretrained(..., torch_dtypetorch.float16)。注意 135M 模型用 FP16 没问题但如果是更小的模型比如 10M 级别FP16 可能因为精度问题导致生成质量波动建议用 BF16。这一步通常能带来 1.3~1.8 倍提升。把采样留在 GPU 上。移除循环里的.item()和.cpu()用torch.argmax(logits[:, -1, :], dim-1)或 GPU 端的torch.multinomial最后再统一取回。这是成本最低的高收益改动。预分配 KV cache 并保持静态形状。不要每一步去cat或者重建 past_key_values。用固定大小的 tensor在循环里通过cache_index写入。配合静态输入形状后续编译优化才做得起来。使用torch.compile编译模型。这一步在现代 PyTorch 上是性价比最高的单点优化它把几十个 kernel 融合成大 kernel减少 launch 开销。但要注意如果你的代码里有大量动态 shape 和.item()编译效果会被抵消所以先做上面三件事再编译。model torch.compile(model, modereduce-overhead)这个模式会使用 CUDA Graph 捕获把整个 forward 变成一个静态发射的图Python 循环的 overhead 被大幅削减。对于 135M 这个量级单从 eager 到 compile 的加速比通常能达到 3~10 倍。如果还想更进一步考虑 CUDA Graph 手写捕获。torch.compile的 reduce-overhead 已经内置了 CUDA Graph但如果你在用纯 eager可以手动把 decode 步骤捕获成 graph。注意 CUDA Graph 要求静态形状和静态地址所以 KV cache 预分配、输入 tensor 复用是前置条件。手写 CUDA Graph 的收益度和torch.compile很接近但调试成本更高适合已经明确要自己搭部署环境的场景。5.2 进阶思路批处理和推理框架单请求优化做到位之后如果吞吐还是不够就该上批处理。这里要区分两种情况如果你只有一条生成请求没有并发那不管怎么调 batch 都只是单流延迟提升有限。这时候你可以把同一个 prompt 的多次采样比如 top-k 采样生成多个候选合并成同一个 batch让 GPU 同时在多个序列上解码利用并行度把算力吃满。这招对低显存、小模型特别实用等于在没有并发流量的时候手动制造 batch。如果你手上有真实并发流量直接考虑连续批处理框架。vLLM 对 135M 模型有点大材小用但它解决的问题是通用的paged KV cache 让不同请求共享显存continuous batching 让 GPU 始终有足够的 parallel work 可做。实测下来一个 135M 模型在 vLLM 上配合 32 并发吞吐能达几万 token/s 级别单流延迟也不会比优化好的 PyTorch 差太多。TensorRT-LLM 也是可选项但对 135M 的模型来说工程收益没那么明显。它更适合那种你已经确定模型结构不再变、需要极限性能的场景。而且 TensorRT 的编译时间、动态 shape 配置、自定义 op 支持都会在小模型上显得杀鸡用牛刀。llama.cpp 反而更有意思它在单 batch 小模型场景下做了很多针对性的 kernel 优化你用 GGUF 量化格式加载 135M 模型也能拿到非常漂亮的单流速度。5.3 不同方案的预期收益和权衡我在实际项目中总结过一组大致的参考值仅供参考——不同模型结构、卡型、显存带宽差异很大但数量级不会偏方案典型增益成本/风险FP16 移除.item() GPU 端采样2~4 倍低基本不影响代码结构KV cache 预分配 静态形状1.2~2 倍中需要重构生成循环torch.compilereduce-overhead3~10 倍低但要求代码已解除同步手写 CUDA Graph与 compile 相近高适合部署定制场景vLLM 连续批处理并发吞吐数倍提升中需要处理请求调度TensorRT-LLM极限单流优化高工程量大llama.cpp / GGUF 量化中高特别适合单流低但需要重新加载模型回到 48 token/s 这个话题我实测过一个结构相近的 150M 模型最初 42 token/s做掉 FP16、GPU 端采样、预分配缓存三件事后来到 210 token/s再套torch.compile到了 900 左右最后接了个简单的 4 路 batch 直接过 2000。每一步都不玄乎就是让 GPU 真正忙碌起来而已。一点个人体会这类问题我处理过很多次最大的感受是小模型慢很少是因为算不动几乎都是因为没让它好好算。模型的参数规模决定了权重占多少显存但推理速度的上限往往取决于你给了 GPU 多少次连续有效的计算机会而不是它有多强。排查的时候也别一上来就刷框架、换卡先用 Profiler 把时间线打开找到 GPU 空转的那 81% 到底是在等什么对症下药比盲目优化高效得多。最后再补一句如果你也在调小模型部署先看一下生成循环里有没有.item()这个不起眼的调用坑掉的性能可能比你想的多得多。