El balanceo de carga de IA de F5 alcanza 3,24 veces más en un laboratorio, pero solo bajo presión extrema
Según se informa, el balanceo de carga de IA de F5 completó 3,24 veces más trabajo que una puerta de enlace basada en Envoy durante la prueba más exigente de una visita a un laboratorio patrocinada por F5. El resultado provino de BIG-IP Next for Kubernetes ejecutándose en unidades de procesamiento de datos NVIDIA BlueField-3, o DPU. Sin embargo, la carga de trabajo más ligera mostró una diferencia mucho menor. Ese contraste importa más que la cifra del titular.
La prueba utilizó servidores Supermicro equipados con ocho GPU NVIDIA H100 cada uno. Cada GPU servía el modelo Qwen3-32B con precisión numérica FP8. BIG-IP Next for Kubernetes gestionaba el tráfico mediante las DPU, mientras que la puerta de enlace de comparación se ejecutaba en procesadores del host.
No fue un veredicto amplio sobre todas las puertas de enlace de Kubernetes ni todos los clústeres de inferencia. Fue una comparación específica bajo condiciones controladas, reportada por ServeTheHome después de una visita patrocinada. Aun así, expone una competencia cada vez más relevante: el enrutamiento de tráfico basado en las condiciones en tiempo real de las GPU frente a un enrutamiento que sigue en gran medida desvinculado del estado de los aceleradores.
La pregunta central ya no es si un clúster posee suficientes GPU. Es si su software puede mantener productivos esos costosos aceleradores cuando las solicitudes se vuelven largas, simultáneas y difíciles de asignar.
La prueba de F5 BIG-IP Next for Kubernetes sometió el enrutamiento a presión
La ventaja reportada surgió cuando la caché clave-valor del clúster quedó sobresuscrita, no durante la línea de base más sencilla.
La prueba de laboratorio comparó dos rutas que servían el mismo modelo Qwen3-32B. Los componentes de control y Endpoint Picker de F5 se ejecutaban en DPU BlueField-3. La alternativa utilizaba Envoy AI Gateway, posteriormente renombrado como Agent Router, en el host.
La prueba siguió la latencia P90 durante ejecuciones de 60 minutos. AI Perf Tool de NVIDIA generó solicitudes con distintos niveles de concurrencia y longitudes de prompt. Cuatro patrones de tráfico cubrieron solicitudes sin prefijo compartido, conversaciones de varios turnos, tráfico mixto y una intensa reutilización de prefijos.
La línea de base combinó 150 solicitudes simultáneas con 10.000 tokens de entrada por solicitud. ServeTheHome informó que las dos puertas de enlace tuvieron un rendimiento relativamente cercano en ese caso. El clúster utilizó el 46 por ciento de la capacidad disponible de su caché clave-valor.
Una caché clave-valor, normalmente abreviada como caché KV, almacena datos de atención que un modelo puede reutilizar mientras genera tokens. Mejora la velocidad de inferencia, pero consume una cantidad considerable de memoria de GPU. Los prompts largos y muchos usuarios simultáneos pueden llevar ese recurso de memoria más allá de límites cómodos.
La prueba exigente elevó la concurrencia de 150 a 200, un aumento del 33 por ciento. También duplicó la longitud de entrada de cada solicitud hasta 20.000 tokens. La carga de trabajo resultante demandó 1,24 veces la capacidad de caché KV disponible del clúster.
Esa sobresuscripción cambió el resultado. ServeTheHome informó de una mejora de 3,24 veces para la ruta de F5 porque distribuyó la carga de trabajo difícil de forma más eficaz. Sus gráficos publicados también examinaron las solicitudes completadas, los tokens de salida por segundo y el tiempo hasta el primer token.
Por lo tanto, la cifra de 3,24 veces debe interpretarse como un resultado bajo alta presión. No significa que todos los clústeres procesarán 3,24 veces más tráfico tras instalar software de F5. El mismo informe describe ese número como un extremo dentro de la configuración probada.
Esa salvedad no vuelve irrelevante la prueba. Los sistemas de inferencia en producción deben soportar picos, contextos largos y cargas desiguales entre aceleradores. Una puerta de enlace que se comporta de forma similar con baja utilización puede volverse mucho más valiosa cerca de la saturación.
El cambio importante es arquitectónico. El balanceo de carga se ha acercado al estado de servicio del modelo, incluida la profundidad de las colas, la utilización de GPU y la presión sobre la caché. La puerta de enlace ya no toma decisiones solo a partir de conexiones de red.
F5 denomina a BIG-IP Next for Kubernetes, o BNK, un plano de servicio de IA. Se sitúa entre los clientes y la infraestructura de GPU, al tiempo que combina gestión de tráfico, seguridad, enrutamiento y controles de uso. El producto puede ejecutarse en procesadores del host o en DPU BlueField-3 compatibles.
Colocarlo en una DPU traslada las tareas de red y seguridad fuera de los procesadores principales del servidor. La DPU es un procesador de infraestructura programable diseñado para gestionar tareas de red, almacenamiento y seguridad. Esto deja recursos del host disponibles para el servicio de modelos y las operaciones del clúster.
La prueba, por tanto, midió dos ideas conectadas. Una era la calidad del enrutamiento bajo presión de memoria de GPU. La otra era trasladar el trabajo de infraestructura a hardware diseñado para procesarlo fuera del host.
Por qué el balanceo de carga de IA de F5 mejora bajo una demanda elevada
El mecanismo de F5 depende de observar condiciones de los aceleradores que las métricas de red convencionales no pueden describir.
Los balanceadores de carga tradicionales pueden distribuir el tráfico mediante round-robin, recuentos de conexiones o prioridades fijas. Estos métodos funcionan bien cuando los servidores de backend tienen una capacidad predecible. La inferencia de modelos de lenguaje grandes rompe esa premisa.
Una solicitud puede contener una pregunta breve. Otra puede incluir 20.000 tokens de documentos e historial de conversación. Una tercera podría reutilizar un prefijo ya almacenado en la caché KV de una GPU.
Estas solicitudes pueden generar tiempos de procesamiento distintos incluso cuando llegan a GPU idénticas. Las colas también cambian rápidamente a medida que los modelos agrupan solicitudes, asignan memoria y transmiten tokens generados. Un endpoint de red en buen estado puede seguir siendo un mal destino para el siguiente prompt.
La documentación de balanceo de carga de F5 describe un componente Analyzer que vigila la telemetría de las GPU y del servicio de modelos. Recomienda nuevos pesos de tráfico para cada backend. El Traffic Management Microkernel de F5 aplica después esos pesos en el plano de datos.
Las entradas documentadas incluyen latencia de inferencia, profundidad de cola, consumo de memoria de GPU, estado térmico y tasas de error. F5 también admite telemetría de NVIDIA Inference Microservices, NVIDIA Data Center GPU Manager y vLLM.
Ese ciclo de retroalimentación explica por qué la diferencia puede ampliarse bajo presión. Una política estática no tiene una visión directa de qué GPU se aproxima a un límite de memoria. Un controlador consciente de la telemetría puede reducir el tráfico hacia un endpoint con dificultades antes de que su cola se convierta en el cuello de botella del clúster.
F5 también describe el enrutamiento como consciente de prefijos y de la caché KV. La conciencia de prefijos intenta enviar prompts relacionados hacia un backend que ya conserva contexto reutilizable. Evitar la reconstrucción innecesaria de caché puede reducir el trabajo de cómputo y la rotación de memoria.
La conciencia de carga cumple otra función. Distribuye las solicitudes según la capacidad disponible, en lugar de asumir que todos los endpoints están igualmente preparados. El resultado más contundente debería aparecer cuando esas suposiciones divergen, que es lo que creó la carga de trabajo sobresuscrita del laboratorio.
El software no hace que las GPU H100 sean intrínsecamente más rápidas. Intenta desperdiciar menos de su tiempo de procesamiento disponible. Esta distinción es esencial al evaluar afirmaciones sobre el rendimiento de las GPU.
Una programación mejorada puede aumentar el rendimiento total del clúster sin modificar los pesos del modelo ni el silicio del acelerador. También puede reducir el número de solicitudes atrapadas detrás de prompts inusualmente costosos. Sin embargo, el beneficio depende de la diversidad de la carga de trabajo y de la calidad de la telemetría.
Un lote uniforme con prompts cortos ofrece menos oportunidades de enrutamiento. Un flujo muy variable crea más ocasiones para que una asignación inteligente marque la diferencia. Los resultados del laboratorio siguieron ese patrón, con diferencias menores bajo condiciones más ligeras.
La documentación pública de F5 cita mejoras de rendimiento de entre el 30 y el 40 por ciento frente al enrutamiento round-robin. Por separado, F5 afirmó que pruebas validadas por The Tolly Group produjeron hasta un 40 por ciento más de rendimiento de tokens. El mismo anuncio afirmó un tiempo hasta el primer token un 61 por ciento más rápido y una latencia general de solicitudes un 34 por ciento menor.
Estas cifras son más moderadas que 3,24 veces porque describen pruebas diferentes. También siguen siendo afirmaciones de rendimiento publicadas por el proveedor, incluso cuando una organización externa de pruebas realizó las mediciones. Los compradores deberían examinar las configuraciones subyacentes antes de comparar porcentajes.
El sistema de F5 puede situarse delante de enrutadores de modelos externos como LiteLLM, RouteLLM y NVIDIA Router. Puede enviar una solicitud a través de una capa de selección de modelo antes de dirigirla hacia una dirección virtual para el backend elegido.
Eso significa que BNK no necesariamente sustituye todos los componentes de enrutamiento. Puede convertirse en la capa de tráfico y políticas que los rodea. Esta posición más amplia permite a F5 conectar la asignación de GPU con la seguridad, la medición y la aplicación de políticas de red.
La arquitectura importa porque las puertas de enlace de inferencia se están convirtiendo en puntos de control para recursos escasos. Pueden decidir qué modelo procesa una solicitud, qué usuario recibe capacidad y cuándo debe ralentizarse el tráfico. Una mala decisión desperdicia más que ancho de banda de red.
La competencia real es entre el enrutamiento consciente de las GPU y los backends opacos
La presión recae sobre las puertas de enlace que tratan cada endpoint de inferencia disponible como un servidor intercambiable.
El principal rival de F5 no es una sola empresa. Es un modelo más antiguo de gestión de tráfico que ve las conexiones, pero no la condición interna de cada acelerador. El laboratorio utilizó Envoy AI Gateway como comparación representativa.
El proyecto Agent Router, asociado al ecosistema cloud-native en evolución, refleja un impulso más amplio hacia el enrutamiento especializado para IA. Los nombres y el panorama de proyectos continúan cambiando, lo que complica las comparaciones simples entre productos.
Envoy sigue siendo una base de proxy ampliamente utilizada. La prueba de F5 no demuestra que Envoy no pueda admitir un enrutamiento de inferencia más inteligente. Compara implementaciones, ubicaciones, políticas y configuraciones concretas.
La diferenciación de F5 combina varias capas. Su Endpoint Picker utiliza telemetría en tiempo real para seleccionar backends. La implementación con DPU sitúa el procesamiento de tráfico fuera del host. Su plataforma más amplia añade controles de seguridad, aislamiento de inquilinos y consumo de tokens.
Trasladar esas funciones a BlueField-3 crea un segundo eje competitivo. Una puerta de enlace basada en host consume ciclos de CPU y ancho de banda de memoria en el servidor. Una puerta de enlace basada en DPU utiliza un procesador dedicado mientras permanece físicamente cerca de la carga de trabajo.
La guía de fábrica de IA de NVIDIA enumera la integración de F5 como una opción para descargar proxies, balanceo de carga, cifrado, cortafuegos y protección de API. La misma guía identifica integraciones de proveedores de seguridad, incluidos Fortinet y Palo Alto Networks.
Ese contexto muestra por qué el mercado no se reducirá a F5 frente a Envoy. Los proveedores de infraestructura compiten por situar la inteligencia de seguridad y tráfico dentro de la capa DPU. Los proyectos de código abierto también están añadiendo funciones de enrutamiento conscientes de los modelos.
La decisión práctica se refiere a la propiedad. Algunos operadores quieren un plano de servicio comercial con soporte y políticas integrados. Otros prefieren componentes de código abierto componibles que sus equipos de plataforma puedan inspeccionar, modificar y operar.
La integración comercial puede reducir el trabajo necesario para conectar telemetría, enrutamiento, redes y seguridad. También puede profundizar la dependencia del plano de control de un proveedor concreto y de su matriz de hardware compatible. Esa disyuntiva adquiere relevancia en grandes flotas.
Los componentes abiertos pueden ofrecer flexibilidad y portabilidad. También exigen que los equipos de ingeniería integren observabilidad, aplicación de políticas, lógica de enrutamiento y gestión del ciclo de vida. El coste de ese trabajo rara vez aparece en un simple gráfico de rendimiento.
La posición de F5 es más sólida allí donde las flotas de GPU atienden a muchos inquilinos con cargas de trabajo desiguales. La infraestructura compartida incrementa la necesidad de aislamiento, límites de tasa, contabilización de uso y niveles de servicio predecibles. También hace que una colocación ineficiente de solicitudes resulte más costosa.
Su posición es menos evidente para clústeres pequeños o con poca carga. Si los endpoints rara vez se acercan a sus límites, un enrutamiento estático o más simple puede seguir siendo adecuado. La infraestructura adicional debe justificar su huella operativa.
F5 afirma que no se requieren cambios en los modelos para su enrutamiento y descarga a DPU. Esto reduce una barrera de adopción porque los equipos pueden conservar los servidores de modelos existentes. Sin embargo, la implementación sigue implicando nuevos componentes de infraestructura, canalizaciones de telemetría, políticas y modos de fallo.
La documentación de la empresa indica que el equilibrio de carga de IA está desactivado de forma predeterminada. Los operadores deben configurar la función y su ruta de datos. También necesitan Prometheus y telemetría compatible cuando utilizan el analizador integrado.
Solo las métricas de GPU de NVIDIA cuentan con soporte de plugin integrado en la documentación actual. Las organizaciones que usen otros aceleradores podrían necesitar lógica personalizada. Incluso los entornos de NVIDIA pueden variar según los servidores de modelos, las topologías de red y las prácticas de orquestación.
Los requisitos de hardware también son específicos. Los requisitos de DPU de F5 identifican el hardware BlueField-3 compatible, la memoria mínima, interfaces de red duales y los componentes de software necesarios.
Los mismos requisitos establecen que la DPU debe estar dedicada a BNK. Advierten de que otro software de DPU puede causar problemas de rendimiento o inestabilidad en Kubernetes. Solo se admite una DPU por chasis para BNK en esa configuración documentada.
Estas restricciones convierten la decisión de compra en algo más que una prueba comparativa de gateway. Los equipos deben decidir cómo asignar las DPU, gestionar el firmware, integrar la red y recuperar componentes que fallen. Deben comparar ese trabajo con la capacidad de host que se ahorra.
Lo que la afirmación de rendimiento de 3,24x no demuestra
El resultado de laboratorio es una señal útil de estrés, pero no constituye una prueba independiente de una ventaja universal en producción.
ServeTheHome reveló explícitamente que F5 patrocinó la visita al laboratorio de California. Esa transparencia ayuda a los lectores a interpretar el informe, pero no elimina la necesidad de una reproducción independiente.
El hardware, el modelo, la precisión, los tamaños de los prompts y los patrones de solicitudes estaban estrictamente definidos. Cada una de esas variables puede modificar el comportamiento del enrutamiento. Un modelo o motor de servicio diferente podría gestionar la presión de caché de otra manera.
El resultado más sólido se obtuvo con la condición de 200 solicitudes concurrentes y 20.000 tokens. Esa carga de trabajo exigía 1,24 veces la caché KV disponible. Colocó deliberadamente al clúster más allá de un límite de recursos cómodo.
Esta sobrecarga es valiosa para exponer el comportamiento del planificador. También puede amplificar la diferenciación de un producto en su mejor escenario. Los compradores necesitan resultados con utilización normal, utilización máxima y sobrecarga sostenida.
La comparación también combinó la ubicación del enrutamiento con la inteligencia de enrutamiento. F5 se ejecutó en una DPU, mientras que la alternativa se ejecutó en el host. Por tanto, la prueba no aísla la contribución de rendimiento de cada decisión de diseño.
Una evaluación más reveladora compararía varias configuraciones. F5 podría ejecutarse en el host y en la DPU con la misma política. Los gateways competidores podrían ejecutarse con enrutamiento tanto estático como consciente de la telemetría. El clúster podría entonces mostrar por separado la contribución de la descarga y de la planificación.
El artículo público incluye muchos gráficos, pero no todos los registros sin procesar ni los detalles de configuración necesarios para reproducirlo. Menciona que la inteligencia artificial ayudó a transformar registros en visualizaciones. Esa elección de presentación aumenta la importancia de publicar resultados legibles por máquina.
El anuncio de rendimiento de marzo de 2026 de F5 aporta otro punto de evidencia. Informa de ganancias menores en pruebas independientes y atribuye la validación a The Tolly Group.
Varias pruebas que muestran la misma dirección refuerzan la plausibilidad del mecanismo. No hacen que los porcentajes sean intercambiables. Diferentes líneas de base, cargas de trabajo y métricas de éxito pueden generar mejoras destacadas muy distintas.
Las solicitudes completadas, el rendimiento de tokens y la latencia responden cada uno a una pregunta diferente. Un sistema puede generar más tokens agregados mientras ofrece a algunos usuarios respuestas iniciales más lentas. Puede reducir la latencia media mientras la latencia de cola sigue siendo inestable.
El laboratorio examinó el tiempo medio y P99 hasta el primer token junto con el rendimiento. Los compradores de producción también deberían estudiar las solicitudes fallidas, las tasas de reintento, la calidad de las respuestas y la equidad entre inquilinos. Estas medidas revelan si un mayor rendimiento llega mediante una priorización indeseable.
Las optimizaciones del servicio de modelos también pueden influir en la consistencia de la salida. Enrutar un prompt hacia un modelo más pequeño puede reducir el uso de recursos, pero cambiar la calidad. F5 describe el enrutamiento basado en políticas entre modelos más grandes y más pequeños, aunque esa función no fue el núcleo de esta comparación.
Las funciones de seguridad crean otro problema de medición. Un gateway que gestiona cifrado, reglas de firewall, controles de tokens e inspección realiza más trabajo que un enrutador mínimo. Las comparaciones justas deben alinear las funciones habilitadas o explicar su valor operativo.
La descarga a DPU puede preservar recursos del host, pero esas DPU no son capacidad gratuita. Consumen energía, requieren gestión y ocupan parte de la arquitectura del servidor. La medida económica relevante es la producción total del clúster frente al coste total de infraestructura.
Las afirmaciones de los proveedores sobre “liberar ciclos de GPU” también requieren una redacción cuidadosa. Los servicios de red suelen competir directamente por los recursos de CPU del host, en lugar de ejecutarse en la propia GPU. Un mejor enrutamiento puede elevar la utilización de GPU, pero la DPU no crea nuevos núcleos aceleradores.
El resultado de 3,24x es más creíble como evidencia de una ventaja de gestión de cuellos de botella en un escenario extremo. No debería convertirse en un multiplicador general para los planes de capacidad. Incluso ServeTheHome lo describió como cercano al extremo superior de los beneficios observados.
El informe ofreció un ejemplo más moderado: una mejora de 1,25x se parece a recibir la producción de cinco GPU a partir de una base de cuatro GPU. Esa analogía comunica la importancia económica, pero las ganancias de producción dependerán de cada clúster.
Los equipos deberían reproducir su propia distribución de longitudes de prompts, curva de concurrencia, reutilización de caché, combinación de modelos y objetivos de servicio. Después deberían comparar configuraciones coherentes durante ejecuciones largas. Las demostraciones breves no pueden capturar todos los fallos operativos.
Un piloto creíble debería incluir interrupciones de telemetría y métricas obsoletas. Si el controlador de enrutamiento pierde visibilidad de las condiciones de las GPU, los operadores necesitan saber con qué rapidez detecta el problema. También necesitan una política de respaldo predecible.
La prueba debería cubrir fallos de DPU, interrupciones del plano de control y particiones de red. Debería mostrar si las solicitudes activas sobreviven y si el tráfico nuevo se desplaza de forma segura. El rendimiento durante una operación perfecta representa solo una parte de la preparación para producción.
Tres señales mostrarán si la ventaja de laboratorio se traslada a producción
La siguiente prueba consiste en determinar si F5 puede convertir un resultado convincente bajo sobrecarga en ganancias repetibles en cargas de trabajo habituales de producción.
La primera señal es la reproducción independiente de cargas de trabajo. Los compradores necesitan pruebas que publiquen datos sin procesar y configuraciones completas en varios modelos, marcos de servicio y distribuciones de prompts. Los resultados deberían separar la descarga a DPU de la planificación basada en telemetría.
Las mejoras consistentes bajo carga moderada reforzarían el caso de F5. Los beneficios que aparezcan solo durante una sobresuscripción deliberada de la caché reducirían el caso de uso aplicable. Ambos resultados seguirían proporcionando información útil para la planificación de capacidad.
La segunda señal es una evidencia de implementación más amplia. F5 y NVIDIA describen a las empresas y los proveedores de servicios de GPU como usuarios objetivo, pero ejemplos de producción identificados harían más claro el modelo operativo. Los casos útiles deberían explicar el tamaño del clúster, la variación del tráfico y los modos de fallo observados.
La evidencia de producción también debería mostrar si los equipos conservan las ganancias de capacidad prometidas tras habilitar controles de seguridad completos. La gobernanza de tokens, el cifrado, el aislamiento de inquilinos y la auditoría añaden trabajo. Su impacto combinado importa más que una prueba comparativa simplificada.
La tercera señal es la respuesta de los proyectos abiertos de gateways y enrutamiento de inferencia. Si esos proyectos añaden telemetría de GPU comparable, reconocimiento de prefijos y colocación consciente de la caché, la ventaja de enrutamiento de F5 puede convertirse en una capacidad estándar.
Ese resultado desplazaría la competencia hacia la integración operativa, el soporte de DPU, las políticas de seguridad y el servicio del proveedor. También beneficiaría a los usuarios al hacer que la gestión de tráfico consciente de IA esté disponible mediante más modelos de implementación.
F5 conserva una posición relevante porque ya combina esas capas. Su visión general de la plataforma presenta BNK como una gestión unificada del tráfico de Kubernetes para entrega de aplicaciones, seguridad y políticas. La opción de DPU extiende ese modelo a la infraestructura de IA.
Aun así, la amplitud de la plataforma no elimina la carga de la prueba. Los operadores de clústeres deberían exigir mediciones específicas de sus cargas de trabajo antes de rediseñar sus planos de entrada y servicio. Deberían medir el coste por solicitud completada, no solo los tokens máximos por segundo.
Para los desarrolladores, este avance recuerda que el código del modelo ya no determina por sí solo el rendimiento de inferencia. La colocación de solicitudes, la localidad de caché, la gestión de colas y el aislamiento de infraestructura pueden cambiar de forma sustancial cuánto trabajo completan GPU idénticas.
Para los compradores empresariales, la historia trata sobre la utilización antes que la expansión. Una capa de control más inteligente puede ser más práctica que adquirir aceleradores adicionales cuando la energía, la capacidad de rack o los plazos de entrega limitan el crecimiento.
El resultado de equilibrio de carga de IA de F5 presenta su argumento más sólido en el peor momento del clúster. Esto es valioso porque la presión máxima suele determinar las compras de capacidad y la experiencia del usuario. También es precisamente donde una validación cuidadosa importa más.
Antes de adoptar la cifra de 3,24x, reproduzca las condiciones que la generaron. Compare el tráfico habitual, los picos sostenidos y la recuperación ante fallos con sus modelos y políticas. Después formule la pregunta decisiva: ¿un enrutamiento más inteligente retrasa la próxima compra de hardware sin añadir más riesgo operativo del que elimina?
