大型语言模型（LLM）应用的快速增长与能源需求的快速增长息息相关。根据国际能源署（IEA）的数据，到 2026 年，数据中心的电力消耗预计将大致翻倍，主要由人工智能驱动。这是由于大型语言模型训练所需的能源密集型需求——然而，AI 推理工作负载的增加也发挥了作用。例如，与传统的搜索查询相比，单次 AI 推理可能消耗约10 倍的能源。
作为开发人员，我们直接影响着我们 AI 解决方案的能源密集程度。我们可以采取技术决策来帮助使我们的 AI 解决方案更具环境可持续性。将计算量最小化以提供 LLM 解决方案并非创建可持续 AI 用途的唯一要求。例如，可能需要政策干预等系统性变革，但利用能源效率高的解决方案是一个重要因素，也是我们现在就可以采取的有效干预措施。
话虽如此，最大限度地减少您的 LLM 推理云计算需求，也能减少您的云账单，并使您的应用程序更节能，从而实现双赢。在这篇博客中，我们将引导您完成创建 LLM 聊天机器人的步骤，通过优化和部署基于 PyTorch 的 Llama 3.1 模型，并量化特定架构决策的计算效率优势。
我们将评估什么？
在这篇博客中，我们的目标是创建一个沉浸式奇幻故事应用，用户通过与生成式 AI 聊天进入一个奇幻世界。第一个地点是“邪恶之地”（Land of Wicked），允许人们角色扮演在翡翠城中漫步，并实时观察景物。我们将通过聊天机器人和自定义系统提示来实现这一点。
我们将在 CPU 上评估 LLM 性能。您可以在此处查看 CPU 与 GPU 推理的优势。一般来说，对于 Llama 系列等参数量在 10 亿或更少的模型，在云端利用 CPU 进行 LLM 推理是一个不错的选择。
我们还将使用基于 Arm 的 CPU，特别是 AWS Graviton 系列。根据研究，基于 Arm 的 Graviton3 服务器可以提供降低 67.6% 的内置工作负载碳强度。尽管这项研究基于模拟，但它为最小化我们应用的能源需求展示了可能性，这是一个很好的开端。
首先，您将了解如何在 PyTorch 上运行一个简单的 LLM 聊天机器人，然后探索三种技术来优化您的应用程序以提高计算效率
- 模型优化：利用 4 位量化和增加的 KleidiAI 内核。
- 快捷优化：实现向量数据库以处理常见查询。
- 架构优化：采用无服务器架构。
让我们开始吧。
通过 PyTorch 在 AWS Graviton4 上运行 Llama-3.1
为了最大限度地提高能源效率，我们将仅使用支持此 LLM 聊天机器人所需的最小服务器资源。对于这个Llama-3.1 80 亿参数模型，需要 16 核、64GB 内存和 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
接下来，通过命令行从 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”以输入系统提示，然后输入以下提示
你是一个奇幻冒险应用的引导叙述者。让用户沉浸在《邪恶之地》的迷人世界中，引导他们在翡翠城进行互动式实时体验。描述生动的景象，动态的场景，并让用户参与到感觉鲜活和响应迅速的故事讲述中。允许用户做出选择，塑造他们的旅程，同时保持《邪恶之地》宇宙的魔幻基调。
然后输入您的用户查询
我穿过翡翠城门，抬头望去
输出将显示在屏幕上，生成第一个 token 大约需要 7 秒，每秒不足 1 个 token。
这个例子花了 245 秒，也就是 4 分钟，才生成完整的回复——速度不快。我们将要讨论的第一个优化将加快 LLM 的生成速度，减少其计算占用空间。
优化 1：KleidiAI 和量化
上述基本实现可以进行多项优化。最简单快捷的方法是将模型从 FP16 量化到 INT4。这种方法牺牲了一些精度，同时将模型大小从 16GB 缩减到约 4GB，从而提高了推理速度。
另一个常见的优化是利用 TorchAO（Torch 架构优化），这是 PyTorch 库，与 TorchChat 无缝协作，通过各种量化和稀疏化方法增强模型性能。
最后，我们将使用 Arm KleidiAI 优化。这些是使用汇编语言编写的微内核，可显著提高 Arm CPU 上 LLM 推理的性能。如果您感兴趣，可以阅读更多关于KleidiAI 内核如何工作的信息。
要实现这些优化，请启动一个新的 EC2 实例，并按照如何使用 PyTorch 运行大型语言模型（LLM）聊天机器人的说明进行操作。准备好后，运行模型并输入与上述相同的系统提示和用户查询。您将获得显著加快推理速度的结果：第一个 token 不到 1 秒，每秒约 25 个 token。
这将推理时间从 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 存在两个显著限制，首先是 token 生成速度。回想一下，基于服务器的方法通过 KleidiAI 优化实现了大约 25 token/秒的速度。而无服务器方法的速度则慢了一个数量级，我们测得大约为 2.5 token/秒。这个限制主要源于 Lambda 函数部署在 Graviton2 服务器上。当部署转移到具有更多 SIMD 通道的 CPU，例如 Graviton3 和 Graviton4 时，token/秒的速度应该会随着时间的推移而增加。在此处了解更多关于 Graviton3 中引入的架构优化信息：Arm Neoverse-V1 CPU。
这种较慢的速度限制了无服务器 LLM 架构的可用案例，但在某些情况下这可以被视为一种优势。在我们互动式讲故事的用例中，缓慢地揭示信息会营造一种沉浸感，建立期待并模仿实时叙述。其他用例包括
- 引导冥想应用，以缓慢、放松的语速进行讲解
- 虚拟朋友进行深思熟虑的对话，或治疗性对话。
- 诗歌创作或互动艺术，通过缓慢的呈现营造沉思的美感。
在合适的应用程序中，用户可能会在较慢的 token 生成速度下获得更好的体验。当优先考虑更可持续的解决方案时，限制最终会变成优势。打个比方，对现代电影的一个常见批评是它们过度依赖视觉特效，导致故事情节不如老电影引人入胜。视觉特效的成本限制意味着老电影必须精心打造引人入胜的对话，利用娴熟的镜头角度和角色定位来充分吸引观众。同样，专注于可持续的 AI 架构，如果深思熟虑，也能带来更具吸引力、更沉浸式的体验。
LLM 推理的第二个无服务器限制是大约 50 秒的冷启动时间。如果实现不佳，用户等待 50 秒而没有其他替代方案，很可能会离开应用程序。您可以通过一些设计技巧将此限制转化为我们基于“邪恶之地”体验中的一个特色
- 创建一个“序幕体验”，通过硬编码的问题和答案引导用户，为他们在翡翠城中的落脚点做好准备，并收集输入以塑造他们即将到来的体验。
- 将等待期设置为倒计时器，揭示故事或世界构建的硬编码文本片段。一个角色，如巫师，可以通过碎片化的台词与用户交流，以制造悬念，并引导用户进入正确的心境。
- 创作一段带有电影或音乐剧音乐的音频介绍，并辅以旋转的视觉效果，将用户吸引到“邪恶之地”的氛围中。
跳出思维定式
实施以可持续性为导向的解决方案架构，包括但不限于优化您的 AI 推理。了解用户将如何与您的系统交互，并相应地调整您的实施。始终优化每秒快速 token 或第一个 token 的时间将掩盖引人入胜的功能的机会。
话虽如此，您应该尽可能利用直接的优化。使用 TorchAO 和 Arm KleidiAI 微内核是加速您的 LLM 聊天机器人的好方法。通过结合创新的解决方案架构并尽可能进行优化，您可以构建更可持续的基于 LLM 的应用程序。祝您编程愉快！