云端实时图像生成：Transformirror艺术装置的部署经验

Transformirror (2023) 由大藤真也和凯尔·麦当劳制作的

2023年12月，我和Daito Manabe以及Rhizomatiks共同开发了一个实时扩散工具包。该工具包基于SDXL Turbo，分辨率为1024x1024，并通过stable-fast加速。Stability AI 支持了这项工作，允许我们使用 SDXL Turbo 来开发互动装置和应用项目。我们利用这个图像到图像的系统，为大阪的Transformirror和东京NTT ICC的[Ryuichi Sakamoto回顾展]中的[Generative MV]提供动力。此外，我们还成功地满足了Perfume & Daichi Miura新年现场演出的苛刻的视频直播要求。

虽然视频到视频的管道在过去一年中有了很大的进步，但对于实时低延迟处理的可能性并没有显著的变化。Stream Diffusion 使512x512的扩散更容易实现，但因为模型许可的限制和硬件要求，很少有人能在实时环境中体验这种效果。

Transformirror今年被纳入比利时KIKK Festival，就像许多艺术节一样，预算有限。为了降低成本并使巡演更方便，我研究了在云托管作品的解决方案。这样，我们可以只在现场放置一台轻量客户端（如Mac mini），配备网络摄像头、扬声器和高速互联网连接——而租用一台昂贵且重量大的多GPU云机器。

大阪最初的Transformirror版本使用了两台通过网络连接在一起的台式机，每台机器配备了一块RTX 4090显卡。我估计所有这些设备的总价值可能接近10,000美元。运输这些设备可能要花费数千美元，这意味着每次运输成本也很高，我们一次只能在一个地方展示作品。另一方面，在云端使用一块RTX 4090可能低至每小时0.30美元（参考：https://cloud-gpus.com/）。对于为期四天的节日，这可能低至100美元。

我审查了十几个云GPU供应商。我的初始要求只是低延迟。该设施位于布鲁塞尔附近，我希望延迟低于30毫秒——在现有的100毫秒延迟之上，大约一到两帧的延迟。在这一阈值边缘的数据中心有冰岛（位于38毫秒延迟）、罗马尼亚（36毫秒）、芬兰（34毫秒）。任何更近的地方也行（如法国、德国、荷兰，乃至英国）。

当我深入研究之后，我意识到价格亲民是另一个重要因素。例如，我当然可以使用谷歌云或亚马逊AWS，但它们提供的GPU比一些竞争对手的GPU贵将近5倍。

基本上有两种级别的云GPU：企业级GPU和消费级GPU。企业级GPU，如H100和A100，具有非常高的内存和带宽，并且具有有助于训练的高级功能，这使得它们非常适合用于训练任务；消费级GPU，如4090等型号。企业级GPU的价格大约是消费级GPU的3–4倍，这是因为企业级GPU提供了更多的功能和更好的性能。因为我们只进行推理（而不是训练），消费级GPU在性能上与企业级GPU相当。据我了解，NVIDIA自2018年以来明确禁止消费级GPU用于数据中心使用[1]，尽管如此，像Vast.ai、PureGPU和TensorDock这样的公司仍在使用它们。

我发现接下来的事情是，每个服务在配置和网络设置上都有自己的特点。有些服务是为了研究人员想要使用带有GPU的Jupyter Notebook而设计的，性能不是最重要的。有些服务则是为了大规模训练任务而设计的，具有严格的网络策略。还有一些服务是为了运行“无服务器架构”设计的，启动一个临时端点的Docker镜像，然后关闭。我在寻找更接近裸机、持久性更强且网络开放的服务，这样我就能实时发送和接收视频。

在深入探讨云选项之前，我决定在我的本地GPU上重写这个项目。我使用了WebRTC，这是支持浏览器内视频聊天的技术。WebRTC使用UDP协议，因此延迟很低，很适合实时通信。它会根据可用带宽自动调整视频质量，它还会缓冲和去抖动传入的视频。我很快完成了第一个版本，准备开始测试。

那就是我了解到有些服务会限制UDP，因为它与使用 torrent 相关。我通过编写一个简单的 webrtc-bot，该代码将你的视频流色彩反转，从而发现了这个情况。这个简单的代码意味着我不需要先检查 NVIDIA 驱动配置就能得知网络是否支持 WebRTC。我在不同的云服务器上运行它。

最终，不支持 WebRTC 的两个服务是 Hyperstack 和 RunPod。它们也是最便宜的选择，所以我决定不放弃它们，而是重新编写工具，通过 WebSockets 发送 JPEG 图像。我本应先尝试这种方法，因为它已经被 GenDJ 项目 测试过并证明有效，该项目之前成功地在我的图像到图像代码上运行过。

WebSocket运行良好，且延迟比WebRTC低，但抖动更严重，并且也没有带宽调整的好处。

最后一个问题是在哪里托管。经过一系列更彻底的测试，我选择了RunPod和Latitude。主要是因为它们都比较实惠，而且都离布鲁塞尔比较近：RunPod在罗马尼亚提供4090型号的GPU，每小时0.70美元；在荷兰提供L40型号的GPU，每小时1美元；而Latitude在法兰克福提供8xA100服务器，每小时11.50美元。Hyperstack有一个挪威的数据中心，但没有可用资源。

纬度极其流畅。你知道通过 SSH 查看 apt update 的滚动更新时，那种像黄油一样顺滑的感觉吗？一台维护良好且配置冗余的服务器就是有这种感觉。懂的自然懂。还有一些可量化的差异：加载 SDXL Turbo 的模型权重速度极快，只需几秒。而在 RunPod 上，启动速度慢许多。把权重加载到 GPU 上可能需要一分钟，而且第一次运行会非常慢，直到 GPU 预热。一旦所有内容加载好，两个服务的性能就差不多了。

RunPod 有一个非常不错的功能，允许你在停止服务器后保留所有存储。RunPod 提供一个持久的 /workspace 目录，该目录大约每天 $0.13 的维护费用。而在 Latitude 上，没有类似的选项：一旦你停止服务器，磁盘会被清空，下次需要重新开始。他们最近为了解决这个问题，刚刚添加了一个正在测试中的“网络卷”功能，但该功能目前还处于测试阶段，我还没有让它成功运行。

还有一个问题是我在使用过程中遇到了。我原本希望Lambda Cloud能满足我们的需求。自从他们开始销售深度学习桌面以来，我就一直关注他们的动态，并且一直很欣赏他们的努力。但是一台1xA100机器上进行测试后，我发现性能并不稳定。推理时间在120到220毫秒之间。

Lambda Labs的SDXL Turbo定时设置。

参考来说，一个 RunPod 4090 的延迟通常在 70 至 74 毫秒范围内。对于实时应用来说，这种巨大的波动会严重影响实时交互性，因为实际体验的延迟等同于最坏情况下的延迟——换句话说，你必须为所有帧预留足够的时间以避免输出抖动。

SDXL Turbo 加速，由 RunPod 提供。

大多数服务与RunPod差不多，但偶尔会出现一些小问题。比如在Latitude上的一个例子，在几分钟的测试中出现了一次短暂但明显的延迟增加，以及几毫秒的微小延迟。

来自Latitude的SDXL Turbo功能。

还有一些值得一提的服务：

• 我真的很喜欢LeafCloud在阿姆斯特丹所做的工作。他们的数据中心余热被用来给住宅楼供暖。最后他们没有我所需要的GPU库存，从而无法达到Transformirror所需的最低推理延迟。
• 我短暂地测试了新的Digital Ocean H100服务，但当时它们只在纽约可用，而且价格非常昂贵，每小时24美元的8xH100机器。不过，它运行非常顺畅。
• 我试了Leader Telecom，它的界面非常独特，而且有许多UI错误，甚至让付款变得困难。我还遇到了服务器配置问题，不知为何花费了15分钟才启动，并且在这段时间内我一直在被扣费。他们的价格也比RunPod高四倍，每小时6欧元的2x4090机器。后来他们在我联系后退还了我费用。
• 我考虑了TensorDock，但他们没有满足要求的快速GPU可用。
• 我试用了Vast，它是基于Docker镜像运行的，但我难以让带有WebRTC的Docker镜像正常工作。我从未弄清楚是由于我对Docker不熟悉，还是因为他们的网络原因。我没有再试WebSocket版本。
• 我了解了FluidStack，但无法确定他们的服务器实际位于哪里。
• 我试用了OVHCloud，但遇到了一些法律问题，因为我是在美国注册的，但他们不让我在美国注册账户？如果想使用OVHCloud，可能先访问他们的美国网站会好一些。
• 我试了Linode，但无法完成注册流程。
• Vultr看起来非常有前景，但我无法找到满足延迟要求的可用服务器。
• Salad声称是最实惠且高可用性，但不清楚他们的服务器位置。
• Scaleway看起来非常不错，但注册和验证过程复杂，需要护照验证。我没能快速完成验证以测试他们的服务。他们在巴黎提供了2xH100机器，每小时6美元，如果确实是高可用性的话，这将是一个相当不错的交易。

我一直提到“可用性”，这是我学到的一个重要教训是：不是每个服务都能随时提供你想要的GPU。这些服务旨在满足短期GPU应用的需求，比如短期微调和无服务器GPU端点。他们试图动态调整服务器价格，以确保始终有一些GPU可用，但不会太多。我最初的想法是每天从早上8点开始开启服务器，晚上6点关闭，这样只需支付一半的成本运行服务器，而不是全天候运行。经过几天的测试后，我发现有时当我尝试启动服务器时，RunPod上只提供了2个4090 GPU，而不是我所需要的3个。最终，我不得不在整个展览期间一直预留这些GPU，不关闭机器。

感谢Latitude和RunPod，他们为我们运行这个项目提供了技术支持。最终，我们在Latitude上运行了两天，在RunPod上也运行了两天，从两者那里得到了非常相似的成果。特别感谢LeafCloud的支持。