Accelerate prepare为什么要同时接收模型与优化器

第一次把 Hugging Face Accelerate 接进训练脚本时，很多人会先写成 model = accelerator.prepare(model)，然后继续使用原来的优化器。真正容易出问题的地方不在参数数量，而在模型、优化器参数组和优化器状态是否仍然指向同一套训练对象。

简短结论：Accelerator.prepare 通常把模型和优化器一起接收，是为了让模型包装、设备放置、梯度更新和优化器状态保持同一套训练语义。它不是“优化器必须永远和模型成对传入”的语法限制：只做推理时可以只准备模型，但训练时二者应按稳定顺序一起准备。

官方地址：https://huggingface.co/docs/accelerate/

先看 prepare 到底准备了哪些对象

官方参考接口把 prepare 设计成可接收多个对象，并按照传入顺序返回准备后的对象。常见组合是 DataLoader、模型、优化器和学习率调度器：

from accelerate import Accelerator
import torch

accelerator = Accelerator()
model = MyModel()
optimizer = torch.optim.AdamW(model.parameters(), lr=2e-4)

# 返回顺序与传入顺序一致，后续变量要一一对应。
model, optimizer = accelerator.prepare(model, optimizer)

这里的“准备”不只是调用一次 to(device)。在分布式训练或混合精度场景中，模型可能被包装，优化器也需要处于与这些参数和设备相容的状态。多个返回值仍然保持原顺序，所以不要为了省变量而把模型和优化器的接收顺序写反。

为什么模型和优化器要一起进入同一个边界

优化器并不是一个独立的学习率按钮。创建优化器时，model.parameters() 会被保存到参数组里；训练过程中，优化器还会维护动量、二阶矩等状态。模型一旦经过分布式包装或设备调整，训练时参与反向传播的参数对象和原始参数对象可能已经不再是同一层外壳。

如果只准备模型，优化器仍可能保存着未准备前的参数引用；如果只准备优化器，模型的梯度计算又没有进入对应的分布式训练包装。表面上代码能继续运行，并不代表更新关系完整。把二者一起传入，可以让 Accelerate 统一处理这条关系：

• 模型负责前向计算、产生损失和承接梯度。
• 优化器负责读取参数组和状态，执行参数更新。
• 设备与分布式包装是二者共同依赖的运行边界。

所以标题里的“同时接收”更接近一个工程上的配方：让参数、梯度和优化器状态在同一准备语义下协作，而不是要求每次调用都必须恰好传两个对象。

训练时的最小可用写法

把 DataLoader、模型、优化器和调度器一次性交给 prepare，最容易看清对象的对应关系。Accelerate 负责准备对象，训练循环仍由你决定：

from accelerate import Accelerator
import torch

accelerator = Accelerator(gradient_accumulation_steps=2)
model = MyModel()
optimizer = torch.optim.AdamW(model.parameters(), lr=2e-4)
train_loader = build_loader()
scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=1000)

# 四个返回值严格按四个输入的顺序接收。
model, optimizer, train_loader, scheduler = accelerator.prepare(
    model, optimizer, train_loader, scheduler
)

for batch in train_loader:
    with accelerator.accumulate(model):
        outputs = model(batch["input_ids"])
        loss = loss_fn(outputs, batch["labels"])

        # 让 Accelerator 根据配置处理反向传播。
        accelerator.backward(loss)
        optimizer.step()
        scheduler.step()
        optimizer.zero_grad()

这段代码的重点不是某个具体模型，而是三件事：优化器先根据模型参数创建，再与模型一起准备；返回值顺序不变；反向传播使用 accelerator.backward，让梯度累积或混合精度配置能够参与训练。

哪些场景不需要把模型和优化器绑在一起

边界也要说清楚。只做推理且不使用混合精度时，官方文档说明不必准备模型；如果需要让模型进入 Accelerate 管理的设备或混合精度上下文，可以只准备模型：

from accelerate import Accelerator

accelerator = Accelerator(mixed_precision="bf16")
model = MyModel()

# 推理没有 optimizer，也就不存在参数更新状态的配对问题。
model = accelerator.prepare(model)
model.eval()

同理，调度器不是所有训练都需要。如果使用调度器，就把它和优化器一起传入，并按返回顺序接收；如果采用自定义更新规则，也要确保更新的参数确实来自已准备的模型。

最容易踩的三个坑

第一，接收顺序写反。 prepare 会按输入顺序返回，不会根据变量名自动识别对象。传入顺序和赋值顺序必须完全一致。

第二，准备后又用旧对象。 准备完成后，应使用返回的模型、优化器和 DataLoader。不要保留旧变量名并在循环里混用，否则排查时很难判断到底哪套参数在更新。

第三，把“能运行”当作“关系正确”。 训练代码能进入循环，只说明 Python 层面没有立即报错；模型包装、参数组和优化器状态是否对应，取决于对象是否按同一准备边界管理。遇到梯度不更新、设备不一致或状态恢复异常，先回到创建、prepare、训练三处的对象流向检查。

一句话记住这条配方

训练场景下，先用原始模型创建优化器，再把模型、优化器以及实际使用的 DataLoader 和调度器按固定顺序交给 Accelerator.prepare；推理场景则按需准备模型。这样理解后，问题就不再是“为什么 API 要两个参数”，而是“哪些对象共同构成一次可靠的参数更新”。

相关问题：

• 为什么 Accelerate 训练循环要用 accelerator.backward(loss)？
• 使用学习率调度器时，为什么也应该接收 prepare 返回的 scheduler？
• 只做推理时，什么时候需要调用 accelerator.prepare(model)？