Questa è la prima puntata di una serie su AI locale: tool, modelli, fine-tuning, harness, RAG e privacy. Non è un elenco di installazioni. È un percorso: ogni pezzo rimanda al successivo, e insieme devono rispondere a una sola domanda — quando conviene tenersi modello e loop sulla macchina (o sul tuo piccolo cluster), e quando il cloud resta la scelta onesta.
Questa serie vive nell’hub AI Engineering: tool, modelli, fine-tuning, harness, RAG e privacy collegati in un percorso unico, non pezzi isolati.
Cosa significa “locale” qui
Locale non è solo “senza internet”. È controllo sul runtime, sul peso del modello, sui log e sui costi marginali. Può essere Ollama sul laptop, llama.cpp su una macchina dedicata, Unsloth per un fine-tune, un harness che chiama tool sul filesystem. Può anche essere un VPS tuo: il punto è che non stai noleggiando solo token da un provider chiuso.
Il pezzo successivo confronterà i runtime (Ollama, LM Studio, llama.cpp, vLLM). Poi modelli e quantizzazione, Unsloth, eval, harness, tool on-device, RAG locale, privacy, e infine il salto dal laptop a un piccolo cluster — tutto tracciato dall’hub AI Engineering. Se salti avanti, torna qui quando la scelta “cloud o locale” non è ancora chiara.
Quando il locale vince
Privacy e dati che non devono uscire. Se il contenuto è codice cliente, cartelle cliniche, contratti o prompt con PII, il costo di una leak vale più del risparmio di un’API economica.
Costo prevedibile a volume. Se generi o classifichi tanto testo/codice ogni giorno, i token cloud diventano una riga di bilancio; il hardware è un costo fisso che puoi ammortizzare.
Latenza e offline. Editor, agent di refactor, tool su repo grandi: un modello locale a 20–40 token/s “abbastanza buono” batte un round-trip remoto se il loop è stretto.
Sperimentazione di harness. Per capire se i tuoi tool sono descritti male, o se il loop esplode, un runtime locale ti lascia ripetere senza bruciare credito a ogni tentativo.
Quando il cloud resta onesto
Se ti serve il modello di frontiera per ragionamento lungo, multimodale maturo, o tool hosted (web search, browser) già pronti, il locale ti obbliga a compromessi. Un 7B/14B quantizzato non è “lo stesso prodotto” di un modello cloud aggiornato.
Se non hai VRAM/CPU decenti, o non vuoi fare ops (aggiornamenti, driver, quant, backup dei pesi), il cloud è più barato in tempo umano. Tempo umano è costo.
Se il carico è sporadico — un pezzo al mese, non un agente sempre acceso — pagare a consumo è spesso più razionale che tenere una GPU accesa “perché sì”.
La domanda che taglia la scelta
Non “locale è meglio?”. È: cosa non può lasciare la macchina, quanto loop hai al giorno, e quanto modello ti basta. Se non sai ancora rispondere, non comprare hardware e non copiare un repo di agenti. Parti dal vincolo (privacy, costo, latenza), misura un caso d’uso reale, poi scegli il runtime.
Prossimo episodio: i runtime a confronto — Ollama, LM Studio, llama.cpp e vLLM — con i vincoli veri, non le feature list.
Le puntate uscite e gli approfondimenti
Le puntate della serie uscite finora, in ordine:
- Guida AI locale 2: runtime a confronto (Ollama, LM Studio, llama.cpp, vLLM): quale runtime scegliere e con quali vincoli.
- Guida AI locale 3: modelli, quantizzazione e VRAM: quanto modello ti serve davvero e quanta memoria chiede.
- Guida AI locale 4: fine-tuning con Unsloth: quando ha senso addestrare e quando basta il prompt.
- Guida AI locale 5: dataset ed eval locali: come costruire il set di casi e misurare prima di cambiare modello.
Gli approfondimenti collegati, da leggere quando ti serve quel pezzo:
- API OpenAI-compatible in locale: puntare i tuoi tool su Ollama o vLLM senza riscrivere il client.
- Mac con Apple Silicon o GPU NVIDIA per LLM locali: prima di comprare hardware, la domanda è la memoria.
- GGUF, safetensors o MLX: quale formato di modello serve a quale runtime.
- LoRA, QLoRA o full fine-tuning: cosa cambia in VRAM, tempi e risultati.
