Diseñando Flux Engine: un único runtime para todos los productos
Una mirada a las decisiones de arquitectura tras nuestro runtime de inferencia compartido en el dispositivo — y a las restricciones que lo moldearon.
Un runtime, no un wrapper
Construir una app en el dispositivo es difícil. Construir cinco lo es más. Construir cinco que compartan una base técnica coherente, publiquen al mismo ritmo y no regresen en batería — eso es un problema de runtime.
Flux Engine es nuestra respuesta. Es una capa fina y opinada sobre los mejores runtimes open source de cada carril — voz (whisper.cpp / faster-whisper), visión (llama.cpp / mlx-vlm), lenguaje (llama.cpp / MLC-LLM, executorch en Android) — coordinada por un único scheduler que sabe qué hay en memoria, qué hace el usuario y qué puede sostener el dispositivo.
Las tres restricciones
1. Latencia de arranque en frío
Los modelos viven en disco la mayor parte del tiempo. El usuario no. Flux Engine pre-calienta el modelo más probable a partir de los patrones de uso y un pequeño clasificador local. El propio clasificador es un MLP de 50 KB — barato de ejecutar en cada despertar.
2. Throughput sostenido en NPUs pequeñas
Nunca lanzamos cargas paralelas que compitan por el mismo acelerador. El scheduler está basado en colas, conoce las prioridades y cede el paso al app en primer plano. El stream ASR tiene preferencia sobre un resumen en segundo plano; el toque-traducir tiene preferencia sobre una pasada de indexación.
3. Degradación elegante cuando hay poca memoria
Si el usuario está editando vídeo 4K, no vamos a OOM su teléfono para correr un resumen. El motor reporta una señal blanda de "capacidad restante" que los productos respetan — pueden bajar a un modelo más pequeño, posponer al fondo o mostrar un "listo cuando se enfríe".
Lo que Flux Engine realmente expone
Un puñado de abstracciones C++ y bindings finos a Swift / Kotlin / Rust:
FluxSession— sesión de inferencia de larga vida ligada a un modelo + dispositivo.FluxStream— salida incremental, cancelable a mitad de token.FluxBudget— reporte de capacidad consciente del dispositivo.FluxRouter— elige el modelo correcto según la gama del dispositivo, batería, estado térmico y preferencia del producto.
Eso es todo. Cinco primitivas. Cada producto Flux* se construye sobre ellas.
Lo que nos da
Un bug fix, una mejora de rendimiento, una mejora de cuantización — cinco productos mejoran a la vez. Un fix de regresión en el scheduler — cinco productos dejan de disparar la batería a la vez. La cuenta económica de un runtime compartido, para un equipo de nuestro tamaño, es abrumadora.
Lo que erramos
- Sobreinvertimos en un compilador de grafos los primeros seis meses. Ganaron los loaders ajustados a mano.
- Subinvertimos en profiling. Lo reescribimos en el mes nueve.
- Asumimos un único esquema de cuantización para todos los productos. Hoy enviamos mezclas por producto.