Esegui operazioni di implementazione per GKE Inference Gateway

Questa pagina mostra come eseguire operazioni di implementazione incrementale, che eseguono gradualmente il deployment di nuove versioni dell'infrastruttura di inferenza per GKE Inference Gateway. Questo gateway ti consente di eseguire aggiornamenti sicuri e controllati della tua infrastruttura di inferenza. Puoi aggiornare i nodi, i modelli di base e gli adattatori LoRa con interruzioni minime del servizio. Questa pagina fornisce inoltre indicazioni sulla suddivisione del traffico e sui rollback per garantire implementazioni affidabili.

Questa pagina è rivolta agli amministratori di account e di identità GKE e agli sviluppatori che vogliono eseguire operazioni di implementazione per GKE Inference Gateway.

Sono supportati i seguenti casi d'uso:

Aggiornare l'implementazione di un nodo

Gli aggiornamenti dei nodi eseguono la migrazione sicura dei carichi di lavoro di inferenza a nuovo hardware dei nodi o a configurazioni di acceleratori. Questo processo avviene in modo controllato senza interrompere il servizio del modello. Utilizza le implementazioni degli aggiornamenti dei nodi per ridurre al minimo l'interruzione del servizio durante gli upgrade hardware, gli aggiornamenti dei driver o la risoluzione dei problemi di sicurezza.

  1. Crea un nuovo InferencePool: esegui il deployment di un InferencePool configurato con le specifiche hardware o del nodo aggiornate.

  2. Suddividi il traffico utilizzando un HTTPRoute: configura un HTTPRoute per distribuire il traffico tra le risorse InferencePool esistenti e nuove. Utilizza il campo weight in backendRefs per gestire la percentuale di traffico indirizzata ai nuovi nodi.

  3. Mantieni un InferenceModel coerente: mantieni la configurazione InferenceModel esistente per garantire un comportamento uniforme del modello in entrambe le configurazioni dei nodi.

  4. Mantieni le risorse originali: mantieni attivi InferencePool e i nodi originali durante l'implementazione per abilitare i rollback, se necessario.

Ad esempio, puoi creare un nuovo InferencePool denominato llm-new. Configura questo pool con la stessa configurazione del modello del tuo llm InferencePool esistente. Esegui il deployment del pool su un nuovo insieme di nodi all'interno del cluster. Utilizza un oggetto HTTPRoute per suddividere il traffico tra llm originale e llm-new nuovo InferencePool. Questa tecnica ti consente di aggiornare in modo incrementale i nodi del modello.

Il seguente diagramma illustra come GKE Inference Gateway esegue il rollout di un aggiornamento del nodo.

Procedura di implementazione dell'aggiornamento dei nodi
Figura: procedura di implementazione dell'aggiornamento dei nodi

Per eseguire il rollout di un aggiornamento del nodo, svolgi i seguenti passaggi:

  1. Salva il seguente manifest di esempio come 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. Applica il manifest di esempio al cluster:

    kubectl apply -f routes-to-llm.yaml

La pagina llm InferencePool originale riceve la maggior parte del traffico, mentre la pagina llm-new InferencePool riceve il resto del traffico. Aumenta gradualmente il peso del traffico per llm-new InferencePool per completare l'implementazione dell'aggiornamento del nodo.

Implementare un modello di base

Gli aggiornamenti del modello di base vengono implementati in fasi in un nuovo LLM di base, mantenendo la compatibilità con gli adattatori LoRa esistenti. Puoi utilizzare i rollout degli aggiornamenti dei modelli di base per eseguire l'upgrade ad architetture di modelli migliorate o per risolvere problemi specifici del modello.

Per implementare un aggiornamento del modello di base:

  1. Esegui il deployment di una nuova infrastruttura: crea nuovi nodi e un nuovo InferencePool configurato con il nuovo modello base che hai scelto.
  2. Configura la distribuzione del traffico: utilizza un HTTPRoute per suddividere il traffico tra il InferencePool esistente (che utilizza il vecchio modello di base) e il nuovo InferencePool (che utilizza il nuovo modello di base). Il campo backendRefs weight controlla la percentuale di traffico allocata a ogni pool.
  3. Mantieni l'integrità di InferenceModel: mantieni invariata la configurazione di InferenceModel. In questo modo, il sistema applica gli stessi adattatori LoRa in modo coerente a entrambe le versioni del modello di base.
  4. Preserva la funzionalità di rollback: mantieni i nodi eInferencePool originali durante l'implementazione per facilitare un rollback, se necessario.

Credi un nuovo InferencePool denominato llm-pool-version-2. Questo pool esegue il deployment di una nuova versione del modello di base su un nuovo insieme di nodi. Configurando un HTTPRoute, come mostrato nell'esempio fornito, puoi suddividere gradualmente il traffico tra il llm-pool originale e il llm-pool-version-2. In questo modo puoi controllare gli aggiornamenti del modello di base nel tuo cluster.

Per eseguire il rollout di un aggiornamento del modello di base, svolgi i seguenti passaggi:

  1. Salva il seguente manifest di esempio come 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. Applica il manifest di esempio al cluster:

    kubectl apply -f routes-to-llm.yaml

La pagina llm-pool InferencePool originale riceve la maggior parte del traffico, mentre la pagina llm-pool-version-2 InferencePool riceve il resto. Aumenta gradualmente il peso del traffico per llm-pool-version-2 InferencePool per completare il rollout dell'aggiornamento del modello di base.

Implementare gli aggiornamenti dell'adattatore LoRA

I rollout degli aggiornamenti dell'adattatore LoRa ti consentono di eseguire il deployment di nuove versioni di modelli ottimizzati in fasi, senza alterare il modello di base o l'infrastruttura sottostanti. Utilizza i rollout degli aggiornamenti degli adattatori LoRA per testare miglioramenti, correzioni di bug o nuove funzionalità nei tuoi adattatori LoRA.

Per aggiornare un adattatore LoRa:

  1. Rendi disponibili gli adattatori: assicurati che le nuove versioni degli adattatori LoRA siano disponibili sui server dei modelli. Per ulteriori informazioni, consulta la sezione Implementazione dell'adattatore.

  2. Modifica la configurazione di InferenceModel: nella configurazione InferenceModel esistente, definisci più versioni dell'adattatore LoRa. Assegna un valore modelName unico a ogni versione (ad es. llm-v1, llm-v2).

  3. Distribuisci il traffico: utilizza il campo weight nella specifica InferenceModel per controllare la distribuzione del traffico tra le diverse versioni dell'adattatore LoRa.

  4. Mantieni un poolRef coerente: assicurati che tutte le versioni dell'adattatore LoRA fanno riferimento allo stesso InferencePool. In questo modo, si evitano i ricollocamenti dei nodi o di InferencePool. Mantieni le versioni precedenti dell'adattatore LoRa nella configurazione di InferenceModel per abilitare i rollback.

L'esempio seguente mostra due versioni dell'adattatore LoRA, llm-v1 e llm-v2. Entrambe le versioni utilizzano lo stesso modello di base. Definisci llm-v1 e llm-v2 all'interno della stessa InferenceModel. Assegni i pesi per spostare gradualmente il traffico da llm-v1 a llm-v2. Questo controllo consente un'implementazione controllata senza richiedere modifiche ai nodi o alla configurazione di InferencePool.

Per implementare gli aggiornamenti dell'adattatore LoRa, esegui il seguente comando:

  1. Salva il seguente manifest di esempio come 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. Applica il manifest di esempio al cluster:

    kubectl apply -f inferencemodel-sample.yaml

La versione llm-v1 riceve la maggior parte del traffico, mentre la versione llm-v2 riceve il resto. Aumenta gradualmente il peso del traffico per la versione llm-v2 per completare l'implementazione dell'aggiornamento dell'adattatore LoRA.

Passaggi successivi