web analytics

WordPress e LLM self-hosted nel 2026: come usare AI locale con Ollama, LM Studio e WP 7.0

15/06/2026

Contenuto articolo

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

  1. Installa Ollama su laptop developer.
  2. Testa 3-4 modelli su task reali del tuo workflow (generazione titoli, riassunti, traduzioni).
  3. Misura qualità percepita rispetto a Claude/GPT.

Fase 2 (mese 1): produzione singolo sito

  1. Deploy Ollama su un VPS o Mac Studio dedicato.
  2. Crea il connector WordPress visto sopra.
  3. Migra 1-2 workflow AI-assisted su self-hosted (es. auto-tagging, summarization).

Fase 3 (mese 2-3): scaling

  1. Se il carico cresce, migra a vLLM.
  2. Aggiungi monitoring (Prometheus + Grafana).
  3. Documenta runbook per incident response (OOM, model corrotto, GPU failure).

Fase 4 (mese 4+): evoluzione

  1. Fine-tuning di un modello base sui tuoi dati (con privacy by design).
  2. Setup RAG (Retrieval-Augmented Generation) con Qdrant + Ollama.
  3. 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

Autore articolo: Emilio Petrozzi

🌐 Creazione siti web dinamici e di commercio elettronico 🛍 assistenza WordPress 🌐 Con oltre 20 anni di esperienza nel settore, esperto nella realizzazione di soluzioni digitali personalizzate per il tuo business. 🚀

🔧 Offro assistenza WordPress completa, garantendo che il tuo sito sia sempre aggiornato e funzionante al meglio. 📈 Inoltre mi occupo dell'ottimizzazione per motori di ricerca (SEO), assicurando che il tuo sito sia sempre facilmente rintracciabile dai tuoi clienti. 💻

📢 Le mie campagne pubblicitarie web sono progettate per aumentare la visibilità del tuo brand e generare traffico di qualità verso il tuo sito. 🔒 Inoltre la sicurezza informatica è una priorità in modo tale da garantire i tuoi dati e quelli dei tuoi clienti.

🤝 Affidati a mrtux.it per un servizio professionale e di qualità, e porta il tuo business al successo nel mondo digitale! 🎯

🔑 #CreazioneSitiWeb #Ecommerce #AssistenzaWordPress #OttimizzazioneSEO #SicurezzaInformatica

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


Aricoli correlati

Emilio Petrozzi  P. I.V.A. IT03080230604 - Professionista ai sensi della Legge 4/2013