Resumen Técnico: STREAM – Middleware de Inferencia de LLM Multicapa con Transmisión de Tokens HPC de Doble Canal

Planteamiento del Problema

Los investigadores y profesionales se enfrentan a un panorama fragmentado al desplegar Modelos de Lenguaje Extensos (LLMs), viéndose obligados a elegir entre tres opciones imperfectas:

1. Inferencia Local: Gratuita y privada, pero limitada por las restricciones de hardware del usuario (modelos más pequeños, ventanas de contexto limitadas).
2. HPC Institucional: Ofrece potentes recursos de GPU sin coste marginal y mantiene los datos dentro de los límites institucionales, pero opera tras cortafuegos que bloquean los enfoques de transmisión estándar y depende de modelos de ejecución por lotes que carecen de mecanismos para la entrega incremental de resultados.
3. APIs de Nube Comercial: Proporcionan la calidad de los modelos de vanguardia bajo demanda, pero imponen costes significativos por token y políticas de retención de datos inadecuadas para la investigación sensible.

Ningún sistema existente unifica estos tres niveles, lo que provoca un gasto innecesario en la nube, el subaprovechamiento de los recursos de GPU institucionales y flujos de trabajo fragmentados. Además, las arquitecturas de transmisión estándar fallan en entornos HPC porque los nodos de cómputo se encuentran detrás de cortafuegos institucionales que bloquean todas las conexiones entrantes, y las máquinas cliente suelen estar detrás de una NAT, lo que las hace inalcanzables sin VPNs o cambios en las reglas del cortafuegos.

Metodología y Arquitectura del Sistema

STREAM (Smart Tiered Routing Engine for AI Models) actúa como una capa de middleware que unifica la inferencia local, de HPC y de la nube en un único servicio por niveles. El sistema procesa cada consulta a través de un pipeline estandarizado:

1. Arquitectura de Enrutamiento de Tres Niveles

Las consultas son clasificadas por un Juez de Complejidad (un LLM local, específicamente Llama 3.2 3B) en tres niveles:

• BAJO (LOW): Dirigido a modelos locales (p. ej., Llama 3.2 3B, Gemma 3 4B-VL) que se ejecutan en dispositivos de usuario o servidores co-ubicados vía Ollama.
• MEDIO (MEDIUM): Dirigido a recursos de HPC institucional (p. ej., Qwen 2.5-VL-72B-AWQ en GPUs H100 NVL).
• ALTO (HIGH): Dirigido a APIs de la nube comercial (p. ej., vía OpenRouter).
  El sistema incluye un mecanismo de fallback donde las consultas escalan o descienden de nivel según la disponibilidad y los estados de error, garantizando la continuidad.

2. Transmisión de Tokens HPC de Doble Canal

Para resolver el problema de la transmisión en HPC, STREAM introduce una arquitectura novedosa que separa el Plano de Control del Plano de Datos:

• Plano de Control (Globus Compute): Gestiona la autenticación federada y el despacho de tareas. Envía una tarea que contiene la consulta y los metadatos, pero no transporta cargas útiles de tokens.
• Plano de Datos (Relay de WebSocket): Un servidor de relay basado en la nube actúa como punto de encuentro.
  • Productor: El trabajador de HPC (que se ejecuta dentro de una tarea de Globus Compute) se conecta saliente al relay, lee el flujo SSE HTTP de vLLM token por token y los reenvía.
  • Consumidor: El cliente (o proxy) se conecta saliente al mismo canal de UUID único en el relay para recibir los tokens.
• Tránsito de Cortafuegos: Dado que ambos extremos inician conexiones salientes (wss:// en el puerto 443), la arquitectura atraviesa los cortafuegos institucionales y la NAT sin requerir puertos entrantes, VPNs o cambios en las reglas del cortafuego.
• Seguridad: El sistema emplea cifrado AES-256-GCM de extremo a extremo. Las claves de cifrado y los secretos del canal se precargan en el entorno del trabajador y nunca se transmiten como argumentos de la tarea, asegurando que el operador del relay no pueda leer las cargas útiles de los tokens.

3. Resumen de Contexto Sensible al Nivel

Para evitar que los historiales de conversación largos fuercen a las consultas simples hacia niveles costosos debido a los límites de la ventana de contexto, STREAM implementa una compresión diferencial. Cuando una conversación se acerca al 80% del límite de contexto de un nivel, los mensajes antiguos se comprimen en un resumen (usando el modelo local gratuito) mientras que los turnos recientes se mantienen íntegros. Esto permite que las consultas simples permanezcan en el nivel local incluso después de 40 o más turnos.

4. Modo Proxy de HPC-como-API

STREAM expone el nivel HPC como un endpoint compatible con OpenAI (/v1/chat/completions). Esto permite que aplicaciones externas accedan a la inferencia de HPC institucional sin necesidad de que los usuarios gestionen credenciales de Globus o implementen directamente el protocolo de relay. Este modo es práctico únicamente gracias a que la transmisión de doble canal reduce la latencia a niveles de sub-segundo.

Resultados Clave

El sistema fue evaluado mediante un benchmark de 1,200 consultas que abarcó diez dominios (HPC, matemáticas, física, etc.) y se midió a través de los niveles local, HPC y de la nube.

• Precisión de Enrutamiento: El juez de complejidad Llama 3.2 3B logró una precisión general del 49.0% (1.5 veces por encima del azar) y una retención en el nivel gratuito del 85.1%, manteniendo exitosamente el 85% de las consultas en los niveles gratuitos (local o HPC). La principal limitación fue la baja recuperación (recall) de las consultas de complejidad "BAJA", que a menudo se enrutaban de más al nivel "MEDIO" (un error conservador, ya que ambos son gratuitos).
• Latencia (TTFT):
  • Local: 0.26 s de mediana de Tiempo al Primer Token (TTFT).
  • HPC (Streaming): 0.54 s de mediana de TTFT. Esto representa una mejora de 21.1× sobre el modo de fallback por lotes (11.40 s), donde el TTFT equivale al tiempo total de generación.
  • Nube (Cloud): 1.68 s de mediana de TTFT.
• Throughput (Rendimiento): Tanto el modo de streaming de HPC como el de lotes lograron un throughput de generación idéntico (26.9 tok/s), confirmando que el relay no añade sobrecarga por token.
• Resumen de Contexto: En pruebas sintéticas, la síntesis de resumen evitó la actualización forzada de nivel para consultas simples ("¿Cuánto es 2+2?") incluso cuando el contexto bruto superaba los 41K tokens (turno 40), manteniendo la consulta en el nivel local.

Significación y Reivindicaciones

El artículo afirma que STREAM es el primer sistema que unifica la inferencia de LLM local, institucional (HPC) y de la nube con enrutamiento automático basado en la complejidad. Su principal significación radica en resolver el problema de la transmisión en HPC, permitiendo la entrega de tokens en tiempo real desde detrás de cortafuegos institucionales sin necesidad de VPNs o modificaciones de cortafuegos.

Al reducir el TTFT de HPC de 11.40s a 0.54s, STREAM hace que el patrón de despliegue "HPC-como-API" sea práctico para aplicaciones interactivas, un caso de uso previamente imposible debido a la latencia de procesamiento por lotes. El sistema demuestra que los recursos de GPU institucionales pueden hacerse tan accesibles como las APIs de la nube, manteniendo la privacidad de los datos y reduciendo costes. Los autores señalan que STREAM es actualmente un prototipo de investigación; el trabajo futuro implica reemplazar el juez basado en LLM con un clasificador de texto ajustado (fine-tuned) y recopilar trazas de enrutamiento de usuarios reales. Los componentes principales (relay y proxy) se han liberado como librerías de PyPI de dominio agnóstico (streamrelay y hpc-as-api).