作者：Dean Wampler
译者：Carl Cui
1998 年，LAMP 的出现第一次清晰描述了用于构建网站的主要开源软件，也让无数开发者找到了构建 Web 应用的共同语言。二十多年后，生成式 AI 的浪潮同样呼唤一套属于这个时代的标准答案，PARK 栈由此而来。作者 Dean Wampler 在这篇文章中为我们展现了 AI 时代开源“风景”，更难得的是，作者在文章穿插了大量引用，方便感兴趣的读者继续探索。
1. 背景：LAMP 技术栈
根据 Wikipedia，LAMP 技术栈这个缩写是由 Michael Kunze 于 1998 年提出的，用于描述当时流行的用于构建网站的开源软件组合。在 20 世纪 90 年代初，随着万维网（WWW）的普及，各大组织使用各种专有工具和操作系统，外加一些开源软件（OSS - open source software）来构建网站。LAMP 技术栈迅速成为最受欢迎的开源组件集合。
LAMP 是一个缩写词，分别代表以下内容：
| 字母 | 组件 | 职责 |
|---|---|---|
| L | Linux | 操作系统 |
| A | Apache HTTP Server | 网络服务器 |
| M | MySQL | 数据库 |
| P | Perl、PHP 和/或 Python | 应用程序编程语言 |
在当时，依赖开源软件的想法是有争议的。因为源代码对所有人可见，人们担心缺乏支持和存在软件漏洞，最终这些问题解决了。开源之所以具有不可抗拒的吸引力，是因为流行的 OSS 项目提供了极大的灵活性、成本效益、无供应商锁定以及快速迭代。LAMP 堆栈成为企业采用开源的主要驱动力之一。
2. PARK 技术栈
就像互联网的兴起一样，大型语言模型（LLMs）、视觉模型（VMs）和其他生成式 AI 的突然爆发，促使人们去识别最适合生成式 AI 的 OSS 组件。这个时代出现了 PARK 技术栈。它是由 Ben Lorica 去年 11 月在文章 Trends Shaping the Future of AI Infrastructure 中首次提出的。
PARK 分别代表以下内容：
| 字母 | 组件 | 职责 |
|---|---|---|
| P | PyTorch | 模型训练与推理 |
| A | AI Models & Agents | 生成式 AI 的核心能力 |
| R | Ray | 细粒度分布式计算 |
| K | Kubernetes | 集群管理与基础设施编排 |
这里，我将简要介绍每一个缩写及其所满足的需求。
2.1 PyTorch
模型开发者需要软件用于模型训练和调优，应用开发者则需要使用模型和 agent 提供的推理能力。
PyTorch 起初是用于设计和训练各种机器学习模型的众多工具之一。现在，它是这方面最受欢迎的选择。PyTorch 被用于设计和训练世界上许多知名的生成式 AI 模型。其他的替代方案包括 JAX 及其前身 TensorFlow。
PyTorch 由 Meta 开发并开源，现在交由 PyTorch 基金会 维护。它的生态系统逐渐发展，囊括了更多的 项目，例如用于推理的 vLLM、用于分布式训练和推理的 DeepSpeed 和 Ray 以及许多库。
模型推理的成本推动了对像 vLLM 这样专门且高度优化的推理引擎的需求。尽管流行的推理引擎使用 PyTorch 库，但 PyTorch 很少单独出现。
顺便一提，生成式 AI 的兴起也导致了 Python 的复兴，部分原因是 Python 一直是数据科学最流行的语言，而生成式 AI 是其自然的一部分。
2.2 AI 模型和 Agent
生成式 AI 应用的独特能力是由一个或多个模型以及接入这些模型的 agents 提供的。第一波 AI 应用，通常是简单的聊天机器人，采用一个经过训练以很好地理解人类语言（尤其是英语）的单一模型。这个模型通过各种方式进行调优，以便有效地完成对话，例如避免不希望的言论、提供事实性输出等。
模型架构正在快速演进，包括构建更小、更强大的模型，以及使用一组模型（如 mixture of experts 架构）来保持结果质量的同时提供更高的效率。
然而，模型存在一些特定的缺点。例如，它们对训练后发生的事件一无所知，而且模型也不是在所有可能的专业数据上训练出来的，因此无法在每一个可能的领域发挥有效作用。于是，应用模式迅速出现，以补充模型的能力。第一种模式是 RAG（检索-增强-生成），即查询数据库以获取相关上下文信息，然后将这些信息作为上下文与用户查询一起发送给模型进行推理。
目前更通用的方法是 agent，其定义如下：“使用 AI 来实现目标并代表用户完成任务的软件系统。其表现出了推理、规划和记忆能力，并且具有一定的自主性，能够自主学习、适应和做出决定。” 实现用户目标可能意味着查找和检索相关的上下文数据、评估检索信息的质量和效用、总结发现、优雅地从错误中恢复等。
没有一种绝对的模型选择，也没有占据主导地位的“模型族系”。同样，也没有一种通用的 agent 框架。这反映了模型的快速演变和 agent 设计模式的多样性，同时也体现了 AI 应用的多样性，这使得任何单一选择都不太可能满足所有需求。
2.3 Ray
模型训练、调优以及模型推理需要不同的分布式计算模式，这些模式需要高度优化，因为生成式 AI 具有巨大的能耗和相关成本。对于最大的生成式模型，单 GPU 系统太小，无法处理这些任务。即使是对于较小的模型，大规模并行处理也能更有效地扩展这些过程。
模型训练和调优过程中，使用新数据进行追加训练时，需要进行大量的迭代。每次迭代中，数据都会流经模型，同时模型参数（权重）逐步调整以减少误差。整个训练迭代过程会占用较多的内存，并进行大量的数据交换。这些迭代必须快速高效。当模型参数分布在多个 GPU 上时，就需要非常高的带宽用来交换参数更新。
强化学习 Reinforcement learning 是调优的一部分，用于改进 更复杂的领域行为。强化学习也需要大量的快速迭代，但规模和数据访问模式通常更小、更细粒度、更多样化。
推理分布式计算与训练迭代的第一步相同，都是数据流经模型，只是前者没有参数更新步骤而已。
Ray 提供了满足这些不同需求的灵活性。它是一个细粒度的分布式编程系统，具有直观的 actor model 抽象。Ray 由加州大学伯克利分校的研究人员开发，他们需要一个高效且易于使用的系统来扩展强化学习和人工智能研究所需的计算。Ray 的抽象灵活性和实现效率使其非常适合生成式 AI 引入的新分布式计算需求。
Anyscale 是一个专注于将 Ray 产品化的初创公司。Ray 的核心组件最近已捐赠给 PyTorch 基金会。
2.4 Kubernetes
大规模模型训练和调优，以及可扩展的应用程序部署，带来了许多实际需求，包括管理异构硬件集群、其他资源和集群上运行的服务。Kubernetes 已经成为近十年来集群管理工具的业界标准，它源于 Google 的 Borg 项目，并得到了许多其他组织的贡献。Kubernetes 是 Linux 基金会的一部分。Kubernetes 的主要替代方案是各个云供应商提供的管理工具，如 AWS、Microsoft Azure、Google Cloud 等。Kubernetes 的优势在于它可以无缝地运行在这些平台上（直接使用平台提供的服务，或者在平台上“自行搭建”），或者本地运行，提供云服务的优势但无需绑定供应商。
乍一看，Ray 和 Kubernetes 的分布式功能似乎重叠，但实际上它们是互补的。Ray 适用于非常细粒度和轻量级的分布式计算和内存管理，而 Kubernetes 提供更粗粒度的管理以及现代环境中所需的一套广泛的服务（如安全、用户管理、日志和跟踪等）。在 Kubernetes 集群中的一组容器内运行容器化 Ray 应用程序是很常见的，Ray 在这些容器内构建自己的集群。Ray 和 Kubernetes 各有所长，优势互补。事实上，有开源的 KubeRay Operator，它允许你在 Kubernetes 上使用 Ray，而无需成为 Ray 或容器管理的专家。
3. PARK 缺少了什么？
LAMP 从未打算提供网站部署所需的一切。它是作为核心，然后按需添加其他服务。PARK 也是类似的，尽管 Kubernetes 的存在已经覆盖了大部分通用服务需求！
对于生成式 AI 应用，PARK 用户除了要考虑我们多年来一直使用的所有标准实践外，还需要思考新的需求。下面我们讨论几个。
3.1 数据和数据管理
传统的数据管理需求和实践仍然适用，但 AI agents 也在推动变革。Ben 关于 机器用户数据工程的文章 讨论了若干趋势。例如，一些提供商发现 agents 会创建一些新数据库表，这些表通常是短暂的。与人类相比，agents 对数据库查询错误的容忍度较低，并且对安全问题不太谨慎。
非结构化、多模态数据的重要性日益增长：包括视频、音频和文本。特定形式的结构化数据也在增长，例如用于 RAG 应用的 图数据库 和 向量数据库，以及用于更有效结构化数据的 特征存储。
3.2 Agent 编排
任何分布式系统都需要仔细管理组件之间的交互，以实现安全、资源管理和效率。MCP 和 A2A（agent to agent) 是几种新兴标准中的两种，它们允许模型发现可用的 agent 服务并自动学习如何使用它们。这些有前景的功能也引发了关于安全和加强控制的担忧，催生了针对诸如新网关和为满足 agent 特定需求进行裁剪的项目的出现，例如 ContextForge。类似地，成熟的工具正在添加支持功能，以满足相同的需求。
3.3 内存管理
Agents 必须管理和使用他们所获取的信息。这包括在模型的上下文限制内工作，并保留最有用的信息，以优化其资源使用和效率。AI agent memory 是一个持续的研究课题，涌现了很多 项目 以及 MemVerge、Mem0 这样的初创公司，它们强调短期（即单次会话）内存的有效使用。现有的持久化工具也被应用于这个问题，例如 Neo4j 和 Redis，它们还支持跨会话的长期记忆。
Dex 是一种新方法，它解决由 MCP 和 A2A 引起的一个特定挑战：推理上下文内存中添加的信息爆炸。这种内存是有限的，当上下文变得太大时，性能会迅速下降。Dex 将 agent 学到的知识（例如使用 MCP 学习如何查询 GitHub 获取仓库信息）转化为可重用的代码，这既消除了不必要的重复学习步骤，又在模型上下文之外确定性地执行任务。Dex 还提供了一种长期记忆形式。
4. 接下来是什么？
你对 PARK 技术栈有什么看法？你认为这四个组件与替代方案相比如何？你认为哪些 AI 应用需求需要更多关注？不妨在评论区聊聊。