NightRun plantea un experimento especialmente interesante para administradores de sistemas y desarrolladores: arrancar un ordenador directamente en un modelo de lenguaje sin cargar Linux, Windows ni un sistema operativo convencional. El firmware UEFI inicia una aplicación escrita en Rust, el modelo se copia completamente a RAM, el almacenamiento queda bloqueado para posteriores lecturas y comienza la inferencia sobre CPU. No hay shell, systemd, contenedores, navegador, procesos de usuario ni siquiera una pila de red.
Las claves técnicas de NightRun en 20 segundos
- NightRun es una aplicación EFI
no_stdescrita en Rust que permanece sobre UEFI Boot Services. - Ejecuta Llama 3.2, Qwen3 y Granite 4.1 dense directamente sobre CPU.
- Los modelos cuantizados se cargan completos en RAM antes de iniciar el chat.
- No incorpora kernel convencional, filesystem activo durante la inferencia ni TCP/IP.
- Su generación greedy se valida token por token frente a llama.cpp.
Para un sysadmin acostumbrado a desplegar Ollama mediante Docker, una máquina virtual o un servicio de Linux, la diferencia es considerable. En NightRun no existe un sistema anfitrión que ejecute el runtime de IA. El runtime es prácticamente todo el software que queda funcionando sobre el firmware.
Eso reduce las capas de software, pero también elimina muchas de las comodidades que normalmente se dan por hechas. No hay SSH para entrar en la máquina, journalctl para consultar registros, apt para instalar un paquete ni un servicio que reiniciar. Tampoco CUDA, ROCm o una API HTTP a la que conectar aplicaciones.
Es un appliance de IA deliberadamente limitado a una tarea.
UEFI hace de capa de hardware, pero NightRun no es bare metal puro
La arquitectura necesita una precisión importante. NightRun no ejecuta directamente sobre el hardware después de abandonar completamente el firmware.
El proyecto permanece dentro de UEFI Boot Services durante toda la sesión y nunca llama a ExitBootServices().
Eso le permite resolver varios problemas difíciles sin desarrollar medio sistema operativo.
UEFI proporciona el Graphics Output Protocol (GOP) para acceder al framebuffer, servicios para manejar el teclado USB y acceso al almacenamiento FAT durante la carga. Los servicios multiprocesador del firmware también se utilizan para poner los diferentes núcleos de CPU a trabajar.
La arquitectura simplificada queda así:
UEFI firmware
│
▼
BOOTX64.EFI / BOOTAA64.EFI
│
▼
NightRun
├── framebuffer + UI
├── keyboard
├── multicore worker pool
├── model loader
├── tokenizer
├── KV cache
├── inference engine
└── sampling
│
▼
Modelo completamente en RAMNo existe Linux entre UEFI y NightRun.
Pero UEFI continúa prestando determinados servicios, así que definir el proyecto como «sin sistema operativo convencional» resulta técnicamente más preciso que presentarlo como pure bare metal.
La decisión evita tener que escribir controladores propios para xHCI, USB HID, almacenamiento, gráficos y numerosas particularidades del hardware PC.
Los núcleos dedicados al cálculo tienen además una restricción interna: los worker cores no llaman a los servicios del firmware. Ejecutan el cálculo utilizando primitivas atómicas.
El modelo entra completo en RAM y el disco queda fuera de juego
Para un administrador de sistemas hay otra decisión bastante llamativa.
NightRun no utiliza el USB como almacenamiento activo mientras genera tokens.
Durante el arranque lee el modelo en bloques de 16 MB y calcula CRC-32 simultáneamente. Cuando termina, todo el modelo está residente en memoria.
Después sella el acceso al almacenamiento a nivel del runtime. Un intento posterior de lectura provoca deliberadamente un fallo.
La distribución de memoria se prepara de antemano:
| Región | Contenido |
|---|---|
| Model blob | Pesos, tokenizer y metadatos |
| KV cache | Keys/values FP16 para todas las capas |
| Prefill workspace | Activaciones para procesamiento por lotes |
| Decode scratch | Activaciones, logits y buffers |
| UI buffers | Framebuffer e interfaz |
Los tensores se utilizan mediante vistas zero-copy sobre el bloque que contiene el modelo.
NightRun tampoco va solicitando memoria durante la generación. Una arena se dimensiona durante el arranque para alojar KV cache y memoria temporal. El bucle que genera tokens no realiza asignaciones de heap.
Esto proporciona un comportamiento bastante predecible, pero introduce una condición inflexible: si el modelo y sus estructuras auxiliares no caben en memoria, simplemente no arranca.
La documentación establece aproximadamente 4 GB de RAM para Llama 3.2 1B, 6 GB para Llama 3.2 3B y Granite 4.1 3B, y 8 GB para Qwen3 4B.
De GGUF a .nrm: NightRun tiene su propio formato de ejecución
NightRun tampoco carga directamente cualquier GGUF que encuentre en un directorio.
El proyecto incluye nrconvert, una herramienta que inspecciona el GGUF, comprueba arquitectura, tipos de tensores y tokenizer y después lo convierte al formato propio .nrm.
El proceso es aproximadamente:
GGUF
│
├── inspección de arquitectura
├── validación de tensores
├── validación del tokenizer
▼
nrconvert
│
▼
.nrm
│
├── header
├── tokenizer
├── tensor table
├── tensors alineados a 64 bytes
└── CRC-32
▼
Imagen USB / SDEl formato incluye un encabezado fijo con las dimensiones del modelo, parámetros RoPE, características de la arquitectura y metadatos necesarios para ejecutar el tokenizer y la plantilla de conversación.
Los tensores quedan alineados a 64 bytes y se consumen directamente después de cargar el archivo.
No existe una descompresión general de todos los pesos hacia FP32.
NightRun soporta Q8_0, Q4_K y Q6_K, además de determinados tensores F32. Esto permite conservar la mezcla de cuantizaciones presente en modelos como Q4_K_M.
AVX2 y NEON en lugar de CUDA
Otra diferencia importante para cualquiera acostumbrado a desplegar LLM es que NightRun no utiliza GPU.
En x86_64 dispone de kernels escritos para AVX2, FMA y F16C. En ARM utiliza NEON y cuenta con una ruta sdot para CPUs compatibles.
El flujo de inferencia separa dos fases.
El prefill procesa el prompt en lotes de hasta 64 tokens. Un prompt de 129 tokens, por ejemplo, se procesa como 64 + 64 + 1.
El decode genera después un token cada vez.
NightRun intenta reducir el tráfico de memoria ejecutando directamente operaciones sobre los pesos cuantizados. En inferencia CPU el ancho de banda de memoria puede convertirse rápidamente en el límite de rendimiento, especialmente durante el decode.
Los resultados publicados por el proyecto muestran esta diferencia:
| Modelo | Prefill | Decode | Entorno |
|---|---|---|---|
| Llama 3.2 1B Q8_0 | 52-56 tok/s | ~20 tok/s | QEMU/KVM, 8 cores, AVX2 |
| Granite 4.1 3B Q4_K_M | 23-27 tok/s | ~14 tok/s | QEMU/KVM, 8 cores, AVX2 |
| Qwen3 4B Q4_K_M | ~23 tok/s | ~11 tok/s | QEMU/KVM, 8 cores, AVX2 |
| Granite 4.1 3B Q4_K_M | 6,2 tok/s | 3 tok/s | Raspberry Pi 5 |
Son mediciones del propio proyecto, no benchmarks independientes, y los resultados de QEMU pueden variar con la carga del host. NightRun tampoco afirma superar globalmente a llama.cpp.
De hecho, sus desarrolladores sitúan el prefill entre 1,15 y 1,4 veces por detrás de llama.cpp en determinadas comparaciones equivalentes.
La optimización interesante no consiste aquí en batir un récord, sino en conseguir una implementación suficientemente rápida sin depender de todo el stack habitual del sistema operativo.
La comparación con llama.cpp forma parte de los tests
Para un desarrollador, probablemente una de las partes más interesantes del repositorio está en su estrategia de validación.
NightRun mantiene kernels escalares de referencia y compara contra ellos sus implementaciones AVX2 y NEON.
Después existe otra comprobación a un nivel superior: la generación greedy debe coincidir token por token con llama.cpp para las familias soportadas.
También se comprueba que:
batched prefill == sequential processingtanto para los logits como para el contenido del KV cache.
El tokenizer tiene su propia batería de pruebas. Los casos de prueba se generan desde los tokenizers oficiales de Hugging Face y las plantillas de chat se comparan contra apply_chat_template.
Este punto es más importante de lo que parece. Dos motores pueden implementar correctamente las multiplicaciones matriciales y producir resultados diferentes porque uno tokeniza el prompt o construye la conversación de otra manera.
El proyecto documenta precisamente errores detectados gracias a estas comparaciones, como diferencias en la implementación de RoPE de Qwen.
Un PC realmente aislado no es simplemente un portátil con el Wi-Fi apagado
Desde el punto de vista de un sysadmin, probablemente la característica más provocadora sea la red.
NightRun no tiene stack TCP/IP.
No significa que exista una interfaz de red administrativamente desactivada:
ip link set eth0 downLenguaje del código: JavaScript (javascript)Tampoco una regla:
iptables -P OUTPUT DROPNi una VM conectada a una red interna.
El runtime directamente no implementa la infraestructura necesaria para comunicarse por IP.
Esto no convierte automáticamente a NightRun en una plataforma segura para cualquier información sensible. El firmware UEFI continúa formando parte de la cadena de confianza, igual que el código del proyecto, el modelo descargado y el equipo utilizado para preparar la imagen.
Pero elimina una cantidad considerable de software de la superficie activa.
También cambia el modelo operativo. No hay actualizaciones remotas, telemetría, dependencias cloud ni servicios escuchando puertos porque no existe una red que puedan utilizar.
La contrapartida: tampoco hay SSH, Docker, API ni observabilidad convencional
Ese aislamiento tiene un precio.
Para un entorno de producción tradicional, algunas limitaciones son importantes:
| Función habitual | NightRun |
|---|---|
| SSH | No |
| API REST | No |
| Docker/Kubernetes | No |
| TCP/IP | No |
| GPU | No |
| Sistema de paquetes | No |
| Actualización remota | No |
| Prometheus/OpenTelemetry | No |
| Logs mediante systemd | No |
| Shell local | No |
| Interfaz de chat | Sí |
| Ejecución multinúcleo CPU | Sí |
NightRun tampoco pretende ocultarlo. Su documentación lo define como un appliance de chat de propósito único, no como un sistema operativo generalista.
Eso limita bastante los casos prácticos, pero hace más interesante el proyecto desde el punto de vista técnico.
El USB se construye desde Linux y el instalador intenta no destruir el disco equivocado
La preparación inicial sí necesita un sistema Linux.
El proceso guiado puede resumirse en:
git clone https://github.com/hardrave/NIGHTRUN.git
cd NIGHTRUN
./install.shLenguaje del código: PHP (php)El instalador permite elegir x86_64 o Raspberry Pi 5, descargar un modelo validado o utilizar un GGUF local, convertirlo, generar la imagen y escribirla sobre USB o microSD.
Como escribir una imagen completa implica destruir el contenido del dispositivo, el instalador aplica varias comprobaciones. Excluye los discos asociados a /, /boot, /home y swap, vuelve a verificar la identidad física de la unidad antes de escribir y obliga a introducir una confirmación explícita del tipo:
FLASH /dev/sdXDespués vuelve a leer la región escrita y compara su SHA-256 con la imagen original.
En el equipo de destino basta seleccionar el USB desde UEFI, aunque Secure Boot debe estar desactivado porque las imágenes no están firmadas.
NightRun también es un experimento sobre programación con agentes de IA
Hay otra capa curiosa para desarrolladores: buena parte del proyecto fue creada con Claude Code utilizando el modelo Fable 5, según sus responsables.
El repositorio resulta especialmente interesante por el tipo de código generado y posteriormente validado.
Aquí hay Rust no_std, UEFI, SIMD, formatos binarios, tokenización, gestión manual de memoria, inferencia transformer, framebuffer y código capaz de escribir directamente un disco.
Precisamente por ello el proyecto apuesta por tests contra implementaciones de referencia en lugar de asumir que el código generado funciona porque compila.
NightRun sigue siendo experimental. La compatibilidad x86_64 depende de peculiaridades de cada firmware, solo existen tres familias de modelos soportadas, no hay aceleración GPU y el modelo debe caber completamente en RAM.
Pero para administradores de sistemas y desarrolladores resulta interesante precisamente porque lleva al extremo una idea que normalmente se formula de manera mucho más sencilla.
Ejecutar un LLM «en local» suele significar instalar Ollama, descargar un GGUF y asegurarse de que ninguna petición sale del equipo. NightRun cambia la pregunta: si la máquina solo va a ejecutar un modelo, ¿cuánto software puede eliminarse entre el firmware y los pesos?
Su respuesta actual es bastante radical: Linux entero.
Fuente: Noticias inteligencia artificial
