Utilizza il routing basato sulla latenza prevista con GKE Inference Gateway

Questo documento descrive come abilitare e utilizzare il routing basato sulla latenza prevista fornito da llm-d in GKE Inference Gateway. Per impostazione predefinita, GKE Inference Gateway instrada le richieste utilizzando una combinazione di indicatori di carico ed euristiche di affinità della cache dei prefissi. Il routing basato sulla latenza prevista sostituisce i pesi euristici statici con un modello XGBoost addestrato continuamente sul traffico live, prendendo decisioni di routing più accurate man mano che i pattern dei workload cambiano.

Quando utilizzare il routing basato sulla latenza prevista

Questa funzionalità è più efficace quando si verificano le seguenti condizioni per il tuo workload:

  • Varianza elevata nella lunghezza del prompt e del completamento: la profondità della coda da sola è un proxy scadente per il carico del server quando le dimensioni delle richieste variano in modo significativo. Il predittore della latenza tiene conto del costo effettivo di precompilazione e decodifica per richiesta.
  • SLO di latenza per richiesta: quando le tue applicazioni specificano target Time-to-First-Token (TTFT) o Time-per-Output-Token (TPOT) per singole richieste, lo scheduler applica questi target durante il routing. Lo fa calcolando l'headroom (latenza prevista meno target SLO) per ogni pod candidato.
  • Regolazione statica fragile del peso: se regoli spesso l'equilibrio tra affinità della cache e indicatori di carico man mano che i pattern di traffico cambiano, il modello addestrato online si adatta automaticamente.

Come funziona il routing basato sulla latenza prevista

Questa sezione descrive in dettaglio l'architettura e la pipeline di pianificazione utilizzate dal routing basato sulla latenza prevista.

Architettura

La pianificazione basata sulla latenza prevista esegue il deployment di due container sidecar aggiuntivi all'interno del pod EPP, insieme all'EPP stesso:

Componente Descrizione
Training Server Esegue il retraining continuo dei modelli XGBoost TTFT e TPOT sugli esempi di richieste completate ricevuti dall'EPP. Utilizza il bucketing stratificato su una finestra scorrevole in modo che i regimi di traffico rari non vengano dimenticati. Scrive i modelli aggiornati in un volume condiviso.
Prediction Servers Pubblica le previsioni TTFT e TPOT per l'EPP nel percorso rapido della richiesta. Leggi l'ultimo modello addestrato dal volume condiviso. Scalabilità orizzontale: ogni istanza del server supporta circa 300 QPS di lavoro di previsione. Più istanze vengono bilanciate dal carico da un proxy di coalescenza Go nell'EPP che raggruppa le richieste di previsione simultanee in una finestra di 1 ms.

llm-d EPP scheduling pipeline

Quando è abilitata la pianificazione basata sulla latenza prevista, l'EPP elabora ogni richiesta tramite la seguente sequenza di plug-in componibili:

  1. predicted-latency-producer: chiama il server di previsione per ottenere le stime di TTFT e TPOT per ogni pod candidato in InferencePool, in base all'utilizzo attuale della cache KV, alla profondità della coda, al punteggio di corrispondenza della cache dei prefissi e alle funzionalità della richiesta in entrata di ogni pod. Dopo che la risposta viene restituita al client, il produttore invia il TTFT osservato e la latenza inter-token al server di addestramento come nuovo campione di addestramento.

    • Comportamento di fallback: se il server di previsione non è raggiungibile o restituisce un errore, l'EPP esegue automaticamente il fallback a un punteggio composito basato sull'utilizzo della cache KV, sulla profondità della coda e sulla corrispondenza della cache dei prefissi.

  2. prefix-cache-affinity-filter: questo filtro restringe l'insieme di candidati ai pod cache-warm quando il punteggio di corrispondenza della cache del prefisso di un pod supera la soglia di affinità (valore predefinito 0,80). Questa soglia separa due popolazioni osservate in produzione: i pod che hanno già una cronologia delle conversazioni memorizzata nella cache dai turni precedenti e i pod che non ce l'hanno. Questo filtro implementa una strategia di esplorazione ed exploit epsilon-greedy:

    • Exploit (percorso predefinito): questo percorso indirizza ai pod di precaricamento della cache in modo che il punteggio si concentri sul riutilizzo della cache.

    • Esplora (probabilità ridotta): questo percorso bypassa completamente il filtro su una frazione configurabile di richieste per inserire voci della cache nei pod freddi per evitare la frammentazione della cache.

    • TTFT load gate: anche nel percorso di exploit, se il TTFT previsto del pod con il miglior cache-warm supera il TTFT del miglior pod complessivo di oltre una soglia configurabile (valore predefinito di 5000 ms), l'affinità viene interrotta e viene utilizzato l'intero insieme di candidati.

  3. slo-headroom-tier-filter (solo richieste SLO): quando la richiesta include le intestazioni SLO, suddivide i pod candidati in un livello positivo (previsto per soddisfare l'SLO) e un livello negativo (previsto per violarlo).

  4. latency-scorer: assegna un punteggio ai pod candidati. Senza intestazioni SLO, viene selezionato il pod con la latenza prevista più bassa. Con le intestazioni SLO, il punteggio si basa sul margine di crescita (SLO meno latenza prevista) utilizzando headroomSelectionStrategy:

    • least (predefinito): bin-pack. Percorsi verso il pod con il margine positivo più piccolo, massimizzando l'utilizzo e mantenendo i pod meno caricati liberi per i futuri picchi di traffico.
    • most: Spread. Percorsi verso il pod con il margine più positivo, lasciando più spazio per picchi di carico imprevisti.

  5. latency-slo-admitter (solo richieste SLO): rifiuta le richieste eliminabili (la priorità è inferiore a 0) quando non è previsto che nessun pod candidato soddisfi l'SLO, anziché consumare capacità per una richiesta che non raggiungerà il target. Questo filtro non ha effetto quando le intestazioni SLO sono assenti o quando esiste un pod che soddisfa l'SLO.

  6. weighted-random-picker: seleziona il pod finale utilizzando la selezione casuale ponderata in base ai punteggi. In questo modo, il carico viene distribuito favorendo comunque i pod con un punteggio migliore.

Modalità flusso di dati

Il plug-in predicted-latency-producer supporta due modalità di addestramento, configurate utilizzando il parametro streamingMode:

  • streamingMode: false (impostazione predefinita): esegue il training sulla latenza delle richieste end-to-end (E2E). Utilizza questa modalità se il tuo workload combina risposte in streaming e non in streaming o se hai bisogno solo del routing sensibile alla latenza senza l'applicazione dell'SLO per richiesta.
  • streamingMode: true: addestra modelli TTFT e TPOT separati. Il TTFT viene registrato nel primo blocco trasmesso in streaming; il TPOT viene campionato nei token successivi. Utilizza questa modalità se il tuo workload è completamente in streaming e hai bisogno di un'applicazione significativa di x-slo-ttft-ms / x-slo-tpot-ms.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

  • Se necessario, abilita l'API Compute Engine, l'API Network Services e l'API Model Armor.

    Vai ad Abilita l'accesso alle API e segui le istruzioni.

  • Assicurati di avere un deployment di GKE Inference Gateway funzionante. Consulta Esegui il deployment di GKE Inference Gateway.

  • Assicurati che il tuo InferencePool utilizzi un insieme omogeneo di pod: tipo di GPU, pesi del modello e configurazione di pubblicazione identici.

  • Assicurati che il cluster GKE sia la versione 1.32.3 o successive.

  • Installa Helm. Consulta la guida all'installazione di Helm.

Abilita la pianificazione basata sulla latenza prevista

I seguenti passaggi ti guidano nell'abilitazione della pianificazione basata sulla latenza prevista per il deployment di GKE Inference Gateway.

Passaggio 1: installa o esegui l'upgrade di InferencePool con la latenza prevista attivata

Il flag latencyPredictor.enabled=true esegue il deployment dei sidecar del server di addestramento e del server di previsione all'interno del pod EPP e collega l'intera pipeline del plug-in di pianificazione:

helm upgrade --install INFERENCE_POOL_NAME \
  --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_LABEL \
  --set provider.name=gke \
  --set inferenceExtension.monitoring.gke.enabled=true \
  --set inferenceExtension.latencyPredictor.enabled=true \
  --version LLM_D_VERSION \
  oci://LLM_D_REGISTRY_PATH

Sostituisci quanto segue:

  • INFERENCE_POOL_NAME: il nome del tuo InferencePool, ad esempio vllm-llama3-8b-instruct.
  • MODEL_SERVER_LABEL: la chiave di etichetta utilizzata per selezionare i pod del server del modello.
  • LLM_D_VERSION: la versione del grafico Helm llm-d da utilizzare.
  • LLM_D_REGISTRY_PATH: il percorso del registro OCI llm-d.

Passaggio 2: verifica il deployment

Verifica che il pod EPP sia in esecuzione con tutti i container sidecar pronti:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

Il pod EPP deve mostrare tutti i container nello stato In esecuzione o Pronto: l'EPP stesso, il server di addestramento e uno o più server di previsione.

Passaggio 3: invia una richiesta di base

Invia una richiesta di inferenza standard per verificare che il routing funzioni prima di attivare le intestazioni SLO:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
 -H 'Content-Type: application/json' \
 -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
 -H 'x-prediction-based-scheduling: true' \
 -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0"
 }'

Sostituisci quanto segue:

  • GATEWAY_IP: l'indirizzo IP del servizio gateway.
  • PORT: il numero di porta del servizio gateway.
  • MODEL_NAME: il nome del modello da utilizzare per l'inferenza.
  • PROMPT_TEXT: il prompt di input.
  • MAX_TOKENS: il numero massimo di token da generare.

L'intestazione x-prediction-based-scheduling: true attiva questa richiesta nella pipeline di pianificazione della latenza prevista. Durante il periodo di riscaldamento del predittore, l'EPP torna al routing euristico.

(Facoltativo) Passaggio 4: invia richieste sensibili agli SLO

Per attivare l'applicazione degli SLO per richiesta, aggiungi le intestazioni degli obiettivi di latenza TTFT e TPOT:

curl -i -X POST GATEWAY_IP:PORT/v1/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer $(gcloud auth print-access-token)' \
  -H 'x-prediction-based-scheduling: true' \
  -H 'x-slo-ttft-ms: 500' \
  -H 'x-slo-tpot-ms: 50' \
  -d '{
    "model": "MODEL_NAME",
    "prompt": "PROMPT_TEXT",
    "max_tokens": MAX_TOKENS,
    "temperature": "0",
    "stream": true
  }'

Sostituisci quanto segue:

  • GATEWAY_IP: l'indirizzo IP del servizio gateway.
  • PORT: il numero di porta del servizio gateway.
  • MODEL_NAME: il nome del modello da utilizzare per l'inferenza.
  • PROMPT_TEXT: il prompt di input.
  • MAX_TOKENS: il numero massimo di token da generare.

Intestazioni delle richieste:

  • x-prediction-based-scheduling: true: attiva la richiesta nella pipeline di pianificazione della latenza prevista.
  • x-slo-ttft-ms: il tempo massimo accettabile per il primo token in millisecondi.
  • x-slo-tpot-ms: il tempo per token di output massimo accettabile in millisecondi.

Monitora la pianificazione della latenza prevista

Quando il predittore della latenza è abilitato, l'EPP espone metriche aggiuntive tramite Cloud Monitoring.

Metrica Descrizione
inference_objective_request_ttft_seconds Distribuzione TTFT effettiva (o latenza E2E se streamingMode=false).
inference_objective_request_predicted_ttft_seconds Distribuzione TTFT prevista (o latenza E2E se streamingMode=false).
inference_objective_request_tpot_seconds Distribuzione effettiva di TPOT.
inference_objective_request_predicted_tpot_seconds Distribuzione TPOT prevista.
inference_objective_request_ttft_slo_violation_total Contatore delle violazioni dello SLO TTFT.

Scalare il server di previsione

L'EPP effettua una chiamata di previsione per ogni pod candidato per ogni richiesta in entrata. Ogni istanza del server di previsione supporta circa 300 QPS di lavoro di previsione.

Indicazioni approssimative per il conteggio delle istanze del server di previsione:

QPS cluster (100 pod) Server di previsione richiesti
Fino a 1000 QPS 1 server
Fino a 5000 QPS 2 server
Fino a 10.000 QPS 4 server

Aggiungi istanze del server di previsione aggiornando il valore latencyPredictor.predictionServerCount di Helm.

Limitazioni

  • InferencePool omogeneo richiesto: non sono supportati tipi di GPU, varianti di modello o configurazioni di servizio misti all'interno di un singolo pool.
  • Periodo di riscaldamento: il modello XGBoost richiede un numero sufficiente di campioni di traffico in tempo reale prima che le previsioni diventino accurate.
  • Applicazione SLO: l'applicazione avviene solo a livello di routing. Il server del modello non termina le richieste che superano il target SLO dopo la selezione.
  • Stato: questa funzionalità è in anteprima. Non è consigliato per i workload di produzione con requisiti SLA rigorosi senza test approfonditi.

Passaggi successivi