Superfluid propone compartir inferencia local entre agentes
Base Compute presentó el 8 de octubre Superfluid, un servidor para ejecutar modelos de lenguaje en equipos propios y atender varias solicitudes de agentes. Su propuesta reúne un planificador, almacenamiento de sesiones y una interfaz compatible con varios clientes, con el objetivo de repartir mejor los recursos de una máquina compartida.
La herramienta apunta a un problema práctico: un equipo puede ejecutar tareas largas en segundo plano mientras una persona espera una respuesta interactiva. Organizar esas solicitudes puede importar tanto como la velocidad individual del modelo. El anuncio describe un diseño y resultados medidos por el propio proveedor; no constituye una evaluación independiente.
Qué hace el servidor
El anuncio describe soporte para interfaces de OpenAI, Anthropic y Ollama, además de varios motores de inferencia: llama.cpp para archivos GGUF, MLX para directorios de ese formato y BaseRT para paquetes propios. La compatibilidad se refiere a las interfaces del servidor y no significa que los modelos o servicios de esas empresas sean idénticos.
Una aplicación que ya utiliza un formato de solicitud compatible podría conectar con un servidor local, pero aún necesita comprobar las funciones concretas que usa, el modelo elegido y el comportamiento ante errores. Cambiar el destino de una llamada no convierte automáticamente una solución alojada en una réplica funcional de un servicio remoto.
Prioridad para solicitudes interactivas
Según Base Compute, las solicitudes interactivas pueden interrumpir trabajo por lotes en el siguiente ciclo del planificador. El proveedor también describe reutilización de prefijos compartidos entre solicitudes, para evitar repetir parte del procesamiento cuando varias usan el mismo contexto inicial.
Estas dos funciones abordan problemas diferentes. La prioridad busca reducir la espera de una consulta urgente cuando hay trabajo en curso; la reutilización pretende evitar cálculos repetidos. Su valor real depende del tamaño de los contextos, las cargas simultáneas y los recursos disponibles. Una prueba de una sola solicitud no basta para conocer el comportamiento con varios agentes.
Recuperación de sesiones y sus límites
El proveedor afirma que el servidor registra los tokens y puede retomar sesiones después de la caída de un proceso de trabajo o un reinicio. Esta es una capacidad descrita por el proyecto, no una garantía de que toda acción externa de un agente se ejecute una sola vez.
La distinción es importante si un agente usa herramientas. Recuperar una conversación no equivale a revertir o verificar una operación realizada en otro sistema. Antes de confiar en una reanudación, el responsable debería probar cortes controlados y revisar cómo se identifica cada operación y cómo se reconcilian sus resultados.
El README consultado el 28 de octubre advierte que Superfluid es anterior a la versión 1.0 y que opciones, protocolos y formatos en disco pueden cambiar entre versiones. Por ello, una integración debería registrar su versión y tener un plan de actualización y recuperación acorde al entorno.
La prueba de rendimiento no es una promesa universal
En su anuncio, Base Compute presenta una medición en un Mac con procesador Apple M5 Pro y el modelo Qwen3.8 de 27 mil millones de parámetros en cuatro bits. En un escenario de una consulta de chat detrás de ocho agentes, informa un tiempo hasta el primer token de 1,5 segundos para Superfluid, frente a 291 segundos para llama-server en su comparación.
Esos números proceden del proveedor y corresponden a esa configuración de prueba; no prueban que todas las cargas sean más rápidas ni describen necesariamente el tiempo de una respuesta completa. Para evaluar una instalación distinta haría falta repetir una carga comparable, fijar versiones, motores, modelo y concurrencia y observar también el consumo de memoria.
El resultado puede ser útil como hipótesis para una prueba local, no como una promesa de velocidad en otra máquina. También conviene distinguir latencia de la primera respuesta, velocidad de generación sostenida y número de solicitudes completadas: cada métrica responde a una pregunta diferente.
Distribución, licencias y seguridad
El proyecto describe un modo distribuido con una máquina principal y otros nodos, conectados mediante un enlace cifrado. La máquina principal asigna sesiones completas a los nodos. El cifrado del enlace es una propiedad declarada de esa comunicación, no una certificación independiente de seguridad del sistema completo.
El README dice que, por defecto, el servidor escucha en la interfaz local y no solicita clave salvo configuración. Advierte que se revise la seguridad antes de exponerlo en una red. La guía específica de seguridad no pudo abrirse en esta revisión; no se debe interpretar el valor predeterminado local como protección suficiente para un servicio accesible a terceros.
El repositorio identifica Apache 2.0 para Superfluid y aclara que BaseRT es un producto separado con licencia propia. Las condiciones de los modelos y otros componentes también deben revisarse individualmente: la licencia del servidor no concede automáticamente derechos sobre cada modelo que pueda ejecutar.
Una evaluación responsable empieza por conocer qué archivos quedan en disco, quién puede acceder al proceso y qué datos viajan entre dispositivos. Este artículo no instaló el software, no comprobó su aislamiento ni ejecutó pruebas de recuperación o de red.
Preguntas frecuentes
¿Superfluid garantiza que todos los agentes respondan más rápido?
No. El proveedor publica pruebas concretas en su propio equipo. La mejora para otra carga debe medirse con sus modelos, versiones y recursos, y no puede deducirse de una sola cifra.
¿El servidor y todos los modelos tienen la misma licencia?
No. El repositorio señala Apache 2.0 para el servidor y una licencia separada para BaseRT. Los modelos y dependencias pueden tener condiciones distintas que el usuario debe comprobar.
¿El registro de sesiones garantiza que una compra no se repita?
No. La reanudación de una sesión y la confirmación de una acción externa son problemas distintos. Una aplicación debe controlar y verificar sus propias operaciones antes de reintentarlas.
¿Es seguro exponer el servidor en internet con sus valores predeterminados?
No debe suponerse. El README describe escucha local sin clave por defecto y pide revisar la seguridad antes de conectarlo a una red. La revisión de una configuración concreta requiere sus controles y documentación vigentes.
Fuente: anuncio de Base Compute y README del proyecto.
