Non è raro sottovalutare il ruolo dello scheduling nella pipeline di inference di un Large Language Model. Ci si concentra su VRAM, quantization, throughput dei token, ma quando un server on-premise gestisce più carichi contemporaneamente – magari un servizio di embedding, una coda di batch processing e qualche container applicativo – è il kernel a dover orchestrare l'accesso alla GPU. Ed è qui che entrano in gioco le patch recentemente proposte per lo scheduler Direct Rendering Manager (DRM) di Linux.

Il DRM scheduler è il componente condiviso tra i vari driver grafici del kernel che si occupa di serializzare i comandi destinati all'hardware. In pratica, gestisce la coda dei job da inviare alla GPU. Quando il sistema è sotto pressione lato CPU – decine di processi in esecuzione, context switch frequenti – la latenza con cui un nuovo job di rendering (o, nel nostro caso, di compute) viene accodato e successivamente spedito alla scheda può aumentare in modo significativo. Le nuove patch affrontano proprio questo scenario, mostrando miglioramenti tangibili quando il carico CPU è elevato.

Per chi esegue modelli in locale, il vantaggio non è astratto. Immaginiamo un server che ospita Llama 3 o Mistral con un backend di serving come vLLM o llama.cpp. Mentre l'inference procede, il sistema operativo deve continuamente allocare finestre di tempo alla GPU per elaborare i prompt degli utenti. Se in parallelo gira un processo di addestramento incrementale (fine-tuning parziale) o semplicemente il sistema è saturo di richieste, il DRM scheduler vecchia maniera può introdurre micro-latenze che si traducono in una generazione di token a singhiozzo. Non crash, ma una fastidiosa irregolarità che degrada l'esperienza, specie in applicazioni interattive come chatbot o assistenti di codice.

L'intervento sul DRM scheduler è un esempio di come le ottimizzazioni a livello di infrastruttura – spesso invisibili all'utente finale – possano rafforzare il caso del deployment on-premise. In ambienti cloud controllati, il bilanciamento e l'isolamento delle risorse sono delegati all'hypervisor e alle policy del provider; ma in un data center privato o su un singolo nodo bare metal, il kernel Linux è il primo responsabile della qualità del servizio. Avere uno scheduler più reattivo significa poter consolidare più workload sulla stessa macchina senza sacrificare la latenza di inference, abbassando il TCO.

Non siamo ancora all'integrazione nel ramo principale, ma la direzione è chiara. Con l'espansione dei modelli open-weight e la crescente adozione di stack self-hosted, l'ecosistema Linux sta affinando ogni anello della catena, dal runtime di calcolo al kernel. Per chi valuta un'architettura on-premise, seguire l'evoluzione di componenti come il DRM scheduler non è un esercizio accademico: è una delle leve che determinano se un server con quattro GPU consumer può davvero comportarsi come un'appliance dedicata, anche quando gli si chiede di fare più cose insieme.