La disaggregazione tra prefill e decode è diventata un'architettura comune per il serving di LLM, perché separa due fasi con profili di esecuzione e obiettivi SLO molto diversi. Il problema è che la maggior parte dei sistemi abbina questa separazione a un rapporto rigido tra worker dedicati al prefill e worker dedicati alla decode. Funziona finché il carico reale si comporta come il dimensionamento previsto. Quando non lo fa, la latenza sfora gli SLO anche se da qualche parte c'è capacità libera. FluidPD nasce esattamente qui.

Il sistema introduce due meccanismi. FluidToken affronta gli squilibri transitori spostando una porzione limitata del calcolo di prefill sui worker di decode, ma solo quando il lato decode ha margine disponibile. FluidRole interviene invece sui cambiamenti sostenuti: riassegna i worker già in esecuzione tra i ruoli di prefill e decode senza ricaricare il modello e senza riavviare il motore di inference. A guidare entrambi sono indici di pressione leggeri, pensati per esporre la tensione sulle risorse prima che si trasformi in una violazione di SLO.

Il risultato riportato dagli autori su tracce di produzione Azure è netto: fino a 94,6 punti percentuali in più di raggiungimento complessivo degli SLO rispetto a SGLang statico, senza aggiungere nuovi worker. Non è un benchmark isolato: è un segnale strutturale. Il disallineamento tra prefill e decode non è un problema da risolvere comprando più GPU, ma un problema di orchestrazione e tempismo.

Questo sposta il baricentro del dibattito. Per chi gestisce un'infrastruttura on-premise, dove il parco GPU è fisso e ogni unità aggiuntiva è una decisione di budget, la possibilità di riassegnare ruoli senza fermare il motore ha un valore immediato. Significa meno tempo perso a ricaricare modelli, meno capacità di riserva da tenere parcheggiata e una risposta più rapida ai picchi brevi. Non è solo efficienza operativa: è TCO. Il costo totale scende se lo stesso hardware serve più carico senza violare i livelli di servizio.

Ci sono implicazioni meno visibili. Se l'elasticità in-place diventa la norma, la qualità del software di coordinamento diventa un fattore competitivo più importante della quantità di acceleratori installati. I team di operations dovranno smettere di guardare solo l'utilizzo medio e iniziare a osservare indici di pressione che anticipano i colli di bottiglia. E i fornitori di soluzioni di serving saranno valutati non sulla capacità che possono aggiungere, ma su quanto bene sfruttano quella già presente. In questo senso, il vero avversario di FluidPD non è un altro sistema di serving, ma l'idea che l'elasticità richieda necessariamente nuove risorse.

Certo, le tracce Azure hanno caratteristiche specifiche e il guadagno di 94,6 punti percentuali non va proiettato automaticamente su ogni contesto. Ma la direzione è chiara: la disaggregazione prefill-decode ha bisogno di una logica di adattamento fine, non di un rapporto fisso. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per confrontare i trade-off tra capacità fissa, orchestrazione e rispetto degli SLO. FluidPD è un caso concreto di come l'infrastruttura di serving possa guadagnare maturità senza aspettare la generazione successiva di hardware.