Questa pagina mostra come eseguire operazioni di implementazione incrementale, che eseguono il deployment graduale di nuove versioni dell'infrastruttura di inferenza, per GKE Inference Gateway. Questo gateway ti consente di eseguire aggiornamenti sicuri e controllati dell'infrastruttura di inferenza. Puoi aggiornare nodi, modelli di base e adattatori LoRA con un'interruzione minima del servizio. Questa pagina fornisce anche indicazioni sulla suddivisione del traffico e sui rollback per garantire deployment affidabili.
Questa pagina è rivolta agli amministratori di account e identità GKE e agli sviluppatori che vogliono eseguire operazioni di implementazione per GKE Inference Gateway.
Sono supportati i seguenti casi d'uso:
- Implementazione dell'aggiornamento dei nodi (compute, acceleratore)
- Implementazione dell'aggiornamento del modello di base
Implementare un aggiornamento dei nodi
Gli aggiornamenti dei nodi migrano in modo sicuro i carichi di lavoro di inferenza alle nuove configurazioni hardware o dell'acceleratore dei nodi. Questo processo avviene in modo controllato senza interrompere il servizio del modello. Utilizza gli 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.
Crea un nuovo
InferencePool: esegui il deployment di unInferencePoolconfigurato con le specifiche aggiornate del nodo o dell'hardware.Dividi il traffico utilizzando un
HTTPRoute: configura unHTTPRouteper distribuire il traffico tra le risorseInferencePoolesistenti e quelle nuove. Utilizza il campoweightinbackendRefsper gestire la percentuale di traffico indirizzata ai nuovi nodi.Mantieni una
InferenceObjectivecoerente: mantieni la configurazioneInferenceObjectiveesistente per garantire un comportamento uniforme del modello in entrambe le configurazioni dei nodi.Conserva le risorse originali: mantieni attivi
InferencePoole i nodi originali durante l'implementazione per consentire i rollback, se necessario.
Ad esempio, puoi creare un nuovo InferencePool denominato llm-new. Configura questo pool con la stessa configurazione del modello di InferencePool llm esistente. Esegui il deployment del pool su un nuovo set di nodi all'interno del cluster. Utilizza
un HTTPRoute oggetto per dividere il traffico tra l'llm originale e il nuovo
llm-new InferencePool. Questa tecnica ti consente di aggiornare in modo incrementale i nodi del modello.
Il seguente diagramma illustra come GKE Inference Gateway esegue l'implementazione di un aggiornamento dei nodi.
Per eseguire l'implementazione di un aggiornamento dei nodi:
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 group: gateway.networking.k8s.io kind: Gateway rules: - backendRefs: - name: llm group: inference.networking.k8s.io kind: InferencePool weight: 90 - name: llm-new group: inference.networking.k8s.io kind: InferencePool weight: 10Applica il manifest di esempio al cluster:
kubectl apply -f routes-to-llm.yaml
L'originale llm InferencePool riceve la maggior parte del traffico, mentre il
llm-new InferencePool riceve il resto. Aumenta gradualmente il peso del traffico per InferencePool llm-new per completare l'implementazione dell'aggiornamento dei nodi.
Implementare un modello di base
Gli aggiornamenti dei modelli di base vengono implementati in fasi in un nuovo LLM di base, mantenendo la compatibilità con gli adattatori LoRA esistenti. Puoi utilizzare le implementazioni degli aggiornamenti dei modelli di base per eseguire l'upgrade ad architetture di modelli migliorate o per risolvere problemi specifici dei modelli.
Per implementare un aggiornamento del modello di base:
- Esegui il deployment di una nuova infrastruttura: crea nuovi nodi e un nuovo
InferencePoolconfigurato con il nuovo modello di base che hai scelto. - Configura la distribuzione del traffico: utilizza un
HTTPRouteper dividere il traffico traInferencePoolesistente (che utilizza il modello di base precedente) e il nuovoInferencePool(che utilizza il nuovo modello di base). Il campobackendRefs weightcontrolla la percentuale di traffico allocata a ogni pool. - Mantieni l'integrità di
InferenceObjective: mantieni invariata la configurazione diInferenceObjective. Questo approccio consente di garantire che il sistema applichi gli stessi adattatori LoRA in modo coerente in entrambe le versioni del modello di base. - Mantieni la funzionalità di rollback: mantieni i nodi originali e
InferencePooldurante l'implementazione per facilitare un rollback, se necessario.
Crea un nuovo InferencePool denominato llm-pool-version-2. Questo pool esegue il deployment di una nuova versione del modello di base su un nuovo set di nodi. Configurando un HTTPRoute, come mostrato nell'esempio fornito, puoi dividere in modo incrementale il traffico tra llm-pool originale e llm-pool-version-2. In questo modo puoi controllare gli aggiornamenti dei modelli di base nel cluster.
Per eseguire l'implementazione di un aggiornamento del modello di base:
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 group: gateway.networking.k8s.io kind: Gateway rules: - backendRefs: - name: llm-pool group: inference.networking.k8s.io kind: InferencePool weight: 90 - name: llm-pool-version-2 group: inference.networking.k8s.io kind: InferencePool weight: 10Applica il manifest di esempio al cluster:
kubectl apply -f routes-to-llm.yaml
L'originale llm-pool InferencePool riceve la maggior parte del traffico, mentre
llm-pool-version-2 InferencePool riceve il resto. Aumenta gradualmente il peso del traffico per InferencePool llm-pool-version-2 per completare l'implementazione dell'aggiornamento del modello di base.