Inferência distribuída: 50 data centers, um único serviço

Praful BhaidasnaVice-presidente de Produto - F5 BIG-IP Next for Kubernetes | F5

Peça a um arquiteto de telecomunicações para desenhar um cluster de IA e ele mostrará racks, GPUs, a malha de interconexão, o armazenamento — tudo. Peça que desenhe como uma solicitação chega a esse cluster e a caneta para. O tráfego simplesmente chega. Ele aparece à porta, e o cluster assume dali em diante.

Esse ponto cego está prestes a sair caro. Para a inferência distribuída, essa lacuna pode significar GPUs ociosas em um local e filas sobrecarregadas em outro. Um provedor de serviços com 50 instalações espalhadas por um país dispõe de algo que um hyperscaler com apenas duas não pode comprar: proximidade dos usuários, diversidade de fontes de energia, presença soberana e fibra óptica já instalada.

Esse é o argumento mais convincente a favor da inferência distribuída: disponibilizar modelos a partir de uma rede de locais, em vez de apenas um. Mas 50 locais só se tornam um único serviço de inferência se algo decidir, para cada solicitação, qual deles deve atendê-la. Hoje, nada faz isso. É essa lacuna que a F5 está eliminando com a NVIDIA, a AMD e outros fornecedores de infraestrutura de IA, para que a decisão seja baseada na telemetria dos aceleradores e das pilhas de inferência que os provedores de serviços realmente implantam.

O tráfego não chega por mágica

Veja o que realmente acontece. Uma consulta DNS seleciona um site. Um balanceador de carga global de servidores avalia a proximidade, a integridade e a capacidade e retorna um endereço. Dentro do site, um proxy encerra a conexão, verifica quem está fazendo a solicitação, aplica a política e um balanceador de carga seleciona um servidor. Essa cadeia é chamada de roteamento com reconhecimento de aplicações. Há duas décadas, ela sustenta discretamente todos os serviços web e móveis, e a F5 foi responsável por grande parte de sua criação.

A cadeia ainda funciona para IA. Ela apenas toma suas decisões com base nos critérios errados. O balanceador de carga global de servidores (GSLB) sabe qual site está mais próximo e qual está disponível. Ele não sabe qual site tem o modelo carregado, se as GPUs desse site estão saturadas ou se esta solicitação é uma interação por voz que não pode atravessar o país ou uma tarefa agêntica longa que pode ser direcionada para onde a capacidade for mais barata. Por isso, ele escolhe o site disponível mais próximo, que pode estar operando no limite enquanto um cluster idêntico, a 200 quilômetros de distância, permanece com metade da capacidade ociosa.

Do roteamento com reconhecimento de aplicações ao roteamento com reconhecimento de IA

O salto é este: o roteamento com reconhecimento de aplicações precisa passar a reconhecer aplicações de IA. Mesma cadeia, mesmo DNS, mesmos proxies. Duas novas entradas.

O primeiro é a telemetria proveniente do interior da infraestrutura de IA. Cada cluster sabe quais modelos está atendendo, o tamanho de suas filas, quanto do cache de KV está em uso, quantas solicitações estão em andamento e quanto tempo uma nova solicitação aguardará até receber seu primeiro token. F5 BIG-IP Next for Kubernetes já está à frente desses clusters e tem visibilidade de tudo isso, até mesmo da contagem de tokens por solicitação. Envie esses dados para a camada superior, e as soluções de DNS da F5 deixam de manter um mapa de onde os sites estão localizados e passam a oferecer uma visão em tempo real do que cada site é capaz de fazer neste exato momento.

As soluções de DNS da F5 combinam a telemetria de inferência em tempo real de cada local com a intenção da solicitação para direcioná-la ao local capaz de atender ao seu SLA naquele momento.

O segundo é a intenção da solicitação. Um roteador com reconhecimento de LLM pode classificar uma solicitação antes de encaminhá-la: de qual modelo ela precisa, qual é sua sensibilidade à latência, aproximadamente quanto trabalho ela representa e por qual nível de SLA o locatário está pagando. Essa intenção passa a ser um dado de entrada para a resposta de DNS, em vez de algo descoberto depois que a solicitação já chegou ao lugar errado.

Combine os dois, e um acordo de nível de serviço (SLA) deixa de ser um parágrafo em um contrato e passa a ser uma regra de roteamento. Um SLA de latência direciona para o site mais próximo que tenha o modelo carregado e capacidade de sobra. Um SLA de custo direciona para a capacidade disponível de menor custo. Um requisito de soberania garante que os dados nunca saiam do país. O GSLB toma a decisão que sempre pôde tomar, agora com as informações que nunca teve.

Três níveis de decisão, uma única resposta

O posicionamento não é uma única decisão, mas três decisões interligadas.

• Globalmente, as soluções de DNS da F5 escolhem o local ou a fábrica de IA, agora com base na telemetria de inferência em tempo real e na intenção da solicitação, além da proximidade, integridade e soberania.
• Regionalmente, a solicitação é direcionada a um cluster com o modelo adequado e capacidade disponível, atravessando um limite de segurança específico do tenant que impõe o isolamento antes que qualquer GPU seja acessada.
• Localmente, dentro do cluster, o BIG-IP Next for Kubernetes aplica políticas de identidade, acesso e tráfego, e o Endpoint Picker escolhe o worker.

É nesse último nível que o roteamento deixa de ser apenas um caminho até a GPU e passa a fazer parte do desempenho da inferência. Quando um mecanismo processa um prompt, a etapa de prefill preenche o cache KV da GPU. Se a próxima solicitação compartilhar esse prefixo e for direcionada a um worker que ainda o mantém em cache, o trabalho será reutilizado. Se for direcionada a qualquer outro worker, a GPU terá de refazê-lo. Com pouca carga, ninguém percebe. Sob a concorrência de um ambiente de produção, o conjunto de trabalho ultrapassa a capacidade do cache, e o direcionamento passa a determinar se o trabalho será reutilizado ou refeito.

Com o BIG-IP Next for Kubernetes 2.4, o Endpoint Picker considera o prefixo em cache, a profundidade da fila, as solicitações em execução, a utilização do cache KV e o tempo estimado até o primeiro token antes de escolher um worker. Ele oferece suporte à desagregação de prefill/decode e a tecnologias abertas de inferência, como llm-d e a Kubernetes Gateway API Inference Extension. O que importa é que os três níveis compartilham contexto. Um site escolhido com base na capacidade não encaminha a solicitação para um cluster sobrecarregado. Um cluster escolhido para um modelo não envia a solicitação a um worker que precise reconstruir seu contexto do zero.

A rede que sabe o que as GPUs sabem

Nada disso exige uma nova plataforma além da infraestrutura de IA. A camada de direcionamento global já existe. A inteligência no nível do cluster também existe e já está em produção com clientes da F5. O trabalho em andamento agora é integrar esses componentes, fazendo com que a telemetria do cluster e a intenção da solicitação alimentem uma única decisão de DNS.

Então, voltemos ao arquiteto com a caneta na mão. Cinquenta data centers são, sim, melhores do que dois para inferência de IA, mas somente se a rede entre eles souber o que as GPUs sabem. Assim, os 50 locais deixam de ser 50 ilhas de capacidade e passam a funcionar como um único serviço de inferência, capaz de cumprir um SLA, respeitar fronteiras e utilizar todas as GPUs já adquiridas.

Considere isto uma prévia. A versão completa, mostrando como tudo foi construído, quais ferramentas foram usadas e o que foi medido, está a caminho.

Saiba mais sobre como a F5 está ajudando organizações a aprimorar a inferência distribuída, o gerenciamento de tráfego de IA e a utilização de GPUs em infraestruturas modernas de IA.

Sobre o autor

Praful BhaidasnaVice-presidente de Produto - F5 BIG-IP Next for Kubernetes | F5

Mais publicações de Praful Bhaidasna