Python + Docker 还是 Rust + WebAssembly？-编程知识

在不断发展的技术世界中，由大语言模型驱动的应用程序，通常被称为“LLM 应用”，已成为各种行业技术创新背后的驱动力。随着这些应用程序的普及，用户需求的大量涌入对底层基础设施的性能、安全性和可靠性提出了新的挑战。

Python 和 Docker 一直是构建机器学习应用程序的主流选择。然而，当涉及到为大型语言模型（LLM）应用程序构建基础设施时，这种组合的一些缺点变得更加严重，例如 Python 的性能问题和 Docker 的冷启动问题。本演讲重点关注为 LLM 生态构建基础设施的主要场景，并深入探讨 Python 和 Docker 组合的问题，更重要的是，为什么 Rust + WebAssembly (WASM) 优于 Python + Docker。最后，我们将演示如何在 flows.network 平台上构建一个代码检查机器人。

现有解决方案：Python + Docker 方法

在机器学习领域，Python 几乎称王，主要得益于以下三个特点：

易于学习： Python 是一种高级语言，语法简单，易于学习和使用。对于 AI 新手或需要快速原型设计和测试想法的开发者，这可能至关重要。
庞大的社区： Python 拥有庞大且活跃的开发者社区，这意味着有许多库和工具可用于 AI 开发。对于需要快速找到常见问题解决方案的开发者来说，这是个优势。
灵活性： Python 用途多样，可用于广泛的 AI 任务，包括数据分析、机器学习和自然语言处理。对于需要从事多个 AI 项目的开发者而言很有吸引力。

Docker 容器作为当今最流行的容器管理工具之一，为应用部署提供了极大的便利：

可移植性： Docker 容器被设计为可移植的，这意味着它们可以在不同环境之间轻松移动。对于需要将 AI 应用程序部署到多个平台或云提供商的开发者来说，这可能是一个优势。
隔离： Docker 容器在应用程序和主机操作系统之间提供了高度的隔离，可以提高安全性和稳定性。对于需要高级别安全性的组织来说，这可能是一个优势。
可扩展性： Docker 容器可以轻松扩展或缩小以满足不断变化的需求，这对于需要大量计算或需要处理大型数据集的 AI 应用程序来说是一个优势。

对于传统机器学习应用的开发和部署，Python+Docker 模式展现了其优势。然而，在 LLM 生态的基础设施建设中，却面临着挑战。

Python + Docker 的挑战

Python 和 Docker 的优点自然也带来了一些缺点。然而，在 LLM 生态基础设施建设的过程中，这些缺陷变得更加突出，成为关键障碍。让我们先看看 Python 存在的问题。

Python 的缺点

性能瓶颈

Python 是一种解释性语言，这意味着它可能比 C++ 或 Rust 等编译语言慢。当处理需要大量计算的大型数据集或复杂模型时，这可能是一个缺点。

在图 1 中，前三行分别显示了用 Python、Java 和 C 编写的将两个 4096 x 4096 矩阵相乘的编程性能。从“运行时间（秒）”一栏的统计数据可以看出，（1）Java（作为静态编程语言）比 Python（作为动态编程语言）快 10 倍；(2) C（作为非 GC 编程语言）比 Python（作为 GC 编程语言）快 50 倍。

图 1 程序性能工程的加速将两个 4096×4096 矩阵相乘。

并行性 Python 的全局解释器锁 (GIL) 通常被认为是并行执行时的限制。GIL 确保单个进程中一次只有一个线程执行 Python 字节码，这会阻碍多核处理器的充分利用并影响并行性能。
内存管理 Python 的动态类型和垃圾收集会带来内存管理的开销。虽然垃圾收集器有助于自动内存管理，但有时会导致效率低下，特别是在实时性能至关重要的情况下。

混合编程：Python + C/C++/Rust

为了改善 Python 语言本身的性能问题，常见的做法是使用 Python 作为负责与用户交互的前端语言，同时选择 C/C++/Rust 等高性能编程语言作为后端语言来处理繁重的计算任务。Python 生态中很多知名库都采用这种方式来满足高性能计算的需求，比如 Numpy。然而，这种混合编程方法不可避免地需要额外的工具（或库）作为“连接”两种不同编程语言的桥梁。因此，这个过程可能会带来新的问题。

维护成本

假设我们想要“绑定” Python 和 C++ API，我们必须使用第三方库来自动化这个转换过程，例如 Pybind11。图 2 中的示例代码展示了如何使用 Pybind11 “绑定” C++ 和 Python 程序。不难看出，尽管 Pybind11 极大地简化了转换过程，但添加或删除任何 C++ API 都需要对转换代码进行相应的更改，并且更改的难度与变更内容密切相关。从成本角度来看，这个过程不仅增加了开发者的学习成本，也增加了项目的开发和维护成本。

图 2 将 C++ 和 Python“粘合”在一起。

可移植性问题

混合编程可能会带来可移植性挑战。由于 Python 与本机库交互的方式或不同环境中的系统级依赖关系存在差异，在一个平台上无缝运行的代码可能会在另一个平台上遇到问题。

集成复杂性

如图 2 所示，将 Python 与其他语言绑定通常需要仔细管理数据类型、内存分配和错误处理。尽管有第三方库可以改进绑定任务，例如 Pybind11，但这种“粘合”过程仍然容易出错，并且需要对 Python 和所使用的其他语言有深入的了解。这会在一定程度上增加开发时间和风险。

Docker 容器的局限性

冷启动性能

Docker 容器虽然高效，但有时会面临冷启动性能的挑战。“冷启动”是指容器实例化后开始运行所需的时间。就 Docker 而言，启动时间通常为秒级。这可能看起来不多，但在快速扩展和响应能力至关重要的环境中，这些时间可能会导致明显的延迟并降低用户满意度。

磁盘空间消耗

Docker 容器有时可能非常庞大，消耗的磁盘空间达到千兆字节 (GB) 的量级。当容器包含所有必要的依赖项和运行时环境时尤其如此。如此大的容器大小可能会导致存储成本增加、部署时间变慢以及管理和分发容器映像方面的挑战。

硬件加速器支持

虽然 Docker 容器可以利用硬件加速器来提高性能，但有一个问题。他们通常需要特定版本的软件来确保兼容性。这意味着组织可能需要维护多个版本的容器或更新其硬件加速器以满足软件要求，从而增加了复杂性和管理开销。

可移植性问题

Docker 的主要卖点之一是它的可移植性。然而，这种可移植性有时取决于 CPU 架构。虽然 Docker 容器被设计为在不同环境中一致运行，但在不同 CPU 架构之间移动时可能会存在差异。这可能会给确保不同部署环境中的一致性能和行为带来挑战。

安全依赖

Docker 容器依赖主机操作系统的用户权限来保证安全。这意味着容器的安全性在一定程度上依赖于底层操作系统的安全配置。如果主机操作系统受到损害或配置错误，则可能会使容器面临安全漏洞。

这些限制凸显了对替代解决方案的需求，例如 Rust + WebAssembly，它有望解决其中一些痛点，并为部署 LLM 应用程序提供更高效、更安全的环境。

AGI 将是由 Rust 和
WebAssembly 构建

为什么 Rust 和 WebAssembly 可以成为 AGI 的语言？

Rust：AGI 时代的最佳选择

性能。 Rust 是一种编译语言，以其极快的性能而闻名。当与基于堆栈的虚拟机的二进制指令格式 WebAssembly 结合使用时，这两个组合有望提供无与伦比的执行速度。
内存安全。 Rust 的突出特点之一是它强调内存安全而不牺牲性能。这确保了应用程序既快速又安全。
并发性。 Rust 的并发性方法是独一无二的。它确保在编译时捕获数据竞争（并发系统中最常见和最具挑战性的错误之一）。这意味着开发者可以编写并发代码，而不必担心引入难以检测的运行时错误。
富有表现力的类型系统。 Rust 拥有强大且富有表现力的类型系统。该系统不仅有助于在编译时捕获错误，而且还允许开发者以清晰简洁的方式表达他们的意图。
现代包管理。 Cargo，Rust 的包管理器，简化了管理依赖项、构建项目甚至发布库的过程。因其易用性和高效性而受到赞誉的工具。
快速增长的生态。 Rust 的生态正在蓬勃发展。像“ndarray”、“llm”、“candle”和“burn”这样的库证明了社区积极参与扩展 Rust 的能力。

WASM 容器：更快、更轻、更安全

Shivraj Jadhav 从多个维度比较了 Docker 容器和 WASM。

表 1 WASM 与 Docker

可移植性。 WebAssembly 被设计为用于编译高级语言的可移植目标，允许部署在 Web 和服务端，跨不同硬件。
沙箱机制。 WebAssembly 引入了沙箱机制，提供更安全的生产环境。这可以确保代码在隔离的环境中运行，从而最大限度地减少潜在风险。
保护用户数据和系统资源。 WebAssembly 的设计考虑了安全性。它确保用户数据和系统资源免受潜在威胁。
字节码验证。 在执行之前，WebAssembly 字节码会经过验证过程，以防止恶意代码运行。这增加了额外的安全层。
隔离执行环境。 WebAssembly 中的模块在隔离环境中运行。这意味着即使一个模块出现问题，也不会影响其他模块的正常运行。
占用空间更小。 使用 Rust 和 WebAssembly，开发者可以事半功倍。编译后的代码通常要小得多，从而加快加载时间并提高执行效率。

WASI-NN 标准

除了上述优点之外，WebAssembly 针对机器学习应用的 WASI-NN 标准也是一个重要因素。

主流机器学习推理引擎。 WASI-NN 旨在与流行的机器学习推理引擎（如 TensorFlow、PyTorch 和 OpenVINO）无缝协作。
大型语言模型的扩展。 借助“Llama2.c”和“llama.cpp”等工具和库，WASI-NN 提供为大型模型应用程序量身定制的功能，确保开发者拥有他们需要的的工具，以处理广泛的数据集和复杂的模型。

最新发布的 WasmEdge 0.13.5 已经支持使用 Rust 和 Wasm 运行 llama2 系列大模型，包括但不限于我们熟知的 Codellama、Mistral、OpenChat、BELLE-Llama2、Yi-34B 等等。详情请查看 llama-utils。

应用场景：代码检查代理（Agent）

在本节中，我们将演示如何使用“flows.network”平台构建代码检查代理。在深入讨论具体示例之前，我们首先看一下“Agent”和“flows.network”平台的概念模型。

Agent 的概念模型

这是 Lilian Weng 提出的基于 LLM 的 AI Agent 的概念框架。

图 3 LLM 驱动的自治代理系统概述

在这个模型中，LLM 函数扮演了智能体大脑的角色，负责核心推理和决策，但它仍然需要额外的模块来启用关键能力：规划、长 / 短期记忆和工具使用。

“flows.network”平台是基于与 Lilian 提出的模型类似的理念构建的。图 4 显示了其主要组件。整个平台是用 Rust 编写的，编译为 wasm 模块，并在 WasmEdge Runtime 上运行。

图 4 Flows.network 的主要组件

代码检查代理

在“flows.network”平台上，我们提供了一个代理（一个机器人模版）来帮助 GitHub 上开源项目的维护者审核 PR。将其命名为“代码检查机器人”。

代理的抽象设计如图 5 所示。图中中心的红色块code-review-function 定义了核心代理函数，而红色块周围的每个虚线圆圈与直接连接到图 3 中“代理”块的对应部分相匹配。

图 5 Code Review Bot 抽象设计

图 6 描述了Code Review Bot的架构。除了 GitHub Service 等外部资源外，代理由 wasm 模块组成，并在 WasmEdge Runtime 上运行。集成 wasm 模块负责通过 Web API 将 WebAssembly 函数连接到外部资源。例如，“code-review-function” wasm 模块将审核中的代码提取为提示词，然后“openai-integration” wasm 模块将提示词发送到 ChatGPT 服务并等待响应；最后，将评论发送到 code-review-function wasm 模块。