Spinf-serve: 491 preguntas por segundo en una GPU

Qué es spinf-serve y por qué aparece ahora

491 preguntas por segundo en una sola GPU de 24 GB. Ese es el número que el equipo de spinf pone sobre la mesa al publicar spinf-serve, un motor de inferencia open source (licencia Apache 2.0) diseñado para una tarea muy concreta: leer un contenido una sola vez y responder decenas de preguntas sobre él en la misma pasada.

La diferencia con un servidor de chat es de fondo, no de matiz. Aquí nada se genera salvo que lo pidas explícitamente: cada respuesta es una probabilidad sobre las opciones que tú defines, no un párrafo. Si tu producto necesita decidir si un mensaje es billing o technical, si un cliente pide un reembolso, o si un listado de producto cumple una política, este motor está construido exactamente para eso.

El proyecto nació de una necesidad propia: el equipo construyó el motor para su trabajo diario, un índice de mercado que se lee de millones de artículos de noticias, donde a cada artículo se le hacen decenas de preguntas estrechas y calibradas. Los servidores pensados para chat releen el contenido por cada pregunta y generan token a token, lo que vuelve ese trabajo lento y caro.

Cómo funciona: una lectura, muchas preguntas

La mecánica central es simple de entender y difícil de replicar. En lugar de procesar cada pregunta como una consulta independiente, spinf-serve convierte cada pregunta en una rama de una única lectura del contenido y empaqueta muchos contenidos en una sola pasada hacia adelante.

En la práctica, esto significa que el costo de agregar la pregunta número 57 a un mismo texto es marginal: solo paga sus propios tokens, no una relectura completa. Los placeholders permiten además convertir una plantilla en una grilla de preguntas, lo que multiplica la cobertura sin multiplicar el costo.

La respuesta de la API devuelve, por cada opción, tres valores que conviene entender:

• p: la probabilidad entre las opciones que tú diste.
• floor_p: la misma pregunta sin contenido, es decir, el sesgo base del modelo. La resta p - floor_p es lo que el contenido realmente aportó.
• residual: la probabilidad que se fue a palabras fuera de tus opciones.

Ese floor_p es el detalle que separa a este motor de un clasificador improvisado. Sin una línea base, no puedes saber si el modelo está leyendo el texto o simplemente respondiendo por inercia.

Qué tan rápido es frente a vLLM

El propio proyecto publicó sus benchmarks, y son la parte más citable de la propuesta. Medido en una RTX 4090 con Gemma 4 12B en fp8, sobre 24 artículos de Wikinews de unos 470 tokens cada uno y 56 preguntas de dos opciones por artículo (1.344 preguntas en total), comparado contra vLLM 0.26 con prefix caching y 128 requests en vuelo:

• 491 preguntas por segundo frente a 200 de vLLM.
• 11.200 tokens de trabajo por segundo frente a 4.600.
• Las 1.344 preguntas resueltas en 2,7 segundos frente a 6,7 segundos.

El matiz importante es que vLLM ya reutiliza cada artículo entre sus 56 preguntas gracias al prefix cache. Lo que no puede hacer es responderlas en una sola pasada: ejecuta 1.344 requests de un token, mientras spinf-serve dispone las 56 preguntas como ramas de una lectura y empaqueta los 24 artículos en dos pasadas de 16k tokens. La brecha crece con el número de preguntas por contenido, que es justo el escenario de la moderación y el scoring masivo.

En números de operación real, el proyecto reporta que el pack spinf/moderation (106 preguntas por mensaje, 22 categorías) puntúa alrededor de 20.000 mensajes por hora por cada 4090, y que un artículo de noticias con 74 preguntas se lee a casi 700 preguntas por segundo.

Qué modelos y packs incluye

El servidor corre sobre Linux con una GPU NVIDIA de 24 GB con tensor cores fp8 (Ada, Hopper o Blackwell: RTX 4090, 5090, L4, L40S, RTX 6000 Ada, H100), driver con CUDA 13 y Python 3.12. Las tarjetas Ampere funcionan con pesos int8.

Los checkpoints publicados son cuatro:

• spinf/gemma-4-12b-fp8 (por defecto), basado en Google Gemma 4 12B, corre en una GPU de 24 GB y lee texto, imágenes, audio y video.
• spinf/gemma-4-31b-fp8, en una GPU de 48 GB, texto, imágenes y video.
• spinf/qwen3.8-27b-int4, en 24 GB, texto, imágenes y video.
• spinf/pplx-decider-v1-27b-int4, un modelo de decisión con readout de 255 códigos, solo texto y solo scoring.

Sobre los prompt packs: un pack es un archivo que reúne las preguntas, cómo se presenta el contenido al modelo, cómo las respuestas se convierten en scores y cómo esos scores se convierten en una decisión. El servidor los precarga y una request nombra uno, recibiendo de vuelta las categorías y la decisión del pack junto a las preguntas propias, todo desde la misma lectura. Los packs oficiales están en el repositorio spinf-prompts y se cargan por defecto.

¿Qué significa esto para tu startup?

Si tu producto procesa volumen —soporte, moderación, clasificación de leads, enriquecimiento de catálogos, análisis de reseñas— el cuello de botella casi nunca es la calidad del modelo, sino el costo por ítem. Este motor ataca ese punto exacto.

Dos acciones concretas que puedes evaluar esta semana:

• Mide tu costo real por decisión, no por token. Si hoy haces N llamadas a un LLM por cada documento, calcula cuántos tokens gastas releyendo el mismo texto. Con una arquitectura de una lectura y muchas preguntas, ese número puede caer de forma drástica. El benchmark del proyecto sugiere una diferencia de más de 2x en throughput, pero verifícalo con tu propio tráfico.
• Empieza por un pack, no por un modelo. Antes de armar tu propio set de preguntas, prueba un pack ya calibrado (moderación, triage, listados de producto, reseñas) y mide qué tan bien separa tus casos reales. Ajustar umbrales sobre datos propios es más rápido que entrenar o afinar nada.

Un punto de arquitectura que vale la pena retener: la invariancia de batch. Con los checkpoints fp8, los scores de un contenido son idénticos bit a bit ya sea que se procese solo o empaquetado con miles de otros, entre llamadas, días y servidores. Para un founder, eso significa que un umbral calibrado hoy sigue siendo válido mañana, algo que no es trivial cuando el batch cambia el resultado.

Lo que todavía no está resuelto

El proyecto está en versión 0.1. El motor (scoring, extracción, generación, media, invariancia de batch y los dos stacks de modelos) se declara completo y probado contra referencias grabadas, y el servidor habla la API pública del servicio hosteado. Lo que falta está listado en la propia documentación.

Hay además un costo que conviene no ignorar: los slots de extracción agregan trabajo de decodificación. Según el proyecto, un slot buscado cuesta aproximadamente lo que 200 a 600 tokens de scoring, y uno generado hasta unos 2.000, aunque comparten la lectura.

No se encontraron datos adicionales verificables en la búsqueda web sobre el proyecto, su financiación o su tracción: los números citados provienen íntegramente del repositorio oficial y de sus benchmarks publicados.

Fuentes

• spinf-serve (repositorio oficial) (fuente original)