L’équilibrage de charge IA de F5 atteint 3,24x en laboratoire, mais seulement sous pression extrême

L’équilibrage de charge IA de F5 aurait permis d’effectuer 3,24 fois plus de travail qu’une passerelle basée sur Envoy lors du test le plus exigeant d’une visite de laboratoire sponsorisée par F5. Le résultat a été obtenu avec BIG-IP Next for Kubernetes exécuté sur des unités de traitement des données NVIDIA BlueField-3, ou DPU. Pourtant, la charge de travail plus légère n’a montré qu’un écart bien moindre. Ce contraste compte davantage que le chiffre mis en avant.

Le test utilisait des serveurs Supermicro équipés chacun de huit GPU NVIDIA H100. Chaque GPU servait le modèle Qwen3-32B avec une précision numérique FP8. BIG-IP Next for Kubernetes gérait le trafic via les DPU, tandis que la passerelle de comparaison s’exécutait sur les processeurs hôtes.

Il ne s’agissait pas d’un verdict général sur toutes les passerelles Kubernetes ou tous les clusters d’inférence. C’était une comparaison précise, menée dans des conditions contrôlées et rapportée par ServeTheHome après une visite sponsorisée. Elle met néanmoins en lumière une confrontation de plus en plus importante : un routage du trafic fondé sur l’état en temps réel des GPU, face à un routage qui reste largement détaché de l’état des accélérateurs.

La question centrale n’est plus de savoir si un cluster possède suffisamment de GPU. Elle est de savoir si ses logiciels peuvent maintenir ces accélérateurs coûteux à un niveau de productivité élevé lorsque les requêtes deviennent longues, concurrentes et difficiles à placer.

Le test F5 BIG-IP Next for Kubernetes a soumis le routage à rude épreuve

L’avantage rapporté est apparu lorsque le cache clé-valeur du cluster est devenu sursouscrit, et non lors de la référence plus facile.

Le test en laboratoire comparait deux chemins servant le même modèle Qwen3-32B. Les composants Control et Endpoint Picker de F5 s’exécutaient sur des DPU BlueField-3. L’alternative utilisait Envoy AI Gateway, depuis renommé Agent Router, sur l’hôte.

Le test suivait la latence P90 au cours d’exécutions de 60 minutes. NVIDIA AI Perf Tool générait des requêtes selon différents niveaux de concurrence et longueurs de prompts. Quatre schémas de trafic couvraient des requêtes sans préfixe partagé, des conversations à plusieurs tours, du trafic mixte et une forte réutilisation des préfixes.

La référence combinait 150 requêtes concurrentes avec 10 000 tokens d’entrée par requête. ServeTheHome a indiqué que les deux passerelles affichaient des performances relativement proches dans ce cas. Le cluster utilisait 46 % de sa capacité disponible de cache clé-valeur.

Un cache clé-valeur, généralement abrégé en cache KV, stocke des données d’attention qu’un modèle peut réutiliser pendant la génération de tokens. Il accélère l’inférence, mais consomme une part importante de la mémoire GPU. Les prompts longs et un grand nombre d’utilisateurs simultanés peuvent pousser cette ressource mémoire au-delà de limites confortables.

Le test exigeant a porté la concurrence de 150 à 200, soit une hausse de 33 %. Il a également doublé la longueur d’entrée de chaque requête, à 20 000 tokens. La charge de travail résultante nécessitait 1,24 fois la capacité de cache KV disponible du cluster.

Cette sursouscription a modifié le résultat. ServeTheHome a rapporté un gain de 3,24x pour le chemin F5, car celui-ci répartissait plus efficacement la charge de travail difficile. Ses graphiques publiés examinaient également les requêtes terminées, les tokens de sortie par seconde et le délai avant le premier token.

Le chiffre de 3,24x doit donc être lu comme un résultat obtenu sous très forte pression. Il ne signifie pas que chaque cluster traitera 3,24 fois plus de trafic après l’installation de logiciels F5. Le même rapport qualifie ce nombre d’extrême dans le cadre de la configuration testée.

Cette réserve ne rend pas le test sans intérêt. Les systèmes d’inférence de production doivent supporter les pics, les contextes longs et les charges inégales sur les accélérateurs. Une passerelle qui se comporte de façon similaire à faible utilisation peut devenir bien plus précieuse à l’approche de la saturation.

Le changement important est architectural. L’équilibrage de charge s’est rapproché de l’état du service de modèles, notamment de la profondeur des files d’attente, de l’utilisation des GPU et de la pression sur le cache. La passerelle ne prend plus ses décisions à partir des seules connexions réseau.

F5 appelle BIG-IP Next for Kubernetes, ou BNK, un plan de services IA. Il se situe entre les clients et l’infrastructure GPU, tout en combinant gestion du trafic, sécurité, routage et contrôles d’utilisation. Le produit peut fonctionner sur des processeurs hôtes ou sur des DPU BlueField-3 pris en charge.

Son placement sur un DPU déplace les tâches de réseau et de sécurité hors des processeurs principaux du serveur. Le DPU est un processeur d’infrastructure programmable conçu pour traiter les tâches de réseau, de stockage et de sécurité. Les ressources hôtes restent ainsi disponibles pour le service des modèles et les opérations du cluster.

Le test mesurait donc deux idées liées. La première était la qualité du routage sous pression de la mémoire GPU. La seconde consistait à déplacer le travail d’infrastructure vers du matériel conçu pour le traiter hors de l’hôte.

Pourquoi l’équilibrage de charge IA de F5 s’améliore sous forte demande

Le mécanisme de F5 dépend de sa capacité à voir des conditions d’accélérateur que les métriques réseau conventionnelles ne peuvent pas décrire.

Les équilibreurs de charge traditionnels peuvent répartir le trafic par tourniquet, nombre de connexions ou priorités fixes. Ces méthodes fonctionnent bien lorsque les serveurs de backend ont une capacité prévisible. L’inférence des grands modèles de langage contredit cette hypothèse.

Une requête peut contenir une question brève. Une autre peut inclure 20 000 tokens de documents et d’historique de conversation. Une troisième peut réutiliser un préfixe déjà stocké dans le cache KV d’un GPU.

Ces requêtes peuvent produire des temps de traitement différents, même lorsqu’elles atteignent des GPU identiques. Les files d’attente évoluent également rapidement à mesure que les modèles regroupent les requêtes, allouent de la mémoire et diffusent les tokens générés. Un point de terminaison réseau sain peut néanmoins être une mauvaise destination pour le prompt suivant.

La documentation sur l’équilibrage de charge de F5 décrit un composant Analyzer qui surveille la télémétrie des GPU et du service de modèles. Il recommande de nouveaux poids de trafic pour chaque backend. Le Traffic Management Microkernel de F5 applique ensuite ces poids dans le plan de données.

Les entrées documentées comprennent la latence d’inférence, la profondeur des files d’attente, la consommation de mémoire GPU, l’état thermique et les taux d’erreur. F5 prend également en charge la télémétrie de NVIDIA Inference Microservices, NVIDIA Data Center GPU Manager et vLLM.

Cette boucle de rétroaction explique pourquoi l’écart peut se creuser sous pression. Une politique statique ne voit pas directement quel GPU approche d’une limite mémoire. Un contrôleur conscient de la télémétrie peut réduire le trafic vers un point de terminaison en difficulté avant que sa file d’attente ne devienne le goulot d’étranglement du cluster.

F5 décrit également le routage comme sensible aux préfixes et au cache KV. La sensibilité aux préfixes tente d’envoyer des prompts associés vers un backend qui détient déjà un contexte réutilisable. Éviter de reconstruire inutilement le cache peut réduire le travail de calcul et les fluctuations de consommation mémoire.

La prise en compte de la charge sert un objectif différent. Elle répartit les requêtes selon la capacité disponible, au lieu de supposer que chaque point de terminaison est également prêt. Le résultat le plus marqué devrait apparaître lorsque ces hypothèses divergent, ce que la charge sursouscrite du laboratoire a créé.

Le logiciel ne rend pas intrinsèquement les GPU H100 plus rapides. Il cherche à gaspiller moins de leur temps de traitement disponible. Cette distinction est essentielle lors de l’évaluation des affirmations sur les performances des GPU.

Une meilleure planification peut accroître le débit total du cluster sans modifier les poids du modèle ni le silicium des accélérateurs. Elle peut aussi réduire le nombre de requêtes bloquées derrière des prompts particulièrement coûteux. Toutefois, le bénéfice dépend de la diversité de la charge de travail et de la qualité de la télémétrie.

Un lot uniforme de prompts courts offre moins d’occasions de routage. Un flux très variable crée davantage de situations où un placement intelligent peut compter. Les résultats du laboratoire ont suivi ce schéma, avec des écarts plus faibles dans des conditions plus légères.

La documentation publique de F5 cite des améliorations de débit de 30 à 40 % par rapport au routage par tourniquet. Séparément, F5 a indiqué que des tests validés par The Tolly Group avaient produit jusqu’à 40 % de débit de tokens supplémentaire. La même annonce revendiquait un délai avant le premier token 61 % plus rapide et une latence globale des requêtes inférieure de 34 %.

Ces chiffres sont plus mesurés que 3,24x parce qu’ils décrivent des tests différents. Ils restent également des affirmations de performance publiées par le fournisseur, même lorsqu’une organisation de test externe a effectué les mesures. Les acheteurs devraient examiner les configurations sous-jacentes avant de comparer les pourcentages.

Le système de F5 peut se placer devant des routeurs de modèles externes tels que LiteLLM, RouteLLM et NVIDIA Router. Il peut faire passer une requête par une couche de sélection de modèle avant de la diriger vers une adresse virtuelle du backend choisi.

Cela signifie que BNK ne remplace pas nécessairement chaque composant de routage. Il peut devenir la couche de trafic et de politiques qui les entoure. Cette position élargie permet à F5 de relier le placement GPU à la sécurité, à la mesure de consommation et à l’application des règles réseau.

L’architecture compte parce que les passerelles d’inférence deviennent des points de contrôle de ressources rares. Elles peuvent décider quel modèle traite une requête, quel utilisateur reçoit de la capacité et à quel moment le trafic doit être ralenti. Une mauvaise décision gaspille plus que de la bande passante réseau.

La véritable confrontation oppose le routage conscient des GPU aux backends opaques

La pression s’exerce sur les passerelles qui traitent chaque point de terminaison d’inférence disponible comme un serveur interchangeable.

Le principal adversaire de F5 n’est pas une entreprise en particulier. C’est un ancien modèle de gestion du trafic qui voit les connexions, mais pas l’état interne de chaque accélérateur. Le laboratoire a utilisé Envoy AI Gateway comme comparaison représentative.

Le projet Agent Router, associé à l’écosystème cloud-native en évolution, reflète une dynamique plus large en faveur d’un routage IA spécialisé. Les dénominations et le paysage des projets continuent d’évoluer, ce qui complique les comparaisons simples entre produits.

Envoy demeure lui-même une base de proxy largement utilisée. Le test F5 n’établit pas qu’Envoy ne peut pas prendre en charge un routage d’inférence plus intelligent. Il compare des implémentations, emplacements, politiques et configurations spécifiques.

La différenciation de F5 combine plusieurs couches. Son Endpoint Picker utilise la télémétrie en temps réel pour sélectionner les backends. Le déploiement sur DPU place le traitement du trafic hors de l’hôte. Sa plateforme plus large ajoute des contrôles de sécurité, d’isolation des locataires et de consommation de tokens.

Le déplacement de ces fonctions vers BlueField-3 crée un second axe de concurrence. Une passerelle basée sur l’hôte consomme des cycles CPU et de la bande passante mémoire sur le serveur. Une passerelle basée sur DPU utilise un processeur dédié tout en restant physiquement proche de la charge de travail.

Le guide des usines IA de NVIDIA présente l’intégration de F5 comme une option pour décharger les proxys, l’équilibrage de charge, le chiffrement, les pare-feux et la protection des API. Le même guide identifie des intégrations de fournisseurs de sécurité, notamment Fortinet et Palo Alto Networks.

Ce contexte montre pourquoi le marché ne se résumera pas à F5 contre Envoy. Les fournisseurs d’infrastructure rivalisent pour placer l’intelligence de sécurité et de trafic dans la couche DPU. Les projets open source ajoutent eux aussi des fonctions de routage sensibles aux modèles.

La décision pratique concerne la propriété. Certains opérateurs souhaitent un plan de services commercial avec support et politiques intégrés. D’autres préfèrent des composants open source composables que leurs équipes de plateforme peuvent inspecter, modifier et exploiter.

L’intégration commerciale peut réduire le travail nécessaire pour relier télémétrie, routage, réseau et sécurité. Elle peut aussi accroître la dépendance envers le plan de contrôle d’un fournisseur particulier et sa matrice matérielle prise en charge. Ce compromis devient important à l’échelle de grandes flottes.

Les composants ouverts peuvent offrir flexibilité et portabilité. Ils obligent également les équipes d’ingénierie à assembler l’observabilité, l’application des politiques, la logique de routage et la gestion du cycle de vie. Le coût de ce travail apparaît rarement dans un simple graphique de débit.

La position de F5 est la plus forte lorsque des flottes de GPU servent de nombreux locataires aux charges de travail inégales. Une infrastructure partagée accroît le besoin d’isolation, de limites de débit, de comptabilisation de l’utilisation et de niveaux de service prévisibles. Elle rend également plus coûteux un placement inefficace des requêtes.

Sa position est moins évidente pour les petits clusters ou les clusters faiblement sollicités. Si les endpoints approchent rarement leurs limites, un routage statique ou plus simple peut rester adéquat. L’infrastructure supplémentaire doit justifier son empreinte opérationnelle.

F5 indique qu’aucune modification de modèle n’est nécessaire pour son routage et son déchargement sur DPU. Cela réduit un obstacle à l’adoption, car les équipes peuvent conserver leurs serveurs de modèles existants. Le déploiement implique néanmoins de nouveaux composants d’infrastructure, des pipelines de télémétrie, des politiques et des modes de défaillance.

La documentation de l’entreprise indique que l’équilibrage de charge AI est désactivé par défaut. Les opérateurs doivent configurer cette fonctionnalité et son chemin de données. Ils ont également besoin de Prometheus et d’une télémétrie compatible lorsqu’ils utilisent l’analyseur intégré.

Seules les métriques GPU NVIDIA bénéficient d’une prise en charge intégrée par plugin dans la documentation actuelle. Les organisations utilisant d’autres accélérateurs peuvent nécessiter une logique personnalisée. Même les environnements NVIDIA peuvent varier selon les serveurs de modèles, les configurations réseau et les pratiques d’orchestration.

Les exigences matérielles sont également spécifiques. Les exigences DPU de F5 identifient le matériel BlueField-3 pris en charge, la mémoire minimale, les interfaces double réseau et les composants logiciels requis.

Ces mêmes exigences précisent que le DPU doit être dédié à BNK. Elles avertissent que d’autres logiciels DPU peuvent provoquer des problèmes de performances ou une instabilité de Kubernetes. Un seul DPU par châssis est pris en charge pour BNK dans cette configuration documentée.

Ces contraintes font de la décision d’achat bien plus qu’une comparaison de performances de passerelle. Les équipes doivent décider comment allouer les DPU, gérer les firmwares, intégrer le réseau et récupérer les composants défaillants. Elles doivent comparer ce travail à la capacité hôte économisée.

Ce que l’affirmation de performances de 3,24x n’établit pas

Le résultat de laboratoire est un signal de stress utile, mais il ne constitue pas une preuve indépendante d’un avantage universel en production.

ServeTheHome a explicitement révélé que F5 avait sponsorisé la visite du laboratoire en Californie. Cette transparence aide les lecteurs à interpréter le rapport, mais elle ne supprime pas la nécessité d’une reproduction indépendante.

Le matériel, le modèle, la précision, les tailles de prompts et les modèles de requêtes étaient étroitement définis. Chacune de ces variables peut modifier le comportement du routage. Un modèle ou un moteur de service différent pourrait gérer différemment la pression sur le cache.

Le résultat le plus marquant est apparu dans la condition de 200 requêtes concurrentes et 20 000 tokens. Cette charge de travail exigeait 1,24 fois le cache KV disponible. Elle plaçait délibérément le cluster au-delà d’une limite de ressources confortable.

Une telle surcharge est utile pour révéler le comportement de l’ordonnanceur. Elle peut aussi amplifier la différenciation d’un produit dans son meilleur scénario. Les acheteurs ont besoin de résultats couvrant l’utilisation normale, l’utilisation de pointe et la surcharge prolongée.

La comparaison associait également l’emplacement du routage et l’intelligence du routage. F5 fonctionnait sur un DPU, tandis que l’alternative fonctionnait sur l’hôte. Le test n’isole donc pas la contribution aux performances de chaque choix de conception.

Une évaluation plus révélatrice comparerait plusieurs configurations. F5 pourrait fonctionner sur l’hôte et sur DPU avec la même politique. Les passerelles concurrentes pourraient fonctionner avec un routage statique et un routage tenant compte de la télémétrie. Le cluster pourrait alors distinguer séparément la contribution du déchargement et de l’ordonnancement.

L’article public fournit de nombreux graphiques, mais pas tous les journaux bruts ni tous les détails de configuration nécessaires à la reproduction. Il mentionne que l’intelligence artificielle a contribué à transformer les journaux en affichages visuels. Ce choix de présentation renforce l’importance de publier des résultats lisibles par machine.

L’annonce de performances de F5 de mars 2026 offre un autre point de preuve. Elle fait état de gains plus faibles issus de tests distincts et attribue la validation à The Tolly Group.

Plusieurs tests indiquant la même direction renforcent la plausibilité du mécanisme. Ils ne rendent pas les pourcentages interchangeables. Des références, charges de travail et métriques de réussite différentes peuvent produire des améliorations affichées très différentes.

Les requêtes terminées, le débit de tokens et la latence répondent chacun à une question différente. Un système peut produire davantage de tokens agrégés tout en donnant à certains utilisateurs des réponses initiales plus lentes. Il peut réduire la latence moyenne tout en laissant la latence de queue instable.

Le laboratoire a examiné le temps moyen et P99 jusqu’au premier token, parallèlement au débit. Les acheteurs en production devraient également étudier les requêtes échouées, les taux de nouvelle tentative, la qualité des réponses et l’équité entre locataires. Ces mesures révèlent si un débit plus élevé provient d’une priorisation indésirable.

Les optimisations du service de modèles peuvent également influencer la cohérence des résultats. Router un prompt vers un modèle plus petit peut réduire l’utilisation des ressources, mais modifier la qualité. F5 décrit un routage fondé sur des politiques entre modèles plus grands et plus petits, bien que cette fonction ne constituait pas le cœur de cette comparaison.

Les fonctions de sécurité créent un autre problème de mesure. Une passerelle qui gère le chiffrement, les règles de pare-feu, les contrôles de tokens et l’inspection effectue davantage de travail qu’un routeur minimal. Des comparaisons équitables doivent aligner les fonctionnalités activées ou expliquer leur valeur opérationnelle.

Le déchargement sur DPU peut préserver les ressources hôtes, mais ces DPU ne sont pas une capacité gratuite. Ils consomment de l’énergie, nécessitent une gestion et occupent une partie de l’architecture serveur. La mesure économique pertinente est la production totale du cluster rapportée au coût total de l’infrastructure.

Les affirmations des fournisseurs sur la « libération de cycles GPU » exigent également une formulation prudente. Les services réseau rivalisent souvent directement pour les ressources CPU de l’hôte plutôt que de s’exécuter sur le GPU lui-même. Un meilleur routage peut accroître l’utilisation des GPU, mais le DPU ne crée pas de nouveaux cœurs d’accélérateur.

Le résultat de 3,24x est le plus crédible comme preuve d’un avantage de gestion des goulots d’étranglement dans un scénario extrême. Il ne devrait pas devenir un multiplicateur général dans les plans de capacité. Même ServeTheHome l’a décrit comme se situant près de la limite supérieure des bénéfices observés.

Le rapport a proposé un exemple plus modeste : une amélioration de 1,25x ressemble à l’obtention de la production de cinq GPU à partir d’une base de quatre GPU. Cette analogie illustre les enjeux économiques, mais les gains en production dépendront de chaque cluster.

Les équipes devraient recréer leur propre distribution de longueurs de prompts, courbe de concurrence, réutilisation du cache, mix de modèles et objectifs de service. Elles devraient ensuite comparer des configurations cohérentes sur de longues périodes. Les démonstrations courtes ne peuvent pas capturer toutes les défaillances opérationnelles.

Un pilote crédible devrait inclure des interruptions de télémétrie et des métriques obsolètes. Si le contrôleur de routage perd sa visibilité sur l’état des GPU, les opérateurs doivent savoir à quelle vitesse il détecte le problème. Ils ont également besoin d’une politique de repli prévisible.

Le test devrait couvrir la défaillance du DPU, la perturbation du plan de contrôle et le partitionnement réseau. Il devrait montrer si les requêtes actives survivent et si le nouveau trafic se déplace en toute sécurité. Les performances en fonctionnement parfait ne représentent qu’une partie de la préparation à la production.

Trois signaux montreront si l’avantage du laboratoire se confirme

Le prochain test consiste à déterminer si F5 peut transformer un résultat convaincant en surcharge en gains reproductibles sur des charges de travail de production ordinaires.

Le premier signal est la reproduction indépendante des charges de travail. Les acheteurs ont besoin de tests publiant les données brutes et des configurations complètes pour plusieurs modèles, frameworks de service et distributions de prompts. Les résultats devraient distinguer le déchargement sur DPU de l’ordonnancement piloté par télémétrie.

Des améliorations cohérentes sous charge modérée renforceraient le dossier de F5. Des bénéfices qui n’apparaissent que lors d’une surallocation délibérée du cache réduiraient le cas d’usage adressable. Les deux résultats fourniraient néanmoins des informations utiles pour la planification de capacité.

Le deuxième signal est un éventail plus large de preuves de déploiement. F5 et NVIDIA décrivent les entreprises et fournisseurs de services GPU comme utilisateurs cibles, mais des exemples de production nommés rendraient le modèle opérationnel plus clair. Des retours utiles devraient expliquer la taille du cluster, les variations de trafic et les modes de défaillance observés.

Les preuves de production devraient également montrer si les équipes conservent les gains de capacité promis après l’activation de contrôles de sécurité complets. La gouvernance des tokens, le chiffrement, l’isolation des locataires et l’audit ajoutent tous du travail. Leur impact combiné compte davantage qu’un benchmark allégé.

Le troisième signal est la réponse des projets de passerelles ouvertes et de routage d’inférence. Si ces projets ajoutent une télémétrie GPU comparable, une prise en compte des préfixes et un placement sensible au cache, l’avantage de routage de F5 pourrait devenir une capacité standard.

Cette issue déplacerait la concurrence vers l’intégration opérationnelle, la prise en charge des DPU, les politiques de sécurité et le service fournisseur. Elle bénéficierait aussi aux utilisateurs en rendant la gestion du trafic consciente de l’AI disponible via davantage de modèles de déploiement.

F5 conserve une position significative parce qu’elle combine déjà ces couches. Sa présentation de plateforme présente BNK comme une gestion unifiée du trafic Kubernetes couvrant la livraison applicative, la sécurité et les politiques. L’option DPU étend ce modèle à l’infrastructure AI.

Toutefois, l’étendue de la plateforme ne supprime pas la charge de la preuve. Les opérateurs de clusters devraient exiger des mesures spécifiques à leurs charges de travail avant de repenser leurs plans d’entrée et de services. Ils devraient mesurer le coût par requête terminée, pas seulement le pic de tokens par seconde.

Pour les développeurs, cette évolution rappelle que le code du modèle ne détermine plus à lui seul les performances d’inférence. Le placement des requêtes, la localité du cache, la gestion des files d’attente et l’isolation de l’infrastructure peuvent modifier sensiblement la quantité de travail accomplie par des GPU identiques.

Pour les acheteurs en entreprise, le sujet concerne l’utilisation avant l’expansion. Une couche de contrôle plus intelligente peut être plus pratique que l’acquisition d’accélérateurs supplémentaires lorsque l’alimentation, la capacité en rack ou les calendriers de livraison limitent la croissance.

Le résultat d’équilibrage de charge AI de F5 présente son argument le plus fort au pire moment du cluster. C’est précieux, car la pression de pointe détermine souvent les achats de capacité et l’expérience utilisateur. C’est aussi précisément là qu’une validation rigoureuse compte le plus.

Avant d’adopter le chiffre de 3,24x, reproduisez les conditions qui l’ont produit. Comparez le trafic ordinaire, les pics prolongés et la récupération après défaillance avec vos modèles et vos politiques. Posez ensuite la question décisive : un routage plus intelligent retarde-t-il le prochain achat de matériel sans ajouter plus de risque opérationnel qu’il n’en élimine ?