扩展Rufus这款由亚马逊生成式AI驱动的对话购物助手，配备超过80000个AWS Infer

• 2026-01-27 14:15:39

扩展Rufus：亚马逊生成AI驱动的对话购物助手

关键要点

亚马逊Rufus是一种基于生成AI的购物助手体验。它通过整合亚马逊及网络上的相关信息，为客户提供准确的答案，以帮助他们做出更理智的购物决策。借助Rufus，客户可以像有一个了解亚马逊产品的专家陪伴购物一样，获取更丰富的信息，助力他们做出明智的购买选择。

为了满足亚马逊客户的规模化需求，Rufus需要一种低成本、高性能及高可用性的推理基础设施。该解决方案需要具备向全球客户提供数十亿参数的大语言模型(LLMs)的低延迟服务能力。这种低延迟确保用户在与Rufus聊天时能够拥有积极的体验，并且能够在不到一秒的时间内收到回复。为了实现这一目标，Rufus团队使用了多种AWS服务以及AWS AI芯片，包括AWS Trainium和AWS Inferentia。

Inferentia和Trainium是AWS专门开发的芯片，能够以高性能和低成本加速深度学习工作负载。使用这些芯片后，Rufus的成本降低至其他评估解决方案的45倍，同时保持低延迟，为客户提供稳定的服务。在这篇文章中，我们将深入探讨Rufus使用AWS芯片的推理部署，如何顺利应对亚马逊Prime Day这样的高峰事件。

解决方案概述

Rufus的核心是一个训练于亚马逊产品目录和网络信息的大语言模型(LLM)。LLM的部署可能会面临多重挑战，需要在模型大小、精度和推理性能之间找到平衡。尽管较大的模型通常具有更好的知识和推理能力，但由于计算需求增加和延迟提升，其成本也相应提高。为了满足亚马逊Prime Day等活动的大量需求，Rufus的部署和扩展需考虑其性能、环境影响和托管成本。为应对这些挑战，Rufus采用了多种AWS解决方案，包括Inferentia2和Trainium、Amazon弹性容器服务(Amazon ECS)以及应用负载均衡器 (ALB)。此外，Rufus团队还与NVIDIA合作，使用NVIDIA的推理服务器来提升解决方案的能力。

Rufus推理是一个检索增强生成(RAG)系统，它通过额外检索与客户查询相关的产品信息，从而提升响应质量。这确保了LLM能生成可靠、高质量和精准的回答。

为了确保Rufus在Prime Day期间表现最佳，团队利用多个AWS区域构建了一个异构推理系统，包括Inferentia2和Trainium。跨多个区域构建系统的两个主要好处是：提供额外的容量应对高需求时期，同时提高系统的整体弹性。

Rufus团队使用了Inf2和Trn1实例类型。由于Inf2和Trn1实例类型使用的都是同一AWS Neuron SDK，因此他们能够用两个实例服务相同的Rufus模型。唯一需要调整的配置设置是张量并行度Inf2为24，Trn1为32。使用Trn1实例，还能比Inf2获得额外20的延迟减少和吞吐量提升。

以下图示展示了解决方案架构。

为支持实时流量在多个区域之间的路由，Rufus构建了一种新颖的流量协调器。Amazon CloudWatch支撑基础监控功能，帮助团队在基于流量模式的变化中，在不到15分钟内调整各区域的流量比重。通过这种协调方式，Rufus团队能够在必要时将请求引导到其他区域，尽管首个令牌会有轻微的延迟，但最终用户感知的延迟却微乎其微。

Rufus的选择使其能够在三大区域扩展超过80000个Trainium和Inferentia芯片，以每分钟处理300万个令牌，并且为Prime Day客户提供首个回应的P99延迟低于1秒。此外，利用这些专用芯片，Rufus在每瓦性能上比其他评估解决方案提升了54，这帮助Rufus团队达成了能效目标。

优化推理性能及主机利用率

在每个区域内，Rufus推理系统使用Amazon ECS管理底层的Inferentia和Trainium驱动的实例。通过管理底层基础设施，Rufus团队只需通过定义ECS任务来带入其容器和配置。在每个容器中，运行着带有Python后端的NVIDIA Triton推理服务器，使用vLLM和Neuron SDK。vLLM是一款内存高效的推理和服务引擎，经过优化以实现高吞吐量。Neuron SDK则使团队能够轻松应用AWS芯片并支持多种库和框架，例如PyTorch Lightning。

Neuron SDK为利用Trainium和Inferentia硬件的LLM推理提供了一种简便的解决方案，优化性能并支持各种基于变换器的LLM架构。为减少延迟，Rufus与AWS Annapurna团队合作开发了多个优化手段，例如INT8仅限权重量化、vLLM的持续批处理、资源计算及内存带宽在Neuron编译器及运行时中的优化。这些优化目前已在Rufus生产中部署，并在Neuron SDK 218及后续版本中可用。

Rufus团队还开发了一种推理流式架构，以减少客户开始看到响应的总等待时间。由于LLM推理需要高计算和内存负载，生成客户查询的完整响应总时间可能需要几秒钟。使用流式架构，Rufus能够在生成令牌后立即返回。这种优化允许客户在不到1秒的时间内开始获取响应。此外，通过gRPC连接，多种服务协同工作，实时智能聚合和增强流式响应，提升客户体验。

如以下图所示，响应中嵌入了图像和链接，使客户可以与Rufus进行交互并继续探索。

扩展能力

尽管我们需要保持低延迟，以实现最佳客户体验，但通过高硬件资源利用率扩充服务吞吐量同样至关重要。高硬件利用率确保加速器不会闲置，从而避免不必要的成本。为优化推理系统的吞吐量，团队改善了单主机的吞吐量及负载均衡效率。

LLM推理的负载均衡面临多个挑战。首先，单个主机只能处理有限数量的并发请求。其次，完成单个请求的端到端延迟可能会有所不同，根据LLM响应的长度，可能需要几秒的时间。

为了解决这些挑战，团队在优化吞吐量时考虑了单主机吞吐量与多个主机间的吞吐量。团队使用了ALB的最少未完成请求LOR路由算法，使吞吐量较早期基线测量提升了五倍。这使每台主机能有足够的时间处理未完请求，并通过gRPC连接流回响应，而不被同时收到的请求淹没。Rufus还通过与AWS和vLLM团队合作，通过与Neuron SDK及NVIDIA Triton推理服务器的vLLM集成，提升了单主机的并发性。

通过这种集成，Rufus得以采用一个关键的优化：持续批处理。持续批处理使单个主机的吞吐量大大提高。此外，持续批处理在能力上超越了其他批处理技术例如静态批处理。例如，使用静态批处理时，首个令牌的时延(TTFT)随着批处理请求数量的增加而线性增加。而持续批处理则优先考虑LLM推理的预填充阶段，即使在同时运行更多请求的情况下，也能控制TTFT。这帮助Rufus在生成首个响应时提供低延迟的良好体验，并改善单主机吞吐量，有助于控制服务成本。

结论

在这篇文章中，我们讨论了Rufus如何利用Neuron SDK与Inferentia2和Trainium芯片及AWS服务，可靠地部署和服务其数十亿参数的LLM。Rufus在生成AI和客户反馈的推动下不断演进，欢迎您使用Inferentia和Trainium。

了解更多关于我们如何在亚马逊推动生成AI创新的信息。

关于作者

James Park 是亚马逊网络服务的解决方案架构师。他与Amazoncom合作设计、构建和部署AWS上的技术解决方案，对于AI和机器学习有着特殊的兴趣。在业余时间，他喜欢探索新文化和新体验，并保持关注最新的科技趋势。

RJ 是亚马逊的一名工程师。他构建和优化分布式训练系统，并致力于优化延迟的减少，以提高机器学习推理性能。在工作之外，他还探索使用生成AI构建的食谱。

Yang Zhou 是一名软件工程师，专注于构建和优化机器学习系统。他最近着重于提升生成AI推理的性能和成本效益。在工作之余，他喜欢旅游，并对长跑产生了新的热情。

Adam (Hongshen) Zhao 是亚马逊商店基础AI的软件开发经理。目前，他正在引领Rufus推理团队，构建生成AI推理优化解决方案，并实现快速、低成本的推理系统。工作之外，他喜欢和妻子一起旅行和艺术创作。

Faqin Zhong 是亚马逊商店基础AI的一名软件工程师，正在从事大语言模型(LLM)推理基础设施和优化工作。热衷于生成AI技术，Faqin与领先团队合作推动创新，使LLM更具可用性和影响力，从而提升不同应用的客户体验。工作之余，她喜欢与儿子一起进行有氧运动和烘焙。

Nicolas Trown 是亚马逊商店基础AI的工程师，最近专注于对Rufus进行系统优化，以提升Rufus的推理团队和高效利用率。工作之余，他享受与妻子共度的时光以及前往附近海岸、纳帕和索诺玛地区的短途旅行。

Bing Yin 是亚马逊商店基础AI的科学董事，领导专注于购物用例的LLM构建和推理优化项目。工作之外，他喜欢参加马拉松比赛。