Gateway de Aplicação para Contentores - Gateway de inferência

As cargas de trabalho de inferência de IA não se comportam como aplicações HTTP sem estado tradicionais. As solicitações são frequentemente específicas do modelo, de longa duração, dispendiosas de processar e sensíveis a sinais em tempo de execução, como a disponibilidade do acelerador, a profundidade da fila, a prioridade das solicitações, o orçamento de tokens e a capacidade do servidor de modelos.

O Application Gateway for Containers Inference Gateway suporta estas cargas de trabalho integrando-se com a Kubernetes Gateway API Inference Extension, que adiciona recursos conscientes da inferência ao modelo da API Gateway. Ao usar o gateway de inferência, pode expor servidores de modelos alojados localmente através do Application Gateway for Containers, com um comportamento de encaminhamento sensível ao modelo e à carga.

O gateway de inferência é concebido especificamente para servir grandes modelos de linguagem (LLMs) e outras cargas de trabalho de inferência. Encaminha pedidos com base nos sinais do servidor modelo em vez do balanceamento genérico de carga, que reduz o tempo até ao primeiro token (TTFT), reduz os timeouts sob carga e melhora a eficiência da GPU. Baseado nas capacidades de entrada do Application Gateway for Containers, o gateway de inferência também permite emparelhar cargas de trabalho de IA com capacidades como o firewall de aplicações web (WAF) para proteger o tráfego antes que chegue aos seus servidores modelo.

Muitos runtimes de inferência auto-hospedados, incluindo vLLM, expõem APIs HTTP compatíveis com OpenAI , como /v1/chat/completions, /v1/completions, e /v1/models. Compatível com OpenAI refere-se ao formato da API, não a uma restrição para modelos alojados na OpenAI. Se outra família de modelos for servida através de um runtime ou proxy que utiliza este formato, o Application Gateway for Containers pode usar o model campo no corpo do pedido JSON para o encaminhamento baseado no corpo.

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

A Extensão de Inferência da API do Gateway transforma uma implementação da API do Gateway num gateway de inferência, adicionando conceitos de backend e agendamento específicos da inferência.

A extensão introduz estes recursos e componentes primários:

• InferencePool: Um recurso backend que representa um grupo de pods de servidor modelo e o seletor de endpoint usado para selecionar um pod para cada pedido de inferência.
• InferenceObjective: Um recurso que representa objetivos de serviço de pedidos, como prioridade, para pedidos que partilham um InferencePool.
• Endpoint Picker (EPP): Uma extensão fornecida pelo cliente que corre no seu cluster e implementa o agendamento por inferência. O EPP recebe metadados do pedido, atribui pontuações a pods candidatos de servidor de modelos utilizando plugins configuráveis (por exemplo, profundidade da fila, utilização da cache KV e afinidade da cache de prefixos) e devolve o endpoint selecionado. Como a seleção do ponto terminal é executada no EPP, os comportamentos de encaminhamento disponíveis dependem dos plugins de classificação que o seu EPP tem ativados.
• Encaminhamento baseado no corpo (BBR): Um processador de solicitações que pode inspecionar o corpo de um pedido compatível com OpenAI, extrair o nome do modelo e disponibilizá-lo ao gateway como o cabeçalho X-Gateway-Model-Name para encaminhamento com reconhecimento do modelo.

O Application Gateway for Containers executa o processador BBR como uma parte gerida do gateway, pelo que não existe uma camada separada de encaminhamento com base no corpo para implementar, dimensionar ou aplicar patches. Integra-se com um EPP fornecido pelo cliente para permitir decisões de encaminhamento no momento da solicitação. O gateway de inferência suporta a API de Extensão de Inferência da API do Gateway, por isso configura estas capacidades através dos recursos padrão da API Gateway e as equipas da plataforma podem usar um modelo nativo de API Kubernetes para tráfego de inferência, em vez de introduzirem um modelo de configuração de entrada separado.

Como o Application Gateway for Containers utiliza recursos de inferência

O Application Gateway for Containers continua a utilizar recursos padrão da API do Gateway para a configuração de entrada. O comportamento de inferência é ativado quando uma referência de backend 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 que têm como destino backends do Kubernetes Service não invocam processadores de inferência nem recebem comportamento de encaminhamento específico da inferência.

Para rotas de inferência, o plano de controlo concilia a API do Gateway e os recursos de inferência e programa o plano de dados de modo que:

• O HTTPRoute seleciona o back-end InferencePool.
• O InferencePool seleciona os pods do servidor de modelos que pertencem ao pool.
• O EPP associado ao conjunto é invocado para selecionar o endpoint.
• O endpoint do servidor modelo selecionado recebe o pedido.
• O encaminhamento opcional baseado no modelo utiliza o nome do modelo do pedido extraído pelo BBR.

Fluxo de pedidos

Um pedido típico de inferência segue este caminho. Os passos numerados correspondem aos rótulos no diagrama seguinte:

1. Pedido do cliente: Um cliente envia um pedido compatível com OpenAI para a interface do Application Gateway for Containers, e o ouvinte do Gateway aceita-o.
2. Encaminhamento baseado no corpo (BBR): Para rotas com reconhecimento do modelo, o processador BBR gerido inspeciona o corpo do pedido, extrai o nome do modelo e injeta o cabeçalho X-Gateway-Model-Name. O HTTPRoute pode então basear-se nesse valor para selecionar o InferencePool apropriado.
3. Seleção do endpoint: Quando a rota correspondente tem como alvo um InferencePool, o Application Gateway for Containers invoca o EPP, que avalia a telemetria do servidor de pedido e modelo e devolve o endpoint selecionado.
4. Rotear para o InferencePool: O Application Gateway for Containers encaminha o pedido para o pod do servidor modelo selecionado, e a resposta do servidor modelo retorna ao cliente através do gateway.

Capacidades de encaminhamento

O gateway de inferência suporta estes padrões de encaminhamento para cargas de trabalho de IA auto-hospedadas. A seleção de endpoint é executada no EPP, pelo que os comportamentos sensíveis à carga e à cache dependem dos plug-ins de pontuação que o seu EPP tem ativados.

• Roteamento consciente do modelo: Encaminha pedidos com base no nome do modelo em corpos de requerimento compatíveis com OpenAI, que o processador BBR gerido extrai.
• Divisão de tráfego e implementações graduais: Utilize o HTTPRoute balanceamento ponderado backendRefs padrão para dividir o tráfego por vários InferencePool backends para implementações de modelos do tipo canário ou azul-verde.
• Seleção de endpoints em função da carga e da cache: O EPP atribui pontuações aos endpoints com base na telemetria do servidor do modelo, como a profundidade da fila e a utilização da cache KV. Quando o EPP ativa a pontuação com reconhecimento da cache de prefixos, os pedidos que partilham o mesmo prefixo do prompt são encaminhados para a mesma réplica, para aumentar os acertos na cache e reduzir o TTFT.
• Prioridade de pedidos e proteção contra sobrecarga: Use InferenceObjective recursos e o x-gateway-inference-objective cabeçalho do pedido para atribuir prioridade de serviço. Quando os servidores de modelo estão saturados, o EPP descarta primeiro as requisições de menor prioridade para proteger o tráfego sensível à latência.
• Seleção resiliente de endpoint: Configure o comportamento de falha do EPP com FailOpen ou FailClose, dependendo se a disponibilidade ou a seleção rigorosa de endpoint é mais importante para um pool.
• Compatibilidade com a API do Gateway: Continue a utilizar as condições de estado da API Gateway, HTTPRoute, ReferenceGrant e o padrão da API do Gateway para a configuração de entrada.

Inferência segura

Mantenha os servidores modelo privados atrás do gateway gerido e aplique as capacidades de segurança da plataforma para inferir o tráfego.

• Firewall de aplicações web (WAF): O gateway de inferência emparelha-se nativamente com a capacidade WAF existente no Application Gateway for Containers, aplicando proteções alinhadas com OWASP ao tráfego de IA antes que os pedidos cheguem aos seus servidores modelo.
• Proteção para backends dispendiosos: Como a política é aplicada na edge gerida, pedidos mal formados ou abusivos podem ser inspecionados e bloqueados antes de consumirem a escassa capacidade da GPU.

Cenários de exemplo

Os cenários seguintes mostram formas comuns de usar o gateway de inferência:

• Disponibilizar e implementar versões do modelo: Encaminhe pedidos compatíveis com OpenAI para um InferencePool por nome do modelo e, em seguida, utilize HTTPRoute backendRefs ponderadas para desviar uma percentagem do tráfego para uma nova versão do modelo, para testes de canário, antes de concluir a implementação progressiva.
• Dê prioridade ao tráfego sensível à latência: Defina InferenceObjective recursos para cargas de trabalho de alta e baixa prioridade num conjunto partilhado. Pedidos de chat interativos têm o objetivo de alta prioridade, enquanto os trabalhos em lote usam uma prioridade mais baixa que é eliminada primeiro quando o pool está saturado.

InferencePool comparado com Serviço

Um Kubernetes Service continua a ser a abstração backend correta para tráfego padrão de aplicações. Use um InferencePool quando o backend é um grupo de pods de servidor modelo que precisam de seleção de endpoint específica para inferência.

InferencePool inclui um seletor de pod, informações sobre a porta de destino e uma referência ao seletor de endpoint. O EPP é responsável por selecionar o endpoint para um pedido. Um único EPP está associado a um único agrupamento.

Comportamento em caso de falha

O encaminhamento de inferência é um comportamento em tempo de pedido, pelo que o modo de falha do seletor de endpoint é importante.

InferencePool As referências do seletor de endpoint suportam os seguintes modos de falha:

• FailOpen: Se o EPP não estiver disponível ou não responder, o gateway pode continuar com a seleção padrão de endpoint no pool. Esta escolha preserva a disponibilidade, mas pode reduzir a qualidade do encaminhamento.
• FailClose: Se o EPP não estiver disponível ou não responder, o gateway rejeita o pedido. Esta escolha impede que o tráfego seja enviado sem a decisão necessária de seleção do endpoint.

Para o encaminhamento sensível ao modelo que depende da análise do corpo do pedido, o Application Gateway for Containers privilegia a correção. Se não for possível extrair o nome do modelo para uma rota que requer BBR, o pedido é rejeitado em vez de ser silenciosamente encaminhado para o backend do modelo incorreto.

Considerações operacionais

Planeie as seguintes considerações ao executar cargas de trabalho de inferência atrás do Application Gateway for Containers:

• Capacidade do EPP: O EPP está no caminho das solicitações para os sistemas de InferencePool back-end. Dimensione e monitorize como um componente crítico da aplicação.
• Telemetria de servidores modelo: O EPP necessita de métricas de servidores modelo frescas para tomar decisões de roteamento de alta qualidade. Confirme que o seu servidor modelo suporta as métricas esperadas pela configuração do seu EPP.
• Capacidade da GPU e agendamento: Os pods do servidor de modelos requerem frequentemente conjuntos de nós com GPU, plug-ins de dispositivos e credenciais para transferência de modelos.
• Escalonamento automático: Escalone os pods do servidor do modelo com base em sinais de inferência, como a profundidade da fila e a utilização da cache KV, utilizando o Horizontal Pod Autoscaler ou o KEDA. O dimensionamento automático aumenta a capacidade à medida que a procura aumenta, enquanto o EPP encaminha os pedidos de modo a contornar réplicas já saturadas.
• Respostas em streaming: Muitas cargas de trabalho de conclusão de chat usam eventos enviados pelo servidor. Valide o comportamento do streaming ao testar as definições de latência e timeout de ponta a ponta.
• Observabilidade: Monitorizar o estado do Gateway e do HTTPRoute, o estado do InferencePool, a saúde do EPP, o estado de prontidão do servidor do modelo e métricas do servidor do modelo, tais como pedidos ativos e comprimento da fila.

Limitações

O gateway de inferência centra-se em cargas de trabalho de inferência autoalojadas executadas no Kubernetes. O encaminhamento direto para pontos de extremidade públicos ou geridos do fornecedor de modelos está fora do âmbito desta integração.

A Extensão de Inferência da API do Gateway evolui independentemente do Application Gateway for Containers. Use versões e manifestos da API que correspondam aos CRDs de extensão de inferência instalados no seu cluster.

Passos seguintes

• Configurar o Gateway de Aplicação para o gateway de inferência de containers
• Componentes do Gateway de Aplicação para Contentores
• Documentação da Extensão de Inferência da API Gateway