Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.4. 优化性能和调整

您可以优化并调优部署的模型，以平衡速度、效率以及不同用例的成本。

要评估模型的 inference 性能，请考虑以下关键指标：

  • latency ：生成响应所需的时间，对于实时应用程序至关重要。这包括 HEKETITime-to-First-Token (TTFT)和 Inter-Token Latency (ITL)。
  • 吞吐量：模型服务器的整体效率，以每秒(TPS)或请求每秒(RPS)来衡量。

  • 每百万令牌的成本：模型推测的经济性。



根据模型大小、可用 GPU 内存和输入序列长度等因素影响性能，特别是对于文本恢复和检索生成(RAG)等应用程序。要满足性能要求，您可以使用量化等技术来减少内存要求或并行性来在多个 GPU 之间分发非常大的模型。

2.4.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 中使用管道并行分发模型，甚至在两个服务器间分发。这种方法允许您扩展单个服务器的内存限制，但为了获得最佳性能，需要仔细管理服务器间的通信。

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

还有额外的因素，需要考虑文本恢复和 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.4.3. inference 性能指标
复制链接

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

2.4.3.1. latency
复制链接

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

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

2.4.3.2. 吞吐量
复制链接

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

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

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

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

2.4.4. 配置基于指标的自动扩展
复制链接

重要

基于指标的自动缩放目前在 Red Hat OpenShift AI 中作为技术预览功能提供。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

基于 Knative 的自动扩展在标准部署模式中不可用。但是，您可以在标准部署模式中为 inference 服务启用基于指标的自动扩展。基于指标的自动扩展可帮助您有效地管理加速器资源、操作成本并确保您的 inference 服务满足性能要求。

要在标准部署中为您的 inference 服务设置自动扩展，请安装和配置基于 Kubernetes 事件驱动的自动扩展(KEDA)的 OpenShift 自定义 Metrics Autoscaler (CMA)。然后，您可以使用 OpenShift Monitoring 中的各种模型运行时指标来触发对 inference 服务的自动扩展，如 KVCache 使用率、到第一个令牌(TTFT)和 Concurrency。

先决条件

  • 具有集群管理员特权。

  • 在集群中安装了 CMA Operator。如需更多信息 ，请参阅安装自定义指标自动扩展。

    注意
    • 安装 CMA operator 后，您必须配置 KedaController 资源。
    • odh-controller 会自动创建 TriggerAuthentication,ServiceAccount, Role ,Role,RoleBinding, 和 Secret 资源，以允许 CMA 访问 OpenShift Monitoring 指标。
  • 您已为集群启用了用户工作负载监控(UWM)。如需更多信息，请参阅配置用户工作负载监控。
  • 您已在标准部署模式中以单模式服务平台部署了模型。

流程

  1. 以集群管理员身份登录 OpenShift 控制台。
  2. 在 Administrator 视角中，点击 Home Search。
  3. 选择部署模型的项目。
  4. 从 资源 下拉菜单中，选择 InferenceService。
  5. 单击您部署的模型的 InferenceService，然后单击 YAML。

  6. 在 spec.predictor 下，定义基于指标的自动扩展策略，如下例所示： 

    kind: InferenceService
metadata:
  name: my-inference-service
  namespace: my-namespace
  annotations:
    serving.kserve.io/autoscalerClass: keda
spec:
  predictor:
    minReplicas: 1
    maxReplicas: 5
    autoscaling:
      metrics:
        - type: External
          external:
            metric:
              backend: "prometheus"
              serverAddress: "https://thanos-querier.openshift-monitoring.svc:9092"
              query: vllm:num_requests_waiting
          authenticationRef:
            name: inference-prometheus-auth
          authModes: bearer
          target:
            type: Value
            value: 2
    Copy to Clipboard Toggle word wrap

    示例配置将 inference 服务设置为根据等待处理的请求数在 1 到 5 个副本之间自动扩展，如 vllm:num_requests_waiting 指标所示。

  7. 点击 Save。

验证

  • 确认 KEDA ScaledObject 资源已创建： 

    oc get scaledobject -n <namespace>
    Copy to Clipboard Toggle word wrap

2.4.5. 基于指标的自动扩展指南
复制链接

您可以使用基于指标的自动扩展来根据延迟或以吞吐量为中心的服务级别目标(SLO)来扩展 AI 工作负载，而不是传统的请求并发。基于指标的自动扩展基于 Kubernetes 事件驱动的自动扩展(KEDA)。

传统的扩展方法取决于请求并发、请求率或 CPU 使用率等因素不适用于扩展 GPU 的 LLM inference 服务器。相反，vLLM 容量由 GPU 的大小以及同时处理的令牌总数决定。您可以使用自定义指标来帮助自动扩展决策来满足 SLO。

以下准则可帮助您自动扩展 AI inference 工作负载，包括选择指标、定义分片窗口、配置 HPA 缩减设置，以及采用模型大小来获得最佳性能。

2.4.5.1. 为延迟和吞吐量优化扩展选择指标
复制链接

对于对延迟敏感的应用程序，请选择扩展指标，具体取决于请求的特性：

  • 当序列长度不同时，请使用服务级别目标(SLO)用于到第一个令牌(TTFT)和 Inter-Token Latency (ITL)。这些指标提供更多的缩放信号，因为它们会受到一定程度的变化的影响。
  • 当请求有类似的序列长度时，使用 端到端请求延迟 来触发自动扩展。

端到端(e2e)请求延迟取决于序列长度，在输入/输出令牌计数中造成大量用例的挑战。10 令牌完成和 2000 个令牌完成将具有大量不同的延迟，即使在相同的系统条件下也是如此。要在没有延迟限制的情况下最大化吞吐量，请使用 vllm:num_requests_waiting > 0.1 metric (KEDA scaledObject not support a threshold 0)来扩展您的工作负载。此指标在请求排队后立即扩展系统，从而最大化利用率并防止积压。当输入和输出序列长度一致时，此策略最适合。

要构建有效的基于指标的自动扩展功能，请遵循以下最佳实践：

  • 选择正确的指标：

    • 分析您的负载模式，以确定序列长度差异。
    • 为高变量工作负载选择 TTFT/ITL，为统一工作负载选择 E2E 延迟。
    • 通过不同优先级实施多个指标，实现强大的扩展决策。

  • 逐渐调优配置：

    • 从保守阈值和较长的窗口开始。
    • 监控一段时间内的扩展行为和 SLO 合规性。
    • 根据观察到的模式和业务需求优化配置。

  • 通过测试验证行为：

    • 使用真实序列长度分布运行负载测试。
    • 验证各种流量模式下的扩展。
    • 测试边缘情况，如流量激增和逐步负载增加。

2.4.5.2. 选择右滑窗口
复制链接

sliding 窗口长度是聚合或评估指标以做出缩放决策的时间周期。滑动窗口长度的长度会影响到扩展响应性和稳定性。

理想的窗口长度取决于您使用的指标：

  • 对于第一个令牌(TTFT)和 Inter-Token Latency (ITL)指标的时间，您可以使用较短的窗口(1-2 分钟)，因为它们不太不确定。
  • 对于端到端延迟指标，您需要较长的窗口(4 到 5 分钟)以序列长度考虑变化。
Expand
窗口长度特性最适合

短（表示 30 秒以上）

如果指标提取间隔太长，则不会有效地触发自动扩展。

不建议。

中(60 秒)

快速响应负载变化，但可能会导致成本更高。可能会导致快速扩展和缩减，也称为 thrashing。

具有 sharp, 不可预测的工作负载。

长（覆盖 4 分钟）

平衡响应性和稳定性，同时减少不必要的扩展。可能会造成短暂的激增，并缓慢地适应负载变化。

具有中等差异的生产工作负载。

2.4.5.3. 优化 HPA 缩减配置
复制链接

有效的缩减配置对于成本优化和资源效率至关重要。它需要平衡需要快速终止空闲的 pod 以减少集群负载，并考虑维护它们以避免冷启动时间。用于缩减 Pod 的 Horizontal Pod 配置在及时删除空闲 pod 时扮演重要角色，并防止不必要的资源使用量。

您可以通过管理 KEDA scaledObject 自定义资源(CR)来控制 HPA 缩减行为。此自定义资源(CR)为特定工作负载启用事件驱动的自动扩展。

要设置 HPA 在缩减前等待的时间，请调整 stabilizationWindowSeconds 字段，如下例所示： 

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-app-scaler
spec:
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 300
Copy to Clipboard Toggle word wrap

2.4.5.4. 为优化扩展考虑模型大小
复制链接

模型大小会影响自动扩展行为和资源使用。下表描述了不同模型大小的典型特征，并描述了为 AI inference 工作负载实施基于指标自动扩展时选择的扩展策略。

Expand
模型大小内存占用扩展策略冷开始时间

小(Less 大于 3B)

小于 6 GiB

使用低资源缓冲区的主动扩展。

最多 10 分钟可下载 30 秒以加载。

Medium (3B-10B)

6-20 GiB

使用更保守的扩展策略。

最多 30 分钟可以下载和 1 分钟以加载。

Large (Greater than 10B)

大于 20 GiB

可能需要模型分片或量化。

最多需要几小时时间下载和分钟以加载。

对于少于 3 亿参数的模型，您可以使用以下策略减少冷启动延迟：

  • 通过将模型直接嵌入到镜像中，而不是在运行时下载它们来优化容器镜像。您还可以使用多阶段构建来减少最终镜像大小，并使用镜像层缓存更快地拉取容器。
  • 持久性卷声明(PVC)上的缓存模型，用于在副本间共享存储。将您的 inference 服务配置为使用 PVC 来访问缓存的模型。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部