SiliconBench: velocità, memoria e fedeltà nel serving di LLM su computer desktop con memoria unificata

Abstract degli autori

Il serving locale di LLM con richieste concorrenti su computer desktop con memoria unificata deve preservare un margine di memoria disponibile e la fedeltà degli output, aspetti trascurati dalle classifiche basate solo sulla velocità. Presentiamo SiliconBench, che valuta nove motori di serving per Apple Silicon sotto tre aspetti: velocità, memoria e fedeltà. Valutiamo il serving per chat e agenti su Qwen3, Qwen3.5 e Gemma 4. Usiamo un compito di classificazione per verificare eventuali peggioramenti della qualità rispetto a un riferimento NVIDIA. DGX Spark fornisce un ulteriore riferimento per le prestazioni di serving. Tre criteri desiderabili guidano l’interpretazione: maturità dell’architettura di serving, gestione della memoria e scalabilità multinodo. Su Qwen3-0.6B, solo vllm-metal più che raddoppia il throughput in entrambi i carichi di lavoro passando da un livello di concorrenza di 1 a 16. CUDA vLLM e SGLang mostrano una maggiore scalabilità al crescere delle richieste concorrenti con gli stessi prompt. Budget di memoria espliciti non garantiscono un margine di memoria disponibile: due stack completano tutte le richieste mentre l’uso della memoria si avvicina alla capacità fisica e il throughput diminuisce. Le architetture dei modelli più recenti sono supportate da un numero inferiore di motori. Le implementazioni valutate eguagliano il riferimento per la fedeltà. Solo tre stack soddisfano i criteri di completamento, fedeltà e copertura dei modelli. I confronti su modelli densi e MoE più grandi confermano l’importanza di pianificare l’elaborazione dei prompt insieme alla generazione in corso: il percorso di prefill-decode combinato di vllm-metal mantiene una latenza del primo token inferiore a quella di omlx con richieste concorrenti. Nelle configurazioni testate con due macchine, il parallelismo tensoriale tramite Thunderbolt RDMA scala, mentre il parallelismo a pipeline tramite TCP registra un peggioramento delle prestazioni. Rilasciamo il codice del benchmark, i risultati di ogni esecuzione e i diari di manutenzione, avvalendoci di un workflow che combina correzioni circoscritte apportate dagli agenti e revisione umana.