大型语言模型（LLM）应用的快速增长与能源需求的快速增长息息相关。根据国际能源署（IEA）的数据，到 2026 年，数据中心的电力消耗预计将大致翻倍，这主要受人工智能驱动。这是由于大规模 LLM 的能源密集型训练要求——然而，人工智能推理工作量的增加也起着作用。例如，与传统的搜索查询相比，单次人工智能推理的能耗可能高出约10 倍。
作为开发者，我们直接影响我们的 AI 解决方案的能源密集程度。我们可以采取一些技术决策来帮助我们的 AI 解决方案更具环境可持续性。最小化计算量以交付 LLM 解决方案并非创建可持续 AI 使用的唯一要求。例如，可能需要政策干预等系统性变革，但利用能源效率高的解决方案是一个重要因素，也是我们可以立即采纳的有效干预措施。
话虽如此，最小化 LLM 推理的云端计算需求也会降低您的云账单，并使您的应用程序更节能，从而实现双赢。在这篇博客中，我们将引导您完成通过优化和部署基于 PyTorch 的 Llama 3.1 模型来创建 LLM 聊天机器人的步骤，并量化特定架构决策的计算效率优势。
我们将评估什么？
在这篇博客中，我们的目标是创建一个沉浸式奇幻故事讲述应用程序，用户通过与生成式 AI 聊天进入一个奇幻世界。第一个地点是“邪恶之地”，允许人们角色扮演在翡翠城中漫步，并实时观察景色。我们将通过聊天机器人和自定义系统提示来实现这一点。
我们将在 CPU 上评估 LLM 性能。您可以在此处查看CPU 与 GPU 推理的优势。一般来说，在云中使用 CPU 进行 LLM 推理对于参数量约为 10B 或更少的模型（如 Llama 系列）是一个很好的选择。
我们还将使用基于 Arm 的 CPU，特别是 AWS Graviton 系列。根据研究，基于 Arm 的 Graviton3 服务器可以提供内置的 67.6% 更低的工作负载碳强度。虽然这项研究是基于模拟的，但它是一个很好的开端，展示了最小化我们应用程序能源需求的可能性。
首先，您将了解如何在 PyTorch 上运行一个简单的 LLM 聊天机器人，然后探索三种优化应用程序以提高计算效率的技术
- 模型优化：利用 4 位量化和添加 KleidiAI 内核。
- 快捷方式优化：实现向量数据库来处理常见查询。
- 架构优化：采用无服务器架构。
让我们开始吧。
在 AWS Graviton4 上通过 PyTorch 运行 Llama-3.1
为了最大限度地提高能源效率，我们将仅使用支持此 LLM 聊天机器人所需的最小服务器资源。对于这个Llama-3.1 8 亿参数模型，需要 16 核、64GB RAM 和 50GB 磁盘空间。我们将使用运行 Ubuntu 24.04 的 r8g.4xlarge Graviton4 实例，因为它符合这些规格。
启动此 EC2 实例，连接到它，并开始安装所需组件
sudo apt-get update
sudo apt install gcc g++ build-essential python3-pip python3-venv google-perftools -y
然后安装 Torchchat，这是 PyTorch 团队开发的库，可实现跨设备运行 LLM
git clone https://github.com/pytorch/torchchat.git
cd torchchat
python3 -m venv .venv
source .venv/bin/activate
./install/install_requirements.sh
接下来，通过 CLI 从 Hugging Face 安装 Llama-3.1-8b 模型。您首先需要在您的 HF 账户上创建一个 Hugging Face 访问令牌。这将把 16GB 的模型下载到您的实例中，这可能需要几分钟。
pip install -U "huggingface_hub[cli]"
huggingface-cli login
<enter your access token when prompted>
python torchchat.py export llama3.1 --output-dso-path exportedModels/llama3.1.so --device cpu --max-seq-length 1024
现在您已准备好运行 LLM 模型，添加一个系统提示，使其成为《邪恶之地》中的引导故事讲述者。
LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libtcmalloc.so.4 TORCHINDUCTOR_CPP_WRAPPER=1 TORCHINDUCTOR_FREEZING=1 OMP_NUM_THREADS=16 python torchchat.py generate llama3.1 --device cpu --chat
输入“y”以进入系统提示并输入以下提示
您是奇幻冒险应用程序的引导故事讲述者。让用户沉浸在《邪恶之地》的迷人世界中，引导他们通过翡翠城的互动、实时体验。描述生动的景象、动态的场景，并让用户参与到感觉真实且响应迅速的故事讲述中。允许用户做出选择来塑造他们的旅程，同时保持《邪恶之地》宇宙的魔幻基调。
然后输入您的用户查询
我穿过翡翠城的大门，抬头望去
输出将显示在屏幕上，生成第一个令牌大约需要 7 秒，每秒不到 1 个令牌。
此示例耗时 245 秒（即 4 分钟）才生成完整回复——速度不快。我们将探讨的第一个优化将加快 LLM 生成速度，从而减少其计算足迹。
优化 1：KleidiAI 和量化
在上述基本实现的基础上，可以进行多种优化。最简单快捷的方法是将模型从 FP16 量化到 INT4。这种方法以牺牲一些精度为代价，将模型大小从 16Gb 减小到约 4Gb，并在此过程中提高了推理速度。
另一个常见的优化是利用 TorchAO（Torch Architecture Optimization），这是一个与 TorchChat 无缝协作的 PyTorch 库，通过各种量化和稀疏方法来增强模型性能。
最后，我们将使用 Arm KleidiAI 优化。这些是使用汇编语言编写的微内核，可显著提高 Arm CPU 上 LLM 推理的性能。如果您感兴趣，可以阅读更多关于KleidiAI 内核如何工作的信息。
要实现这些优化，请启动一个新的 EC2 实例，并按照如何使用 PyTorch 运行大型语言模型 (LLM) 聊天机器人的说明进行操作。准备就绪后，运行模型并输入与上面相同的系统提示和用户查询。您将获得显著加快推理速度的结果：第一个令牌生成时间不到 1 秒，每秒约 25 个令牌。
这将推理时间从 245 秒缩短到大约 10 秒。这使得您的服务器的功耗降低，因为它花费更多时间处于空闲状态，而不是运行耗电的推理。在其他条件相同的情况下，这是一种比未优化应用程序更具碳友好性的解决方案。接下来的两种方法超越了模型推理优化，通过修改解决方案架构来进一步减少计算负载。
优化 2：FAISS 用于匹配常见问题的数据库
正如引言中所述，模型推理通常比其他搜索技术计算成本更高。如果您可以自动响应常见用户查询而无需执行 LLM 推理怎么办？使用查询/响应数据库是一种绕过 LLM 推理并有效响应的选项。对于这个互动式故事讲述应用程序，您可以想象关于特定角色、世界本身以及聊天机器人能/不能做什么的规则的常见问题，这些问题都可以有预先生成的答案。
然而，传统的精确匹配数据库不足以应对用户以多种方式表达同一查询的情况。询问聊天机器人的能力都可能得到相同的答案，但表达方式不同：
- “你能做什么？”
- “告诉我你能做什么。”
- “我如何与你互动？”
通过理解用户的意图，将用户的查询与最相关的预生成答案进行匹配，实现语义搜索可以解决这个问题。FAISS 库是实现语义搜索的一个很好的选择。
这种方法节省的计算量取决于三个因素：
- 可以通过语义搜索而不是 LLM 提供服务的用户查询百分比。
- 运行 LLM 推理的计算成本。
- 运行语义搜索的计算成本。
节省的计算量方程为
Computational_savings = (% of queries) * (LLM_cost – search_cost).
这种类型的架构在几种情况下是合理的。一种情况是如果您的系统有许多重复问题的常见查询。另一种情况是具有数十万传入查询的大规模系统，其中很小的百分比节省也能累积成有意义的改变。最后，如果您的 LLM 推理与搜索成本相比计算成本非常高，特别是对于更大参数的模型。
最终的优化方法是从服务器过渡到无服务器。
优化 3：无服务器方法
使用无服务器架构受欢迎的原因有很多，其中之一就是只为活动的计算时间付费，并消除了空闲服务器的成本。空闲服务器需要大量的电力来维持运行，在等待时浪费能源。
这种成本效益转化为一种本质上更环保的架构，因为它减少了浪费的能源消耗。此外，多个应用程序共享底层物理基础设施，提高了资源效率。
要设置您自己的无服务器聊天机器人，您需要首先使用包含 Lambda 入口函数 lambda_handler 的 Python 脚本，将量化的 Llama-3.1-8b 与 TorchChat、TorchAO 和 Arm KleidiAI 优化一起容器化。一种部署选项是将您的容器上传到 AWS ECR 并将容器附加到您的 Lambda 函数。然后设置 API Gateway WebSocket 或类似服务，通过 API 与您的 Lambda 进行交互。
使用无服务器架构来托管您的 LLM 有两个显著的限制，首先是令牌生成速度。回想一下，基于服务器的方法通过 KleidiAI 优化实现了大约 25 令牌/秒的速度。无服务器方法的速度慢了一个数量级，我们测量到大约 2.5 令牌/秒。此限制主要是由于 Lambda 函数部署在 Graviton2 服务器上。当部署转移到具有更多 SIMD 通道的 CPU（如 Graviton3 和 Graviton4）时，令牌/秒的速度应该会随时间增加。通过此处了解更多关于 Graviton3 中引入的架构优化，了解 Arm Neoverse-V1 CPU。
这种较慢的速度限制了无服务器 LLM 架构的可用场景，但在某些情况下，这也可以被视为一种优势。在我们互动式故事讲述的用例中，缓慢地揭示信息会营造一种沉浸感，建立预期并模仿实时叙述。其他用例包括：
- 引导冥想应用程序，提供缓慢、放松的文字输出。
- 虚拟朋友进行深思熟虑的对话，或治疗性对话。
- 诗歌生成或互动艺术，通过缓慢的输出营造沉思的美感。
在正确的应用程序中，用户可能会在较慢的令牌生成速度下获得更好的体验。当优先考虑更可持续的解决方案时，限制最终会变成优势。打个比方，当今现代电影的一个常见批评是，它们过度依赖视觉效果导致故事情节不如老电影引人入胜。视觉特效的成本限制意味着老电影必须精心制作引人入胜的对话，利用巧妙的摄影角度和人物站位来充分吸引观众。同样，专注于可持续的人工智能架构，如果用心设计，也可以带来更具吸引力、更身临其境的体验。
LLM 推理的第二个无服务器限制是约 50 秒的冷启动时间。如果实施不当，用户等待 50 秒而没有替代方案很可能会离开应用程序。您可以通过几种设计技巧将此限制转化为我们基于《邪恶之地》的体验中的一个特点：
- 创建一个“序言体验”，引导用户完成硬编码的问题和答案，为他们即将在翡翠城降落做好准备，并收集输入以塑造他们即将到来的体验。
- 将等待期设为倒计时器，显示故事或世界构建的硬编码文本片段。一个角色，如巫师，可以与用户通过碎片化的台词进行交流，以制造悬念并引导用户进入正确的心境。
- 制作一个音频介绍，配上电影或音乐剧中的音乐，以及旋转的视觉效果，将用户吸引到《邪恶之地》世界的氛围中。
跳出固有思维
实施以可持续性为导向的解决方案架构包括但不限于优化您的人工智能推理。了解用户将如何与您的系统交互，并相应地调整您的实施规模。总是为了快速的每秒令牌数或首次令牌生成时间进行优化，将隐藏引人入胜的功能机会。
话虽如此，您应该尽可能利用直接的优化。使用 TorchAO 和 Arm KleidiAI 微内核是加速 LLM 聊天机器人的好方法。通过结合创新的解决方案架构并在可能的情况下进行优化，您可以构建更可持续的基于 LLM 的应用程序。祝您编程愉快！