交易员.Coder前几天有朋友拿了一段训练代码跑过来，跟我说他遇上了个特别憋屈的“性能悖论”：手里显卡明明是RTX级别的，用来跑PyTorch却比在公司旧CPU上还慢，一个epoch动不动就多出几倍时间。他检查了半天，甚至怀疑是不是显卡驱动坏了，要不要重装环境。我看了一眼他贴的代码，再让他去跑一条nvidia-smi看实时利用率，结果GPU占用率在个位数和40%之间反复横跳。问题从来不在显卡算力上，而在Python这边怎么写代码、怎么调用GPU资源。
这种“GPU变慢”的假象，在Python生态里太常见了。尤其是刚接触深度学习、刚在本机装好GPU版PyTorch的朋友，经常会在这一步被卡住。本文就把这个现象拆开讲清楚，从性能悖论的本质，到调用开销的账单，再到一个把整个调用结构理顺的Python特殊方法——__call__。我希望能用一篇文章帮大家把这个链路看透，以后再遇到GPU占用率上不去、训练反而变慢的问题，不至于一头雾水。
1. GPU变慢不是玄学：算力没少，是你的数据在“排队”等调用
1.1 从“GPU利用率只有9%”说起
先说说那个最直观的现象。很多人判断GPU是否“认真干活”，就打开nvidia-smi刷利用率，一旦看到利用率低，马上得出“显卡不行”的结论。但nvidia-smi里的GPU-Util只是GPU在采样周期内有没有活跃算子的粗略指标，不是算力被用满的比例。它更像是一个“有没有活干”的开关，而不是“活干得多重”的进度条。
一个比较典型的场景是：训练循环里，每一步都从磁盘读图、在CPU侧做数据增强，然后才转成Tensor送到GPU。在CPU把这一批数据准备好之前，GPU无事可做，利用率自然掉得很低。这不是GPU在“变慢”，而是数据管线在给GPU“供血不足”。
再往深一层看，GPU不是独立干活的，它需要CPU不断派发任务。CPU每派发一个计算任务，GPU执行完可能只需要几毫秒，但CPU准备这个任务、搬运数据、启动内核的耗时可能是几十毫秒甚至更多。如果代码里到处是细碎的小操作，CPU就会变成瓶颈，GPU大部分时间在空转等待。算力再高，也只能看着。
1.2 “性能悖论”的三种典型马甲
我把平时大家反馈的“GPU变慢”归类了一下，基本是这三种情况。
第一种是小任务跑不出优势。比如你要对一批几百个向量做余弦相似度计算，数据量本身很小，用GPU反而比CPU慢。原因在于GPU启动一个计算内核有固定开销，你要搬运数据、建立上下文、排队执行；任务本身太小，这些固定开销反而超过计算时间。CPU的优势是启动快、调度灵活，所以适合小任务。
第二种是循环里反复调用GPU算子。这是最常见的写法问题：在Python的for循环里，每次只处理一条样本，每个样本都要经历一次完整的Tensor搬运和一次模型推理。一次两次还好，但训练集有成千上万条数据时，等于把本来可以合并成一次的大型并行计算，硬生生拆成了成千上万次小调用。
第三种是CPU侧数据预处理和同步等待拖垮节奏。比如在训练循环里频繁调用.item()、.cpu()、.numpy()，这些操作都会强制CPU和GPU同步。GPU算完一步，必须等CPU把这些值拿回去处理完，才能开启下一步，流式并行的好处全没了，GPU变成一台“一步一停”的老式机器。
这三种情况加在一起，就会形成一个非常反直觉的现象：明明用上了GPU，训练却比CPU还慢。这不是悖论，而是你把GPU用错了方式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 实测：循环调用 vs 批量调用，时间差究竟有多大
2.1 一个小实验，把问题桌面化
光说不练假把式。我写了一个很小的对比实验，模拟“对一批向量做模型推理”的两种写法。假设有一个简单的编码器模型，输入是一批512维的向量，输出也是512维的向量；数据量是2000条。实验环境是PyTorch的GPU版，显卡是常见的中端卡。
先看“逐条推理”的写法：
python复制import torch
import time
from torch import nn
class SimpleEncoder(nn.Module):
def __init__(self):
super().__init__()
self.fc = nn.Sequential(
nn.Linear(512, 512),
nn.ReLU(),
nn.Linear(512, 512),
)
def forward(self, x):
return self.fc(x)
model = SimpleEncoder().cuda()
model.eval()
# 模拟2000条样本，每条都是[1, 512]的张量
samples = [torch.randn(1, 512).cuda() for _ in r