Realizar operações de lançamento do gateway de inferência do GKE

Nesta página, mostramos como realizar operações de lançamento incremental, que implantam gradualmente novas versões da sua infraestrutura de inferência para o GKE Inference Gateway. Com ele, é possível fazer atualizações seguras e controladas na infraestrutura de inferência. É possível atualizar nós, modelos de base e adaptadores LoRA com interrupção mínima do serviço. Esta página também oferece orientações sobre divisão de tráfego e rollbacks para ajudar a garantir implantações confiáveis.

Esta página é destinada a administradores de identidade e conta do GKE e desenvolvedores que querem realizar operações de lançamento para o GKE Inference Gateway.

Os seguintes casos de uso são aceitos:

Atualizar um lançamento de nós

As implantações de atualização de nós migram com segurança as cargas de trabalho de inferência para novas configurações de hardware ou acelerador de nós. Esse processo acontece de maneira controlada, sem interromper o serviço do modelo. Use as implantações de atualização de nós para minimizar a interrupção do serviço durante upgrades de hardware, atualizações de driver ou resolução de problemas de segurança.

  1. Crie um novo InferencePool: implante um InferencePool configurado com o nó ou as especificações de hardware atualizadas.

  2. Divida o tráfego usando um HTTPRoute: configure um HTTPRoute para distribuir o tráfego entre os recursos InferencePool atuais e novos. Use o campo weight em backendRefs para gerenciar a porcentagem de tráfego direcionada aos novos nós.

  3. Mantenha um InferenceModel consistente: retenha a configuração InferenceModel atual para garantir um comportamento uniforme do modelo nas duas configurações de nó.

  4. Reter recursos originais: mantenha os InferencePool e nós originais ativos durante o lançamento para permitir rollbacks, se necessário.

Por exemplo, você pode criar um novo InferencePool chamado llm-new. Configure esse pool com a mesma configuração de modelo do seu llm InferencePool atual. Implante o pool em um novo conjunto de nós no cluster. Use um objeto HTTPRoute para dividir o tráfego entre o llm original e o novo llm-new InferencePool. Com essa técnica, é possível atualizar os nós do modelo de forma incremental.

O diagrama a seguir ilustra como o GKE Inference Gateway realiza um lançamento de atualização de nó.

Processo de lançamento da atualização de nós
Figura : processo de lançamento da atualização de nós

Para fazer o lançamento de uma atualização de nó, siga estas etapas:

  1. Salve o seguinte manifesto de amostra como 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. Aplique o manifesto de exemplo ao cluster:

    kubectl apply -f routes-to-llm.yaml

O llm InferencePool original recebe a maior parte do tráfego, enquanto o llm-new InferencePool recebe o restante. Aumente gradualmente a ponderação de tráfego para o llm-new InferencePool para concluir o lançamento da atualização do nó.

Lançar um modelo de base

As atualizações do modelo de base são lançadas em fases para um novo LLM de base, mantendo a compatibilidade com os adaptadores LoRA atuais. É possível usar os lançamentos de atualizações do modelo de base para fazer upgrade para arquiteturas de modelo aprimoradas ou para resolver problemas específicos do modelo.

Para lançar uma atualização do modelo de base:

  1. Implantar nova infraestrutura: crie novos nós e um novo InferencePool configurado com o novo modelo de base escolhido.
  2. Configurar a distribuição de tráfego: use um HTTPRoute para dividir o tráfego entre o InferencePool atual (que usa o modelo de base antigo) e o novo InferencePool (usando o novo modelo de base). O campo backendRefs weight controla a porcentagem de tráfego alocada a cada pool.
  3. Mantenha a integridade do InferenceModel: não mude a configuração do InferenceModel. Isso garante que o sistema aplique os mesmos adaptadores LoRA de maneira consistente nas duas versões do modelo de base.
  4. Preserve a capacidade de reversão: mantenha os nós originais e InferencePool durante o lançamento para facilitar uma reversão, se necessário.

Você cria um novo InferencePool chamado llm-pool-version-2. Esse pool implanta uma nova versão do modelo de base em um novo conjunto de nós. Ao configurar um HTTPRoute, como mostrado no exemplo fornecido, é possível dividir o tráfego de forma incremental entre o llm-pool original e llm-pool-version-2. Isso permite controlar as atualizações do modelo de base no seu cluster.

Para fazer o lançamento de uma atualização do modelo de base, siga estas etapas:

  1. Salve o seguinte manifesto de amostra como 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. Aplique o manifesto de exemplo ao cluster:

    kubectl apply -f routes-to-llm.yaml

O llm-pool InferencePool original recebe a maior parte do tráfego, enquanto o llm-pool-version-2 InferencePool recebe o restante. Aumente gradualmente o peso do tráfego para o llm-pool-version-2 InferencePool para concluir o lançamento da atualização do modelo de base.

Lançar atualizações do adaptador LoRA

Com as implantações de atualizações graduais do adaptador LoRA, é possível implantar novas versões de modelos refinados em fases, sem alterar o modelo de base ou a infraestrutura subjacente. Use implantações de atualização do adaptador LoRA para testar melhorias, correções de bugs ou novos recursos nos seus adaptadores LoRA.

Para atualizar um adaptador LoRA, siga estas etapas:

  1. Disponibilizar adaptadores: verifique se as novas versões do adaptador LoRA estão disponíveis nos servidores de modelo. Para mais informações, consulte Implantação do adaptador.

  2. Modifique a configuração InferenceModel: na configuração InferenceModel atual, defina várias versões do seu adaptador LoRA. Atribua um modelName exclusivo a cada versão (por exemplo, llm-v1, llm-v2).

  3. Distribuir tráfego: use o campo weight na especificação InferenceModel para controlar a distribuição de tráfego entre as diferentes versões do adaptador LoRA.

  4. Mantenha um poolRef consistente: garanta que todas as versões do adaptador LoRA façam referência ao mesmo InferencePool. Isso evita novas implantações de nós ou InferencePool. Mantenha as versões anteriores do adaptador LoRA na configuração InferenceModel para permitir rollbacks.

O exemplo a seguir mostra duas versões do adaptador LoRA, llm-v1 e llm-v2. As duas versões usam o mesmo modelo de base. Você define llm-v1 e llm-v2 no mesmo InferenceModel. Você atribui pesos para mudar o tráfego de llm-v1 para llm-v2 de forma incremental. Esse controle permite uma implantação controlada sem exigir mudanças nos nós ou na configuração do InferencePool.

Para lançar atualizações do adaptador LoRA, execute o seguinte comando:

  1. Salve o seguinte manifesto de amostra como 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. Aplique o manifesto de exemplo ao cluster:

    kubectl apply -f inferencemodel-sample.yaml

A versão llm-v1 recebe a maior parte do tráfego, enquanto a versão llm-v2 recebe o restante. Aumente gradualmente a ponderação de tráfego para a versão llm-v2 para concluir a implantação da atualização do adaptador LoRA.

A seguir