Balanceamento de Carga de IA da F5 Atinge 3,24x em Laboratório, mas Apenas sob Pressão Extrema

O balanceamento de carga de IA da F5 teria entregue 3,24 vezes mais trabalho concluído do que um gateway baseado em Envoy durante o teste mais exigente de uma visita a laboratório patrocinada pela F5. O resultado veio do BIG-IP Next for Kubernetes executado em unidades de processamento de dados NVIDIA BlueField-3, ou DPUs. Ainda assim, a carga de trabalho mais leve mostrou uma diferença muito menor. Esse contraste importa mais do que o número de destaque.

O teste utilizou servidores Supermicro equipados com oito GPUs NVIDIA H100 cada. Cada GPU atendia ao modelo Qwen3-32B com precisão numérica FP8. O BIG-IP Next for Kubernetes gerenciava o tráfego pelas DPUs, enquanto o gateway de comparação rodava nos processadores do host.

Isso não foi um veredito amplo sobre todos os gateways Kubernetes ou clusters de inferência. Foi uma comparação específica sob condições controladas, relatada pela ServeTheHome após uma visita patrocinada. Ainda assim, ela expõe uma disputa cada vez mais importante: roteamento de tráfego baseado nas condições em tempo real das GPUs versus roteamento que permanece em grande parte desconectado do estado dos aceleradores.

A questão central já não é se um cluster possui GPUs suficientes. É se seu software consegue manter esses caros aceleradores produtivos quando as solicitações se tornam longas, simultâneas e difíceis de alocar.

O Teste do F5 BIG-IP Next for Kubernetes Colocou o Roteamento sob Estresse

A vantagem relatada surgiu quando o cache de chave-valor do cluster ficou sobrecarregado, e não durante a linha de base mais fácil.

O teste de laboratório comparou dois caminhos atendendo ao mesmo modelo Qwen3-32B. Os componentes Control e Endpoint Picker da F5 rodavam em DPUs BlueField-3. A alternativa utilizava Envoy AI Gateway, desde então renomeado para Agent Router, no host.

O teste acompanhou a latência P90 em execuções de 60 minutos. A AI Perf Tool da NVIDIA gerou solicitações em diferentes níveis de simultaneidade e comprimentos de prompt. Quatro padrões de tráfego cobriram solicitações sem prefixo compartilhado, conversas de múltiplos turnos, tráfego misto e forte reutilização de prefixos.

A linha de base combinava 150 solicitações simultâneas com 10.000 tokens de entrada por solicitação. A ServeTheHome relatou que os dois gateways tiveram desempenho relativamente próximo nesse caso. O cluster usava 46% de sua capacidade disponível de cache de chave-valor.

Um cache de chave-valor, normalmente abreviado como cache KV, armazena dados de atenção que um modelo pode reutilizar enquanto gera tokens. Ele melhora a velocidade de inferência, mas consome memória substancial da GPU. Prompts longos e muitos usuários simultâneos podem levar esse recurso de memória além de limites confortáveis.

O teste exigente elevou a simultaneidade de 150 para 200, um aumento de 33%. Também dobrou o comprimento de entrada de cada solicitação para 20.000 tokens. A carga de trabalho resultante exigiu 1,24 vezes a capacidade de cache KV disponível no cluster.

Essa sobrecarga mudou o resultado. A ServeTheHome relatou um ganho de 3,24x para o caminho da F5 porque ele distribuiu a carga de trabalho difícil de forma mais eficaz. Seus gráficos publicados também examinaram solicitações concluídas, tokens de saída por segundo e tempo até o primeiro token.

Portanto, o número de 3,24x deve ser interpretado como um resultado sob alta pressão. Isso não significa que todo cluster processará 3,24 vezes mais tráfego após instalar o software da F5. O mesmo relatório chama esse número de um extremo dentro da configuração testada.

Essa ressalva não torna o teste irrelevante. Sistemas de inferência em produção precisam sobreviver a picos, contextos longos e cargas desiguais nos aceleradores. Um gateway que se comporta de forma semelhante com baixa utilização pode se tornar muito mais valioso perto da saturação.

A mudança importante é arquitetural. O balanceamento de carga se aproximou do estado de atendimento do modelo, incluindo profundidade de fila, utilização da GPU e pressão de cache. O gateway já não toma decisões apenas com base em conexões de rede.

A F5 chama o BIG-IP Next for Kubernetes, ou BNK, de plano de serviços de IA. Ele fica entre clientes e a infraestrutura de GPU, combinando gerenciamento de tráfego, segurança, roteamento e controles de uso. O produto pode rodar em processadores do host ou em DPUs BlueField-3 compatíveis.

Colocá-lo em uma DPU desloca tarefas de rede e segurança dos processadores principais do servidor. A DPU é um processador de infraestrutura programável, projetado para lidar com tarefas de rede, armazenamento e segurança. Isso deixa recursos do host disponíveis para o atendimento de modelos e as operações do cluster.

O teste, portanto, mediu duas ideias conectadas. Uma era a qualidade do roteamento sob pressão de memória da GPU. A outra era transferir o trabalho de infraestrutura para hardware projetado para processá-lo fora do host.

Por Que o Balanceamento de Carga de IA da F5 Melhora sob Demanda Elevada

O mecanismo da F5 depende de enxergar condições dos aceleradores que métricas de rede convencionais não conseguem descrever.

Balanceadores de carga tradicionais podem distribuir tráfego por round-robin, contagem de conexões ou prioridades fixas. Esses métodos funcionam bem quando servidores de backend têm capacidade previsível. A inferência de grandes modelos de linguagem viola essa premissa.

Uma solicitação pode conter uma pergunta breve. Outra pode incluir 20.000 tokens de documentos e histórico de conversa. Uma terceira pode reutilizar um prefixo já armazenado no cache KV de uma GPU.

Essas solicitações podem produzir tempos de processamento diferentes mesmo quando chegam a GPUs idênticas. As filas também mudam rapidamente à medida que os modelos agrupam solicitações, alocam memória e transmitem tokens gerados. Um endpoint de rede saudável ainda pode ser um destino ruim para o próximo prompt.

A documentação de balanceamento de carga da F5 descreve um componente Analyzer que monitora a telemetria de GPU e de atendimento de modelos. Ele recomenda novos pesos de tráfego para cada backend. O Traffic Management Microkernel da F5 então aplica esses pesos no plano de dados.

As entradas documentadas incluem latência de inferência, profundidade de fila, consumo de memória da GPU, estado térmico e taxas de erro. A F5 também oferece suporte a telemetria do NVIDIA Inference Microservices, NVIDIA Data Center GPU Manager e vLLM.

Esse ciclo de feedback explica por que a diferença pode aumentar sob pressão. Uma política estática não tem uma visão direta de qual GPU está se aproximando de um limite de memória. Um controlador atento à telemetria pode reduzir o tráfego para um endpoint com dificuldades antes que sua fila se torne o gargalo do cluster.

A F5 também descreve o roteamento como consciente de prefixos e de cache KV. A consciência de prefixos tenta enviar prompts relacionados para um backend que já mantém contexto reutilizável. Evitar a reconstrução desnecessária de cache pode reduzir o trabalho computacional e a rotatividade de memória.

A consciência de carga tem outra finalidade. Ela distribui solicitações de acordo com a capacidade disponível, em vez de presumir que todos os endpoints estão igualmente prontos. O resultado mais forte deve aparecer quando essas premissas divergem, que foi o que a carga de trabalho sobrecarregada do laboratório criou.

O software não torna as GPUs H100 intrinsecamente mais rápidas. Ele tenta desperdiçar menos de seu tempo de processamento disponível. Essa distinção é essencial ao avaliar alegações sobre desempenho de GPU.

Um agendamento melhorado pode aumentar a vazão total do cluster sem alterar os pesos do modelo ou o silício do acelerador. Também pode reduzir o número de solicitações presas atrás de prompts excepcionalmente caros. No entanto, o benefício depende da diversidade da carga de trabalho e da qualidade da telemetria.

Um lote uniforme com prompts curtos oferece menos oportunidades de roteamento. Um fluxo altamente variável cria mais chances para que o posicionamento inteligente faça diferença. Os resultados do laboratório seguiram esse padrão, com diferenças menores em condições mais leves.

A documentação pública da F5 cita melhorias de vazão de 30% a 40% em comparação com roteamento round-robin. Separadamente, a F5 afirmou que testes validados pelo The Tolly Group produziram até 40% mais vazão de tokens. O mesmo anúncio alegou tempo até o primeiro token 61% mais rápido e latência geral de solicitações 34% menor.

Esses números são mais moderados do que 3,24x porque descrevem testes diferentes. Eles também continuam sendo alegações de desempenho publicadas pelo fornecedor, mesmo quando uma organização externa de testes conduziu as medições. Compradores devem examinar as configurações subjacentes antes de comparar percentuais.

O sistema da F5 pode ficar diante de roteadores externos de modelos, como LiteLLM, RouteLLM e NVIDIA Router. Ele pode enviar uma solicitação por uma camada de seleção de modelo antes de direcioná-la a um endereço virtual para o backend escolhido.

Isso significa que o BNK não está necessariamente substituindo todos os componentes de roteamento. Ele pode se tornar a camada de tráfego e políticas ao redor deles. Essa posição mais ampla permite que a F5 conecte a alocação de GPU com segurança, medição e aplicação de políticas de rede.

A arquitetura importa porque gateways de inferência estão se tornando pontos de controle para recursos escassos. Eles podem decidir qual modelo atende uma solicitação, qual usuário recebe capacidade e quando o tráfego precisa ser reduzido. Uma decisão ruim desperdiça mais do que largura de banda de rede.

A Disputa Real É Roteamento Consciente de GPU versus Backends Opacos

A pressão recai sobre gateways que tratam cada endpoint de inferência disponível como um servidor intercambiável.

O principal adversário da F5 não é uma única empresa. É um modelo mais antigo de gerenciamento de tráfego que enxerga conexões, mas não a condição interna de cada acelerador. O laboratório utilizou Envoy AI Gateway como comparação representativa.

O projeto Agent Router, associado ao ecossistema cloud-native em evolução, reflete uma iniciativa mais ampla em direção ao roteamento especializado para IA. A nomenclatura e o cenário de projetos continuam mudando, o que complica comparações simples entre produtos.

O próprio Envoy continua sendo uma base de proxy amplamente utilizada. O teste da F5 não estabelece que o Envoy não possa oferecer suporte a roteamento de inferência mais inteligente. Ele compara implementações, localizações, políticas e configurações específicas.

A diferenciação da F5 combina várias camadas. Seu Endpoint Picker usa telemetria em tempo real para a seleção de backend. A implantação em DPU coloca o processamento de tráfego fora do host. Sua plataforma mais ampla acrescenta controles de segurança, isolamento de tenants e consumo de tokens.

Transferir essas funções para a BlueField-3 cria um segundo eixo competitivo. Um gateway baseado no host consome ciclos de CPU e largura de banda de memória no servidor. Um gateway baseado em DPU utiliza um processador dedicado enquanto permanece fisicamente próximo da carga de trabalho.

O guia de fábrica de IA da NVIDIA lista a integração da F5 como uma opção para descarregar proxies, balanceamento de carga, criptografia, firewall e proteção de API. O mesmo guia identifica integrações de fornecedores de segurança, incluindo Fortinet e Palo Alto Networks.

Esse contexto mostra por que o mercado não se reduzirá a F5 contra Envoy. Fornecedores de infraestrutura estão competindo para posicionar inteligência de segurança e tráfego dentro da camada de DPU. Projetos de código aberto também estão adicionando recursos de roteamento conscientes de modelos.

A decisão prática diz respeito à propriedade. Alguns operadores querem um plano de serviços comercial com suporte e políticas integrados. Outros preferem componentes de código aberto combináveis, que suas equipes de plataforma possam inspecionar, modificar e operar.

A integração comercial pode reduzir o trabalho necessário para conectar telemetria, roteamento, rede e segurança. Ela também pode aprofundar a dependência do plano de controle de um fornecedor específico e de sua matriz de hardware compatível. Essa troca se torna significativa em grandes frotas.

Componentes abertos podem oferecer flexibilidade e portabilidade. Eles também exigem que as equipes de engenharia integrem observabilidade, aplicação de políticas, lógica de roteamento e gestão do ciclo de vida. O custo desse trabalho raramente aparece em um gráfico simples de throughput.

A posição da F5 é mais forte em ambientes nos quais frotas de GPUs atendem muitos locatários com cargas de trabalho irregulares. A infraestrutura compartilhada aumenta a necessidade de isolamento, limites de taxa, contabilização de uso e níveis de serviço previsíveis. Também torna mais caro o posicionamento ineficiente de requisições.

Sua posição é menos evidente para clusters pequenos ou com baixa carga. Se os endpoints raramente se aproximam de seus limites, roteamento estático ou mais simples pode continuar sendo suficiente. A infraestrutura adicional precisa justificar sua pegada operacional.

A F5 afirma que não são necessárias alterações nos modelos para seu roteamento e offload de DPU. Isso reduz uma barreira de adoção, pois as equipes podem manter os servidores de modelos existentes. Ainda assim, a implantação envolve novos componentes de infraestrutura, pipelines de telemetria, políticas e modos de falha.

A documentação da empresa informa que o balanceamento de carga de IA vem desativado por padrão. Os operadores precisam configurar o recurso e seu caminho de dados. Eles também precisam do Prometheus e de telemetria compatível ao usar o analisador integrado.

Apenas métricas de GPU da NVIDIA contam com suporte integrado por plugin na documentação atual. Organizações que usam outros aceleradores podem precisar de lógica personalizada. Mesmo ambientes NVIDIA podem variar conforme os servidores de modelos, os layouts de rede e as práticas de orquestração.

Os requisitos de hardware também são específicos. Os requisitos de DPU da F5 identificam hardware BlueField-3 compatível, memória mínima, interfaces de rede duplas e componentes de software exigidos.

Os mesmos requisitos afirmam que a DPU deve ser dedicada ao BNK. Eles alertam que outro software de DPU pode criar problemas de desempenho ou instabilidade no Kubernetes. Apenas uma DPU por chassi é compatível com o BNK nessa configuração documentada.

Essas restrições transformam a decisão de compra em algo maior do que um benchmark de gateway. As equipes precisam decidir como alocar DPUs, gerenciar firmware, integrar a rede e recuperar componentes que falharam. Elas precisam comparar esse trabalho com a capacidade de host economizada.

O que a alegação de desempenho de 3,24x não comprova

O resultado de laboratório é um sinal útil de estresse, mas não é uma prova independente de uma vantagem universal em produção.

O ServeTheHome divulgou explicitamente que a F5 patrocinou a visita ao laboratório na Califórnia. Essa transparência ajuda os leitores a interpretar o relatório, mas não elimina a necessidade de reprodução independente.

O hardware, o modelo, a precisão, os tamanhos de prompt e os padrões de requisição foram rigidamente definidos. Cada uma dessas variáveis pode alterar o comportamento do roteamento. Um modelo ou mecanismo de serving diferente poderia administrar a pressão sobre o cache de outra forma.

O resultado mais forte surgiu na condição de 200 requisições concorrentes e 20.000 tokens. Essa carga exigiu 1,24 vezes o cache KV disponível. Ela colocou deliberadamente o cluster além de um limite confortável de recursos.

Esse tipo de sobrecarga é valioso para expor o comportamento do agendador. Também pode ampliar a diferenciação de melhor caso de um produto. Os compradores precisam de resultados em utilização normal, utilização de pico e sobrecarga sustentada.

A comparação também combinou o local do roteamento com a inteligência de roteamento. A F5 rodou em uma DPU, enquanto a alternativa rodou no host. Portanto, o teste não isola a contribuição de desempenho de cada escolha de arquitetura.

Uma avaliação mais reveladora compararia várias configurações. A F5 poderia rodar no host e na DPU com a mesma política. Gateways concorrentes poderiam rodar com roteamento estático e roteamento orientado por telemetria. O cluster poderia então revelar separadamente a contribuição do offload e do agendamento.

O artigo público fornece muitos gráficos, mas não todos os logs brutos ou detalhes de configuração necessários para reprodução. Ele menciona que inteligência artificial ajudou a transformar logs em visualizações. Essa escolha de apresentação aumenta a importância de publicar resultados legíveis por máquina.

O anúncio de desempenho da F5, de março de 2026, oferece outro ponto de evidência. Ele relata ganhos menores em testes separados e atribui a validação ao The Tolly Group.

Vários testes que apontam na mesma direção fortalecem a plausibilidade do mecanismo. Eles não tornam as porcentagens intercambiáveis. Linhas de base, cargas de trabalho e métricas de sucesso diferentes podem gerar ganhos de destaque muito distintos.

Requisições concluídas, throughput de tokens e latência respondem, cada um, a uma pergunta diferente. Um sistema pode produzir mais tokens agregados enquanto oferece a alguns usuários respostas iniciais mais lentas. Pode reduzir a latência média enquanto mantém a latência de cauda instável.

O laboratório examinou o tempo médio e P99 até o primeiro token, além do throughput. Compradores em produção também devem estudar requisições que falham, taxas de repetição, qualidade das respostas e equidade entre locatários. Essas medidas revelam se um throughput maior é obtido por meio de priorização indesejável.

Otimizações de serving de modelos também podem influenciar a consistência da saída. Encaminhar um prompt para um modelo menor pode reduzir o uso de recursos, mas alterar a qualidade. A F5 descreve o roteamento baseado em políticas entre modelos maiores e menores, embora essa função não tenha sido o núcleo desta comparação.

Funções de segurança criam outro problema de medição. Um gateway que lida com criptografia, regras de firewall, controles de tokens e inspeção realiza mais trabalho do que um roteador mínimo. Comparações justas precisam alinhar os recursos ativados ou explicar seu valor operacional.

O offload de DPU pode preservar recursos do host, mas essas DPUs não são capacidade gratuita. Elas consomem energia, exigem gerenciamento e ocupam parte da arquitetura do servidor. A medida econômica relevante é a produção total do cluster em relação ao custo total da infraestrutura.

As alegações de fornecedores sobre “liberar ciclos de GPU” também exigem formulação cuidadosa. Serviços de rede geralmente competem diretamente por recursos de CPU do host, em vez de serem executados na própria GPU. Um roteamento melhor pode elevar a utilização da GPU, mas a DPU não cria novos núcleos de acelerador.

O resultado de 3,24x é mais crível como evidência de uma vantagem na gestão de gargalos em um cenário extremo. Ele não deve se tornar um multiplicador genérico nos planos de capacidade. Até mesmo o ServeTheHome o descreveu como próximo ao limite superior dos benefícios observados.

O relatório ofereceu um exemplo mais modesto: uma melhoria de 1,25x se assemelha a receber a produção de cinco GPUs a partir de uma base de quatro GPUs. Essa analogia comunica a dimensão econômica envolvida, mas os ganhos em produção dependerão de cada cluster.

As equipes devem recriar sua própria distribuição de comprimento de prompts, curva de concorrência, reutilização de cache, combinação de modelos e objetivos de serviço. Depois, devem comparar configurações consistentes em execuções longas. Demonstrações curtas não conseguem capturar todas as falhas operacionais.

Um piloto confiável deve incluir interrupções de telemetria e métricas desatualizadas. Se o controlador de roteamento perder a visibilidade das condições das GPUs, os operadores precisam saber com que rapidez ele detecta o problema. Também precisam de uma política de fallback previsível.

O teste deve cobrir falha de DPU, interrupção do plano de controle e particionamento de rede. Deve mostrar se as requisições ativas sobrevivem e se o novo tráfego é movido com segurança. O desempenho durante a operação perfeita representa apenas parte da prontidão para produção.

Três sinais mostrarão se a vantagem de laboratório se confirma na prática

O próximo teste será verificar se a F5 consegue transformar um resultado convincente sob sobrecarga em ganhos repetíveis em cargas de trabalho comuns de produção.

O primeiro sinal é a reprodução independente das cargas de trabalho. Os compradores precisam de testes que publiquem dados brutos e configurações completas em vários modelos, frameworks de serving e distribuições de prompts. Os resultados devem separar o offload de DPU do agendamento orientado por telemetria.

Melhorias consistentes sob carga moderada fortaleceriam o caso da F5. Benefícios que aparecem apenas durante uma sobrescrição deliberada do cache reduziriam o caso de uso endereçável. Ambos os resultados ainda forneceriam informações úteis para o planejamento de capacidade.

O segundo sinal é uma evidência mais ampla de implantação. A F5 e a NVIDIA descrevem empresas e provedores de serviços de GPU como usuários-alvo, mas exemplos nomeados em produção tornariam o modelo operacional mais claro. Relatos úteis devem explicar o tamanho do cluster, a variação de tráfego e os modos de falha observados.

A evidência de produção também deve mostrar se as equipes mantêm os ganhos de capacidade prometidos após ativar controles de segurança completos. Governança de tokens, criptografia, isolamento de locatários e auditoria acrescentam trabalho. Seu impacto combinado importa mais do que um benchmark reduzido.

O terceiro sinal é a resposta de projetos abertos de gateway e roteamento de inferência. Se esses projetos adicionarem telemetria de GPU comparável, consciência de prefixos e posicionamento orientado por cache, a vantagem de roteamento da F5 poderá se tornar uma capacidade padrão.

Esse resultado deslocaria a competição para integração operacional, suporte a DPU, política de segurança e serviço do fornecedor. Também beneficiaria os usuários, ao disponibilizar a gestão de tráfego orientada por IA por meio de mais modelos de implantação.

A F5 mantém uma posição relevante porque já combina essas camadas. Sua visão geral da plataforma apresenta o BNK como uma gestão unificada do tráfego Kubernetes em entrega de aplicações, segurança e política. A opção de DPU estende esse modelo à infraestrutura de IA.

Ainda assim, a amplitude da plataforma não elimina o ônus da prova. Operadores de cluster devem exigir medições específicas para suas cargas de trabalho antes de redesenhar seus planos de entrada e de serviço. Eles devem medir o custo por requisição concluída, e não apenas o pico de tokens por segundo.

Para desenvolvedores, esse avanço lembra que o código do modelo já não determina sozinho o desempenho de inferência. Posicionamento de requisições, localidade de cache, gestão de filas e isolamento de infraestrutura podem alterar materialmente quanto trabalho GPUs idênticas concluem.

Para compradores empresariais, a história trata de utilização antes da expansão. Uma camada de controle mais inteligente pode ser mais prática do que adquirir aceleradores adicionais quando energia, capacidade de rack ou cronogramas de entrega restringem o crescimento.

O resultado de balanceamento de carga de IA da F5 apresenta seu argumento mais forte no pior momento do cluster. Isso é valioso porque a pressão de pico frequentemente determina compras de capacidade e a experiência do usuário. Também é exatamente onde a validação cuidadosa mais importa.

Antes de adotar a cifra de 3,24x, reproduza as condições que a criaram. Compare tráfego comum, picos sustentados e recuperação de falhas usando seus modelos e políticas. Em seguida, faça a pergunta decisiva: um roteamento mais inteligente adia a próxima compra de hardware sem acrescentar mais risco operacional do que remove?