Contenuto articolo
- Introduzione: perché il self-hosted LLM non è più un esperimento da hipster
- Quando il self-hosted LLM ha senso (e quando è un spreco di soldi)
- Setup Ollama: l'inference server più semplice del 2026
- Integrazione con WordPress 7.0 AI Connectors
- LM Studio: alternativa desktop per team non-DevOps
- vLLM: quando serve throughput enterprise
- Costi reali: self-hosted vs API cloud nel 2026
- Compliance GDPR e AI Act: il vantaggio nascosto del self-hosted
- Integrazione con MCP (Model Context Protocol)
- Roadmap adozione per team WordPress
- FAQ
- Conclusione: self-hosted LLM come scelta strategica, non tecnologica
- Riferimenti utili per approfondire
Introduzione: perché il self-hosted LLM non è più un esperimento da hipster
Fino a 18 mesi fa, l'idea di far girare un modello di linguaggio in produzione su un server WordPress sembrava un esercizio accademico. Nel 2026 è una scelta architetturale concreta, con tre driver reali: costo per token, compliance GDPR/AI Act, e indipendenza da provider che cambiano pricing ogni 6 mesi. OpenAI, Anthropic e Google offrono API eccellenti, ma un'azienda europea che processa 50.000 richieste AI al mese spende tra gli 8.000 e i 25.000 euro. Un server H100 in colocation o un Mac Studio M3 Ultra in ufficio ammortizza lo stesso carico in 6-8 mesi, con la differenza che i dati non lasciano mai il perimetro aziendale.
Abbiamo iniziato a esplorare il self-hosted su mrtux.it per progetti editoriali di clienti con dati sanitari e finanziari, dove il GDPR non è una clausola ma un vincolo di design. Questo articolo è il consolidato di 6 mesi di test su Ollama, LM Studio, vLLM e llama.cpp, integrati con WordPress 7.0 AI Connectors e plugin MCP (Model Context Protocol). Non è un tutorial "installa Ollama in 5 minuti": è una guida operativa per team di sviluppo che devono prendere decisioni di architettura.
Quando il self-hosted LLM ha senso (e quando è un spreco di soldi)
I tre casi in cui il self-hosted vince
1. Compliance stringente: settori regolamentati (sanità, finanza, PA, legal) dove i dati non possono uscire dal perimetro EU o aziendale. LLM self-hosted risolve il problema alla radice. Abbiamo un cliente studio legale milanese che usa Ollama su Mac Studio in ufficio per analizzare 200+ contratti al mese: zero dati escono dall'ufficio, il modello è Llama 3.1 70B Instruct quantizzato Q5.
2. Volume alto e prevedibile: se fai più di 30.000 richieste/mese con prompt medio-lunghi (1500+ token di input), il break-even con API cloud è di 4-6 mesi su hardware adeguato. Sotto quella soglia, il cloud è più economico anche considerando l'overhead di gestione.
3. Latenza e offline-first: tool interni che devono funzionare in ambienti air-gapped (cantieri, navi, stabilimenti) o con latenza sub-100ms. L'inferenza locale batte qualsiasi API cloud su questo fronte.
I tre casi in cui il self-hosted è una pessima idea
1. Pochi utenti e prompt semplici: se fai 500 generazioni di titoli SEO al mese, Ollama è overkill. L'API di OpenAI costa 5 dollari.
2. Team senza competenze DevOps/ML: gestire un inference server significa monitoring (GPU utilization, VRAM, OOM), model updates, security patching. Se non hai almeno una persona con queste competenze, stai buttando soldi.
3. Hai bisogno del modello più aggiornato in tempo zero: i provider cloud rilasciano GPT-5, Claude 4, Gemini 2.5 in settimane. I modelli open source arrivano con 2-6 mesi di ritardo e spesso in versioni quantizzate meno performanti. Se il vantaggio competitivo è "usare l'ultimo modello", self-hosted non è la strada.
Setup Ollama: l'inference server più semplice del 2026
Installazione e primo modello
Ollama è diventato lo standard de facto per self-hosted LLM in locale. Installazione su Linux (Ubuntu 22.04+):
# installa Ollama con lo script ufficiale
curl -fsSL https://ollama.com/install.sh | sh
# avvia il servizio e abilita al boot
sudo systemctl enable --now ollama
# scarica il primo modello: Llama 3.1 8B Instruct (4.7GB)
ollama pull llama3.1:8b-instruct-q5_K_M
# test rapido via CLI
ollama run llama3.1:8b-instruct-q5_K_M "Riassumi in 50 parole cosa fa WordPress"
Per workload di produzione si sale a Llama 3.1 70B o Qwen 2.5 72B, che richiedono GPU con almeno 48GB di VRAM (2x RTX 6000 Ada, 1x A100 80GB, 1x Mac Studio M3 Ultra 192GB). I modelli quantizzati Q4/Q5 permettono di scendere a 24-32GB di VRAM con perdita di qualità accettabile per task di generazione e summarization.
Esposizione API compatibile OpenAI
Ollama espone nativamente un'API su http://localhost:11434 con un endpoint OpenAI-compatible: POST /v1/chat/completions. Questo significa che qualsiasi plugin WordPress o libreria che usa OpenAI SDK può puntare a Ollama con cambio di due parametri (base URL + API key fittizia). È il vantaggio competitivo chiave rispetto a llama.cpp nudo.
# test API compatibile OpenAI
curl -X POST http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"llama3.1:8b-instruct-q5_K_M","messages":[{"role":"user","content":"Ciao, chi sei?"}]}'
Integrazione con WordPress 7.0 AI Connectors
Architettura del Connector
WordPress 7.0 ha introdotto gli AI Connectors come sistema unificato per parlare con provider AI. Il connettore custom per Ollama è un plugin di una quarantina di righe che registra un provider type e gestisce capability + kill switch. Approfondiremo il pattern generale; per i dettagli sull'architettura dei Connectors rimandiamo a WordPress 7.0 AI Connectors: guida operativa per sviluppatori e agenzie che abbiamo già pubblicato su mrtux.it.
<?php
/**
* Plugin Name: Ollama Connector for WP 7.0 AI
* Description: Connects WordPress 7.0 AI subsystem to self-hosted Ollama instance
* Version: 1.0.0
*/
add_filter( 'wp_ai_providers', function( $providers ) {
$providers['ollama_local'] = [
'label' => __( 'Ollama (Self-hosted Local)', 'ollama-connector' ),
'endpoint' => defined( 'OLLAMA_ENDPOINT' ) ? OLLAMA_ENDPOINT : 'http://localhost:11434/v1',
'models_url' => '/v1/models',
'chat_url' => '/v1/chat/completions',
'capabilities' => [ 'chat', 'embeddings', 'summarization' ],
'kill_switch' => defined( 'WP_AI_SUPPORT' ) ? WP_AI_SUPPORT : true,
'auth_type' => 'none', // Ollama di base non ha auth
];
return $providers;
});
Configurazione e variabili d'ambiente
// wp-config.php: definire endpoint e policy
define( 'OLLAMA_ENDPOINT', 'http://10.0.0.50:11434/v1' ); // IP interno del server Ollama
define( 'WP_AI_SUPPORT', true ); // abilita il provider
define( 'WP_AI_DEFAULT_MODEL', 'llama3.1:8b-instruct-q5_K_M' );
Test del connettore via WP-CLI
# verifica che il provider sia registrato
wp eval 'print_r( apply_filters( "wp_ai_providers", [] ) );'
# genera un post riassunto via AI
wp ai generate --provider=ollama_local --model=llama3.1:8b --prompt="Scrivi un riassunto di 100 parole del plugin Yoast SEO" --post=12345
Il comando wp ai è il wrapper CLI introdotto in WP 7.0 che astrae dal provider. Cambiare provider = cambiare un parametro, senza toccare il codice del plugin.
LM Studio: alternativa desktop per team non-DevOps
Quando LM Studio batte Ollama
LM Studio è un'app desktop (macOS, Windows, Linux) che fa le stesse cose di Ollama ma con GUI. Per team che non vogliono gestire systemd, prompt bash e aggiornamenti manuali, è una scelta pragmatica. Limite principale: gira sul desktop di un singolo sviluppatore, non è pensato per produzione multi-utente.
Casi d'uso reali
- Prototipazione rapida: 5 minuti per scaricare un modello e testarlo, 0 configurazione server.
- Demo a clienti: mostri un workflow AI in locale, nessun dato lascia la macchina.
- Formazione interna: developer imparano i prompt engineering senza dover gestire infra.
Per produzione, Ollama vince su tutti i fronti: cluster mode, monitoring, OpenAI API compatibility, model management.
vLLM: quando serve throughput enterprise
vLLM è l'inference server per carichi alti. Supporta PagedAttention (fino a 24x throughput in più rispetto a HuggingFace Transformers), continuous batching, e speculative decoding. Lo usiamo quando Ollama non ce la fa: siti con 100+ utenti concorrenti che fanno richieste AI.
# installa vLLM (richiede Python 3.10+ e GPU NVIDIA)
pip install vllm
# avvia server con Llama 3.1 70B quantizzato AWQ
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-70B-Instruct-AWQ \
--quantization awq \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.9
# test throughput: quante richieste/secondo regge
vllm bench --model meta-llama/Llama-3.1-70B-Instruct-AWQ --num-prompts 100
Per un sito WordPress editoriale con 50 articoli/giorno e AI-assisted tagging, Llama 3.1 8B su Ollama basta. Per un portale WooCommerce con AI search su 100k prodotti, vLLM 70B è necessario. La scelta non è religiosa ma basata su carico.
Costi reali: self-hosted vs API cloud nel 2026
Scenario 1: piccola agenzia (5 developer, uso interno)
- API cloud (Claude Sonnet 4.5, 20M token/mese): 600-1.000 €/mese
- Self-hosted (Mac Studio M3 Ultra 192GB, 1 modello 70B quantizzato Q4): 5.500 € ammortamento + 50 €/mese elettricità = 510 €/mese equivalenti in 12 mesi
- Break-even: 7-8 mesi
Scenario 2: media azienda (50 dipendenti, tool AI interno)
- API cloud (GPT-5, 200M token/mese): 6.000-12.000 €/mese
- Self-hosted (2x H100 in colocation, modello 70B FP16): 28.000 € setup + 1.200 €/mese housing/energia = 3.500 €/mese equivalenti in 12 mesi
- Break-even: 4-5 mesi
Scenario 3: enterprise con compliance EU
- API cloud: vietato per dati sanitari/finanziari
- Self-hosted on-prem (4x A100 80GB, modello custom fine-tuned): 80.000 € setup + manutenzione
- Decisione: non economica, obbligata
I numeri reali dipendono da pattern di utilizzo, modello scelto, e prezzo dell'energia. Su mrtux.it abbiamo pubblicato un tool di calcolo che stima il break-even in base a token/mese, modello, costo elettricità e investimento hardware.
Compliance GDPR e AI Act: il vantaggio nascosto del self-hosted
Dati che non escono dal perimetro
Con Ollama self-hosted, i prompt e le risposte non transitano mai su server di terze parti. Questo significa: nessun data processing agreement con OpenAI/Anthropic, nessuna preoccupazione per data retention policy americane (FISA 702, CLOUD Act), nessun rischio di training on user data.
Per settori come sanità, finanza, PA, difesa, legale, il self-hosted non è un'opzione: è l'unica strada per usare LLM in modo legale in Europa post-AI Act.
Audit e logging on-prem
Tutte le richieste AI restano su log locali. Per audit GDPR (art. 30 registro trattamenti) è un vantaggio enorme: il registro contiene già tutti i dati necessari senza integrazioni esterne.
# log di tutte le richieste Ollama in formato JSON strutturato
sudo journalctl -u ollama --output=json | jq 'select(.MESSAGE | contains("POST /v1/chat"))' > /var/log/ollama-audit.jsonl
Integrazione con MCP (Model Context Protocol)
Server MCP Ollama
MCP è il protocollo standard di Anthropic per connettere LLM a tool e dati esterni. Esiste un server MCP Ollama che permette a Claude Desktop, Cursor o altri client MCP di usare Ollama come backend. Per WordPress, significa che un developer può chiedere a Claude: "Analizza questo sito WordPress e dimmi quali plugin hanno vulnerabilità note" e Claude usa Ollama + i tool MCP di WordPress per rispondere, con i dati che restano locali.
// claude_desktop_config.json: aggiungi Ollama come provider
{
"mcpServers": {
"ollama-local": {
"command": "ollama",
"args": ["serve"],
"env": { "OLLAMA_HOST": "127.0.0.1:11434" }
}
}
}
Roadmap adozione per team WordPress
Fase 1 (settimana 1-2): sperimentazione
- Installa Ollama su laptop developer.
- Testa 3-4 modelli su task reali del tuo workflow (generazione titoli, riassunti, traduzioni).
- Misura qualità percepita rispetto a Claude/GPT.
Fase 2 (mese 1): produzione singolo sito
- Deploy Ollama su un VPS o Mac Studio dedicato.
- Crea il connector WordPress visto sopra.
- Migra 1-2 workflow AI-assisted su self-hosted (es. auto-tagging, summarization).
Fase 3 (mese 2-3): scaling
- Se il carico cresce, migra a vLLM.
- Aggiungi monitoring (Prometheus + Grafana).
- Documenta runbook per incident response (OOM, model corrotto, GPU failure).
Fase 4 (mese 4+): evoluzione
- Fine-tuning di un modello base sui tuoi dati (con privacy by design).
- Setup RAG (Retrieval-Augmented Generation) con Qdrant + Ollama.
- Valutazione di alternative (vLLM, TensorRT-LLM, SGLang) in base al carico.
FAQ
Ollama è pronto per la produzione?
Sì, dal 2025 Ollama ha cluster mode (multi-GPU, multi-host), monitoring integrato, e API stabile. Lo usiamo in produzione su 3 clienti enterprise con carichi fino a 200 richieste/minuto. Per carichi superiori, vLLM è la scelta.
Quale modello scegliere per task generici WordPress?
Per uso generale: Llama 3.1 8B Instruct (qualità sorprendente per le dimensioni). Per qualità massima: Llama 3.1 70B o Qwen 2.5 72B. Per embedding (search, RAG): nomic-embed-text o mxbai-embed-large. Per italiano specifico: modelli come MareADev/Proxima-1.5B-Instruct o fine-tuning su dati italiani.
Quanto costa un server H100 usato?
Una H100 80GB SXM nuova costa 25.000-35.000 €. Usata (1 anno, garanzia) 15.000-22.000 €. Noleggio mensile (Lambda, RunPod, Vast.ai) 2-3 €/ora = 1.500-2.200 €/mese per uso 24/7.
Posso usare Apple Silicon (M1/M2/M3)?
Sì, con Ollama o llama.cpp. Mac Studio M2/M3 Ultra con 64-192GB di memoria unificata è una scelta eccellente per team che vogliono semplicità. Performance inferiori a H100 di circa 3-5x ma costi hardware molto più bassi e zero rumore in ufficio.
Il self-hosted è conforme all'AI Act europeo?
Dipende dal caso d'uso. AI Act classifica i sistemi per rischio. Per uso interno aziendale (non destinato a interazione con consumatori), spesso ricade in "rischio limitato" con obblighi di trasparenza minori. Consulta sempre un legale specializzato, la materia è in evoluzione.
Come gestisco gli aggiornamenti dei modelli?
Ollama supporta ollama pull <model> per scaricare versioni aggiornate. In produzione, testiamo il nuovo modello in staging per 1-2 settimane su un campione di prompt reali, poi aggiorniamo produzione. Non aggiornare modello e prompt insieme: tienili separati per isolare regressioni.
Conclusione: self-hosted LLM come scelta strategica, non tecnologica
L'LLM self-hosted non è una moda da devoto di Linux né una scelta puramente economica. È una decisione di sovranità digitale che diventa obbligata in certi contesti e strategicamente vantaggiosa in molti altri. Il setup è alla portata di qualsiasi team WordPress con un minimo di competenze DevOps: Ollama in 10 minuti, connector in 40 righe di codice, test in un'ora. La parte difficile è la governance: prompt management, valutazione qualità, monitoraggio costi, policy di aggiornamento.
La domanda da porsi non è "posso permettermi di passare al self-hosted?" ma "posso permettermi di non avere il self-hosted come opzione per i miei clienti enterprise?". Nel 2026 la risposta è quasi sempre no. Su mrtux.it continueremo a documentare setup reali, modelli testati, e pattern di integrazione con WordPress mano a mano che l'ecosistema matura.
Riferimenti utili per approfondire
- Sito ufficiale Ollama - download, documentazione, model library aggiornata.
- Ollama GitHub Repository - codice sorgente, issue tracker, roadmap pubblica.
- LM Studio - alternativa desktop con GUI per uso locale non-produzione.
- vLLM Documentation - inference server ad alte prestazioni per produzione.
- MCP Server Ollama - implementazione Model Context Protocol per Ollama.
- WordPress 7.0 AI Connectors - MrTux.it - guida operativa completa sull'architettura dei Connectors WP 7.0.
- Hugging Face Model Hub - catalogo di modelli open source con licenze e benchmark.
- RunPod - GPU Cloud - noleggio GPU on-demand per test e produzione.
- Lambda Labs - GPU Cloud - cluster H100/H200 con pricing trasparente.
- WP Tavern - WordPress News - copertura delle novità AI nel core WordPress.
- Kinsta Blog - articoli su performance, hosting e infrastruttura AI.
- Mrtux.it Sviluppo Web - archivio articoli tecnici su architetture WordPress avanzate.




Lascia un commento