GPU利用率低训练慢？用__call__把PyTorch调用结构理顺

前几天有朋友拿了一段训练代码跑过来，跟我说他遇上了个特别憋屈的“性能悖论”：手里显卡明明是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用错了方式。

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 range(2000)]

with torch.no_grad():
    start = time.time()
    outputs = []
    for sample in samples:
        output = model(sample)      # 每次只跑一个样本
        outputs.append(output)
    elapsed_loop = time.time() - start

再看“一次批量推理”的写法：

python复制batch = torch.randn(2000, 512).cuda()

with torch.no_grad():
    start = time.time()
    outputs = model(batch)          # 一次把2000条全丢进去
    elapsed_batch = time.time() - start

这两段代码跑出来，差距是非常明显的。我在自己机器上测得的结果大致如下：

同样是一个模型、同一批数据，只因为调用方式不同，差了四十多倍。这就是“GPU变慢”的真相：不是模型算得慢，而是你给GPU派活的方式太碎了。

2.2 拆解一次GPU调用的账单

为什么逐条推理会这么慢？我们要把GPU调用的固定开销拆开看。

一次完整的GPU调用大致包括这几部分开销：Python解释器执行字节码、PyTorch框架层的类型检查和dispatch、CUDA runtime的函数调用、内核启动与排队、显存读写、CPU与GPU之间可能的同步等待。后面那些涉及CUDA的部分，虽然单次耗时很低，但并不是零。

举个例子，一个简单矩阵乘法的内核，在GPU上真正执行可能只需要几十微秒；但内核启动本身、Python侧函数栈的进出，可能也要几十微秒。如果样本量小，这些开销甚至比计算时间还高。而当你在一个2000次的循环里反复做这件事时，固定开销会被放大2000倍，最终变成几秒甚至几十秒的浪费。

把GPU想成一条流水线。你给它一整箱零件，它能同时处理；但你非要一个一个零件往传送带上放，流水线每次刚跑起来就停了，机器根本没法发挥并行优势。批量调用就是在积累足够多的零件再送进去，让流水线持续满载。

3. 把调用结构理顺：__call__在GPU工作流里到底解决什么

3.1 不只是语法糖：__call__让对象变成带状态的“函数”

讲完GPU性能问题，现在该请出今天的主角__call__了。可能有人会觉得奇怪：__call__和GPU有什么关系？它不就是让一个类实例能像函数一样被调用吗？关系很大，因为GPU工作流里最需要优化的，恰恰就是“调用结构”。

先看__call__最基础的用法：

python复制class Greeter:
    def __init__(self, prefix="Hello"):
        self.prefix = prefix

    def __call__(self, name):
        return f"{self.prefix}, {name}"

greeter = Greeter("Hi")
print(greeter("Python"))   # 输出 Hi, Python

定义__call__之后，对象greeter就能像普通函数一样使用。如果只看到这一层，那它确实只是语法糖。但真正的区别在于：一个对象可以在__init__阶段完成各种准备，把状态保存在属性里，之后每次“像函数一样调用”时，这些状态还能持续复用。

在GPU编程场景里，这个能力极其重要。你可以在初始化时完成设备选择、模型加载、显存预分配、归一化参数缓存；在调用阶段就不用反复做这些准备工作，只要专注处理数据即可。对比普通函数，它会强迫你把该缓存的参数塞进参数列表，于是每次调用都要重新走一遍环境判断、设备判断这些琐碎逻辑。

3.2 为什么GPU代码尤其需要“带状态的可调用对象”

为了说明这个点，我们可以回想前面那个慢代码：循环里逐条调用模型。如果把它改写成批量处理，最简单的方式是把一批数据先torch.stack成一个大的Tensor，再调用一次模型。但实际工程里，数据不是一开始就整整齐齐码在显存里的，它可能来自不同的预处理流程、不同的设备。这时候你需要的不是一段写死的批处理代码，而是一个能帮你统一设备、统一批量、统一调度的收口组件。

一个带状态的__call__对象，正好承担这个收口任务。外面的人不需要关心模型在哪个GPU上、输入是不是已经转到CUDA、要不要做归一化，只要把原始数据丢给这个对象就行。对象内部会利用保存好的设备句柄、缓存参数、批大小设置，自己完成组织张量、搬运、计算的过程。这就从代码结构上保证了“批量调用”不会退化成“散装调用”。

换句话说，__call__提供的是“调用即服务”。而调用开销的优化，恰恰需要这种从结构层面减少重复准备、强制批量聚合的设计。

4. 实战改造：一个GPU推理偏慢的代码，如何用__call__程序化提速

4.1 重构前的“裸函数”写法占满了哪些坑

为了让大家有更直观的体感，我拿一个具体的重构案例来讲。假设你要写一个文本向量检索服务，输入一组句子，输出对应的归一化向量。初版代码非常直白，直接写了一个普通函数：

python复制import torch
from torch import nn

model = None
device = None

def predict_one(texts, model, device):
    # 每次都要检查设备、转换Tensor
    inputs = tokenize(texts).to(device)
    with torch.no_grad():
        outputs = model(inputs)
    return outputs

def tokenize(texts):
    # 模拟一个文本转Tensor的过程
    return torch.randint(0, 1000, (len(texts), 16))

这个函数本身没什么问题，但调用方一旦在一个大循环里使用它，问题就来了：

python复制all_texts = [f"sample {i}" for i in range(2000)]
results = []

for i in range(0, len(all_texts), 8):
    chunk = all_texts[i:i+8]
    # 每次都要传入model和device，还得在外面维护torch.no_grad()
    result = predict_one(chunk, model, device)
    results.append(result)

这段代码有两个隐患。第一，每次函数调用都把model和device作为参数传一遍，函数内部无法缓存任何和GPU上下文相关的状态。第二，调用方必须自己控制批大小和循环逻辑，很容易退化成每条数据单独调用一次，或者漏掉torch.no_grad()导致中间变量占满显存。这种代码到了GPU上，自然会出现利用率忽高忽低的情况。

4.2 用__call__重构成一个可复用的GPU推理处理器

我把它重构成一个类，利用__init__承载所有状态，利用__call__对外提供统一的推理入口：

python复制import torch
from torch import nn

class TextVectorizer:
    def __init__(self, model: nn.Module, device="cuda", batch_size=64):
        self.model = model.eval().to(device)
        self.device = torch.device(device)
        self.batch_size = batch_size

    def _tokenize(self, texts) -> torch.Tensor:
        # 模拟把文本转成固定长度Tensor，实际项目里换成你的Tokenizer
        return torch.randint(0, 1000, (len(texts), 16))

    @torch.no_grad()
    def __call__(self, texts):
        # 如果没有数据，直接返回空Tensor
        if len(texts) == 0:
            return torch.empty(0, 512, device=self.device)

        outputs = []
        for start in range(0, len(texts), self.batch_size):
            chunk_texts = texts[start:start + self.batch_size]
            inputs = self._tokenize(chunk_texts).to(self.device)
            chunk_outputs = self.model(inputs)
            outputs.append(chunk_outputs)

        return torch.cat(outputs, dim=0)

# 初始化一次，之后反复调用
vectorizer = TextVectorizer(model, device="cuda", batch_size=64)

all_texts = [f"sample {i}" for i in range(2000)]
vectorized = vectorizer(all_texts)

重构后，调用方不需要再关心模型参数、设备转换、no_grad上下文管理这些问题。模型加载和缓存都发生在__init__阶段，批量逻辑封装在对象内部，外部只需要一句vectorizer(texts)就能拿到完整结果。

这个设计在GPU场景里的意义是：热路径上不再有重复的设备判断和临时变量传播，所有可能需要复用的状态都挂在同一个对象上。因为实例本身保存着model、device、batch_size，每次调用时省掉的这些准备工作虽然看起来不起眼，但在大循环中会被放大成非常可观的调度开销。

4.3 重构前后的对比结果

我在同一批数据上对比了三种写法：原始裸函数、按每条数据循环调用的裸函数、使用TextVectorizer批量调用的写法，结果如下：

需要说明的是，不同机器、不同模型结构下具体数值会有差异，但趋势非常一致：调用次数越碎、状态缓存越少，GPU利用率就越低，耗时就越长。把推理过程封装成可调用对象，核心价值不在于语法好看，而在于它会强制你把批量策略、状态缓存、统一入口放进同一个地方。

5. 在深度学习框架里，__call__相当于“官方专用入口”

5.1 为什么PyTorch模型推荐用model(x)而不是model.forward(x)

很多新手在写PyTorch时都会有一个疑问：定义模型时我重写的是forward，为什么调用时用的却是model(x)，而不是model.forward(x)？原因就在nn.Module内部重写了__call__。

看一段简化后的逻辑，思路是这样的：

python复制def __call__(self, *input, **kwargs):
    # 1. 先触发forward预钩子
    for hook in self._forward_pre_hooks.values():
        hook(self, input)

    # 2. 调用真正的前向计算
    result = self.forward(*input, **kwargs)

    # 3. 再触发forward后置钩子
    for hook in self._forward_hooks.values():
        hook(self, input, result)

    return result

实际源码比这复杂得多，还包含参数设备判断、版本计数、torch.fx图捕获支持等逻辑。但从这个简化版本就能看出来：forward只是__call__内部的一步，__call__才是完整的入口。

如果你绕过__call__直接调用forward，很多框架层的约定就不会生效。最常见的例子是注册了forward hook想提取中间层特征图，结果发现日志里什么都没打印——因为你跳过了钩子调度。所以 PyTorch 社区一直强调：调用模型统一走model(x)，这才是在调用框架约定好的完整前向流程。

5.2 手写前向时容易踩的“钩子失效”暗坑

我早期调试一个特征可视化脚本时，就踩过这个坑。当时为了拿某一层输出，我注册了一个forward hook，然后习惯性地写了output = model.forward(sample)。结果跑了半天，缓冲区里什么都没有。我还以为是hook写错了，排查了很久才发现问题是直接调了forward。

改成output = model(sample)之后，hook立刻生效，中间层特征顺利拿到了。那次排查给我留下很深的印象：__call__不只是语法上的便利，它是整个框架回调机制、钩子机制、设备管理机制的统一入口。你绕开它，等于绕开了框架给你准备好的全套管理能力。

所以，不要觉得__call__只是“让对象像函数那样调用”这么简单。在GPU场景里，框架就是通过这个入口帮你完成了批量调用背后的资源管理。你写的模型类虽然继承的是nn.Module，但真正生效的入口是继承下来的__call__。

6. 除了调用方式，GPU“假慢”还要查这五个方向

6.1 DataLoader的num_workers和pin_memory影响大于你的想象

如果你的数据预处理在CPU侧，GPU就很可能在等待。默认情况下DataLoader只用一个主进程加载数据，CPU预处理成了整个训练流程的瓶颈。调高num_workers可以让多个子进程并行加载和预处理数据，等于给GPU准备了好几个送料员。

同时开启pin_memory=True，可以让CPU侧的数据存放在锁页内存中，CPU到GPU的拷贝可以走更快的DMA通道，减少传输阻塞。我见过不少项目在没开这两个参数时训练速度上不去，开了之后整个训练时间直接砍半。

python复制dataloader = torch.utils.data.DataLoader(
    dataset,
    batch_size=32,
    shuffle=True,
    num_workers=4,
    pin_memory=True
)

6.2 训练循环里别到处加同步点

这条虽然前面提过，但值得单独强调：.item()、.cpu()、.numpy()这些操作都会打断GPU异步执行的节奏。

正常情况下，PyTorch的CUDA操作是异步的：你在代码里写了一串GPU运算，它们会被排到队列里连续执行，不需要CPU逐个等结果。但只要你调用.item()去取一个标量出来打印，CPU就必须等到这个GPU操作完成，整个队列的流水线优势就被破坏了。

调试时可以适度打印loss，但别在每一步都做这种事。真要看训练状态，可以每隔几十步打印一次，或者用torch.cuda.synchronize()手动控制同步点，而不是在每个小操作上都插入隐式同步。

6.3 显存不够导致的“假慢”：CUDA内存交换比计算慢得多

有些模型本身很大，或者batch size开得太大，显存不够用时，CUDA runtime就会执行内存整理、缓存清理，甚至把部分数据临时换出再换入。这个过程会严重拖慢速度，表现就是GPU利用率不低，但整体训练时间异常长。

遇到这种情况，最直接的解法是用torch.cuda.max_memory_allocated()看看训练过程中的峰值显存占用，然后调小batch size，或者使用混合精度训练（AMP）、梯度累积、梯度检查点等技巧。大模型微调时，torch.cuda.amp.autocast配合GradScaler几乎是我现在的默认配置，显存占用能省下不少。

6.4 cudnn.benchmark在动态shape下反而是负优化

torch.backends.cudnn.benchmark = True对固定输入shape的模型很有用，它会让cuDNN在第一次运行时自动测试多个算法，挑一个最快的，后续直接复用。

但如果你输入数据的sequence length、图像尺寸经常变化，这个开关会让模型每次遇到新shape都重新做一遍算法测试，反而增加额外开销。所以如果你在处理变长序列或者动态尺寸的输入，建议把这个开关关掉，或者只在固定shape的实验里打开。

6.5 多卡机器上，先确认代码跑在预想的那张卡上

在多GPU机器上，最容易忽视的是“你以为在跑0号卡，实际因为别的原因排到了别的卡上”。CUDA_VISIBLE_DEVICES是控制进程可见GPU的最直接方式，如果设了CUDA_VISIBLE_DEVICES=2，程序内部的所有cuda:0指向的都是物理3号卡，这个偏移会让很多人糊涂。

还有一点，模型参数和输入数据必须在同一张卡上。如果模型在cuda:0，输入张量却还在CPU上，PyTorch不会报错，但会在调用时隐式拷贝到GPU，这个拷贝是一次同步操作，会打断整条异步流水线。写代码时尽量在__init__阶段就统一好设备，不要每次计算前再做设备判断。

最后说两句

回想那个最初GPU利用率只有9%的问题，最终修复动作其实很简单：把逐条推理改成了批量推理，又顺手把推理逻辑封装成了一个可调用对象。整个过程没有换显卡、没有重装驱动，训练直接快了一个数量级。

我个人在这些日踩坑中最大的体会是：在Python里做GPU性能排查，优先看的往往不是GPU本身，而是Python怎么组织调用。GPU喜欢的是密集的大批量计算，Python擅长的是灵活调度和快速开发，这两者中间的桥梁，就是一层适合GPU工作流的代码结构。而__call__，恰好是设计中非常顺手的一个工具。它在PyTorch框架里是前向传播的官方入口，在业务代码里也能把模型、设备、批大小这些状态收敛到一个对象里，让GPU调用变得既清晰又高效。