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

Neste documento, descrevemos 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 cache de prefixo. O roteamento baseado em latência prevista substitui os pesos heurísticos estáticos por um modelo XGBoost treinado continuamente no tráfego ativo, tomando decisões de roteamento mais precisas à medida que os padrões de carga de trabalho mudam.

Quando usar o roteamento com base na latência prevista

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

• Alta variância no comprimento do comando e da conclusão: a profundidade da fila por si só é um proxy ruim para a carga do servidor quando os tamanhos das solicitações variam muito. 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) ou tempo por token de saída (TPOT) em solicitações individuais, o programador aplica essas metas durante o roteamento. Isso é feito 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 do cache e os indicadores de carga à medida que os padrões de tráfego mudam, o modelo treinado on-line se adaptará automaticamente.

Como funciona o roteamento com base na latência prevista

Nesta seção, detalhamos a arquitetura e o pipeline de programação usados pelo roteamento com base na latência prevista.

Arquitetura

O agendamento com base na latência prevista implanta dois contêineres sidecar adicionais no pod do EPP, junto com o próprio EPP:

Pipeline de programação de 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, condicionadas à utilização atual do cache KV, profundidade da fila, pontuação de correspondência do cache de prefixo e recursos da solicitação recebida de cada pod. Depois que a resposta é retornada ao cliente, o produtor envia o TTFT observado e a latência entre tokens de volta ao servidor de treinamento como uma nova amostra de treinamento.

   • Comportamento de substituição: se o servidor de previsão estiver inacessível ou retornar um erro, a EPP vai usar automaticamente uma pontuação composta com base na utilização do cache de 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 de pré-aquecimento de cache quando a pontuação de correspondência de 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:

   • Exploit (caminho padrão): esse caminho direciona para pods de pré-aquecimento de cache para que a pontuação concentre a reutilização do cache neles.

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

   • Gate de carregamento do TTFT: mesmo no caminho de exploração, se o TTFT previsto dos melhores pods de 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 os cabeçalhos de SLO, a pontuação é baseada na margem de lucro (SLO menos latência prevista) usando o headroomSelectionStrategy:

   • least (padrão): bin packing. Encaminha para o pod com o menor headroom positivo, maximizando a utilização e mantendo os pods menos carregados livres para futuros picos de tráfego.
   • most: intervalo. Rotas para o pod com a maior margem positiva, deixando mais espaço para picos de carga inesperados.

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

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

Modo de streaming

O plug-in predicted-latency-producer é compatível com 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). 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 imposição de SLO por solicitação.
• streamingMode: true: treina modelos TTFT e TPOT separados. O TTFT é registrado no primeiro bloco transmitido, e o TPOT é amostrado em tokens subsequentes. Use esse modo se a carga de trabalho for totalmente de streaming 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:

• Ative 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, Network Services e Model Armor, se necessário.

  Acesse Ativar acesso a APIs e siga as instruções.

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

• Verifique se o InferencePool usa um conjunto homogêneo de pods: tipo de GPU, pesos do modelo e configuração de serviç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 o agendamento com base na latência prevista

As etapas a seguir orientam você a ativar o agendamento baseado em latência prevista para sua 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 dentro do pod do 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 seu 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 do EPP está em execução com todos os contêineres secundários prontos:

kubectl get pods -l app=INFERENCE_POOL_NAME-epp

O pod do 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: envie uma solicitação de comparativo de mercado

Envie uma solicitação de inferência padrão para confirmar que 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: o comando de entrada.
• MAX_TOKENS: o número máximo de tokens a serem gerados.

O cabeçalho x-prediction-based-scheduling: true inclui essa solicitação no pipeline de programação de latência prevista. Durante o período de aquecimento do preditor, o EPP volta ao 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: o comando 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 o pipeline de programação de latência prevista para a solicitação.
• x-slo-ttft-ms: tempo máximo aceitável para o primeiro token em milissegundos.
• x-slo-tpot-ms: tempo máximo aceitável por token de saída em milissegundos.

Monitorar o agendamento de latência prevista

Quando o preditor de latência está ativado, o EPP expõe outras métricas 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

• Homogêneo InferencePool necessário: tipos de GPU, variantes de modelo ou configurações de disponibilização mistos em um único pool não são compatíveis.
• Período de aquecimento: o modelo XGBoost precisa de amostras suficientes de trânsito em tempo real antes que as previsões se tornem precisas.
• Aplicação de SLO: a aplicação é feita 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.
• Realize operações de lançamento para o GKE Inference Gateway.