Gateway de Aplicativo para Contêineres – Gateway de Inferência

As cargas de trabalho de inferência de IA não se comportam como aplicativos HTTP sem estado tradicionais. As solicitações geralmente são específicas do modelo, de execução longa, caras para servir e sensíveis a sinais de runtime, como disponibilidade de acelerador, profundidade da fila, prioridade de solicitação, orçamento de token e capacidade do servidor modelo.

O Gateway de inferência do Application Gateway for Containers oferece suporte a essas cargas de trabalho ao se integrar à API Gateway API Inference Extension do Kubernetes, que adiciona recursos sensíveis à inferência ao modelo da API Gateway. Ao usar o gateway de inferência, você pode expor servidores de modelos auto-hospedados por meio do Gateway de Aplicativo para Contêineres com comportamento de roteiros sensível ao modelo e à carga.

O gateway de inferência foi projetado especificamente para executar grandes modelos de linguagem (LLMs) e outras cargas de trabalho de inferência. Ele roteia solicitações com base em sinais de servidor modelo em vez de balanceamento de carga genérico, o que reduz o tempo para o primeiro token (TTFT), reduz os tempos limite sob carga e melhora a eficiência da GPU. Baseado nos recursos de entrada do Gateway de Aplicativo para Contêineres, o gateway de inferência também permite que você emparelhe cargas de trabalho de IA com recursos como o WAF (firewall do aplicativo Web) para proteger o tráfego antes que ele atinja seus servidores modelo.

Muitos runtimes de inferência auto-hospedados, incluindo vLLM, expõem APIs HTTP compatíveis com a OpenAI, como /v1/chat/completions, /v1/completions e /v1/models. Compatível com OpenAI refere-se ao formato de API, não a uma restrição aos modelos hospedados pelo OpenAI. Se outra família de modelos for disponibilizada por meio de um runtime ou proxy que use esse formato, o Application Gateway for Containers poderá usar o campo model no corpo da solicitação JSON para fazer roteamento com base no corpo da solicitação.

O que a Extensão de Inferência da API do Gateway fornece

A extensão de inferência da Gateway API transforma uma implementação da Gateway API em um gateway de inferência ao adicionar conceitos de backend e agendamento específicos para inferência.

A extensão apresenta estes principais recursos e componentes:

• InferencePool: um recurso de backend que representa um grupo de pods de servidor de modelos e o seletor de endpoint usado para selecionar um pod para cada solicitação de inferência.
• InferenceObjective: Um recurso que representa objetivos de atendimento de solicitações, como prioridade, para solicitações que compartilham um InferencePool.
• Seletor de endpoint (EPP): uma extensão fornecida pelo cliente que é executada em seu cluster e implementa o agendamento de inferência. O EPP recebe os metadados da solicitação, atribui pontuações aos pods candidatos de servidor de modelos usando plug-ins configuráveis (por exemplo, profundidade da fila, utilização do cache KV e afinidade com o cache de prefixo) e retorna o endpoint selecionado. Como a seleção de endpoint é executada no EPP, os comportamentos de roteiros disponíveis dependem dos plugins de pontuação que seu EPP habilita.
• Roteamento baseado em corpo (BBR): um processador de solicitação que pode inspecionar um corpo de solicitação compatível com OpenAI, extrair o nome do modelo e disponibilizá-lo para o gateway como o X-Gateway-Model-Name cabeçalho para roteamento com reconhecimento de modelo.

O Gateway de Aplicativo para Contêineres executa o processador BBR como uma parte gerenciada do gateway, portanto, não há nenhuma camada de roteamento baseada em corpo separada para implantar, dimensionar ou aplicar patches. Integra-se a um EPP fornecido pelo cliente para oferecer suporte a decisões de roteamento no momento da solicitação. O gateway de inferência dá suporte ao API de Extensão de Inferência do API de Gateway. Sendo assim, você pode configurar essas funções por meio de recursos do API de Gateway padrão e as equipes de plataforma podem usar um modelo de API nativo do Kubernetes para tráfego de inferência em vez de introduzir um modelo de configuração de entrada separado.

Como o Application Gateway para Contêineres usa recursos de inferência

O Application Gateway for Containers continua a usar recursos padrão da API Gateway para a configuração de ingresso. O comportamento de inferência é ativado quando uma referência de back-end HTTPRoute aponta para um InferencePool em vez de um Service do Kubernetes.

Para rotas que não são de inferência, o Application Gateway for Containers mantém o comportamento existente da Gateway API. As rotas direcionadas aos back-ends do Kubernetes Service não invocam processadores de inferência e não recebem um comportamento de roteiros específico de inferência.

Para rotas de inferência, o plano de controle reconcilia a API do Gateway e os recursos de inferência e programa o plano de dados para que:

• O HTTPRoute seleciona o back-end InferencePool.
• O InferencePool seleciona os pods do servidor de modelo que pertencem ao pool.
• O EPP associado ao pool é chamado para selecionar o endpoint.
• O ponto de extremidade do servidor de modelo selecionado recebe a solicitação.
• O roteamento opcional com reconhecimento de modelo usa o nome do modelo de solicitação extraído pelo BBR.

Fluxo de solicitação

Uma solicitação de inferência típica segue esse caminho. As etapas numeradas correspondem aos rótulos no diagrama a seguir:

1. Solicitação do cliente: um cliente envia uma solicitação compatível com OpenAI para o frontend do Application Gateway for Containers, e o listener do Gateway a aceita.
2. Roteamento baseado em corpo (BBR): para rotas com reconhecimento de modelo, o processador BBR gerenciado inspeciona o corpo da solicitação, extrai o nome do modelo e injeta o X-Gateway-Model-Name cabeçalho. O HTTPRoute pode então usar esse valor para selecionar o InferencePool apropriado.
3. Seleção de ponto de extremidade: quando a rota correspondente tem como destino um InferencePool, o Gateway de Aplicativo para Contêineres invoca o EPP, que avalia a solicitação e a telemetria do servidor de modelo e retorna o ponto de extremidade selecionado.
4. Roteamento para o InferencePool: o Application Gateway for Containers encaminha a solicitação ao pod do servidor de modelo selecionado, e a resposta do servidor de modelo é retornada ao cliente por meio do gateway.

Capacidades de encaminhamento

O gateway de inferência dá suporte a esses padrões de roteamento para cargas de trabalho de IA auto-hospedadas. A seleção de endpoints é executada no EPP, portanto os comportamentos sensíveis à carga e ao cache dependem dos plug-ins de pontuação que seu EPP habilita.

• Roteamento com reconhecimento do modelo: roteie solicitações com base no nome do modelo em corpos de requisição compatíveis com OpenAI, que o processador BBR gerenciado extrai.
• Divisão e distribuição de tráfego: use o padrão HTTPRoute ponderado backendRefs para dividir o tráfego entre InferencePool back-ends para distribuições de modelo canário ou azul-verde.
• Seleção de endpoint sensível à carga e cache: o EPP pontua endpoints usando a telemetria do servidor modelo, como a profundidade da fila e a utilização do cache KV. Quando o EPP habilita a pontuação sensível ao cache de prefixo, as solicitações que compartilham um prefixo do prompt são encaminhadas para a mesma réplica, a fim de aumentar os acertos de cache e reduzir o TTFT.
• Prioridade da solicitação e proteção contra sobrecarga: use os recursos InferenceObjective e o cabeçalho de solicitação x-gateway-inference-objective para atribuir prioridade de atendimento. Quando os servidores de modelo ficam sobrecarregados, o EPP descarta primeiro as solicitações de menor prioridade para proteger o tráfego sensível à latência.
• Seleção de ponto de extremidade resiliente: configure o comportamento de falha do EPP com FailOpen ou FailClose, dependendo se a disponibilidade ou a seleção estrita de ponto de extremidade é mais importante para um pool.
• Compatibilidade da API do Gateway: continue usando o Gateway, HTTPRoute, ReferenceGrant e condições de status da API de Gateway padrão para a configuração de entrada.

Inferência segura

Mantenha os servidores de modelo privados por trás do gateway gerenciado e aplique os recursos de segurança da plataforma para inferência de tráfego.

• WAF (firewall do aplicativo Web): o gateway de inferência é emparelhado nativamente com a funcionalidade existente do WAF no Gateway de Aplicativo para Contêineres, aplicando proteções alinhadas ao OWASP ao tráfego de IA antes que as solicitações cheguem aos servidores modelo.
• Proteção para back-ends caros: como a política é imposta na borda gerenciada, solicitações malformadas ou abusivas podem ser inspecionadas e bloqueadas antes de consumirem a capacidade escassa do GPU.

Cenários de exemplo

Os cenários a seguir mostram maneiras comuns de usar o gateway de inferência:

• Implantar e lançar versões de modelos: encaminhe solicitações compatíveis com o OpenAI para um InferencePool com base no nome do modelo e, em seguida, use backendRefs HTTPRoute ponderados para direcionar uma porcentagem do tráfego para uma nova versão do modelo para teste de canário antes de concluir a distribuição.
• Priorizar o tráfego crítico de latência: defina InferenceObjective recursos para cargas de trabalho de alta prioridade e de baixa prioridade em um pool compartilhado. As solicitações interativas do chat têm alta prioridade, enquanto as tarefas em lote usam uma prioridade mais baixa, que é descartada primeiro quando o pool fica saturado.

InferencePool comparado com o Serviço

Um Kubernetes Service continua sendo a abstração de back-end adequada para o tráfego padrão de aplicações. Use um InferencePool quando o back-end for um grupo de pods de servidor de modelo que precisa de uma seleção de endpoints específica de inferência.

Um InferencePool inclui um seletor de pod, informações da porta de destino e uma referência a um seletor de endpoint. O EPP é responsável por selecionar o endpoint para uma solicitação. Um único EPP é associado a um único pool.

Comportamento em caso de falha

Os roteiros de inferência são um comportamento em tempo de solicitação, portanto o modo de falha do seletor de endpoint é importante.

InferencePool As referências de seletor de endpoint oferecem suporte aos seguintes modos de falha:

• FailOpen: se o EPP não estiver disponível ou não responder, o gateway poderá continuar com a seleção padrão de endpoint do pool. Essa opção preserva a disponibilidade, mas pode reduzir a qualidade do roteamento.
• FailClose: Se o EPP não estiver disponível ou não responder, o gateway rejeitará a solicitação. Essa escolha impede que o tráfego seja enviado sem que a decisão necessária de seleção do endpoint tenha sido tomada.

Para os roteiros sensíveis ao modelo que dependem da análise do corpo da solicitação, o Gateway do Aplicativo para Contêineres prioriza a correção. Se não for possível extrair o nome do modelo para uma rota que exija BBR, a solicitação será rejeitada em vez de ser roteada silenciosamente para o back-end do modelo errado.

Considerações operacionais

Considere os seguintes aspectos ao executar cargas de trabalho de inferência por trás de um Application Gateway for Containers:

• Capacidade do EPP: o EPP está no caminho da solicitação para os InferencePool back-ends. Dimensione e monitore-o como um componente de aplicativo crítico.
• Telemetria do servidor de modelo: o EPP precisa de novas métricas de servidor de modelo para tomar decisões de roteamento de alta qualidade. Confirme se o servidor de modelo dá suporte às métricas esperadas pela configuração do EPP.
• Capacidade de GPU e agendamento: os pods do servidor de modelos geralmente exigem pools de nós de GPU, plugins de dispositivo e credenciais para download de modelos.
• Escalonamento automático: escale os pods do servidor de modelo com base em sinais de inferência, como a profundidade da fila e a utilização do cache KV, usando o Horizontal Pod Autoscaler ou o KEDA. O dimensionamento automático adiciona capacidade à medida que a demanda aumenta, enquanto o EPP roteia em torno de réplicas que já estão saturadas.
• Respostas de streaming: muitas cargas de trabalho de conclusão de chat usam eventos enviados pelo servidor. Valide o comportamento de streaming ao testar a latência de ponta a ponta e as configurações de tempo limite.
• Observabilidade: monitoramento do status do Gateway e do HTTPRoute, do status do InferencePool, da integridade do EPP, da prontidão do servidor de modelos e das métricas do servidor de modelos, como solicitações ativas e tamanho da fila.

Limitações

O gateway de inferência se concentra em cargas de trabalho de inferência autohospedadas executadas no Kubernetes. Os roteiros diretos para endpoints do provedor de modelos públicos ou gerenciados está fora do escopo dessa integração.

A extensão de inferência da API Gateway evolui independentemente do Application Gateway for Containers. Use as versões do API e os manifestos que sejam compatíveis com os CRDs de extensão de inferência instalados no seu cluster.

Próximas Etapas 

• Configurar o Gateway de Aplicativo para Contêineres como gateway de inferência
• Componentes do Gateway de Aplicações para Contêineres
• Documentação da Extensão de Inferência da API do Gateway