**帮助改进此页面** 

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。

# 在 Amazon EKS 上运行人工智能/机器学习推理工作负载
<a name="ml-inference"></a>

**提示**  
 [注册参加](https://events.eksworkshop.com/workshops/genai/)即将举办的 Amazon EKS 人工智能/机器学习讲习会。

推理是运行经过训练的人工智能（AI）模型，以根据输入数据生成预测或输出的过程。这包括服务可生成文本或代码的大语言模型（LLM）、可生成图像的扩散模型、可用于语音合成和转录的语音模型以及可用于实时分析或生成的视频模型等。Amazon EKS 提供了一种可扩展且可移植的解决方案，来使用 NVIDIA GPU 或 AWS Trainium 加速器部署这些推理工作负载，执行动态扩缩以及与更广泛的 Kubernetes 以及 AWS 工具和服务组合集成。

## 为什么要使用 Amazon EKS 进行推理
<a name="_why_use_amazon_eks_for_inference"></a>

Amazon EKS 将 Kubernetes 编排与 AWS 基础设施相结合，解决了大规模运行推理时所面临的各种关键挑战：
+  **动态 GPU 扩展**：Karpenter 会根据容器组资源请求按需预调配大小合适的 GPU 实例，在空闲时从零开始扩展并随着流量增加而添加容量。这样可以避免过多配置高成本的 GPU 资源。
+  **快速冷启动**：SOCI（Seekable OCI）并行拉取功能会同时下载和解压缩大型容器映像层，将映像拉取时间从几分钟缩短到几秒。再加上模型会从 Amazon S3 直接流式传输到 GPU 内存，容器组可在不到两分钟的时间内开始提供服务。
+  **自动 GPU 故障恢复**：EKS 节点监控代理可检测到 GPU 硬件故障并触发自动节点替换，无需人工干预，从而最大限度减少停机时间。
+  **成本优化**：使用竞价型实例并启用按需型回退、实例选择时会合理调整大小并执行缩减到零行为，从而降低 GPU 成本。预留容量（ODCR）可为稳态工作负载提供额外的节省。
+  **开放标准和可移植性**：推理工作负载在标准的 Kubernetes API（部署、服务、HPA）上运行，使用 vLLM 或 SGLang 等开源模型服务器，实现跨环境可移植性。
+  **集成监控**：来自 vLLM 或 SGLang 的 Prometheus 指标以及 NVIDIA DCGM Exporter 可通过 Grafana 控制面板查看请求延迟、词元吞吐量、GPU 利用率和内存使用情况。

## 术语表
<a name="_glossary"></a>

本节中使用了以下术语：
+  **推理**：运行经过训练的模型以根据输入数据生成输出（文本、嵌入、分类）的过程。
+  **模型服务器**：一种用于将模型加载到内存中，接收推理请求并返回预测的容器化服务。示例包括 [vLLM](https://docs.vllm.ai/en/latest/)、[SGLang](https://github.com/sgl-project/sglang)、[Triton Inference Server](https://github.com/triton-inference-server/server) 和 [Text Generation Inference（TGI）](https://github.com/huggingface/text-generation-inference)。
+  **模型权重**：经训练模型的学习参数，存储为文件（通常采用 SafeTensors 或 GGUF 格式），模型服务器会将该文件加载到 GPU 内存中。
+  **加速器**：可加快推理所需矩阵运算的专用硬件，例如 NVIDIA GPU 或 AWS Trainium/Inferentia 芯片。
+  **张量并行度**：将模型拆分到同一节点上的多个 GPU 上，以服务超过单个 GPU 内存的模型。
+  **KV 缓存**：一种用于在文本生成期间存储先前计算的键值对的内存缓冲区，从而避免对每个新词元进行冗余计算。

## Amazon EKS 上的推理工作原理
<a name="_how_inference_on_amazon_eks_works"></a>

概括来说，在 Amazon EKS 上部署推理工作负载涉及以下步骤：


| 步骤 | 说明 | 
| --- | --- | 
|  **设置集群**  | 创建一个具有 GPU 节点的集群，以及监控和存储。请参阅 EKS 上的人工智能/机器学习文档中的[集群设置](ml-cluster-setup.md)。 | 
|  **存储模型权重**  | 从模型注册表（例如 Hugging Face）下载模型权重并将其存储在 Amazon S3 中，以便在冷启动或纵向扩展事件期间快速加载模型。 | 
|  **部署模型服务器**  | 创建一个将在 GPU 节点上运行模型服务器（例如 vLLM）的 Kubernetes 部署。该模型服务器会将权重从 S3 流式传输到 GPU 内存中，并公开一个兼容 OpenAI 的 API。 | 
|  **公开推理端点**  | 创建 Kubernetes 服务以提供稳定的网络端点。使用端口转发进行测试，也可使用诸如 AWS 应用程序负载均衡器（ALB）之类的负载均衡器来处理生产流量。 | 
|  **监控和扩展**  | 使用 Prometheus 指标（请求速率、词元吞吐量、延迟、KV 缓存利用率等）来监控性能并配置自动扩缩。 | 

## 推理性能指标
<a name="_inference_performance_metrics"></a>

要了解推理性能，需要跟踪延迟和吞吐量指标：

 **延迟指标** 
+  **首词元时间（TTFT）**：从请求到达至第一个词元生成所需的时间。对于交互式应用程序至关重要。
+  **每输出词元时间（TPOT）**：在第一个词元之后生成每个后续词元所需的平均时间。
+  **端到端请求延迟**：从提交请求到完成完整响应所需的总时间。

 **吞吐量指标** 
+  **每秒请求数**：所有副本中每秒处理的推理请求总数。
+  **每秒输出词元数**：词元生成速率，以输出词元总数除以经过的时间来衡量。
+  **GPU 利用率**：积极用于推理的 GPU 计算周期占比。
+  **KV 缓存利用率**：所分配 KV 缓存内存的使用占比，表示服务器接近其容量上限的程度。

## 缩短冷启动时间
<a name="_reducing_cold_start_time"></a>

大型推理容器（8-15 GB）和模型权重（10-100\+ GB）可能会导致容器组启动缓慢。以下技术可最大限度地减少冷启动延迟：
+  **SOCI 并行拉取**：同时下载和解压缩容器映像层，而不是串行拉取。EKS 自动模式会为 GPU 实例默认启用此功能。
+  **从 S3 流式传输模型**：诸如 [Run:ai Model Streamer](https://github.com/run-ai/runai-model-streamer) 之类的工具可将模型权重直接从 Amazon S3 流式传输到 GPU 内存，绕过本地磁盘，从而将加载时间从几分钟缩短到几秒。
+  **将映像存储在 Amazon ECR 中**：通过 VPC 端点从区域 ECR 存储库中拉取大型容器映像，避免互联网延迟。
+  **实例存储缓存** ：具有本地 NVMe 磁盘的 G 系列实例可以缓存容器层和模型构件，从而加快在同一节点上的后续拉取速度。

## 需要部署什么
<a name="_what_youll_deploy"></a>

[加载和服务模型](ml-inference-load-serve-model.md)演练将指导您部署一个端到端的推理应用程序：

1.  **下载模型权重**：使用 Kubernetes 作业从 Hugging Face 下载 Ministral-3-8B-Instruct 模型并将其上传到您的 S3 存储桶。

1.  **部署 vLLM**：部署使用 Run:ai Model Streamer 运行 vLLM，将权重从 S3 直接流式传输到 GPU 内存，并服务兼容 OpenAI 的 API。

1.  **使用 Grafana 进行监控**：ServiceMonitor 将 vLLM Prometheus 指标连接到监控堆栈中，以用于实时控制面板。

1.  **部署聊天前端**：Open WebUI 提供了一个连接到 vLLM 端点的基于浏览器的聊天界面。

本演练使用[设置用于人工智能/机器学习工作负载的 Amazon EKS 集群](ml-cluster-setup.md)部分中的集群基础设施，对 EKS 自动模式和自行管理的 Karpenter 路径均适用。