Servir un modelo de decisión como Jev con vLLM recalcula el mismo contexto una vez por cada pregunta. Flide lo calcula una sola vez y, según el proyecto, responde hasta 9,5 veces más rápido que vLLM y SGLang sin cambiar las respuestas.
Estado al 9 de noviembre de 2026: la versión actual en PyPI es la 0.1.10, publicada ese mismo día. El proyecto ha lanzado una versión nueva cada pocos días desde la 0.1.0 (24 de octubre), y la lista de modelos compatibles crece con cada una.
Flide es un servidor de inferencia open source (Apache-2.0) para decision models: modelos que leen un estado y responden preguntas tipadas sobre él con una probabilidad para cada opción, en lugar de generar texto. Se instala desde PyPI y lo firma un equipo de la Universidad Nacional de Singapur y de la Universidad de Oxford, que lo describe en el paper Flide: Accelerating Decision Inference with Exact State Forking (arXiv 2610.42148). Se presentó en Hacker News el 9 de noviembre.
Este artículo se basa en el README, la documentación, el paper y las respuestas del equipo en Hacker News. No lo hemos ejecutado: Flide necesita una GPU NVIDIA, y todas las cifras de rendimiento que verás son del propio proyecto.
¿Qué es un modelo de decisión como Jev?
Un modelo de decisión recibe un estado (un ticket, una conversación, la trayectoria de un agente) y varias preguntas sobre él, y devuelve una distribución de probabilidad sobre las opciones de cada pregunta en una sola pasada. Nunca escribe texto, así que su salida se conecta directamente a un umbral: derivar el ticket, bloquear el comando, escalar a un humano.
El modelo cerrado Jev, de TypeSafe, creó la categoría; explicamos cómo funciona en Jev de TypeSafe: cómo funciona la IA que toma decisiones sin generar texto. Flide sirve la misma API de Jev, /v1/systemone, pero con modelos abiertos en tu propia GPU: es, en la práctica, una forma de tener un Jev open source autoalojado.
¿Por qué vLLM y SGLang son lentos con modelos de decisión?
Porque están diseñados para generar texto, donde la unidad de trabajo es una secuencia lineal, y una petición de decisión es un árbol: un estado compartido del que cuelgan muchas preguntas independientes.
Según el paper de Flide:
- vLLM y SGLang tratan cada pregunta como un prompt propio, así que el contexto compartido se renderiza, tokeniza y planifica otra vez por cada pregunta. La versión más reciente de vLLM calcula el contexto compartido una sola vez, pero cada pregunta sigue ejecutándose como una secuencia aparte que se reanuda desde el prefix cache.
- En modelos híbridos como Qwen3.5, cuyas capas Gated DeltaNet comprimen todos los tokens anteriores en un único estado recurrente, esa caché solo puede restaurar el estado en los límites de bloque. Cada pregunta vuelve a calcular los tokens que quedan después del último límite.
- El multi-item scoring de SGLang pone todas las preguntas en una misma secuencia, con un token delimitador delante de cada una. Es rápido, pero cada pregunta lee ese token extra, lo que desplaza sus probabilidades respecto a hacerla sola.
En el hilo de Hacker News, un desarrollador comentó que obtuvo aceleraciones parecidas modificando vLLM para sus propios experimentos con modelos de decisión. La respuesta del mantenedor: eso funciona con full attention, pero no con las capas Gated DeltaNet de Qwen3.5, y por eso construyeron un motor nuevo. Si vienes comparando vLLM vs SGLang, esta es la pieza que falta en esa comparación: ninguno de los dos está pensado para este tipo de carga.
¿Cómo funciona el state forking de Flide?
Flide calcula el estado compartido una sola vez y ejecuta todas las preguntas juntas en una única pasada hacia delante (forward pass), mientras cada pregunta calcula exactamente lo mismo que si se hiciera sola.
En la práctica:
- En las capas de atención, una máscara hace que cada pregunta solo vea el estado y a sí misma, y cada pregunta recibe los índices de posición que tendría justo después del estado.
- En las capas Gated DeltaNet, el cálculo se hace en dos llamadas: una sobre los estados y otra sobre todas las preguntas, cada una partiendo del estado recurrente exacto de su propia petición.
- Toda la pasada se ejecuta como un CUDA graph pregrabado. Una petición de decisión corta ocupa solo milisegundos de GPU, así que lanzar los kernels uno a uno dominaría el tiempo total.
Es la misma idea que el prefix caching o la reutilización del KV cache, llevada al extremo: el contexto común no se reanuda desde una caché, sino que se calcula dentro de la misma pasada que las preguntas.
El paper afirma que, en aritmética exacta, cada respuesta es idéntica a la de la pregunta hecha por separado. En coma flotante, las diferencias quedan en el nivel del redondeo, y el paper sitúa a Flide como el motor más cercano a una referencia en float32 de los que comparó. Si necesitas exactamente los mismos bits para la misma petición sin importar la carga del servidor, existe el modo opcional --batch-invariant, a cambio de algo de velocidad.
¿Cuánto más rápido es Flide que vLLM?
Depende de cuántas preguntas compartan un mismo estado. La cifra de 9,5 veces corresponde a Qwen3.5-0.8B sobre QuALITY, donde un artículo largo (unos 5.800 tokens) lleva 18 preguntas de media, según explicó el mantenedor en Hacker News.
Con una sola pregunta por petición no hay nada que compartir, y la ganancia viene únicamente de un menor coste por petición. El mantenedor la sitúa entre un empate técnico (modelo de 27B con una entrada larga) y más de 3 veces (modelo pequeño con una entrada corta).
La tabla del README da la aceleración por familia de modelos como latencia mediana en una H200, frente al más rápido entre vLLM y SGLang en el caso de los modelos de chat. Algunas filas:
| Modelo | DI | MultiRC | QuALITY |
|---|---|---|---|
| Qwen3.5 (media entre tamaños) | 2,1× | 4,8× | 1,3× |
| Gemma 4 (media entre tamaños) | 1,3× | 1,7× | 1,0× |
| OneJev (frente a qev) | 6,8× | 7,3× | 4,7× |
| Senova | 3,1× | 28,1× | 1,2× |
| Clef | 1,3× | 1,0× | 1,0× |
DI es el Decision Index; MultiRC tiene unas 48 preguntas por párrafo de media. La conclusión práctica: pon todo lo compartido en el estado y haz todas tus preguntas en una sola petición. Ese es el caso para el que Flide está diseñado.
¿Cómo instalar Flide y enviar tu primera petición?
Crea un entorno con Python 3.12 e instala desde PyPI:
uv venv -p 3.12 && source .venv/bin/activate
uv pip install flide torchvision
Arranca un servidor con cualquier modelo compatible. Cualquier modelo de chat basado en Qwen3.5 o Gemma 4 funciona tal cual:
flide serve --model Qwen/Qwen3.5-4B
O el modelo de decisión del propio proyecto:
flide serve --model OmniJev/OneJev1.6-0.8B
Por defecto, flide serve escucha en todas las interfaces de red, en el puerto 8000. Añade --host 127.0.0.1 si quieres que solo sea accesible desde tu máquina.
Después, envía una petición a /v1/systemone:
curl http://localhost:8000/v1/systemone -H "Content-Type: application/json" -d '{
"state": "Order #1182 arrived with a cracked screen. The customer asks for a refund and attached two photos.",
"questions": {
"action": {"type": "choice", "instructions": "What should support do next?",
"criteria": {"refund": "refund the order", "replace": "send a replacement", "escalate": "ask a human"}},
"urgent": {"type": "noul", "instructions": "Does this need a reply within the hour?"}
}
}'
Cada respuesta incluye la probabilidad de cada opción, lista para aplicarle un umbral.
¿Qué opciones de Flide importan para agentes?
El README documenta cuatro:
| Opción | Qué hace |
|---|---|
--session-cache-gb 40 |
guarda los estados de peticiones anteriores, así el siguiente paso de un agente solo calcula lo nuevo |
--batch-invariant |
los mismos bits para una petición sin importar con qué otras se agrupe, a cambio de algo de velocidad |
--quantize fp8 |
Qwen3.5 en FP8 en GPU Ada, Hopper y Blackwell |
--frontends 2 |
HTTP, renderizado y tokenización en procesos separados, para muchos clientes |
--session-cache-gb es la que importa en los bucles de agentes: el estado de cada paso es casi el del paso anterior más unos pocos tokens nuevos, y Flide se reanuda desde un punto de control en lugar de recalcular todo el historial.
¿Qué modelos de decisión puedes servir con Flide?
Al 9 de noviembre de 2026, el README lista más de 30 familias. Entre ellas están los modelos de chat Qwen3.5 y Gemma 4, el OneJev del propio proyecto y modelos de decisión como Open-Jev, Kev, pplx-decider de Perplexity, Clef de Cloudflare, Intern-Decision y KnowLine. Los adaptadores LoRA se sirven tal como se publican, y el comando flide verify comprueba el state forking exacto con tu propio modelo y tus propias peticiones.
¿Flide funciona en Windows? ¿Necesitas GPU?
Sí necesitas GPU: Flide es un motor CUDA para GPU NVIDIA, y su documentación no describe ningún modo para CPU. En cuanto a Windows, el mantenedor indicó en Hacker News que el equipo solo lo ha probado en Linux y que en Windows quizá necesites WSL2. También dijo que una RTX 3050 es suficiente para el modelo de 0.8B.
¿Flide, Ollaya o vLLM: cuál usar?
Flide y Ollaya ejecutan modelos de decisión abiertos en local detrás de la API de Jev, pero resuelven problemas distintos, y vLLM sigue teniendo su lugar.
- Ollaya copia el flujo de Ollama: un binario,
pullyrun, grafos ONNX y CPU en cualquier plataforma, incluidos Windows y Mac. Es la forma sencilla de poner un paso de decisión delante de un agente en un portátil. - Flide es un motor de inferencia para GPU, pensado para modelos decodificadores (Qwen3.5, Gemma 4 y sus fine-tunes) y optimizado para el caso en que muchas preguntas comparten un mismo estado.
- vLLM sigue siendo la herramienta para generar texto. Si ya lo usas para servir modelos generativos, como en nuestra guía para servir modelos open source en tu propio hardware con vLLM, no lo cambies: Flide solo es una vLLM alternative para cargas de decisión.
Si estás prototipando en tu máquina, Ollaya. Si sirves modelos de decisión en una GPU NVIDIA y estás pagando cada token recalculado, Flide.
¿Para quién tiene sentido Flide hoy?
Tres perfiles le sacan más partido:
- Equipos que ya sirven modelos de decisión con vLLM o SGLang, sobre todo con Qwen3.5.
- Quien construye agentes y hace varias preguntas sobre la misma trayectoria en cada paso.
- Quien necesita la misma respuesta para la misma petición, sin importar la carga del servidor.
Tiene tres semanas de vida y cambia cada pocos días, así que fija la versión que instalas y ejecuta flide verify con tus propias peticiones antes de confiarle tráfico de producción.
¿Y tú? ¿Qué decisión de tu agente o de tu backend resuelve ya un modelo de decisión en lugar de un LLM que genera texto?
- En una API alojada (Jev u otra)
- En local, con Ollaya u otra herramienta
- En mi propia GPU, con vLLM, SGLang o Flide
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Jev de TypeSafe: cómo funciona la IA que toma decisiones sin generar texto