The Pulse

SGLang registra una latenza di 18,7 ms nel valutare decisioni con 16 opzioni

Nel benchmark di multi-item scoring di SGLang, la latenza p95 per decisioni con 16 opzioni è stata di 18,7 ms con Qwen3-0.6B. Secondo LMSYS, il metodo riutilizza il calcolo relativo alla query condivisa mantenendo separate le valutazioni de

AI.info Team · Scritto con l’IA · verificato · 2026-09-26

SGLang ha misurato una latenza p95 di 18,7 millisecondi per attribuire un punteggio a 16 azioni candidate con Qwen3-0.6B, contro 39,6 millisecondi con la generazione di un token. Il benchmark, pubblicato il 25 settembre da LMSYS, esamina come l’ambiente di esecuzione gestisce i compiti decisionali che richiedono un punteggio o una categoria anziché una spiegazione generata. La sua modalità di multi-item scoring riutilizza il calcolo relativo alla query condivisa mantenendo separata la valutazione di ciascun candidato.

Una query condivisa, 16 candidati da valutare

I test usano compiti a scelta tratti dal dataset Open-Jev, nei quali la domanda e il suo contesto restano invariati mentre un modello valuta più risposte possibili. Il multi-item scoring, o MIS, di SGLang consente all’ambiente di esecuzione di riutilizzare quel contesto ripetuto all’interno di una richiesta. Ogni candidato continua a prendere in considerazione soltanto la query condivisa e il proprio testo, quindi i candidati non vengono riuniti in un unico prompt di scelta.

Con 16 opzioni, il post riporta latenze p95 per la decisione di 18,7 millisecondi per Qwen3-0.6B con MIS, 39,6 millisecondi con la generazione e 24,3 millisecondi con lo scoring di un singolo elemento. Qwen3-8B ha registrato 20,6 millisecondi con MIS, contro 54,1 millisecondi con la generazione e 53,1 millisecondi con lo scoring di un singolo elemento. Per Qwen3.5-4B il miglioramento è stato più contenuto: 55,7 millisecondi con MIS, contro 84,8 millisecondi con la generazione e 74,4 millisecondi con lo scoring di un singolo elemento.

«La latenza di MIS resta pressoché invariata quando il numero di opzioni passa da 2 a 16, coerentemente con la ripartizione del calcolo relativo alla query condivisa tra i candidati», scrivono Sundara Raman Ramachandran, Chuanrui Zhu, Qing Lan, Shri Rajamanikandan Vasudevan, Jian Sheng, I-Ting Chen e Fedor Borisyuk.

La Score API richiede etichette specifiche

Il post descrive anche la Score API /v1/score di SGLang, che permette a chi invia la richiesta di specificare i punteggi dei token corrispondenti alle etichette di cui ha bisogno, come Yes e No, invece di fare affidamento sulle probabilità logaritmiche top-k restituite da una risposta di generazione affinché includano quelle etichette. L’ambiente di esecuzione può evitare il campionamento dei token, non calcolare le probabilità logaritmiche non necessarie per i token in input e raccogliere in batch i punteggi richiesti per le etichette. Gli autori avvertono che questo non elimina la proiezione sul vocabolario né la normalizzazione sull’intera distribuzione.

L’API e MIS intervengono su aspetti diversi del carico di lavoro: le etichette esplicite definiscono quali punteggi riceve l’applicazione, mentre MIS riutilizza il calcolo tra i candidati. Abilitare soltanto l’API non attiva MIS. La configurazione dell’esempio richiede un modello e un backend supportati; per l’esempio con Qwen3-0.6B, LMSYS specifica FlashInfer e disabilita la cache radix e il chunked prefill.

Una latenza inferiore non dimostra che le decisioni siano migliori

LMSYS ha testato Qwen3-0.6B, Qwen3-8B e Qwen3.5-4B su una GPU NVIDIA H200 con SGLang su CUDA 13.0. I benchmark confrontano il tempo p95 end-to-end necessario per completare l’attribuzione dei punteggi ai candidati di una domanda, non la latenza di un solo candidato. Con carichi offerti più elevati, il vantaggio di MIS variava a seconda del modello; secondo il post, a carico basso non era sistematicamente più veloce.

I risultati riguardano le prestazioni del sistema di erogazione, non stabiliscono se i diversi metodi di scoring scelgano altrettanto bene. Gli autori avvertono inoltre che i tassi di richieste offerti non mostrano, da soli, il throughput effettivamente raggiunto e raccomandano di misurare la latenza ai percentili più alti con il carico previsto per l’impiego. Per i team che usano i modelli per instradare azioni o ordinare risposte, l’accelerazione riportata riguarda la rapidità con cui arrivano i punteggi, non la capacità di quei punteggi di portare all’azione giusta.