A execução de modelos de linguagem de grande escala (LLMs) em ambientes de nuvem exige uma infraestrutura de roteamento altamente eficiente. Em clusters Kubernetes, como o Amazon EKS, o desafio vai além de apenas subir pods; trata-se de garantir que as requisições cheguem ao destino correto, considerando fatores como a localidade do cache KV e a prioridade das tarefas. O uso de recursos customizados (CRDs) permite que o cluster tome decisões de roteamento em tempo real, otimizando a latência e o uso de recursos.
O Papel do Endpoint Picker (EPP)
No coração dessa arquitetura está o Endpoint Picker (EPP), um componente responsável por decidir para qual pod de inferência (vLLM) uma requisição deve ser enviada. Este componente opera como um servidor gRPC e é composto, geralmente, por dois contêineres principais: um responsável pela lógica de roteamento e outro focado no rastreamento do estado do cache KV entre as réplicas. A comunicação entre esses contêineres, muitas vezes realizada via ZeroMQ, permite que o sistema escolha o pod que já possui os dados necessários em cache, reduzindo drasticamente o tempo de resposta.
Integração com Envoy e Ext-Proc
O roteamento inteligente é viabilizado pelo recurso external processor (ext-proc) do Envoy. Quando uma requisição chega ao gateway, o Envoy pausa o processamento e consulta o EPP via gRPC. O EPP analisa o estado atual do cluster e indica o melhor destino. Esse padrão permite que a infraestrutura de rede tome decisões baseadas em contexto, algo fundamental para aplicações de IA que dependem de alta performance.
Gerenciamento de Prioridades com InferenceObjective
Para ambientes de produção, nem todas as requisições possuem a mesma urgência. O uso de InferenceObjective permite definir prioridades para o tráfego. Ao configurar um objetivo, é possível garantir que requisições sensíveis à latência sejam processadas antes de tarefas em lote (batch). Os clientes podem selecionar essas prioridades através de cabeçalhos HTTP customizados, permitindo um controle granular sobre a fila de processamento.
Considerações de Segurança e RBAC
A implementação correta desses recursos exige atenção ao controle de acesso (RBAC). O scheduler (EPP) precisa de permissões para monitorar os recursos InferencePool e InferenceObjective. É importante notar que, em uma arquitetura bem segmentada, o pod do gateway (Envoy) não deve ter acesso direto à API do Kubernetes. O controle é feito pelo plano de controle do Istio, que compila as configurações e as distribui, garantindo que o gateway saiba apenas para onde enviar o tráfego, sem expor permissões desnecessárias ao nível de rede.
Impacto Prático para Infraestrutura
Para administradores de sistemas e engenheiros de cloud, adotar essa abordagem significa:
- Redução de Latência: Ao rotear requisições para pods com cache KV local, evita-se o reprocessamento desnecessário.
- Escalabilidade: O uso de
InferencePoolpermite agrupar pods de forma lógica, facilitando a gestão de grandes frotas de modelos. - Flexibilidade: A capacidade de definir prioridades por requisição permite que a mesma infraestrutura atenda tanto a usuários finais quanto a processos internos de processamento de dados.
Implementar esse nível de automação no Kubernetes transforma o cluster em uma plataforma robusta para inferência, garantindo que a infraestrutura de servidores e cloud seja utilizada de forma inteligente e eficiente.