大型语言模型 (LLM) 应用的快速增长与能源需求的激增息息相关。根据国际能源署 (IEA) 的预测，受人工智能驱动，数据中心的用电量预计到 2026 年将翻一番左右。这不仅是因为大规模 LLM 对训练过程有高能耗需求，AI 推理工作负载的增加也起到了重要作用。例如，与传统的搜索查询相比，单次 AI 推理过程所消耗的能量大约高出 10 倍。
作为开发者，我们直接影响着 AI 解决方案的能耗强度。我们可以通过技术决策，使 AI 解决方案在环境方面更具可持续性。交付 LLM 解决方案时，尽量减少算力消耗并不是创建可持续 AI 的唯一要求。例如，可能还需要政策干预等系统性变革，但采用节能解决方案是一个重要因素，也是我们可以立即采取的有效干预措施。
话虽如此，最大限度地减少 LLM 推理所需的云算力，不仅能降低云成本，还能提高应用的能效，实现双赢。在这篇博客中，我们将引导您通过在 PyTorch 上优化并部署 Llama 3.1 模型来创建 LLM 聊天机器人，并量化特定架构决策所带来的计算效率收益。
我们将评估什么？
对于本篇博客，我们的目标是创建一个沉浸式奇幻故事应用，用户可以通过与生成式 AI 聊天进入奇幻世界。第一个场景是“Wicked（魔法坏女巫）”之地，允许用户进行角色扮演，在翡翠城中漫步并实时观察景象。我们将通过聊天机器人和自定义系统提示词来实现这一点。
我们将评估 LLM 在 CPU 上的表现。您可以在此处查看 CPU 推理与 GPU 推理的对比优势。总体而言，对于 Llama 系列等参数量在 10B 左右或更小的模型，在云端利用 CPU 进行 LLM 推理是一个非常好的选择。
我们还将使用基于 Arm 的 CPU，特别是 AWS Graviton 系列。根据相关研究，基于 Arm 的 Graviton3 服务器可使工作负载的碳强度降低 67.6%。虽然该研究基于模拟环境，但这对于展示如何最大限度地降低应用能源需求提供了绝佳的起点。
首先，您将了解如何在 PyTorch 上运行简单的 LLM 聊天机器人，然后探索三种优化计算效率的应用程序技术：
- 模型优化：利用 4 位量化并添加 KleidiAI 内核。
- 捷径优化：实现向量数据库以处理常见查询。
- 架构优化：采用无服务器 (Serverless) 架构。
让我们开始吧。
在 AWS Graviton4 上通过 PyTorch 运行 Llama-3.1
为了最大限度地提高能效，我们将仅使用支持此 LLM 聊天机器人所需的最小服务器资源。对于这款 Llama-3.1 80 亿参数模型，需要 16 核 CPU、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
接下来，通过 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 模型，并添加一个系统提示词，使其成为“Wicked”之地的引导式故事讲述者。
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”以输入系统提示词，并输入以下内容：
你是奇幻冒险应用的引导式故事讲述者。让用户沉浸在“Wicked”的迷人世界中，引导他们在翡翠城进行互动式实时体验。描述生动的景象、动态的场景，并以充满活力和响应迅速的方式与用户互动。允许用户做出塑造旅程的选择，同时保持“Wicked”世界的神奇基调。
然后输入您的用户查询：
我穿过翡翠城的大门，抬头仰望。
屏幕将显示输出结果，生成第一个 token 大约需要 7 秒，速度不到每秒 1 个 token。
这个示例花了 245 秒（即 4 分钟）才生成完整回复——速度并不理想。我们将研究的第一个优化方案将加速 LLM 生成过程，减少其计算足迹。
优化 1：KleidiAI 和量化
在上述基础实现的基础上，可以进行多种优化。最简单且最快捷的方法是将模型从 FP16 量化为 INT4。这种方法在牺牲少量精度的同时，将模型大小从 16GB 缩减至约 4GB，并在此过程中提高了推理速度。
另一种常见的优化是利用 TorchAO (Torch Architecture Optimization)，这是一个与 TorchChat 无缝协作的 PyTorch 库，通过各种量化和稀疏化方法增强模型性能。
最后，我们将使用 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：无服务器 (Serverless) 方法
使用无服务器架构很受欢迎，原因之一是只需为活跃计算时间付费，并消除了空闲服务器的成本。空闲服务器需要不可忽视的电量来维持运行，在等待时浪费能源。
这种成本效率转化为本质上更环保的架构，因为它减少了浪费的能源消耗。此外，多个应用共享底层物理基础设施，提高了资源利用率。
要建立您自己的无服务器聊天机器人，首先需要将量化后的 Llama-3.1-8b 与 TorchChat、TorchAO 和 Arm KleidiAI 优化封装在容器中，并编写包含 Lambda 入口函数 lambda_handler 的 Python 脚本。一种部署选择是将您的容器上传到 AWS ECR，并将容器附加到 Lambda 函数。然后设置 API Gateway WebSocket 或类似接口，通过 API 与您的 Lambda 交互。
使用无服务器架构托管 LLM 有两个显著限制，首先是 token 生成速度。回想一下，基于服务器的方法在 KleidiAI 优化下可提供约 25 个 token/秒。无服务器方法的速度慢了一个数量级，我们测得大约为 2.5 个 token/秒。这种限制主要源于 Lambda 函数部署在 Graviton2 服务器上。当部署迁移到具有更多 SIMD 通道的 CPU（如 Graviton3 和 Graviton4）时，token/秒应会随着时间增加。了解更多关于通过 Arm Neoverse-V1 CPU 在 Graviton3 中引入的架构优化。
这种较慢的速度限制了无服务器 LLM 架构的可行用例，但在某些情况下这可以被视为一种优势。在我们交互式故事的用例中，缓慢显示信息可以创造沉浸感，建立预期并模仿实时叙事。其他用例包括：
- 带有缓慢、舒缓文字呈现的引导式冥想应用。
- 进行深思熟虑对话的虚拟朋友，或治疗性对话。
- 诗歌生成或交互式艺术，通过缓慢的呈现创造沉思的审美。
在合适的应用中，用户可能会对较慢的 token 生成有更好的体验。当优先考虑更可持续的解决方案时，限制最终会转化为优势。打个比方，现代电影的一个常见批评是，对视觉特效 (VFX) 的过度依赖导致相比老电影，故事内容缺乏吸引力。VFX 的成本限制意味着老电影必须精心设计引人入胜的对话，利用巧妙的运镜和角色定位来吸引观众。同样，专注于可持续的 AI 架构，在精心设计时可以带来更具吸引力、更沉浸式的体验。
无服务器架构对 LLM 推理的第二个限制是约 50 秒的“冷启动”时间。如果实现不当，用户在没有任何替代方案的情况下等待 50 秒，很可能会离开应用。通过一些设计技巧，您可以将这种限制转化为“Wicked”体验中的一个特色：
- 创建一个“序章体验”，引导用户通过硬编码的问题和答案，为他们即将进入翡翠城做好准备，并收集输入信息以塑造他们接下来的体验。
- 将等待期设计为倒计时，展示故事或世界观的硬编码文本片段。角色（如巫师）可以通过零碎的对话行与用户交流，以制造悬念并将用户引导至正确的思维模式。
- 制作一段带有电影或音乐剧音乐的音频介绍，配合旋转的视觉效果，将用户带入“Wicked”世界的氛围中。
打破常规思维
实现可持续意识的解决方案架构，不仅包括优化 AI 推理，还超越了这一点。了解用户将如何与您的系统交互，并相应地调整您的实现规模。始终盲目优化“每秒 token 数”或“首个 token 时间”可能会掩盖开发引人入胜功能的各种机会。
话虽如此，您应该在可能的情况下利用直接的优化措施。使用 TorchAO 和 Arm KleidiAI 微内核是加速 LLM 聊天机器人的绝佳方法。通过结合创造性的解决方案架构并在可能的地方进行优化，您可以构建更具可持续性的 LLM 应用。编码愉快！