NightRun lleva la ejecución local de modelos de lenguaje a un terreno bastante más cercano al firmware que al escritorio tradicional. El proyecto arranca directamente desde una unidad USB mediante UEFI, carga el modelo completo en RAM y ejecuta la inferencia sobre CPU sin Linux, Windows, kernel convencional ni pila de red. No pretende sustituir a Ollama o llama.cpp para el uso cotidiano, sino construir una máquina dedicada donde prácticamente todo el software existente entre el firmware y el LLM desaparece.
Las claves técnicas de NightRun en 30 segundos
- NightRun es una aplicación EFI
no_stdescrita en Rust que permanece sobre UEFI Boot Services. - Carga modelos cuantizados de entre 1,3 y 2,4 GB completamente en RAM y después bloquea nuevas lecturas del almacenamiento.
- Ejecuta inferencia exclusivamente sobre CPU mediante AVX2 en x86_64 y NEON en Raspberry Pi 5.
- Implementa Llama 3.2, Qwen3 y Granite 4.1 dense, con validación frente a llama.cpp.
- No incluye kernel convencional, procesos de usuario, servicios, shell, navegador ni pila TCP/IP.
La precisión sobre UEFI es importante. NightRun no es bare metal en el sentido estricto del término. El proyecto no ejecuta ExitBootServices(), por lo que mantiene disponibles los servicios del firmware durante toda la sesión. UEFI proporciona funciones necesarias para manejar pantalla, teclado, almacenamiento y arranque de los diferentes núcleos de CPU.
Es una decisión deliberada. Desarrollar controladores propios para USB HID, xHCI, almacenamiento, gráficos y las peculiaridades de miles de placas base convertiría el proyecto en algo mucho más próximo a escribir un sistema operativo.
NightRun utiliza el firmware como capa de plataforma y construye encima su propio cargador de modelos, motor de inferencia, gestión de memoria, tokenizer, interfaz gráfica y ejecución multinúcleo.
De BOOTX64.EFI al primer token sin arrancar un kernel
En un PC x86_64 el firmware ejecuta directamente BOOTX64.EFI. En Raspberry Pi 5 el punto de entrada es BOOTAA64.EFI.
Desde ahí comienza una secuencia bastante diferente a la de cualquier instalación habitual de IA local:
- NightRun activa el estado SIMD necesario para la CPU.
- Inicializa framebuffer y teclado.
- Arranca los núcleos disponibles mediante los servicios MP de UEFI.
- Detecta la memoria.
- Carga el modelo completo en RAM.
- Comprueba su integridad mientras realiza la lectura.
- Sella el acceso posterior al almacenamiento.
- Inicializa tokenizer y plantilla de conversación.
- Reserva KV cache y memoria de trabajo.
- Arranca el chat.
El runtime utiliza UEFI Graphics Output Protocol (GOP) para acceder al framebuffer y dibuja su propia interfaz. No existe un compositor, terminal de Linux o servidor gráfico escondido debajo.
Lo mismo sucede con el teclado. NightRun utiliza los servicios proporcionados por el firmware para recibir la entrada USB, pero la edición del texto, el historial y la interfaz del chat pertenecen al propio proyecto.
| Capa | Ollama sobre Linux | NightRun |
|---|---|---|
| Firmware | UEFI | UEFI |
| Kernel | Linux | No |
| Drivers del SO | Sí | Servicios UEFI |
| Userspace | Sí | No |
| Servicios en segundo plano | Sí | No |
| Runtime LLM | Ollama/llama.cpp | NightRun |
| Modelo | RAM + posible I/O | RAM |
| Red | Disponible | No implementada |
| Interfaz | Terminal/web/app | Framebuffer propio |
La arquitectura explica por qué describirlo simplemente como «Ollama sin Internet» se queda corto.
El modelo se carga una vez y el almacenamiento desaparece de la ejecución
Otra diferencia está en cómo NightRun trata el modelo.
El instalador parte de un archivo GGUF compatible, inspecciona su arquitectura y lo convierte al formato propio .nrm. Este contenedor está diseñado específicamente para que los tensores puedan utilizarse directamente desde la representación cargada en memoria.
Durante el arranque, el archivo se lee en bloques y NightRun calcula simultáneamente sus CRC-32, evitando una segunda pasada completa únicamente para verificar la integridad.
Una vez terminado el proceso, los pesos permanecen en RAM.
El runtime impone entonces una regla: cualquier intento posterior de lectura del almacenamiento produce un fallo. La inferencia no vuelve a consultar el USB o la microSD.
También se reserva previamente toda la memoria necesaria.
El diseño incluye regiones para los pesos, KV cache, espacio de trabajo del prefill, memoria temporal del decode y buffers gráficos. Una función calcula previamente el tamaño de la arena de memoria y, si la máquina no dispone de suficiente RAM, el arranque falla antes de comenzar la conversación.
El bucle de generación realiza cero asignaciones de heap, según la documentación del proyecto.
La consecuencia práctica es que la RAM determina qué modelos pueden utilizarse.
Un Llama 3.2 1B de 1,3 GB requiere una máquina con unos 4 GB. Llama 3.2 3B y Granite 4.1 3B necesitan alrededor de 6 GB, mientras Qwen3 4B requiere 8 GB.
Inferencia CPU con pesos cuantizados utilizados directamente
NightRun no tiene actualmente soporte para GPU.
Su motor está orientado a inferencia cuantizada sobre CPU y utiliza los pesos sin generar previamente una copia completa descomprimida en FP32.
En x86_64 implementa kernels específicos para AVX2, FMA y F16C. En ARM utiliza NEON y dispone de una ruta basada en sdot para procesadores compatibles como el Cortex-A76 de Raspberry Pi 5.
Las cuantizaciones implementadas son Q8_0, Q4_K y Q6_K, además de determinados tensores F32.
El proyecto explica además una peculiaridad que suele perderse cuando se habla de archivos GGUF: Q4_K_M no significa que absolutamente todos los tensores estén almacenados como Q4_K. Un modelo puede mezclar Q4_K, Q6_K y F32 dependiendo del tensor. NightRun conserva esas cuantizaciones durante la conversión.
El prefill procesa hasta 64 tokens por pasada, mientras el decode trabaja token a token.
Esto importa porque ambas fases tienen perfiles diferentes. El procesamiento inicial puede reutilizar pesos entre varios tokens, mientras durante la generación interactiva el rendimiento queda mucho más condicionado por el ancho de banda de memoria.
NightRun también reconoce una consecuencia habitual de los transformers: la generación se ralentiza a medida que aumenta el contexto porque la atención tiene que recorrer un KV cache cada vez mayor.
Llama, Qwen y Granite, pero no cualquier GGUF
NightRun no intenta ofrecer compatibilidad universal.
Actualmente implementa tres familias: Llama 3.2, Qwen3 y Granite 4.1 en su arquitectura transformer convencional.
| Modelo validado | Cuantización | Tamaño .nrm | RAM objetivo |
|---|---|---|---|
| Llama 3.2 1B Instruct | Q8_0 | 1,3 GB | 4 GB |
| Llama 3.2 3B Instruct | Q4_K_M | 1,9 GB | 6 GB |
| Granite 4.1 3B | Q4_K_M | 2,0 GB | 6 GB |
| Qwen3 4B Instruct 2507 | Q4_K_M | 2,3 GB | 8 GB |
Las variantes híbridas SSM/MoE de Granite se rechazan explícitamente durante la conversión. Añadir una arquitectura nueva requiere implementar su ejecución y validarla, no simplemente incorporar su nombre al catálogo.
Hay bastante trabajo técnico detrás de esta restricción.
Qwen3, por ejemplo, utiliza una disposición RoPE diferente a Llama, normalización RMSNorm específica para Q/K y una anchura de atención distinta de la dimensión oculta. NightRun implementa estas diferencias en lugar de intentar resolverlas mediante una capa genérica.
El tokenizer recibe un tratamiento parecido.
Las plantillas de conversación se comparan token por token con apply_chat_template de Hugging Face y existen pruebas específicas para evitar que texto introducido por el usuario pueda interpretarse accidentalmente como tokens de control.
La referencia de corrección es llama.cpp
Uno de los aspectos técnicos más interesantes del proyecto es cómo intenta comprobar que eliminar tantas capas no altera el resultado del modelo.
NightRun utiliza llama.cpp como referencia para la generación greedy.
Para las familias compatibles, los cambios en el motor deben mantener la generación token por token respecto a la referencia. Los kernels escalares sirven a su vez para comprobar las implementaciones vectorizadas AVX2 y NEON.
El proyecto también comprueba que el prefill por lotes genere los mismos logits y KV cache que procesar los tokens secuencialmente.
Esto no demuestra que NightRun esté libre de errores, pero proporciona una metodología reproducible para detectar divergencias en un motor de inferencia desarrollado prácticamente desde cero.
El propio proyecto evita además una afirmación tentadora: no asegura ser globalmente más rápido que llama.cpp.
Sus benchmarks publicados muestran aproximadamente 20 tokens por segundo durante el decode de Llama 3.2 1B sobre QEMU/KVM con ocho núcleos y AVX2. Granite 4.1 3B ronda 13-14 tokens por segundo y Qwen3 4B unos 10-11.
En Raspberry Pi 5, Granite 4.1 3B alcanzó 3 tokens por segundo en la prueba publicada, aunque esa medición precede a los nuevos kernels sdot.
La documentación estima que el decode puede ser comparable con llama.cpp en determinadas condiciones, mientras el prefill queda entre 1,15 y 1,4 veces por detrás.
El objetivo no es ganar un benchmark. El experimento consiste en comprobar dónde puede ejecutarse el modelo.
Sin TCP/IP: el aislamiento forma parte de la arquitectura
Una máquina con Ollama también puede desconectarse físicamente de Internet. Desde una perspectiva práctica puede ofrecer un aislamiento excelente si se configura correctamente.
NightRun adopta una decisión más radical: no existe una pila de red dentro del runtime.
No hay navegador, demonios, actualizaciones automáticas, telemetría ni proceso capaz de abrir accidentalmente una conexión TCP porque el software necesario para hacerlo no está implementado.
Eso reduce considerablemente la superficie de software activa durante una sesión, aunque no convierte automáticamente la máquina en un dispositivo invulnerable.
UEFI sigue formando parte de la cadena de confianza. También importan el origen del modelo, la imagen generada, el ordenador utilizado para prepararla y el propio código de NightRun.
Por eso el proyecto resulta especialmente interesante desde la arquitectura de sistemas, más que como una afirmación absoluta de seguridad.
Un proyecto de IA que también fue construido con IA
NightRun añade otra peculiaridad: sus responsables indican que la mayor parte del código fue escrita utilizando Claude Code con el modelo Fable 5.
El dato resulta especialmente llamativo por el tipo de software desarrollado.
No se trata de generar una aplicación web convencional. El repositorio contiene código para UEFI, formatos binarios, SIMD, gestión de memoria, tokenización, inferencia cuantizada, framebuffer y un instalador que escribe directamente dispositivos de almacenamiento.
Precisamente por eso los responsables insisten en la validación mediante implementaciones de referencia, comparación con llama.cpp, pruebas del parser y controles del instalador.
NightRun continúa siendo experimental. Requiere UEFI, Secure Boot desactivado, modelos que entren completamente en RAM y una CPU razonablemente moderna si se quiere obtener un rendimiento interactivo. La cobertura de hardware x86_64 real todavía es limitada y diferentes implementaciones de firmware pueden generar incompatibilidades.
Pero técnicamente plantea una pregunta interesante sobre el futuro de la IA local.
Hasta ahora se ha intentado hacer cada vez más sencillo ejecutar un LLM dentro del sistema operativo. NightRun explora la dirección contraria: eliminar el sistema operativo convencional y convertir temporalmente todo el ordenador en un appliance dedicado al modelo.
El resultado no pretende competir con la comodidad de Ollama. Es otra categoría: un runtime de inferencia que cabe en un USB, arranca desde firmware, mete los pesos en RAM y después trabaja sin disco ni red.
Para determinados experimentos de privacidad, sistemas aislados y edge computing, esa diferencia puede ser bastante más interesante que conseguir unos cuantos tokens por segundo adicionales.
Fuente: Noticias inteligencia artificial
