NightRun propone una forma bastante distinta de ejecutar inteligencia artificial en local: el ordenador arranca directamente desde un USB, carga el modelo completo en la memoria RAM y abre un chat sin iniciar Linux, Windows ni otro sistema operativo convencional. Tampoco incorpora una pila de red. Una vez cargado el modelo, el almacenamiento queda bloqueado para nuevas lecturas y la inferencia se realiza exclusivamente con la CPU y la memoria de la máquina.
Las claves de NightRun en 20 segundos
- NightRun es una aplicación UEFI escrita en Rust que arranca directamente desde USB o microSD.
- No utiliza Linux, Windows, navegador, servicios en segundo plano ni pila de red.
- El modelo completo, de entre 1,3 y 2,4 GB, se copia a la RAM antes de comenzar.
- Funciona en ordenadores x86_64 y Raspberry Pi 5.
- Actualmente admite modelos Llama 3.2, Qwen3 y Granite 4.1.
La diferencia frente a instalar Ollama, LM Studio o llama.cpp en un portátil desconectado de Internet está en las capas que desaparecen. Esas herramientas ejecutan modelos localmente, pero continúan dependiendo de un sistema operativo completo. NightRun convierte el ordenador en un dispositivo dedicado prácticamente a una única tarea: arrancar y conversar con un modelo de lenguaje.
Hay, sin embargo, un matiz técnico importante. NightRun no afirma ser un sistema completamente “bare metal”. Permanece durante toda la sesión sobre los UEFI Boot Services del firmware y no ejecuta ExitBootServices(). Esto le permite aprovechar funciones del propio firmware para manejar pantalla, teclado, almacenamiento y varios núcleos de CPU sin tener que desarrollar todos esos controladores desde cero.
Por tanto, decir que “no hay sistema operativo convencional debajo” es correcto. Afirmar que no existe ninguna capa de firmware prestando servicios sería exagerar lo que realmente hace el proyecto.
Del botón de encendido al modelo cargado en RAM
El proceso de arranque ayuda a entender por qué NightRun resulta peculiar.
En un ordenador habitual, UEFI encuentra un cargador que termina iniciando Windows o el kernel de Linux. Después aparecen controladores, servicios, procesos de usuario y finalmente la aplicación encargada de ejecutar el modelo.
NightRun acorta considerablemente esa cadena.
En x86_64 el firmware inicia directamente BOOTX64.EFI. En Raspberry Pi 5 se utiliza BOOTAA64.EFI. A partir de ahí NightRun configura el framebuffer de vídeo, el teclado, los núcleos disponibles y la memoria necesaria.
Después comienza a leer el modelo desde el USB o la tarjeta SD.
| Arranque convencional de una IA local | NightRun |
|---|---|
| UEFI | UEFI |
| Cargador de arranque | Aplicación NightRun |
| Kernel Linux/Windows | No hay kernel convencional |
| Drivers y servicios | Servicios UEFI necesarios |
| Aplicación de inferencia | Runtime NightRun |
| Modelo | Modelo |
| Disco utilizado durante la sesión | Modelo completamente residente en RAM |
| Red disponible según el sistema | Sin pila de red |
El modelo se copia completo a memoria en bloques mientras NightRun calcula comprobaciones CRC-32. No necesita realizar después una segunda lectura completa para comprobar su integridad.
Cuando termina la carga ocurre una de las decisiones de diseño más interesantes: NightRun sella la ruta de almacenamiento. Una lectura posterior del disco provoca deliberadamente un fallo. Los pesos permanecen en RAM y toda la generación se realiza desde allí.
Esto no significa que el USB pueda retirarse necesariamente con seguridad física en cualquier máquina ni que la memoria quede protegida frente a cualquier tipo de ataque. Significa algo más concreto: el propio runtime está diseñado para no volver a consultar el almacenamiento después de cargar el modelo.
La memoria también se reserva previamente. NightRun prepara el KV cache y el espacio de trabajo necesario para la inferencia antes de empezar el chat, de manera que el bucle de generación no realiza asignaciones dinámicas de memoria.
Sin red porque NightRun directamente no tiene una pila de red
La privacidad es probablemente el caso de uso más evidente.
Un portátil con Ollama puede desconectarse de Internet. También puede bloquearse mediante firewall, colocarse en una VLAN aislada o utilizarse sin Wi-Fi ni Ethernet. Son alternativas perfectamente válidas y mucho más flexibles.
NightRun lleva el aislamiento a otro planteamiento: el runtime no incorpora una pila de red.
No existe una aplicación que decida no conectarse a Internet. Simplemente no hay dentro de NightRun la infraestructura de software necesaria para realizar esa conexión.
Esto puede resultar interesante para experimentar con equipos destinados a información sensible, laboratorios aislados, determinados entornos industriales o simplemente usuarios que quieran una máquina de IA deliberadamente desconectada.
Pero conviene separar aislamiento de seguridad absoluta.
NightRun continúa dependiendo del firmware UEFI del ordenador y, antes de arrancar, el modelo y la imagen han tenido que obtenerse y prepararse en otro sistema. Además, la seguridad física, el firmware comprometido o vulnerabilidades en el propio código siguen formando parte de la superficie de riesgo.
Su ventaja concreta es reducir drásticamente el software que permanece activo mientras se utiliza el modelo.
No necesita GPU, pero eso limita los modelos que puede ejecutar
NightRun realiza actualmente toda la inferencia mediante CPU.
En equipos x86_64 utiliza instrucciones AVX2, FMA y F16C cuando están disponibles. En Raspberry Pi 5 aprovecha NEON y dispone de una ruta para las instrucciones sdot.
Los pesos cuantizados se utilizan directamente sin reconstruir previamente una copia completa en FP32. El proyecto admite Q8_0, Q4_K y Q6_K, además de determinados tensores F32.
Esta decisión reduce los requisitos de memoria, pero también marca claramente los límites del proyecto.
Actualmente el catálogo validado es pequeño:
| Modelo | Cuantización | Tamaño aprox. | RAM necesaria |
|---|---|---|---|
| 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 |
No existe compatibilidad universal con cualquier archivo GGUF. NightRun implementa específicamente tres familias de arquitectura: Llama 3.2, Qwen3 y la versión dense transformer de Granite 4.1. Las variantes híbridas SSM/MoE de Granite se rechazan durante la conversión.
El proyecto utiliza además su propio formato .nrm. El instalador inspecciona el GGUF, comprueba la arquitectura y las cuantizaciones y posteriormente realiza la conversión.
Esto es importante porque NightRun no pretende competir con Ollama por cantidad de modelos disponibles. Su planteamiento actual es prácticamente el contrario: pocos modelos, explícitamente implementados y comprobados.
Entre 3 y 20 tokens por segundo según el modelo y la máquina
El desarrollador publica también mediciones de rendimiento, aunque deben interpretarse con cuidado porque buena parte de las pruebas x86_64 procede de QEMU/KVM sobre un host con ocho núcleos y AVX2.
Llama 3.2 1B alcanza alrededor de 20 tokens por segundo durante la generación, mientras Granite 4.1 3B ronda los 13-14 y Qwen3 4B se mueve aproximadamente entre 10 y 11 tokens por segundo en las condiciones publicadas.
En una Raspberry Pi 5 real con 8 GB, Granite 4.1 3B registró unos 3 tokens por segundo. Esa medición, además, es anterior a los nuevos kernels ARM con instrucciones sdot, que todavía están pendientes de nuevas pruebas sobre hardware según la documentación del proyecto.
NightRun tampoco afirma ser más rápido que llama.cpp.
Sus responsables señalan que el rendimiento de generación resulta comparable en determinadas pruebas realizadas con el mismo modelo y máquina, mientras el procesamiento inicial del prompt queda entre 1,15 y 1,4 veces por detrás de llama.cpp.
El atractivo, por tanto, no está en conseguir más tokens por segundo. Está en eliminar prácticamente todo lo que normalmente existe alrededor del motor de inferencia.
El instalador crea un USB que convierte el PC en una máquina de IA
Preparar NightRun requiere inicialmente otro ordenador con Linux.
El instalador permite seleccionar x86_64 o Raspberry Pi 5, escoger un modelo, descargarlo y comprobar su SHA-256, convertirlo al formato .nrm, generar la imagen y escribirla en un USB o microSD.
El proceso de escritura merece precaución porque elimina completamente el contenido de la unidad seleccionada.
El proyecto ha incorporado varias protecciones para reducir el riesgo de sobrescribir accidentalmente el disco principal. El instalador solamente presenta dispositivos extraíbles compatibles, intenta excluir unidades relacionadas con /, /boot, /home y swap, vuelve a verificar la identidad del dispositivo antes de escribir y exige introducir literalmente una confirmación como FLASH /dev/sdX.
Una vez preparada la unidad, el ordenador de destino necesita UEFI y Secure Boot desactivado. Se selecciona el USB desde el menú de arranque y NightRun hace el resto.
En Raspberry Pi 5 el proceso utiliza una microSD y firmware UEFI específico. La documentación recomienda refrigeración activa y explica incluso un detalle que normalmente resolvería el sistema operativo: NightRun controla directamente el ventilador de la Raspberry Pi porque no existe Linux debajo encargado de hacerlo.
Un proyecto experimental que lleva la IA local a otro extremo
NightRun tiene licencia MIT y su código está disponible públicamente en GitHub. Los modelos no se distribuyen como parte del proyecto y conservan las licencias establecidas por Meta, IBM o los responsables de Qwen.
También sigue siendo software experimental.
La documentación reconoce que la compatibilidad con ordenadores x86_64 reales todavía necesita ampliarse porque cada implementación UEFI puede introducir peculiaridades. Tampoco existe aceleración mediante GPU, el contexto está limitado actualmente a 4.096 tokens y los modelos deben caber completos en RAM.
Hay además una historia poco habitual detrás del código: sus responsables explican que gran parte de NightRun fue desarrollado utilizando Claude Code con el modelo Fable 5. El proyecto se presenta también como un experimento sobre hasta dónde puede llegar un agente de programación trabajando con firmware, SIMD, formatos binarios e inferencia, aunque el resultado debe evaluarse como cualquier otro software.
Para controlar errores, NightRun compara la generación greedy de los modelos compatibles token por token con llama.cpp, además de comprobar tokenizadores frente a las implementaciones oficiales de Hugging Face y mantener implementaciones de referencia para sus kernels.
Todo ello deja a NightRun en una categoría bastante diferente de las aplicaciones habituales para ejecutar IA en local.
Ollama o llama.cpp buscan que un modelo conviva con el resto del ordenador. NightRun hace exactamente lo contrario: durante esa sesión, prácticamente convierte el ordenador en el modelo. Arranca desde el USB, carga los pesos en RAM, bloquea nuevas lecturas del almacenamiento, prescinde de la red y dedica la CPU a mantener una conversación.
No será la forma más cómoda de utilizar inteligencia artificial local, ni la que permite ejecutar los modelos más grandes. Pero para quien busque experimentar con una máquina deliberadamente aislada, la propuesta va bastante más allá de instalar un modelo en un portátil y apagar el Wi-Fi.
