想象你是一家深夜餐厅的大厨。备菜台只有两平米，可你一顿饭要出 24 道菜。每道菜切好腌好的半成品——焯过水的青菜、裹好浆的肉片——在轮到它下锅之前都必须有个地方摆着。这个台面，就是 GPU 显存。台面一旦堆满，后面的菜就备不出来，整条出菜线都得停摆。 聪明的后厨会怎么做？把暂时用不到的半成品撤下台面：近处的冰箱（CPU 内存）放一批，地下室的大冷库（SSD）再放一批。等某道菜快轮到下锅时，提前让帮厨把半成品取回来回温。这样台面永远腾得出位置，火也永远不熄。这就是“激活值卸载”：把训练中暂时用不到的中间计算结果搬出显存，用到前几天再搬回来。本文带你走进这个后厨，看什么时候搬、搬到哪、怎么让搬运不耽误炒菜，以及这笔“搬运账”到底划不划算。

岗位关联

对 AI 从业者而言，掌握激活值卸载，就是在显存告急时多一条工程出路：把“放不下”变成“挪得动”，让大模型训练在有限硬件上持续推进。

目录
  1. 可视化演示
  2. 显存压力来源：操作台上的“四房客”
  3. 卸载技术原理：冰箱还是地下冷库
  4. 卸载时机策略：掐着秒表搬菜
  5. 传输计算重叠：边炒菜边搬料
  6. 吞吐量影响评估：老板的账本
  7. 工程实践方案：顶级后厨的流程管理
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

显存压力来源：操作台上的“四房客”

走进深夜的餐厅后厨，你会看到备菜台上同时躺着四样东西：正在腌渍的大块牛肉、洗好沥水的青菜、几桶调好的酱汁，还有一盘盘切得整整齐齐的“半成品”。台面只有两平米，四样齐上阵立刻水泄不通。深度学习训练时的 GPU 显存，就是这块永远不够用的备菜台。台上挤着的四类“房客”——模型参数、梯度、优化器状态和激活值——各占多少地方、谁能搬走谁不能搬，直接决定了训练能不能继续。

训练的一次迭代中，显存占用可以写成一张清清楚楚的账单。模型参数是“主菜原料”，每步更新一次，几乎常驻；梯度在反向传播时产生，算完就放；优化器状态（比如 Adam 的动量与方差）是参数的“升级副本”，往往比参数本身还占地方；最后是激活值——前向传播每一层算出的输出，反向传播求这一层梯度时还要用到它。账单一目了然：

四类房客里，谁最适合被请出显存？答案是激活值。原因有三：它生命周期短，只从前向产生活到反向消费，通常只有几毫秒到几秒；它的存在严格限制在“前向→反向”之间，可通过扫描计算图精确预测下一次使用时刻；它虽然账面上占得大，但并非每时每刻都需要全部驻留。相比之下，参数每步都要读写，搬走反而拉垮；梯度稍纵即逝，不值得搬；优化器状态虽也可卸载，但那是另一套方案（如 ZeRO-Offload）的活。

回到后厨：腌好的牛肉（参数）正等着下锅，不能放远；几桶酱汁（优化器状态）可以进冰箱，但每次都要拿出来用；唯独那盘焯好水、包上保鲜膜随时能回锅的青菜——也就是激活值——才是冰箱最欢迎的客人。认清谁适合搬，是理解激活值卸载的第一步。

Mtotal=Mparam+Mgrad+Mopt+Mact+Mscratch\displaystyle M_{\text{total}} = M_{\text{param}} + M_{\text{grad}} + M_{\text{opt}} + M_{\text{act}} + M_{\text{scratch}}
显存总占用等于参数、梯度、优化器状态、激活值和临时缓冲区五类开销之和。
  1. 总占用标记$M_{\text{total}}$ 表示训练时显存的总需求，单位是 MB 或 GB，是评估“装不装得下”的第一把尺子。
    Mtotal\displaystyle M_{\text{total}}
  2. 参数项$M_{\text{param}}$ 是模型权重本身的显存，由参数量与精度（如 FP16/BF16）决定，每步更新后原地覆盖，不搬家。
    Mparam\displaystyle M_{\text{param}}
  3. 梯度项$M_{\text{grad}}$ 是反向传播算出的梯度，尺寸与参数相同，生命周期只有一步。
    Mgrad\displaystyle M_{\text{grad}}
  4. 优化器状态项$M_{\text{opt}}$ 是 Adam 这类优化器维护的动量、方差副本，常达到参数的 2-3 倍。
    Mopt\displaystyle M_{\text{opt}}
  5. 激活项$M_{\text{act}}$ 是前向每层输出暂存区，与 batch size、序列长度、层数三者乘积成正比，是卸载的头号目标。
    Mact\displaystyle M_{\text{act}}
  6. 临时缓冲项$M_{\text{scratch}}$ 是矩阵乘法、归一化等算子执行时的临时工作区，用完即还。
    Mscratch\displaystyle M_{\text{scratch}}

卸载技术原理：冰箱还是地下冷库

后厨里有两处“外挂仓库”：厨房角落的冰箱，开门就到；地下室的大冷库，下去一趟要一分钟。冰箱容量小但取用快，冷库容量大但来回慢。深度学习里，这两个仓库就是 CPU 内存（主机 DRAM）与 NVMe SSD：CPU 内存的传输带宽可达 20-50GB/s，SSD 往往只有 2-7GB/s，相差 5-10 倍，但 SSD 容量轻松做到几个 TB。

把激活值从 GPU 搬到 CPU 或 SSD，走的是 PCIe 或 NVLink 这条“货梯”。搬运耗时只由两件事决定：搬多少数据和电梯多快。数据量越大、通道越慢，搬运时间越长。这个关系简单得像个物理定律：

除了介质选择，还要决定“按什么粒度搬”。张量粒度卸载是细心的帮厨，每次只端走一盘菜，灵活精准，适合只卸少数层；层粒度卸载是整托盘点货，把整层激活打包搬走，省调度开销，适合大量成片卸载。实际框架常采用张量粒度，因为它能最大化“谁冷谁走”的精准度。同样一片食材，放冰箱还是冷库，决定了回温速度；对激活而言，就近的 CPU 内存是首选，只有显存与内存双双吃紧时，才动用 SSD 这座“地下冷库”。

Ttransfer=DdataBbandwidth\displaystyle T_{\text{transfer}} = \frac{D_{\text{data}}}{B_{\text{bandwidth}}}
传输时间等于数据量除以带宽：要搬 2GB 激活，走 32GB/s 的 CPU 通道约需 62 毫秒，走 6GB/s 的 SSD 通道则要 333 毫秒。
  1. 传输时间标记$T_{\text{transfer}}$ 表示从 GPU 显存出发、到达目标介质的时间，单位是秒，是最核心的卸载成本。
    Ttransfer\displaystyle T_{\text{transfer}}
  2. 数据量$D_{\text{data}}$ 是被卸载激活张量的字节数，由层输出尺寸与 batch 决定，越大搬得越久。
    Ddata\displaystyle D_{\text{data}}
  3. 带宽$B_{\text{bandwidth}}$ 是“货梯”的吞吐能力，CPU 内存走 PCIe 带宽高，SSD 走 NVMe 带宽低。
    Bbandwidth\displaystyle B_{\text{bandwidth}}
  4. 除法关系$D_{\text{data}} / B_{\text{bandwidth}}$ 把“体积”除以“速度”得到“时间”，和开车 120 公里、时速 60 公里要 2 小时一个道理。
    DdataBbandwidth\displaystyle \frac{D_{\text{data}}}{B_{\text{bandwidth}}}

卸载时机策略：掐着秒表搬菜

聪明的后厨绝不会把菜全塞进冰箱就完事。半成品要“前手备、后手用”：菜快下锅了才去冰箱拿，会害得大厨干等；菜还没谢幕就急着搬走，又可能刚搬走马上又要取回，白白跑两趟。卸载时机，本质上是一场精确到毫秒的调度。

工程上的做法分两步。前向传播：每一层算出激活值后，若显存即将见顶，立刻把暂时用不到的层输出搬走——这是“前向计算卸载”。反向传播：在某一层需要激活值之前，提前把它从 CPU/SSD 取回显存——这是“反向计算预取”。预取必须“提前”，是因为搬运本身要花时间；如果等反向真的轮到这一层才开始取，GPU 就不得不空转等待。

要不要卸载一个张量，可以套用一个简单决策：看它距离下次被使用的时间，是否足够支付一次搬运的往返成本。如果答案为是，就值得搬；否则留在显存里更划算：

除了时机，还要排优先级。大尺寸、访问间隔长的“冷激活”优先卸载；下一层反向马上就要用到的“热激活”坚决不搬。这套生命周期管理相当于给每盘半成品贴标签：注明出生时刻、保质期和下次上桌时间。后厨的灵魂就是时机：卸早了占冰箱，取早了占台面，取晚了锅空等——每一步都要掐着秒表。

若 tnext−tnow>DdataBbandwidth+ϵ, 则该激活值得卸载\displaystyle \text{若 } t_{\text{next}} - t_{\text{now}} > \frac{D_{\text{data}}}{B_{\text{bandwidth}}} + \epsilon, \text{ 则该激活值得卸载}
下次使用时刻减去当前时刻，若大于单程传输时间加安全余量，就卸载；这个条件避免“刚搬走又取回”的乒乓效应。
  1. 当前时刻$t_{\text{now}}$ 是前向刚算完这层激活的时刻，也是决定“动不动手”的起点。
    tnow\displaystyle t_{\text{now}}
  2. 下次使用时刻$t_{\text{next}}$ 是反向传播消费该激活的时刻，可通过计算图静态分析精确预测。
    tnext\displaystyle t_{\text{next}}
  3. 剩余窗口$t_{\text{next}} - t_{\text{now}}$ 是激活在显存里“闲置”的时间，窗口越长，越值得把它请出去。
    tnext−tnow\displaystyle t_{\text{next}} - t_{\text{now}}
  4. 搬运耗时$D_{\text{data}} / B_{\text{bandwidth}}$ 是单程传输时间，卸载出去和取回都要花这么久，所以余量不能抠太死。
    DdataBbandwidth\displaystyle \frac{D_{\text{data}}}{B_{\text{bandwidth}}}
  5. 安全余量$\epsilon$ 是工程上预留的调度抖动余量，避免传输延迟波动导致预取迟到。
    ϵ\displaystyle \epsilon

传输计算重叠：边炒菜边搬料

台面紧张的问题解决了，新的麻烦来了：帮厨去地下室取料时，大厨难道就干等着？当然不。真正的后厨里，帮厨的脚步声和大厨的颠勺声是同时响的——搬运和炒菜互不打扰，这就是“异步”。

技术实现上，卸载不是由 GPU 计算核心亲力亲为，而是交给独立的数据搬运引擎（DMA），跑在单独的 CUDA Stream 上。计算 Stream 专心执行前向/反向的内核计算，搬运 Stream 负责把冷激活送出去、把热激活取回来。两条流水线各走各的，互不阻塞。调度员再排一个让它们交错的流水表：对第 $i$ 层做反向计算的同时，预取第 $i-1$ 层的激活，顺手卸载第 $i+1$ 层用完的缓冲。理想状态下，所有搬运都“藏”在计算间隙里，训练仿佛什么都没发生过：

这个公式揭示了一个工程真相：只要每段搬运时间不超过相邻计算时间，卸载就可以“隐身”；一旦某个传输比相邻计算还长，多出来的差值就会裸露成 GPU 的空闲等待。因此，带宽分配策略会尽量避免在计算密集的节点安排大规模卸载——就像高峰期不让帮厨去搬整箱食材，只让他递手边的小碟子。大厨的锅铲不停，帮厨的脚步也始终不歇，一台高效训练机器的后厨，奏的就是这么一支双人舞。

Tpipeline≈max⁡(Tcompute,Ttransfer)\displaystyle T_{\text{pipeline}} \approx \max\left(T_{\text{compute}}, T_{\text{transfer}}\right)
当卸载预取与计算完全并行时，整条流水线的总时间只取决于计算和传输中较慢的那个，而不是两者相加。
  1. 流水线总时间$T_{\text{pipeline}}$ 表示完成“前向+卸载+预取+反向”整段流程的等效墙钟时间，是优化目标本身。
    Tpipeline\displaystyle T_{\text{pipeline}}
  2. 计算时间$T_{\text{compute}}$ 是 GPU 执行内核的净运算时间，由模型结构与算力决定，卸载不会改变它。
    Tcompute\displaystyle T_{\text{compute}}
  3. 传输时间$T_{\text{transfer}}$ 是搬运激活的总耗时，见第二节的带宽公式。
    Ttransfer\displaystyle T_{\text{transfer}}
  4. 取最大值$\max\left(\cdot\right)$ 表示两件事若完全并行，总时长由最慢的一方决定——像大厨与帮厨同时开工，整个流程只看比较慢的那个人。
    max⁡(Tcompute,Ttransfer)\displaystyle \max\left(T_{\text{compute}}, T_{\text{transfer}}\right)

吞吐量影响评估：老板的账本

后厨老板最关心的是翻台率：今晚能出多少桌菜。对训练而言，这个“翻台率”叫训练吞吐量——每秒喂给模型多少个样本。搬运半成品虽然解决了台面问题，但帮厨多跑腿、电梯多运转，会不会让整个晚上出菜变慢？这必须用账本说话。

评估方式是对比实验：同一模型、同一数据集，分别开启与关闭激活值卸载，实测每轮 epoch 的墙钟时间与吞吐量。两者的差值，就是卸载的净开销。这个开销来自传输时间，但传输只要与计算重叠，就不算真正的损失。于是账面上有两个关键数字：搬运总耗时，以及其中被计算隐藏掉的部分：

账本上还有一行对比项：重计算（activation checkpointing）。重算方案干脆把一部分激活扔掉，反向需要时重新跑一遍前向来“现做”，代价是消耗算力；卸载方案保留半成品，代价是消耗带宽。前者省带宽费算力，后者省算力费带宽。聪明的后厨不会只用一种手段，而是混着来：小的便宜的菜现做，大的贵的半成品冷藏——这正是下一节工程方案的基本盘。老板的账本上，搬菜的钱和重新做菜的钱都得记，哪种便宜用哪种。

训练吞吐=NsamplesTcompute+Tvisible,Tvisible=max⁡(0,  Ttransfer−Thidden)\displaystyle \text{训练吞吐} = \frac{N_{\text{samples}}}{T_{\text{compute}} + T_{\text{visible}}}, \qquad T_{\text{visible}} = \max\left(0,\; T_{\text{transfer}} - T_{\text{hidden}}\right)
吞吐量等于处理的样本数除以“计算时间加可见等待”；可见等待是传输时间中被计算隐藏后剩下的纯损失。
  1. 吞吐量定义$\text{训练吞吐}$ 是每秒处理的样本数，是衡量卸载划不划算的最终账本，单位 samples/s。
    训练吞吐\displaystyle \text{训练吞吐}
  2. 分子$N_{\text{samples}}$ 是一轮要处理的样本总数，由数据集决定，卸载不改变它。
    Nsamples\displaystyle N_{\text{samples}}
  3. 分母结构$T_{\text{compute}} + T_{\text{visible}}$ 表示总墙钟时间由净计算时间与“看得见的等待”组成。
    Tcompute+Tvisible\displaystyle T_{\text{compute}} + T_{\text{visible}}
  4. 净等待$T_{\text{visible}} = \max(0, T_{\text{transfer}} - T_{\text{hidden}})$，搬运总时长减去被隐藏的部分，剩多少就是白等多少。
    Tvisible=max⁡(0,  Ttransfer−Thidden)\displaystyle T_{\text{visible}} = \max\left(0,\; T_{\text{transfer}} - T_{\text{hidden}}\right)

工程实践方案：顶级后厨的流程管理

街头小馆的老板往往等台面满了才喊“放进冰箱”，而顶级餐厅的行政总厨在开菜单时就算好了：台面多大、冰箱几层、冷库几间，每道菜什么时候备、什么时候上，全在流程里。成熟框架的激活值卸载，走的正是后者这条路。

工程落地分四步。第一步是显存容量规划：训练还没开始，先套用第一节的总账公式，估算参数、梯度、优化器状态与激活值的体量，确定 batch size 与是否开启卸载。第二步是卸载决策引擎：运行时逐层扫描计算图，对每个激活张量套用第三节的时机公式，动态决定卸不卸、卸到哪。第三步是热点数据识别：统计哪些激活被频繁访问、哪些长期无人问津，把“热数据”留在显存、“冷数据”请出家门。最后是端到端调优：调节 batch、卸载阈值、预取提前量等旋钮，用第五节吞吐量公式做闭环验证。引擎的核心，是把所有账目汇成一道选择题：

从“台面满了再搬”到“一开始就排好谁进冰箱”，是应急方案与成熟工程方案的分水岭。容量规划让心里有数，决策引擎让每个张量各得其所，热点识别让搬运动作有的放矢，端到端调优让整套系统在真实负载下持续逼近最佳吞吐。这便是激活值卸载的全景：它不是一招救火的野路子，而是一套可以设计、可以度量、可以优化的后厨管理制度。

每层代价=min⁡(Toffload+Twait⏟搬运方案,  Trecompute⏟重算方案)\displaystyle \text{每层代价} = \min\left(\underbrace{T_{\text{offload}} + T_{\text{wait}}}_{\text{搬运方案}}, \; \underbrace{T_{\text{recompute}}}_{\text{重算方案}}\right)
决策引擎对每个激活张量分别估算“搬运代价”与“重算代价”，谁小选谁，实现全局最优的显存-带宽-算力平衡。
  1. 代价函数$\text{每层代价}$ 是决策引擎为每一层激活算出的统一度量，单位是时间，越小越好。
    每层代价\displaystyle \text{每层代价}
  2. 搬运代价$T_{\text{offload}} + T_{\text{wait}}$ 等于卸载预取的传输时间加上可能裸露的等待时间，本质是“花带宽”。
    Toffload+Twait\displaystyle T_{\text{offload}} + T_{\text{wait}}
  3. 重算代价$T_{\text{recompute}}$ 是丢弃激活后，反向阶段重新执行前向所需的算力时间，本质是“花算力”。
    Trecompute\displaystyle T_{\text{recompute}}
  4. 取最小值$\min(\cdot)$ 表示对每个张量单独比价：大尺寸、低频访问者往往搬运更便宜，小尺寸、高频访问者重算更划算。
    min⁡(⋅)\displaystyle \min\left(\cdot\right)

AI 应用场景

场景 1：大模型微调的显存救急

阶段：训练/微调的显存规划

解决的问题：在 24GB 消费级显卡上微调 7B 参数大模型，前向传播保存的激活值极易撑爆显存导致 OOM 崩溃。传统做法只能把 batch size 调到 1 或强行切分模型，训练效率极低。激活值卸载把暂时用不到的激活搬到 CPU 内存，让“放不下”变成“挪得动”。

具体案例：某工程师用 DeepSpeed 的 offload 配置微调 7B 模型，将每步约 12GB 激活中的 8GB 异步卸载到主机内存，batch size 从 8 提升到 32，显存峰值从 31GB 降到 21GB，训练吞吐反而因 batch 增大而提升。

场景 2：训练框架的自动卸载决策

阶段：AI 编译器与分布式训练框架的显存管理

解决的问题：人工决定每个张量何时卸载既繁琐又易错。现代训练框架内置卸载调度器，像“后厨总管”一样每步扫描计算图，自动识别冷激活、安排异步搬运、在反向前预取，让工程师无感获得显存收益。

具体案例：某训练框架在 8×80GB A100 集群上训练 175B 参数模型时，激活卸载将单卡峰值显存从 78GB 压到 60GB，使原本无法容纳的更大 batch 成为可能，整体吞吐提升约 18%。

场景 3：云上训练成本优化

阶段：MLOps 资源选型与成本控制

解决的问题：80GB 显存的 A100 按小时计费昂贵，而许多训练任务的显存瓶颈恰恰是激活值峰值。通过激活卸载将显存需求压到低规格实例的容量内，可以显著降低单次训练成本。

具体案例：某算法团队将 13B 模型微调从 A100-80GB 迁移到 A10G-24GB 实例，配合激活卸载与混合精度，日训练成本下降约 60%，代价仅是吞吐降低约 12%，在预算敏感场景下非常划算。

Python 演示

python47 行
def transfer_time(size_gb, bandwidth_gbps):    """传输时间 = 数据量 / 带宽（单位：秒）"""    return size_gb / bandwidth_gbps  class OffloadPlanner:    def __init__(self, gpu_mem_gb, bandwidth_gbps):        self.gpu_mem_gb = gpu_mem_gb        self.bandwidth = bandwidth_gbps     def decide(self, used_gb, act_gb):        """显存够就不卸，不够则卸载该层激活"""        if used_gb + act_gb <= self.gpu_mem_gb:            return False, 0.0        return True, transfer_time(act_gb, self.bandwidth)     def run_epoch(self, num_layers, act_gb, compute_per_layer_s):        used_gb = 0.0        round_trip = 0.0        offload_count = 0        for _ in range(num_layers):            need, one_way = self.decide(used_gb, act_gb)            if need:                round_trip += 2.0 * one_way                offload_count += 1                used_gb = 0.0            else:                used_gb += act_gb        total_compute = compute_per_layer_s * num_layers        hidden = min(round_trip, total_compute * 0.5)        visible = max(0.0, round_trip - hidden)        return offload_count, visible, total_compute + visible  def main():    for target, bw in (("CPU 内存", 32.0), ("SSD", 6.0)):        planner = OffloadPlanner(gpu_mem_gb=16.0, bandwidth_gbps=bw)        count, visible, epoch_time = planner.run_epoch(            num_layers=24, act_gb=2.0, compute_per_layer_s=0.1        )        slow = visible / epoch_time * 100        print("%s 卸载 %d 层，可见等待 %.3fs，拖慢 %.1f%%" %              (target, count, visible, slow))  if __name__ == "__main__":    main()
目的：模拟 24 层模型训练中，激活值卸载到 CPU 内存与 SSD 两种介质时对训练吞吐的影响，直观验证“带宽决定拖慢程度”这一核心结论。
  1. return size_gb / bandwidth_gbps这就是传输时间公式 $T = D / B$：数据量除以带宽，算出搬一层激活要多久。
  2. if used_gb + act_gb <= self.gpu_mem_gb:显存还够就先记账驻留，零成本换来最少搬运，避免无谓的乒乓传输。
  3. round_trip += 2.0 * one_way卸载出去加反向前取回，一次管理层要跑两趟，成本必须按往返计算。
  4. hidden = min(round_trip, total_compute * 0.5)搬运可以搭在相邻层计算上，最多隐藏掉一半总计算时间。
  5. visible = max(0.0, round_trip - hidden)没被计算藏住的传输时间就是纯等待，会实打实拖慢吞吐。
  6. for target, bw in (("CPU 内存", 32.0), ("SSD", 6.0)):同一套模拟换两个带宽参数，直观对比“冰箱”与“冷库”的差异。

常见误区

误区“我把卸载开关打开，显存不够的问题解决了，训练应该还是原来的速度吧？毕竟只是搬点数据而已。”

正解卸载不是免费的。数据要经过 PCIe/NVLink 搬运，占用带宽并带来时间开销；只有当传输被其他计算充分重叠隐藏时，吞吐才可能不降。带宽不足或没有可并行的计算时，训练会明显变慢。工程上通常把卸载与梯度累积、重计算配合使用，而不是把它当成“一键免罪”。

为何常见：看到“卸载”两个字，容易被类比成“清理缓存”，以为是零成本的顺手操作；实际上它本质是用带宽换显存，账要细算。

误区“既然 CPU 内存比 SSD 快好几倍，所有激活都往 CPU 丢不就好了？谁还稀罕 SSD？”

正解CPU 内存虽快，但容量有限，而且后厨的“货梯”（PCIe）是共享的。多卡并行训练时，多张卡同时卸载会互相争抢带宽，整体吞吐雪崩式下跌。SSD 容量巨大、适合极冷数据，CPU 内存储存温热数据，GPU 显存留给热数据——正确做法是按“冷热程度”分层放置。

为何常见：只比较了带宽单一指标，忽略了容量上限、共享争抢与访问延迟三个维度的综合影响。

误区“反正后面才用，前向一结束就马上搬走，肯定能最快释放显存，这还需要犹豫吗？”

正解立刻卸载确实最快腾出台面，但反向传播很快就要消费这批激活。若卸载与预取间隔过短，会出现“刚搬走又搬回来”的乒乓效应，传输量翻倍，搬运账反而更贵。成熟策略会预测“下次使用时刻”，只在 $t_{\text{next}} - t_{\text{now}}$ 大于传输成本时才卸载。

为何常见：把显存释放当成了唯一优化目标，忽略了传输流量本身也是成本——台面省了，电梯却累坏了。

误区“重计算也是省显存，卸载也是省显存，两者手段不同、效果差不多，随便选一个用就行。”

正解两者省显存的路径完全不同。卸载是把激活保存到更远的介质，反向时取回，代价是带宽；重计算是丢弃激活，反向时重新执行前向，代价是算力。工程上常按张量粒度混合使用：大张量卸载、小张量重算，让决策引擎逐个比价。

为何常见：两者的目标相同（解决显存不足），初学者容易盯着结果而混淆手段，只有在系统性能优化时才意识到选错方案的代价。

面试题

Q1. 训练中“激活值”主要指什么？

单选题 · easy

  • A.前向传播每层的输出缓存← 正确答案
  • B.模型训练使用的全部参数
  • C.反向传播后得到的梯度
  • D.优化器保存的动量状态

答案：A。激活值是前向传播每一层算出的结果，反向传播求梯度时还需要它，因此被缓存下来。B 是参数，C 是梯度，D 是优化器状态——这三者与激活值并称显存的“四房客”，但都不是激活值本身。

Q2. 显存不够时，最先考虑卸载的对象是？

单选题 · easy

  • A.前向传播保存的激活值← 正确答案
  • B.每步都更新的模型参数
  • C.训练框架的代码配置
  • D.数据加载器缓存队列

答案：A。激活值生命周期短、占用大、可通过计算图预测下次使用时间，是最适合暂离的“半成品”。参数每步都要读写，搬走反而拖慢训练；代码配置与数据队列根本不属于显存账本。

Q3. 卸载到 CPU 内存相比 SSD 的优势是？

单选题 · easy

  • A.传输带宽更高延迟更低← 正确答案
  • B.完全不占主机内存
  • C.支持断电后数据保存
  • D.无需 PCIe 总线参与

答案：A。CPU 内存就在“厨房隔壁”，带宽可达 20-50GB/s，延迟远低于 SSD 的“地下冷库”。卸载本质是拿带宽换显存，所以首选高带宽的 CPU 内存；SSD 只在容量实在不够时兜底。

Q4. 某层激活 2GB，CPU 带宽 32GB/s，单程传输约需多久？

单选题 · mid

  • A.约 62 毫秒← 正确答案
  • B.约 620 毫秒
  • C.约 6 毫秒
  • D.约 16 毫秒

答案：A。套用传输时间公式 T = D / B，2GB 除以 32GB/s 等于 0.0625 秒，即约 62 毫秒。若卸载加预取算往返，则要再乘 2，约 125 毫秒。

Q5. 前向算完某层激活后，最佳卸载时机是？

单选题 · mid

  • A.计算完立即搬走，反向前预取← 正确答案
  • B.等反向刚好需要时才搬运
  • C.训完整轮再统一处理
  • D.显存彻底耗尽才开始搬

答案：A。前向算完、确认暂时不用，就应立刻卸载以腾出显存；反向需要前再提前预取回显存。等反向恰好需要时才搬，GPU 只能空转等待；等显存耗尽再搬，可能已经来不及避免 OOM。

Q6. 传输 20ms、相邻层计算 30ms 且完全重叠时，额外等待是？

单选题 · mid

  • A.约 0 毫秒← 正确答案
  • B.约 10 毫秒
  • C.约 20 毫秒
  • D.约 50 毫秒

答案：A。当搬运完全落在计算期间，流水线总时间由较慢的一方（计算 30ms）决定，传输被完全隐藏，额外等待约 0ms。若传输大于计算，裸露出来的才是差值，这正是 T_pipeline ≈ max(T_compute, T_transfer) 的含义。

Q7. 评估卸载对吞吐的影响，应关注的核心指标是？

单选题 · mid

  • A.可见等待占总训练耗时比← 正确答案
  • B.卸载数据总量的绝对值
  • C.CPU 内存的空闲容量
  • D.SSD 的健康剩余寿命

答案：A。训练吞吐 = 样本数 /（计算时间 + 可见等待）。只有“没被计算隐藏掉的传输时间”才是纯损失，它占总耗时的比例直接决定拖慢程度。卸载总量再大，只要被藏住就不影响吞吐。

Q8. 关于卸载与重计算的取舍，正确的是？

单选题 · hard

  • A.卸载耗带宽，重计算耗算力← 正确答案
  • B.卸载耗算力，重计算耗带宽
  • C.两者都只增加显存压力
  • D.两者效果在数学上等价

答案：A。卸载把激活搬到远处、反向取回，代价是 PCIe/NVLink 带宽；重计算丢弃激活、反向现做前向，代价是 GPU 算力。二者都能省显存，但消耗的资源完全不同，因此工程上按张量粒度混合使用，谁便宜选谁。

Q9. 显存中的主要占用者包括哪些？

多选题 · mid

  • A.模型参数与梯度数值← 正确答案
  • B.优化器的动量方差副本← 正确答案
  • C.前向传播的激活缓存← 正确答案
  • D.训练日志与监控指标

答案：ABC。按照显存总账公式，主要占用者是参数、梯度、优化器状态（Adam 动量/方差）与激活值，外加算子临时缓冲。训练日志与监控指标存放在主机侧，不属于 GPU 显存的“四房客”。

Q10. 某层激活 8GB，CPU 带宽 32GB/s，该层相邻计算约 0.3s。下列说法正确的有？

多选题 · extreme

  • A.单程传输耗时约 250 毫秒← 正确答案
  • B.卸载与预取往返约 500 毫秒← 正确答案
  • C.传输与计算重叠后完全无感
  • D.整层训练必定多等 500 毫秒

答案：AB。单程 T = 8GB / 32GB/s = 0.25s，A 正确；往返为两趟共 0.5s，B 正确。但相邻计算只有 0.3s，无法完全隐藏 0.5s 的搬运，差额约 0.2s 会裸露成等待，因此 C 错误；D 把全部 500ms 都算成等待，忽略了可被重叠隐藏的 300ms，也错误。