Usar o roteamento baseado em latência prevista com o GKE Inference Gateway

Este documento descreve como ativar e usar o roteamento baseado em latência prevista fornecido pelo llm-d no GKE Inference Gateway. Por padrão, o GKE Inference Gateway encaminha solicitações usando uma combinação de indicadores de carga e heurísticas de afinidade de prefixo-cache. O roteamento baseado em latência prevista substitui os pesos heurísticos estáticos por um modelo XGBoost treinado continuamente no tráfego em tempo real, tomando decisões de roteamento mais precisas à medida que os padrões de carga de trabalho mudam.

Quando usar o roteamento baseado em latência prevista

Esse recurso é mais eficaz quando as condições a seguir se aplicam à sua carga de trabalho:

• Alta variância no comprimento da solicitação e da conclusão: a profundidade da fila sozinha é um proxy ruim para a carga do servidor quando os tamanhos das solicitações variam significativamente. O preditor de latência considera o custo real de pré-preenchimento e decodificação por solicitação.
• SLOs de latência por solicitação: quando seus aplicativos especificam metas de Tempo até o Primeiro Token (TTFT, na sigla em inglês) ou Tempo por Token de Saída (TPOT, na sigla em inglês) em solicitações individuais, o programador aplica essas metas durante o roteamento. Ele faz isso calculando a margem (latência prevista menos a meta de SLO) para cada pod candidato.
• Ajuste de peso estático frágil: se você estiver reajustando com frequência o equilíbrio entre a afinidade de cache e os indicadores de carga à medida que os padrões de tráfego mudam, o modelo treinado on-line se adapta automaticamente.

Como funciona o roteamento baseado em latência prevista

Esta seção detalha a arquitetura e o pipeline de programação usado pelo roteamento baseado em latência prevista.

Arquitetura

A programação baseada em latência prevista implanta dois contêineres sidecar adicionais no pod EPP, além do próprio EPP:

Pipeline de programação do EPP llm-d

Quando a programação baseada em latência prevista está ativada, o EPP processa cada solicitação na seguinte sequência de plug-ins combináveis:

1. predicted-latency-producer: chama o servidor de previsão para receber estimativas de TTFT e TPOT para cada pod candidato no InferencePool, condicionado à utilização atual do cache KV, à profundidade da fila, à pontuação de correspondência do cache de prefixo e aos recursos de solicitação recebidos de cada pod. Depois que a resposta é retornada ao cliente, o produtor envia a latência observada de TTFT e entre tokens de volta ao servidor de treinamento como uma nova amostra de treinamento.

   • Comportamento de fallback: se o servidor de previsão estiver inacessível ou retornar um erro, o EPP fará o fallback automático para uma pontuação composta com base na utilização do cache KV, na profundidade da fila e na correspondência do cache de prefixo.

2. prefix-cache-affinity-filter: esse filtro restringe o conjunto de candidatos a pods com cache quente quando a pontuação de correspondência do cache de prefixo de qualquer pod excede o limite de afinidade (padrão de 0,80). Esse limite separa duas populações observadas na produção: pods que já têm um histórico de conversas armazenado em cache de turnos anteriores e pods que não têm. Esse filtro implementa uma estratégia de exploração e descoberta epsilon-greedy:

   • Explorar (caminho padrão): esse caminho é roteado para pods com cache quente para que a pontuação concentre a reutilização do cache neles.

   • Descobrir (pequena probabilidade): esse caminho ignora o filtro completamente em uma fração configurável de solicitações para propagar entradas de cache em pods frios para evitar a fragmentação do cache.

   • Portão de carga TTFT: mesmo no caminho de exploração, se o TTFT previsto do melhor pod com cache quente exceder o TTFT do melhor pod geral em mais de um limite configurável (padrão de 5.000 ms), a afinidade será interrompida e o conjunto completo de candidatos será usado.

3. slo-headroom-tier-filter (somente solicitações de SLO): quando a solicitação inclui cabeçalhos de SLO, divide os pods candidatos em um nível positivo (previsto para atender ao SLO) e um nível negativo (previsto para violá-lo).

4. latency-scorer: pontua os pods candidatos. Sem cabeçalhos de SLO, o pod com a menor latência prevista é selecionado. Com cabeçalhos de SLO, a pontuação é baseada na margem (SLO menos latência prevista) usando a headroomSelectionStrategy:

   • least (padrão): bin-pack. É roteado para o pod com a menor margem positiva, maximizando a utilização e mantendo os pods menos carregados livres para picos de tráfego futuros.
   • most: espalhar. É roteado para o pod com a margem mais positiva, deixando mais espaço para picos de carga inesperados.

5. latency-slo-admitter (somente solicitações de SLO): rejeita solicitações descartáveis (a prioridade é menor que 0) quando nenhum pod candidato é previsto para atender ao SLO, em vez de consumir capacidade em uma solicitação prevista para perder a meta. Esse filtro não tem efeito quando os cabeçalhos de SLO estão ausentes ou quando um pod que atende ao SLO existe.

6. weighted-random-picker: seleciona o pod final usando a seleção aleatória ponderada nas pontuações. Isso distribui a carga, mas ainda favorece pods com melhor pontuação.

Modo de streaming

O plug-in predicted-latency-producer oferece suporte a dois modos de treinamento, configurados usando o parâmetro streamingMode:

• streamingMode: false (padrão): treina na latência de solicitação de ponta a ponta (E2E, na sigla em inglês). Use esse modo se a carga de trabalho misturar respostas de streaming e não streaming ou se você precisar apenas de roteamento com reconhecimento de latência sem aplicação de SLO por solicitação.
• streamingMode: true: treina modelos TTFT e TPOT separados. O TTFT é gravado no primeiro bloco transmitido; o TPOT é amostrado em tokens subsequentes. Use esse modo se a carga de trabalho for totalmente transmitida e você precisar de uma aplicação significativa de x-slo-ttft-ms / x-slo-tpot-ms.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

• Ativar a API Google Kubernetes Engine.
Ativar a API Google Kubernetes Engine
• Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.

• Ative a API Compute Engine, a API Network Services e a API Model Armor, se necessário.

  Acesse Ativar o acesso às APIs e siga as instruções.

• Verifique se você tem uma implantação funcional do GKE Inference Gateway. Consulte Implantar o GKE Inference Gateway.

• Verifique se o InferencePool usa um conjunto homogêneo de pods: tipo de GPU, pesos de modelo e configuração de veiculação idênticos.

• Verifique se o cluster do GKE é a versão 1.32.3 ou mais recente.

• Instale o Helm. Consulte o guia de instalação do Helm.

Ativar a programação baseada em latência prevista

As etapas a seguir orientam você na ativação da programação baseada em latência prevista para a implantação do GKE Inference Gateway.

Etapa 1: instalar ou fazer upgrade do InferencePool com a latência prevista ativada

A flag latencyPredictor.enabled=true implanta os sidecars do servidor de treinamento e do servidor de previsão no pod EPP e conecta o pipeline completo do plug-in de programação:

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

Substitua:

• INFERENCE_POOL_NAME: o nome do InferencePool. Por exemplo, vllm-llama3-8b-instruct.
• MODEL_SERVER_LABEL: a chave de rótulo usada para selecionar os pods do servidor de modelo.
• LLM_D_VERSION: a versão do gráfico do Helm llm-d a ser usada.
• LLM_D_REGISTRY_PATH: o caminho do registro OCI llm-d.

Etapa 2: verificar a implantação

Confirme se o pod EPP está em execução com todos os contêineres sidecar prontos:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

O pod EPP precisa mostrar todos os contêineres no estado "Em execução" ou "Pronto": o próprio EPP, o servidor de treinamento e um ou mais servidores de previsão.

Etapa 3: enviar uma solicitação de linha de base

Envie uma solicitação de inferência padrão para confirmar se o roteamento está funcionando antes de ativar os cabeçalhos de 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"
 }'

Substitua:

• GATEWAY_IP: o endereço IP do serviço de gateway.
• PORT: o número da porta do serviço de gateway.
• MODEL_NAME: o nome do modelo a ser usado para inferência.
• PROMPT_TEXT: a solicitação de entrada.
• MAX_TOKENS: o número máximo de tokens a serem gerados.

O cabeçalho x-prediction-based-scheduling: true ativa essa solicitação no pipeline de programação de latência prevista. Durante o período de aquecimento do preditor, o EPP faz o fallback para o roteamento heurístico.

Etapa 4: enviar solicitações com reconhecimento de SLO (opcional)

Para ativar a aplicação de SLO por solicitação, adicione cabeçalhos de objetivo de latência 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
  }'

Substitua:

• GATEWAY_IP: o endereço IP do serviço de gateway.
• PORT: o número da porta do serviço de gateway.
• MODEL_NAME: o nome do modelo a ser usado para inferência.
• PROMPT_TEXT: a solicitação de entrada.
• MAX_TOKENS: o número máximo de tokens a serem gerados.

Cabeçalhos de solicitação:

• x-prediction-based-scheduling: true: ativa a solicitação no pipeline de programação de latência prevista.
• x-slo-ttft-ms: tempo máximo aceitável até o primeiro token em milissegundos.
• x-slo-tpot-ms: tempo máximo aceitável por token de saída em milissegundos.

Monitorar a programação de latência prevista

Quando o preditor de latência está ativado, o EPP expõe métricas adicionais pelo Cloud Monitoring.

Escalonar o servidor de previsão

O EPP faz uma chamada de previsão por pod candidato por solicitação recebida. Cada instância do servidor de previsão sustenta aproximadamente 300 QPS de trabalho de previsão.

Orientação aproximada para a contagem de instâncias do servidor de previsão:

Adicione instâncias do servidor de previsão atualizando o valor do Helm latencyPredictor.predictionServerCount.

Limitações

• **`InferencePool` homogêneo necessário**: tipos de GPU mistos, variantes de modelo, ou configurações de veiculação em um único pool não são aceitos.InferencePool
• Período de aquecimento: o modelo XGBoost requer amostras de tráfego em tempo real suficientes antes que as previsões se tornem precisas.
• Aplicação de SLO: a aplicação está apenas na camada de roteamento. O servidor de modelo não encerra solicitações que excedem a meta de SLO após a seleção.
• Status: esse recurso está em pré-lançamento. Não é recomendado para cargas de trabalho de produção com requisitos de SLA rigorosos sem testes completos.

A seguir

• Personalizar a configuração do GKE Inference Gateway.
• Realizar operações de lançamento para o GKE Inference Gateway.