Google Cloud AI平台及其基础设施

演讲人：Ameer Abbas、Brandon Royal，Google Cloud

我叫Brandon Royal，是Google Cloud的产品经理，专注于我们的AI基础设施和为AI量身定制的云，主要与众多在Google基础设施上部署AI的客户紧密合作，特别是Google Cloud的基础设施。

今天的会议分为几个环节，其中AI会是一个讨论的重点。我们将探讨Google如何利用AI解决Google Cloud中的关键客户问题。此外，我们还将关注AI的趋势，即我们所说的平台变革。我们将讨论Google在Google Cloud中为满足应用AI的客户需求所做的特别工作，以及提供专用于生成式AI的平台和基础设施。我们将深入探讨推理和服务，讨论我们如何从平台的角度来解决相关问题。此外，还会探讨训练、微调等环节。之后，我将邀请Ameer来谈谈我们如何在Google Cloud中运用这些技术。

当我们谈论平台变革时，指的是平台随着时间的推移如何发展演变。大家可能会认出其中的一些图片。还记得互联网平台吗？那曾是一个重大事件，当时没有人真正知道互联网会带来什么。那是第一个平台变革。移动也是另一个重大变革。这是第一款Android手机。那是一次巨大的变革，推动了许多技术创新和颠覆。

AI代表着下一个平台变革。目前，我们对AI已经有了许多了解，但实际上我们还没有完全掌握它。就像爱迪生和西屋在电力发展初期一样，我们能够制造灯泡并进行一些简单的操作，但我们还没有完全把握AI的所有潜力。我们认为AI是一个同样巨大，甚至更大的机遇。这就是Google和Google Cloud存在的意义——帮助我们的客户抓住这一机遇，拥抱这一平台变革，提供工具、基础设施、平台和解决方案，构建基于AI的平台，并将AI融入开发和运营工作流程中。这也是我们今天讨论的重点。

AI模型的飞速发展想必在座的各位都深有体会。尤其值得关注的是开放模型领域取得的重大进展。Gemini和ChatGPT等模型的出现已经激发了众多人的想象力，其价值也得到了生态系统的广泛认可。如果我的祖母或母亲也能和我讨论AI，足见这些工具已经普及到了多么广泛的程度。然而，对于在座的各位以及许多部署AI的人来说，另一个引人关注的领域是开放基础模型生态系统及其未来发展。

我们认为这是一个持续演进的过程，开放模型将提供灵活的部署选项。这意味着这些模型可以部署在任何位置，并根据特定任务进行微调和优化，同时优化资源利用。

今天，我将重点介绍如何在Google Cloud的AI基础设施和平台上接纳和部署开放模型，以及如何将开放模型融入生成式AI战略中。

对于众多在Google Cloud上部署的客户而言，开放模型的重要性毋庸置疑，因为它们为平台提供了极大的灵活性和扩展性。我们深感自豪的是，大约70%的最具影响力的独角兽企业，都选择了Google Cloud作为他们的AI基础设施和平台。

接下来，我们将深入探讨开放模型为何受到如此广泛的欢迎，并重点介绍那些在模型开发方面表现活跃的公司，比如Anthropic、character.ai和Cohere等。同时，我们也会探讨AI基础设施是如何助力这些模型的构建和发展的。

2023年，我们的主要工作聚焦于构建基础模型并确保其可用性。而2024年，我们的工作重心将转向如何将这些模型广泛应用于实际场景。随着新一年的到来，微调和推理技术也将逐渐成熟。

Gemini是Google于12月发布的顶级人工智能多模型，它拥有多种版本，并已集成到从Workspace到Android手机再到Google Cloud等Google的各种产品中。Gemini作为我们的主打模型，自设计之初就旨在实现多模态交互，支持通过文本、音频、视频、代码等多种方式进行沟通。它凭借出色的灵活性和强大性能，成为我们向客户提供的最顶尖的模型，而其背后的支撑正是我们提供的AI基础设施。

Gemma的发布标志着我们AI旅程中的一个重要里程碑，我期待着它将如何重塑未来的AI格局。Gemma是由Google DeepMind推出的新型开放模型，它将助力用户构建自己的生成式应用程序。这是一系列轻量级且技术领先的模型，建立在与Gemini相同的研究和技术基础之上。尽管它属于不同的模型系列，但其构建方式与研究基础与Gemini相似，同时在部署方面提供了极大的灵活性。Gemma的开放权重已在Hugging Face和Kaggle等平台上发布，许多实现已经可供使用。下面我将向大家展示其中的一些实现。

Gemma拥有两个版本：一个是2B参数模型，另一个是7B参数模型，每个版本都包括基础版本和微调版本。这些模型在C++、PyTorch、JAX等多种语言中都有完整的实现。我将展示所有可用的实现，因为我们已投入大量努力，确保这些实现在生态系统中对开发者友好易用，从而激发他们的创新活力。

我们预计，类似于LLaMA、Alpaca和Orca等模型的情况，Gemma的后续衍生版本也将在Hugging Face平台上发布。这是因为我们一直致力于推动这些开发者工具的普及和应用。

对于开放模型来说，安全性至关重要。这始终是Google AI原则的核心承诺。在Gemma的开发过程中，我们已经从头开始内置了安全功能，包括将安全对齐作为模型设计的一部分。此外，我们还直接向开发者提供安全工具包，帮助他们确保使用Gemma构建的应用程序符合相同的安全标准。

确保模型输出的准确性、安全性和非歧视性，以及符合整体原则，都是至关重要的。虽然对齐过程在模型构建阶段已经完成，以确保输出的安全性，但我们仍然鼓励客户对模型进行微调，这可能会影响到对齐结果。我们的目标是提供工具，帮助客户执行类似的对齐练习，以确保模型输出的安全性。

关于伦理团队的变动，我无法深入讨论DeepMind团队内部的具体情况。然而，自项目启动以来，模型的安全性一直是我们关注的焦点。与Gemma团队紧密合作，在Google Cloud上部署Gemma时，我们始终将安全性放在首位。

观众：你们是否已经发布了用于训练Gemma的数据？

关于模型本身的训练过程，有一些细节需要说明。首先，并非所有训练数据都公开，但我将指引大家查阅那些详细讨论训练方式、参数和方法的技术文档。其次，数据本身并非公开可获取，但我们致力于尽可能透明地解释数据在训练中的运用情况。这种透明度对于确保模型输出质量至关重要。与Gemini类似，我们在数据的调整和筛选上非常严谨，以确保其准确性。

接下来，来谈谈AI平台和基础设施。刚才我们聚焦在模型本身，现在来讨论一下Gemma如何在各种场景下部署，以及Google Cloud的平台和基础设施如何支持这一过程。

在谈论模型时，我们往往会忽视支撑这些模型的基础设施。那么，我们如何构建如此庞大的模型？AI社区如何实现规模化微调、基础训练和推理？这其中，容器技术，尤其是Kubernetes，扮演着关键角色。

Kubernetes之所以成为开放LLM模型的基础，原因有几点。

首先，它提供了灵活性，允许模型的可移植性，并支持使用任何框架，与ML和云原生生态系统完美兼容。

其次，性能至关重要，因为客户都希望能够最大化性能，这是他们竞争的关键。Kubernetes通过水平和垂直扩展来帮助实现这一点，为跨AI加速器的微调和推理模型提供编排能力。

再者，效率也是不可或缺的因素，因为这些资源成本相当高。包括小型AI初创公司在内的众多客户，都需要有效地管理数以千计的节点和长时间的训练作业。而Google Kubernetes Engine（GKE）正是他们有效管理计算和日常运营的得力助手。

观众：看起来Kubernetes似乎对GPU虚拟化的支持并不多。这是否存在呢？

我们提供的服务中有一个核心方面是GPU共享，这对我们来说是一个非常重要的特性。我们最近推出的MPS时间共享和时间切片功能，可以有效地共享这些资源。这在AI推理中尤为重要，特别是当你需要高效推理的小型模型时。与CPU相比，GPU在资源分配上存在一些限制。尽管我们没有为GPU提供与CPU相同的原语，但我们绝对致力于确保这些资源在GPU级别上得到高效的时间切片。同样，对于CPU，我们也会进行类似的切片处理。

我们为GPU、CPU和TPU提供全面的一体化支持，这种支持在各个方面都表现得尤为突出，特别是在可扩展性方面。对于大规模训练任务，需要将众多加速器节点编排在一起。我们在去年11月左右发布了一篇论文，展示了我们是如何成功扩展到5万个TPU芯片的，这创下了使用TPU进行的最大分布式训练集群的记录。此外，在常规集群规模方面，我们也能支持高达1.5万个节点，这在行业内堪称顶尖水平。这种出色的可扩展性对于训练和微调至关重要。

正如之前提到的，我们的客户期望在价格性能方面充分利用其资源。多租户作业排队、GPU共享和优化Pod启动时间等特性在这里都发挥着重要作用。而这一切，都基于Google在Google Kubernetes Engine上近10年的全面托管经验。

观众：Vertex在这一切中扮演的角色是什么呢？

Google Cloud内部提供了多种不同的平台选项。其中，更偏向于受管理的平台选项是Vertex。Vertex AI是我们为那些追求完全受管理体验的客户提供的起点。它提供了即插即用的支持，涵盖了包括Gemma和Gemini模型在内的开放模型。同时，它还提供了一个全面的端到端平台，用于训练和推理。然而，有些客户可能更倾向于较低级别的抽象，并希望拥有更多的选择权。这时候，AI基础设施和Kubernetes就派上了用场。

让我们来谈谈支撑这一切工作的基础吧。我们需要确保资源的高效编排、扩展以及其它任务得以顺利执行。这涉及到Kubernetes的接口、控制平面、数据平面以及底层AI基础设施资源之间的协同工作。

Google在AI加速器方面提供了市场上最丰富的选择，对那些正在考虑其生成式AI战略的客户来说是非常有益的。客户经常咨询我们，询问如何在扩展和扩大规模时确保拥有所需的资源，我们对此提供了相关的指导。

观众：在客户中，我们看到哪些领域是最广泛应用的呢？

大型客户主要部署TPU和GPU，主要用于大规模训练作业。而从客户数量来看，大多数客户选择部署的模型是基于CPU的，而部署最多的模型则是小型GPU。当然，我们也有一些对资源需求极大的大型客户。

观众：你认为这可能是因为部门最初应用的推理和训练类型吗？

我想你可能指的是，所有的训练都是在GPU上进行的，而推理可能在一些较小的场景下发生，会是什么样子的呢...

观众：那么，你认为在较小规模上常见的工作类型是什么呢？

我们通常将客户分为三类：生产者、应用者和消费者。

生产者是指从头开始构建模型的组织，这需要大量的资源和专业知识。他们通常使用TPU等强大的加速器来训练模型。

应用者是指不从头开始构建模型，而是调整现有模型（如Gemini）以适应特定任务的组织。他们可能同时运行多个模型，以混合专家架构的形式，或者可能使用RAG作为基础。在这种情况下，他们通常使用CPU和GPU进行训练和推理。

消费者是指希望直接使用这些模型，但不想参与构建或调整的组织。他们通常使用CPU和GPU进行推理，因为这些处理器在这项任务中表现最佳。

观众：这再次凸显了CPU和GPU在计算中的重要性。我们将对推理中的CPU进行更深入的探讨，但从运营的角度来看，如果我们回到前一张幻灯片，这有助于我们理解在Google Cloud环境中，我需要进行多少定制化工作，才能从左到右进行转变。随着我们越来越多地考虑网络和网络服务，我们是否会更倾向于向右移动，而保持左侧进行通用计算呢？在从左到右的转变过程中，我的员工配备和专业知识需求会发生哪些变化？

这是一个很好的问题。就我们提供的更低级别基础设施而言，我们的目标是为客户提供尽可能接近即插即用的体验。无论客户规模大小，我们都希望能够为客户处理更低级别的网络和存储编排。这也是为什么许多客户选择Kubernetes和GKE的原因，因为编排层是由我们管理的。

但问题是，当我们考虑团队扩展和协作时，那些位于更高层次的平台团队需要我们投资的方向在哪里呢？比如说，假设我有一个庞大的数据科学团队，拥有数百名数据科学家或研究人员，我们该如何确保他们能够高效地利用手中的资源呢？这正是客户在我们提供的平台和基础设施之间创建抽象层，整合最终消费者体验的地方。

在某些场景下，比如更深度地集成到应用程序中，这完全依赖于，比如Kubernetes API、推理API或训练API与他们应用程序的实际运作方式之间的整合程度。这恰恰说明了客户为何愿意在平台和基础设施之上投入，以构建出独特的体验。这确实是个值得深入探讨的问题。

我们经常听到很多关于那些强大的硬件解决方案的信息，比如TPU、GPU以及专用于运行AI工作负载的加速器。但有一点很重要，那就是许多AI项目其实还是依赖于CPU的。事实上，根据我们对自己机群的内部研究，CPU仍然是AI模型的主要计算平台。CPU在推理过程中发挥着重要作用，因为虽然许多模型是在专用加速器上训练的，但它们可以通过在CPU上进行高效优化来实现推理。CPU的可用性、高可用性和突发性优势使其成为了一个可靠的选择。例如，像英特尔AMX这样的下一代CPU指令集，就能够帮助优化LLM和其它AI模型，而无需依赖GPU或TPU。

Palo Alto Networks就是一个很好的例子，他们在客户网络内部使用深度学习模型进行威胁检测。通过利用支持英特尔AMX的CPU进行低延迟推理，他们实现了两倍的性能提升，而这一切都是在我们在平台上提供的C3和H3虚拟机上实现的。

至于他们为何选择CPU而不是GPU或TPU作为模型运行的平台，这主要归结于模型的资源需求、可用性约束以及延迟方面的考虑。对于那些可以通过技术如英特尔AMX有效构建为CPU的模型，从CPU开始是一个不错的选择。而对于那些规模更大或资源需求更高的模型，GPU或TPU可能更为合适。

说到GPU，基于Nvidia L4 GPU的G2 VM针对推理进行了优化，具有出色的性价比。

而在高端领域，基于H100 GPU的A3 VM专为大规模部署设计，提供了卓越的AI性能，并利用Google独特的网络架构进行分布式训练和推理。

再来说说TPU，即张量处理单元，这是Google专为机器学习任务设计的定制芯片。虽然它最初是为内部使用而开发的，但现在Google Cloud也将其提供给客户使用。TPU得到了PyTorch等框架的支持，通过项目如PyTorch XLA，你可以使用PyTorch构建模型并将其部署到TPU上。此外，Google内部的另一个项目JAX，因其对TPU的本地支持而日益受到关注。

TPU的历史可谓悠久，可能比我在本次会议上能讲述的还要长。但我想强调的是，它作为Google内部快速迭代的产品，一直在不断进步。我们在内部使用TPU，同时也通过云向客户提供。每一次迭代都展示了我们的快速发展。例如，2018年，我们发布了V2版本，这充分展示了这一领域的快速发展。这些TPU是完全定制的芯片，存放在定制机架中，并配备了专为大规模机器学习模型的训练和推理而设计的定制水冷和空冷系统。

关于TPU的部署情况，它们确实在各个地区都有分布，但具体的可用性会因版本的不同而有所差异。通常，我们会从一个或两个地区开始部署，随后逐步扩展至更多地区。TPU V5e作为最新版本（e代表高效），既支持训练也支持推理，由于其更侧重于推理功能，因此在更多地区都有广泛的可用性。举例来说，TPU V5p目前仅部署在一个地区。不过，我们预计随着时间的推移，它将在更多地区得到部署。

观众：我想回应之前提到的一个问题。我相信在询问Paulo Auto为何选择CPU而非GPU时，已经暗示了其中的一些考量。我想请教你，是否曾与客户就TPU在某一地区的可用性与C3的可用性之间的差异进行过讨论？你能否分享一些关于C3与TPU在可用性方面的具体信息？这可能是客户选择的一个因素吗？

在云环境中，尤其是当资源有限时，可用性成为了一个至关重要的考虑因素。尽管能够按需获取TPU和H100等资源是理想状态，但这在实际操作中并不总是可行的。因此，对于许多客户而言，CPU通常成为了首选。C3实例等选项提供了出色的可用性、区域冗余、多区域负载均衡支持和应对突发需求的能力。不过，在使用这些资源进行突发工作时可能会遇到挑战，因为通常需提前进行资源预留。因此，在很多场景中，CPU确实是一个优秀的起始选择。接下来，我将进一步探讨可获得性以及我们在平台上实施的一些解决方案。

让我们快速谈谈推理。确实，当提及推理时，我们主要指的是模型推理。简单来说，有一个函数和一个模型，输入一些内容后就能得到相应的输出。这就是推理的核心。但当我们考虑到操作化推理时，所需的服务堆栈远不止于此。一个全面的服务堆栈除了需要能够调用LLM、暴露函数和处理输入输出外，还应具备可观察性、可追溯性、健康检查等功能。在与客户合作构建全面解决方案时，我们会看到从Hugging Face的VLM和文本生成推理到众多其它优秀的开放解决方案，以及Google直接提供的针对TPU的Saxml等方案。这些都有助于构建更强大的服务堆栈，支持CPU、GPU和TPU的使用。

许多客户向我们表示：“我们想要Kubernetes的体验，但不想管理所有底层基础设施。我们不想处理节点、扩展或分配等问题。”为了解决这个问题，我们应用了一种称为Autopilot模式的操作方式，这已成为在GKE中部署集群时的默认选择。使用Autopilot模式，你可以像平常一样使用Kubernetes API，而GKE将负责其余所有工作。它会根据你的需求提供适当的节点和资源，无论是CPU、GPU还是TPU。GKE会根据你的需求进行扩展，并管理这些节点的生命周期。这大大提升了运营效率，因为你无需担心节点的修补或维护，这些工作由Google的SRE团队负责。此外，我们还提供了基于Pod的SLA，这对于关注服务可用性和正常运行时间的客户来说至关重要。SLA实际上是在Pod级别而不是节点级别提供的，这表明我们在GKE中为客户部署其AI模型时承担了更高的责任。

观众：在谈到接近控制时，假设某个任务需要或希望使用20个GPU，这显然不适合部署在同一台服务器上。那么如何确保在需要数据传输时，GPU不会远距离通信而几乎是本地交互呢？

这是一个非常实际的问题。在内部，我们利用节点自动配置技术来确保节点的形状、大小和分布都能与工作负载的需求相匹配。对于网络和连接性的问题，当客户进行大规模训练时，他们通常会提前准备好集群，而不是让集群根据训练任务动态扩展和缩减。这有多种原因，但可获得性通常是其中的关键因素。然而，在推理方面，情况就有所不同了。

作为一个推理作业，我基本上可以指定我需要的Pod数量，甚至可以设置水平Pod自动缩放功能。Pod的数量可以根据需求进行增减，节点也会根据扩展Pod的需求进行相应的配置。

观众：从互连技术的角度来看，是否有使用InfiniBand的情况呢？通常，大家会选择InfiniBand来实现低延迟。你们使用的是以太网还是InfiniBand呢？

我们的网络堆栈与InfiniBand略有不同，但本质上目的是相同的，我们确保了GPU到GPU的网络连接，以实现最低延迟。这对于任何大规模训练作业来说都是至关重要的。在A3中，我们采用了稍微不同的网络堆栈解决方案，这是我们正在持续投资和改进的领域，因为我们深知这对于客户来说是一个关键需求。

接下来，我们简要讨论一下训练。我之所以提到这个，主要是因为资源的可用性对于训练作业来说非常重要。目前，我们已经推出了一项功能，我们称之为动态工作负载调度。这个功能的核心理念是，你无需预先保留资源，只需指定：“我有这个作业需要运行，它需要这些资源，并持续这么长的时间，当资源可用时请为我分配。”作为云服务商，我们擅长在资源之间进行调配，知道它们何时可用并进行配置。我要强调的是，我们正在逐步将调度这些加速器的任务交给Google来处理，首先是GPU，然后是TPU。这对于训练和微调来说非常重要，客户不希望为这些资源预订大块的时间，而是希望根据需求进行动态分配。

观众：这些资源是按需分配还是在资源可用时进行分配呢？

让我澄清一下术语。我们使用“按需”来描述一种资源类型。感谢你提出这个问题，因为这是一个重要的概念澄清。我们有所谓的按需资源和保留资源。对于保留资源，你购买了一批资源，它们归你所有，你支付费用并可以按需使用。而对于按需实例，你请求一个资源，使用它，然后释放它，不再支付费用。目前的模型解决了“我现在需要这些资源”的问题；如果它们不可用，你需要稍后再试。我们希望能够解决客户的这个问题，告诉他们：“你知道你需要什么，只需让我们为你配置，或者让我们在资源可用时为你找到并配置这些资源。”

现在到了演示时间。

我们将从一个模型开始演示。

让我们从Gemma开始。首先，我将带大家了解我们如何在Google内部部署Gemma。然后，我们将讨论一些可以在其中部署Gemma并增强其功能的场景。

我们快速浏览一下。

首先，你可以在哪里找到Gemma呢？它在几个地方都可以找到。主要位置是Hugging Face Hub，这可以被视为模型的GitHub。在Hugging Face Hub上，你可以找到Gemma以及Transformer实现的两个版本：gemma-7b和gemma-7b-it。在Hugging Face上，你可以找到模型卡片和实现细节，使得尝试变得快速而简便。此外，还有一个用于实验的区域和直接将Gemma部署到Google Cloud的选项，我稍后会为你演示。

此外，你还可以在Kaggle上找到Gemma，这是Google的模型和数据集中心，你可以在那里找到更详细的信息。Gemma还有其它几个实现，包括用于微调和推理的Keras、PyTorch、C++实现以及TensorRT-LLM实现。这些实现旨在鼓励生态系统开发人员使用Gemma，部署它，并构建创新的应用程序。这对我们来说是一个关键目标，并且我们也非常重视安全性。

部署选项丰富多样，其中包括Vertex AI，你只需一键操作即可轻松部署Gemma，同时选择适合你的项目和区域。这种受管理的体验既快速又便捷，尤其适合那些没有专门平台团队来管理较低级别抽象的人员。另一个值得考虑的部署选项是Google Kubernetes Engine（GKE），它为客户提供了所需的控制和灵活性。我们为Kubernetes管理员准备了详尽的指南和YAML文件，以便轻松将其集成到自动化部署工具中。

此外，我们还支持在笔记本电脑上进行部署，包括专为GKE设计的笔记本电脑，为客户提供了在他们最熟悉的框架和推理实现中尝试各种部署选项的机会。

接下来，让我演示一下这种部署的具体过程。

我已经有一个集群准备好了——让我们检查一下，希望我已经正确配置了它。好的，看起来有一个节点在运行，我认为我已经设置好了一切。简而言之，这是一个全新的集群，没有任何部署。今天早些时候，我设置了一个Autopilot集群，目前上面还没有任何部署。接下来，我将带你经历整个部署流程。你在Model Garden UI中看到的那个YAML文件，基本上是这样的内容。这里包含了我们的Kubernetes清单，对于熟悉Kubernetes的人来说应该非常熟悉。我们从Vertex AI的可信容器中拉取镜像，并添加一些额外的配置，比如所需的CPU和GPU资源，以及一些附加信息，如Hugging Face令牌和所需的加速器类型。在这个例子中，我们将使用Nvidia L4进行推理。另外，由于这是一个70亿大小的模型，不适合放在单个GPU上运行，因此我们会将其分片到多个GPU上，并利用Nvidia和CCL进行分片处理。

现在，我们开始部署吧。这将包括部署一个服务和相关的应用。同时，我们还会展示一个简洁的Gradio UI界面。如果你愿意的话，我们可以稍等几分钟，让它自动配置。不过，这个过程可能有些枯燥。我会向你展示一个预先配置好的环境是什么样的。但请放心，Autopilot GKE会为你处理这些繁琐的事务。我们会为你提供所有所需的资源，包括加速器，并自动进行扩展。你只需与之交互即可。当你关闭它时，所有资源都会被释放；一个月后不会有意外的账单出现。

说实话，我的演示也没有无限的预算。当我完成演示后，我会关闭这些资源，确保账单归零。

现在，我们想要展示的是完全部署好的状态。那就开始吧。我先切换一下上下文。我们有一些pod正在运行，希望它们都已经准备就绪。哦，对了，我需要切换一下上下文。记得是哪个集群吗？没错，就是这个。我们有几个不同的应用正在运行。其中就有我们的TGI实现。我们可以通过cURL命令或其RESTful API端点来与之交互。但更有趣的方式是通过Gradio来与它互动。Gradio是一个基于聊天的界面，由我们在Hugging Face的朋友开发，使得与这些模型的交互变得非常有趣和直观。

观众：Gemma支持多少个token呢？

当前版本支持8000个token。

好的，这就是Gemma部署的大致情况。非常简单。在GKE中部署和扩展它简直就是易如反掌。你甚至可以在五分钟内或更短的时间内完成这个过程。

观众：是否将Gradio应用程序作为示例发布了？

是的，它实际上就在我们的文档中。如果你按照任何文档操作，你就会看到Gradio应用程序的示例。这是直接从我们网站上获取的内容。接下来我要向你展示的内容可能没有在文档中记录，但无论如何都非常有趣。我将演示如何实现RAG用例。

我们来谈谈Kubernetes吧。我想构建一个聊天应用程序，能为我提供有关Kubernetes信息的基本回复。我打算构建一个基于Kubernetes知识训练的向量数据库，并将响应注入到我的提示中，以实现基本理解和引用。

为此，我将使用LangChain来连接服务，测试一个提示，并利用提示工程技术请求Kubernetes信息。原始输出已经相当不错，但我还想进一步优化它。我将从Kubernetes.io中收集示例文档，为了提高效率，我将使用句子转换器在CPU上（虽然使用GPU可能更高效）以及在我的GKE集群上的Postgres PGvector数据库进行处理。我将整合所有内容，并使用嵌入模型和分块文档来更新（这里可能是指用户界面或某个组件，但原文中并未明确）。这个更新过程可能需要一两分钟。

在此运行的同时，我们可以利用作业和排队机制来扩展这个过程，就像我之前提到的那样。这是我们采取的可扩展方法，使用加速器进行定期训练作业。然后我们可以将这些响应链接在一起。

关于嵌入模型（embedding model），由于时间限制，我只能简要介绍一下。这是一个开源的句子转换器模型。Vertex AI还为此目的提供了多种嵌入模型供选择。

观众：Google是否提供托管的向量数据库服务？还是目前是由客户自己驱动的，他们将自己的数据库带到GKE集群中，或者使用Pinecone或类似的服务？

当然有。Vertex AI提供了一个完全托管的向量解决方案，实质上是一个搜索人工智能服务。我们在搜索数据和向量数据库方面有深厚的专业知识，提供了一个无缝集成的托管服务。这非常简单——你可以指向一个BigQuery数据集或其它数据集，比如CSV文件，并通过定期作业保持数据更新。这是我们的完全托管解决方案。我刚才展示的是如何自己构建它。

我不会深入探讨扩展的细节，但其实非常简单。我们可以观察我们的响应效果。例如，当我搜索“部署”时，我会收到一些带有引用的片段。然后我可以将其整合到LangChain模板中。

“解释Kubernetes概念”。实际上这个解释并不是最完美的。部署管理一组pod，并在不保持状态的情况下运行工作负载，这里增加了一些额外的上下文信息。让我们看看在Gradio中是什么样子。当我问同样的问题时，我收到了一个稍微简短的回答，我认为这是基于我的配置。我们还在这里添加了引文参考，因为它直接来自向量数据库。这是你可以将开放模型与基础模型结合使用的一种方式。

关于这些链接，它们都是来自向量数据库的真实链接。这是一个我们期望看到许多客户部署这些方法的领域，使用RAG技术。关于上下文窗口也存在一个重要的讨论点。在Gemma中，尽管有百万级的token上下文窗口，但真正需要多少RAG呢？这些问题仍然悬而未决，这使得这个领域在未来一年变得非常令人期待。

--【本文完】---

近期受欢迎的文章：

更多交流，可添加本人微信

（请附姓名/关注领域）