原文 11677 字，FishAI速读将为你节省 59 分钟
全文总结
Amazon Rufus 是一款由生成式 AI 驱动的购物助手，它利用来自亚马逊和网络上的相关信息生成答案，帮助亚马逊客户做出更明智、更明智的购物决策。借助 Rufus，客户可以与一位了解亚马逊产品选择的生成式 AI 专家一起购物，并结合来自网络的信息，帮助购物者做出更明智的购买决策。为了满足亚马逊客户的大规模需求，Rufus 需要一个低成本、高性能且高可用的推理基础设施。该解决方案需要能够以低延迟在全球范围内为数十亿参数的大型语言模型 (LLM) 提供服务，以服务其庞大的客户群。低延迟确保用户在与 Rufus 聊天时拥有积极的体验，并且可以在不到一秒钟的时间内开始获得响应。为了实现这一点，Rufus 团队正在使用多个 AWS 服务和 AWS AI 芯片，AWS Trainium 和 AWS Inferentia。
关键要点
🤔 Rufus 的核心是基于亚马逊产品目录和网络信息训练的 LLM。为了满足 Amazon Prime Day 等高峰事件的巨大需求，Rufus 需要部署和扩展，并考虑性能、环境影响和托管解决方案的成本。为了应对这些挑战，Rufus 使用了 AWS 解决方案的组合：Inferentia2 和 Trainium、Amazon Elastic Container Service (Amazon ECS) 以及 Application Load Balancer (ALB)。此外，Rufus 团队与 NVIDIA 合作，使用 NVIDIA 的 Triton Inference Server 为解决方案提供支持，提供使用 AWS 芯片托管模型的功能。
🚀 Rufus 推理是一个检索增强生成 (RAG) 系统，其响应通过检索附加信息（例如来自亚马逊搜索结果的产品信息）来增强。这些结果基于客户查询，确保 LLM 生成可靠、高质量和精确的响应。为了确保 Rufus 能够为 Prime Day 做好最佳准备，Rufus 团队使用 Inferentia2 和 Trainium 构建了一个跨多个 AWS 区域的异构推理系统。在多个区域构建系统使 Rufus 得益于两个关键领域。首先，它提供了在高需求时期可以使用的额外容量，其次，它提高了系统的整体弹性。
💡 为了支持跨多个区域的实时流量路由，Rufus 构建了一个新颖的流量协调器。Amazon CloudWatch 支持底层监控，帮助团队根据流量模式的变化在不到 15 分钟的时间内调整不同区域的流量比例。通过使用这种类型的编排，Rufus 团队能够在需要时将请求定向到其他区域，但对第一个令牌的延迟略有影响。由于 Rufus 的流式架构和区域之间的高性能 AWS 网络，最终用户的感知延迟很小。
🤖 为了优化推理性能和主机利用率，Rufus 推理系统在每个区域都使用 Amazon ECS，它管理底层由 Inferentia 和 Trainium 支持的实例。通过管理底层基础设施，Rufus 团队只需要通过定义 ECS 任务来提供他们的容器和配置。在每个容器中，使用带有 Python 后端的 NVIDIA Triton Inference Server 运行使用 Neuron SDK 的 vLLM。vLLM 是一种内存高效的推理和服务引擎，针对高吞吐量进行了优化。Neuron SDK 使团队能够轻松采用 AWS 芯片，并支持许多不同的库和框架，例如 PyTorch Lightning。
📈 为了减少客户开始看到 Rufus 响应的总体等待时间，该团队还开发了一个推理流式架构。由于 LLM 推理需要高计算量和内存负载，完成为客户查询生成完整响应所需的时间可能需要几秒钟。使用流式架构，Rufus 能够在令牌生成后立即返回它们。这种优化使客户能够在不到一秒钟的时间内开始使用响应。此外，多个服务使用 gRPC 连接协同工作，以实时智能地聚合和增强客户的流式响应。
💰 尽管我们必须保持低延迟以获得最佳的客户体验，但通过实现高硬件资源利用率来扩展服务吞吐量也至关重要。高硬件利用率确保加速器不会闲置并无谓地增加成本。为了优化推理系统吞吐量，该团队改进了单主机吞吐量以及负载均衡效率。
💪 由于以下挑战，LLM 推理的负载均衡很棘手。首先，单个主机只能处理有限数量的并发请求。其次，完成一个请求的端到端延迟可能会有所不同，具体取决于 LLM 响应长度，可能需要几秒钟。为了解决这些挑战，该团队通过考虑单主机吞吐量和使用负载均衡的多个主机的吞吐量来优化吞吐量。
🚀 该团队使用了 ALB 的最少未完成请求 (LOR) 路由算法，与早期的基线测量相比，吞吐量提高了五倍。这使每个主机都有足够的时间来处理正在进行的请求并使用 gRPC 连接流回响应，而不会被同时接收的多个请求淹没。Rufus 还与 AWS 和 vLLM 团队合作，使用 vLLM 与 Neuron SDK 和 NVIDIA Triton Inference Server 的集成来提高单主机并发性。
✨ 借助这种集成，Rufus 能够从一项关键优化中获益：持续批处理。持续批处理允许单个主机大幅提高吞吐量。此外，与其他批处理技术（例如静态批处理）相比，持续批处理提供了独特的功能。例如，使用静态批处理时，第一个令牌的时间 (TTFT) 会随着一个批次中请求数量的增加而线性增加。持续批处理优先处理 LLM 推理的预填充阶段，即使在同时运行更多请求的情况下也能控制 TTFT。这帮助 Rufus 在生成第一个响应时提供愉快的低延迟体验，并提高单主机吞吐量以控制服务成本。
💡 在本文中，我们讨论了 Rufus 如何使用 Neuron SDK 以及 Inferentia2 和 Trainium 芯片以及 AWS 服务来可靠地部署和服务其数十亿参数的 LLM。Rufus 随着生成式 AI 和客户反馈的进步而不断发展，我们鼓励您使用 Inferentia 和 Trainium。