2.18. 性能优化和调整

2.18.1. 确定 LLM 支持的应用程序的 GPU 要求
复制链接

在为由 OpenShift AI 上托管的 Large Language Model (LLM)支持的应用程序选择 GPU 时需要考虑以下因素。

以下指南可帮助您根据模型的大小和预期使用，确定应用程序的硬件要求。

估算内存需要 ：一般的 thumb 规则是 16 位精度中带有 N 参数的模型需要大约 2N 字节。例如，一个 8-billion-parameter 模型需要大约 16GB 的 GPU 内存，而 70-billion-parameter 模型则需要大约 140GB。
Quantization ：要减少内存要求并可能提高吞吐量，您可以使用量化来加载或以较低精度格式（如 INT8、FP8 或 INT4）加载或运行模型。这可减少内存占用量，以牺牲模型准确性的降低。
注意
KServe 模型服务运行时的 vLLM ServingRuntime 支持多种量化方法。有关支持的实现和兼容硬件的更多信息，请参阅支持的硬件来量化内核。
键值缓存的额外内存 ：除了模型权重外，还需要 GPU 内存来存储注意的键值(KV)缓存，这会随着请求数量和每个请求的序列长度增加。这可能会影响实时应用程序的性能，特别是对于大型模型。
推荐的 GPU 配置 ：
- 小模型(1B-8B 参数) ：对于范围内的模型，带有 24GB 内存的 GPU 通常足以支持少量并发用户。
- Medium Models (10B-34B 参数) ：
  - 20B 参数下的模型需要至少 48GB 的 GPU 内存。
  - 20B 间的模型 - 34B 参数在单个 GPU 中至少需要 80GB 或更多内存。
- 大型模型(70B 参数) ：此范围内的模型可能需要使用 10sor parallelism 技术在多个 GPU 之间分发。Tensor parallelism 允许模型跨越多个 GPU，通过释放 KV 缓存的额外内存来提高内部令牌延迟并增加最大批处理大小。当 GPU 具有快速互连（如 NVLink）时，Tensor parallelism 可以正常工作。
- 超大 模型(405B 参数): 对于非常大的模型，建议量化来减少内存需求。您还可以在多个 GPU 中使用管道并行分发模型，甚至在两个服务器间分发。这种方法允许您扩展单个服务器的内存限制，但为了获得最佳性能，需要仔细管理服务器间的通信。

为获得最佳结果，从较小的模型开始，然后根据需要扩展到更大的模型，使用并行和量化等技术以满足您的性能和内存要求。

2.18.2. 文本恢复和检索生成(RAG)应用程序的性能注意事项
复制链接

还有额外的因素，需要考虑文本恢复和 RAG 应用，以及处理用户上传的大型文档的 LLM 支持的服务。

较长的输入 序列：如果每个用户查询包含大型提示或大量上下文，则输入序列长度可能比典型的聊天应用程序要长得多。较长的输入序列长度会增加 填充时间，模型在生成响应前处理初始输入序列所需的时间，然后可能导致更高的 生存时间(TTFT)。较长的 TTFT 可能会影响应用程序的响应。最小化这个延迟以获得最佳用户体验。
KV Cache Usage: Longer sequences 需要更多 GPU 内存用于 键值(KV)缓存。KV 缓存存储中间关注数据，以便在生成期间提高模型性能。每个请求的高 KV 缓存利用率需要有足够 GPU 内存的硬件设置。如果多个用户同时查询模型，这尤其重要，因为每个请求都会添加到总内存负载中。
最佳硬件配置 ：为了保持响应速度并避免内存瓶颈，请选择具有足够内存的 GPU 配置。例如，无需在单个 24GB GPU 上运行 8B 模型，在更大的 GPU （如 48GB 或 80GB）上部署它，或通过为 KV 缓存提供更多内存空间并降低令牌延迟来提高性能。带有十个并行性的多GPU设置也可以帮助管理内存需求，并提高更大输入序列的效率。

总之，要确保基于文档的应用程序的最佳响应性和可扩展性，您必须优先选择具有高 GPU 内存容量的硬件，并考虑多 GPU 配置，以处理长输入序列和 KV 缓存增加的内存要求。

2.18.3. inference 性能指标
复制链接

延迟、吞吐量 和成本每百万令牌是 评估模型在推断过程中的响应生成效率时需要考虑的关键指标。这些指标提供了模型推测性能的综合视图，有助于平衡不同用例的速度、效率和成本。

2.18.3.1. latency
复制链接

对交互式或实时用例 的延迟 至关重要，并使用以下指标来测量：

time-to-First-Token (TTFT) ：初始请求和第一个令牌的生成之间的延迟（毫秒）。此指标对于流响应非常重要。
Inter-Token Latency (ITL) ：在第一个令牌后生成每个后续令牌所需的时间（以毫秒为单位），也与流相关。
time -Per-Output-Token (TPOT): 对于非流请求，在输出序列中生成每个令牌的平均时间（毫秒）。

2.18.3.2. 吞吐量
复制链接

吞吐量 测量模型服务器的整体效率，并使用以下指标表示：

Token per Second (TPS) ：在所有活跃请求之间每秒生成的令牌总数。
每秒请求数(RPS) ：每秒处理的请求数。RPS 与响应时间一样，对序列长度非常敏感。

2.18.3.3. 每百万令牌的成本
复制链接

每 Million 令牌的成本测量模型推测的经济性，表明了每百万个令牌所产生的成本。该指标有助于评估部署模型的经济可行性和可扩展性。

2.18.4. 解决 CUDA 内存不足错误
复制链接

在某些情况下，根据所使用的模型和硬件加速器，TGIS 内存自动调整算法可能会降低处理长序列所需的 GPU 内存量。这个错误计算可能会导致模型服务器进行 Compute Unified Architecture (CUDA)内存不足(OOM)错误响应。在这种情况下，您必须在 TGIS 模型运行时更新或添加额外的参数，如以下步骤所述。

注意

KServe 文本 Generation Inference Server (TGIS) Standalone ServingRuntime 已弃用。如需更多信息，请参阅 OpenShift AI 发行注记。

先决条件

您已以具有 OpenShift AI 管理员特权的用户身份登录到 OpenShift AI。

流程

在 OpenShift AI 仪表板中点 Settings Serving runtime。
Serving 运行时 页面将打开，并显示已安装和启用的模型服务运行时。
根据用于部署模型的运行时，执行以下操作之一：
- 如果您使用预安装的 文本 Generation Inference Server (TGIS) Standalone ServingRuntime for KServe 运行时，复制运行时以创建自定义版本，然后按照此流程的其余部分操作。有关复制预安装的 TGIS 运行时的更多信息，请参阅为单模型服务平台添加自定义模型运行时。
- 如果您已使用自定义 TGIS 运行时，点运行时旁边的操作菜单(ProductShortName)，然后选择 Edit。
  嵌入的 YAML 编辑器会打开并显示自定义模型服务运行时的内容。
添加或更新 BATCH_SAFETY_MARGIN 环境变量，并将值设置为 30。同样，添加或更新 ESTIMATE_MEMORY_BATCH_SIZE 环境变量，并将值设为 8。
```
spec:
  containers:
    env:
    - name: BATCH_SAFETY_MARGIN
      value: 30
    - name: ESTIMATE_MEMORY_BATCH
      value: 8
```
```
spec:
  containers:
    env:
    - name: BATCH_SAFETY_MARGIN
      value: 30
    - name: ESTIMATE_MEMORY_BATCH
      value: 8
```
Copy to Clipboard Toggle word wrap
注意
BATCH_SAFETY_MARGIN 参数设置可用 GPU 内存百分比，以保存回安全边缘以避免 OOM 条件。BATCH_SAFETY_MARGIN 的默认值为 20。ESTIMATE_MEMORY_BATCH_SIZE 参数设置内存自动调整算法中使用的批处理大小。ESTIMATE_MEMORY_BATCH_SIZE 的默认值为 16。
点 Update。
Serving runtime 页面将打开，并显示安装的运行时列表。观察您更新的自定义模型运行时是否显示。
要重新部署模型以使参数更新生效，请执行以下操作：
1. 在 OpenShift AI 仪表板中点 Models Model deployments。
2. 找到您要重新部署的型号，点模型旁边的操作菜单(&&)，然后选择 Delete。
3. 重新部署模型，如在单模式服务平台上部署模型中所述。

验证

您从模型服务器收到成功的响应，不再看到 CUDA OOM 错误。

2.18. 性能优化和调整

2.18.1. 确定 LLM 支持的应用程序的 GPU 要求
复制链接

2.18.2. 文本恢复和检索生成(RAG)应用程序的性能注意事项
复制链接

2.18.3. inference 性能指标
复制链接

2.18.3.1. latency
复制链接

2.18.3.2. 吞吐量
复制链接

2.18.3.3. 每百万令牌的成本
复制链接

2.18.4. 解决 CUDA 内存不足错误
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.18. 性能优化和调整

2.18.1. 确定 LLM 支持的应用程序的 GPU 要求复制链接链接已复制到粘贴板!

2.18.2. 文本恢复和检索生成(RAG)应用程序的性能注意事项复制链接链接已复制到粘贴板!

2.18.3. inference 性能指标复制链接链接已复制到粘贴板!

2.18.3.1. latency复制链接链接已复制到粘贴板!

2.18.3.2. 吞吐量复制链接链接已复制到粘贴板!

2.18.3.3. 每百万令牌的成本复制链接链接已复制到粘贴板!

2.18.4. 解决 CUDA 内存不足错误复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.18.1. 确定 LLM 支持的应用程序的 GPU 要求
复制链接

2.18.2. 文本恢复和检索生成(RAG)应用程序的性能注意事项
复制链接

2.18.3. inference 性能指标
复制链接

2.18.3.1. latency
复制链接

2.18.3.2. 吞吐量
复制链接

2.18.3.3. 每百万令牌的成本
复制链接

2.18.4. 解决 CUDA 内存不足错误
复制链接