← Alle artikelen

Mijn lokale LLM draaide tien uur op de CPU zonder dat iets het meldde. Twee oorzaken van dezelfde nachtelijke update: een gewiste device-cgroup en een driver die niet meer bij de geladen module paste.

De GPU die na elke kernel-update verdween

Op een ochtend was mijn lokale model traag. Niet een beetje: het draaide al tien uur op de processor. Niets had gealarmeerd, want de container draaide, de healthcheck was groen en het model gaf antwoord. Alleen veel langzamer.

Oorzaak 1: de device-cgroup werd gewist

De container start met --gpus all. De NVIDIA-hook voegt de GPU-devices toe bij het starten, maar die staan niet in de container-spec. Een kernel-update via unattended-upgrades laat dpkg een systemd daemon-reload doen. Daarbij wordt de device-cgroup van draaiende containers opnieuw gezet, op basis van de spec. De GPU-devices verdwijnen dan uit de toegestane lijst.

Herkenning:

  • /dev/nvidia0 en /dev/nvidiactl staan nog in de container, met dezelfde major/minor als op de host;
  • openen wordt geweigerd, en nvidia-smi in de container geeft Failed to initialize NVML: Unknown Error;
  • llama.cpp valt stilletjes terug op de CPU: no usable GPU found, --gpu-layers option will be ignored.

De fix is twee regels naast --gpus all:

--device-cgroup-rule "c 195:* rmw" \
--device-cgroup-rule "c 235:* rmw"

Die staan wél in de spec en overleven een daemon-reload. Bewust cgroup-regels en geen --device, omdat de device-nodes dan niet hoeven te bestaan op het moment dat de container na een reboot start.

Oorzaak 2: een driver die niet bij de module past

Dezelfde update werkte ook de NVIDIA-driver bij, terwijl de oude kernelmodule geladen bleef. Dan faalt zelfs nvidia-smi op de host, en kan de container niet meer starten (nvidia-container-cli: initialization error). Alleen een reboot lost dat op. DKMS bouwt de module voor beide kernels, dus dat is veilig.

Wat ik toevoegde

Het startscript leest na het starten de log en waarschuwt bij "no usable GPU found". Een model dat antwoordt terwijl de GPU nul procent doet, draait op de CPU, en dat wil je weten voordat je tien uur traag werkt.

De les: "de dienst draait" is geen gezondheidscheck. Meet wat de dienst moet doen, niet of het proces bestaat.