加速图形链接：揭示稳定扩散图形网络传输的终极优化方案

本文主要针对利用FAAS提供SD(Stable Diffusion WebUI) 生图的业务场景，讨论生图过程中网络传输部分的优化方法，以提高整个生图任务的速度。

对于Stable Diffusion，大家并不陌生，一个简单的Stable Diffusio FAAS服务的链路如下所示：

简单来说可以分为两步：

步骤一：用户请求FAAS API 这一步涉及到的主要是鉴权，计费，任务调度等等各FAAS平台内部的应用逻辑。

步骤二：FAAS服务真正去请求分配到的Stable Diffusion WebUI实例，进行图片生成，并将结果返回给用户。

经过如上链路分解，我们很容易就可以发现：在网络传输上，步骤一可优化的点不多，基本就是一个简单的API调用，这步能做的也最有效的就是压缩数据内容，降低传输数据量。

对于步骤二，这里我们先简单看一下在一个GPU资源为3090场景下，一个512*512的一般文生图请求，整个链路大致的时间分布。

可以看到，在常规场景下，总和3.7s的FAAS生图过程，仅第二步的网络传输部分就占据了38%！

这里过长的时间消耗主要是由以下几个原因导致的：

（1）FAAS服务与WEBUI实例间的物理延迟：这里由于大部分的FAAS服务和WEBUI实例之间都是通过公网传输，首先于地域距离，仅一个RTT的延迟可能就在100-300ms之间不等；

（2）tcp传输过程中的拥塞控制：一个简单的文生图请求，传输的数据内容大致是在400K-2000K之间，这里由于tcp默认拥塞窗口的变化：initcwnd的值从从初始的10， 不断指数增增长。可大致得出，即使在图片大小为400K的场景下，也需要至少5个RTT才能完成数据传输，这无疑加剧了（1）带来的影响！

针对如上问题，有没有大致的解决方案呢？

当然有，最直接的就是不考虑成本，直接自建IDC，这种方式下，几乎可以将延迟降低到50ms以内。但是对于大部分的FAAS服务，都需要考虑在资源，成本受限的情况下，如何对这一部分进行尽可能的优化，所以，我们提出了以下几个方案：

减小图片尺寸

如步骤一的优化，最简单高效的方式就是压缩图片尺寸，这一步目前流行的http服务几乎都已经支持，只需要简单的调用一些参数即可带来不弱的速度提升。

"Accept-Encoding: gzip"

提高拥塞窗口，减少RTT次数

如上所示，由于tcp的拥塞控制算法导致了RTT次数的增加，又由于服务间地理位置的限制，导致了RTT的时间增加，两者叠加的影响是巨大的，这里我们可以通过控制tcp的拥塞窗口，以一个较大的初始值开始数据传输，这一步可以将RTT的次数从5-7次减小到3以内，平均减少600ms的延迟， 带来的提升是巨大的！

具体可以通过IP Route的方式进行配置，以及调整默认的so buffer大小。

ip route change default via <gateway_ip> initcwnd 500

syscall.SetsockoptInt(int(fd), syscall.SOL_SOCKET, syscall.SO_SNDBUF, <send_buffer_size>)

终极方案：应用层控制传输

如上的方案，在当前场景下，还是有很多限制的，目前的GPU服务，基本都部署在各个供应商提供的云平台上，带来的问题就是权限的不足，如上所示对IP Route的配置以及内核参数的修改，很大概率都是没有权限的，那又什么方案能一劳永逸的解决这个问题呢，答案就是："UDP+用户层控制传输"。

假如我们的架构变成这种：

显而易见，通过这一步，虽然带来了链路复杂度的增加，但我们将公网链路的数据传输控制在了自己手里。这带来的好处就是我们可以任意使用传输方式，QUIC、KCP等等，通过这些协议，我们完全掌握了拥塞控制，不仅能实现RTT的减少，私有协议的使用，在一定程度上，还增加了系统的安全性

总结

如上的优化思路带给我们的启发就是，只有尽可能的掌握对网络传输的控制权，才能减少对各种环境对系统带来的影响，增加适用性，同时，网络优化永无止境，以上只是浅层的讨论对Stable Diffusion图像生成过程中的优化。

最后，如果您有任何疑问，或者想要一起探讨 Stable Diffusion 更多的加速方案，可以在我们的 discord 上联系我们 discord.gg/7gt3q5R77s ，最后，如果您想要使用 SDXL1.0 模型，也可以在 discord 获取相关信息

欢迎点击体验测试 Omniinfer的图片生成速度： API 、 demo 、 nogpu