El 18 de junio de 2026, Anyscale y Google Cloud publicaron resultados conjuntos que documentan un salto de rendimiento importante en el stack de inferencia Ray Serve LLM + vLLM. Según los blogs de ingeniería de ambas compañías y el anuncio del proyecto vLLM en X, el nuevo stack alcanza "up to 4.4x higher throughput on prefill-heavy workloads and 24x on decode-heavy workloads" frente a versiones anteriores de Ray Serve LLM. Para las organizaciones que ejecutan modelos de lenguaje en infraestructura propia, estas cifras cambian la ecuación económica de forma significativa.
Lo relevante para pymes es que las optimizaciones ya están publicadas: Ray 2.56 y las versiones actuales de vLLM incluyen los cambios. No es una promesa de hoja de ruta.
Las tres optimizaciones que lo hacen posible
Tres cambios arquitectónicos explican la mejora. Cada uno ataca un cuello de botella diferente del pipeline de serving.
1. Direct Token Streaming (streaming directo de tokens)
Anteriormente, el routing de peticiones y el streaming de respuestas compartían el mismo camino de código a través del router de entrada. Ray 2.56 los separa: los tokens fluyen ahora directamente desde las réplicas del modelo hasta el cliente, sin pasar por el router en el camino de vuelta. Esto reduce la latencia al primer token (TTFT) y la latencia entre tokens (ITL), especialmente en respuestas largas y conversaciones multi-turno donde cada milisegundo de latencia es perceptible para el usuario.
2. v2 Ray Executor Backend para vLLM
Este cambio saca a Ray del plano de datos de inferencia. En lugar de que Ray coordine las operaciones de tensor, el ejecutor nativo de vLLM gestiona el bucle del motor mientras Ray se encarga de la orquestación y la tolerancia a fallos. El beneficio es acumulativo: cada mejora de motor que publique el equipo de vLLM, Flash Attention, paged KV-cache, decoding especulativo, se aplica automáticamente a los despliegues sobre Ray Serve, sin esperar un ciclo de integración adicional. Antes de esta optimización, los usuarios de Ray Serve solían ejecutar versiones de vLLM con uno o dos releases de retraso por los tiempos de integración.
3. Integración de HAProxy
Una capa HAProxy integrada gestiona el balanceo de carga interno entre réplicas del modelo. Esto evita que el hilo Python del router se sature bajo alta concurrencia, un problema documentado que provoca picos de latencia y peticiones descartadas en entornos de producción con muchas solicitudes simultáneas. Según el blog de Google Cloud, la combinación de las tres optimizaciones logra hasta 5x más rendimiento y 8x menos latencia respecto a la configuración anterior de Ray Serve LLM.
Qué significa para la IA local en pymes
La métrica más relevante para un despliegue local es el rendimiento por hora de GPU: cuántas peticiones puede servir el hardware fijo. Cuando las cargas decode-heavy, generación de texto largo, resúmenes de documentos, sesiones de chat multi-turno, alcanzan hasta 24x más rendimiento según mediciones reportadas por Anyscale y Google Cloud, las implicaciones prácticas son tres:
El mismo hardware atiende muchas más peticiones. Un servidor local que antes gestionaba 20 sesiones concurrentes puede gestionar un múltiplo de esa cifra sin coste adicional en GPU. Para organizaciones que ya han invertido en infraestructura propia, esto supone una reducción directa del coste por consulta.
El punto de equilibrio frente a las APIs en la nube se desplaza a favor de la infraestructura propia. Las APIs de IA en la nube cobran por token. La inferencia local tiene costes fijos de hardware. Cuanto mayor es el rendimiento, más peticiones comparten ese coste fijo, reduciendo el coste efectivo por consulta. Con una mejora de 24x en decode, la economía del autoalojamiento mejora de forma considerable a escala.
La soberanía del dato se mantiene al 100%. Con Ray Serve + vLLM ejecutándose en servidores propios, ningún dato sale de la infraestructura de la empresa. Para despachos de abogados, consultorías, empresas del sector salud o cualquier organización que procese documentos con información confidencial o datos personales, este es el requisito no negociable que ninguna API en la nube puede satisfacer, independientemente de sus cifras de rendimiento. Más información sobre IA local y soberanía del dato.
Limitaciones honestas del benchmark
Los tests se realizaron con hardware de nivel empresarial: GPUs NVIDIA HGX B200 en máquinas virtuales Google Cloud A4, ocho réplicas, modelo Gemma 4 E2B (elegido para aislar los cuellos de botella de orquestación, no de la inferencia del modelo en sí). Una estación de trabajo con una sola NVIDIA RTX 4090 o un Mac Studio M3 Ultra no alcanzará estas cifras absolutas.
Lo que sí se transfiere a cualquier escala de hardware:
- El v2 executor backend y el direct streaming son características publicadas, no código experimental. Se aplican a cualquier despliegue de vLLM, incluyendo configuraciones de una sola GPU.
- HAProxy puede añadirse manualmente delante de cualquier servidor Ollama o vLLM sin necesitar Kubernetes, configuración estándar de proxy inverso.
- Ray Serve en infraestructura propia (sin GKE) se beneficia igualmente de las mejoras de Ray 2.56.
Las ganancias porcentuales variarán según hardware y perfil de carga, pero los cuellos de botella que se están corrigiendo existen en todas las escalas.
Kit Digital y la inversión en IA local
Si tu empresa está evaluando la instalación de un servidor de inferencia local, una estación de trabajo GPU o un pequeño clúster on-premise, es el momento de revisar las opciones de financiación disponibles en España.
Según nuestra interpretación de las bases actuales del programa Kit Digital, la categoría "Inteligencia Artificial" puede cubrir la implementación de soluciones de IA local, incluyendo servicios de configuración y despliegue de software de inferencia. Los importes disponibles varían según el segmento de empresa (Segmento I, II o III), y los requisitos de justificación han evolucionado con las últimas convocatorias.
Recomendamos confirmar la elegibilidad de cada caso concreto con un agente digitalizador acreditado, ya que las condiciones específicas dependen del tipo de solución y del proveedor seleccionado. En Freshlab hemos acompañado a pymes españolas en proyectos de IA local articulados dentro del marco Kit Digital. Si quieres explorar si tu caso encaja, escríbenos.
Pasos siguientes
Si ya ejecutas vLLM en producción:
- Actualiza a la versión actual de vLLM, el v2 executor backend está incluido.
- Activa el direct streaming si usas Ray Serve (requiere Ray 2.56+).
- Monitoriza TTFT e ITL además de requests/segundo, estas son las métricas que reflejan la experiencia real del usuario en aplicaciones de chat o asistencia.
- Añade HAProxy delante de tu capa de serving si experimentas picos de latencia bajo alta concurrencia.
Si aún no tienes un stack de inferencia local y quieres saber si tiene sentido para tu organización, reserva una consulta con nuestro equipo. Analizamos tu caso, el perfil de carga esperado y la comparativa de costes frente a las APIs en la nube más habituales.
Fuentes: vLLM Project en X · Google Cloud Blog · Anyscale Blog