Nei benchmark LLM in locale su un single-board computer ARM, la NPU da 6 TOPS del Rockchip RK3588 genera token più in fretta della CPU, ma il vantaggio reale è del 17-42% a seconda del modello — non l'ordine di grandezza che i "6 TOPS" lasciano immaginare. Il motivo è fisico: la generazione di un LLM è limitata dalla banda di memoria, non dalla potenza di calcolo. L'ho misurato sul mio Orange Pi 5 Pro, CPU contro NPU, sullo stesso modello.
Disclosure: ho richiesto io l'Orange Pi 5 Pro a Orange Pi per provarla in laboratorio; me l'hanno inviata gratuitamente, senza alcun compenso e senza alcun accordo o condizione sui contenuti. Quello che leggi sono test e opinioni miei, completamente indipendenti.
Il motivo fisico: memoria, non potenza di calcolo
Generare un token in un LLM, nella fase di decode, richiede di caricare dalla LPDDR5 i pesi di tutti i layer — sequenzialmente, per ogni singolo token prodotto. Il token N+1 dipende logicamente dal token N; non esiste parallelismo da sfruttare su questo percorso, e nessuna architettura può aggirare questa dipendenza causale. La velocità di generazione è condizionata quasi interamente dalla banda della memoria, non dalla capacità di calcolo dell'acceleratore. I TOPS misurano quante operazioni l'hardware può eseguire in parallelo, ma non è di questo che ha bisogno il decode.
La NPU del RK3588 ha tre core progettati per carichi massivamente paralleli — classificazione immagini, reti convoluzionali, batch di inferenze su computer vision. Su quei carichi, i 6 TOPS dichiarati sono reali. Su un LLM in decode, quei core ricevono i pesi di un token alla volta, eseguono una serie di moltiplicazioni matriciali, e poi aspettano che la LPDDR5 consegni i pesi del token successivo. Il collo di bottiglia si trasferisce sul bus memoria, dove CPU e NPU competono in modo molto più simmetrico di quanto i TOPS nominali lascino immaginare.
C'è un secondo fattore che riduce ulteriormente il gap. La quantizzazione standard per il path CPU su SBC è q4_k_m: 4 bit per peso. La NPU RK3588 supporta esclusivamente W8A8: 8 bit per peso. Non è una configurazione scelta — è un vincolo hardware. Su un modello da 1.5 miliardi di parametri, W8A8 trasferisce il doppio dei byte per ogni token generato rispetto a q4_k_m. La NPU parte già in svantaggio sulla dimensione che è esattamente il collo di bottiglia.
OpenClaw homelab: AI gateway self-hosted e tool calling da 5 minuti
openclaw homelab con Ollama su LattePanda: 52 skill, AI gateway self-hosted su WhatsApp e Telegram. Il tool calling su CPU m3-8100Y costa 5 minuti reali.
Confronto non a parità di bit I benchmark in questo post confrontano q4_k_m su CPU con w8a8 su NPU. È "cosa giri davvero su ciascun path" — non una gara artificiale. Q4 è lo standard pratico per CPU su SBC; W8A8 è l'unico formato che la NPU RK3588 accetta.
L'ho misurato sull'Orange Pi 5 Pro che ho nel lab: RK3588S a 16GB, Ubuntu Rockchip, governor performance con LPDDR5 fissata a 2400 MHz, board idle. Il path CPU usa Ollama con q4_k_m; il path NPU usa lo stack RKLLM 1.1.4 con driver 0.9.6, modelli in formato .rkllm pre-convertiti.
20.3 tok/s.
Questo è TinyLlama 1.1B sulla NPU, con queste impostazioni. Sulla CPU, lo stesso modello pesa 16.0 tok/s. Il silenzio dopo quel numero è parte del messaggio: +27% è reale, misurabile, utile — ed è anche tutto quello che c'è.
Per Qwen2.5 1.5B: CPU 12.1 tok/s, NPU 14.2 tok/s (+17%). Per Qwen2.5 3B: CPU 6.6 tok/s, NPU 7.9 tok/s (+20%). Per Qwen2.5 7B: CPU 2.8 tok/s, NPU 3.93 tok/s (+42%). Sul 7B il vantaggio della NPU cresce — il modello gira (il file w8a8 da ~7.6 GB sta nei 16 GB della board e produce output coerente) — ma entrambi i path restano a 3-4 tok/s, troppo lenti per un uso interattivo continuato. Il range +17-27% è consistente sui modelli 1-3B, che è la fascia effettivamente utile su questa classe di hardware.
Una nota necessaria su questi numeri: sono best-case, con DDR pinnata. Con le impostazioni di default di Ubuntu Rockchip, il governor DDR dmc_ondemand rimane bloccato a 534 MHz. In quella configurazione, la NPU su Qwen2.5 1.5B scende a circa 10.6 tok/s — sotto la CPU con governor ottimizzato. Pinnare la DDR a 2400 MHz è il primo passo obbligatorio prima di qualsiasi confronto significativo. Chi trova online risultati in cui la NPU risulta più lenta della CPU sull'Orange Pi ha quasi certamente dimenticato questo passaggio.
I benchmark RKLLM ufficiali Rockchip pubblicati nel luglio 2024 (via CNX Software) indicano 15.03 tok/s su TinyLlama 1.1B e 6.46 tok/s su Phi-3 3.8B su RK3588. I miei numeri su Qwen2.5 1.5B (14.2 tok/s NPU) sono nello stesso ordine di grandezza — le variazioni riflettono le differenze architetturali tra modelli, non anomalie di misura.
La meccanica è nota: il pre-fill — parallelizzabile — beneficia in modo significativo della NPU. Il decode invece non scala allo stesso modo perché è strutturalmente sequenziale: la NPU accelera il completamento del pre-fill, poi la generazione torna a essere dominata dalla banda di memoria. Il risultato è il +17-27% misurato sopra, non un ordine di grandezza.
Orange Pi 5 Pro vs Raspberry Pi 5: architetture diverse, costi diversi
L'assenza di NPU integrata nel Raspberry Pi 5 è un fatto tecnico del SoC Broadcom BCM2712 — quattro Cortex-A76 a 2.4 GHz, senza alcun acceleratore AI on-die. Per avere accelerazione AI su Raspberry Pi 5 la strada è esterna: un add-on basato su chip Hailo, collegato via PCIe attraverso l'interfaccia HAT+. Non è parte del SoC — è hardware separato da comprare, montare e configurare, con un costo aggiuntivo non trascurabile.
Questa differenza architetturale cambia il calcolo economico in modo non ovvio. Su Orange Pi 5 Pro la NPU è inclusa nel SoC RK3588: zero costo aggiuntivo, zero hardware extra, nessun HAT da comprare. Chi ha già una scheda nel proprio homelab non deve acquistare nulla per accedere alla NPU. Su Raspberry Pi 5, invece, usare un acceleratore significa comprare un add-on a parte — un costo che può avvicinarsi a quello di una seconda board entry-level. Sul rapporto costo/prestazioni dell'hardware per LLM in locale ho ragionato più in generale in quanto costa l'hardware per un LLM in casa.
Il confronto su CPU pura, escludendo la NPU, è più equilibrato. Il paper arxiv 2511.07425 (novembre 2025, 25 LLM testati su tre piattaforme con q4_k_m) misura il Raspberry Pi 5 da 8GB su modelli da 1.5B nella fascia 5-15 tok/s. L'Orange Pi 5 Pro su modelli da 3-7B si assesta su 1.5-5 tok/s. I range non sono direttamente confrontabili — i modelli testati differiscono — ma indicano che su CPU pura le due board sono nella stessa fascia di performance a parità di prezzo. Il vantaggio reale dell'Orange Pi 5 Pro emerge solo quando si attiva la NPU. Per un'idea di cosa renda un mini-PC sul solo path CPU con Ollama, ho misurato un caso simile nel benchmark del LattePanda Alpha.
Modelli e quantizzazione: cosa gira davvero tra 1B e 7B
Su un SBC, dove la memoria è condivisa tra sistema operativo e modello, il range pratico va da architetture sub-1B fino a 7B — e il 7B è già borderline per qualsiasi uso interattivo. Il paper arxiv 2511.07425 è esplicito su questo: i modelli fino a 1.5 miliardi di parametri sono quelli che gli SBC riescono a supportare in modo affidabile su tutte le piattaforme testate. I modelli 3-7B su Orange Pi 5 Pro con CPU si assestano su 1.5-5 tok/s, usabili per pipeline batch o automazioni, non per un chatbot che deve rispondere in tempo reale. Modelli oltre 7B su un singolo SBC senza clustering non compaiono nella letteratura recente come configurazione pratica — non perché sia impossibile, ma perché il risultato è talmente lento da non essere utile.
La quantizzazione è determinante quanto il numero di parametri. Q4_k_m su CPU è lo standard de facto su SBC — il paper 2511.07425 lo usa come riferimento su tutte e tre le piattaforme testate. W8A8 su NPU RK3588 non è una scelta: è l'unico formato accettato. Non si prende un file GGUF da HuggingFace e lo si carica sulla NPU — serve il formato .rkllm prodotto dalla toolchain Rockchip. Questo limita il catalogo di modelli disponibili su NPU a un sottoinsieme molto più ristretto rispetto all'ecosistema GGUF.
Per uso pratico, il mapping è approssimativo ma utile. Un agente che deve rispondere in meno di cinque secondi su input brevi: 1-1.5B su NPU, fascia 14-20 tok/s (numeri misurati sopra). Elaborazione in background senza vincoli stretti di latenza: 3B su NPU o CPU, 6.5-8 tok/s. Pipeline batch o sperimentazione: 7B su CPU, 2.8 tok/s, accettando la lentezza come condizione di progetto.
llama.cpp in esecuzione diretta guadagna il 10-20% in generazione su Raspberry Pi 5 rispetto al wrapper, secondo Stratosphere Labs. Per chi vuole massimizzare la performance sul path CPU senza il setup NPU, vale la pena considerarlo.
Il setup NPU: dove va il tempo
Il percorso NPU su Orange Pi 5 Pro non è "installa un pacchetto e scarica un modello in cinque minuti". Il sistema operativo richiesto è Ubuntu con kernel Rockchip — non una distribuzione generica. La libreria da compilare è rknn-llm 1.1.4, nativamente su aarch64. Il formato modello è .rkllm, prodotto dalla toolchain Rockchip: nessun file GGUF funziona sulla NPU senza conversione, e l'ecosistema GGUF a cui la maggior parte degli utenti è abituata non è compatibile. Queste tre dipendenze, messe in fila, si traducono in alcune ore di configurazione prima del primo token generato. Il guadagno concreto al termine c'è: +17–20% in tok/s in generazione rispetto alla CPU su modelli nella fascia 1.5-3B. Vale. Ma prima va messo nel conto il costo per arrivarci, con alcune trappole non ovvie da conoscere prima di iniziare.
Il punto di partenza è un sistema operativo con driver Rockchip NPU: Ubuntu con kernel Rockchip community è il riferimento più documentato. La libreria rknn-llm fornita di default è la versione 1.0.1. Per la 1.1.4 — necessaria per i numeri riportati sopra — serve una build nativa su aarch64 e la si passa via LD_LIBRARY_PATH. Non esiste un pacchetto apt.
Nessun file GGUF è compatibile con la NPU. Serve il formato .rkllm, prodotto dalla toolchain rknn-toolkit2 di Rockchip. I modelli pre-convertiti disponibili su HuggingFace sono un sottoinsieme ristretto rispetto all'ecosistema GGUF. Chi vuole un modello specifico deve convertirlo: la toolchain gira su x86_64 Linux, non nativamente su aarch64, il che significa fare la conversione su un'altra macchina e trasferire il file risultante.
C'è un problema specifico con il download di file .rkllm di dimensioni significative da HuggingFace. Il CDN Xet (us.aws.cdn.hf.co), usato per i file grandi, produce corruzione silenziosa con aria2: l'URL firmata scade sull'ultimo chunk, il file risulta apparentemente scaricato ma è troncato, e l'output del modello è gibberish senza messaggi di errore diagnostici. Il workaround documentato è usare hf-mirror.com come endpoint alternativo.
Un problema di comportamento riportato in più fonti: i modelli su NPU tendono a produrre output incoerente o ripetitivo oltre una certa lunghezza — il fenomeno descritto come "talks to itself". Esiste un limite pratico sulla lunghezza del contesto gestibile in modo affidabile, più basso rispetto alla stessa architettura su CPU. Non compromette l'usabilità su input brevi e task ben definiti; diventa rilevante su conversazioni lunghe.
Sul fronte energetico c'è il vantaggio strutturale degli SBC: l'intera scheda assorbe pochi watt, ordini di grandezza meno di una GPU desktop sotto carico. Per un servizio always-on con modelli nella fascia 1-3B è proprio questo a renderli interessanti — non la velocità di picco, ma il consumo. Tra path CPU e NPU la differenza di assorbimento è comunque secondaria: il collo di bottiglia resta la memoria.
Il setup NPU vale per chi ha familiarità con il debugging di toolchain ARM, ha un caso d'uso concreto in cui il +20% cambia qualcosa di misurabile, e può investire alcune ore nella configurazione iniziale. Per chi vuole girare un LLM locale sul proprio SBC senza complessità, il path CPU resta la scelta più solida — più aggiornabile, perché l'ecosistema GGUF evolve molto più velocemente del catalogo .rkllm. Discorso diverso per le NPU integrate nelle piattaforme x86 recenti, come quelle Ryzen AI: ne ho scritto in NPU Ryzen AI per LLM su Linux.
2.8 tok/s.
Domande frequenti
La NPU dell'Orange Pi 5 Pro rende davvero più della CPU per gli LLM?
Sì, ma poco. Nei miei test la generazione di token va dal 17 al 42% più veloce sulla NPU rispetto alla CPU, a seconda del modello. Non è l'ordine di grandezza che i "6 TOPS" lasciano immaginare, perché la generazione è limitata dalla banda di memoria, non dalla potenza di calcolo dell'acceleratore.
Il Raspberry Pi 5 ha una NPU per far girare gli LLM?
No. Il SoC Broadcom BCM2712 del Pi 5 ha solo CPU, nessun acceleratore AI integrato. Per avere accelerazione serve un add-on esterno — un HAT basato su chip Hailo collegato via PCIe — con hardware e costo a parte.
Che modelli posso far girare su un Orange Pi 5 Pro?
La fascia comoda è 1-3B (Qwen2.5, TinyLlama, Gemma, Llama 3.2) quantizzati a 4 bit. Un 7B gira ma a circa 3-4 tok/s, troppo lento per un uso interattivo continuato. Oltre i 7B su una singola board non è una configurazione pratica.
Perché la NPU non va 10 volte più veloce nonostante i 6 TOPS?
Perché generare token in un LLM è un'operazione sequenziale e memory-bound: ogni token impone di rileggere i pesi dalla memoria, e i TOPS non aiutano su questo percorso. In più la NPU RK3588 accetta solo pesi a 8 bit, che muovono il doppio dei dati rispetto ai 4 bit usati sulla CPU.
I dati di benchmark su piattaforme SBC con q4_k_m provengono dal paper arxiv 2511.07425 (novembre 2025, 25 LLM su tre piattaforme). I benchmark RKLLM ufficiali Rockchip (TinyLlama 1.1B, Qwen 1.8B, Phi-3 3.8B, ChatGLM3 6B) sono riportati da CNX Software da documentazione Rockchip luglio 2024. Il setup NPU e i problemi noti sull'Orange Pi 5 Pro sono documentati su XDA Developers. Il confronto qualitativo tra i due percorsi è discusso da Ominous Industries. Il vantaggio di llama.cpp diretto su Raspberry Pi 5 viene da Stratosphere Labs. I benchmark NPU (CPU vs NPU su Qwen2.5/TinyLlama, governor performance) sono misure mie dirette sull'Orange Pi 5 Pro, 26 giugno 2026.
Resta Aggiornato
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
