La qualità del servizio di un LLM in produzione non dipende solo dal modello scelto, ma dal traffico reale che deve sostenere. Peccato che per anni la ricerca sui sistemi di serving si sia accontentata di tracce sintetiche o proxy grossolani, incapaci di riflettere la complessità delle piattaforme moderne che gestiscono decine di modelli diversi, ciascuno con dimensioni, architetture e casi d’uso propri.

FineServe, presentato da un gruppo di ricerca e accompagnato da un dataset pubblico, prova a colmare questa lacuna in modo radicale. I dati provengono da un marketplace commerciale globale, quindi non da un esperimento controllato, ma dall’utenza viva di servizi LLM in produzione. Non sorprende che contengano dinamiche di arrivo delle richieste e consumo di token molto più irregolari e stratificate di quanto simulassero i benchmark tradizionali.

L’analisi mette in luce regimi di fluttuazione fondamentalmente diversi in base all’architettura del modello (trasformer-only, mixture-of-experts, ecc.), alla sua scala e alla tipologia di compito (chat, completamento codice, traduzione). Significa che un sistema di ottimizzazione del serving pensato per un modello generalista può crollare se usato con un mixture-of-experts, o viceversa. Non si tratta di una differenza di grado, ma di natura: cambiano i burst, la coda, il rapporto tra prefill e decode, e persino la correlazione tra richieste consecutive.

FineServe non si limita a descrivere: fornisce un generatore di workload in grado di comporre miscele configurabili che rispecchiano queste dinamiche granulari. Chi sviluppa o gestisce piattaforme di serving — orchestratori open source come vLLM o soluzioni commerciali — può ora testare le proprie strategie di routing e scheduling contro uno specchio molto più fedele del comportamento reale.

Per il mondo on-premise, il valore è doppio. Finora, le stime per dimensionare un cluster GPU dedicato al serving di LLM in azienda si basavano su estrapolazioni poco affidabili o su dati proprietari dei cloud provider. Un dataset aperto e realistico permette di modellare il Total Cost of Ownership con maggiore precisione, provare configurazioni hardware (ad esempio, bilanciando GPU con VRAM generosa contro più nodi con meno memoria) e valutare se le code di richieste tollerino latenze più alte senza ricorrere a un eccesso di provisioning. Non è un esercizio accademico: in uno scenario di sovranità dei dati, dove l’inference deve restare nel perimetro aziendale, il sovradimensionamento si trasforma in spesa Capitale immobilizzata, e il sottodimensionamento in rischio di servizio interrotto.

C’è una conseguenza strutturale più ampia. L’apertura di dataset come FineServe riduce l’asimmetria informativa tra chi eroga servizi LLM su cloud su scala planetaria e chi deve allestire un ambiente privato. Con workload generator condivisi, i fornitori di hardware e software possono concorrere su benchmark trasparenti, mentre le organizzazioni guadagnano autonomia nella progettazione dell’infrastruttura. Il serving smette di essere una scatola nera tarata su pattern altrui e diventa una funzione ingegneristica governabile, perfino predicibile. O almeno, un po’ meno cieca.