Stable Diffusion WebUI AMDGPU 项目中GFPGAN与CodeFormer的兼容性问题解析

问题背景

在Stable Diffusion WebUI AMDGPU项目中，用户在使用GFPGAN和CodeFormer进行人脸修复时遇到了兼容性问题。这些问题主要表现为模型加载失败或运行时出现张量类型不匹配的错误。本文将深入分析这些问题的根源，并提供可行的解决方案。

问题现象

用户在使用GFPGAN和CodeFormer时主要遇到以下两类错误：

1. 模型加载失败：系统提示"Unable to load face-restoration model"或"No GFPGAN model found"错误
2. 运行时张量类型不匹配：出现"Input type (torch.FloatTensor) and weight type (torch.cuda.FloatTensor) should be the same"错误

根本原因分析

经过深入分析，这些问题主要源于以下几个方面：

1. DirectML的存储访问限制：DirectML后端不支持某些存储访问操作，导致GFPGAN和CodeFormer无法正常工作
2. ZLUDA的兼容性问题：虽然ZLUDA性能更好，但它缺少hiprtc支持，影响CodeFormer的正常运行
3. 模型加载路径问题：部分情况下模型文件未正确放置或加载路径配置不当
4. 张量设备不匹配：模型权重与输入数据位于不同设备（CPU与GPU）导致运算失败

解决方案

针对上述问题，我们提供以下几种解决方案：

方案一：使用ZLUDA替代DirectML

1. 安装ZLUDA运行时环境
2. 确保安装了兼容的ROCm库（特别是对于非官方支持的AMD显卡）
3. 注意ZLUDA下CodeFormer将自动回退到CPU运行

方案二：回退到WebUI 1.7版本

对于使用GCN架构显卡（如Radeon VII）的用户：

1. 将WebUI回退到1.7版本
2. 使用DirectML后端
3. 此方案下GFPGAN和CodeFormer均可正常工作

方案三：强制使用CPU运行特定模块

在启动参数中添加：

--use-cpu gfpgan codeformers

此方案虽然牺牲了一些性能，但能确保功能正常，且性能差异在实际使用中并不明显。

方案四：手动模型部署

针对"No GFPGAN model found"错误：

1. 手动下载GFPGAN模型文件
2. 将其放置在正确的模型目录中（通常是models/GFPGAN）
3. 确保文件权限和路径配置正确

技术细节深入

DirectML的限制

DirectML作为微软提供的跨厂商GPU加速接口，虽然提供了广泛的兼容性，但在存储访问支持方面存在限制。这直接影响了GFPGAN和CodeFormer这类需要复杂内存操作的人脸修复模型的运行。

ZLUDA的优势与局限

ZLUDA通过将CUDA调用转换为ROCm/HIP调用，在AMD GPU上实现了接近原生CUDA的性能。然而：

1. 优势：

   • 性能接近原生CUDA实现
   • 支持更广泛的存储操作
   • 兼容更多现代AMD显卡

2. 局限：

   • 缺少hiprtc支持，影响CodeFormer的JIT编译
   • 对某些旧架构显卡支持有限

张量设备同步问题

当出现"Input type and weight type should be the same"错误时，这表明模型权重和输入数据位于不同的设备上。解决方案包括：

1. 确保所有张量位于同一设备
2. 使用.to(device)方法显式转换张量设备
3. 在模型加载时指定正确的设备

最佳实践建议

1. 对于现代AMD显卡（RDNA架构及以上），优先考虑ZLUDA方案
2. 保留DirectML作为备选方案，特别是当遇到兼容性问题时
3. 定期检查模型文件的完整性和存放位置
4. 考虑使用--no-half参数避免精度转换问题
5. 监控GPU内存使用情况，必要时使用--medvram参数

结论

Stable Diffusion WebUI AMDGPU项目中GFPGAN和CodeFormer的兼容性问题主要源于后端实现的差异。通过合理选择运行后端、正确配置模型路径以及理解张量设备同步机制，用户可以有效地解决这些问题。对于大多数用户而言，结合使用ZLUDA和CPU回退方案能够提供最佳的使用体验。

随着项目的持续发展，这些问题有望在未来版本中得到更好的解决。建议用户关注项目更新日志，及时获取最新的兼容性改进信息。