Girare modelli AI sul tuo hardware senza pagare abbonamenti, senza mandare dati in cloud, e senza aspettarti miracoli.
Da "ho sentito che posso girare ChatGPT a casa" a "so scegliere il modello giusto per quello che mi serve"
"Un modello locale che risponde in 30 secondi è meglio di nessun modello. A volte. Dipende."
No, non stai "girando ChatGPT". Ma qualcosa di interessante sì.
I modelli AI in cloud (ChatGPT, Claude, Gemini) sono come un ristorante stellato dove puoi ordinare quello che vuoi, il cuoco è fantastico, ma ogni piatto costa, devi fare la fila, e il cuoco sente tutto quello che dici al tavolo. L'IA locale è come avere un cuoco a casa: più lento, meno bravo sui piatti difficili, ma sempre disponibile, gratuito dopo l'investimento iniziale, e non riporta niente a nessuno. La scelta dipende da cosa cucini e quanto ti importa della privacy.
La GPU è tutto. La RAM è tutto. La CPU quasi non conta.
Un modello AI è fondamentalmente una moltiplicazione di matrici enormi. La GPU è progettata per fare esattamente questo in parallelo — migliaia di core piccoli invece di pochi core grossi. La VRAM (memoria della GPU) è il vero collo di bottiglia: il modello deve starci tutto dentro. Se il modello non ci sta in VRAM, finisce in RAM di sistema, che è 10-50x più lenta. Se non ci sta nemmeno lì, va su disco: a quel punto vai a fare una passeggiata mentre aspetti la risposta.
Regola pratica per stimare quanta VRAM serve un modello:
# Quantizzazione = riduzione della precisione per risparmiare memoria
# Q4 = 4 bit per parametro (~50% di un float16), qualità ok
# Q8 = 8 bit per parametro, qualità quasi identica al pieno
VRAM (GB) ≈ (parametri in miliardi) × (bit / 8) + ~15-20% overhead (KV cache)
Qwen3 8B a Q4: 8 × 0.5 = ~5-6 GB VRAM # RTX 3060 12GB / RTX 5060 Ti: ✓
gpt-oss 20B MXFP4: 21B MoE = ~13 GB VRAM # RTX 5060 Ti 16GB: ✓ (3.6B attivi)
Qwen3 14B a Q4: 14 × 0.5 = ~9-10 GB VRAM # RTX 5070 12GB: ✓ (giusto)
Qwen3 32B a Q4: 32 × 0.5 = ~18-20 GB VRAM # RTX 3090/4090/5090 24-32GB: ✓
gpt-oss 120B MXFP4: 117B MoE = ~60-65 GB # Mac 128GB / GPU 80GB: ✓ (5.1B attivi)
Llama 4 Scout a Q4: 109B MoE = ~60 GB # Mac 64-128GB unified
DeepSeek 671B a Q4: 671B MoE = ~380 GB # classe server, o Mac Studio 512GB
# MoE (Mixture-of-Experts): conta i parametri TOTALI per la VRAM,
# ma solo quelli ATTIVI per la velocità → modelli grandi ma rapidi
# MXFP4 = quant FP4 nativo (gpt-oss): qualità quasi piena a metà spazio
# Velocità approssimativa: VRAM >> RAM unificata (Mac/Strix) >> RAM >>> Disco
Funziona? Sì. È usabile? Dipende dalla tua soglia di dolore. Modelli piccoli (Gemma 3 1B/4B, Qwen3 1.7B/4B, Phi-4-mini) rispondono in 10-30 secondi su CPU decente. Utile per esperimentare.
Il sweet spot per cominciare seriamente. Qwen3 8B/14B a Q4 ci sta comodo, e con 16GB entra anche gpt-oss-20b (MoE, ~13GB) che ragiona vicino a o3-mini. Risposte in 30-60 t/s: fluido per uso quotidiano.
Qui si fa sul serio. La RTX 5090 con 32GB è il nuovo riferimento enthusiast; la RTX 3090 usata (24GB, ~600-900€) resta il miglior rapporto qualità/prezzo. Giri modelli 32B a Q4 o MoE come Qwen3-30B-A3B che vola.
Tre strade nel 2026: Mac Studio M3 Ultra fino a 512GB unificati a 819 GB/s (gira DeepSeek 671B in 4-bit a >20 t/s); NVIDIA DGX Spark o AMD Strix Halo (128GB unificati, ~$2-4k) per modelli fino a ~200B; oppure 2× RTX 3090 = 48GB con NVLink. Vedi il box dedicato sotto.
La grossa novità dell'ultimo anno: non servono più rack di GPU per i modelli grandi. La memoria unificata (CPU+GPU condividono la stessa RAM) permette di caricare modelli enormi su un mini-desktop. Lente in decoding rispetto a una GPU dedicata, ma con tanta memoria a poco prezzo.
| Sistema | Memoria | Banda | Prezzo indic. | Note |
|---|---|---|---|---|
| NVIDIA DGX Spark (GB10) | 128 GB unif. | 273 GB/s | ~$4.000 | Fino a ~200B; prefill fortissimo, decode lento (~3 t/s su 70B). ASUS Ascent GX10 ~$3.000 |
| AMD Strix Halo (Ryzen AI Max+ 395) | fino 128 GB unif. | ~256 GB/s | ~$2.000+ | Framework Desktop, mini-PC. MoE volano (Qwen3-30B ~98 t/s). ROCm maturo nel 2026 |
| Mac Studio M3 Ultra | fino 512 GB unif. | 819 GB/s | $4.000 → $14.000 | Il re dei modelli grandi: DeepSeek 671B Q4 a >20 t/s in una scatola sola |
| Mac Studio M4 Max | fino 128 GB unif. | 546 GB/s | da $1.999 | Ottimo equilibrio prezzo/prestazioni per 70B e MoE medi |
⚠️ Prezzi indicativi di giugno 2026, gonfiati dalla carenza globale di memoria DRAM/GDDR7. La banda memoria è il vero numero da guardare: più è alta, più veloce genera token.
| Hardware | Modello | Token/sec | Usabilità |
|---|---|---|---|
| CPU moderna (no GPU) | Qwen3 4B Q4 | ~5-12 t/s | lento |
| RTX 5060 Ti 16GB | gpt-oss-20b MXFP4 | ~40-60 t/s | ok |
| RTX 3090 24GB (usata) | Qwen3 8B Q8 | ~80-110 t/s | fluido |
| RTX 5090 32GB | Qwen3 32B Q4 | ~45-70 t/s | veloce |
| M4 Max 128GB | gpt-oss-120b MXFP4 | ~30-45 t/s | fluido |
| M3 Ultra 512GB | DeepSeek-R1 671B Q4 | ~20-25 t/s | ok |
| DGX Spark / Strix Halo 128GB | Llama 3.1 70B Q4 | ~3-15 t/s | variabile |
Per riferimento: leggere testo a schermo comodamente richiede ~15-20 t/s. Sotto quella soglia senti la latenza.
L'ecosistema open-weight cresce ogni settimana. Qui le scelte sensate.
I primi pesi aperti di OpenAI dai tempi di GPT-2 (ago 2025). Architettura MoE con quantizzazione nativa MXFP4: il 20b sta in 16GB di VRAM e ragiona vicino a o3-mini, il 120b sta in ~65GB (Mac 128GB o GPU 80GB) e si avvicina a o4-mini. Reasoning effort regolabile (low/med/high), fortissimi su tool use e agenti. Oggi il punto di partenza per chi vuole ragionamento serio in locale.
La famiglia open più completa e versatile del 2026. Dense da 0.6B a 32B, più MoE 30B-A3B (30B totali, solo 3B attivi: gira su 24GB e va velocissimo) e 235B-A22B. Edizioni separate Instruct e Thinking (256K context). Italiano ottimo, coding forte, tool use nativo. Il tuttofare da scegliere se non sai cosa scegliere.
La generazione MoE di Meta (apr 2025), nativamente multimodale (testo+immagini). Scout (17B attivi / 109B totali) entra in una scatola a memoria unificata da 64-128GB; Maverick (17B / 400B) richiede hardware serio. Contesto enorme. Buoni ma meno dominanti del previsto: per uso locale spesso Qwen3 e gpt-oss rendono di più a pari hardware.
I modelli di Google per uso locale (mar 2025), con checkpoint QAT ufficiali pensati per GPU consumer. Gemma 3 4B è eccezionale per le dimensioni; il 27B è multimodale e ottimo a Q4 in 24GB. Gemma 3n (E2B/E4B) è per edge/mobile e gestisce anche audio e video in 2-3GB.
Il team francese resta efficientissimo. Mistral Small 3.2 (24B, vision, 128K) è un dense compatto e veloce. Magistral Small è la versione reasoning open. E novità 2025: Mistral Large 3 (MoE 675B/41B) è il primo Large completamente aperto. Mixtral è stato ritirato.
Il colosso open (MIT) che batte i frontier a frazione del costo. V3.2 introduce la Sparse Attention; R1 ragiona step-by-step al livello dei top cloud. Il 671B richiede un Mac Studio 512GB o un server, ma i distillati R1 (1.5B → 70B) girano in locale e sono eccellenti. Nota: cinese, valuta le implicazioni.
Due famiglie cinesi salite alla ribalta nel 2025 per uso agentico. GLM-4.5-Air (106B/12B, MIT) gira su un Mac 128GB ed è fortissimo su coding. Kimi K2 (MoE 1T/32B attivi) e la sua variante Thinking sono allo stato dell'arte sugli agenti, ma sono roba da server.
Il miglior modello di coding eseguibile in locale nel 2026. Il 30B-A3B (MoE, 3B attivi) sta in 24GB / un Mac e regge ~51% SWE-bench restando velocissimo: il tuttofare ideale per coding agentico privato. Il 480B-A35B è frontiera ma da server. Esiste anche il piccolo Qwen2.5-Coder 7B/32B per autocomplete.
Specializzato in coding agentico (modifica repo, esegue task multi-file). Devstral Small 2 (24B dense, Apache 2.0) entra in 16-24GB e tocca ~68% SWE-bench: tra i migliori modelli locali per lavorare davvero su un codebase, non solo autocomplete.
Per chi ha hardware limitato ma vuole codice e ragionamento solidi. gpt-oss-20b (16GB VRAM) è fortissimo su debugging e task agentici. Phi-4-reasoning-plus (14B, MIT) batte modelli più grandi su math e coding. Entrambi ottimi rapporti qualità/dimensione.
La famiglia di modelli visione open più forte del 2026 (Apache 2.0). OCR in 32 lingue, grounding, comprensione di video e screenshot, persino agent per GUI. Il 4B/8B gira su 8-16GB; il 32B su 24GB. Edizioni Instruct e Thinking.
Il multimodale locale più comodo da installare: analizza immagini, documenti, screenshot con ottima qualità. Il 27B richiede ~14-20GB VRAM a Q4, il 4B gira ovunque. Anche Llama 4 Scout è multimodale nativo, e Gemma 3n gestisce pure audio/video.
Un comando per installare, uno per scaricare un modello, uno per usarlo. Fine.
Ollama è il Docker dei modelli AI. Come Docker astrae la complessità di far girare container, Ollama astrae la complessità di far girare modelli quantizzati. Gestisce il download, la quantizzazione, l'accelerazione GPU, il server HTTP, e l'interfaccia CLI. Tu scrivi ollama run qwen3 e lui fa tutto il resto. Dal 2025 ha anche un motore multimodale proprio (non solo llama.cpp) e su Apple Silicon un backend MLX per andare più veloce.
:cloud, stessa API, zero retention) e una web search API per dare ai modelli accesso al web. Su Linux resta CLI-only.
# macOS
brew install ollama
# oppure dal sito: curl -fsSL https://ollama.com/install.sh | sh
# Linux (una riga, fa tutto)
curl -fsSL https://ollama.com/install.sh | sh
# Windows: installer .exe da ollama.com
# Verifica che funzioni
ollama --version
ollama version is 0.x.x
# Ollama gira come servizio in background su :11434
ollama serve # solo se non parte in automatico
# Scarica e avvia in chat interattiva
ollama run qwen3 # 8B tuttofare, ~5GB download
ollama run gpt-oss:20b # reasoning, ~13GB (entra in 16GB VRAM)
ollama run gpt-oss:120b # reasoning top, ~65GB (Mac 128GB / GPU 80GB)
ollama run qwen3-coder:30b # coding agentico MoE
ollama run deepseek-r1:14b # reasoning distillato locale
ollama run gemma3:27b # Google Gemma 3, multimodale
ollama run qwen3-vl:8b # visione (immagini, OCR, video)
# Una domanda singola senza chat interattiva
ollama run qwen3 "traduci in italiano: hello world"
# Lista modelli scaricati
ollama list
# Rimuovi un modello (libera spazio)
ollama rm mistral
# Vedi quanto VRAM/RAM sta usando
ollama ps
Ollama espone un'API REST compatibile (in gran parte) con OpenAI. Qualsiasi app che parla con OpenAI può puntare a Ollama cambiando solo l'URL.
# Chiamata base all'API (endpoint /api/generate)
curl http://localhost:11434/api/generate \
-d '{"model":"qwen3","prompt":"spiega kubernetes in 2 righe","stream":false}'
# Endpoint compatibile OpenAI (per drop-in replacement)
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3",
"messages": [{"role":"user","content":"ciao, come stai?"}]
}'
# Python con libreria ollama
pip install ollama
# client.py
import ollama
response = ollama.chat(model='qwen3', messages=[
{'role': 'user', 'content': 'Spiega Docker in 3 righe'}
])
print(response['message']['content'])
# Oppure con libreria openai, cambiando solo base_url
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
response = client.chat.completions.create(model="qwen3", ...)
Come il Dockerfile per i container, il Modelfile ti permette di creare versioni personalizzate di un modello con system prompt fissi, parametri custom, template diversi.
# Modelfile
FROM qwen3
# Temperatura: 0.0 = deterministico, 1.0 = creativo
PARAMETER temperature 0.2
# Context window
PARAMETER num_ctx 8192
# System prompt fisso
SYSTEM """
Sei un assistente tecnico per sistemisti. Rispondi sempre in italiano.
Sii conciso e diretto. Se non sai qualcosa, dillo chiaramente.
Quando mostri comandi, usa blocchi di codice.
"""
# Crea il modello custom
ollama create mio-assistente -f Modelfile
ollama run mio-assistente
ollama run hf.co/bartowski/Llama-3.1-8B-Instruct-GGUF. Se un modello non è nel registry ufficiale di Ollama, cercalo su Hugging Face con il tag GGUF.
Ollama è il motore. Questi sono i sedili, il volante e il cruscotto.
L'interfaccia grafica per chi vuole tutto incluso senza terminale. Scarica modelli da Hugging Face con una ricerca, li gestisce, li gira con un click, e include una chat integrata + server API. Due backend: llama.cpp (GGUF, cross-platform) e MLX (Apple Silicon). Disponibile per Mac, Windows, Linux.
lmsUn'interfaccia web tipo ChatGPT da girare localmente sopra Ollama (o qualsiasi backend compatibile). Docker compose e sei operativo in 2 minuti. Features: chat con più modelli, gestione conversazioni, RAG integrato, image generation, multi-user.
docker run -d \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
ghcr.io/open-webui/open-webui:main
# Poi vai su http://localhost:3000
La soluzione all-in-one per RAG locale. Carica PDF, Word, pagine web, codice — lui li indicizza e puoi farci domande. Supporta Ollama come backend, ha UI desktop e versione server, agenti con tool e supporto MCP. Licenza MIT (punto a favore rispetto a Open WebUI). Ideale per "parla con i tuoi documenti" senza mandare niente in cloud.
LocalAI: drop-in replacement dell'API OpenAI (chat, embeddings, immagini, TTS, STT), gira anche solo su CPU. Per la produzione ad alto throughput su GPU si usano invece vLLM (lo standard, multi-hardware incluso ROCm/TPU) o SGLang (top su RAG con prefix cache e MoE). Non sono tool da laptop: sono server.
Nel 2026 non è più solo autocomplete: gli agenti modificano interi repo. Tutti puntabili su Ollama/LM Studio per restare privati e gratis. Pairing consigliato: Qwen3-Coder o Devstral.
num_ctx)Tool CLI di Simon Willison per interagire con qualsiasi LLM (locale e cloud) da terminale. Ottimo per scripting, pipe, automazioni. cat file.txt | llm "riassumi" è tutto quello che devi sapere per capire il potenziale.
pip install llm llm-ollama
llm install llm-ollama
# Usa modello ollama
llm -m ollama/qwen3 "spiega il CAP theorem"
# Pipe dal terminale
git diff | llm -m ollama/qwen3 "scrivi un commit message"
cat error.log | llm "cosa significa questo errore?"
Il Model Context Protocol (MCP) è lo standard aperto (nato in Anthropic, donato alla Linux Foundation a fine 2025) che fa parlare un LLM con tool e dati esterni: filesystem, database, shell, API interne, monitoraggio. È "l'USB-C dell'IA". La cosa interessante per il locale: un modello on-premise può usare gli stessi tool server degli assistenti cloud, completamente air-gapped — tramite LM Studio (MCP Host), il client MCP integrato in llama.cpp, AnythingLLM o Goose.
I task dove i modelli locali rendono bene. Aspettative realistiche incluse.
Autocomplete, spiegazione di codice, refactoring, docstring. Con un 8B decente: buono. Con 32B+: molto buono. Alternativa reale a Copilot per uso privato.
Fai domande su PDF, manuali, documentazione interna. Funziona bene se i documenti sono in italiano e le domande sono precise. Non è magia, è un motore di ricerca intelligente.
Riassumere testi lunghi, estrarre punti chiave, trasformare bullet point in testo. Task semplice dove anche 7B funziona bene.
EN→IT e IT→EN funzionano bene anche sui modelli piccoli. Lingue meno comuni: risultati variabili. Non al livello di DeepL ma accettabile per uso interno.
Categorizzare ticket di supporto, email, feedback. Ottimo caso d'uso per automazione: nessun dato esce, costo zero, basta un 7B.
Email, report, documentazione tecnica, YAML di configurazione. Dato un contesto chiaro, i modelli locali producono output utile anche in italiano.
Da testo non strutturato a JSON. "Estrai nome, data e importo da questa fattura" funziona sorprendentemente bene anche su 7B con un buon prompt.
FAQ aziendale, primo livello di supporto, assistente per documentazione interna. Combinato con RAG: soluzione utile e completamente privata.
Generare script bash/python per task ripetitivi, convertire comandi tra sistemi operativi, debug di regex. I coding model da 7B ci riescono spesso al primo colpo.
Un benchmark pratico e onesto di Qwen3 8B Q4 su hardware tipico (RTX 5060 Ti 16GB):
| Task | Qualità | Note |
|---|---|---|
| Spiegare codice esistente | buona | Molto utile, raramente sbaglia il senso |
| Scrivere funzione semplice | buona | Python/JS funzionano bene, assembly no |
| Scrivere funzione complessa | variabile | Spesso funziona, a volte inventa API che non esistono |
| Debug di errori | buona | Ottimo se gli dai l'errore completo + contesto |
| Riassumere documenti | buona | Affidabile, un po' meccanico |
| Ragionamento matematico | mediocre | Aritmetica ok, algebra/calcolo: ci sbaglia spesso |
| Ragionamento complesso multi-step | migliorato | Usa gpt-oss o un modello Thinking; molto meglio di un anno fa |
| Rispondere in italiano corretto | accettabile | Si difende, qualche errore di concordanza |
| Generare codice sicuro | variabile | Sempre revisionare manualmente |
Le aspettative irrealistiche che uccidono i progetti locali.
gpt-oss-120b e i grandi MoE open sono eccellenti, ma non sono GPT-5.5, e tantomeno Claude Opus 4.8. Su benchmark standard c'è un gap misurabile. Per molti task quotidiani non importa. Per task complessi, importa eccome.
Una GPU da 12-16GB è ottima per modelli fino a ~14B (e gpt-oss-20b). Per i grandi MoE o il 70B serve memoria unificata (Mac/DGX Spark/Strix Halo) o multi-GPU. Girare un modello con overflow in RAM non è un'esperienza piacevole.
Probabilmente no, a meno che i tuoi task siano molto specifici e ben definiti. L'approccio più efficace è ibrido: locale per il 70-80% del lavoro di routine, cloud per il 20% che richiede qualità superiore.
I modelli open-weight sono addestrati prevalentemente in inglese. Rispondono in italiano ma commettono più errori, usano costruzioni anglicizzate, e a volte switching di lingua. Migliora con Qwen (ha più dati multilingua) ma non sparisce.
Non è locale vs cloud. È locale + cloud al posto giusto.
Immagina di avere un assistente locale sempre disponibile per le banalità quotidiane (rispondi a email semplici, trova info nel manuale, formatta questo CSV) e un consulente esterno che chiami quando hai bisogno di qualcosa di vero (strategia complessa, problema non banale, documento critico). Non mandi tutto al consulente perché costa. Non affidi tutto all'assistente perché sbaglia sui task difficili. Usi entrambi in modo intelligente.
| Criterio | Usa Locale | Usa Cloud |
|---|---|---|
| Dati | Dati sensibili, confidenziali, PII | Dati pubblici o non critici |
| Complessità | Task semplici e ripetitivi | Ragionamento complesso, multistep |
| Volume | Tante richieste, costo sarebbe alto | Poche richieste critiche |
| Latenza | Quando il delay è accettabile | Quando serve risposta rapida |
| Connettività | Offline, VPN aziendale rigida | Con internet disponibile |
| Lingua | Inglese o lingue con molti dati | Italiano di qualità, dialetti |
Uno strumento che espone un'unica API OpenAI-compatibile e smista le chiamate verso qualsiasi backend: Ollama locale, OpenAI, Anthropic, Gemini. Cambi il backend nel config, non nel codice.
model_list:
- model_name: fast-local
litellm_params:
model: ollama/qwen3
api_base: http://localhost:11434
- model_name: smart-cloud
litellm_params:
model: claude-opus-4-8
api_key: sk-ant-...
- model_name: coding
litellm_params:
model: ollama/qwen3-coder:30b
api_base: http://localhost:11434
# La tua app chiama sempre localhost:4000
# LiteLLM smista in base al model scelto
Un pattern utile: prova prima il cloud (risultato migliore), in caso di errore/rate limit/offline usa il locale come fallback. Implementabile con qualsiasi SDK OpenAI-compatibile.
def ask(prompt, prefer_cloud=True):
if prefer_cloud:
try:
return openai_client.chat(prompt)
except (RateLimitError, APIError):
pass # fallback al locale
return ollama_client.chat(prompt)
# Oppure con LiteLLM fallback nativo:
completion(
model="claude-opus-4-8",
fallbacks=["ollama/qwen3"],
messages=[...]
)
Esempi concreti da implementare oggi, non ipotesi astratte.
Il caso d'uso più immediato: sostituire GitHub Copilot con un modello locale per il 90% del lavoro quotidiano. Zero dati che escono, zero abbonamento.
ollama pull qwen3-coder:30b (24GB+) per coding agentico, oppure ollama pull qwen2.5-coder:7b per il solo autocomplete su hardware modesto.
Cline o Zed per lavorare in editor, Aider o Goose da terminale. Tutti gratuiti, open source: imposti il provider su "Ollama" e via.
Configura anche Claude o GPT-5 per quando serve ragionamento complesso. Routine = locale, task difficili = cloud, decidi tu.
Gli agenti indicizzano il repo e, via MCP, possono leggere/scrivere file, lanciare test, interrogare un DB. "Come funziona l'autenticazione in questo progetto?" diventa una domanda utile e azionabile.
Il caso d'uso killer per le aziende: "parla con i nostri manuali/procedure/contratti" senza mandare niente a OpenAI.
pip install langchain-community langchain-ollama chromadb pymupdf
# rag_locale.py
from langchain_community.document_loaders import PyMuPDFLoader
from langchain_ollama import OllamaEmbeddings, OllamaLLM
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
# 1. Carica i tuoi documenti
loader = PyMuPDFLoader("manuale_aziendale.pdf")
docs = loader.load()
# 2. Spezzali in chunk
splitter = RecursiveCharacterTextSplitter(chunk_size=500)
chunks = splitter.split_documents(docs)
# 3. Crea embeddings locali (multilingua → meglio per l'italiano)
embeddings = OllamaEmbeddings(model="bge-m3")
db = Chroma.from_documents(chunks, embeddings, persist_directory="./db")
# 4. Fai domande
llm = OllamaLLM(model="qwen3")
qa = RetrievalQA.from_chain_type(llm=llm, retriever=db.as_retriever())
risposta = qa.invoke("Qual è la procedura per le ferie?")
print(risposta["result"])
# Scarica anche il modello di embedding (alt: qwen3-embedding, embeddinggemma)
ollama pull bge-m3
Classificare ticket di supporto, estrarre entità da email, taggare documenti. Con un 7B e lo stesso loop:
import ollama, json
def classifica(testo):
resp = ollama.chat(
model="qwen3",
messages=[{
"role": "user",
"content": f"""Classifica questo ticket.
Rispondi SOLO con JSON valido.
Categorie: bug, feature, billing, other
Priorità: low, medium, high
Ticket: {testo}
Risposta JSON:"""
}],
format="json"
)
return json.loads(resp["message"]["content"])
print(classifica("Il login non funziona da stamattina"))
# → {"categoria": "bug", "priorità": "high"}
Con modelli multimodali (Qwen3-VL, Gemma 3) puoi analizzare screenshot, diagrammi, foto di errori — localmente.
# Scarica un modello con visione
ollama pull qwen3-vl:8b
# oppure: ollama pull gemma3:27b
import ollama, base64
with open("screenshot_errore.png", "rb") as f:
img = base64.b64encode(f.read()).decode()
resp = ollama.chat(
model="qwen3-vl:8b",
messages=[{
"role": "user",
"content": "Cosa mostra questo screenshot? C'è qualche errore?",
"images": [img]
}]
)
print(resp["message"]["content"])
Il motivo per cui molte aziende stanno guardando a questo con interesse.
Mandare prompt a un'API cloud significa (a seconda del fornitore e dei termini):
Codice proprietario, contratti, comunicazioni interne. L'IA locale è l'unica opzione sensata senza un accordo enterprise con il fornitore cloud.
HIPAA (USA), GDPR (EU): processare dati sanitari richiede accordi specifici. Locale elimina il problema alla radice.
Contratti, atti, comunicazioni avvocato-cliente. Molti ordini professionali vietano o limitano il cloud per questi dati.
I problemi che incontrerai quasi certamente. Con le soluzioni.
Causa probabile: il modello non sta in VRAM e sta girando su RAM di sistema (o disco).
Verifica: esegui ollama ps mentre il modello gira. Controlla la colonna "SIZE" e se dice "100% GPU" o meno.
Soluzioni:
1. Usa un modello più piccolo o più quantizzato: ollama pull qwen3:8b-instruct-q4_K_M invece della versione Q8.
2. Su Linux/Windows con GPU NVIDIA: verifica che CUDA sia installato correttamente e che Ollama usi la GPU (nvidia-smi durante una generazione deve mostrare utilizzo GPU).
3. Chiudi altre applicazioni che usano VRAM (giochi, altre istanze di modelli).
4. Su macOS con Apple Silicon: Ollama usa automaticamente la memoria unificata, dovrebbe andare bene nativamente.
Su NVIDIA: verifica che CUDA Toolkit sia installato. nvidia-smi deve funzionare. Se Ollama non trova CUDA, usa la CPU come fallback silenzioso.
Su AMD: serve ROCm, molto più maturo nel 2026 (ROCm 7.2 ha installer unificato Windows+Linux e supporto RDNA 4 e Strix Halo). Ollama e llama.cpp girano bene; su Strix Halo può servire tuning manuale di GTT/VRAM per esporre tutta la memoria.
Su Intel Arc: supporto via SYCL/oneAPI e Vulkan, migliorato ma ancora dietro a NVIDIA/AMD.
I modelli tendono a rispondere nella lingua in cui sono stati addestrati prevalentemente (inglese). Per forzare l'italiano:
Soluzione 1 - System prompt: crea un Modelfile con SYSTEM "Rispondi sempre e solo in italiano. Non usare mai l'inglese."
Soluzione 2 - Nel prompt: inizia il prompt con "Rispondimi in italiano:" o terminalo con "(rispondi in italiano)".
Soluzione 3 - Cambia modello: Qwen3 e Gemma 3 hanno dati di training multilingua più bilanciati e si comportano meglio in italiano rispetto a Llama.
Realtà: su modelli piccoli (4-8B) il comportamento in italiano è meno affidabile. Con modelli da 14B+ migliora significativamente.
Le allucinazioni sono più frequenti sui modelli locali rispetto ai top cloud. Non spariscono mai completamente, ma si riducono con queste pratiche:
1. Fornisci il contesto: "Basandoti SOLO sul seguente testo, rispondi a..." riduce l'invenzione di informazioni.
2. Chiedi incertezza: aggiungi al system prompt "Se non sei sicuro, di' esplicitamente 'Non lo so' invece di inventare".
3. Abbassa la temperatura: PARAMETER temperature 0.1 nel Modelfile rende le risposte più conservative e meno creative (anche meno allucinate).
4. Usa RAG per i fatti: se hai bisogno di informazioni precise da documenti, usa RAG invece di affidarti alla memoria del modello.
5. Accetta il limite: per task che richiedono fatti precisi (leggi, dati storici, documentazione tecnica), usa il cloud o il RAG. Non fidarti della memoria del modello locale.
Il problema classico Docker: il container non riesce a raggiungere Ollama che gira sull'host.
Se Ollama gira in un container separato nello stesso docker network, usa il nome del container come host invece di localhost.
Il modello richiede più memoria di quella disponibile (RAM + VRAM combinata).
Soluzioni:
1. Scarica una versione più quantizzata: invece di :latest usa :8b-instruct-q4_0 (la versione più leggera).
2. Prova un modello più piccolo: da 7B a 3B, da 13B a 7B.
3. Su macOS: chiudi le app che usano molta memoria (browser con molte tab, Xcode, ecc.).
4. Aumenta la swap/page file (aiuta ma rallenta molto).
5. Verifica la stima VRAM con la formula: parametri × quantizzazione + ~15-20% overhead.
6. Considera un modello MoE (es. gpt-oss-20b, Qwen3-30B-A3B): grande in qualità ma con pochi parametri attivi, quindi più leggero e veloce.
Tutto quello che devi ricordare in una pagina. Stampala, appendila.