Negli ultimi anni la crescente attenzione verso la privacy dei dati e la necessità di ridurre la dipendenza dalle infrastrutture cloud hanno spinto sviluppatori e ricercatori a sperimentare soluzioni di completamente locali. Un assistente vocale offline, capace di riconoscere la voce, comprendere il contenuto e generare risposte sintetiche senza inviare alcuna informazione a server remoti, rappresenta una risposta concreta a queste esigenze. Solus è uno dei progetti più recenti in questo ambito: combina modelli open‑source per il riconoscimento automatico del parlato (STT), la generazione del linguaggio naturale (LLM) e la sintesi vocale (TTS) in un unico stack eseguibile su laptop o desktop di fascia media. Questo articolo fornisce un'analisi tecnica approfondita dell'architettura ibrida CPU/GPU adottata da Solus, evidenziando le scelte di ottimizzazione necessarie per far funzionare un modello LLM da 7 billion di parametri su una scheda grafica con soli 4 GB di VRAM.

Panoramica dello stack tecnologico di Solus

Solus è costruito attorno a quattro componenti principali, tutti disponibili sotto licenza open‑source:

• Whisper (‑whisper) per il riconoscimento vocale, eseguito in modalità offline;
•  7B tramite il runtime , che fornisce l'inferenza del modello di linguaggio;
• Piper per la sintesi vocale, capace di trasformare il testo generato dal LLM in audio;
• Un backend ibrido Python/Node.js e una semplice interfaccia web monofile che gestiscono la comunicazione tra i tre moduli.

La scelta di questi strumenti è motivata dalla loro licenza permissiva, dalla documentazione estesa e dalla capacità di funzionare su sistemi operativi Windows e Linux senza richiedere componenti proprietari. L’intero flusso – dalla registrazione dell’audio all’emissione della risposta – avviene all’interno della macchina dell’utente, garantendo che nessun dato sensibile lasci il dispositivo.

Riconoscimento vocale con Whisper

Whisper è un modello di trascrizione sviluppato da , disponibile in diverse dimensioni (tiny, base, small, medium, large). Solus utilizza la versione “small” per bilanciare accuratezza e consumo di risorse. La particolarità di Whisper è la sua capacità di operare interamente sulla CPU, sfruttando le istruzioni SIMD per accelerare le operazioni di convoluzione. In ambienti con GPU limitata, mantenere Whisper sulla CPU è una strategia consolidata: libera la memoria video per il modello LLM, che è più esigente in termini di VRAM.

LLM 7B via

 7B è un modello di linguaggio di grandi dimensioni (circa 7 billion di parametri) rilasciato con licenza Apache 2.0. Il runtime consente di caricare il modello direttamente nella GPU, sfruttando le ottimizzazioni di PyTorch e le librerie CUDA per l’inferenza. Su una scheda GTX 1650 con 4 GB di VRAM, il modello occupa quasi tutta la memoria disponibile, rendendo indispensabile una gestione attenta delle risorse. supporta la quantizzazione a 8‑bit (int8) e la conversione a precisione mista (fp16), riducendo il footprint di memoria senza compromettere drasticamente la qualità delle risposte.

Sintesi vocale con Piper

Piper è una soluzione TTS leggera, basata su modelli di rete neurale addestrati su dataset multilingue. Come Whisper, Piper può essere eseguito sulla CPU, poiché il carico computazionale richiesto per la generazione di brevi frasi è contenuto. La latenza tipica è inferiore a un secondo, rendendo possibile una risposta quasi in tempo reale una volta che il testo è stato prodotto dal LLM.

Backend e interfaccia web

Il backend di Solus è costituito da un server Python che gestisce le chiamate a Whisper e Piper, e da un processo Node.js che espone un’API REST per l’interfaccia web. L’interfaccia è un singolo file HTML che utilizza Web Audio API per catturare l’audio del microfono, inviarlo al server e riprodurre la risposta sintetizzata. L’assenza di un processo di build complesso rende l’applicazione facilmente distribuibile: basta clonare il repository, installare le dipendenze e avviare i due server.

Vincoli hardware: la realtà dei laptop con GPU 4 GB

Molti utenti che desiderano sperimentare assistenti vocali offline possiedono laptop dotati di GPU di fascia media, come la NVIDIA GTX 1650 o la RTX 3050 con 4 GB di VRAM. Queste schede offrono una potenza di calcolo sufficiente per operazioni di inferenza su modelli di medie dimensioni, ma presentano limiti evidenti:

• Capacità di memoria video limitata, che impedisce il caricamento simultaneo di più modelli;
• Bandwith di memoria inferiore rispetto a soluzioni di fascia alta, con impatto sulla velocità di trasferimento dei tensori;
• Assenza di supporto hardware per la quantizzazione a 4‑bit, che è disponibile solo su GPU più recenti.

Questi vincoli richiedono una progettazione attenta dell’architettura, con una chiara separazione dei compiti tra CPU e GPU per evitare conflitti di memoria e garantire una latenza accettabile.

Distribuzione dei carichi: CPU vs GPU

La decisione di posizionare Whisper e Piper sulla CPU e sulla GPU nasce da una valutazione pratica delle risorse disponibili. La GPU è l’unico componente in grado di gestire l’inferenza di un modello LLM di 7 B in tempi ragionevoli, grazie alla sua capacità di parallelizzare le operazioni matriciali. Al contrario, Whisper, pur potendo beneficiare di accelerazione GPU, è più leggero e può essere eseguito in modo efficiente sulla CPU senza saturare le risorse di sistema.

Gestione della memoria VRAM

Su una GTX 1650, occupa quasi tutti i 4 GB di VRAM. Per evitare il sovraccarico, è fondamentale impostare la memoria di lavoro di Whisper a 0 GB di VRAM, forzando l’esecuzione sulla CPU. fornisce parametri di configurazione per limitare la quantità di memoria riservata al modello, consentendo di riservare una piccola porzione di VRAM per le operazioni di trasferimento dati e per eventuali buffer temporanei.

Bilanciamento del carico di lavoro

Il flusso di lavoro tipico di Solus può essere rappresentato come una pipeline a tre stadi:

1. STT (Whisper): acquisizione audio → trascrizione testuale (≈2 s);
2. LLM (): elaborazione del prompt → generazione della risposta (≈6‑8 s);
3. TTS (Piper): sintesi vocale della risposta (≈1 s).

Poiché i tre stadi sono sequenziali, la latenza totale è la somma delle singole durate. Tuttavia, è possibile introdurre un livello di parallelismo limitato, ad esempio avviando la sintesi TTS non appena il LLM ha prodotto la prima porzione di testo, riducendo così la percezione di attesa da parte dell’utente.

Analisi delle prestazioni su una GTX 1650 4 GB e Ryzen 5 5600H

Il test di riferimento effettuato dall’autore di Solus su una configurazione tipica di laptop con GPU GTX 1650 e CPU Ryzen 5 5600H ha prodotto i seguenti risultati:

• Whisper (CPU): circa 2 secondi di latenza, con utilizzo della CPU al 65 %;
• (GPU): 6‑8 secondi di latenza, con utilizzo della GPU al 100 % e occupazione completa della VRAM;
• Piper (CPU): circa 1 secondo, variabile in base al carico di sistema.

La latenza complessiva di circa 10 secondi è accettabile per molte applicazioni domestiche, ma può risultare limitante per scenari interattivi più esigenti (ad esempio assistenza in tempo reale per disabili). Di seguito vengono analizzati i fattori che influenzano ciascuna fase.

Profilazione dei singoli componenti

La fase di riconoscimento vocale è la più veloce, ma il suo utilizzo della CPU al 65 % indica che il processore rimane disponibile per altre attività. La fase di inferenza LLM è il collo di bottiglia principale: l’occupazione al 100 % della GPU dimostra che il modello sfrutta appieno le capacità di calcolo della scheda, ma la limitata quantità di VRAM costringe a una gestione stretta dei tensori. La sintesi vocale, infine, è poco impegnativa e può essere ulteriormente ottimizzata con versioni più leggere del modello Piper.

Impatto della CPU sul riconoscimento vocale

Whisper utilizza la libreria torch per l’esecuzione su CPU, sfruttando le istruzioni AVX2/AVX512 quando disponibili. Sul Ryzen 5 5600H, che supporta AVX2, la latenza di 2 secondi è tipica per la versione “small”. Passare a una versione “tiny” ridurrebbe la latenza a meno di un secondo, ma al costo di una precisione inferiore, soprattutto in presenza di rumore di fondo.

Utilizzo della GPU per l’inferenza LLM

L’inferenza di su GPU è influenzata da due parametri chiave: la precisione dei pesi (fp16 vs int8) e la dimensione del batch. Su una GTX 1650, la quantizzazione a int8 permette di ridurre il consumo di VRAM di circa il 30 %, lasciando spazio a buffer temporanei. Tuttavia, la precisione int8 può introdurre una leggera degradazione della qualità della risposta, percepibile soprattutto in compiti di ragionamento complesso. L’utilizzo di batch di dimensione 1 è obbligatorio per mantenere la latenza bassa, poiché batch più grandi aumenterebbero il tempo di elaborazione senza fornire benefici significativi in un contesto di conversazione interattiva.

Strategie di ottimizzazione per hardware di fascia media

Per migliorare ulteriormente le prestazioni di Solus su sistemi con risorse limitate, è possibile adottare diverse tecniche di ottimizzazione, molte delle quali sono già state sperimentate nella comunità open‑source.

Quantizzazione e pruning dei modelli

La quantizzazione riduce la precisione dei pesi da 32‑bit floating point a 8‑bit interi, diminuendo drasticamente il consumo di memoria e velocizzando le operazioni di moltiplicazione matrice‑vettore. supporta la quantizzazione post‑training, che può essere applicata senza richiedere un nuovo ciclo di addestramento. Il pruning, invece, elimina i pesi meno significativi, riducendo il numero totale di parametri. Entrambe le tecniche sono compatibili con la maggior parte delle GPU di fascia media, ma è consigliabile testare la qualità delle risposte dopo ogni modifica.

Uso di versioni più leggere di Whisper (tiny, base)

Whisper è disponibile in cinque configurazioni di dimensione. Passare da “small” a “base” o “tiny” comporta una riduzione del numero di parametri da 74 M a 39 M o 39 M rispettivamente, con una conseguente diminuzione della latenza di trascrizione. Per applicazioni in cui la precisione non è critica (ad esempio comandi brevi e ben strutturati), l’adozione di una versione più piccola può ridurre la latenza totale di circa 0,5‑1 secondo.

Riduzione della precisione del modello LLM (int8, fp16)

La conversione di a precisione fp16 è già supportata da e riduce il consumo di VRAM di circa il 50 % rispetto a fp32. L’ulteriore passaggio a int8 è possibile, ma richiede una calibrazione accurata per evitare artefatti di generazione. In pratica, molti utenti segnalano che la differenza di qualità tra fp16 e int8 è minima per compiti di conversazione generica, mentre per ragionamenti logici complessi la precisione fp16 rimane preferibile.

Batching e pipelining

Il modello LLM può essere configurato per elaborare più richieste in parallelo (batching). Tuttavia, in un assistente vocale interattivo, il batch size ottimale è 1, poiché le richieste arrivano in modo asincrono. Il pipelining, invece, consente di avviare la sintesi vocale non appena il LLM produce i primi token, riducendo la percezione di attesa. Implementare un buffer di token condiviso tra il processo di inferenza e quello di TTS è una tecnica avanzata, ma può portare a una riduzione della latenza complessiva di 1‑2 secondi.

Cache della memoria e swap

Su sistemi con 16 GB di RAM, è consigliabile configurare un file di swap di almeno 4 GB per gestire picchi di utilizzo della memoria durante il caricamento dei modelli. Inoltre, l’utilizzo di torch.backends.cudnn.benchmark = True permette a PyTorch di ottimizzare automaticamente le kernel CUDA per le dimensioni dei tensori più frequenti, migliorando le prestazioni di inferenza.

Confronto con soluzioni commerciali e alternative open‑source

Solus non è l’unico progetto che mira a fornire un assistente vocale offline. È utile confrontarlo con altre offerte presenti sul mercato, sia commerciali sia open‑source, per evidenziare punti di forza e limiti.

Assistenti vocali basati su cloud vs offline

Le soluzioni commerciali più diffuse, come Google Assistant, Amazon Alexa o Microsoft Copilot, si basano su infrastrutture cloud per l’elaborazione del linguaggio. Questo approccio garantisce bassa latenza e aggiornamenti continui dei modelli, ma comporta la trasmissione di dati vocali a server remoti, sollevando preoccupazioni sulla privacy. Solus, al contrario, mantiene tutti i dati all’interno del dispositivo, ma richiede hardware più potente per ottenere prestazioni comparabili.

MAIA AI: architettura MoE e differenze

MAIA AI, citata nelle fonti aggiuntive, utilizza un’architettura “Mixture of Experts” (MoE) che distribuisce i compiti tra più modelli specialistici. Questo approccio consente di ridurre il carico su una singola GPU, poiché ogni “expert” può essere caricato in modo dinamico a seconda del tipo di input (testo, immagine, voce). Tuttavia, MAIA è attualmente disponibile come piattaforma chiusa e richiede risorse di calcolo più elevate per gestire l’orchestrazione degli esperti. Solus, con la sua architettura monolitica, è più semplice da distribuire su hardware di fascia media, ma non beneficia della flessibilità modulare offerta da MAIA.

Copilot: integrazione con assistente Google

Copilot, menzionato come esempio di assistente vocale con supporto a comandi vocali in italiano, si integra con l’Assistente Google su Android. Questa integrazione sfrutta le API cloud di Google per la trascrizione e la generazione di testo, garantendo una latenza molto bassa ma dipendendo completamente dalla connessione internet. Solus, pur non offrendo la stessa rapidità, si distingue per l’indipendenza dalla rete e per la possibilità di personalizzare i prompt e i modelli senza vincoli di licenza.

Best practice per la scrittura di prompt efficaci con

Un aspetto cruciale per migliorare la qualità delle risposte di Solus è la formulazione del prompt inviato al modello LLM. Poiché è un modello generico, la chiarezza e la struttura del prompt influenzano direttamente la pertinenza delle risposte.

Struttura del prompt

Una buona pratica consiste nel suddividere il prompt in tre sezioni:

1. Contesto: fornisce al modello informazioni di base sulla conversazione (ad esempio “Sei un assistente vocale che risponde in italiano.”);
2. Istruzione: indica esplicitamente cosa si desidera ottenere (ad esempio “Rispondi in modo conciso alla domanda seguente.”);
3. Input dell’utente: il testo trascritto da Whisper.

Questo schema aiuta il modello a distinguere tra informazioni di background e compiti specifici, riducendo le ambiguità.

Esempi di prompt migliorati

Di seguito sono riportati due esempi di prompt, prima e dopo l’ottimizzazione:

• Prompt originale: “Qual è la capitale della Francia?”
• Prompt ottimizzato: “Contesto: Sei un assistente vocale che risponde in italiano. Istruzione: Fornisci una risposta breve e corretta. Domanda: Qual è la capitale della Francia?”

Nel caso di richieste più complesse, è utile includere esempi di risposta (few‑shot prompting) per guidare il modello verso il formato desiderato.

Prospettive future e roadmap per Solus

Il progetto Solus è ancora in fase di sviluppo attivo. Tra le possibili evoluzioni, si segnalano:

• Supporto a modelli LLM più leggeri, come ‑2 7B o Falcon 7B, che offrono un trade‑off tra dimensione e qualità;
• Implementazione di un motore di retrieval‑augmented generation (RAG) per accedere a documenti locali e migliorare la pertinenza delle risposte;
• Ottimizzazioni specifiche per CPU ARM, per consentire l’esecuzione su dispositivi mobili e single‑board computer (Raspberry Pi 4, Jetson Nano);
• Interfaccia grafica avanzata con visualizzazioni di stato della GPU e della CPU, utile per il monitoraggio in tempo reale;
• Integrazione di modelli di sintesi vocale multilingue per supportare lingue diverse dall’italiano senza dover installare pacchetti aggiuntivi.

Queste direzioni di sviluppo mirano a rendere Solus più accessibile a una platea più ampia di utenti, mantenendo al contempo l’obiettivo di privacy totale.

Conclusioni

L’analisi di Solus dimostra che è possibile realizzare un assistente vocale offline completo anche su hardware di fascia media, a patto di adottare un’architettura ibrida ben bilanciata. La separazione dei carichi tra CPU (Whisper, Piper) e GPU () permette di sfruttare al meglio le risorse limitate, mentre tecniche di quantizzazione, pruning e prompt engineering contribuiscono a migliorare sia le prestazioni che la qualità delle risposte. Confrontato con soluzioni commerciali basate su cloud, Solus offre un vantaggio competitivo in termini di privacy e personalizzazione, sebbene la latenza rimanga un punto critico da ottimizzare ulteriormente. L’evoluzione del progetto, con l’integrazione di modelli più leggeri e di meccanismi RAG, promette di ridurre ulteriormente il divario tra assistenti offline e servizi cloud, aprendo la strada a una nuova generazione di interfacce vocali indipendenti e rispettose della sovranità dei dati.