Da un certo punto di vista è solo un dettaglio da changelog: systemd-oomd abilitato di default, swap su zRAM attivata in automatico. Ma quando Fedora CoreOS, la distribuzione container-optimized di casa Red Hat, decide di gestire la memoria in modo più aggressivo, c’è una ragione che va oltre la semplice prevenzione degli out-of-memory kill. Per chi fa deployment on-premise di modelli linguistici, la novità ha un sapore molto pratico.

Fedora CoreOS nasce per eseguire container in modo affidabile, spesso su hardware minimale o su nodi edge dove la memoria fisica è poca e aggiungere GPU non è un’opzione. Ecco perché il passaggio a systemd-oomd, unito allo swap compresso su zRAM, colpisce nel segno: quando un carico di inference LLM – magari un modello quantizzato a INT8 o eseguito direttamente su CPU con framework come llama.cpp – inizia a spingere sui limiti di RAM, il sistema non va in crash in modo brutale. Invece interviene prima, uccidendo selettivamente i processi che consumano di più e, nel frattempo, sfrutta la compressione in RAM per creare spazio di respiro senza toccare il disco.

Cosa vuol dire per chi macina token su Kubernetes bare-metal o su un mini-cluster in colocation? Significa che l’orchestratore non deve essere l’unico a sorvegliare i consumi: il sistema operativo diventa un alleato nella gestione delle risorse, riducendo il rischio che un pod di servizio venga terminato a sorpresa mentre sta servendo una finestra di contesto lunga. E questo è particolarmente rilevante con modelli da 7-13 miliardi di parametri, dove la VRAM scarseggia e si finisce per spillare sulla RAM di sistema, con latenze che salgono ma che, grazie allo swap in memoria compressa, restano comunque lontane dai costi proibitivi dell’I/O su disco.

C’è un secondo effetto – meno visibile, ma strutturale. Distribuzioni come Fedora CoreOS stanno implicitamente riconoscendo che i carichi di lavoro AI non sono più ospiti eccezionali, ma cittadini di prima classe dell’infrastruttura containerizzata. La mossa non arriva da un vendor di GPU, bensì da un sistema operativo generalista che aggiorna i propri default per tenere in piedi servizi di inference su hardware comune. È un segnale che la corsa alla GPU più potente convive con un’altra traiettoria, fatta di modelli compressi, esecuzione su CPU e controllo granulare della memoria, dove il costo totale (TCO) si abbassa e la sovranità dei dati resta in casa.

Chi ci guadagna sono i team che gestiscono deployment self-hosted su nodi eterogenei: dal server riciclato in ufficio al NUC parcheggiato in fabbrica. Per loro, systemd-oomd e zRAM non sono ritocchi cosmetici, ma strumenti per aumentare la densità dei carichi e ridurre l’overprovisioning di RAM, sapendo che il sistema saprà gestire i picchi senza mandare tutto in crash. È un vantaggio che si traduce in bollette energetiche più basse e meno chiamate notturne per il team infra.

La direzione, del resto, è chiara: mentre il cloud promette scalabilità infinita, l’on-premise gioca la sua partita sull’efficienza. E Fedora CoreOS, con questa release, mette un mattoncino importante.