Llevaba un rato mirando la tabla de benchmarks de Janas, un motor en C puro que apareció fuerte en Hacker News, cuando me di por vencido buscando la trampa: un modelo de 80 mil millones de parámetros, archivo de 48 GB, corriendo a 37 tok/s en un laptop de 32 GB de RAM. Donde llama.cpp escribe a 2,8 tok/s, Janas escribe a 24. No es magia, es un chorro de decisiones de ingeniería bien tomadas, y varias se aplican directo a infraestrctura de VPS.
El truco: el disco es la RAM lenta, no la swap
La familia de modelos modernos tipo Mixture-of-Experts tiene una propiedad curiosa: para generar cada token solo usa una fracción de sus pesos, los «expertos» activos. La mayoría de los runtimes igual cargan todo el modelo en memoria antes de arrancar. Janas no: deja los pesos en el SSD, hace streaming de los expertos que cada token pide vía O_DIRECT (sin pasar por el page cache), y los que se repiten los va quedando en RAM como caché de expertos. Con un NVMe de ~5,7 GB/s de lectura, la cuenta sale.
La idea clave es invertir la jerarquía: en vez de tratar el disco como el último recurso cuando se acaba la RAM, lo trata como el almacén natural del modelo y usa la RAM como caché de lo caliente. Es exactamente lo que hace un CDN respecto a un origen, o un buffer pool de base de datos respecto al disco. Pero para inferencia local casi nadie lo había hecho bien hasta ahora, porque llama.cpp termina copiando y repackeando buffers que el sistema no puede devolver, y ahí se muere cuando el archivo pesa más que la memoria.
Lo que me gusta y lo que no
Me gusta que es C sin dependencias más allá de la libc. En un mundo donde «local-first» significa arrastrar un runtime de 2 GB de Python, un binario que corre en Debian 12 es refrescante. Y que el motor mide lo que hace: elige threads por sí solo, prueba configuraciones y el benchmark (janas-bench) es la salida que piden para hardware no probado, porque todo los números vienen de una sola laptop con un Core Ultra 9 185H de Intel.
Ese último punto es justamente la advertencia honesta del autor: es un experimento, no un producto. En otra máquina puede ir más lento, negarse al modelo oportuno o, peor, colgar el escritorio. Llena la memoria libre con su caché y lee el disco a fondo. En un server compartido sería una mala idea: los vecinos de ruido no perdonan un proceso que se come toda la RAM disponible. En el laptop de casa con margen de sobra, otra cosa.
Por qué esto importa más allá del benchmark
El patrón de fondo — modelos que no caben en RAM pero corren bien si el disco es rápido y el acceso está bien cacheado — se alinea con hacia dónde va el hardware: NVMe cada vez más rápido, RAM cada vez más cara. El shortage de DRAM que ya empujó incluso a traer de vuelta DDR4 no se va a resolver pronto, y alternativas así son la válvula de escape lógica para correr IA local sin comprar una workstation de 128 GB.
3 cosas que me llevo para mi pega
- Medí antes de asumir. Los números de un hardware ajeno no valen para tu caso; lo primero es correr el benchmark propio y creerle a esos números, no al README.
- Cachear lo caliente es la respuesta genérica. Streaming de pesos, buffer pools, CDN: es el mismo patrón. Cuando te enfrentes a «esto no cabe en memoria», la pregunta correcta es qué fracción realmente se usa siempre.
- Sin dependencias es una feature. Un binario en C que corre donde sea vale oro cuando tus servidores son heterogéneos y el uptime es sagrado.
Lo probé solo por encima, ojo: es un proyecto de días de vida, la API cambia semana a semana y solo lo vi funcionar en screenshots y benchmarks publicados. Pero la dirección es tan sensata que prefiero contarlo ahora a esperar seis meses.
Nota propia de la casa: esto conecta directo con lo que probamos hace un tiempo con Ollama Cloud y GLM: la pregunta siempre es la misma, dónde viven los pesos y cuánto cuesta moverlos. Ahí la nube ganaba por conveniencia; con herramientas como Janas, la balanza local empieza a moverse.
Vía Janas en GitHub, trendeando en Hacker News.
Fuente de inspiración: Janas: Run LLMs larger than RAM by streaming experts from SSD
