Con un semplice dialogo in linguaggio naturale e la potenza di una scheda video di fascia alta è possibile costruire software funzionante da zero, senza scrivere una riga di codice e senza inviare dati a server esterni. Grazie all’evoluzione del cosiddetto Vibe Coding – termine con cui si indica la pratica di sviluppare software descrivendo all’IA ciò che si desidera in linguaggio naturale – l’assenza di competenze di programmazione non è più un ostacolo.

Integrando strumenti visivi accessibili e un approccio iterativo, chiunque può dare vita a un’applicazione personalizzata senza scrivere manualmente codice. Ecco cosa abbiamo appreso, e costruito con questo metodo.

Il primo pilastro di questo ecosistema è la rimozione della complessità tecnica legata alla gestione dei modelli. Per comunicare in modo chiaro ciò che vogliamo ottenere, abbiamo scelto Unsloth Studio, uno strumento che elimina la necessità di interagire con il terminale tramite un’interfaccia grafica per scaricare e avviare gli LLM.

Dopo una configurazione guidata che mappa automaticamente i driver della scheda video, l’utente ha accesso a una dashboard centralizzata collegata ai principali database di modelli open-source. Per ottimizzare le risorse di una GeForce RTX 5070 Ti, la scelta del modello deve ricadere su architetture bilanciate come Gemma 4, Llama 3 o Mistral.

È consigliabile prediligere le versioni quantizzate in formato GGUF. Una volta avviato il modello, Unsloth Studio espone un server locale all’indirizzo http://localhost:8000, che imita la struttura delle API commerciali più note. Questo standard consente a qualsiasi applicazione esterna di comunicare con il modello locale, inviare istruzioni e ricevere risposte generate direttamente dalla scheda video.

Per sfruttare in modo equilibrato una RTX 5070 Ti, non basta “un modello qualsiasi”. Architetture come Llama 3, Gemma 4 o Mistral sono progettate per l’esecuzione su hardware consumer: supportano tecniche moderne come GQA e FlashAttention, gestiscono ampie finestre di contesto senza sovraccaricare la VRAM e offrono una qualità di output comparabile a molti modelli commerciali. È il compromesso ideale tra numero di parametri, richiesta di memoria e qualità delle risposte, condizione indispensabile per chi non dispone di una GPU da data center.

La raccomandazione di usare versioni con compressioni matematiche (quantizzazione) in formato GGUF ha una ragione pratica: ridurre il peso del modello fino a farlo rientrare nella VRAM disponibile senza rinunciare alla qualità. In FP16 un modello da 12 miliardi di parametri (12B) occuperebbe circa 24 GB di VRAM, rendendo impossibile il caricamento su una 5070 Ti da 16 GB. La quantizzazione a 4-5 bit porta lo stesso modello a circa 6-8 GB, lasciando spazio per la KV cache e il sistema operativo.

GGUF è attualmente uno standard de facto per i modelli compressi: è supportato da quasi tutti i runtime locali, permette caricamenti rapidi e rende possibile ciò che in FP16 rimarrebbe solo teorico. Senza quantizzazione, l'”AI avanzata in locale” su un PC di casa si fermerebbe ai modelli piccoli; con GGUF possiamo spingerci fino a 7-12B parametri in modo stabile.

Nel panorama degli strumenti per eseguire LLM in locale, Unsloth Studio non è una scelta banale. La sua selezione nasce da tre motivi:

• Unsloth riduce al minimo la necessità di usare il terminale offrendo un’interfaccia grafica che guida l’utente nel download dei modelli, nella configurazione della GPU e nell’avvio del server locale.
• Unsloth integra ottimizzazioni specifiche per l’esecuzione locale come quantizzazione, kernel più efficienti e gestione delle risorse, permettendo a una scheda come la GeForce RTX 5070 Ti di ospitare modelli più grandi e veloci rispetto ad alternative basate su backend generici.
• Unsloth espone il modello tramite un endpoint locale compatibile con le API più diffuse, consentendo a strumenti e librerie pensate per i servizi cloud di dialogare con l’LLM in locale senza richiedere una riscrittura completa del codice.

È la combinazione di usabilità, efficienza e compatibilità a renderlo la scelta più sensata per chi parte da zero ma vuole arrivare a un’app reale funzionante su hardware domestico.

Calcolo dello spazio occupato in VRAM

Un dubbio comune riguarda il calcolo esatto dello spazio occupato da un modello all’interno della VRAM. Esiste una relazione tra il numero di parametri di un LLM e il peso del file in Gigabyte, ma questa equazione è influenzata dalla precisione numerica con cui il modello è stato convertito (quantizzazione). In un modello non ottimizzato espresso in precisione standard a 16 bit (FP16), ogni parametro richiede 2 byte di memoria. Di conseguenza, un modello da 12 miliardi di parametri (12B) occuperebbe circa 24 GB di VRAM solo per essere caricato.

Scaricando una versione quantizzata a 4 bit, il consumo si riduce drasticamente a circa 0,5 byte per parametro: lo stesso modello da 12B richiederà circa 6-7 GB di file su disco e altrettanti GB di VRAM per il caricamento iniziale. Questo lascia spazio per la Context Window e il sistema operativo.

Il discorso cambia con modelli di scala industriale come Kimi 3, la cui configurazione estesa può raggiungere una dimensione stimata di 300 GB. Un file di tale portata descrive un’infrastruttura complessa basata su logiche MoE (Mixture of Experts), in cui il modello globale è suddiviso in sotto-reti specializzate: quando l’utente invia un prompt, un algoritmo attiva solo una frazione di questi esperti.

Anche a una quantizzazione spinta a 4 bit, un modello di questa mole richiederebbe almeno 150-180 GB di VRAM libera per l’avvio. Non basterebbe una GeForce RTX 5070 Ti: sarebbe necessaria un’infrastruttura server composta da un cluster di almeno quattro o sei schede NVIDIA RTX 9000 Ada Generation o H100 collegate in parallelo.

Questa differenza di scala chiarisce il confine tra AI locale e AI cloud: mentre le architetture giganti richiedono data center dedicati, l’ottimizzazione dei modelli open-source da 7B a 12B parametri permette di ottenere assistenti privati sfruttando al 100% l’architettura consumer di una singola scheda video domestica. In condizioni come queste conviene ricorrere all’elaborazione via cloud.

AI locale vs AI Cloud

Mentre l’esecuzione in locale degli LLM rimarrà appannaggio degli utenti minimamente smaliziati, la maggior parte delle persone avrà vita più facile con i modelli disponibili in cloud. Questi vedono miglioramenti quotidiani nell’interpretazione del prompt e forniscono risposte sempre più immediate. Allo stesso tempo si assiste a un continuo aumento dei costi per piattaforme come queste.

Per comprendere l’impatto di un LLM sul computer, è fondamentale monitorare il comportamento dei componenti attraverso la Gestione Attività di Windows, distinguendo lo stato di riposo dalla fase di calcolo attivo. Quando il modello viene caricato in memoria, la percentuale di occupazione della RAM e della VRAM subisce un’impennata immediata, stabilizzandosi su valori elevati anche superiori al 95%. I miliardi di parametri devono risiedere nella memoria d’accesso rapido per essere consultabili all’istante.

I Tensor Core della GeForce RTX 5070 Ti vengono attivati in parallelo per eseguire le moltiplicazioni matriciali necessarie a prevedere ogni token successivo. La RAM e la VRAM delimitano la dimensione del modello che il PC può ospitare, mentre la potenza pura della GPU determina la velocità di generazione del testo.

Questo scenario apre a considerazioni su come si analizza la capacità di una CPU, dove il valore di token al secondo tende a rimpiazzare quello di frame al secondo. Questa considerazione va letta alla luce di diverse puntualizzazioni: l’unità di misura del token al secondo non è precisa come quella del frame al secondo per un benchmark classico.

Context Window e Temperature

La Context Window è la quantità massima di dati che il modello può elaborare contemporaneamente, includendo sia il testo inserito dall’utente sia la risposta generata. All’aumentare dei token gestiti, la scheda video deve mantenere in memoria le relazioni geometriche tra tutte le parole analizzate. Se si imposta una finestra di contesto troppo ampia rispetto alle capacità della VRAM, il sistema sarà costretto a fare offloading sulla RAM, rallentando i tempi di risposta.

La Temperature agisce come un modulatore di probabilità matematica durante la selezione delle parole. Quando il valore è impostato vicino a 0.0, l’algoritmo seleziona solo i token con la massima probabilità statistica, rendendo l’output deterministico e ideale per compiti logici. Impostando il valore verso 1.0, si appiattisce la curva di probabilità permettendo al modello di selezionare parole meno scontate, aumentando la variabilità e la creatività del testo.

Quando un LLM elabora un testo, deve calcolare e conservare le relazioni geometriche tra ogni token all’interno di un archivio temporaneo chiamato KV Cache. In un modello non ottimizzato, il consumo della KV Cache cresce in modo lineare rispetto alla lunghezza del contesto: ogni token aggiunto può richiedere circa 1-2 Megabyte di VRAM.

Le architetture più recenti mitigano questo problema con due tecnologie chiave: la GQA (Grouped-Query Attention), che raggruppa chiavi e valori riducendo il consumo di VRAM legato al contesto fino all’80% senza compromettere l’accuratezza; e FlashAttention, che ottimizza il passaggio dei dati tra la memoria ad alta velocità della GPU (SRAM) e la VRAM principale.

Progetti Pratici

Nel primo tentativo abbiamo chiesto all’AI di creare una semplice interfaccia con Streamlit per inserire del testo e inviarlo al modello locale, ma il programma cercava ancora di collegarsi a server esterni richiedendo una chiave a pagamento. Nel secondo passaggio , abbiamo spiegato all’AI che volevamo usare il server locale di Unsloth Studio su http://localhost:8000 . A questo punto, l’AI ha aggiornato il codice sfruttando la libreria Python compatibile con le API OpenAI , ma configurata per puntare all’endpoint locale invece che ai server esterni.

In altre parole, non stavamo usando il servizio cloud OpenAI, ma un client API già esistente per parlare con un modello in esecuzione sulla nostra GPU. Il risultato era un’app capace di interagire correttamente con l’LLM locale, anche se ancora limitata a una sola modalità di analisi.

Nell’ ultimo passaggio , è stato chiesto all’AI di implementare un sistema di controllo degli errori che bloccasse l’invio in caso di campo vuoto e mostrasse un avviso visivo di attesa durante il calcolo intensivo della GPU. Successivamente, durante la fase di integrazione con il modello Gemma-4-12B ospitato sul server locale, sono emerse ulteriori criticità di rete e autenticazione con errori HTTP 401 e 405 che sono state risolte passando dalla libreria standard OpenAI a richieste HTTP dirette tramite la libreria requests .

Il secondo progetto ha seguito un percorso di sviluppo diverso, incentrato sulla creazione di una PWA (Progressive Web App) per Android pensata come sveglia/task alarm da telefono. Da PWA poi si è trasformata in app nativa.

Alla base dell’app c’è un array tasks che funge da Single Source of Truth, con ogni modifica riflessa immediatamente nell’interfaccia tramite una funzione di rendering dedicata, e sulla persistenza tramite LocalStorage, che permette di gestire i dati sul dispositivo senza bisogno di un server esterno in quello che è un esempio di Local-First Software Architecture. Un setInterval funge da loop di controllo che osserva costantemente il tempo, mentre l’allarme sonoro viene generato tramite AudioContext API invece di caricare un file .mp3 esterno, sintetizzando l’onda sonora direttamente nel browser.

In realtà questo sistema ha prodotto un suono di sintesi non gradevole, per cui nell’iterazione finale dell’app abbiamo propeso per un mp3. Per completare la trasformazione in PWA vera e propria sono stati aggiunti un manifest.json, che definisce icona e colori dell’app quando installata sulla home di Android, e un service-worker.js, che intercetta le richieste di rete servendo i file dalla cache locale e permette all’app di funzionare offline.

Per superare questo vincolo, l’evoluzione naturale del progetto è passata a un’architettura Ibrida tramite Capacitor, un framework che trasforma il codice web in un’app nativa senza rinunciare alla velocità di sviluppo di HTML, CSS e JavaScript, ma abbattendo i muri della Sandbox attraverso un Bridge che permette all’app di parlare direttamente con i servizi di sistema di Android, come l’ Alarm Manager. Tecnicamente, la differenza cruciale emersa in questa fase è che il codice nativo, come Jetpack Compose, disegna ogni singolo pixel dell’interfaccia tramite istruzioni del sistema operativo, mentre una PWA o un’app ibrida si affidano a una WebView, un motore di rendering che interpreta il codice web all’interno di un contenitore nativo.

Una volta generato l’APK tramite Android Studio, il risultato è un’app che suona anche a schermo spento e con l’app chiusa, esattamente ciò che la versione puramente web non poteva garantire. Il passaggio ad Android Studio è stato fondamentale in questa esperienza, uno strumento che personalmente non so usare direttamente. Android Studio, con l’integrazione a sua volta di strumenti IA basati su Gemini 3 Flash, ha risolto gli errori di codice che si erano generati durante le iterazioni ricorsive del modello Gemma incapsulato dentro Unsloth. Questo passaggio è stato fondamentale per ottenere l’APK funzionante.

Non è stato facile superare i controlli incrociati che Android esegue su ciò che le app fanno quando sono chiuse. Ma ora Task Alarm riesce a gestire le sveglie in qualsiasi momento ed è anche possibile spegnere la sveglia subito dopo che si è attivata. Può gestire vari task e continua a funzionare anche quando non in esecuzione.

Il filo che unisce entrambi i progetti è lo stesso: costruire strumenti funzionali, privati e autonomi sfruttando solo le risorse già presenti sul proprio hardware, senza dipendere da abbonamenti cloud o da competenze tecniche pregresse. L’analizzatore di PDF dimostra come una singola GeForce RTX 5070 Ti, abbinata a un modello quantizzato da 12 miliardi di parametri, sia sufficiente per costruire un assistente specializzato capace di leggere, riassumere e analizzare documenti sensibili senza che un singolo byte lasci il proprio computer. Il task alarm, dall’altro lato, mostra che anche i piccoli progetti “senza internet” nascondono sfide ingegneristiche reali, dai limiti imposti dai browser fino alla necessità di scendere a compromessi tra velocità di sviluppo e accesso ai permessi di sistema.

Chi esegue un modello in locale tramite strumenti come Unsloth Studio, al contrario, ha il controllo diretto sul file del modello che sta usando: se non lo si aggiorna manualmente, quel modello resterà esattamente lo stesso, con lo stesso comportamento, la stessa qualità di output e le stesse eventuali “stranezze”, in queste ore come in un anno. Questo non significa che il modello locale sia necessariamente migliore in termini assoluti, ma garantisce una riproducibilità che nel cloud semplicemente non esiste: un vantaggio concreto per chi costruisce un’applicazione attorno a un comportamento specifico del modello, e non vuole ritrovarsi a dover rincorrere modifiche silenziose apportate da un fornitore esterno su cui non ha alcun controllo.

C’è però un punto cruciale che va necessariamente toccato: la democratizzazione della programmazione non equivale automaticamente a codice sano. Se chiunque può “scrivere software” parlando con un LLM, è altrettanto vero che la maggior parte degli utenti non ha gli strumenti per valutare se quel software sia robusto, sicuro ed efficiente. Questo nuovo scenario, in cui basta descrivere un’idea all’AI per ottenere codice funzionante, ha un rovescio della medaglia che non va ignorato.

Un utente che non sa programmare può generare un’applicazione perfettamente utilizzabile, ma non ha gli strumenti per giudicare la qualità del codice che sta eseguendo. Non può verificare se ci siano vulnerabilità banali (input non validati, gestione superficiale degli errori, uso insicuro di file e rete), se l’app regga carichi prolungati o se stia consumando risorse in modo inutile. In pratica, la barriera d’ingresso si abbassa per la produttività, ma resta alta sul fronte dell’ingegneria del software.

Nel nostro caso, gli errori emersi come quello dell’app che crasha in assenza di testo fino ai problemi di autenticazione con l’endpoint locale, sono stati risolti proprio grazie al dialogo iterativo con l’LLM. Ma questo non deve far dimenticare che il modello non sostituisce la fase di revisione critica: serve comunque un minimo di consapevolezza per chiedere controlli d’errore, per porsi domande su come vengono gestiti i dati, e idealmente serve un passaggio di auditing da parte di chi conosce almeno i principi base di sicurezza e robustezza. La vera “democratizzazione” non sarà completa finché gli strumenti non aiuteranno anche a valutare e spiegare la salute del codice, non solo a generarlo.

Detto questo, il messaggio finale è semplice: la potenza dell’intelligenza artificiale non vive solo nei data center delle grandi aziende tecnologiche. Grazie a strumenti come Unsloth Studio (ma, ribadiamo, non è l’unico, è semplicemente l’esempio che abbiamo scelto di utilizzare per i nostri scopi), che democratizzano l’accesso ai modelli open-source ottimizzandone memoria e velocità, chiunque possieda una scheda video moderna può trasformare il proprio computer in un laboratorio personale di intelligenza artificiale. Non serve saper programmare, non serve un cluster di GPU professionali: serve solo la curiosità di provare, un dialogo ben costruito con l’AI, e la consapevolezza che il vero limite, in queste ore, non è più la tecnologia disponibile, ma quanto siamo disposti a sperimentare con ciò che già abbiamo in casa.

* Contenuto realizzato con l’ausilio di sistemi di intelligenza artificiale.