📢 转载信息
原文作者：Chaitanya Hazarey, Caesar Chen, Kunal Ghosh, Ziwen Ning, Piyush Daftary, Pradeep Cruz, Roman Blagovirnyy, Chandra Lohit Reddy Tekulapally, Vivek Gangasani, and Vinay Arora
现代人工智能应用要求大型语言模型（LLM）能够快速、经济高效地响应，尤其是在处理长文档或扩展对话时。然而，随着上下文长度的增加，LLM推理可能会变得极其缓慢且昂贵，延迟呈指数级增长，每次交互的成本也随之攀升。
LLM推理需要在生成每个新Token时重新计算先前Token的注意力机制。这会带来显著的计算开销和高延迟，尤其对于长序列而言。键值（KV）缓存通过存储和重用先前计算出的键值向量，解决了这一瓶颈，从而减少了推理延迟和首个Token时间（TTFT）。LLM中的智能路由是一种技术，它将具有共享提示的请求发送到相同的推理实例，以最大化KV缓存的效率。它将新请求路由到已处理相同前缀的实例，从而可以重用缓存的KV数据来加速处理并降低延迟。但是，客户反馈称，在生产规模上设置和配置合适的KV缓存和智能路由框架具有挑战性，需要漫长的实验周期。
今天，我们很高兴地宣布，Amazon SageMaker HyperPod 现在通过 HyperPod 推理操作员（HyperPod Inference Operator）支持托管分层KV缓存和智能路由功能。这些新功能可以通过降低TTFT最高达40%、提高吞吐量，以及在使用我们的内部工具处理长上下文提示和多轮聊天对话时，将计算成本降低高达25%，为LLM推理工作负载带来显著的性能提升。这些功能可与 HyperPod 推理操作员配合使用，该操作员会自动管理路由和分布式KV缓存基础设施，从而在交付企业级生产LLM部署性能的同时，显著减少运营开销。通过使用新的托管分层KV缓存功能，您可以有效地将注意力缓存卸载到CPU内存（L1缓存），并通过HyperPod中的分层存储架构为跨实例共享分配L2缓存，从而在规模化时实现最佳资源利用率和成本效益。
高效的KV缓存与智能路由相结合，可以最大化跨工作节点的缓存命中率，从而在模型部署中实现更高的吞吐量和更低的成本。这些功能对于处理相同上下文或前缀的长文档应用，或在多轮对话中需要跨多次交互有效维护先前交换的上下文的应用尤其有益。
例如，分析200页合同的法律团队现在可以立即获得后续问题的答案，而不是每查询等待5秒以上；医疗保健聊天机器人可以在20多轮的患者对话中保持自然的对话流程；客户服务系统可以以更好的性能和更低的成本处理每日数百万的请求。这些优化使得文档分析、多轮对话和高吞吐量推理应用在企业规模上变得具有经济可行性。
使用托管分层KV缓存和智能路由优化LLM推理
我们来分解一下这些新特性：
- 托管分层KV缓存（Managed Tiered KV Cache）：跨CPU内存（L1）和分布式分层存储（L2）自动管理注意力状态，具有可配置的缓存大小和驱逐策略。SageMaker HyperPod 通过新推出的分层存储处理分布式缓存基础设施，减轻了跨集群进行节点间缓存共享的运营开销。KV缓存条目在整个集群内（L2）可访问，因此一个节点可以受益于其他节点执行的计算。
- 智能路由（Intelligent Routing）：可配置的请求路由，通过各种策略最大化缓存命中率，包括前缀感知（prefix-aware）、KV感知（KV-aware）和轮询（round-robin）路由。
- 可观测性（Observability）：内置 HyperPod 可观测性集成，可通过 Amazon Managed Grafana 监控托管分层KV缓存和智能路由的指标和日志。
带有KV缓存和智能路由的推理请求示例流程
当用户向 HyperPod 负载均衡器发送推理请求时，它会将请求转发到 HyperPod 集群内的智能路由器。智能路由器根据路由策略动态地将请求分发到最合适的模型Pod（实例 A 或实例 B），以最大化KV缓存命中率并最小化推理延迟。当请求到达模型Pod时，Pod首先检查L1缓存（CPU）中常用的键值对，如果未找到，则查询共享的L2缓存（托管分层KV缓存），然后再执行Token的完整计算。新生成的KV对会存储在两个缓存层中，以供将来重用。计算完成后，推理结果通过智能路由器和负载均衡器返回给用户。
托管分层KV缓存
托管分层KV缓存和智能路由是可配置的选择加入（opt-in）功能。启用托管KV缓存时，默认启用L1缓存，而L1和L2缓存都可以配置为启用或禁用。L1缓存驻留在每个推理节点上，利用CPU内存。这种本地缓存提供了显著的快速访问，非常适合单个模型实例中频繁访问的数据。缓存会自动管理内存分配和驱逐策略，以优化最有价值的缓存内容。L2缓存作为跨整个集群的分布式缓存层运行，支持跨多个模型实例的缓存共享。我们为L2缓存支持两种后端选项，每种都有以下优势：
- 托管分层KV缓存（推荐）：一种 HyperPod 分离式内存解决方案，具有出色的可扩展性至TB级内存池、低延迟、AWS网络优化、支持零拷贝的GPU感知设计，以及规模化时的成本效益。
- Redis：设置简单，适用于中小型工作负载，并提供丰富的工具和集成环境。
这种双层架构协同工作，无缝运行。当请求到达时，系统首先检查L1缓存中所需的KV对。如果找到，它们会以最小的延迟立即使用。如果在L1中未找到，系统会查询L2缓存。如果在此找到数据，则会检索该数据，并可选择提升到L1以供将来更快访问。只有当数据不存在于任一缓存中时，系统才会执行完整的计算，并将结果存储在L1和L2中以供将来重用。
智能路由
我们的智能路由系统提供了四种可配置的策略，可根据您的工作负载特性优化请求分发，路由策略可在部署时由用户配置，以匹配应用程序的特定要求。
- 前缀感知路由（Prefix-aware routing）：作为默认策略，它维护一个树状结构来跟踪哪些前缀缓存在哪些端点上，为具有常见提示模板的应用（如多轮对话、具有标准问候语的客户服务机器人以及具有常见导入的代码生成）提供强大的通用性能。
- KV感知路由（KV-aware routing）：通过跟踪缓存位置并实时处理驱逐事件的集中式控制器，提供最复杂的缓存管理，在需要最大化缓存效率的长对话线程、文档处理工作流程和扩展编码会话中表现出色。
- 轮询路由（Round-robin routing）：提供最直接的方法，将请求均匀分布到可用工作节点上，最适用于请求独立的情况，例如批量推理作业、无状态 API 调用和负载测试场景。
| 策略 | 最适用于 |
| 前缀感知路由 (默认) | 多轮对话、客户服务机器人、具有常见头部的代码生成 |
| KV感知路由 | 长对话、文档处理、扩展编码会话 |
| 轮询路由 | 批量推理、无状态 API 调用、负载测试 |
部署托管分层KV缓存和智能路由解决方案
先决条件
使用 Amazon EKS 作为编排器创建一个 HyperPod 集群。
- 在 Amazon SageMaker AI 控制台中，导航到 HyperPod 集群，然后是 集群管理。
- 在 集群管理 页面上，选择 创建 HyperPod 集群，然后选择 由 Amazon EKS 编排。
- 您可以使用 SageMaker AI 控制台的一键式部署。有关集群设置详情，请参阅使用 Amazon EKS 编排创建 SageMaker HyperPod 集群。
- 验证 HyperPod 集群状态为 InService。
- 验证推理操作员已启动并正在运行。当您从控制台创建 HyperPod 集群时，推理插件作为默认选项安装。如果您想使用现有的 EKS 集群，请参阅为模型部署设置 HyperPod 集群以手动安装推理操作员。
从命令行运行以下命令：
kubectl get pods -n hyperpod-inference-system输出：
hyperpod-inference-operator-conroller-manager-xxxxxx pod is in running state in namespace hyperpod-inference-system
或者，也可以从控制台验证操作员是否正在运行。导航到 EKS 集群，资源，Pods，选择命名空间， hyperpod-inference-system。
准备模型部署清单文件
您可以通过向 InferenceEndpointConfig 自定义 CRD 文件添加配置来启用这些功能。
有关完整示例，请访问AWS 示例 GitHub 存储库。
export MODEL_NAME="Llama-3.1-8B-Instruct" export INSTANCE_TYPE="ml.g5.24xlarge" export MODEL_IMAGE="public.ecr.aws/deep-learning-containers/vllm:0.11.1-gpu-py312-cu129-ubuntu22.04-ec2-v1.0" export S3_BUCKET="my-model-bucket" export S3_MODEL_PATH="models/Llama-3.1-8B-Instruct" export AWS_REGION="us-west-2" export CERT_S3_URI="s3://my-bucket/certs/" export NAMESPACE="default" export NAME="demo" cat << EOF > inference_endpoint_config.yaml apiVersion: inference.sagemaker.aws.amazon.com/v1 kind: InferenceEndpointConfig metadata: name: ${NAME} namespace: ${NAMESPACE} spec: modelName: ${MODEL_NAME} instanceType: ${INSTANCE_TYPE} replicas: 1 invocationEndpoint: v1/chat/completions modelSourceConfig: modelSourceType: s3 s3Storage: bucketName: ${S3_BUCKET} region: ${AWS_REGION} modelLocation: ${S3_MODEL_PATH} prefetchEnabled: false kvCacheSpec: enableL1Cache: true enableL2Cache: true l2CacheSpec: l2CacheBackend: "tieredstorage" # can also be "redis" # Set l2CacheLocalUrl if selecting "redis" # l2CacheLocalUrl: "redis:redisdefaultsvcclusterlocal:6379" intelligentRoutingSpec: enabled: true routingStrategy: prefixaware tlsConfig: tlsCertificateOutputS3Uri: ${CERT_S3_URI} metrics: enabled: true modelMetrics: port: 8000 loadBalancer: healthCheckPath: /worker: resources: limits: nvidia.com/gpu: "4" requests: cpu: "6" memory: 30Gi nvidia.com/gpu: "4" image: ${MODEL_IMAGE} args: - "--model" - "/opt/ml/model" - "--max-model-len" - "20000" - "--tensor-parallel-size" - "4" modelInvocationPort: containerPort: 8000 name: http modelVolumeMount: name: model-weights mountPath: /opt/ml/model environmentVariables: - name: OPTION_ROLLING_BATCH value: "vllm" - name: SAGEMAKER_SUBMIT_DIRECTORY value: "/opt/ml/model/code" - name: MODEL_CACHE_ROOT value: "/opt/ml/model" - name: SAGEMAKER_MODEL_SERVER_WORKERS value: "1" - name: SAGEMAKER_MODEL_SERVER_TIMEOUT value: "3600" EOF kubectl apply -f inference_endpoint_config.yaml # Check inferenceendpointconfig status kubectl get inferenceendpointconfig ${NAME} -n ${NAMESPACE} NAME AGE demo 8s # Check pods status - you should see worker pods kubectl get pods -n ${NAMESPACE} NAME READY STATUS RESTARTS AGE demo-675886c7bb-7bhhg 3/3 Running 0 30s # Router pods are under hyperpod-inference-system namespace kubectl get pods -n hyperpod-inference-system NAME READY STATUS RESTARTS AGE hyperpod-inference-operator-controller-manager-dff64b947-m5nqk 1/1 Running 0 5h49m demo-default-router-8787cf46c-jmgqd 2/2 Running 0 2m16s可观测性
您可以通过 SageMaker HyperPod 的可观测性功能来监控托管KV缓存和智能路由的指标。有关更多信息，请参阅使用 Amazon SageMaker HyperPod 中的一键式可观测性加速基础模型开发。
KV 缓存指标可在推理仪表板中查看。
基准测试
我们进行了全面的基准测试，以验证生产LLM部署的实际性能提升。我们的基准测试使用了 Llama-3.1-70B-Instruct 模型，部署在 p5.48xlarge 实例（每个配备八个 NVIDIA GPU）上，共 7 个副本，采用稳定的负载流量模式，并启用了托管分层KV缓存和智能路由功能。基准环境使用了一个专用的客户端节点组——每 100 个并发请求对应一个 c5.12xlarge 实例来产生受控负载，以及一个专用的服务器节点组，以确保模型服务器在隔离状态下运行，防止在高并发下出现资源争抢。
我们的基准测试表明，L1 和 L2 托管分层KV缓存与智能路由的结合，在多个维度上带来了显著的性能提升。对于中等上下文场景（8k Token），与没有优化的基线配置相比，我们观察到 P90 TTFT 降低了 40%，P50 降低了 72%，吞吐量提高了 24%，成本降低了 21%。对于长上下文工作负载（64K Token），收益更为明显，P90 TTFT 降低了 35%，P50 降低了 94%，吞吐量提高了 38%，成本节省了 28%。优化效益随上下文长度急剧增加。虽然 8K Token 场景在各项指标上显示出稳固的改进，但 64K Token 工作负载获得了变革性的收益，从根本上改变了用户体验。我们的测试还证实，与基于 Redis 的 L2 缓存相比，AWS 托管分层存储的性能始终更优。分层存储后端在延迟和吞吐量方面表现更好，同时无需管理单独 Redis 基础设施的运营开销，使其成为大多数部署的推荐选择。最后，与传统上需要在成本和速度之间进行权衡的性能优化不同，此解决方案同时实现了两者。
TTFT (P90)
TTFT (P50)
吞吐量 (TPS)
成本/1000 Token ($)
结论
Amazon SageMaker HyperPod 中的托管分层KV缓存和智能路由通过高效的内存管理和智能请求路由，帮助您优化LLM的推理性能和成本。您可以通过在支持 SageMaker HyperPod 的AWS 区域中向 HyperPod 模型部署添加这些配置，立即开始使用。
要了解更多信息，请访问 Amazon SageMaker HyperPod 文档或遵循模型部署入门指南。
关于作者
Chaitanya Hazarey 是亚马逊 SageMaker HyperPod 推理的软件开发经理，在全栈工程、ML/AI 和数据科学方面拥有丰富的专业知识。作为负责任的 AI 开发的热情倡导者，他将技术领导力与推进 AI 能力同时保持道德考量深深结合起来。他对现代产品开发的全面理解推动了机器学习基础设施的创新。
Pradeep Cruz 是 AWS 的高级软件开发经理（SDM），致力于推动企业规模的 AI 基础设施和应用。他在亚马逊 SageMaker AI 领导跨职能组织，为企业客户构建和扩展了多项高影响力服务，包括 SageMaker HyperPod-EKS 推理、任务治理、特征存储、AIOps 和 JumpStart 模型中心，同时也在 T-Mobile 和爱立信构建企业 AI 平台。他的技术深度涵盖分布式系统、生成式AI/ML、Kubernetes、云计算和全栈软件开发。
Vinay Arora 是 AWS 的生成式 AI 专家解决方案架构师，与客户合作设计利用 AWS 技术的尖端 AI 解决方案。在加入 AWS 之前，Vinay 在金融领域拥有二十多年的经验——曾在银行和对冲基金工作——他构建了风险模型、交易系统和市场数据平台。Vinay 拥有计算机科学和商业管理硕士学位。
Piyush Daftary 是 AWS 的高级软件工程师，专注于 Amazon SageMaker，致力于为大型语言模型构建高性能、可扩展的推理系统。他的技术兴趣涵盖 AI/ML、数据库和搜索技术，专注于开发支持大规模模型部署和推理的生产级解决方案。他的工作涉及优化系统性能、实施智能路由机制以及设计支持研究和生产工作负载的架构，热衷于解决复杂的分布式系统挑战，使开发人员和组织更容易获得先进的 AI 功能。业余时间，他喜欢旅行、徒步旅行和与家人共度时光。
Ziwen Ning 是 AWS 的高级软件开发工程师，目前在 SageMaker HyperPod 推理团队工作，专注于为大规模 AI 模型推理构建可扩展的基础设施。他的技术专长涵盖容器技术、Kubernetes 编排和 ML 基础设施，这些都是通过在整个 AWS 生态系统中广泛的工作开发的。他在容器注册表和分发、容器运行时开发和开源贡献、以及使用自定义资源管理和监控容器化 ML 工作负载方面拥有深厚经验。Ziwen 热衷于设计使先进 AI 功能更易于访问的生产级系统。在空闲时间，他喜欢踢拳、羽毛球和沉浸在音乐中。
Roman Blagovirnyy 是 SageMaker AI 团队的高级用户体验设计师，在加入亚马逊之前，他在金融、医疗、安全和人力资源行业拥有 19 年的 B2B 和企业级应用界面设计经验。在 AWS，Roman 是 SageMaker AI Studio、SageMaker Studio Lab、数据和模型治理功能以及 HyperPod 设计的关键贡献者。Roman 目前致力于 HyperPod 管理员体验的新功能和改进。此外，他对设计运营和流程有浓厚兴趣。
Caesar Chen 是 AWS SageMaker HyperPod 的软件开发经理，负责领导尖端机器学习基础设施的开发。凭借在构建生产级 ML 系统方面的丰富经验，他推动技术创新，同时培养团队卓越。他在可扩展模型托管基础设施方面的工作，使数据科学家和 ML 工程师能够更高效、更可靠地部署和管理模型。
Chandra Lohit Reddy Tekulapally 是 Amazon SageMaker HyperPod 团队的软件开发工程师。他热衷于设计和构建为大规模 AI 工作负载提供支持的可靠、高性能的分布式系统。工作之余，他喜欢旅行和探索新的咖啡店。
Kunal Jha 是 AWS 的首席产品经理。他专注于将 Amazon SageMaker Hyperpod 打造成生成式 AI 模型训练和推理的最佳选择。在业余时间，Kunal 喜欢滑雪和探索太平洋西北地区。
Vivek Gangasani 是 SageMaker 推理的全球 GenAI 专家解决方案架构师。他推动 SageMaker 推理的上市（GTM）和外向产品战略。他还帮助企业和初创公司使用 SageMaker 和 GPU 部署、管理和扩展他们的 GenAI 模型。目前，他专注于为托管大型语言模型制定优化推理性能和 GPU 效率的策略和内容。在业余时间，Vivek 喜欢徒步旅行、看电影和尝试不同的美食。
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区