367 讀數

人工智能应用：高级架构建议（AKA AAAA！）

经过 Austin Gil9m2024/02/15

太長; 讀書

我故意让这些架构图适用于各种数据库、边缘计算、对象存储和 CDN 提供商。我希望我的内容具有广泛的适用性。但值得一提的是，集成边缘不仅仅关乎性能。您还可以启用许多非常酷的安全功能。例如，在 Akamai 的网络上，您可以访问 Web 应用程序防火墙 (WAF)、分布式拒绝服务 (DDoS) 保护、智能机器人检测等。不过，这超出了今天帖子的范围。所以，现在，我要对您的阅读表示深深的“感谢”。我希望你学到了一些东西。与往常一样，请随时联系我们提出意见、问题或疑虑。

featured image - 人工智能应用：高级架构建议（AKA AAAA！）

惊喜！这是我最近完成的 AI for Web Devs 系列的附赠博客文章。如果您还没有读过该系列，我鼓励您阅读一探究竟。

这篇文章将着眼于现有的项目架构以及我们可以为应用程序开发人员和最终用户改进它的方法。

我将讨论一些一般概念，并在示例中使用特定的 Akamai 产品。

基本应用架构

现有的应用程序非常基础。用户提交两个对手，然后应用程序会返回人工智能生成的响应，表明谁会在战斗中获胜。

架构也很简单：

客户端向服务器发送请求。
服务器构造提示并将提示转发给OpenAI。
OpenAI 将流式响应返回到服务器。
服务器进行任何必要的调整并将流响应转发到客户端。

我使用了 Akamai 的云计算服务（以前易诺德），但这对于任何托管服务来说都是一样的，真的。

🤵看起来像一家高级餐厅的服务员，👁️‍🗨️是“眼睛”，或者说AI。哈哈

从技术上讲，这工作正常，但存在一些问题，特别是当用户发出重复请求时。将响应存储在我们的服务器上并且仅针对独特的请求才转到 OpenAI，这样可能会更快、更经济。

这假设我们不需要每个请求都是不确定的（相同的输入产生不同的输出）。我们假设相同的输入可以产生相同的输出。毕竟，对谁会在战斗中获胜的预测不太可能改变。

添加数据库架构

如果我们想存储来自 OpenAI 的响应，一个实用的地方就是将它们放在某种数据库中，这样可以使用两个对手进行快速轻松的查找。这样，当发出请求时，我们可以先检查数据库：

客户端向服务器发送请求。
服务器检查数据库中是否存在与用户输入相匹配的现有条目。
如果存在先前的记录，服务器将使用该数据进行响应，并且请求完成。跳过以下步骤。
如果没有，服务器将从上一流程中的第三步开始执行。
在关闭响应之前，服务器将 OpenAI 结果存储在数据库中。

虚线代表可选请求，💽 看起来像硬盘。

通过此设置，任何重复的请求都将由数据库处理。通过将某些 OpenAI 请求设置为可选，我们可以减少用户体验的延迟，并通过减少 API 请求的数量来节省资金。

这是一个好的开始，特别是当服务器和数据库位于同一区域时。与 OpenAI 的服务器相比，它的响应时间要快得多。

然而，随着我们的应用程序变得越来越流行，我们可能会开始吸引来自世界各地的用户。更快的数据库查找固然很棒，但如果瓶颈是飞行时间造成的延迟，会发生什么情况？

我们可以通过让事物更接近用户来解决这个问题。

引入边缘计算

如果您还不熟悉“边缘”一词，这部分可能会令人困惑，但我将尝试简单地解释它。边缘是指内容尽可能贴近用户。对于某些人来说，这可能意味着物联网设备或手机信号塔，但就网络而言，典型的例子是内容分发网络 (CDN) 。

我就不详细介绍了，CDN 是一个由全球分布的计算机组成的网络，可以响应来自网络中最近节点的用户请求（我过去写过的一些事情）。虽然传统上它们是为静态资产设计的，但近年来，它们开始支持边缘计算（还有我过去写过的东西）。

通过边缘计算，我们可以将许多后端逻辑移至离用户非常近的位置，并且它不会停留在计算上。大多数边缘计算提供商还在相同的边缘节点中提供某种最终一致的键值存储。

这会对我们的应用程序产生什么影响？

客户端向我们的后端发送请求。
边缘计算网络将请求路由到最近的边缘节点。
边缘节点检查键值存储中是否存在与用户输入匹配的现有条目。
如果存在先前的记录，则边缘节点会使用该数据进行响应，并且请求完成。跳过以下步骤。
如果没有，边缘节点会将请求转发到源服务器，源服务器将其传递给 OpenAI 和 yadda yadda yadda。
在关闭响应之前，服务器将 OpenAI 结果存储在边缘键值存储中。

边缘节点是蓝色框，由 🔪 表示，因为它有一条边缘，EdgeWorker 是 Akamai 的边缘计算产品，由 🧑‍🏭 表示，EdgeKV 是 Akamai 的键值存储，由 🔑🤑🏪 表示。边缘盒比云中的源服务器更靠近客户端，以表示物理距离。

源服务器在这里可能不是绝对必要的，但我认为它更有可能存在。出于数据、计算和逻辑流的考虑，这与之前的架构基本相同。主要区别是以前存储的结果现在离用户非常近，并且几乎可以立即返回。

（注意：虽然数据缓存在边缘，但响应仍然是动态构造的。如果不需要动态响应，在源服务器前面使用 CDN 并将正确的 HTTP 标头设置为更简单缓存响应。这里有很多细微差别，我可以说更多，但是……好吧，我累了，并且真的不想这样做。如果您有任何问题，请随时与我们联系。）

现在我们做饭了！任何重复的请求几乎都会立即得到响应，同时也节省了我们不必要的 API 请求。

这整理了文本响应的架构，但我们也有人工智能生成的图像。

缓存这些图像

今天我们要考虑的最后一件事是图像。在处理图像时，我们需要考虑传递和存储。我确信 OpenAI 的人员有自己的解决方案，但出于安全、合规性或可靠性原因，一些组织希望拥有整个基础设施。有些人甚至可能运行自己的图像生成服务，而不是使用 OpenAI。

在当前的工作流程中，用户发出的请求最终会到达 OpenAI。 OpenAI 生成图像但不返回它。相反，它们返回一个 JSON 响应，其中包含图像的 URL，托管在 OpenAI 的基础设施上。

通过此响应，可以使用 URL 将<img>标记添加到页面，从而启动对实际图像的另一个请求。

如果我们想在自己的基础设施上托管图像，我们需要一个地方来存储它。我们可以将图像写入原始服务器的磁盘上，但这可能会很快耗尽磁盘空间，并且我们必须升级我们的服务器，这可能会很昂贵。

对象存储是一个更便宜的解决方案（我也写过这个）。我们可以将其上传到我们自己的对象存储实例并使用该 URL，而不是使用图像的 OpenAI URL。

这解决了存储问题，但对象存储桶通常部署到单个区域。这与我们在数据库中存储文本时遇到的问题相呼应。单个区域可能距离用户较远，这可能会导致大量延迟。

已经引入了边缘，仅为静态资产添加 CDN 功能将非常简单（坦率地说，每个站点都应该有一个 CDN）。配置完成后，CDN 将根据初始请求从对象存储中提取图像，并缓存它们以供同一区域访问者将来的任何请求。

我们的图像流程如下所示：

客户端发送请求以根据其对手生成图像。
边缘计算检查该请求的图像数据是否已存在。如果是，则返回 URL。
图像被添加到带有 URL 的页面，并且浏览器请求该图像。
如果图像之前已缓存在 CDN 中，则浏览器几乎会立即加载它。这是流程的结束。
如果之前未缓存该图像，CDN 将从对象存储位置拉取图像，缓存其副本以供将来请求，然后将图像返回给客户端。这是流程的另一端。
如果图像数据不在边缘键值存储中，则生成图像的请求将发送到服务器并继续发送到 OpenAI，后者生成图像并返回 URL 信息。服务器启动任务将图像保存到对象存储桶中，将图像数据存储到边缘键值存储中，并将图像数据返回到边缘计算。
使用新的图像数据，客户端创建图像，该图像创建新请求并从上面的第五步继续。