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


Esta página mostra como realizar operações de lançamento incremental, que implantam gradualmente novas versões da sua infraestrutura de inferência, para o gateway de inferência do GKE. Esse gateway permite que você realize atualizações seguras e controladas na sua infraestrutura de inferência. É possível atualizar nós, modelos básicos e adaptadores LoRA com a interrupção mínima do serviço. Esta página também oferece orientações sobre a divisão de tráfego e as revisões para 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 do Gateway de inferência do GKE.

Os seguintes casos de uso são compatíveis:

Atualizar um lançamento de nó

As implantações de atualização de nós migram com segurança as cargas de trabalho de inferência para novos hardwares de nó ou configurações de acelerador. Esse processo ocorre 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. Criar uma InferencePool: implantar uma InferencePool configurada com as especificações atualizadas do nó ou do hardware.

  2. Dividir 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. Manter um InferenceModel consistente: mantenha a configuração InferenceModel atual para garantir o comportamento uniforme do modelo nas duas configurações de nó.

  4. Manter os recursos originais: mantenha o InferencePool e os 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 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 InferencePool llm-new. Essa técnica permite atualizar de forma incremental os nós do modelo.

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 realizar um lançamento de 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 InferencePool llm original recebe a maior parte do tráfego, enquanto o InferencePool llm-new recebe o restante. Aumente gradualmente o peso do tráfego para o InferencePool llm-new para concluir o lançamento da atualização do nó.

Implantar um modelo base

As atualizações do modelo de referência são lançadas em fases para um novo LLM de referência, mantendo a compatibilidade com os adaptadores LoRa atuais. Você pode usar as atualizações de modelos básicos para fazer upgrade para arquiteturas de modelos aprimoradas ou resolver problemas específicos do modelo.

Para lançar uma atualização de modelo básico:

  1. Implantar nova infraestrutura: crie novos nós e um novo InferencePool configurado com o novo modelo 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 (que usa o novo modelo de base). O campo backendRefs weight controla a porcentagem de tráfego alocada para cada pool.
  3. Manter a integridade do InferenceModel: mantenha a configuração do InferenceModel inalterada. Isso garante que o sistema aplique os mesmos adaptadores LoRa de forma consistente nas duas versões do modelo básico.
  4. Preserve o recurso 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 com o nome llm-pool-version-2. Esse pool implanta uma nova versão do modelo base em um novo conjunto de nós. Ao configurar um HTTPRoute, conforme mostrado no exemplo fornecido, você pode dividir o tráfego de forma incremental entre o llm-pool original e o llm-pool-version-2. Isso permite controlar as atualizações do modelo base no cluster.

Para realizar um lançamento de atualização de modelo básico, 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 InferencePool llm-pool original recebe a maior parte do tráfego, enquanto o InferencePool llm-pool-version-2 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 básico.

Lançar atualizações do adaptador LoRA

Os lançamentos de atualização do adaptador LoRa permitem implantar novas versões de modelos ajustados em fases, sem alterar o modelo de base ou a infraestrutura subjacente. Use as atualizações de adaptadores LoRA para testar melhorias, correções de bugs ou novos recursos nos 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 Lançamento do adaptador.

  2. Modificar a configuração InferenceModel: na configuração InferenceModel atual, defina várias versões do 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. Manter um poolRef consistente: verifique se todas as versões do adaptador LoRA fazem referência ao mesmo InferencePool. Isso evita reimplantações de nó ou InferencePool. Mantenha as versões anteriores do adaptador LoRa na configuração InferenceModel para ativar reversões.

O exemplo a seguir mostra duas versões do adaptador LoRA, llm-v1 e llm-v2. As duas versões usam o mesmo modelo básico. Você define llm-v1 e llm-v2 na mesma InferenceModel. Você atribui pesos para mudar gradualmente o tráfego de llm-v1 para llm-v2. Esse controle permite um lançamento controlado sem requerer nenhuma mudança nos nós ou na configuração 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 o peso do tráfego para a versão llm-v2 para concluir o lançamento da atualização do adaptador LoRA.

A seguir