此页面由 Cloud Translation API 翻译。

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

Autopilot Standard

本页介绍了如何为 GKE 推理网关执行增量发布操作，以逐步部署推理基础架构的新版本。借助此网关，您可以安全且受控地更新推理基础架构。您可以更新节点、基准模型和 LoRA 适配器，同时尽可能减少服务中断。本页面还提供了有关流量分配和回滚的指导，以帮助确保部署可靠。

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

支持以下用例：

节点（计算、加速器）更新发布
基本模型更新发布
LoRA 适配器更新发布

更新节点发布

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

创建新的 InferencePool：部署使用更新后的节点或硬件规范配置的 InferencePool。
使用 HTTPRoute 拆分流量：配置 HTTPRoute 以在现有 InferencePool 资源和新 InferencePool 资源之间分配流量。使用 backendRefs 中的 weight 字段管理定向到新节点的流量百分比。
保持一致的 InferenceModel：保留现有的 InferenceModel 配置，以确保在两个节点配置中实现一致的模型行为。
保留原始资源：在发布期间让原始 InferencePool 和节点保持活跃状态，以便在需要时进行回滚。

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

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

如需执行节点更新发布，请执行以下步骤：

将以下示例清单保存为 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

将示例清单应用到您的集群：
```
kubectl apply -f routes-to-llm.yaml
```

原始 llm InferencePool 会接收大部分流量，而 llm-new InferencePool 会接收其余流量。逐步提高 llm-new InferencePool 的流量权重，以完成节点更新的发布。

发布基本模型

基准模型更新会分阶段发布到新的基准 LLM，从而保持与现有 LoRA 适配器的兼容性。您可以使用基本模型更新发布来升级到经过改进的模型架构，或解决特定于模型的问题。

如需发布基础模型更新，请执行以下操作：

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

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

如需发布基准模型更新，请执行以下步骤：

将以下示例清单保存为 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

将示例清单应用到您的集群：
```
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 适配器，请按以下步骤操作：

提供适配器：确保模型服务器上提供新的 LoRA 适配器版本。如需了解详情，请参阅适配器发布。
修改 InferenceModel 配置：在现有的 InferenceModel 配置中，定义多个版本的 LoRA 适配器。为每个版本分配一个唯一的 modelName（例如 llm-v1、llm-v2）。
分配流量：使用 InferenceModel 规范中的 weight 字段来控制不同 LoRA 适配器版本之间的流量分配。
保持一致的 poolRef：确保所有 LoRA 适配器版本都引用相同的 InferencePool。这可以防止重新部署节点或 InferencePool。在 InferenceModel 配置中保留之前的 LoRA 适配器版本，以启用回滚。

以下示例展示了两个 LoRA 适配器版本，llm-v1 和 llm-v2。这两个版本使用相同的基准模型。您可以在同一 InferenceModel 中定义 llm-v1 和 llm-v2。您可以分配权重，以逐步将流量从 llm-v1 转移到 llm-v2。借助此控件，您可以进行受控的发布，而无需对节点或 InferencePool 配置进行任何更改。

如需发布 LoRA 适配器更新，请运行以下命令：

将以下示例清单保存为 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

将示例清单应用到您的集群：

kubectl apply -f inferencemodel-sample.yaml

llm-v1 版本会接收大部分流量，而 llm-v2 版本会接收其余流量。逐步提高 llm-v2 版本的流量权重，以完成 LoRA 适配器更新的发布。

执行 GKE 推理网关的发布操作 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

更新节点发布

发布基本模型

发布 LoRA 适配器更新

后续步骤

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