Kubernetes, AI Gateways, and the Future of MLOps // Alexa Griffith // #294
51:43 Share

我的名字是Alexa Griffith。我的职位是彭博社的高级软件工程师。我喜欢全脂牛奶，所以我只喝加牛奶的普通咖啡。我是一个野蛮人。我很奇怪。欢迎回到MLOps社区播客。我是你的主持人Demetrios。今天，这场对话中有一件让我念念不忘的大事，那就是Alexa提到

对她来说，拥有导师并在能够选择具有实际业务价值的问题的团队中工作是多么有用，以及这如何转化为她在职业生涯中参与大量开源项目的工作，因为他们能够适当地为需要

参与这些开源项目并将其与它将如何帮助她所在的公司联系起来。我喜欢听到这些。我喜欢和Alexa交谈。让我们直接进入正题。对于那些在Spotify或播客平台上收听节目的朋友们，我们今天有一首歌要送给你们，那就是……

为了配合日本主题，因为Alexa刚从那里回来，我想播放Air乐队的这首歌，它叫做《迷失在京都》。不，对不起，它叫做《独自在京都》。如果你没听过Air乐队，他们来自90年代，但实际上，他们很永恒。他们就是永恒的。

让我们来听听Alexa的这个播客。祝大家度过特别的一天。希望你们喜欢。

但是，告诉我关于日本的事情，因为我真的很想知道，你在那里滑雪了吗？是的，太棒了。太疯狂了。雪太多了，超过三米厚。我的意思是，那里的雪一直下个不停。我去了白马村，实际上就在东京郊外，但那里太棒了。我知道二世古也很受欢迎。

是的，这是一次很棒的旅行。我认为东京也非常好。我们也去了首尔。所以我四处转了转。我走了大约两周。所以这是一次漫长的旅行，但它太棒了。是的，我知道你刚回来，你还在享受一点时差，这总是很不错的。我发现了一个技巧，当我跨越大西洋去探望家人时

如果你穿压缩袜，血液就不会在你的脚里凝结。显然，通过保持血液流动，它以某种神奇的方式帮助对抗时差。哇，这太棒了。好的。是的，下次我一定会记住这一点。也许我的问题是我没有穿那些袜子。

你应该穿压缩袜。据说大量喝水也有很大帮助。然后尽快在你的所在地晒太阳也有帮助。这是一个好建议。是的，你已经在科技行业工作了一段时间了。我认为你有一个非常酷的故事。实际上，我想从你写了很多关于你的科技之旅开始。一个……

你写过的事情是在过去的工作中使用Airflow，对吧？以及使用Kubernetes和Airflow。我一直对至今为止，你记得在使用Airflow时最大的痛苦是什么？

你这么问很有趣，因为已经过去一段时间了。我们使用Airflow，就像我们自己运行它，自己构建它，自己部署它一样。我们的数据科学家正在用它构建许多DAG。我记得我们也为数据科学家构建了一些管道。我当时在一个数据科学基础设施团队。所以这是我们拥有的一部分。我的第一个任务是

让日志显示在Airflow中，以便人们可以查看其作业的日志。基本上，我们只是将日志写入数据库。然后我从数据库中提取数据，并在任务运行时将其显示在屏幕上。所以我认为我们改进了一些操作方面的事情。Airflow本身也改进了一些事情。我们当时也有它的一个分支。我最记得的是

它会经常崩溃。它无法处理同时运行和跨越的大量工作负载。正如我所说，这是我刚开始工作的时候，所以也许存在资源问题，或者调整资源也是一个问题，但我认为我们的调度程序在我们尝试执行的操作中经常会崩溃，这也引出了一个问题，比如也许有更好的工具来处理，你知道的，

我们试图执行的大量扇出也是如此，但我记得当时这是一个问题。对我来说，一开始写关于Airflow的文章真的很好，因为正如你提到的，我有一个。

我会说非典型的，但我感觉现在科技界很多人也有些非典型。我没有计算机科学学位。我有一个化学学位。我实际上学习的是计算化学。我在计算化学方面做过研究。所以这就是……

我如何进入软件工程的世界，以及学习和消化这些信息的一种方式。我开始写关于它的事情，这就是它如何产生的。我的第一个项目是Airflow，这真的很好，因为当时，很多人也对其他人如何使用Airflow以及我们遇到的问题感兴趣，如何最好地设置DAG，如何构建它并充分利用它。所以，

这真的很好。对我来说这是一个非常好的机会，它导致了很多其他的事情。是的，你这么说很有趣，哦，也许这不是正确的工具。但在你使用它的时候，我认为它……

当时是唯一可用的工具。而且现在你看到的这种成熟度并不存在。现在有各种各样的管道工具，无论你是做ML管道还是数据管道，你都有更多选择。但仅仅四年前，你甚至没有这些选择。这就是促使的。我认为像你这样很多人都有过Airflow崩溃或无法按他们想要的方式工作的经历。然后他们去了

他们因此创办了自己的公司。所以你现在可以看到管道领域已经成熟了。

这是千真万确的。我的意思是，我记得在某个时候我们开始讨论，好吧，现在我们应该看看Kubeflow吗，因为Kubeflow变得流行起来？我们应该看看Argo工作流吗？我的意思是，我们当时使用了Argo CD，它也是一个很棒的工具。我的意思是，使用起来非常棒。我记得当他们实现Argo CD时，我感觉，哇，这太棒了，我们可以以如此出色的方式管理我们的部署并查看我们所有的资源。所以是的，Argo非常成功，现在仍然如此。

但是是的，我认为我们开始考虑我们已经投资的其他事情。我现在不知道他们是否还在使用它。也许他们已经改变了。但是是的，这是对的。我认为我到现在已经在科技行业工作了大约五年了。是的，即将满五六年了。谁来数呢？但我认为有时很容易忘记变化有多大。所以我现在在想，现在有其他的工作流工具。但是你说的没错。是的。

它们不像现在这样成熟，以及变化的速度有多快。这太疯狂了。你玩过Argo工作流吗？就我个人而言，没有。我们有一个团队管理Argo工作流，但我有一些工作，它非常有用。据我了解，它非常易于使用，类似于Argo CD。据我了解，它具有类似的布局。但就我个人而言，我没有太多使用它。是的，因为我一直想知道

那里不同的管道工具，归根结底，你有了这些DAG。我本周早些时候刚与一个人进行了一次谈话，他谈到基本上所有东西都是一个图，所有东西都是一种形式的工作流，无论是技术工作流、业务流程工作流还是流程图。你可以看看。他提到通常……

业务流程图比技术DAG复杂得多，因为他就像，是的，他的名字是Alex，Alex Malowski。他说一个……

技术DAG，一般来说，你会得到三到四个步骤。就像，我希望它这样做，然后这样做，然后那样做。回到我为什么用Argo工作流提到这一点的最初想法，那就是你会有不同背景和需求的人带着他们的需求来到管道工具。

做事的方式和观点。我认为来自DevOps背景的人会倾向于使用Argo工作流。然后你有了

或者DAG和前缀以及世界上的法师。来自数据工程背景的人可以更好地理解或喜欢这些。然后你有了世界上的Kubeflows、Metaflows和Zen MLs。像ML工程师这样的人会更喜欢这些。所以你有了所有这些空间来使用你喜欢的管道工具。这完全是……

忘记了像无代码低代码管道工具这样的管道工具，让我们把它们从图中移除，但想到这一点以及每个背景如何很好地适应一种工具或你将进入的一个空间，这真是令人着迷

是的，这是千真万确的。我认为你在很多事情上都能看到这一点，尤其是在AI ML领域，你看到基础设施人员创建东西，然后AI ML工程师使用它。所以即使，你知道，我认为他们更喜欢或AI ML工程师更喜欢Python。通常情况下，基础设施工程师似乎更喜欢Go或YAML配置，以及你与API或工具交互方式的差异。当然。我见过很多次了。

你有没有发现你看到这两种角色之间的互动更好或更糟的方法？因为对于基础设施人员来说，这非常像一种固执己见的方面，而ML甚至数据科学家的观点也是如此。这几乎就像。

非常不同的观点、工作流程以及他们需要完成的工作。但我不知道你是否注意到一些有助于弥合这些不同角色之间差距的事情。我认为你说的完全正确。他们是我们的平台的用户。而且

但我们都是工程师，所以这是一个有趣的互动。我认为现在有很多工作要做。这并不总是那么容易，但是要将Kubernetes和那些东西抽象出来，什么是pod，什么是容器，什么是，你知道的，我的意思是，什么是虚拟服务？他们真的需要知道吗？并尽量从他们那里抽象出尽可能多的东西，我认为这似乎是开始

能够根据你在YAML规范中遇到的三种不同类型的错误清楚地告诉你，例如，如果出现错误，对于可能不太了解Kubernetes的部署人员来说，它实际上意味着什么？他们需要采取什么行动？因为他们应该采取一些行动，他们的服务出了问题，他们可以修复。尝试弥合这一差距是我们一直在努力的事情，我也觉得很有趣。

起初我的反应是，你是什么意思他们不需要了解Kubernetes？你知道，从我们这边来看，当然他们需要，他们有一个pod，他们正在运行它，他们有一个容器。但是我的意思是，你越来越多的看到它。总的来说，Kubernetes在其之上有很多抽象来构建所有这些工具。我的意思是，这就是KubeCon，一个大型Kubernetes会议。有很多，你知道的，大量的不同工具，人们在Kubernetes之上构建这些工具，以使其更容易运行。

以所有这些不同的方式。所以我认为我们正在努力的是试图确保他们不需要看到所有这些东西。说到KubeCon，你最近发言了，对吧？在KubeCon和KubeCon AI日。是的。你能告诉我你的演讲内容吗？

是的，我最近在KubeCon为Envoy AI Gateway做了一个主题演讲。这是一个新的开源项目，彭博社和Tetrate的工程师们一直在合作开发。同样，它基本上是在Envoy Gateway项目之上的一个抽象层，这是一个

服务器代理，用于我们许多或用于我们的推理服务中，以管理诸如流量、竞赛请求、法律和监控、流量流等方面的事情。这对我们来说非常有用。我们使用它，当

所有这些Gen-AI模型出现时。与过去的推理服务相比，它们带来许多不同的复杂性。例如，它们更大，它们使用令牌。所以……

由于这些原因，它们需要解决一组不同的问题。因此，我们不再希望根据请求来限制服务的速率，而是能够根据令牌数量来限制服务的速率将非常有用，因为这是我们试图区分的工作单元。对我来说，这是一次非常酷的经历，因为我以前从未在这么多人面前演讲过。

而且能够代表Tetrate和彭博社合作的所有工程师介绍一个真正非常有趣的新开源项目也很酷。所以我对此非常兴奋。是的，这总是很有趣，尤其是我认为我听到一个统计数据，95%的人会

将公开演讲列为比死亡更大的恐惧。哦，我的天哪，真的吗？是的。好的，这很有趣。是的，对很多人来说都是如此。这是真的。我很紧张，但以一种兴奋的方式。所以，告诉我一下差异，或者KSERV和您设置的代理，它叫什么名字？是Envoy吗？Envoy at Gateway。好的。

是的，Envoy AI Gateway，它与Envoy不同，对吧？有一个Envoy，然后还有一个Envoy AI Gateway？是的，Envoy AI Gateway是一个新的项目，它建立在Envoy Gateway之上。它基本上只是添加了一些针对这些LLM Gen AI模型的更多功能。好的，它如何与KSERV交互？这两个的堆栈是什么样的？是的，是的，当然。所以，我的意思是，我已经有点，

假设大多数人都知道Kubernetes是什么，但这些都是建立在Kubernetes之上的开源项目，它可以帮助你大规模运行和管理你的服务。所以Envoy是一个服务代理。因此，进入你的集群的每个请求

对于集群来说，可以通过Envoy进行路由。这特别有助于处理诸如流量控制、流量管理、可观察性等方面的事情。它可以进行请求路由。所以这些都是关于管理请求以及它如何在系统中移动的事情。

但是是的，所以Knative是，我还会提到这一点。它是我们使用的另一个工具或构建块。所以Knative Serving是我们在Knative中使用的主要项目。它也是开源的。它非常适合帮助运行具有无服务器概念的应用程序，你知道的，无需过多担心基础设施。所以再次，这是一个……

它是在Kubernetes之上的一个抽象，其目标是简化服务器的设置和运行。通过无服务器，你基本上是指可以动态配置资源的东西。它并不太关心这些资源位于哪个服务器上。你不需要指定它。它会为你弄清楚。

所以它使运行更容易。这一切都是为了使运行更容易，因为如果不是这样，你将拥有所有这些带有所有这些配置的YAML文件。你可以复制粘贴它们，并且你正在设置所有这些资源以确保一切正常运行。我真的很喜欢

运行kubectl tree。有一个名为kubectl tree的工具。从中，你可以看到你拥有的顶级资源的树，因为在Kubernetes中，所有这些不同的资源，如部署、pod，以及更多取决于你正在运行的内容。它可以显示所有创建的不同资源。

你可以进入命名空间并查看配置是什么以及它们在做什么。我发现这对于理解这些类型的事情非常有帮助。但基本上，这些工具可以帮助你自动设置所有这些东西，所以你真的不必担心它。所以它们都在做一些假设，大多数人都需要这些配置。通常，对于大多数工具来说，如果你需要更具体的东西，那么你可以添加或更改它。但不是你需要知道并自己指定所有内容。

但是Knative，这是帮助你以无服务器方式运行事物的指令。它可以帮助你自动扩展，因此可以根据以下内容扩展和缩减你的服务：

使用情况，以及缩减到零，这实际上是我们经常使用的一种功能，因为GPU资源是有限的。因此，如果可以的话，一些服务可以使用这个称为缩减到零的功能。如果你可以进行这样的设置，哦，如果在一两个小时内我没有收到任何请求，那么就缩减到零，让其他人使用该GPU资源，而不是在不活动的情况下占用它。

有些服务无法使用此功能，但当你可以使用时，它是一个非常有用的工具。所以是的，总而言之，这些是KServe的构建块。KServe是另一个抽象，它简化了实际运行AI模型、AI服务（即推理服务本身）的过程。所以基本上，你可以拥有这个非常短的YAML，如果使用现成的模型或一些

一些AI，比如Alama之类的东西，它们都支持这一点。你可以做的是，你可以很容易地以无服务器的方式运行它。所以它的好处在于，你不需要担心所有这些配置。目标是你不需要拥有一个了解如何运行AI模型的整个团队。他们可以专注于其他事情，例如构建平台。但是是的，所以它使运行这些服务容易得多。好的，所以基本上……

网关位于前端，当流量进入时。它可以动态配置。然后你有了Knative，它可以帮助配置。所以它会看到，哦，网关说我们需要更多资源。让我们配置它们。然后KServe建立在Knative之上，哦，我们需要的一种资源是KServe。

能够ping这个模型。该模型可能是一个大型语言模型，也可能是一种随机森林模型。在这种情况下，它并不重要。这就是我的理解吗？是的，是的。所以K-Service特别地，像Knative可以运行任何无服务器服务，但K-Service专门用于AI模型、ML模型等，就是这样。所以它有很多现成的工具，专门

专门针对AI模型，就像Envoy AI Gateway专门针对AI模型一样，KServe也是如此。它有很多现成的工具和功能，这些工具和功能是AI模型所需要的。所以它可以支持轻松配置以运行

许多现成的模型，它可以轻松地设置这些模型。或者你可以拥有一个我们称之为自定义预测器的预测器。你可以编写你自己的预测器。所以我们基本上只是启动服务。你得到一个端点，你可以点击它。我们有一个统一的API，这非常有用，因为所有这些不同的模型提供商都可以有不同的访问模式来访问模型。所以KServe的一个非常好的功能是，无论你使用哪个模型，你都可以始终使用相同的统一API。而且

Envoy AI Gateway是对此的扩展，它也作为免费MVP功能之一具有统一的API。因此，如果你试图访问Bedrock中的模型，或者你有一些本地模型，这并不重要。你将有一个统一的API通过Envoy AI Gateway，它将在后台将具有正确结构的流量定向到你使用模型的位置。

哦，很好。是的，这实际上是我提出的另一个问题，例如，这是否只允许你使用本地服务或开源模型？或者你也可以动态地将一些东西发送到OpenAI API？然后你可能想将一些东西发送到Anthropic或其他什么地方。如果你有自己的服务和自己的开源模型，你也可以将它发送给他们。

是的，所以Envoy AI Gateway允许你能够运行跨云，例如混合云。这是主要功能之一，也是出现问题的原因之一。这是因为所有这些不同的云提供商都有不同的访问其系统的方式。但是是的，我的意思是，KSERV本身类似于SageMaker、Google Vertex。

在云中，如果你想自己管理推理服务，你也可以运行KServe。我的意思是，如果你不想使用这些云提供商之一，这绝对很有帮助。如果你担心成本节省并且想自己管理某些东西，很多人也可以在云中使用它。但是，我的意思是，还有这些用于推理的产品，运行推理服务，它们也非常相似，具有相同目标。所以……

Envoy AI Gateway是，请坚持听我说，因为我知道我对它有点慢。不，不，你很好。我第一次真正深入研究它。我真的很喜欢这些AI网关。这不是我第一次听说它，但我确实发现

这是人们遇到的一个问题，尤其是在你很容易受到速率限制的情况下。如果你使用外部服务，你希望有一些后备计划。所以这几乎就像Envoy AI Gateway是一个抽象，你可以将任何你需要的端点放在下面。因此，无论你使用的是SageMaker端点、Vertex端点还是KServe端点，你都可以……

将它们全部链接到Envoy AI网关，它将根据请求的内容确定请求需要去哪里。是的，是的，完全正确。是的，它有一个统一的API，你可以轻松指定你需要做什么，它会自动为你路由，这很棒。

这一切都是为了使运行和管理更容易。是的，你开始看到模式。正如我所说，所有东西都开始建立在Kubernetes之上，建立在这些其他工具之上，所有这些都是为了使运行更容易，并且不必过多地担心基础设施。

我的意思是，这些大型语言模型和Gen AI系统也带来许多非常酷或非常有趣的问题。模型大小非常大，因此下载模型也需要很长时间。因此，KServe开始研究的一个有趣问题是模型缓存，能够缓存模型，并且不必在每个pod启动时为每个pod下载它们。所以这就像一些小事情也会非常

对于超级有帮助的，例如在GPU利用率方面的工作，当然，因为GPU现在是资源有限的，所以围绕运行和启动企业AI并使其有用和优化的许多这些问题是我们正在努力解决的事情，是的，冷启动是，有时你不能

是的，如果你说，哦，好吧，明天再来，也许它会运行。我们会看到的。是的，我的意思是，大型模型在这么短的时间内变得如此之大，它们能够做的事情也越来越多，这真是太疯狂了。我的意思是，我认为，是什么，Llama 3.1刚刚发布，它有超过，它可以处理超过128,000个令牌。我的意思是，它还有一个，

一个疯狂的存储大小，就像它不能放在一个节点上一样，所以是的，它至少需要两个节点，这也使得它更加分布式，你必须解决这些问题，所以我的意思是，我认为这很棒，只是出现了一些新问题，而且事情变化很大，但这也是一个非常有趣的领域。是的，现在告诉我关于Celery的事情，那是什么？而且

芹菜？是的。已经很久了。这是我的第一个开源贡献。之所以会发生这种情况，是因为我们需要修复一个小小的愚蠢的bug，但它是在处理Airflow时发生的。我记得他们做了很多。就像他们做的那样。我认为芹菜是……

我不知道我是否说错了，但基本上它是Airflow使用的一个组件。我试图建立一个连接，比如与Google Cloud的私有连接，但它还不是完全支持的。

而且他们只是说所有这些选项都不允许，比如选项A到C不允许，而我的选项以字母C开头，或者类似的东西，所以我通过说允许这个获得了我的第一个开源贡献，我的意思是就是这样，但这是一种很酷的感觉，我的第一个开源贡献，现在我

更多地参与开源，但是能够产生影响并让其他公司的人查看你的代码，这也很酷，所以这是我第一次尝试，现在你已经接受了这么多问题或合并了PR到开源领域，你做了很多工作，就像核心贡献者一样，你有什么想说的？

你当时或者在你职业生涯早期，是如何看待对开源的贡献的？我认为我所做的所有开源工作真正令人高兴的地方在于，它具有非常明确的商业价值。这使得事情变得容易得多。我认为我在这方面有点幸运，因为

就像去彭博社工作一样，我的目标不是从事开源工作，但它是其中一个很棒的部分。你知道，我们能够做到这一点真是太棒了，我们每天都在使用它，呃，

我们每天都在使用它，我们在做的每一件事都是我们真正需要的功能，所以我认为这使得我认为如果你真的想从事开源工作，我喜欢在工作中学习，我认为爱好和副项目对于学习来说是很棒的，但是当你边工作边学习，并且在生产环境中使用它并部署它时，我的意思是，如果可以的话，这是最好的方法，但是我认为如果你真的只想参与开源，而这是你的目标，并且你找不到现在能做到的工作，或者你

出于某种原因，你不会。是的，我认为，你知道，大多数社区都非常乐于接受，并且有很多“良好入门问题”的标签。如果这是你真正感兴趣的事情，“良好入门问题”。而且许多社区也每月或每两周举行一次会议。所以，如果你想，你知道，有人来帮助你处理你的PR，最好去参加这些会议，并结识一些人。但我的意思是，如果你参与开源，你通常也是一个了解

的人，你知道，真的是开源的支持者，每个人都走到一起并做出贡献。所以我发现我在开源社区与人们的经历非常积极。回到你刚才说的关于具有明确商业价值的问题，你发现了哪些方法可以……

证明这一点或为此而奋斗，以便向任何你需要的人清楚地表明，这是应该处理的正确问题，这个问题具有商业价值，你应该把时间花在这个问题上。

再说一次，我觉得我在这个领域有点幸运，因为通常情况下这是很清楚的。例如，由于生成式AI的出现，由于大型语言模型如此庞大，我们都需要这些东西。你知道，我们很明显需要它。所以我想，你知道，从……

资源的角度来看，从可用性的角度来看，这方面还有很大的增长空间。所以我觉得这有点容易，但我一直在思考很多，尤其是我想到我的第一份工作，因为它是一家规模较小的公司，只有少数几位首席工程师和高级工程师，但他们……

就像摇滚明星一样。我不是说像编码摇滚明星一样，但他们真的很好。他们真的很好。他们深入研究，并且非常擅长寻找具有商业价值的问题。我认为这是一项关键技能。我思考了很多，其中一部分是运气。有时你会失败。例如，我认为在我的第一家公司，我加入了最好的团队。我有可能得到的最好的导师。

我的意思是，我为自己获得的机会感到非常幸运和感激，因为我当时并不太懂编码，就像我在学校里做过一些Python编程一样，但我获得了这种经验，因为他们非常愿意帮助我，因为他们非常擅长发现具有商业价值的问题，然后把它交给我，帮助我成长，我的意思是，这改变了世界，我认为，如果我当时在另一个团队或另一个地方，情况会一样吗？但我认为看到他们的工作和

让我对这个话题思考了很多。我不知道答案到底是什么，但我希望知道。嗯，能够嗅出关键的商业价值问题，并具备良好的洞察力或嗅觉，这是非常重要的。

正如你所说，这是一种技能，是的，我认为，当我设计某些东西时，我试图明确的一点是，需求是什么，如果你不知道，你应该弄清楚，以确保它值得你花费时间。我认为我一直在尝试做的事情，而且我仍然希望提高这项技能，当然，但我一直在尝试做的事情是至少知道尝试找出什么不是一个好的商业价值

我认为有一些明显的迹象表明它可能不是。所以有多少人会使用它与有多少人相比？这是否为我们创造任何收入，或者它有什么用途？我的意思是，这取决于产品是什么。但是你需要那个新按钮吗？我们问过他们了吗，它真的有用吗？那是他们真正会使用的东西吗？我认为获得客户或用户反馈也超级有帮助，因为我认为你能做的最糟糕的事情是制作没有人关心的东西。

这是浪费时间，浪费金钱，而且非常令人沮丧。是的。然后你再去试图证明你在过去三到六个月里一直在做的事情。是的。是的。最糟糕的事情也是努力工作却没有人关心。所以，我认为知道如何管理你的时间和精力非常重要，并且尽可能确保它将是一件非常有用的东西。是的。

我还想知道，因为有些事情可能，你知道，它们非常重要，但如果你没有正确地向你的利益相关者宣传它们，那么它仍然可能以失败告终。几个月前，我们邀请了Stefano来这里，

他谈到了他是如何构建有史以来最令人难以置信的ML平台的，它拥有你想要的一切。所有他在每个博客中阅读到的顶级功能，你知道，然后他说，我们发布它时却无人问津。没有一个数据科学家想要使用它，因为我们没有正确地宣传它对他们开始使用的好处。所以他们都继续以自己的方式做自己的事情，并且

没有使用他花了所有时间制作的绝对令人难以置信的平台，你知道，并且拥有你想要的所有功能，你会认为这些功能几乎是基本要素，或者每个人都必须需要它们。即使在他做了之后，他也失败了。是的。我认为我非常喜欢另一句名言，这是我当时在那家公司工作时工程团队的座右铭，

工程部门当时的座右铭很简单：尽可能简单，尽可能强大。我认为要说明这一点的一件事是发布一些东西，然后对其进行迭代，这样，你知道，它不必完美。我不是说这是，但这只是让我想到的一点，即它不需要那么完美。只需发布一个MVP，并能够开始对其进行迭代，让人们使用它并获得反馈。因为我认为很多时候我们认为我们最了解人们想要什么。

但有时事实并非如此。你知道，特别是作为为另一位工程师制作平台的工程师，我认为我们甚至更认为，哦，我们知道他们想要什么。但有时事实并非如此，你知道？就像你说的，有时人们……

需要采用它，或者有时间，或者可能它并不完全是他们希望的，但我认为你经常提到的另一点是，我不仅拥有并且仍然拥有非常优秀的导师，而且拥有一个为你呐喊并确保你的工作被人们知道和宣传的人非常重要，我的意思是

我做了很多自我宣传，可能和你一样。我们是公众人物。我们发布了很多内容。这对我有所帮助吗？是的，我认为确实有很多帮助。我的意思是，我认为……

我讨厌说房间里声音最大的人会被听到。我的意思是，这并不总是正确的，但是你需要，你的名字需要被知道，或者项目需要被知道并被宣传出去。我相信有一些很棒的应用程序，但是如果他们没有任何营销，他们可能没有任何用户。所以，如果你没有任何用户，你可以拥有世界上最好的应用程序，但这有什么意义呢？你知道吗？是的。就像第一次创业的人专注于产品，而第二次创业的人专注于市场营销。但是，

基本上是这样。是的。所以，我的意思是，是的，这非常非常重要。整个营销部分非常重要。营销自己也超级重要。例如，我为自己创建了一个“吹嘘文档”。我得到了这个主意。我忘了那个，嗯，科技网红的名字。她曾经在推特上很火，但她创建了这些，呃，小册子，就像这些评论杂志一样。这是一个来自她的想法。我必须查一下她是谁。

但是要写一篇关于你自己的“吹嘘文档”。所以我每个季度都这样做。我有一些关于演示文稿、一般工作之类的部分。我每个季度都会总结我的所有工作，并将其交给我的经理或任何负责我审查的人。我得到的反馈是，这也很有帮助。关于自我宣传和你的产品，我认为这在科技领域非常重要。是的。

我需要这样做，这样在我感到沮丧的日子里，我可以打开它，然后说，你看，我并没有像我让自己看起来那样失败。你的也会很棒，你做了很多事情。所以，是的，提醒自己很好。记录下来很好，然后它会使写作变得更容易。因为有时你会忘记，我做了什么？但是有记录是很好的。

是的，我认为人性的一部分是你会陷入低谷，拥有这样的东西并经历这样的事情非常有用。我甚至听说过一个故事

约翰·列侬和披头士乐队在录音棚里，列侬情绪低落，不想录制任何东西。但这是在一周的狂欢之后。但是，正如你所知，在一周的狂欢之后，你有点筋疲力尽了，他不想录制任何东西。然后人们开始给他播放一些歌曲或朗读他写的一些歌词。他开始说，哦，是的，我写过这个？哦，是的，也许我是一个

也许我是一个不错的词曲作者，你知道吗？所以，即使是我们最好的人，也会发生这种情况。拥有这样的东西非常有用。它就像让你再次振奋精神，然后让你回到正轨。是的，当然。但是回到这个座右铭，是什么？只有必要时才强大，尽可能简单。是的，尽可能简单，尽可能强大。这是一个很棒的，

座右铭，因为过度设计东西太容易了，抓住最闪亮工具太容易了，在你意识到之前，你已经陷入困境了，是的，你就像，哦，也许，呃，这将比预期的花费更长的时间，因为范围已经蔓延了，是的，是的，这非常困难，但至少从这个原则开始，我认为会有很大帮助，就像我说的那样

获得你的需求，了解你需要什么，然后尝试从那里发展。所以一开始就试图解决这个巨大的问题。我认为这适用于几种不同的场景。是的，我在考虑需求，以及你提到的，当你开始一个项目时，那些像早期预警信号一样的东西，这些信号可能表明它不像你想象的那么有商业价值。

我想知道你是否还有更多。例如，创建它的团队是否大于实际受益于它的用户？这是一个巨大的危险信号，对吧？是的，这就是我所说的，有多少用户想要这个功能？我们问过多少人？它从哪里来？谁真正想要它？运行它的成本是多少？这就是我所说的需求。就像，它的标准是什么？为什么我们需要这个？它有什么用途？

所以是的，我认为如果一个人说，“哦，嘿，拥有这个会很棒。”我认为我对它是否值得我花费时间有一些疑问，但有时很明显它值得你花费时间。有时很明显我们绝对需要模型缓存。这对每个人来说都是显而易见的。但其他时候，我们需要这个按钮吗？我不知道。也许，也许不。-是的，我想知道任何与GPU和节省相关的事情，

GPU时间或更充分地利用GPU，例如充分利用GPU，这感觉像是，是的，我们应该去做。但同样，你应该从这个角度来看待它，几乎像一个有辨别力的眼睛，能够提出问题并从你得到的东西中识别出它是否真的像人们所说的那样有价值。是的。是的。

没错。有很多不同的方法可以做事情。例如，在KServe中，我们开始添加一些OpenAI协议，例如聊天、聊天完成。还有更多，但我们只是从那里开始。我们开始支持几种不同类型的任务，例如

自动路由，你想要什么类型的任务。然后对于GPU来说，有几种不同的方法可以管理GPU协同工作。我知道现在他们正在研究一种解决方案，它使用其中的两种，因为这可能是两种最流行的、最需要的解决方案。所以我认为这种方法也很好。你不需要一次做所有事情。至少让一些人可以使用它。然后我真的很喜欢使用聊天，这里的聊天端点。现在我也很想使用这个。我认为这非常有帮助。

你与非技术利益相关者（业务方面的）进行过多少次对话，并与他们讨论他们可能想要什么？例如，随着大型语言模型的出现，它扩展了谁在使用AI解决方案的范围？

是的，我的意思是，这是一个很好的问题，因为我觉得作为平台工程师，我的地位比较低。我们与AI和ML工程师进行了很多讨论，但我们确实有定期与之交谈的产品人员。我知道他们非常擅长收集所有不同的反馈，并以一种创造产品和功能的方式将其传递给我们。所以对我们来说，我相信这就是它的工作方式。在彭博社，这真的很酷，因为即使很多管理人员和

产品人员也非常技术娴熟，他们在彭博社成长了很多，彭博社非常擅长留住员工，我知道很多科技公司的人员流动很快，这太常见了，但我对彭博社印象深刻，这里有很多工作了10年以上的人，你知道吗？

所以他们在彭博社内部晋升和调动。但是是的，所以这是彭博社的一个有趣之处。但是至于我们如何获得它，通常是通过产品，我喜欢这种简化的方法，你知道。但我同意。并且围绕着这一点有整个理念，即去询问用户他们想要什么。我认为这非常有帮助。我认为这是正确的做法。你应该一直这样做。如果你没有这样做，我认为这有点令人担忧。是的。

是的，再次强调危险信号。这是你可能想要注意的事情，因为你可能没有找到……

你能拉动的最高杠杆或最大的杠杆？是的，我认为如果你也可以与使用我们平台的AI或ML工程师建立个人关系，去和他们坐在一起，然后说，嘿，如果你认为有人是超级用户，经常使用它，总是出现在支持聊天中，向我展示你如何使用它。然后他们可能会说，哦，顺便说一句，我不知道这个按钮是什么。或者，哦，顺便说一句，我每次都必须这样做。也许你会发现一些事情。我认为这也很重要

一种非常好的方法来找出人们使用你的工具的模式是什么，以及痛点是什么，因为他们可能不会在调查中说出来，他们可能会忘记，或者他们可能不会在聊天中说出来，但是通过与他们坐在一起并观察他们，你可以弄清楚，是的，我

我可能会说，我使用的工具大约90%都不是让我印象深刻的体验。但这并不意味着我会去向创建该工具的人解释该工具可以改进的地方。我假设大多数人都是这样，对吧？因为解释为什么这是个痛点需要很长时间，并且

对我来说有多大的痛苦？所以通常我会说，随便吧，我会用我的时间做其他事情。是的，你不能选择你的战斗。是的。所以你去和某人坐在一起，

你几乎强迫他们向你展示什么很痛苦，因为如果有人在我旁边看着我做事，我相信我会非常直言不讳，是的，一样，是的，有点更私密的方式，让你感觉更舒服，你知道，而不是仅仅在调查中输入一些东西，它需要更多时间，但它更个性化，更高的，是的，更高的杠杆，100%，我还要问你的另一件事是

当你查看堆栈并考虑传统的ML用例以及几乎像表格数据、低延迟等你正在为其创建平台或帮助人们使用这些用例的东西与你正在为其创建平台或帮助引入这些用例的新大型语言模型AI世界相比，你认为它们在哪些方面存在差异？

以及，就像我们讨论过的Envoy AI网关一样，它专门用于大型语言模型用例，对吧？是的。

你认为这两个世界如何在平台上协同工作？例如，平台是否支持所有这些，并且几乎像这样蔓延？平台是否具有支柱，取决于用例是什么，你可以连接到这里的平台或那里的平台？例如，你如何可视化或看待它？所以有几件事，我认为。

我们正在努力使平台尽可能易于使用。归根结底，你只是在某个地方部署一个模型。我们试图确保用户不必太在意，就像我说的那样，尽可能地抽象掉许多Kubernetes概念。试图确保用户不太关心什么或在哪里，例如

为什么他们应该关心它是在本地还是在云中？它只是在有资源的地方运行，你知道吗？所以对于混合环境中的AI模型，我们试图创建一个非常无缝的平台。你实际上不知道或不在乎它在哪里运行。这就是整个，你知道，无服务器的意义，以及能够运行混合云，能够将资源用于不同的东西。至于在Kubernetes上运行的不同产品，

我会说训练就像我们UI中的一个不同的选项卡，你知道吗？它在哪些方面有所不同？我认为它在推理服务或长时间运行的作业和训练作业方面有所不同，通常情况下并非如此。这取决于你正在训练什么以及你在做什么。所以这些作业的运行方式，你仍然在Kubernetes中部署某些东西。所以基础仍然相同。我认为一些较小的功能有所不同。例如，我们有一个模型注册表，所以你可以……

只需点击一个按钮即可保存你的模型，提取它们的版本，并稍微更改不同的配置，拥有不同的工件。所以我认为这是推理中需要的东西，而训练中可能不需要，或者一些不同的功能。这就是我看到它们差异的地方。这回答了你的问题吗？是的。我喜欢这个想法，就像

相同之处在于，无论你拥有一个巨大的模型，还是一个非常小的修剪模型、微调模型、蒸馏模型还是随机森林模型，它都是一个模型，它将位于某种Kubernetes服务上。你只需要模型。你不需要考虑

该模型可以处理多少流量？实际位置，它位于哪个云中？它是在本地吗？所有这些东西。我真的很喜欢这个想法，就像，让我们尽可能地抽象掉所有东西，这样如果数据科学家要发布一个模型，

他们知道他们可以发布该模型，他们的工作是创建最好的模型。然后其余的事情会为他们处理。-是的，没错。这就是统一API如此好的原因，因为我们为你提供了一个端点，无论你在哪里运行它，端点看起来都非常相似。你将用于预测或聊天的内容在格式上非常相似

无论它在哪里运行。所以，我认为这是这些工具的一个非常好的优点。你是否区分了……

对于大型语言模型世界，你可以蒸馏模型，或者你可以修剪它们，或者你可以做一些事情来使它们更小。或者你可能有一个模型集合，你拥有网关等等。所以有一些你可能想对大型语言模型做的事情。

你不会对传统的ML模型做这些事情。就像你说的，如果你正在训练这些模型，并且你拥有模型注册表，并且可能在传统的ML世界中正在进行特征工程，

你也会在那里区分吗？还是像你提到的那样，这些只是平台上不同的选项卡，具体取决于你的用例？所以，对于你的推理服务正在运行的内容，它是否正在运行这个模型或那个模型？这只是一个配置，或者是你放入推理服务的小YAML中的一小部分。然后案例服务器将在后台做出很多假设，所以你不需要编写YAML。

所有这些关于它们特定于该模型的大事情，它如何运行，例如获取指标的端口是什么。我们知道TensorFlow在这个端口上，另一个模型在这个端口上。所以如果获取指标，我们将自动打开该端口或能够从中提取。所以很多这样的事情，你只需要告诉我们关键字或关键配置一项，然后我们做其余的事情。但这在YAML本身中。所以这是推理产品本身的选项卡中。

太有趣了。