Saluki 27B: Qwen3.8 quantizzato in 7,9 GB mantiene il tool-calling

Saluki 27B comprime Qwen3.8-27B in 7,9 GB, dichiara circa due bit per peso e, nei test degli autori, supera la build da 54 GB su 120 task di function calling scelti dal Berkeley Function Calling Leaderboard¹.

Il confronto parte dai file GGUF in una copia di llama.cpp senza modifiche. Gli autori affiancano Saluki e la quantizzazione di riferimento dello stesso modello, poi eseguono un diff degli header tensor per tensor per cercare differenze nei metadati¹. Passano al contenuto. Confrontano i byte per capire se Saluki riusa i bit della quantizzazione di partenza o se il contenuto cambia. L’analisi scende oltre i nomi dei tensori e controlla la corrispondenza byte per byte¹.

Il progetto dichiara la base: la quantizzazione GSQ-RCO di ISTA-DASLab applicata a Qwen3.8-27B. La domanda che guida il tutorial è netta. Saluki è un remix dei bit esistenti o un modello che modifica la rappresentazione? La risposta viene cercata sia con l’ispezione dei file sia in esecuzione¹.

La prova in runtime usa una singola GPU e la stessa cornice per entrambe le build. Ogni modello viene caricato in llama.cpp. Gli autori leggono l’uso di memoria e misurano la velocità di servizio. Mantengono costanti ambiente e procedure per ridurre l’effetto di variabili esterne¹.

La valutazione funzionale segue il Berkeley Function Calling Leaderboard. Gli autori selezionano 120 task con seme fisso. Usano il checker del BFCL in due modalità di parsing, strict e lenient, per contare successi e fallimenti con criteri diversi. Applicano lo stesso protocollo a entrambe le build¹.

Il risultato dichiarato è il punto del lavoro: Saluki mantiene il tool-calling nonostante la compressione e, nel loro confronto, la build da 7,9 GB supera quella da 54 GB sul set di 120 task. Il giudizio usa il checker del BFCL, con le due modalità di parsing e lo stesso seme, all’interno della stessa cornice di test¹.

Il tutorial pubblica anche il codice dell’esperimento. Import standard, strutture dati per raccogliere i risultati, funzioni per lanciare, misurare e confrontare i due modelli in modo ripetibile. La documentazione chiarisce l’ordine delle operazioni, dalla lettura degli header alla misura di memoria e throughput, fino al conteggio dei successi nel function calling¹.

Gli autori concludono che Saluki, costruito sulla GSQ-RCO e compresso a circa due bit per peso, tiene il tool-calling e si comporta meglio della build piena da 54 GB nel perimetro della loro prova su 120 task BFCL selezionati con seme fisso¹.

Se questo risultato regge oltre il set scelto, indica che una quantizzazione aggressiva può preservare le capacità di tool-calling e ridurre in modo netto l’impronta di memoria. Resta un limite chiaro: numeri, protocollo e selezione dei task provengono dal tutorial degli autori. Servono repliche indipendenti sul BFCL e su compiti diversi per misurare quanto il vantaggio si generalizzi¹.