Stable Diffusion 3.5 FP8 多卡并行实测：双 GPU 扩展性分析

多 GPU 并行：不是所有'能分'的模型都能'高效分'

说到多卡，很多人第一反应是'数据并行'——复制模型到两张卡，各跑一批图像。听起来合理，但对文生图任务来说，这不是最优解。

为什么？因为大多数用户请求都是独立的小批量（batch=1 或 2），根本填不满两张卡的算力。这时候真正有用的是 模型并行（Model Parallelism） ——把一个巨大的 U-Net 拆开，一部分放在 GPU0，另一部分放 GPU1，协同完成一次推理。

Stable Diffusion 3.5 的结构非常适合这种拆分。它的 U-Net 层数深、参数多，且前中后段计算负载相对均衡。我们可以这样分配：

custom_device_map = {
    "text_encoder": 0,
    "unet.encoder": 0,
    "unet.middle_block": 1,
    "unet.decoder": 1,
    "vae": 1
}

在这个配置下，文本编码仍在 GPU0 完成，早期下采样留在 GPU0，中间块和上采样交给 GPU1，最后 VAE 解码也在 GPU1 收尾。整个流程就像一条装配线，数据沿着 NVLink 高速流动。

但这里有个致命细节：通信开销。

如果两张卡之间靠 PCIe 4.0 x16 连接，最大带宽只有约 32 GB/s。而 U-Net 中间特征图动辄几十 MB，每步迭代都要跨卡传输一次，很容易造成'计算等传输'的局面。结果就是：双卡总显存翻倍了，速度却没快多少，甚至可能更慢。

解决办法只有一个：NVLink。

我们在一台配备双 L40S（通过 NVLink 桥接）的服务器上进行了对比测试：

看到区别了吗？只有在 NVLink 加持下，双卡才真正发挥了价值。PCIe 版本甚至比单卡还慢一点点，就是因为通信成了瓶颈。

这也解释了一个现象：为什么很多云服务商宣传'多 GPU 加速 SD3'，但实测效果平平。很可能他们的实例根本没有启用 NVLink，或者使用的是跨节点分布式架构（网络延迟更高）。

实战部署：别让'理论上可行'变成'实际上崩溃'

你以为加载成功就万事大吉？远远没有。

我们在实际部署中遇到过几个典型坑：

坑一：device_map="balanced" 并不总是平衡

Hugging Face Accelerate 提供的 load_checkpoint_and_dispatch(..., device_map="balanced") 看似智能，但实际上它是按参数量均分，而不是按 FLOPs 或内存峰值来划分。结果可能导致 GPU0 承担了更多高耗能层（如 Attention QKV 投影），而 GPU1 空转等待。

解决方案是手动指定 device_map，结合 accelerate estimate-memory 工具预估各层显存消耗，做到真正的负载均衡。

坑二：FP8 模型无法直接保存为 .safetensors

当前主流的 safetensors 格式尚未完全支持 FP8 数据类型。如果你尝试直接保存量化后的状态字典，可能会遇到类型不兼容错误。建议做法是：

• 使用 TensorRT-LLM 编译成 .engine 文件；
• 或者保持模型在内存中动态加载，避免频繁序列化。

坑三：某些插件（如 ControlNet）未适配 FP8

当你想叠加姿态控制、边缘检测等功能时，发现第三方 ControlNet 模型仍是 FP16。一旦融合进来，整个流水线会被迫升回高精度，FP8 的优势瞬间归零。

应对策略有两种：

1. 对 ControlNet 也进行 PTQ 量化（需自行校准）；
2. 将 ControlNet 固定部署在辅助 GPU 上，主流程仍走 FP8 路径。

生产级架构该怎么设计？

回到现实世界。如果你要搭建一个面向企业客户的 AIGC 平台，仅仅跑通单次推理远远不够。你需要考虑的是：稳定性、并发能力、成本效率。

我们的推荐架构如下：

[客户端] → [API Gateway] → [Kubernetes Ingress]
                                          ↓
                              [推理 Pod 集群（Deployment）]
                                          ├── Pod A: 双 L40S + NVLink, sd35-fp8 + TRT-LLM
                                          ├── Pod B: 同上
                                          └── 共享 PV: 模型缓存/NFS 输出目录

每个 Pod 内部运行一个经过 TensorRT-LLM 编译的 FP8 引擎，采用模型并行 + 流水线调度。外部通过 KEDA 实现基于 GPU 利用率的自动扩缩容。当 QPS 上升时，Kubernetes 自动拉起新 Pod；请求低谷时回收资源。

监控层面重点关注三个指标：

• per-GPU 显存使用率（警惕 >90% 触发 OOM）
• 跨卡通信延迟（>5ms 需排查 NVLink 状态）
• P99 端到端延迟（应稳定在 8 秒以内）

此外，务必设置降级策略：当主模型加载失败或超时时，自动切换至轻量版（如 SDXL-Turbo 或 SD3.5-base half precision），保证服务可用性。

结语：FP8 + 多卡，并非万能药，但已是必选项

stable-diffusion-3.5-fp8 的出现，标志着开源文生图模型正式迈入'工程友好'时代。它不再是研究者的玩具，而是可以真正在生产环境中跑起来的工业组件。

它的多 GPU 支持并不是'开箱即用'的功能按钮，而是一套需要精心调校的技术组合拳：从量化方法的选择，到设备映射的设计，再到互联硬件的匹配，每一个环节都影响最终表现。

但我们必须承认，在 NVLink 支持下的双 GPU FP8 部署，已经能够实现接近 1.7 倍的速度增益和近乎线性的显存分摊。这意味着：

• 更低的单位生成成本；
• 更高的服务吞吐；
• 更广泛的硬件适配可能性。

未来，随着 FP8 生态进一步成熟（ONNX Runtime、Triton Inference Server 等陆续跟进），我们有望看到更多自动化工具帮助开发者绕过底层复杂性，专注于业务逻辑本身。

而对于今天的你我而言，掌握这套'量化 + 并行'的核心技术栈，已经不再是'加分项'，而是构建下一代 AI 内容引擎的基本功。