GenAI Traffic: Why API Infrastructure Must Evolve... Again // Erica Hughberg // #296
01:06:24 Share

我的名字是埃里卡·胡伯格，我在一家名为 Tetrate 的公司担任社区倡导者，这意味着我倾听业内人士的意见，并确保正在构建的解决方案真正能够满足人们的实际需求。我如何喝咖啡？不幸的是，我通常喝冷咖啡，并非出于选择，但我确实喝黑咖啡。所以我经常会在桌子上放一杯冷咖啡，因为我没有及时喝完。

我们又回到了 MLOps 社区播客的节目中。我是主持人德米特里奥斯。今天与埃里卡的交谈中，我了解了一些关于互联网演变以及我们如何普遍地在计算机上进行操作的信息，还有她关于我们如何朝着互联网的一种现实努力，但由于大型语言模型，这一切都发生了翻天覆地的变化的理论。我们不会剧透任何内容。我只想直接进入对话。我和埃里卡的谈话非常愉快。她很有幽默感，我很感谢她来到播客节目。让我们开始吧！我想直接进入这次谈话的重点。听起来很糟糕。我们就这样开始吧。

是的，我不太喜欢豆腐。我对吃豆腐的方式非常挑剔。只有在泰式炒河粉里，而且是脆的才行。是的，但是有很多方法可以制作豆腐。我一生中做过一些非常糟糕的豆腐。我尝试过做一些炒豆腐。那不是一个好主意。是的，很难。是的，我失败了。所以我不会再做了。所以，让我们进入这次谈话的重点，那就是……

互联网正在发生一些变化。你一直在花很多时间研究网关，并思考不同的网关，我认为。是的。你能为我们解释一下吗？然后我们将深入探讨它。是的。所以我认为有时回顾一下互联网的网络以及我们的应用程序在过去是如何通信的，这很有帮助……

自 2010 年以来，或者更早，不，更早之前。自 21 世纪初以来，我把年份弄错了。看，我老了。我想，哦，也许没那么久。所以至少在过去的 25 年里，

互联网的演变非常有趣，如果我们回到 21 世纪初，比如 2001 年、2002 年、2003 年，当时发生了什么，以及这与生成式 AI 如何相关，希望很快就会变得很明显，但如果你当时在场，我很感激所有年龄超过 25 岁的人，也有一些年龄小于 25 岁的人

但对于我们这些当时在场的人来说，那是一个非常激动人心的时刻。我们正在从拨号上网转向宽带，越来越多的人可以访问互联网，而且互联网越来越普及。

公司拥有网站是很常见的事情。我们见证了社交媒体和论坛的兴起。我们当时在论坛上。我们当时在网络论坛上与我们不认识的人交谈。非常令人兴奋。还有 IRC 频道。非常酷。如果你知道这是什么，我希望你服用你的补充剂。但是我……我正在服用。太……

这听起来很真实。哦，我的上帝。那么，如果你还记得这些事情，当时发生的事情是，随着越来越多的人获得设备并连接到互联网，这也意味着我们需要处理更多、更多的并发连接到 Web 服务器。想象一下 Facebook，对吧？

你不能只用几千人来运行一个社交媒体应用程序。那不会很有趣。当我提到几千人时，我说的是个位数的几千人，而不是几十万。因此，随着我们的规模扩大，并且互联网上出现了更多互动和多连接的情况，我们遇到了一个问题，即传统的基于线程的代理

正在苦苦挣扎。那么，什么是基于线程的代理？这意味着你每个线程只有一个连接。想象一下，你去了一家餐馆，你正在点餐。所以你进来，你得到一个服务员为你点餐。你点你的太妃糖或任何你喜欢的食物。也许你会找到你喜欢的太妃糖菜肴。

在那时，服务员不是在你等待食物烹饪的时候四处为其他桌子服务，而是会站在你的桌子旁，等待你的食物准备好，然后回来，回到厨房，拿到你的食物，并在准备好后把它送到你面前。所以服务员在你食物烹饪的整个时间里都会很忙。

但是当互联网爆炸式增长时，我们转向了另一个方向，有一个被称为 C10K 问题的问题，即处理 10,000 个并发连接。随着互联网的增长，这个问题只会继续扩大，对吧？这个问题不仅仅局限于 10,000 个并发连接，而是随着互联网的增长和用户数量的增加而不断增长。但那是这个问题的开始。

然后我们得到了实际上不必再站在桌子旁等待你的食物准备好的服务员。就像你不用坐在那里等待食物一样，

桌子准备好，服务员必须和你一起站在那里。但是后来我们得到了一个更好的模型，服务员可以将订单输入系统，然后去服务其他桌子。即使你的服务员很忙，也有一名送餐员可以在食物准备好后送达你的食物，因为他们知道你点了什么以及你的桌子在哪里，因为有一个系统。这就是转向事件驱动代理的过程。

所以现在我们可以收到订单了。这就是事件。订单来了，请求来了，我们把它送到厨房。这是你要到达的后端目标服务器。他们正在处理它，烹饪，烹饪，烹饪。然后你共享线程。许多连接可以共享线程，不同的工作人员可以接收和传递响应。你不需要你的特定服务员。

所以那是当时发生的一件很酷的事情。当我们开始，然后之后会发生什么？所以它们很酷。我们解决了连接问题。我们可以处理大量连接。那真是令人兴奋，对吧？没有人必须坐在那里等待。好吧，我们仍然必须等待，但服务员不必等待。然后发生的事情是，

这是分解我们所有应用程序的过程。这发生在大约 2010 年代初期。这种运动真正开始于大约 2015 年。那就是，我们过去拥有大型单体架构。

在软件工程中，单体架构究竟是什么？我喜欢把它想象成，想象一下你有一个大盒子，构成你软件的所有小组件都在这个盒子里。所以你的登录方式在这个盒子里。它很小，也许你可以把它想象成一个你塞进盒子里的泰迪熊。然后你还有一个装满发圈的盒子，盒子里有很多小功能。你把所有东西都扔进一个大盒子里。

这些大盒子存在的问题是，随着用户数量的增加，我们需要开始水平扩展。这就是我们进入云工程和水平扩展领域的地方。但是想象一下

在这个大盒子里，有很多不同的功能，从查看图像到登录，如果你考虑社交媒体部分，比如加载你的信息流，比如获取来自联系人、连接或朋友的所有帖子并显示它们。这是这个大盒子的一项功能，但这个盒子做了很多事情，并且

我们想，哦，如果我们要水平扩展，并且用户越来越多，这将变得越来越昂贵。所以扩展这个大盒子，一遍又一遍地克隆这个大盒子，开始变得计算成本很高，因为我们需要为这个盒子保留如此多的内存。而且有很多浪费。是的。是的。所以我们想，好吧，如果我们把泰迪熊从盒子里拿出来，而是

克隆整个盒子。我们只克隆我们放在盒子里的泰迪熊，对吧？所以现在我们可以有

这就是我们开始将盒子分解成更小的盒子，所以泰迪熊现在有了自己的盒子，它不必与你扔进去的其他垃圾放在同一个大盒子里，它现在有了自己的盒子，而且是一个小得多的盒子，所以现在我们可以更有效地利用资源进行扩展，这就是推动我们转向微服务的动力，我们从装满许多东西的大型单体架构盒子

变成了许多较小的盒子，每个盒子里只有一两件物品，可以一起扩展。所以它变得更有效地利用资源了。但是当我们开始拆分这些盒子时，我们当然遇到了网络问题。嗯哼。

因为当我们拥有单体架构时，从网络和代理的角度来看，一切都非常简单。所以是的，我们解决了对代理的多个连接。干得好，大家。我们做到了。但是现在，好吧，我们要把流量发送到哪里？所以现在我们有了一个新问题，因为当我们试图使我们的所有系统更有效地利用资源，并且我们正在扩展所有这些服务时，我们遇到了一个令人着迷的问题。等等。

东西在移动，它们现在位于不同的地址。随着你的扩展和拥有更多的泰迪熊盒子，泰迪熊盒子也在四处移动，因为有人想出了一个名为 Kubernetes 的好主意，你真的知道 Kubernetes 是做什么的吗？它真正做的事情是将你的泰迪熊盒子和其他盒子在服务器上移动，就像实际的计算机硬件一样。

在 Kubernetes 中它们被称为节点，但它真正做的事情是玩盒子俄罗斯方块。Kubernetes 真正擅长的是这个。它只是将这些盒子堆叠起来，以最大限度地提高节点上资源利用率的效率。所以现在你可能会四处移动你的泰迪熊，因为它感觉好像它更适合放在那里，因为，是的，Kubernetes 只是在玩计算资源的盒子俄罗斯方块。

并将它们放入。所以，好吧，现在东西在四处移动。所以网络工程师们正在抓狂。他们想，我们无法跟上所有这些四处移动和更改地址的情况。这就是，这也是变得有趣的地方，因为我们现在不仅需要处理多个连接。现在我们必须能够动态且快速地更新代理指向的位置。

从逻辑角度来看，来自你的流量。哦，你想访问泰迪熊 API？好的。这些都是提供泰迪熊 API 的所有位置。现在我们必须。所以这再次是一个巨大的转变，改变了我们处理代理的方式。因为直到这一点，

像 NGINX 这样的代理是静态配置的。当你的情况发生变化时，它们不会动态更新。所以那时我们看到这实际上是推动引入像 Envoy Proxy 这样的代理的原因，它可以动态重新加载配置，因此它根本不需要重新启动。所以当你的目标四处移动时，你的泰迪熊在不同的盒子里四处移动时，

Envoy Proxy 不需要重新启动。它只是被动态更新。现在我说 Envoy Proxy 确实是为此而创建的。它是在分解事物时代创建的。

所以现在我们退后一步。然后在这个微服务时代也很酷。当我们开始优化时，我们想要进行大量的少量请求，它们很轻量级，而且很快。这些小型服务就像我们现在的泰迪熊服务一样。顺便说一句，我脑子里想象着这只可爱粉红色的泰迪熊。

这只泰迪熊服务必须非常快，而且必须非常轻量级，因为如果你还想进行非常好的水平扩展，我们需要启动速度快的东西，响应。我的意思是，如果你可以构建一个真正独立且经过深思熟虑的服务，那么响应速度快会随之而来。但是……

所以我们现在优化了我们在微服务时代对网络的思考方式，使其变得更快。该过程本身应该在个位数毫秒内响应，对吧？不应该花费更长时间。现在记住这一点，因为生成式 AI 发生了什么，生成式 AI，就像一项服务，一项模型服务，

如果它在 100 毫秒内返回响应，则速度很快。所以，如果你认为泰迪熊 API 服务在自身内部的响应时间在一到两毫秒或五毫秒内，也许吧，但我们谈论的是任何从慢一百倍到慢十倍，比如在 10 到 100 倍之间，当我们查看时，速度最快

例如 LLM 服务。时间……不，我们不是在谈论网络延迟。我们只是在谈论该过程本身的响应时间。所以从第一个字节开始，它的响应速度要慢得多。然后我们还有其他有趣的东西。我们讨论第一个字节，到第一个字节的时间，因为 LLM 内容也往往是流式传输的。然后我们真正关注的是到第一个字节的时间。

那是我听过的最好的“像我五岁一样解释”的软件工程演变描述。太棒了。从餐馆的比喻到泰迪熊，再到 Kubernetes 只是俄罗斯方块。太棒了。我喜欢其中的每一小部分。所以在当今世界，一切都是 API，我们的微服务。是的。

我们所处的范式。一件令人着迷的事情是，好吧，这些模型有点慢，但它们很大，对吧？是的。这也有点不同。我认为你提到过我们一直在构建超小型、超快速的负载和 API。现在我们正在关注

非常大且非常慢的事物。是的，所以这也很有趣，即负载，这是一个本身就非常有趣的话题，比如如何在你的计算中管理 LLM 负载。我认为还有一个非常有趣的方面，人们正在关注它们可以有多小？

因为同样，我们非常倾向于如何使事物更小且更具可扩展性。关于如何甚至可以在你的网络边缘堆栈中运行非常轻量级的模型，有一些非常有趣的想法。对于那些可能不知道的人来说，在互联网世界中，

我们不仅要处理大量连接，我们还有内容分发网络在互联网上，所以当你访问一个网站并且上面有图像时，想象一下你只是去 Facebook，在 Facebook 或 Instagram 上有很多照片，每次你加载你的手机并且你在 Instagram 上查看照片时

当我查看美国 Instagram 上的照片时，这些照片很可能通过内容分发网络系统缓存在边缘。而当我母亲在瑞典的家乡，因为我来自瑞典，当她打开 Instagram 并查看照片时，它们不太可能来自美国或德国的某个数据中心。

很多照片都来自瑞典附近的内容分发网络，这样才能给人一种快速交付的感觉。所以有很多有趣的想法，比如我们如何将至少轻量级的生成式 AI 服务更靠近这些边缘，更靠近人们，这样事情就会更快。但我对此并不是专家。我只是知道很多人都在考虑

这些实际工作负载可以有多小？你如何才能更有效地将它们更靠近人们？即使人们在谈论你实际上甚至可以在客户端设备上运行什么？是的，完全正确。以及你如何通过苹果的智能功能看到这一点，对吧？是的。是的。所有……

我们将在你自己的设备上执行的简单查询，然后如果你需要更多，我们将把它带到云端，它将完成，但它将完全是私有的，在我们自己的云中，是的，而且……是的，我没有……我认为我最喜欢的问题是请求和响应的大小已经变得多么大，实际的网络流量越来越重，我想在那里有趣的问题是，现在网络流量会发生什么

是的。首先，我们真的在优化小型请求。顺便说一句，许多网关都有请求和响应大小限制，特别是如果你想要能够检查请求或响应正文以及请求的实际内容。你为什么要这样做？出于安全原因？是的，特别是出于安全原因。在大型语言模型的世界中，人们非常有兴趣检查请求和响应内容，以保护信息不被泄露，保护你的，保护，嗯，

防止信息进入，比如恶意信息进入你的系统。但这在标准 Web 应用程序防火墙挑战中非常常见。人们想要做的另一件有趣的事情是，随着流量的进入。想象一下，你正在发出 LLM 请求，一个查询。所以你有一个应用程序开发人员，他喜欢，我将构建一个很酷的

人们可以写很酷的东西进去。但是构建应用程序的人不是 LLM 专家。他们想，我想要这个很酷的东西。然后想象一下，他们想，我只是想连接一个简单的 LLM API。我不关心选择模型或服务提供商。那不是我的专业领域。想象一下，开发人员只想向 API 发送 LLM 请求。

那么，为什么有人想要检查这个请求的实际内容呢？所以我看到人们在做一些非常有趣的事情，比如 SIM mat，比如字面意思上使用轻量级 LLM 来根据请求选择模型。为了能够对哪种模型最适合这种类型的请求进行分析，你需要访问正文才能做出这个决定。否则，

你不能，对吧？你需要能够访问正文。所以这显然取决于这个正文有多大，你从哪里开始遇到问题。但是

你不能假设每个人都会很小，对吧？拥有允许对请求正文更不可预测的大小执行此操作的架构和基础设施，然后你的响应正文能够，这可能会变得非常复杂，尤其是在流式传输中，你将如何尝试保护它。但是是的，我发现它非常吸引人。所以这就是关于

网络流量如何以不同的方式形成的一个问题，因为它更大，请求和响应都更大。而且我们正在处理的 API 非常开放。它们不是我们传统的微服务 API。当我称它们为旧的时，这听起来很悲伤，因为它们也相当新。但我认为我们现在可以称它们为旧的了，因为它们非常注重确定性，具有非常明确的目标

这种类型的请求总是需要 X 毫秒。你希望对此非常清楚。最慢的一个将是 50 毫秒，例如，然后你也许能够做一组更快的，但有一个非常明确的想法。而在 LLM 的世界中，这是非常不可预测的。如果你去，然后你超越 LLM，你会……

图像的推理模型，它变得更加疯狂。我们开始处理更大数量的数据。我们将进入图像，然后你可以进入视频。现在我们正在处理更大规模的数据。所以 LLM，即使 LLM 正在推动我们，想象一下我们将使用不仅仅是技术的媒体做什么。是的，以及我们需要为数据构建什么样的基础设施

我们都想要的未来，你听到……

互联网上的 AI 影响者谈论如何，哦，好吧，我们只是不再制作电影了。它们将为我们和我们个人的愿望以及我们根据提示或其他内容寻找的东西而制作。如果我们确实想要一个世界，在这个世界中，将会有很多这些较重的文件被共享或从基础模型中进行更重的创作，

而且这更常见。我们需要什么样的基础设施才能做到这一点？因为感觉我们在过去 15 年里一直在朝着一个方向前进。我们一直在努力优化这种快速轻便的方式。是的。但是现在我们需要稍微向右转一下。是的。是的。

并以不同的方式思考我们如何持有，我们如何处理长时间运行的连接，长时间打开的连接，因为当你查看我们使用流式传输所做的事情时，例如当你使用 Netflix 并流式传输视频时，当你登录 Netflix 并连接并流式传输时

当 Netflix 将其媒体流式传输到你的电视或设备时，他们根本不需要检查输出。因此，你可以绕过很多不需要担心的事情，当你查看 LLM 或大型视觉模型的输出时，你会看到这些事情。

你实际上想在将其提供给用户之前检查 alpha，这与你在互联网上流式传输《吉尔莫女孩》时看到的不同，对吧？他们不需要检查《吉尔莫女孩》剧集是否真的是它本身，对吧？所以，因为有一次我想，嗯，埃里卡，我对自己说，这个流式传输问题以及大规模快速地做到这一点，已经被解决了，不是吗？所以我想，

好吧，这在你有九个受控……

你发送的数据是已知和受控的，你知道它是什么，你不担心它会发送出你不知道是什么的东西，对吧？所以这种流式传输与我们在查看生成式 AI 服务的流式传输响应时看到的非常不同，因为安全层和对我们发送内容的控制现在变得不同了，我当时正在考虑

我们如何转向一个支持更多生成式 AI 用例的互联网。从网络角度来看，从网关角度来看，这看起来像什么？我知道你们都在使用 Envoy AI 网关做大量工作。我想这不仅仅是，嘿，让我们把一个很棒的网关添加到组合中，这就能解决我们所有的问题，对吧？是的。

是的，它不能。因为即使是现有的基础，例如，如果你查看 Envoy Proxy 本身的运行方式，我们必须对 Envoy Proxy 本身进行增强。然后我们启动了 Envoy Air Gateway 项目，以进一步扩展……

代理功能和控制平面。我稍后会解释一下这是什么。但是如果我们退后一步，看看网关世界中发生了什么，我认为非常吸引人的是，随着生成式 AI 的兴起，出现了许多 Python 网关，Python 编写的网关。因为这看起来很自然，对吧？就像，哦，我们用 Python 编写了所有这些其他很酷的东西，而且许多来自机器学习和……

AI 世界的人对 Python 非常熟悉。如果你想做一些很酷的事情，比如对传入请求进行自动模型选择，你必须在 Python 中这样做，因为现在你又回到了机器学习和 AI 领域。所以它变成了一个奇怪的事情，比如我们如何做我们想做的聪明的事情，但又不会遇到每个桌子一个服务员的问题？所以因为……

Python 网关从根本上遇到了问题，这与编写这些 Python 网关的人有多聪明无关，不是他们的错。问题又回到了 Python 语言的基础上，在那里实际上只有一个解释器，因为 Python 是一种解释型语言。它不是编译型语言。因此，你有一个解释 Python 的过程，那就是

所以当我们进入线程时，我们现在遇到了每个桌子一个服务员的问题。因此，即使你尝试，你可以开始尝试巧妙地模拟

被称为事件驱动架构的东西。不要将其与 Kafka 混淆。但是当你查看代理的事件驱动架构时，它是你可以让一个服务员为多个桌子服务，并将东西放入系统。这就像餐馆内、代理内的这个小事件通知。所以……

你可以用 Python 模拟很多这样的事情，但你最终会遇到问题和限制。好吧，我们可以称它们为问题。问题不是。Python 本身不是问题。只是你会因为 Python 语言的限制而遇到问题，如果你想处理大量连接的话。

所以这就是我们遇到问题的地方。我们如何解决这个问题？我们如何结合多，你知道，服务员可以为多个桌子服务的餐馆和 Python 可以做的聪明的事情？然后我们开始，这就是我们最终倾向于使用 Python 的原因。

Envoy 代理，它从根本上可以处理，这非常像服务员可以为许多桌子服务的餐馆，对吧？Envoy 代理真正擅长的是这个，并且具有这种事件驱动架构。Envoy 代理与 Envoy 网关、Envoy AI 网关一起，允许我们创建一个扩展机制，我们可以通过它引入很酷的逻辑，比如用 Python 编写的自动模型选择，

并且仍然拥有，你知道，一个服务员为多个桌子服务的代理，然后能够，只有当我们需要时，才能从 Python 扩展中获取特殊订单来做聪明的事情。只有当我们需要时，只有当我们想要时。这就是获得网络优势以及能够引入一些聪明的东西的原因，这就是它如何将这些世界结合在一起的原因，但我们确实会看到，我仍然相信我们会开始看到一些响应时间方面的挑战，比如到第一个字节的时间和完整的流式传输，我只是想象这将继续成为一种需求，我们将不得不开始进一步研究我们代理的内部结构

如果我们不继续在这个领域发展，我会感到惊讶。你知道它让我想起了很多构建 Streamlit 应用程序的人。

就像，是的，我构建了这个 Streamlit 应用，因为我只是用 Python 编程，而且我喜欢 Python。Streamlit 可能不是你前端的最佳选择，但它能让你有所进展。然后，当你想要真正地将其产品化，使其变得花哨，并完成所有前端工作时，你可以转向 React 或其他框架。你可以启动你的 Vercel 任务或 Next.js，然后你实际上就能制作出一些……

对终端用户友好或赏心悦目，并具有一定设计的东西。但有时你只是想，好吧，酷。Streamlit 让我得到了这个 MVP，这就是我想要的。在某种程度上，这几乎就像这里的相似之处在于，已经用 Python 制作了代理。它们带你走了一段……

路，你可以验证想法，并且可以看到它是否有效。然后在某个时候，你可能会对自己说，好吧，现在我

想要将它产品化，而 Python 不是最好的方法。是的。我认为这很有趣，因为如果你只有少量用户，只是为你的公司内部构建一些东西，那么你可能可以用你的 Python 网关做得很好。比如你的公司内部只有几百个用户。你可能没问题。但是如果你有……

即使在内部，如果你有很多并发连接，并且你开始需要处理这个问题，你不能为每个桌子都安排一个服务员站在那里等待，所以你必须弄清楚如何才能更好地利用所有连接，所以这很有趣，正如我们讨论过的，21 世纪初发生了什么，

一万个并发连接问题，随着我们向大众市场引入更多 Gen-AI 功能，Python 网关最终遇到了这个问题。好消息是并发连接问题已经得到解决。所以它说，我们如何将这些东西结合起来才能获得核心功能？但至少好消息是并发连接问题已经解决了。嗯哼。

所以你这里几乎谈到了两个层面，一个是流量和网络流量，另一个是理解请求并能够利用一些很酷的东西，比如，哦，这个请求可能不需要最大的模型。所以让我们将其路由到较小的模型。也许它是开源的，我们自己运行它。也许它只是最小的 OpenAI 模型，无论是什么。所以……

你必须参与的级别是不同的，对吧？或者至少在我看来，我将整个网络级别与实际的 LLM 调用以及 API 中发生的事情区分开来。是的。但是你必须在将其发送到 LLM 服务之前完成一些智能操作。这就是令人兴奋的部分，比如将 Envoy 代理与……

Python 服务、过滤器、Python 过滤器结合起来，以便能够进行智能操作来做出这些草拟决策。你认为这只是在拖延时间吗？如果你在任何步骤中都将其传递给 Python，你仍然会遇到问题

吗？好问题。那时我们不会以同样的方式遇到连接问题，因为现在我们可以拥有专用的 Python 服务，我们可以独立于代理对其进行扩展。

所以现在我们不再处理客户端到代理或代理到上游连接。现在我们有一个代理，它正在向另一个服务发出调用。比如一个 Python 服务。那个服务，你知道我们之前谈论 Kubernetes 中的盒子吗？我们可以根据需求扩展和缩减这个小型 Python 服务盒子。所以这个东西现在可以自行水平和弹性扩展。它不会有任何……

不会有任何嘈杂的邻居问题，因为它们不会互相阻塞。只有当我们在餐厅的服务员数量有限时，我们才会遇到服务员问题。

与一个请求响应生命周期相关联。因为现在我们只需要访问这个小型 Python 服务。完成后，它就会消失。而且我们也没有因为 Envoy 架构的工作方式而阻塞其他请求。在我们咨询这个 Python 进程以了解该做什么时，我们没有阻塞其他请求。我明白了，然后……

就像我们打电话问，嘿，小 Python 服务，你对这个请求有什么看法？我现在要挂断了。当你有了答案，我会接起电话，我们将继续这段旅程。是的。瓶颈可能只发生在代理区域。一旦它通过代理区域，就不会发生。

然后它就像自由放养，你可以将手指伸进各种东西。它说 Envoy 中的请求生命周期很重要，以及如何包含外部过滤器，以便基本上可以进行事件驱动。它谈论的是你基本上将东西放入 Envoy 的中央系统，然后知道该做什么。好的。所以它是……

顺便说一句，我希望这是一个过于简化的解释。所以真正深入了解 Envoy 代理的人可能会说，哦，埃里卡，这并不完全准确。但如果你想要一万英尺的视角，我希望这足够了。如果你真的想深入研究它，你可以花很长时间。

学习它的内部结构。但好消息是它在处理资源和管理连接方面非常巧妙。这真的很酷。

但是 Envoy 代理很难配置。所以我要稍微偏离一下主题，但这是一个重要的主题，也是 Envoy AI Gateway 非常有趣的原因，因为 Envoy AI Gateway 在帮助你利用 Envoy 代理处理流量方面做了两件关键的事情。每次你有一个代理时，你都会遇到一个双面问题。

你不仅仅需要配置这个代理，你还希望能够以一种即使它可以扩展和缩减的方式来配置它。所以你有许多代理，所以一个代理。你有一个控制平面，可以有效且资源高效地配置这个代理集群。因此，Envoy AI Gateway 为你带来了这个控制平面，它扩展了 Envoy Gateway 控制平面。

然后它真的很有趣。我知道你没有时间花在这个上面，但是这个控制平面在配置 WebProxy 方面非常高效，并且可以帮助你在所有正在运行的代理之间传播配置。然后我们添加到 Envoy AI Gateway 中的另一部分是一个外部进程，它有助于配置

特定的 Gen AI 挑战，例如转换请求。我们所做的一件事是拥有一个统一的 API，这样如果我是一个应用程序开发人员，我不必学习所有这些不同的接口来连接到不同的提供商。因为我们不必将这种认知负担强加给想要构建酷炫应用程序的人，让他们构建酷炫的应用程序。

然后我们可以担心管道。是的。你需要一个才能利用另一个吗？我想，你需要 Envoy 才能利用 Envoy AI Gateway 吗？当你安装 Envoy AI Gateway 时，它实际上会安装 Envoy Gateway，这会为你提供 Envoy 代理和 Envoy Gateway 控制平面。所以当你完成安装步骤时，你实际上首先安装 Envoy Gateway。它将在 Kubernetes 集群上运行。

顺便说一句，我称之为网关集群，如果你看过我博客文章中的任何图表，可以参考一下。然后你部署了它。然后有一个 Helm 图表，你只需安装单向 AI 网关即可。这将部署一个外部进程和控制平面的扩展。

因此，它扩展了 Envoy Gateway 和 Envoy Proxy 的功能。所以你实际上不必知道你正在部署所有这些东西，但如果你部署它，就会发生这种情况。它都是 Envoy CNCF 项目的一部分。它不是一个集合。它是该生态系统的一部分。是的。

它本身并不是一个单独的实体。它是 Envoy CNCF 生态系统的一部分。你有没有注意到很多 AI 或 ML 工程师开始参与 Envoy AI Gateway 项目并提交 PR？你会关注这类事情吗？因为我想知道有多少……

或者这个范围落到了 ML 工程师、AI 工程师身上，或者这些人是否只是将其交给 SRE 和 DevOps 人员？这是一个好问题。在我们真正需要那些对机器学习和 Gen AI 有很好理解的人的地方，它真的变成了，看看这些聪明人

Python，也许是基于 Python 的扩展。如果有人有关于如何进行语义路由以能够决定模型的想法，而不是在 Python 中进行，请告诉我。非常有趣。这超出了我的专业领域。所以如果有人可以用 Rust 编写它，请告诉我。那将是惊人的。

但是是的，我们看到有人进来，说，嘿，让我向你展示这个 Python 扩展以及它如何融入 Envoy AI Gateway。智能的东西，这绝对超出了我的专业领域。我发现它非常迷人和有趣。所以如果人们有这方面的专业知识，我很乐意让人们来帮忙。

将这些扩展构建到 Envoy AI Gateway 中，并将这些功能带给社区。因为从根本上说，当我们查看 Envoy 项目中的 Envoy Gateway 计划时，Envoy AI Gateway 计划实际上是关于

我们现在面临的问题以及这种流量如何变化和形成，这不是单一公司的问题，也不是单一用户的问题。我们都在遇到这个问题。因此，在开源中共同努力解决这些问题，并共同维护它，我认为这非常令人兴奋，并且看到供应商和用户都进入这个领域并进行合作。

是的，真正地分享知识，正如你所说，比如将网络知识与我们拥有的 LLM 功能的知识分享，我们如何才能真正地将一些功能带入网关以使其更智能，以及真正了解他们如何运行 LLM 工作负载的挑战的人，我认为这是一个非常非常有趣的组合。在过去的一年中，我学到了很多东西。

六、七、八个月，所以是从与人们合作中学习的。所以这真的很酷很令人兴奋。所以我要说的是，你在这里谈论的内容，已经被社区 100% 验证了，甚至

我知道它已被验证的方式是，当我们进行生产中的 AI 调查时，我们尝试在每次进行大型会议或几乎每个季度一次时进行。我们询问人们，你们的世界发生了什么，最大的挑战是什么？你们现在正在努力解决什么问题？很多人写信说，最难的事情是，

我们使用软件和模型的方式是新的，几乎就像你刚才谈到的那样，这些模型非常庞大。因此，处理它们的方式大相径庭，并且使一切都变得更加复杂。最重要的是，你实际上找不到任何地方可以求助，那里有……

明确的设计模式和已经找到解决方法并与更广泛的开发者社区分享这些信息的人。因此，我发现 A，你们在公开场合工作，这绝对令人难以置信。开源项目试图这样做，这很棒。但是 B，你已经考虑过这个想法了，好的，模型……就像模型的流量。流量是如此不同。它们是如此不同。它们带来了很多……

其他必须处理软件工程的方式，不仅仅是我们一直在关注并试图实现的快速轻量级方式，而是现在有一个稍微重一点的方式。现在我们遇到了这些超时问题，或者模型不适合。并且存在有效负载限制，所有这些，比如这些限制或这些问题，人们正在遇到这些问题，因为……

你试图将这种新的范例放到旧的轨道上，你会看到哪里有一些裂缝。是的，就像我一样，在我的实际工作中，在我的日常工作中，我是一名社区倡导者，这实际上意味着我做的很多事情是了解技术社区中正在发生的事情。

所以我工作在一家名为 Tetrate 的公司，我们非常关注 Envoy 项目，例如

让工程师和像我这样的人在那里进行开源开发。但作为一名社区倡导者，我做的很多事情就像与人交谈，倾听真正发生的事情以及他们遇到的挑战，并在我们展望如何构建事物时为社区倡导。

所以，我认为可能被误解为社区倡导者的是，我正在为社区倡导解决方案。不，不，不。

我正在为社区倡导，以便正在构建的解决方案能够满足社区的需求，甚至有时可能是社区尚未意识到自己已经拥有的需求。也许他们遇到了有趣的问题。我听说过人们说他们遇到了 Python 网关的挑战吗？例如，为什么网关本身似乎增加了延迟？那么，让我们谈谈事件驱动的代理。但是

这就是有趣的地方，你如何倡导和理解社区的挑战，以便正在构建的解决方案能够满足这些需求。

所以是的，我发现这对我来说非常有趣。所以我很高兴听到人们遇到的问题。所以听到你在你的社区中看到的东西以及为现实世界中人们的真实需求进行倡导，这真的令人兴奋。所以我们不构建科学项目。我认为这就是令人兴奋的地方。你知道，你之前说过你这里有 Alexa，对吧？比如与 Alexa 和团队合作。

在开源中，真正地一起碰撞想法，真正地满足实际需求，我认为这非常有趣和美好。而且，你知道，我们不在同一家公司工作，但我们可以一起合作并推动解决方案。哦，这真的很有趣。我好奇的是，你是否觉得必须具备技术能力才能成为那种社区倡导者？

这是一个好问题。我非常擅长技术。我 12 岁就开始编程了，并且在网关领域工作了很多年。我从 2015 年、2016 年开始从事平台工程和网关领域。

当我们开始 2015 年时，当我们开始将这些单体分解成微服务时，网关的需求变得显而易见。所以我在那个领域工作，是的，从 2015 年开始。我当时在金融科技领域。我需要说实话，这个 Gen AI 和这种类型的技术，

我们现在看到的流量模式，我感觉真的得到了验证，因为肯定在 2015 年到至少 2023 年之间，

我处于一种人们说我正在处理的那些财务分析 API 非常开放，你可以说，哦，我有这个投资组合，我想分析它。但是分析包含 10 个美国股票的投资组合与分析包含 10,000 个资产的多资产、跨国投资组合之间存在很大的区别。

所以分析这些，即使你点击的是相同的 API 端点，我希望你能理解其中一个将非常快速且易于响应。而另一个将需要大量时间来处理，包括输入和输出，特别是输出，我们正在谈论非常大的输出，这些输出开始达到……

API 网关的限制，你知道我们谈论的响应正文限制吗？我们开始遇到这些问题，因为它们是如此大的响应，达到了许多网关的 10 兆字节限制。所以我当时想，多年来，我觉得人们告诉我，埃里卡，你的 API 做错了。显然，这些财务分析 API 是

你的设计有问题。问题在于此，而不是网关。老实说，我确实相信我们一定做错了什么，对吧？我们有这些 API……

响应时间和响应大小如此不可预测。但是 Gen AI 和 LLM API 出现了，我想，等等，我以前见过这个。一个 API，你可以输入一些东西，输出的东西会大相径庭。它可能很慢，它可能很大。现在每个人似乎都同意这确实是一个挑战。

但实际上，我们现在使用网关在 LLM 世界中处理和处理的许多事情实际上也使这些财务分析 API 受益。因此，我们看待限制使用的方式发生了变化，例如在 LLM 世界中，我们使用令牌配额。所以你可能允许在一个空间内使用 10,000 个令牌，

无论你喜欢什么时间范围，但是如果你想说一天或一周或一个月，然后你可以开始放置这些，但这些不是请求的数量。你可以只发出几个请求并达到你的配额，或者你可以发出大量的较小的请求，然后你将达到你的配额。所以这是不同的。所以我们实际上必须改变我们在 Envoy 代理中进行速率限制的方式，并且

像普通的速率限制和使用限制一样，能够允许这种更动态的测量使用方式。所以你不仅根据请求数量来衡量使用情况，还可以根据另一个数据点来衡量。在这种情况下，在 LLM 世界中，它将是令牌，例如单词令牌。这对我来说非常迷人。甚至我们衡量使用情况的可观察性

我们响应的速度有多快。所以如果你考虑一个 LLM，并且你正在流式传输响应并流式传输令牌，那么从性能的角度来看，你实际上感兴趣的是每秒响应令牌数。

因为那样你就知道它正在工作，事情正在发生，响应正在流式传输。如果你将其与我们在财务分析 API 中看到的一些挑战相关联，我们没有单词令牌，但我们非常关注第一个字节的时间。所以我们开始在响应中流式传输第一个字节

所以与其查看财务分析 API 中整个请求过程所需的时间，想象一下我们可以监控每秒字节数，因为这将告诉我们事情正在移动。它没有静止不动。所以类似于当我们流式传输 LLM 响应时，我们对每秒响应令牌数感兴趣一样，如果我们进行并行处理并查看财务分析 API，

仅仅改变我们思考性能和可观察性的方式在查看此基础设施以了解我们系统运行状况时也很重要。是的，你确实如此。我喜欢这个想法，嘿，性能指标几乎必须，你想尝试对它们更有创意。它让我想起了我们与在高通工作的克里希纳进行的一次谈话。

他当时谈到，有时当你将 AI 放到边缘设备上时，你想优化电池寿命。你可以做到这一点的方法是

流式传输较少的令牌，或者确保令牌不会以每秒 300 个令牌的速度流式传输，因为人们无法真正阅读每秒 300 个令牌。所以如果人们不会以那么快的速度阅读，为什么要以那么快的速度流式传输它们呢？如果这意味着更低的电池消耗，那么你可以以每秒 20 个令牌的速度流式传输，或者任何可能的值，任何合适的中间值。是的，绝对的。这是一个非常好的观点。所以是的，它们加起来。它们就像……

我认为在这个领域中，有很多事情是相关的，这令人着迷。就像，我通常不考虑电池时间，因为我在有……

电源的地方工作。它是从电源供电的，对吧？没有充电的电池。我们没有电池驱动的服务，对吧？但是是的，我确实认为，回到你的问题，你必须具备技术能力才能在这个领域为社区进行倡导吗？是的，我认为如果我没有我的

技术软件工程和软件工程经理领导背景，这将非常困难。有趣。我认为这将非常困难，因为我身处如此技术性的领域，对吧？它是如此深入的技术。

我相信如果没有在这个领域的经验，这将非常困难，因为有时我可以听到人们描述的问题。就像，哦，这个 Python 网关在网关本身为我的请求添加的延迟方面非常不可预测。酷。我明白了。

他们不一定能够表达他们遇到的挑战是他们餐厅的服务员用完了。因此，他们的请求正在外面等待可用的桌子和服务员。这就是为什么有时请求需要 100 毫秒，有时请求需要 700 毫秒的原因。他们可以解释他们观察到的问题，但你必须理解，好的，

好的，你使用的是 Python 网关吗？Python 语言的局限性是什么？这可能是你观察到的问题的实际根本原因。在这种情况下，能够为用户进行倡导。我需要了解问题的根源。

痛苦，然后倡导在行业中构建解决方案以满足他们的需求。希望这说得通。我认为如果你没有，这将非常困难。你经常会处理观察到挑战但无法看到机会以及他们观察到的挑战的原因的用户。这几乎就像你一部分是产品经理，一部分是

像客户成功或支持一样，并且一部分是社区或面向外部的。我不知道你如何对此进行分类。因此，考虑这些深刻的问题、深刻的技术问题或讨论是如何出现在你的办公桌上，你看到了它们，然后你意识到，哇，这里有一个模式。

也许这意味着我们应该尝试将其构建到产品中，以便我们可以使用此模式帮助这些用户

因为我不断看到它出现。所以让我们领先一步。让我们帮助创建一个功能或任何东西来帮助用户，这样他们就不必再遭受这个问题的困扰了。是的，我认为关于这一点，领先于问题，因为我过去从事平台工程，从事内部构建 API 平台、服务平台等工作。在我的旧角色中。而且……

通常挑战总是你需要在人们真正感到痛苦之前尝试构建事物。是的。因为当人们真正痛苦时，你就太晚了。能够看到有人看到将来会变得非常痛苦的事情的症状，

足够早，你可以解决它们，这样当人们出现时你就有了解决方案，但是真正好的事情是，幸运的是不幸的是，无论你如何看待它，有些人已经开始遇到这些问题了，但是如果你可以尽早为一小部分人解决这些问题，然后能够展示这一点，然后帮助

第二波采用者不必经历第一批先驱者必须经历的成长烦恼，但是是的，通常很难向更广泛的社区解释做某事的目的，因为他们可能会说

你谈论的这个问题，我没有。我们想，这对你来说太好了。太棒了。太棒了。我很高兴你没有。是的，提前告诉我。所以这是倡导社区的另一个棘手部分，因为有时你必须为社区中那些他们不觉得你需要为他们倡导的人进行倡导。他们想，好吧……

而且他们不需要知道我做什么，你知道，当我与人交谈时。紧闭的门。没错。但我确实认为，了解社区和行业的现状、他们的现状、我们认为痛苦开始被感受到还需要多长时间，这很重要。你的工作中一定很难的一件事是你在其上构建的不断变化的沙地，以及

我说这话是因为我的一个朋友弗洛里斯说，在他开始 LLM 热潮时。他做了很多临时性的工作来允许在他们的请求中使用更大的上下文窗口。

他在这方面花了大量时间。然后接下来你知道的是，上下文窗口变得非常大。所以他坐在办公桌前，想，该死，我在这上面花了这么多时间，我本可以再等三个月或六个月，它就会自己发生了。所以我在你生活的世界上思考，当你思考这些问题时，

你如何确保（如果有的话）你在处理正确的问题，并且你不会陷入这种情况：你过去六个月一直在努力解决的问题现在不再重要了，因为难题的另一部分发生了变化，并完全使其

过时了。我认为，当我开始寻找辅助和启用 Gen AI 流量的功能时，老实说，当有人第一次对我说 AI 网关时，我当时想，真的吗？就像它只是网络流量。

我当时想，真的吗？你在说什么？它只是网络流量。我们处理网络流量已经很久了。你有什么问题？就像这是某人，你知道，在一个网络组件上贴上 AI 标签。因为他们需要筹集一些资金。是的。我只是觉得，这太荒谬了。它只是，我甚至有过这样的时刻，我看着他们遇到的问题，比如，

请求和响应中的大型有效负载、不可预测的响应时间以及高计算利用率。我当时想，是的，我多年来一直有这个问题。我看着它，我当时想，是的，这不是 Gen AI 问题。我在金融科技领域已经很久了。恭喜你加入了这个行列。这是我最初的反应。我当时想，好吧，对你来说很有趣。欢迎来到这个充满问题的俱乐部。

但是，当我看到生成式AI领域遇到的问题时，让我真正兴奋的是，我已经经历了五年多的时间。我想，如果我已经经历了五年，每个人都告诉我我遇到的问题是我自己造成的。现在我们有了这个问题。遇到这个问题的人数刚刚增加。

这让我觉得，好吧，即使我们可以推动创新，由于生成式AI的爆炸式增长，这些功能不仅仅对生成式AI有利。它们的好处超越了生成式AI。因此，我目前并不适合。这感觉像是我们处理网络的根本性问题。

流量连接以及请求和响应有效负载的处理。因此，在这个特定领域，我认为我们只是落后了。几年前我们就应该解决这个问题了。是的，我想很多精力、进步和资金都投入到模型层和应用层，但并非一定投入到

螺母和螺栓以及管道和管路层。这就像在你达到规模并意识到这一点时，这有点像事后才想到的事情一样

哦，是的，我们想让它达到生产级别。我们该如何做到呢？你开始考虑这个问题。希望你不是在产品已经发布并收到请求后才考虑这个问题。希望你在那之前就考虑到了这个问题。是的，就像人们完成POC研讨会后，他们如何将其工业化一样？正是如此……

我认为人们应该从他们的POC研讨会开始，对吧？他们应该尝试一下，看看有什么可能。我认为人们不应该在需要扩展系统之前就扩展它们。那是……就像，如果你有一个坏主意怎么办？把它留在POC研讨会里。不要拿出来。它可以留在那里。在架子上，你可以说，我曾经做过这个。这很可爱。没有人需要它。没关系。所以……

不要过早扩展，但现在至少我觉得已经有足够多的人需要扩展了。我真的很兴奋，我们不仅将这些功能引入Envoy AI Gateway，而且真正实现了不仅仅是请求数量的使用限制的概念。此功能现在可在Envoy Gateway中使用。

您不需要使用Envoy AI Gateway来利用它。从1.3版本开始，这已成为Envoy Gateway的一部分。因此，如果您有一个财务分析API，您现在实际上可以，您不必去安装Envoy AI Gateway来获得更智能的，好吧，“智能”这个词用得不对。“动态”才是正确的词。更动态的方式来强制执行超出请求数量的使用限制。