惊喜！这是我最近完成的 AI for Web Devs 系列的附赠博客文章。如果您还没有阅读该系列，我建议您检查一下出。
这篇文章将着眼于现有的项目架构以及我们可以为应用程序开发人员和最终用户改进它的方法。
我将讨论一些一般概念，并在示例中使用特定的 Akamai 产品。
现有的应用程序非常基础。用户提交两个对手，然后应用程序会返回人工智能生成的响应，表明谁会在战斗中获胜。
架构也很简单：
- 客户端向服务器发送请求。
- 服务器构造提示并将提示转发给 OpenAI。
- OpenAI 将流式响应返回到服务器。
- 服务器进行必要的调整并将流响应转发给客户端。
我使用了 Akamai 的云计算服务（以前是 Linode），但这会对于任何托管服务都是相同的。
图。 1.云应用架构从技术上讲，这工作正常，但存在一些问题，特别是当用户发出重复请求时。将响应存储在我们的服务器上并且仅针对独特的请求才转到 OpenAI，这样会更快、更经济。
这假设我们不需要每个请求都是不确定的（相同的输入产生不同的输出）。假设相同的输入可以产生相同的输出。毕竟，对谁会在战斗中获胜的预测不太可能改变。
添加数据库架构
如果我们想存储来自 OpenAI 的响应，一个实用的地方就是将它们放在某种数据库中，这样可以使用两个对手进行快速轻松的查找。这样，当发出请求时，我们可以先检查数据库：
- 客户端向服务器发送请求。
- 服务器会检查数据库中是否存在与用户输入相匹配的现有条目。
- 如果存在先前的记录，服务器将使用该数据进行响应，并且请求完成。跳过以下步骤。
- 如果没有，服务器将从上一流程中的第三步开始执行。
- 在关闭响应之前，服务器会将 OpenAI 结果存储在数据库中。
图 2。带有数据库的应用程序架构通过此设置，任何重复的请求都将由数据库处理。通过将某些 OpenAI 请求设置为可选，我们可以减少用户体验的延迟，并通过减少 API 请求的数量来节省资金。
这是一个好的开始，特别是当服务器和数据库位于同一区域时。与访问 OpenAI 的服务器相比，它的响应时间要快得多。
但是，随着我们的应用程序变得越来越流行，我们可能会开始吸引来自世界各地的用户。更快的数据库查找固然很棒，但如果瓶颈是飞行时间造成的延迟，会发生什么情况？
我们可以通过让事物更接近用户来解决这个问题。
引入边缘计算
如果您还不熟悉“边缘”一词，这部分可能会令人困惑，但我会尽力简单地解释一下。边缘是指内容尽可能贴近用户。对于某些人来说，这可能意味着物联网设备或手机信号塔，但就网络而言，典型的示例是 内容分发网络 (CDN)。
我不会详细介绍，但 CDN 是一个由全球分布的计算机组成的网络，可以响应来自网络中最近节点的用户请求 (我过去写过的内容）。虽然传统上它们是为静态资产设计的，但近年来，它们开始支持边缘计算（也是我过去写过的内容）。
通过边缘计算，我们可以将许多后端逻辑移至离用户非常近的位置，并且它不会停留在计算上。大多数边缘计算提供商还在同一边缘节点中提供某种最终一致的键值存储。
这会对我们的应用程序产生什么影响？
- 客户端向我们的后端发送请求。
- 边缘计算网络将请求路由到最近的边缘节点。
- 边缘节点检查键值存储中是否存在与用户输入匹配的现有条目。
- 如果存在先前的记录，则边缘节点会使用该数据进行响应，并且请求完成。跳过以下步骤。
- 如果没有，边缘节点会将请求转发到源服务器，源服务器将其传递给 OpenAI 和 yadda yadda yadda。
- 在关闭响应之前，服务器会将 OpenAI 结果存储在边缘键值存储中。
图 3。具有边缘计算的应用架构源服务器在这里可能不是绝对必要的，但我认为它更有可能存在。出于数据、计算和逻辑流的考虑，这与之前的架构基本相同。主要区别在于，以前存储的结果现在离用户非常近，并且几乎可以立即返回。
（注意：虽然数据在边缘缓存，但响应仍然是动态构造的。如果不需要动态响应，在源服务器前面使用 CDN 并设置正确的响应可能会更简单用于缓存响应的 HTTP 标头。这里有很多细微差别，我可以说更多，但是……好吧，我累了，不想这样做。如果您有任何问题，请随时与我们联系。）
现在我们开始做饭了！任何重复的请求都将几乎立即得到响应，同时还为我们节省了不必要的 API 请求。
这整理了文本响应的架构，但我们也有人工智能生成的图像。
缓存这些图像
今天我们要考虑的最后一件事是图像。在处理图像时，我们需要考虑传递和存储。我确信 OpenAI 的人员有他们的解决方案，但出于安全、合规性或可靠性原因，一些组织希望拥有整个基础设施。有些甚至可能运行他们的图像生成服务，而不是使用 OpenAI。
在当前的工作流程中，用户发出的请求最终会到达 OpenAI。 OpenAI 生成图像但不返回它。相反，它们返回一个 JSON 响应，其中包含图像的 URL，托管在 OpenAI 的基础设施上。通过此响应，可以使用 URL 将
如果我们想在我们的基础设施上托管图像，我们需要一个地方来存储它。我们可以将图像写入原始服务器的磁盘上，但这可能会很快耗尽磁盘空间，而且我们必须升级服务器，这可能会很昂贵。 对象存储是一种更便宜的解决方案（我也写过相关内容）。我们可以将其上传到我们的对象存储实例并使用该 URL，而不是使用图像的 OpenAI URL。
这解决了存储问题，但对象存储桶通常部署到单个区域。这与我们在数据库中存储文本时遇到的问题相呼应。单个区域可能距离用户较远，这可能会导致大量延迟。
已经介绍了边缘，仅为静态资产添加 CDN 功能将非常简单（坦率地说，每个站点都应该有一个 CDN）。配置完成后，CDN 将根据初始请求从对象存储中提取图像，并缓存它们以供同一区域访问者将来的任何请求。
这是我们的图像流程：
- 客户端发送请求以根据其对手生成图像
- 边缘计算检查该请求的图像数据是否已存在。如果是，则返回 URL。
- 图像将添加到带有 URL 的页面，并且浏览器会请求该图像。
- 如果图像之前已缓存在 CDN 中，则浏览器几乎会立即加载它。流程到此结束。
- 如果之前未缓存该图像，CDN 将从对象存储位置提取图像，缓存其副本以供将来请求，然后将图像返回给客户端。这是流程的另一端。
- 如果图像数据不在边缘键值存储中，则生成图像的请求将发送到服务器并继续发送到 OpenAI，后者生成图像并返回 URL 信息。服务器启动任务将图像保存到对象存储桶中，将图像数据存储到边缘键值存储中，并将图像数据返回给边缘计算。
- 使用新的图像数据，客户端创建图像，该图像会创建新请求并从上面的第五步继续。
图 4。显示客户端连接到边缘节点的架构图诚然，最后一种架构有点复杂，但如果您的应用程序要处理严重的流量，则值得考虑。
瞧
对了！完成所有这些更改后，我们为独特的请求创建了人工智能生成的文本和图像，并为重复的请求从边缘提供缓存的内容。结果是更快的响应时间和更好的用户体验（除了更少的 API 调用）。
我故意让这些架构图适用于各种数据库、边缘计算、对象存储和 CDN 提供商。我希望我的内容具有广泛的适用性。但值得一提的是，集成边缘不仅仅关乎性能。您还可以启用许多非常酷的安全功能。
例如，在 Akamai 的网络上，您可以访问诸如 Web 应用程序防火墙 (WAF)、分布式拒绝服务 (DDoS) 保护、智能机器人检测 等等。不过，这超出了今天帖子的范围。
所以现在，我要对您的阅读表示深深的“感谢”。我希望你学到了一些东西。与往常一样，请随时联系我们提出意见、问题或疑虑。
非常感谢您的阅读。如果您喜欢这篇文章，并且想支持我，最好的方法是 分享并在 Twitter 上关注我。