Fijar la versión de Ubuntu y gestionar los drivers NVIDIA en servidores de IA

Si usted es responsable de un servidor de IA del que dependen otras personas, la causa más probable de su próxima caída no será un fallo de hardware, un error del modelo ni un incidente eléctrico. Será un apt-get upgrade que usted o su distribución ejecutaron en segundo plano, que arrastró un kernel nuevo, contra el que el módulo DKMS de NVIDIA no se recompiló limpiamente, y que dejó a nvidia-smi devolviendo Failed to initialize NVML: Driver/library version mismatch en el siguiente arranque. Esa es, con diferencia, la llamada al soporte de Kentino más habitual cuando un servidor lleva dos o tres meses funcionando.

Este artículo trata de cómo evitar que eso ocurra. Explica qué Ubuntu LTS elegir a mediados de 2026, cómo instalar el controlador de NVIDIA de una forma sobre la que usted pueda razonar de verdad, cómo fijar el controlador y el kernel para que una actualización desatendida no pueda destruir su stack en silencio, y cómo recuperarse cuando alguien lo ha hecho de todos modos.

Va dirigido a quien vaya a teclear sudo en un equipo de 4 u 8 GPU que se supone que debe seguir funcionando durante años.

Por qué Ubuntu LTS

Hay distribuciones de Linux técnicamente solventes que no son Ubuntu: Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Ninguna es una mala elección, y algunas están, probablemente, mejor diseñadas. Aun así recomendamos Ubuntu LTS para servidores de IA, por cuatro razones que nada tienen que ver con la elegancia.

NVIDIA valida primero contra Ubuntu LTS. Sus repositorios apt publican paquetes cuda-keyring explícitamente para ubuntu2204, ubuntu2404 y (desde la primavera de 2026) ubuntu2604. La guía de instalación del controlador menciona Ubuntu LTS por número de versión; las demás distribuciones aparecen al final del documento.

El ecosistema de contenedores da por supuesto Ubuntu. Todas las imágenes de NGC (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) están construidas sobre una base Ubuntu LTS. La distribución del host no tiene por qué coincidir con la del contenedor, pero cuando coincide, las suposiciones sobre el kernel y el espacio de usuario encajan sin fricción.

La mayoría de las herramientas de IA de terceros dan por supuesto Ubuntu en su README. vLLM, llama.cpp, SGLang, las instrucciones de compilación de FlashAttention, los ejemplos de Accelerate de Hugging Face: todo está escrito y probado primero contra Ubuntu. RHEL funciona, pero será usted quien abra las incidencias cuando no funcione.

El grupo de gente que ya ha tropezado con su problema es mayor en Ubuntu. Cuando nvidia-smi devuelva un disparate a las 02:00, los tres primeros resultados de Stack Overflow serán específicos de Ubuntu. Eso importa más de lo que debería.

Debian y RHEL no son malas opciones para un servidor de IA. Simplemente tienen una superficie de pruebas menor, ciclos de validación de NVIDIA más lentos y una comunidad más reducida cuando algo se tuerce. Si tiene un motivo organizativo de peso para una de ellas —un entorno FedRAMP aislado, una licencia de sitio de RHEL ya existente, un equipo de administración de sistemas volcado en Debian—, úsela. Si no, opte por Ubuntu LTS.

22.04 frente a 24.04 y 26.04 en mayo de 2026

Hoy hay tres versiones LTS con soporte activo. La tabla honesta:

Merece la pena destacar algunas cosas de esa tabla.

22.04 sigue siendo el parque instalado más grande del mundo, y es sobre la que el proceso de validación de NVIDIA tiene más historial. Si tiene un parque de 22.04 funcionando, no se precipite a actualizar. Tiene soporte completo hasta abril de 2027 con actualizaciones estándar, y Ubuntu Pro amplía el mantenimiento de seguridad hasta 2032 si lo necesita. Pero si está montando un servidor nuevo a mediados de 2026, está eligiendo el sistema operativo de los próximos cuatro o cinco años. A 22.04 solo le queda un año de soporte estándar. No empiece por ahí.

24.04 es el punto óptimo para trabajo de IA en producción en 2026. Acumula dos años de correcciones y revisiones del kernel HWE, todas las ramas del controlador de NVIDIA desde la R535 en adelante han tenido paquetes de calidad de producción en el repositorio ubuntu2404 de NVIDIA, todas las imágenes de NGC incluyen 24.04 entre sus bases admitidas, y usted tiene hasta abril de 2029 antes de que se acabe el soporte estándar. Es lo que desplegamos hoy en los equipos nuevos de Kentino.

26.04 acaba de salir. Incluye la R595 como controlador por defecto en el repositorio oficial de Ubuntu, trae CUDA en los repositorios principales por primera vez y presenta mejoras en la relación entre Wayland y NVIDIA que importan en equipos de escritorio y no importan en absoluto en servidores de inferencia sin monitor. El riesgo para un servidor de IA son los plazos: durante los tres o cuatro primeros meses tras una versión LTS .0, las recomendaciones de ubuntu-drivers y el comportamiento de los módulos DKMS se mueven, y al propio repositorio de NVIDIA le cuesta unos cuantos ciclos validar por completo cada rama del controlador contra el nuevo kernel. El patrón de versiones LTS anteriores (20.04, 22.04, 24.04) indica que la primera versión de mantenimiento —26.04.1, en agosto de 2026— es cuando empieza a tener sentido desplegarla en producción. Si puede esperar, espere. Si no puede, haga una prueba de rodaje de dos semanas antes de poner nada importante encima.

Las vías de instalación del controlador

Hay tres formas de instalar el controlador de NVIDIA en un equipo Ubuntu. No son igual de buenas.

ubuntu-drivers install es la vía fácil. Canonical mantiene una herramienta que analiza su hardware, elige la rama del controlador que considera recomendada e instala el paquete correspondiente del archivo de Ubuntu. Se encarga por usted de la firma para Secure Boot (con la clave de Canonical), conoce los kernels HWE y, en un equipo de escritorio con una sola GPU de consumo, funciona bien. En un servidor de IA es la vía frágil: la rama recomendada puede cambiar entre versiones del paquete ubuntu-drivers-common, la versión que obtiene al hacer apt update depende de lo que Ubuntu haya empaquetado esta semana, y usted tiene menos control sobre qué versión menor del controlador acaba en disco. Úsela en el portátil. No la use en el servidor.

apt desde el repositorio CUDA de NVIDIA es la vía manual, pero controlable. Añade el paquete cuda-keyring de NVIDIA, que configura la fuente apt adecuada para su versión de Ubuntu, y después instala exactamente los paquetes que quiere: cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, sin sorpresas. NVIDIA controla el empaquetado y usted controla la versión. Es la opción por defecto de Kentino.

El instalador .run de developer.nvidia.com escribe archivos en /usr/local, gestiona sus propias recompilaciones del módulo del kernel y no se integra en absoluto con apt. Es la respuesta correcta en dos casos muy concretos: hardware recién salido, cuya rama del controlador aún no ha llegado al repositorio apt, o una estación de trabajo en la que usted esté desarrollando o depurando el controlador. En cualquier otro caso es la respuesta equivocada. Peleará con DKMS, no lo recogerá apt-mark hold y se romperá en silencio en la siguiente actualización del kernel, porque ahora la vía de recompilación es manual.

En concreto, en un servidor 24.04 recién instalado, la secuencia por defecto de Kentino es:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Instale la rama del controlador que realmente quiere, por número.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Tras reiniciar, nvidia-smi debería informar del controlador 580.x y de la versión máxima de CUDA que admite (CUDA 13 para la R580). Esa es toda la instalación. Fíjese en lo que no aparece: ningún metapaquete cuda, ningún cuda-toolkit-13-0 (solo necesario si compila código CUDA en el host; véase L02), ningún ubuntu-drivers. Usted eligió la versión, instaló la versión y sabe qué hay en disco.

Las ramas del controlador que importan en 2026

NVIDIA publica sus controladores para Linux en ramas con ventanas de soporte concretas. A mediados de 2026:

La R580 es la opción por defecto correcta en 2026. Es compatible con todas las GPU de la gama Kentino (5090, 4090, RTX Pro 6000 Blackwell en sus dos ediciones, L40, L4), incluida la capacidad de cálculo sm_120 de la arquitectura Blackwell, e incorpora soporte nativo de CUDA 13, que es a lo que apuntan todas las versiones recientes de vLLM, PyTorch 2.10/2.11 y TensorRT-LLM. La R570 es la opción LTSB conservadora si tiene un parque de tarjetas Ada (4090 / L40 / L4) que no necesita las funciones más nuevas y quiere ahorrarse un cambio de rama durante otro año. La R595 es la que trae Ubuntu 26.04 por defecto y la que querrá para el hardware más reciente; en un servidor que solo ejecute lo que hay hoy en la gama Kentino, la R580 es más conservadora y está igual de equipada.

El baile a tres bandas entre controlador, CUDA y PyTorch

Tres versiones independientes tienen que encajar. Se apoyan unas sobre otras así:

PyTorch wheel (e.g. torch==2.11.0+cu130)
        │  ships its own CUDA runtime, cuDNN, NCCL inside the wheel
        ▼
CUDA runtime version (here: 13.0)
        │  the driver must support this CUDA version or newer
        ▼
NVIDIA driver branch (here: R580 → supports CUDA 13.x)

La regla es que el controlador admite una versión máxima del runtime de CUDA. Cualquier versión anterior a ese máximo, dentro de la misma versión mayor, funcionará. Así, la R580 (CUDA 13.x como máximo) ejecuta wheels de PyTorch compiladas contra 13.0, 13.1 y 13.2; no ejecuta wheels compiladas contra la (hipotética) CUDA 14.0 hasta que actualice la rama del controlador. Los controladores antiguos no pueden ejecutar CUDA más reciente: existe compatibilidad hacia delante para algunas tarjetas de centro de datos, pero es frágil y no es la forma en que usted querrá trabajar.

Mapa práctico de lo que ejecutan hoy los servidores de Kentino:

Su tarea consiste en fijar el controlador y dejar que todo lo que hay por encima lo siga. No necesita instalar CUDA en el host en absoluto si lo sirve todo desde contenedores (y debería hacerlo; véase L02). El host necesita el controlador y el container toolkit. Nada más.

Fijar versiones: el comando más valioso de este artículo

Una vez instalado el controlador y con nvidia-smi contento, fíjelo. Fijar significa decirle a apt que no actualice, no degrade ni elimine determinados paquetes, aunque una dependencia o una actualización de seguridad fuesen a tocarlos. El comando es apt-mark hold.

# Fije la rama del controlador.
sudo apt-mark hold \
  cuda-drivers \
  cuda-drivers-580 \
  nvidia-driver-580 \
  nvidia-driver-580-server \
  nvidia-dkms-580 \
  libnvidia-compute-580 \
  libnvidia-compute-580-server

# Fije el kernel en ejecución y sus cabeceras: DKMS necesita ambos para recompilar,
# y un salto de kernel que DKMS no gestione es justo la forma de perder la GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# Si usa el metapaquete del kernel HWE de Ubuntu, fíjelo también:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Compruébelo.
apt-mark showhold

Con eso se resuelve aproximadamente la mitad de todas las llamadas del tipo «mi servidor de IA ha dejado de funcionar». Cuando se ejecute apt update && apt upgrade —a mano, desde una herramienta de gestión de configuración o bajo unattended-upgrades—, esos paquetes fijados no se moverán. Los verá aparecer como «kept back» en la salida de la actualización, y podrá revisarlos y liberarlos deliberadamente en una ventana de mantenimiento, cuando a usted le venga bien.

Algunas trampas. Hay quien fija nvidia-driver-580 y se olvida de cuda-drivers-580, que es el metapaquete real del repositorio CUDA. Si cuda-drivers-580 se actualiza porque una dependencia transitiva quiere una versión de mantenimiento más nueva, arrastrará un nvidia-dkms-580 nuevo y usted habrá perdido la fijación. Indique ambos. Hay quien fija la imagen del kernel pero no las cabeceras: el kernel se actualiza igualmente por culpa de un metapaquete y DKMS no encuentra las cabeceras cuando intenta recompilar; nvidia-smi funciona hasta que se reinicia, y entonces ya no. Fije siempre la imagen y las cabeceras juntas.

Las trampas del kernel y de DKMS

DKMS (Dynamic Kernel Module Support) es el sistema que recompila los módulos del kernel que están fuera del árbol cada vez que el kernel cambia. El paquete nvidia-dkms-XXX de NVIDIA registra el controlador como módulo DKMS para que, en teoría, una actualización del kernel gestionada por apt dispare una recompilación limpia del módulo y usted reinicie en un sistema que funciona.

En la práctica, las recompilaciones de DKMS fallan de tres maneras que se repiten:

Las cabeceras del kernel no están instaladas para el kernel nuevo, algo habitual cuando el paquete del kernel se instaló pero el de las cabeceras quedó filtrado por una preferencia de apt o por una selección personalizada. El kernel nuevo arranca, falta el módulo de NVIDIA y nvidia-smi devuelve «NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver».

El kernel nuevo es demasiado reciente para la rama del controlador. La R570 no compila limpiamente contra los últimos kernels 6.14; la R580 sí. Si deja que un salto de HWE le lleve a un kernel contra el que nunca se probó esa rama, DKMS genera un error de compilación en /var/lib/dkms/nvidia/.../make.log y usted reinicia en un sistema que funciona, pero sin GPU.

Secure Boot está activado y el módulo recompilado no está firmado. Los paquetes instalados mediante ubuntu-drivers de Canonical llegan con la firma de Canonical ya resuelta. Los paquetes del repositorio CUDA de NVIDIA no: exigen que usted registre una Machine Owner Key (MOK) y firme los módulos recompilados cada vez que cambia el kernel. DKMS puede firmar automáticamente con la configuración adecuada por módulo, pero hay que prepararlo antes de la primera recompilación, no después de que el sistema no arranque. Si no necesita Secure Boot —y en un servidor de inferencia sin monitor, dentro de un rack cerrado, probablemente no lo necesite—, desactívelo en el firmware antes de instalar el controlador y se ahorrará toda esta clase de problemas.

Fijar el kernel esquiva los tres. El kernel no cambia sin que usted intervenga, las cabeceras siguen emparejadas y el módulo recompilado se sigue cargando. Cuando usted quiera adoptar un kernel nuevo —por un CVE o por una funcionalidad real—, lo hará de forma deliberada, con una instantánea y listo para revertir.

CUDA sobre metal desnudo: cuándo (en contadas ocasiones) sigue siendo lo correcto

L02 defiende que CUDA sobre metal desnudo es hoy casi siempre la elección equivocada: los contenedores ocultan el baile de versiones de CUDA, desacoplan el host de la carga de trabajo e imponen un coste de rendimiento insignificante. Eso es cierto en el ~95 % de las instalaciones.

Las excepciones son muy concretas. El perfilado de GPU a nivel de kernel con Nsight Systems o Nsight Compute, donde la capa de contenedor oculta las llamadas al sistema que a usted le interesan. El trabajo sobre el propio controlador: ejecutar versiones preliminares de NVIDIA, depurar fallos que afectan al módulo del kernel. Entornos estrictamente aislados en los que descargar imágenes OCI y confiar en ellas es más difícil que mantener un espejo de apt congelado. Y un puñado de centros de HPC que lo han construido todo alrededor de module load y MPI sobre metal desnudo y no tienen ningún interés en cambiarlo.

Para todos los demás: instale el controlador sobre metal desnudo, deje el host limpio de CUDA y ejecute CUDA dentro de contenedores. El nvidia-container-toolkit (que se trata en L02) conecta ambos mundos sin fisuras.

Actualizaciones desatendidas: qué permitir y qué bloquear

El paquete unattended-upgrades de Ubuntu es bueno y debería dejarlo activado. Saltarse por completo las actualizaciones de seguridad en un servidor conectado a la red es peor que el riesgo de que una actualización automática salga mal. El patrón correcto es: actualizaciones de seguridad sí, kernel y paquetes de NVIDIA no.

Edite /etc/apt/apt.conf.d/50unattended-upgrades y añada al bloque de la lista de exclusión:

Unattended-Upgrade::Package-Blacklist {
    "linux-image-";
    "linux-headers-";
    "linux-generic";
    "linux-modules-";
    "nvidia-";
    "libnvidia-";
    "cuda";
    "cuda-";
    "libcudnn";
};

apt-mark hold ya impide que estos paquetes se actualicen. La lista de exclusión es el cinturón además de los tirantes: deja explícita la intención, evita que unattended-upgrades llegue siquiera a registrar un intento y sobrevive a un apt-mark unhold descuidado de un administrador novato. Haga las dos cosas.

Confírmelo revisando /var/log/unattended-upgrades/unattended-upgrades.log tras la siguiente ejecución. Debería ver pasar los paquetes de seguridad y los fijados o excluidos omitidos de forma explícita.

El manual de recuperación de «hice un dist-upgrade y ahora no funciona nada»

Alguien ejecutó apt full-upgrade (o lo hizo su herramienta de gestión de configuración) y, al reiniciar, las GPU han desaparecido. Orden de actuación:

1. Arranque. Si el sistema no arranca, mantenga pulsada la tecla Mayús o Esc en el menú de GRUB y elija el kernel anterior. Compruebe que nvidia-smi funciona con el kernel antiguo. Si funciona, el problema es el kernel nuevo; fije el antiguo (apt-mark hold linux-image-<antiguo>) y continúe.
2. Si el sistema arrancó pero nvidia-smi indica un desajuste de NVML, está ejecutando un espacio de usuario nuevo contra un módulo antiguo ya cargado. Reinicie. Casi siempre lo resuelve.
3. Si nvidia-smi dice que el controlador no está cargado, revise /var/lib/dkms/nvidia/<version>/build/make.log y dmesg | grep -i nvidia. Los fallos más habituales: faltan las cabeceras del kernel (apt install linux-headers-$(uname -r) y después dkms autoinstall); un kernel demasiado nuevo para el controlador (degrade el kernel o actualice la rama del controlador de forma deliberada); Secure Boot rechazando el módulo sin firmar (mokutil --sb-state y, a continuación, o bien desactivar SB, o bien registrar una MOK).
4. Si los propios paquetes del controlador acabaron, tras el dist-upgrade, en un estado que usted no quería —por ejemplo, el metapaquete instaló la R585 encima de su R580 fijada porque alguien quitó la fijación—, purgue y reinstale: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, después repita la instalación desde el repositorio CUDA con la versión que realmente quiere y vuelva a aplicar las fijaciones.
5. Si tiene una instantánea —y debería tenerla, véase más abajo—, restáurela. Son veinte minutos para volver a un estado bueno conocido, frente a cuatro horas de depuración.

Haga una instantánea antes de tocar el controlador o el kernel

Sea cual sea su esquema de almacenamiento, tome una instantánea antes de cualquier operación sobre el controlador o el kernel. Quien use ZFS (con / en ZFS o en un conjunto de datos aparte) lo tiene gratis con zfs snapshot rpool@pre-driver-upgrade-2026-05-15. Quien use LVM con pools finos puede recurrir a lvcreate --snapshot. Quien use ext4 sin LVM se queda con las copias completas; es una de las razones por las que tratamos la disposición del sistema de archivos en L04.

La disciplina que acaba compensando: no toque nunca el controlador, los paquetes de CUDA o el kernel sin haber tomado una instantánea en los cinco minutos anteriores. Una instantánea cuesta segundos. No tenerla cuando una actualización se tuerce cuesta media jornada de parada y la tarde de alguien.

Ruta de actualización entre versiones LTS

Las actualizaciones de LTS a LTS de Ubuntu llegan cada dos años; en servidores de IA recomendamos saltarse una de cada dos. La ruta es:

22.04  ──(skip 23.x interim, skip 24.04 if production-stable)──▶  26.04
24.04  ──(skip 25.x interim, skip 26.04 if production-stable)──▶  28.04

El razonamiento: el coste de una actualización de LTS en un servidor de IA es alto (revalidar el controlador, volver a probar las imágenes de contenedor, a menudo repetir las pruebas de integración), la ventaja de avanzar un paso en lugar de dos es pequeña, y las herramientas de actualización de LTS a LTS de Ubuntu admiten el salto sin problemas. Planifique la actualización, programe una ventana de mantenimiento, tome una instantánea, ejecute do-release-upgrade, haga una prueba de rodaje de una semana y devuelva después las cargas de trabajo a su sitio. Pasar directamente de 22.04 a 26.04 está admitido y es lo que acabarán haciendo la mayoría de los clientes de Kentino a finales de 2026 o en 2027.

Qué conviene evitar: actualizaciones in situ en plena fase de desarrollo, actualizar sin instantánea y actualizar y acto seguido hacer un dist-upgrade de todo el stack de NVIDIA a la vez. Cambie una sola cosa cada vez.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Comentarios y correcciones son bienvenidos en info@kentino.com.