pipeline 指定 device 后报错

模型通过 device_map="auto" 加载后，给 pipeline() 传 device=0，可能收到：

cannot be moved to a specific device

在 Transformers 4.45.2 中，只要模型的 hf_device_map 不为 None，又传入非 None 的 device，构造器就拒绝继续。它发生在整体迁移之前，不能据此认定 CUDA 设备不存在。因此不要同时传入这两个参数。

保留 Accelerate 分派时，去掉 pipeline 的 device

先检查已经加载好的模型：

print(getattr(model, "hf_device_map", None))

这个诊断片段假定 model 是项目已加载的对象。映射可能包含多块 GPU、CPU 或磁盘卸载位置。只看 model.device 的第一个位置，不能代表整份模型的分配。

以下例子使用同一份可信本地文本生成 checkpoint：

from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline

checkpoint = "/srv/models/verified-text-checkpoint"
tokenizer = AutoTokenizer.from_pretrained(checkpoint)
model = AutoModelForCausalLM.from_pretrained(
    checkpoint,
    device_map="auto",
)
generator = pipeline(
    "text-generation",
    model=model,
    tokenizer=tokenizer,
)
result = generator("Explain TCP briefly.", max_new_tokens=16)
print(len(result))

示例需要相容的 PyTorch/Accelerate 依赖和足够内存。它会加载真实模型并推理；没有默认允许任意 checkpoint 的远程代码。保留原来的 dtype、量化和 offload 配置，例子只展示需要移除的冲突参数。

注意 device=-1 也是一个明确传入的值，不能把它当成“没有传 device”。公共封装若默认填了 device=0，调用处删除参数后仍会冲突，应检查最终交给 pipeline 的 kwargs。

只有单设备任务，才另走单设备加载路线

若业务确实不需要分派或卸载，而且单卡能装下模型，可以重新按普通单设备方案加载，再由 pipeline 指定设备。不要在已经分片或量化的对象上强行 model.to("cuda")，也不要删除 hf_device_map 属性伪装成未分派模型。

这条路线需要重新评估显存、输入长度和批量大小。消除构造器冲突，不会自动解决 OOM，也不会替应用调整模型覆盖范围。

验收先确认 pipeline 能构造、最终参数只保留一种设备策略，再执行短输入。随后检查代表性长输入与实际批量，核对映射和内存占用符合部署预算。若后续错误变成某个张量设备不匹配，继续检查自定义输入处理，不把它又当成 pipeline 参数冲突。