Non è una semplice nota di changelog. Redox OS, il sistema operativo scritto da zero in Rust, ha annunciato il passaggio a uno scheduler basato su EEVDF con due numeri che meritano attenzione: 2,6x di throughput e 782x di fairness. La modifica tocca il cuore della gestione dei processi e dice molto su quanto margine esista ancora sotto il livello applicativo.

Il dato sulla fairness è quello più rivelatore. Un miglioramento di 782 volte non è il risultato di un tuning incrementale: indica che il precedente scheduler poteva produrre squilibri profondi nella distribuzione del tempo CPU tra processi concorrenti. Per un sistema operativo pensato per essere piccolo, modulare e scritto in Rust, questo tipo di problema non è solo teorico: carichi misti, processi con priorità diverse e accessi concorrenti alle risorse possono rapidamente trasformare un'architettura pulita in un collo di bottiglia.

Per chi lavora con stack self-hosted o valuta deployment on-premise di carichi AI, la notizia ha una rilevanza indiretta ma concreta. L'inference di modelli e la gestione delle pipeline non dipendono solo dalla GPU: preparazione dei batch, gestione della memoria, I/O e orchestrazione dei processi passano anche dalla CPU. Se lo scheduler non assegna il tempo CPU in modo prevedibile, le latenze di coda aumentano e il throughput complessivo ne risente. In contesti CPU-only o ibridi, un salto di 2,6x a livello di scheduler può cambiare i calcoli di TCO e prestazioni senza toccare l'hardware.

Va detto che Redox OS non è ancora una piattaforma comune per il serving di LLM. La maturità dei driver, il supporto per gli acceleratori e la compatibilità con gli strumenti di orchestrazione sono fattori che contano quanto la qualità dello scheduler. Il punto non è quindi consigliare una migrazione a Redox, ma riconoscere un segnale strutturale: lo scheduler non è un componente risolto una volta per tutte. La scelta di EEVDF, una politica che punta a combinare equità e bassa latenza, suggerisce che anche un sistema scritto da zero può trovare margini significativi senza riscrivere le applicazioni.

In questo senso, la notizia si inserisce in una discussione più ampia per chi gestisce infrastruttura AI on-premise. Il controllo dello stack, dalla scelta del sistema operativo alla configurazione dei runtime, è una leva che incide sul costo complessivo e sulla prevedibilità delle prestazioni. AI-RADAR offre su /llm-onpremise framework analitici per valutare questi trade-off, senza scorciatoie. Il dato Redox, con le dovute cautele, ricorda che l'ottimizzazione parte spesso da livelli che diamo per scontati.