为 GKE 推理网关执行发布操作


本页面介绍了如何为 GKE 推理网关执行增量发布操作,以逐步部署推理基础架构的新版本。借助此网关,您可以对推理基础架构执行安全且受控的更新。您可以更新节点、基础模型和 LoRA 适配器,而不会对服务造成太大影响。此页面还提供了有关流量分配和回滚的指南,以帮助确保部署的可靠性。

本页面适用于想要为 GKE 推理网关执行发布操作的 GKE 身份和账号管理员及开发者。

支持以下用例:

更新节点发布

节点更新推出可安全地将推理工作负载迁移到新的节点硬件或加速器配置。此过程以受控方式进行,不会中断模型服务。使用节点更新推出功能,可在硬件升级、驱动程序更新或安全问题解决期间最大限度地减少服务中断。

  1. 创建新的 InferencePool:部署配置了更新后的节点或硬件规范的 InferencePool

  2. 使用 HTTPRoute 拆分流量:配置 HTTPRoute 以在现有 InferencePool 资源和新 InferencePool 资源之间分配流量。使用 backendRefs 中的 weight 字段管理定向到新节点的流量百分比。

  3. 保持一致的 InferenceModel:保留现有的 InferenceModel 配置,以确保在两种节点配置中模型行为保持一致。

  4. 保留原始资源:在发布期间保持原始 InferencePool 和节点处于活动状态,以便在需要时进行回滚。

例如,您可以创建一个名为 llm-new 的新 InferencePool。使用与现有 llm InferencePool 相同的模型配置来配置此池。在集群中的一组新节点上部署该池。使用 HTTPRoute 对象在原始 llm 和新的 llm-new InferencePool 之间拆分流量。此技术可让您以增量方式更新模型节点。

下图展示了 GKE 推理网关如何执行节点更新发布。

节点更新部署流程
图: 节点更新部署流程

如需执行节点更新推出,请执行以下步骤:

  1. 将以下示例清单保存为 routes-to-llm.yaml

    apiVersion: gateway.networking.k8s.io/v1
    kind: `HTTPRoute`
    metadata:
      name: routes-to-llm
    spec:
      parentRefs:
        - name: my-inference-gateway
      rules:
        backendRefs:
        - name: llm
          kind: InferencePool
          weight: 90
        - name: llm-new
          kind: InferencePool
          weight: 10
    
  2. 将示例清单应用于集群:

    kubectl apply -f routes-to-llm.yaml
    

原始 llm InferencePool 接收大部分流量,而 llm-new InferencePool 接收剩余流量。逐步增加 llm-new InferencePool 的流量权重,以完成节点更新发布。

发布基本模型

基础模型更新会分阶段推出到新的基础 LLM,同时保留与现有 LoRA 适配器的兼容性。您可以使用基础模型更新发布来升级到改进的模型架构或解决模型特有的问题。

如需发布基本模型更新,请执行以下操作:

  1. 部署新基础架构:创建新节点和新 InferencePool,并使用您选择的新基础模型进行配置。
  2. 配置流量分配:使用 HTTPRoute 在现有 InferencePool(使用旧的基础模型)和新 InferencePool(使用新的基础模型)之间拆分流量。backendRefs weight 字段用于控制分配给每个池的流量百分比。
  3. 保持 InferenceModel 完整性:保持 InferenceModel 配置不变。这样可确保系统在两个基础模型版本中始终如一地应用相同的 LoRA 适配器。
  4. 保留回滚功能:在发布期间保留原始节点和 InferencePool,以便在必要时进行回滚。

您创建了一个名为 llm-pool-version-2 的新 InferencePool。此池会在一组新节点上部署新版基本模型。通过配置 HTTPRoute(如提供的示例所示),您可以在原始 llm-poolllm-pool-version-2 之间逐步拆分流量。这样,您就可以控制集群中的基础模型更新。

如需执行基础模型更新发布,请执行以下步骤:

  1. 将以下示例清单保存为 routes-to-llm.yaml

    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: routes-to-llm
    spec:
      parentRefs:
        - name: my-inference-gateway
      rules:
        backendRefs:
        - name: llm-pool
          kind: InferencePool
          weight: 90
        - name: llm-pool-version-2
          kind: InferencePool
          weight: 10
    
  2. 将示例清单应用于集群:

    kubectl apply -f routes-to-llm.yaml
    

原始 llm-pool InferencePool 接收大部分流量,而 llm-pool-version-2 InferencePool 接收剩余流量。逐步增加 llm-pool-version-2 InferencePool 的流量权重,以完成基础模型更新的推出。

发布 LoRA 适配器更新

借助 LoRA 适配器更新发布,您可以分阶段部署微调模型的新版本,而无需更改底层基础模型或基础架构。使用 LoRA 适配器更新发布来测试 LoRA 适配器中的改进、bug 修复或新功能。

如需更新 LoRA 适配器,请按以下步骤操作:

  1. 提供适配器:确保新 LoRA 适配器版本在模型服务器上可用。如需了解详情,请参阅适配器发布

  2. 修改 InferenceModel 配置:在现有的 InferenceModel 配置中,定义多个版本的 LoRA 适配器。为每个版本分配一个唯一的 modelName(例如 llm-v1llm-v2)。

  3. 分配流量:使用 InferenceModel 规范中的 weight 字段来控制不同 LoRA 适配器版本之间的流量分配。

  4. 保持一致的 poolRef:确保所有 LoRA 适配器版本都引用相同的 InferencePool。这可防止节点或 InferencePool 重新部署。在 InferenceModel 配置中保留之前的 LoRA 适配器版本,以实现回滚。

以下示例展示了两个 LoRA 适配器版本:llm-v1llm-v2。这两个版本使用相同的基本模型。您可以在同一 InferenceModel 中定义 llm-v1llm-v2。您可以分配权重,以逐步将流量从 llm-v1 转移到 llm-v2。此控制功能可实现受控的推出,而无需对节点或 InferencePool 配置进行任何更改。

如需推出 LoRA 适配器更新,请运行以下命令:

  1. 将以下示例清单保存为 inferencemodel-sample.yaml

    apiVersion: inference.networking.x-k8s.io/v1alpha2
    kind: InferenceModel
    metadata:
      name: inferencemodel-sample
    spec:
    versions:
    -   modelName: llm-v1
      criticality: Critical
      weight: 90
      poolRef:
        name: llm-pool
    -   modelName: llm-v2
      criticality: Critical
      weight: 10
      poolRef:
        name: llm-pool
    
  2. 将示例清单应用于集群:

    kubectl apply -f inferencemodel-sample.yaml
    

llm-v1 版本接收大部分流量,而 llm-v2 版本接收剩余流量。逐步增加 llm-v2 版本的流量权重,以完成 LoRA 适配器更新的推出。

后续步骤