Il bilanciamento del carico AI di F5 raggiunge 3,24x in laboratorio, ma solo sotto pressione estrema
Secondo quanto riportato, il bilanciamento del carico AI di F5 ha completato 3,24 volte più lavoro di un gateway basato su Envoy durante il test più impegnativo di una visita a un laboratorio sponsorizzata da F5. Il risultato è stato ottenuto con BIG-IP Next for Kubernetes in esecuzione su data processing unit, o DPU, NVIDIA BlueField-3. Tuttavia, il carico di lavoro più leggero ha mostrato una differenza molto minore. Questo contrasto conta più del numero in primo piano.
Il test ha utilizzato server Supermicro dotati di otto GPU NVIDIA H100 ciascuno. Ogni GPU serviva il modello Qwen3-32B usando precisione numerica FP8. BIG-IP Next for Kubernetes gestiva il traffico tramite le DPU, mentre il gateway di confronto operava sui processori host.
Non si è trattato di un verdetto generale su ogni gateway Kubernetes o cluster di inferenza. Era un confronto specifico in condizioni controllate, riportato da ServeTheHome dopo una visita sponsorizzata. Resta comunque evidente una competizione sempre più importante: instradamento del traffico basato sulle condizioni live delle GPU rispetto a un instradamento che rimane in gran parte scollegato dallo stato degli acceleratori.
La domanda centrale non è più se un cluster possieda abbastanza GPU. È se il suo software possa mantenere produttivi quegli acceleratori costosi quando le richieste diventano lunghe, concorrenti e difficili da collocare.
Il test di F5 BIG-IP Next for Kubernetes ha messo l'instradamento sotto stress
Il vantaggio riportato è emerso quando la cache chiave-valore del cluster è diventata sovrassegnata, non durante il baseline più semplice.
Il test di laboratorio ha confrontato due percorsi che servivano lo stesso modello Qwen3-32B. I componenti Control ed Endpoint Picker di F5 operavano su DPU BlueField-3. L'alternativa utilizzava Envoy AI Gateway, nel frattempo rinominato Agent Router, sull'host.
Il test ha monitorato la latenza P90 in esecuzioni di 60 minuti. NVIDIA AI Perf Tool ha generato richieste con diversi livelli di concorrenza e lunghezze dei prompt. Quattro modelli di traffico coprivano richieste senza prefisso condiviso, conversazioni multi-turno, traffico misto e un intenso riutilizzo dei prefissi.
Il baseline combinava 150 richieste concorrenti con 10.000 token di input per richiesta. ServeTheHome ha riportato che i due gateway hanno ottenuto risultati relativamente vicini in quel caso. Il cluster utilizzava il 46 percento della capacità disponibile della propria cache chiave-valore.
Una cache chiave-valore, generalmente abbreviata in cache KV, memorizza dati di attenzione che un modello può riutilizzare durante la generazione dei token. Migliora la velocità di inferenza, ma consuma una quantità significativa di memoria GPU. Prompt lunghi e molti utenti simultanei possono spingere questa risorsa di memoria oltre limiti confortevoli.
Il test più impegnativo ha aumentato la concorrenza da 150 a 200, un incremento del 33 percento. Ha inoltre raddoppiato la lunghezza dell'input di ogni richiesta a 20.000 token. Il carico di lavoro risultante richiedeva 1,24 volte la capacità KV cache disponibile del cluster.
Questa sovrassegnazione ha cambiato il risultato. ServeTheHome ha riportato un incremento di 3,24x per il percorso F5 perché distribuiva più efficacemente il carico di lavoro difficile. I grafici pubblicati hanno esaminato anche le richieste completate, i token di output al secondo e il tempo al primo token.
La cifra di 3,24x va quindi letta come un risultato ottenuto sotto alta pressione. Non significa che ogni cluster elaborerà 3,24 volte più traffico dopo l'installazione del software F5. Lo stesso rapporto definisce quel numero un estremo nell'ambito della configurazione testata.
Questa precisazione non rende il test irrilevante. I sistemi di inferenza in produzione devono sostenere picchi, contesti lunghi e carichi non uniformi sugli acceleratori. Un gateway che si comporta in modo simile a basso utilizzo può diventare molto più prezioso vicino alla saturazione.
Il cambiamento importante è architetturale. Il bilanciamento del carico si è avvicinato allo stato del model serving, inclusi profondità delle code, utilizzo delle GPU e pressione della cache. Il gateway non prende più decisioni basandosi soltanto sulle connessioni di rete.
F5 definisce BIG-IP Next for Kubernetes, o BNK, un AI service plane. Si colloca tra i client e l'infrastruttura GPU, combinando gestione del traffico, sicurezza, instradamento e controlli di utilizzo. Il prodotto può operare su processori host o su DPU BlueField-3 supportate.
Collocarlo su una DPU sposta le attività di rete e sicurezza lontano dai processori principali del server. La DPU è un processore infrastrutturale programmabile progettato per gestire attività di rete, storage e sicurezza. Questo lascia le risorse host disponibili per il model serving e le operazioni del cluster.
Il test ha quindi misurato due idee collegate. Una era la qualità dell'instradamento sotto pressione della memoria GPU. L'altra era lo spostamento del lavoro infrastrutturale su hardware progettato per elaborarlo al di fuori dell'host.
Perché il bilanciamento del carico AI di F5 migliora sotto forte domanda
Il meccanismo di F5 dipende dalla visibilità sulle condizioni degli acceleratori che le metriche di rete convenzionali non possono descrivere.
I bilanciatori del carico tradizionali possono distribuire il traffico tramite round-robin, conteggi delle connessioni o priorità fisse. Questi metodi funzionano bene quando i server backend hanno capacità prevedibili. L'inferenza dei large language model infrange questa premessa.
Una richiesta può contenere una domanda breve. Un'altra può includere 20.000 token di documenti e cronologia della conversazione. Una terza potrebbe riutilizzare un prefisso già memorizzato nella cache KV di una GPU.
Queste richieste possono produrre tempi di elaborazione diversi anche quando raggiungono GPU identiche. Anche le code cambiano rapidamente mentre i modelli raggruppano richieste, allocano memoria e trasmettono token generati in streaming. Un endpoint di rete in buono stato può comunque essere una destinazione scadente per il prompt successivo.
La documentazione sul bilanciamento del carico di F5 descrive un componente Analyzer che osserva la telemetria della GPU e del model serving. Raccomanda nuovi pesi di traffico per ogni backend. Il Traffic Management Microkernel di F5 applica poi tali pesi nel data plane.
Gli input documentati includono latenza di inferenza, profondità delle code, consumo di memoria GPU, stato termico e tassi di errore. F5 supporta inoltre la telemetria di NVIDIA Inference Microservices, NVIDIA Data Center GPU Manager e vLLM.
Questo ciclo di feedback spiega perché il divario possa ampliarsi sotto pressione. Una policy statica non ha una visione diretta di quale GPU si stia avvicinando a un limite di memoria. Un controller consapevole della telemetria può ridurre il traffico verso un endpoint in difficoltà prima che la sua coda diventi il collo di bottiglia del cluster.
F5 descrive inoltre l'instradamento come consapevole dei prefissi e della cache KV. La consapevolezza dei prefissi cerca di inviare prompt correlati verso un backend che detiene già un contesto riutilizzabile. Evitare la ricostruzione non necessaria della cache può ridurre il lavoro computazionale e il ricambio della memoria.
La consapevolezza del carico ha uno scopo diverso. Distribuisce le richieste in base alla capacità disponibile invece di presumere che ogni endpoint sia ugualmente pronto. Il risultato più forte dovrebbe apparire quando tali presupposti divergono, esattamente ciò che ha creato il carico di lavoro sovrassegnato del laboratorio.
Il software non rende le GPU H100 intrinsecamente più veloci. Cerca di sprecare meno del loro tempo di elaborazione disponibile. Questa distinzione è essenziale quando si valutano affermazioni sulle prestazioni delle GPU.
Una migliore pianificazione può aumentare il throughput totale del cluster senza modificare i pesi del modello o il silicio dell'acceleratore. Può anche ridurre il numero di richieste bloccate dietro prompt insolitamente costosi. Tuttavia, il vantaggio dipende dalla diversità del carico di lavoro e dalla qualità della telemetria.
Un batch uniforme con prompt brevi offre meno opportunità di instradamento. Un flusso altamente variabile crea più occasioni perché il posizionamento intelligente faccia la differenza. I risultati di laboratorio hanno seguito questo schema, con differenze minori in condizioni più leggere.
La documentazione pubblica di F5 cita miglioramenti del throughput dal 30 al 40 percento rispetto all'instradamento round-robin. Separatamente, F5 ha affermato che test convalidati da The Tolly Group hanno prodotto un throughput di token fino al 40 percento superiore. Lo stesso annuncio ha dichiarato un tempo al primo token più rapido del 61 percento e una latenza complessiva delle richieste inferiore del 34 percento.
Queste cifre sono più contenute di 3,24x perché descrivono test diversi. Rimangono inoltre affermazioni sulle prestazioni pubblicate dal fornitore, anche quando le misurazioni sono state condotte da un'organizzazione esterna. Gli acquirenti dovrebbero esaminare le configurazioni sottostanti prima di confrontare le percentuali.
Il sistema F5 può posizionarsi davanti a router di modelli esterni come LiteLLM, RouteLLM e NVIDIA Router. Può inviare una richiesta attraverso un livello di selezione del modello prima di indirizzarla verso un indirizzo virtuale per il backend scelto.
Ciò significa che BNK non sostituisce necessariamente ogni componente di instradamento. Può diventare il livello di traffico e policy che li circonda. Questa posizione più ampia consente a F5 di collegare il posizionamento delle GPU con sicurezza, misurazione dell'utilizzo e applicazione delle regole di rete.
L'architettura conta perché i gateway di inferenza stanno diventando punti di controllo per risorse scarse. Possono decidere quale modello gestisca una richiesta, quale utente riceva capacità e quando il traffico debba essere rallentato. Una decisione errata spreca più della sola larghezza di banda di rete.
La vera competizione è tra instradamento consapevole delle GPU e backend opachi
La pressione ricade sui gateway che trattano ogni endpoint di inferenza disponibile come un server intercambiabile.
Il principale avversario di F5 non è una singola azienda. È un modello più vecchio di gestione del traffico che vede le connessioni, ma non le condizioni interne di ogni acceleratore. Il laboratorio ha utilizzato Envoy AI Gateway come confronto rappresentativo.
Il progetto Agent Router, associato al panorama cloud-native in evoluzione, riflette una spinta più ampia verso l'instradamento AI specializzato. La nomenclatura e il panorama dei progetti continuano a cambiare, complicando i semplici confronti tra prodotti.
Envoy stesso rimane una base proxy ampiamente utilizzata. Il test F5 non stabilisce che Envoy non possa supportare un instradamento di inferenza più intelligente. Confronta implementazioni, posizionamenti, policy e configurazioni specifiche.
La differenziazione di F5 combina più livelli. Il suo Endpoint Picker utilizza telemetria live per la selezione del backend. L'implementazione su DPU colloca l'elaborazione del traffico al di fuori dell'host. La sua piattaforma più ampia aggiunge controlli per sicurezza, isolamento dei tenant e consumo di token.
Lo spostamento di queste funzioni su BlueField-3 crea un secondo asse competitivo. Un gateway basato sull'host consuma cicli CPU e larghezza di banda della memoria sul server. Un gateway basato su DPU utilizza un processore dedicato restando fisicamente vicino al carico di lavoro.
La guida alle AI factory di NVIDIA elenca l'integrazione di F5 come un'opzione per delegare proxy, bilanciamento del carico, crittografia, firewalling e protezione API. La stessa guida identifica integrazioni di fornitori di sicurezza tra cui Fortinet e Palo Alto Networks.
Questo contesto mostra perché il mercato non si ridurrà a F5 contro Envoy. I fornitori di infrastruttura competono per collocare l'intelligenza di sicurezza e traffico all'interno del livello DPU. Anche i progetti open source stanno aggiungendo funzionalità di instradamento consapevoli dei modelli.
La decisione pratica riguarda la proprietà. Alcuni operatori desiderano un service plane commerciale con supporto e policy integrati. Altri preferiscono componenti open source componibili che i loro team di piattaforma possano ispezionare, modificare e gestire.
L'integrazione commerciale può ridurre il lavoro necessario per collegare telemetria, instradamento, rete e sicurezza. Può anche approfondire la dipendenza dal control plane di un particolare fornitore e dalla sua matrice hardware supportata. Questo compromesso diventa significativo nelle flotte di grandi dimensioni.
I componenti aperti possono offrire flessibilità e portabilità. Richiedono però ai team di ingegneria di assemblare osservabilità, applicazione delle policy, logica di routing e gestione del ciclo di vita. Il costo di questo lavoro raramente emerge in un semplice grafico del throughput.
La posizione di F5 è più solida dove flotte di GPU servono molti tenant con carichi di lavoro disomogenei. L’infrastruttura condivisa aumenta la necessità di isolamento, limiti di frequenza, contabilizzazione dell’utilizzo e livelli di servizio prevedibili. Inoltre, rende più costoso un posizionamento inefficiente delle richieste.
La sua posizione è meno evidente per cluster piccoli o poco caricati. Se gli endpoint raramente si avvicinano ai propri limiti, un routing statico o più semplice può restare adeguato. L’infrastruttura aggiuntiva deve giustificare il proprio impatto operativo.
F5 afferma che non sono richieste modifiche ai modelli per il suo routing e l’offload su DPU. Questo riduce una barriera all’adozione, poiché i team possono mantenere i server dei modelli esistenti. Tuttavia, il deployment continua a comportare nuovi componenti infrastrutturali, pipeline di telemetria, policy e modalità di guasto.
La documentazione dell’azienda afferma che il bilanciamento del carico AI è disabilitato per impostazione predefinita. Gli operatori devono configurare la funzione e il relativo percorso dati. Devono inoltre disporre di Prometheus e di telemetria compatibile quando utilizzano l’analizzatore integrato.
Nella documentazione attuale, solo le metriche GPU NVIDIA dispongono del supporto integrato tramite plugin. Le organizzazioni che usano altri acceleratori potrebbero necessitare di logica personalizzata. Anche gli ambienti NVIDIA possono variare per server dei modelli, configurazioni di rete e pratiche di orchestrazione.
Anche i requisiti hardware sono specifici. I requisiti DPU di F5 identificano hardware BlueField-3 supportato, memoria minima, interfacce di rete doppie e componenti software richiesti.
Gli stessi requisiti stabiliscono che la DPU deve essere dedicata a BNK. Avvertono che altro software DPU può creare problemi di prestazioni o instabilità di Kubernetes. In tale configurazione documentata, per BNK è supportata una sola DPU per chassis.
Questi vincoli fanno sì che la decisione d’acquisto vada oltre un benchmark del gateway. I team devono decidere come allocare le DPU, gestire il firmware, integrare la rete e ripristinare i componenti guasti. Devono confrontare questo lavoro con la capacità host risparmiata.
Cosa non dimostra l’affermazione di prestazioni pari a 3,24x
Il risultato di laboratorio è un utile segnale di stress, ma non è una prova indipendente di un vantaggio universale in produzione.
ServeTheHome ha dichiarato esplicitamente che F5 ha sponsorizzato la visita al laboratorio californiano. Questa trasparenza aiuta i lettori a interpretare il rapporto, ma non elimina la necessità di una riproduzione indipendente.
L’hardware, il modello, la precisione, le dimensioni dei prompt e gli schemi delle richieste erano strettamente definiti. Ognuna di queste variabili può modificare il comportamento del routing. Un modello o un motore di serving differente potrebbe gestire diversamente la pressione sulla cache.
Il risultato più forte è emerso nella condizione con concorrenza pari a 200 e 20.000 token. Quel carico di lavoro richiedeva 1,24 volte la cache KV disponibile. Ha deliberatamente spinto il cluster oltre una confortevole soglia delle risorse.
Un sovraccarico di questo tipo è utile per mettere in luce il comportamento dello scheduler. Può anche amplificare la differenziazione di un prodotto nel suo caso migliore. Gli acquirenti hanno bisogno di risultati in condizioni di utilizzo normale, utilizzo di picco e sovraccarico sostenuto.
Il confronto ha inoltre combinato la posizione del routing con l’intelligenza di routing. F5 operava su una DPU, mentre l’alternativa operava sull’host. Pertanto, il test non isola il contributo alle prestazioni di ciascuna scelta progettuale.
Una valutazione più rivelatrice confronterebbe diverse configurazioni. F5 potrebbe operare su host e DPU con la stessa policy. I gateway concorrenti potrebbero essere eseguiti sia con routing statico sia con routing basato sulla telemetria. Il cluster potrebbe così mostrare separatamente il contributo dell’offload e della pianificazione.
L’articolo pubblico offre molti grafici, ma non tutti i log grezzi o i dettagli di configurazione necessari per la riproduzione. Menziona che l’intelligenza artificiale ha aiutato a trasformare i log in visualizzazioni. Questa scelta di presentazione aumenta l’importanza di pubblicare risultati leggibili dalle macchine.
L’annuncio sulle prestazioni di F5 del marzo 2026 offre un ulteriore elemento di prova. Riporta incrementi inferiori derivati da test separati e attribuisce la validazione a The Tolly Group.
Test multipli che mostrano la stessa direzione rafforzano la plausibilità del meccanismo. Non rendono però le percentuali intercambiabili. Basi di riferimento, carichi di lavoro e metriche di successo differenti possono produrre miglioramenti di primo piano molto diversi.
Richieste completate, throughput dei token e latenza rispondono ciascuno a una domanda diversa. Un sistema può produrre più token complessivi offrendo al contempo ad alcuni utenti risposte iniziali più lente. Può ridurre la latenza media lasciando instabile la latenza di coda.
Il laboratorio ha esaminato il tempo medio e P99 al primo token insieme al throughput. Gli acquirenti in produzione dovrebbero studiare anche richieste fallite, tassi di retry, qualità delle risposte ed equità tra tenant. Queste misure rivelano se il throughput superiore derivi da una prioritizzazione indesiderabile.
Le ottimizzazioni del serving dei modelli possono influire anche sulla coerenza dell’output. Instradare un prompt verso un modello più piccolo può ridurre l’uso delle risorse, ma modificare la qualità. F5 descrive il routing basato su policy tra modelli più grandi e più piccoli, sebbene questa funzione non fosse il nucleo del confronto.
Le funzioni di sicurezza creano un ulteriore problema di misurazione. Un gateway che gestisce crittografia, regole firewall, controlli sui token e ispezione svolge più lavoro di un router minimale. I confronti equi devono allineare le funzionalità abilitate o spiegarne il valore operativo.
L’offload su DPU può preservare risorse host, ma queste DPU non sono capacità gratuita. Consumano energia, richiedono gestione e occupano una parte dell’architettura del server. La misura economica rilevante è l’output totale del cluster rispetto al costo totale dell’infrastruttura.
Anche le affermazioni dei fornitori sul “liberare cicli GPU” richiedono un linguaggio prudente. I servizi di rete spesso competono direttamente per le risorse CPU dell’host, anziché essere eseguiti sulla GPU stessa. Un routing migliore può aumentare l’utilizzo delle GPU, ma la DPU non crea nuovi core acceleratori.
Il risultato di 3,24x è più credibile come prova di un vantaggio nella gestione dei colli di bottiglia in uno scenario estremo. Non dovrebbe diventare un moltiplicatore generalizzato nei piani di capacità. Persino ServeTheHome lo ha descritto come vicino all’estremità superiore dei benefici osservati.
Il rapporto ha offerto un esempio più modesto: un miglioramento di 1,25x somiglia a ricevere l’output di cinque GPU partendo da una base di quattro GPU. Questa analogia comunica la rilevanza economica, ma i guadagni in produzione dipenderanno da ciascun cluster.
I team dovrebbero ricreare la propria distribuzione della lunghezza dei prompt, curva di concorrenza, riutilizzo della cache, mix di modelli e obiettivi di servizio. Dovrebbero quindi confrontare configurazioni coerenti su esecuzioni prolungate. Brevi dimostrazioni non possono cogliere ogni guasto operativo.
Un pilota credibile dovrebbe includere interruzioni della telemetria e metriche obsolete. Se il controller di routing perde visibilità sulle condizioni delle GPU, gli operatori devono sapere quanto rapidamente rileva il problema. Hanno inoltre bisogno di una policy di fallback prevedibile.
Il test dovrebbe coprire il guasto della DPU, l’interruzione del control plane e la partizione della rete. Dovrebbe mostrare se le richieste attive sopravvivono e se il nuovo traffico viene spostato in sicurezza. Le prestazioni durante un funzionamento perfetto rappresentano solo una parte della preparazione alla produzione.
Tre segnali indicheranno se il vantaggio di laboratorio si trasferisce
Il prossimo banco di prova è capire se F5 può trasformare un convincente risultato di sovraccarico in guadagni ripetibili nei normali carichi di lavoro di produzione.
Il primo segnale è la riproduzione indipendente dei carichi di lavoro. Gli acquirenti necessitano di test che pubblichino dati grezzi e configurazioni complete su diversi modelli, framework di serving e distribuzioni dei prompt. I risultati dovrebbero separare l’offload su DPU dalla pianificazione guidata dalla telemetria.
Miglioramenti coerenti con un carico moderato rafforzerebbero il caso di F5. Benefici che emergono solo durante una deliberata sovra-allocazione della cache restringerebbero il caso d’uso indirizzabile. Entrambi gli esiti fornirebbero comunque informazioni utili per la pianificazione della capacità.
Il secondo segnale è una più ampia evidenza di deployment. F5 e NVIDIA descrivono imprese e fornitori di servizi GPU come utenti target, ma esempi nominativi in produzione renderebbero più chiaro il modello operativo. I casi utili dovrebbero spiegare dimensione del cluster, variazione del traffico e modalità di guasto osservate.
Le evidenze di produzione dovrebbero anche mostrare se i team mantengono i promessi guadagni di capacità dopo l’abilitazione dei controlli di sicurezza completi. Governance dei token, crittografia, isolamento dei tenant e auditing aggiungono tutti lavoro. Il loro impatto combinato conta più di un benchmark ridotto all’essenziale.
Il terzo segnale è la risposta dei progetti open gateway e di inference routing. Se tali progetti aggiungeranno telemetria GPU comparabile, consapevolezza dei prefissi e posizionamento attento alla cache, il vantaggio di routing di F5 potrebbe diventare una funzionalità standard.
Questo esito sposterebbe la concorrenza verso integrazione operativa, supporto DPU, policy di sicurezza e servizio del fornitore. Andrebbe inoltre a vantaggio degli utenti rendendo la gestione del traffico consapevole dell’AI disponibile attraverso più modelli di deployment.
F5 conserva una posizione significativa perché combina già questi livelli. La sua panoramica della piattaforma presenta BNK come gestione unificata del traffico Kubernetes tra distribuzione applicativa, sicurezza e policy. L’opzione DPU estende questo modello all’infrastruttura AI.
Tuttavia, l’ampiezza della piattaforma non elimina l’onere della prova. Gli operatori dei cluster dovrebbero richiedere misurazioni specifiche per il carico di lavoro prima di riprogettare i propri piani di ingresso e di servizio. Dovrebbero misurare il costo per richiesta completata, non solo il picco di token al secondo.
Per gli sviluppatori, questa evoluzione ricorda che il solo codice del modello non determina più le prestazioni dell’inferenza. Posizionamento delle richieste, località della cache, gestione delle code e isolamento dell’infrastruttura possono modificare in modo sostanziale la quantità di lavoro completata da GPU identiche.
Per gli acquirenti aziendali, la storia riguarda l’utilizzo prima dell’espansione. Un livello di controllo più intelligente può essere più pratico dell’acquisizione di acceleratori aggiuntivi quando energia, capacità nei rack o tempistiche di consegna limitano la crescita.
Il risultato di F5 nel bilanciamento del carico AI presenta il suo argomento più forte nel momento peggiore del cluster. È prezioso perché la pressione di picco determina spesso gli acquisti di capacità e l’esperienza utente. È anche esattamente il punto in cui una convalida accurata conta di più.
Prima di adottare il dato di 3,24x, riproducete le condizioni che lo hanno generato. Confrontate traffico ordinario, picchi sostenuti e ripristino dopo i guasti usando i vostri modelli e le vostre policy. Poi ponetevi la domanda decisiva: un routing più intelligente rimanda il prossimo acquisto hardware senza aggiungere più rischio operativo di quanto ne elimini?
