PS5LM Plus: un modello da 27 miliardi di parametri sulla GPU di una PS5
Il porting di llama.cpp su PS5 mostra come accesso alla GPU, quantizzazione e gestione della memoria condizionino l’inferenza locale.
Newsletter del 15 ottobre 2026
PS5LM Plus porta l’inferenza di llama.cpp sulla GPU di una PlayStation 5 con jailbreak. Nel README del progetto, l’autore riporta circa 20 token al secondo per una versione quantizzata di Qwen3.8 da 27 miliardi di parametri. Il caso interessa soprattutto chi studia il porting di motori di inferenza: mostra quanto contino il contesto di esecuzione, la memoria accessibile e la gestione delle risorse.
Non è una funzione ufficiale della console. PS5LM Plus è un fork del lavoro di Mert Cobanov: il progetto originale fornisce il porting di llama.cpp, il payload e la ricerca di base; il fork aggiunge l’applicazione nativa con accesso alla GPU. Le prestazioni sono misure dichiarate dal progetto, senza una verifica indipendente nella documentazione fornita.
Il passaggio decisivo: diventare un’applicazione nativa
Secondo il README, l’esecuzione come payload offre circa 6 GiB di memoria e nessun accesso alla GPU. Un’applicazione nativa, eseguita come titolo della console, può invece accedere a 12 GiB di memoria diretta e alla GPU.
PS5LM Plus integra quindi llama-server con il backend Vulkan di ggml e il porting RADV di Mihawk-99. La configurazione descritta espone un unico heap Vulkan da 11,44 GiB.
Questa distinzione spiega il risultato meglio del solo numero di token al secondo. L’autore riferisce che il modello da 27 miliardi di parametri, eseguito sulla CPU come payload con lettura progressiva da disco, produceva circa un token al minuto. Il confronto coinvolge però anche modalità di caricamento e risorse differenti: non permette di isolare un fattore di accelerazione attribuibile soltanto alla GPU.
Prestazioni dichiarate e condizioni da conservare
Il README associa ogni velocità a una specifica combinazione di modello, quantizzazione, contesto e cache KV. Sono dettagli necessari per interpretare i risultati.
| Modello e quantizzazione | Dimensione indicata | Contesto e cache KV | Generazione dichiarata |
|---|---|---|---|
| Qwen3.8-27B UD-Q2_K_XL | 9,2 GiB | 32k, q4_0 | 20,3 token/s |
| Qwen3.8-27B UD-IQ2_XXS | 6,8 GiB | 64k, q8_0 | 20,7 token/s |
| Gemma 4 E4B QAT q4_0, da USB | 4,8 GiB | 64k, q4_0 | 61 token/s |
| Llama 3.2 3B Instruct Q4_K_M, da USB | 1,9 GiB | 64k, q8_0 | 124 token/s |
Per la prima configurazione Qwen, l’autore segnala anche una risposta di 7.775 token generata a 19,7 token/s. È un dato aggiuntivo su una generazione lunga, non una dimostrazione della velocità per qualsiasi richiesta.
La fonte non presenta un protocollo completo con prompt, ripetizioni e variabilità delle misure. Non documenta inoltre confronti di qualità fra le due quantizzazioni Qwen. Velocità simili non dimostrano quindi risposte equivalenti, né la colonna del contesto misura la latenza necessaria a elaborare un prompt di quella lunghezza.
La memoria richiede un bilancio esplicito
L’heap disponibile deve contenere più dei soli pesi del modello. La dashboard distingue memoria del modello, cache KV e altre allocazioni; il pianificatore sceglie il contesto più lungo e il tipo di cache ritenuto migliore fra quelli compatibili con la memoria libera.
La conseguenza pratica è che la dimensione del file GGUF costituisce solo il primo controllo. Un modello può lasciare spazio insufficiente alla configurazione di contesto desiderata. La libreria mostra per ciascun file il contesto previsto, la cache e la possibilità di caricamento.
Le due configurazioni Qwen illustrano questo compromesso: quella da 6,8 GiB è riportata con contesto 64k e cache q8_0, quella da 9,2 GiB con 32k e q4_0. È un esempio documentato di allocazioni differenti, non una regola universale sulla qualità.
Esiste anche un limite operativo concreto: secondo l’autore, scaricare un modello senza terminare l’applicazione lascia circa 5 GiB del pool occupati. Il cambio di modello avviene perciò riavviando l’app. Chi valuta un uso interattivo dovrebbe misurare anche quel tempo, oltre alla generazione.
Requisiti e criteri per una valutazione utile
Il progetto richiede una PS5 già sottoposta a jailbreak, con kstuff-lite, etaHEN e ShadowMountPlus caricati. elfldr è fortemente consigliato per avviare il componente che espone sensori e spazio libero effettivo; ftpsrv è consigliato per installazione e trasferimenti.
L’applicazione serve una chat e API sulla porta 8081 della console. Il README dichiara compatibilità con OpenAI Chat Completions e Responses, oltre ad Anthropic Messages. Questa indicazione permette di pianificare prove d’integrazione, ma non certifica ogni funzionalità dei client.
Una valutazione concreta dovrebbe registrare:
- tempo di caricamento e di cambio modello;
- latenza della prima risposta e velocità sulle proprie richieste;
- qualità delle risposte con ciascuna quantizzazione;
- memoria residua al contesto desiderato;
- comportamento del client con le API utilizzate.
La dashboard espone anche potenza, temperature ed energia per token. La fonte non fornisce però risultati energetici comparabili: la presenza della telemetria non dimostra maggiore efficienza.
FAQ
Basta possedere una PS5 per usare PS5LM Plus?
No. Servono jailbreak e componenti homebrew elencati dal progetto. L’evidenza fornita non specifica una matrice di compatibilità fra firmware e modelli di console.
Qualsiasi file GGUF può essere caricato?
Il README lega la compatibilità al supporto di llama.cpp e alla memoria disponibile. Il formato GGUF, da solo, non garantisce che un modello rientri nelle risorse della console.
I modelli possono restare su un disco esterno?
Sì: il progetto documenta il caricamento diretto da USB o unità M.2. Per USB indica exFAT. Questo evita una copia interna, ma non elimina i vincoli della memoria necessaria all’inferenza.