1. 为什么这篇论文值得翻出来重读深度学习模型这几年膨胀得厉害从几年前的几百万参数一路飙到百亿、千亿级别。显存容量却没能跟上这个节奏高端加速卡也就几十GB的显存训练一个中等规模的模型动不动就爆显存。很多人第一反应是换卡、加卡但硬件成本摆在那里不是每个团队都能随便堆设备。这篇论文讨论的核心问题就是在单卡显存有限的前提下怎么把更大的模型塞进去跑起来。论文标题里的关键词是vDNN、Virtualized、Scalable、Memory-Efficient。拆开看vDNN 是这套方案的代号Virtualized 指的是把显存当成一层可以调度的“虚拟资源”来管理Scalable 说的是模型规模可以随显存策略灵活伸缩Memory-Efficient 则是最终要达成的效果——用更少的显存跑更大的网络。它解决的是训练阶段显存墙的问题适合做模型训练、显存优化、系统方向的同学参考也适合工程实践中被显存卡住脖子的开发者。我第一次接触这篇工作是在做一个图像分类项目的时候模型规模不算特别夸张但加上中间激活值、梯度、优化器状态显存占用直接翻了好几倍单卡根本放不下。当时试过减小 batch size结果训练速度慢得没法接受试过梯度累积又引入了额外的调参负担。后来看到 vDNN 的思路才意识到显存管理本身就是一个可以独立优化的维度不一定非要靠堆硬件解决。这篇论文的价值不在于提出了某个复杂的算子或者全新的网络结构而在于它把显存分配这件事从“静态预留”变成了“动态调度”。这个思路放到今天依然有参考意义因为现在很多框架的显存管理虽然进步了但底层逻辑和这篇论文一脉相承。下面我会从设计思路、核心机制、实操复现、常见问题几个角度把这篇论文拆开讲清楚尽量让没读过原文的人也能理解它在做什么、为什么这么做、怎么落地。2. 论文整体设计与思路拆解2.1 显存墙的本质不是容量不够是利用率太低要理解 vDNN 的设计动机先得搞清楚训练时显存到底被谁吃掉了。一个典型的训练过程显存占用大致分几块模型参数、梯度、优化器状态比如 Adam 的动量和方差、前向传播的中间激活值、以及临时缓冲区。其中参数和梯度是必须常驻的优化器状态也是常驻的真正有弹性的是中间激活值。中间激活值是前向传播时每一层产生的输出反向传播计算梯度时需要用它们。问题在于这些激活值的生命周期很短——前向算完某一层它的输出在反向用到之后就可以释放了。但传统框架的做法是“能留就留”因为释放再重新计算有开销。结果就是显存里堆了大量其实已经用不到的激活值真正需要的时候反而没空间。论文里给了一组数据在当时的硬件条件下一个中等规模的卷积网络激活值占用的显存可以占到总占用的百分之六七十。也就是说显存里一大半空间被“暂时不用但舍不得扔”的数据占着。vDNN 的核心洞察就是如果把这些激活值在不用的时候挪到别的地方需要的时候再拿回来就能腾出大量显存给更大的模型或者更大的 batch size。这个“别的地方”就是主机内存。主机内存通常比显存大一个数量级而且价格便宜得多。把激活值在显存和主机内存之间做交换本质上就是用时间换空间。论文要解决的关键问题是怎么交换才能让额外开销尽可能小同时保证正确性。2.2 为什么选择主机内存而不是其他方案当时也有其他思路比如重计算recomputation也就是不存激活值反向传播时重新算一遍。重计算的好处是不需要额外存储但代价是计算量翻倍对于计算密集型的层来说不划算。另一种思路是模型并行把不同层放到不同设备上但这需要多卡硬件门槛高。vDNN 选择主机内存交换逻辑是这样的主机内存容量大、成本低而且 PCIe 带宽虽然比不上显存带宽但对于激活值这种“一次性读写”的数据来说带宽瓶颈没有想象中那么严重。关键在于调度策略——什么时候把数据挪出去什么时候挪回来怎么挪才能和计算重叠。论文里做了一个很重要的区分前向传播和反向传播的显存行为是不对称的。前向传播是逐层产生激活值显存占用线性增长反向传播是逐层消耗激活值显存占用线性下降。如果能在前向传播时就把暂时不用的激活值挪到主机内存反向传播时再按需取回就能把显存峰值压下来。这个思路听起来简单但实现起来有几个难点。第一哪些激活值可以挪走、哪些必须留在显存里需要一个判断标准。第二挪走的时机和取回的时机要精确控制早了会影响计算晚了显存已经爆了。第三数据传输和计算要尽量重叠否则额外开销会拖慢训练速度。论文针对这三个问题分别给出了方案。2.3 vDNN 的整体架构三层管理论文把 vDNN 的设计分成三个层次来理解。最底层是显存池管理负责跟踪显存里每一块内存的分配和释放知道哪些是参数、哪些是激活值、哪些是临时缓冲区。中间层是交换决策根据当前显存压力、层的类型、数据大小等因素决定哪些激活值需要挪到主机内存。最上层是调度执行负责在合适的时机发起数据传输并尽量让传输和计算重叠。这个分层设计的好处是解耦。显存池管理不关心具体策略交换决策不关心底层怎么传调度执行不关心为什么选这个数据。每一层可以独立优化也方便后续扩展。比如后来有人在这个框架上加入更复杂的决策模型或者适配不同的硬件拓扑都不需要改动底层。论文里特别强调了层的粒度问题。交换的最小单位是一层的激活值而不是整个网络或者单个张量。这个粒度选择是有讲究的太细了调度开销大传输次数多太粗了灵活性差可能挪走的数据还没到该用的时候就又需要了。按层来切刚好匹配前向和反向的逐层计算模式调度逻辑也清晰。2.4 和现代显存优化技术的关系现在回头看vDNN 的很多思想已经被吸收到主流框架里了。比如 PyTorch 的显存管理、TensorFlow 的内存规划器都在不同程度上做了类似的事情。但 vDNN 的独特之处在于它把主机内存交换作为一个显式的优化手段而不是只做显存内的复用。这个区别很重要。显存内复用只能解决“碎片化”和“生命周期重叠”的问题但显存总量是硬上限。主机内存交换则突破了显存容量的物理限制让模型规模可以超过单卡显存。当然代价是额外的数据传输开销所以论文花了很多篇幅讨论怎么把这个开销压到最低。从今天的视角看vDNN 的思路在几个场景下依然有参考价值。一是单卡训练大模型时显存不够但主机内存充裕二是多任务共享一张卡时需要动态调整各任务的显存占用三是边缘设备上显存极其有限但可以外接存储。这些场景下显存交换依然是一个实用的选项。3. 核心细节解析与实操要点3.1 交换决策哪些激活值该被挪走论文里给出的交换决策逻辑核心是一个优先级排序。不是所有激活值都值得挪走因为挪走意味着后续要挪回来有传输开销。如果一个激活值很快就会被反向传播用到那挪走再挪回来就是白费功夫。所以决策的关键是判断“这个激活值距离被使用还有多久”。论文用了一个简单的启发式规则距离反向传播越远的层其激活值越优先挪走。因为反向传播是从最后一层往前推的最后一层的激活值最先被用到第一层的激活值最后才被用到。所以前向传播时最早产生的那些激活值也就是浅层的激活值可以最先挪走因为它们要等很久才会被反向用到。这个规则背后有一个隐含假设反向传播的顺序和前向传播严格相反。对于大多数前馈网络和卷积网络这个假设成立。但对于有跳跃连接的网络比如 ResNet情况会复杂一些因为某一层的激活值可能被多个后续层引用。论文里也讨论了这种情况处理方式是引用计数——只有当某个激活值的所有引用都已经被反向传播处理完才认为它可以被释放或挪走。实操中这个决策逻辑可以简化成一个队列。前向传播时每产生一个激活值就把它加入队列同时记录它的“最晚使用时间”。当显存压力超过阈值时从队列头部也就是最晚被使用的开始挪走。反向传播时按需从主机内存取回。这个队列模型实现简单效果也不错。注意引用计数在实现时容易出错尤其是遇到原地操作in-place operation时。如果某一层对输入做了原地修改引用计数会失效。论文里建议对这类层特殊处理要么不挪走它的激活值要么在挪走前做一次拷贝。3.2 传输与计算的重叠怎么让交换不拖慢训练交换本身是有开销的数据从显存拷到主机内存再从主机内存拷回来走的是 PCIe 总线。如果串行执行训练速度会明显下降。论文的核心优化之一就是把传输和计算重叠起来。具体做法是在计算某一层的时候同时传输另一层的数据。比如前向传播计算第 k 层时可以把第 k-2 层的激活值往主机内存传。因为第 k 层的计算不依赖第 k-2 层的数据两者可以并行。反向传播同理计算第 k 层梯度时可以预取第 k2 层的激活值。这个重叠策略需要双缓冲或者多缓冲的支持。也就是说显存里要留出一块区域专门用于传输中的临时数据不能和计算用的显存冲突。论文里建议至少留两块缓冲区一块用于传出一块用于传入这样可以实现全双工传输。重叠的效果取决于计算时间和传输时间的比例。如果某一层计算量很大传输时间相对较短那重叠后几乎看不到额外开销。如果某一层计算量很小传输时间占主导那重叠效果就有限。论文里给了一个经验公式当计算时间大于传输时间时重叠可以完全隐藏传输开销。所以在选择哪些层做交换时优先选计算量大的层这样重叠收益最高。3.3 显存池的分配策略减少碎片化显存碎片化是另一个容易被忽视的问题。训练过程中不断有激活值产生和释放如果分配策略不当显存里会出现很多小块空闲区域虽然总空闲量够但找不到一块连续的大空间来分配新数据。vDNN 用了一个池化分配器来解决这个问题。池化分配器的思路是预先分配一大块显存作为池子所有激活值都从这个池子里切分。释放时不是真正还给系统而是标记为空闲供后续分配复用。这样可以避免频繁向系统申请和释放显存减少碎片。论文里还提到了大小类的概念。把激活值按大小分成几个类别每个类别维护一个空闲列表。分配时从对应类别的空闲列表里找找不到再向池子申请新的。这个做法借鉴了通用内存分配器的设计在显存管理里同样有效。实操中池子的大小需要根据模型和 batch size 来调。太小了不够用太大了浪费显存。论文建议先用一个较小的池子跑起来观察峰值占用然后逐步调整。另外池子的分配和释放要尽量成对出现避免长时间持有不用的显存块。3.4 层的粒度与调度开销的权衡前面提到交换的最小单位是一层的激活值。这个粒度选择需要权衡。如果按单个张量来交换调度更灵活但调度次数多每次调度的固定开销比如函数调用、状态检查会累积。如果按整个网络来交换调度次数少但灵活性差可能挪走的数据还没到该用的时候就又需要了。论文里做了一个实验对比了不同粒度下的开销。结论是按层交换在大多数情况下是最优的。因为层的边界和前向/反向的计算边界天然对齐调度逻辑简单而且一层的激活值通常是一个连续的内存块传输效率高。不过也有例外。对于某些特别大的层比如全连接层一层的激活值可能就有几百MB这时候按层交换的粒度就太粗了可能需要拆成更小的块。论文建议对超过某个阈值的层做拆分具体阈值根据 PCIe 带宽和显存容量来定。提示拆分大层时要注意保持数据的连续性。如果拆出来的块在内存里不连续传输时需要多次拷贝反而增加开销。建议在分配显存时就按块对齐保证每个块都是连续的。4. 实操过程与核心环节实现4.1 环境准备与基础配置要复现 vDNN 的核心思路不一定非要找到原论文的代码。我们可以基于主流框架自己实现一个简化版。这里以 PyTorch 为例因为它的显存管理接口比较开放方便做定制。首先需要确认几个基础条件。一是硬件支持 PCIe 传输这个基本上所有独立显卡都支持。二是框架版本不要太老建议用近两年的版本因为显存分配器的行为在不同版本间有差异。三是主机内存要足够大至少是显存容量的两到三倍否则交换空间不够。配置上需要关注几个参数。torch.cuda.memory_allocated()可以查看当前显存占用torch.cuda.max_memory_allocated()可以查看峰值占用。这两个接口在调试时很有用。另外torch.cuda.empty_cache()可以释放未使用的显存缓存但在 vDNN 场景下要谨慎使用因为它会清空池子导致后续分配重新向系统申请。import torch # 查看当前显存占用 current_mem torch.cuda.memory_allocated() / 1024**2 # MB peak_mem torch.cuda.max_memory_allocated() / 1024**2 print(fCurrent: {current_mem:.1f} MB, Peak: {peak_mem:.1f} MB) # 查看显存池的状态 print(torch.cuda.memory_summary())memory_summary()会输出显存池的详细状态包括已分配、已缓存、空闲块等信息。通过观察这些信息可以判断显存碎片化程度和池子利用率。4.2 实现一个简单的激活值交换钩子PyTorch 提供了 forward hook 和 backward hook可以在前向和反向传播时插入自定义逻辑。我们可以用 hook 来实现激活值的自动交换。思路是这样的在前向 hook 里把当前层的输出保存到一个自定义的存储管理器里而不是让它留在显存中。在反向 hook 里从存储管理器里取回对应的激活值。存储管理器负责决定哪些激活值放在显存、哪些放在主机内存。import torch import torch.nn as nn class ActivationSwapManager: def __init__(self, gpu_budget_mb4096): self.gpu_budget gpu_budget_mb * 1024**2 self.activations {} # 存储激活值 self.on_gpu set() # 当前在显存中的激活值key self.cpu_store {} # 主机内存中的激活值 def save(self, key, tensor): # 保存激活值根据显存预算决定放哪里 if torch.cuda.memory_allocated() self.gpu_budget: self.activations[key] tensor self.on_gpu.add(key) else: self.cpu_store[key] tensor.cpu() self.activations[key] None def load(self, key): # 取回激活值 if key in self.on_gpu: return self.activations[key] else: tensor self.cpu_store.pop(key).cuda() self.activations[key] tensor self.on_gpu.add(key) return tensor def release(self, key): # 释放激活值 if key in self.on_gpu: self.on_gpu.remove(key) self.activations.pop(key, None) self.cpu_store.pop(key, None)这个管理器很粗糙但能说明核心逻辑。实际使用时需要在每个需要交换的层上注册 hook。manager ActivationSwapManager(gpu_budget_mb4096) def make_forward_hook(layer_name): def hook(module, input, output): manager.save(layer_name, output) return output return hook def make_backward_hook(layer_name): def hook(module, grad_input, grad_output): # 反向传播时取回激活值 manager.load(layer_name) return grad_input return hook # 对需要交换的层注册hook for name, module in model.named_modules(): if isinstance(module, (nn.Conv2d, nn.Linear)): module.register_forward_hook(make_forward_hook(name)) module.register_full_backward_hook(make_backward_hook(name))注意register_full_backward_hook和register_backward_hook的行为不同前者更安全但要求模块的输入和输出都是张量。对于有多个输入输出的模块需要额外处理。4.3 传输与计算重叠的实现上面的实现是串行的保存时同步拷贝到主机内存取回时同步拷贝回显存。这样会阻塞计算训练速度会明显下降。要实现重叠需要用 CUDA 的异步拷贝接口。PyTorch 里可以用tensor.to(cpu, non_blockingTrue)来做异步拷贝但前提是张量在锁页内存pinned memory里。锁页内存的分配需要用torch.cuda.pinned_memory或者tensor.pin_memory()。class AsyncSwapManager(ActivationSwapManager): def save_async(self, key, tensor): if torch.cuda.memory_allocated() self.gpu_budget: self.activations[key] tensor self.on_gpu.add(key) else: # 异步拷贝到锁页内存 cpu_tensor torch.empty_like(tensor, devicecpu, pin_memoryTrue) cpu_tensor.copy_(tensor, non_blockingTrue) self.cpu_store[key] cpu_tensor self.activations[key] None def load_async(self, key): if key in self.on_gpu: return self.activations[key] else: cpu_tensor self.cpu_store.pop(key) gpu_tensor torch.empty_like(cpu_tensor, devicecuda) gpu_tensor.copy_(cpu_tensor, non_blockingTrue) self.activations[key] gpu_tensor self.on_gpu.add(key) return gpu_tensor异步拷贝的关键是拷贝和计算在不同的流stream里执行。PyTorch 默认使用默认流异步拷贝会在默认流里排队如果计算也在默认流里两者还是串行的。需要显式创建不同的流。swap_stream torch.cuda.Stream() def save_with_stream(key, tensor): with torch.cuda.stream(swap_stream): cpu_tensor torch.empty_like(tensor, devicecpu, pin_memoryTrue) cpu_tensor.copy_(tensor, non_blockingTrue) return cpu_tensor这样拷贝操作在swap_stream里执行计算在默认流里执行两者可以并行。但要注意同步问题在取回数据之前需要确保拷贝已经完成。可以用swap_stream.synchronize()或者事件event来同步。4.4 参数选择与性能调优vDNN 的效果很大程度上取决于几个关键参数的选择。第一个是显存预算也就是池子的大小。这个值设得太小交换频繁开销大设得太大显存不够用起不到交换的效果。论文建议从模型峰值占用的百分之七十开始试逐步调整。第二个是交换阈值也就是显存占用达到多少时开始触发交换。这个值通常设为显存预算的百分之八十到九十。设得太低交换过于激进很多本来可以留在显存里的数据被挪走设得太高显存已经快满了才开始交换可能来不及。第三个是传输块大小。一次传输的数据量越大传输效率越高但灵活性越差。论文建议传输块大小在几MB到几十MB之间具体根据 PCIe 带宽和层的激活值大小来定。下面是一个参数配置的参考表参数建议范围说明显存预算峰值占用的70%-90%太小导致频繁交换太大起不到效果交换阈值预算的80%-90%触发交换的显存占用比例传输块大小4MB-64MB根据PCIe带宽和层大小调整缓冲区数量2-4块双缓冲起步多缓冲提升重叠效果异步流数量1-2个太多流会增加调度开销调优时建议先用小模型跑通流程确认正确性再逐步放大模型和 batch size。每次只调一个参数观察显存峰值和训练速度的变化。如果训练速度下降超过百分之二十说明交换开销太大需要调整策略。5. 常见问题与排查技巧实录5.1 交换后训练结果不对数值精度问题这是最容易踩的坑。激活值从显存拷到主机内存再拷回来理论上应该是无损的但实际中可能因为精度问题导致结果偏差。最常见的原因是半精度训练。如果模型用 FP16 训练激活值也是 FP16拷贝过程中如果中间经过了 FP32 的转换可能会引入舍入误差。排查方法是先用 FP32 跑一遍确认结果正确再切换到 FP16。如果 FP16 下结果不对检查拷贝过程中有没有隐式的类型转换。PyTorch 的copy_操作会保持数据类型但如果用了tensor.float()或者tensor.half()就会改变类型。另一个可能的原因是锁页内存的分配失败。如果系统锁页内存不足pin_memoryTrue会退化成普通内存异步拷贝变成同步拷贝虽然不影响正确性但会影响性能。可以用torch.cuda.pinned_memory的接口检查锁页内存的可用量。提示如果发现结果有微小偏差但不影响最终收敛可以忽略。如果偏差很大优先检查数据类型和拷贝路径。5.2 训练速度大幅下降重叠没生效交换本身有开销但如果重叠生效额外开销应该很小。如果训练速度下降明显说明重叠没生效。常见原因有几个。一是拷贝和计算在同一个流里。前面提到过PyTorch 默认使用默认流如果拷贝也在默认流里两者就是串行的。需要显式创建不同的流并把拷贝操作放到独立的流里。二是锁页内存没分配成功。异步拷贝要求源数据或目标数据在锁页内存里。如果锁页内存分配失败non_blockingTrue会被忽略拷贝变成同步的。可以用tensor.is_pinned()检查。三是同步点太多。如果在拷贝之后立即调用了torch.cuda.synchronize()或者访问了拷贝结果就会强制等待拷贝完成重叠失效。需要检查代码里有没有不必要的同步操作。排查时可以用 PyTorch 的 profiler 工具查看拷贝操作和计算操作的时间线确认两者是否重叠。with torch.profiler.profile( activities[torch.profiler.ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3) ) as prof: for step, data in enumerate(dataloader): train_step(data) prof.step() print(prof.key_averages().table(sort_bycuda_time_total))5.3 显存碎片化导致分配失败即使总显存够用碎片化也可能导致分配失败。表现是torch.cuda.OutOfMemoryError但torch.cuda.memory_allocated()显示还有空闲。这时候需要检查显存池的碎片化程度。torch.cuda.memory_summary()会输出空闲块的大小分布。如果有很多小块空闲但找不到大块连续空间就是碎片化问题。解决办法是调整池化分配器的策略比如增大池子的大小类粒度或者定期做一次显存整理。显存整理的做法是把所有激活值暂时挪到主机内存清空显存池然后重新分配。这个操作开销很大不建议频繁做可以在训练的几个关键节点做一次。def defragment(): # 把所有激活值挪到CPU for key in list(manager.on_gpu): tensor manager.activations[key] manager.cpu_store[key] tensor.cpu() manager.activations[key] None manager.on_gpu.remove(key) # 清空显存缓存 torch.cuda.empty_cache() # 按需重新加载 for key in list(manager.cpu_store.keys()): manager.load(key)5.4 常见问题速查表问题现象可能原因排查方法解决思路训练结果偏差大精度转换、锁页内存失败检查数据类型和拷贝路径统一数据类型确认锁页内存可用速度下降明显重叠未生效、同步点过多用profiler查看时间线独立流、减少同步、检查锁页内存显存分配失败碎片化、池子太小查看memory_summary增大池子、显存整理、调整大小类交换频繁阈值设得太低观察交换次数提高阈值、增大显存预算主机内存不足交换空间不够查看主机内存占用减小交换粒度、增加主机内存5.5 几个容易被忽视的细节第一个细节是反向传播的 hook 顺序。PyTorch 的 backward hook 是按注册顺序的反向执行的也就是说最后注册的 hook 最先执行。如果交换逻辑依赖顺序需要特别注意注册顺序。第二个细节是多卡场景下的交换。如果模型分布在多张卡上每张卡都有自己的显存池和交换管理器。跨卡的激活值交换需要走卡间通信开销比单卡内的显存-主机交换大得多。论文里没有深入讨论多卡场景实操中建议先做好单卡再考虑多卡。第三个细节是训练和推理的差异。推理时不需要反向传播激活值的生命周期更短交换策略可以更激进。但推理对延迟敏感交换带来的额外延迟可能不可接受。所以 vDNN 主要针对训练场景推理场景需要单独优化。我在实际复现时还遇到过一个坑hook 里返回的张量如果被原地修改会影响后续的计算。比如某一层的输出被 hook 保存后又被后续层原地修改了那保存的就是修改后的值反向传播时用到的激活值和前向传播时不一致。解决办法是在 hook 里做一次拷贝或者确保后续层不做原地修改。6. 从 vDNN 延伸出的显存优化思路6.1 梯度检查点与交换的结合梯度检查点gradient checkpointing是另一种显存优化手段思路是不存中间激活值反向传播时重新计算。它和 vDNN 的交换策略可以结合使用对于计算量大的层用交换对于计算量小的层用重计算。这样可以在显存和计算之间找到更好的平衡点。论文里没有直接讨论这个组合但从原理上看是可行的。实操中需要根据层的计算量和激活值大小来决策。计算量大且激活值大的层优先交换计算量小但激活值大的层优先重计算计算量大且激活值小的层两者都不需要。6.2 面向现代硬件的适配vDNN 发表时的硬件环境和现在有很大不同。当时 PCIe 带宽是主要瓶颈现在 NVLink 和高速互联的带宽已经大幅提升交换的开销相对降低了。同时显存容量也大了很多单卡几十GB已经很常见。这些变化意味着 vDNN 的策略需要调整。比如在 NVLink 环境下显存和主机内存之间的带宽可能不是瓶颈瓶颈转移到了主机内存的带宽上。这时候需要优化主机内存的访问模式比如用更大的传输块、更少的传输次数。另外现代 GPU 支持显存和主机内存的统一寻址某些情况下可以省去显式的拷贝操作。6.3 对框架开发者的启示如果你在开发深度学习框架或者做系统优化vDNN 的几个设计原则值得参考。一是显存管理要分层底层做分配和释放中间层做策略决策上层做调度执行。二是交换决策要基于生命周期而不是简单的 LRU 或者 FIFO。三是传输和计算要重叠这是隐藏开销的关键。另外vDNN 的评估方法也值得借鉴。论文里不仅报告了显存节省的比例还报告了训练速度的变化、不同模型规模下的可扩展性、不同硬件配置下的表现。这种多维度的评估比单纯说“省了多少显存”更有说服力。我个人在实际操作中的体会是显存优化没有银弹任何方案都有代价。vDNN 的代价是额外的数据传输和调度开销换来的是更大的模型容量。是否值得取决于你的瓶颈在哪里。如果瓶颈是显存容量那交换是有效的如果瓶颈是计算速度那交换可能让情况更糟。先定位瓶颈再选择方案这个顺序不能反。最后分享一个小技巧在实现交换逻辑时先用一个很小的模型和很小的 batch size 跑通流程确认正确性和基本性能再逐步放大。不要一上来就上大模型否则出了问题很难定位是交换逻辑的问题还是模型本身的问题。另外多打日志记录每次交换的数据大小、传输时间、显存占用变化这些数据在调优时非常有用。