13.6 token al secondo. Su un Ryzen 7 1800X del 2017, quattro vCPU, nessuna GPU. Con llama3.2:1b che gira dentro un container LXC su Proxmox VE. Non è un numero da slide — l'ho misurato io, sul CT 130 del mio homelab, mentre analizzava log di sistema via API REST.
Se stai cercando di capire se ha senso far girare ollama proxmox lxc senza GPU, questo post è la risposta diretta. Ti mostro il setup completo — inclusi due gotcha che mi hanno fatto perdere tempo e che le guide online tendono a nascondere — e i benchmark reali per capire dove funziona e dove no.
Se vuoi il contesto su cosa fa Ollama e perché ha senso nel proprio homelab, c'è una introduzione generale a Ollama che copre le basi. Qui partiamo direttamente dal setup Proxmox.
Cosa serve per Ollama Proxmox LXC — prerequisiti e configurazione CT
Ho creato CT 130 partendo da Ubuntu 22.04 LTS con 4 vCPU, 4 GB di RAM e 15 GB su ZFS mirror. Ollama su Proxmox LXC funziona in ambiente unprivileged — nessun privilegio root nel container — e questo è il motivo per cui il processo di installazione ha due gotcha che lo script ufficiale non gestisce su Ubuntu 22.04. La configurazione minima realistica per llama3.2:1b è 4 GB di RAM: il modello occupa 1.4 GB RSS, il resto serve al sistema.
Il CT va creato come unprivileged — è la modalità default e quella raccomandata. Ma richiede due opzioni che non sono attive di default e senza le quali Ollama non parte:
bash
# /etc/pve/lxc/130.conf
# Aggiungere queste righe manualmente o via UI Proxmox → Options → Features
features: keyctl=1,nesting=1
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Hardware
LLM locale costi reali: serve davvero una GPU da 1.700 euro per battere ChatGPT gratis?
Quanto hardware serve per pareggiare i free tier di ChatGPT, Claude e Gemini con un LLM locale? Ho fatto i conti: GPU, VRAM, elettricità, break-even.
Per i valori di risorse: 4 vCPU e 4 GB RAM sono il minimo realistico per modelli da 1B. Con 2 GB RAM riesci a caricare qwen2:0.5b (378 MB) ma non llama3.2:1b (1.38 GB). Con 2 vCPU i token/s scendono in modo non lineare — non dimezzano, ma peggiorano più del previsto perché l'inferenza ha dipendenze sequenziali che limitano il parallelismo.
Installazione Ollama su LXC Ubuntu 22.04 — i due gotcha reali
Prima di procedere manualmente vale la pena sapere che community-scripts/ProxmoxVE ha uno script Ollama aggiornato al 29 marzo 2026 che installa tutto su Ubuntu 24.04 in un click. Se parti da zero puoi usarlo direttamente. Io ho scelto Ubuntu 22.04 perché era il template che avevo già in uso — ed è lì che ho trovato i due gotcha reali che vale la pena documentare, perché non compaiono in nessuna guida italiana su Ollama LXC container install.
bash
# Community-scripts ProxmoxVE — installa CT Ollama con un comando
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/ollama.sh)"
Lo script crea un CT con Ubuntu 24.04, 4 core, 4 GB RAM e 40 GB di disco (aggiornato al 29/03/2026). Se vuoi partire in cinque minuti senza capire cosa succede, è la scelta giusta.
Io ho fatto a mano la procedura di Ollama LXC container install, su Ubuntu 22.04. Ed è lì che ho trovato i due problemi che lo script nasconde — e che nessuna guida italiana documenta, perché tutte le guide recenti usano Ubuntu 24.04 dove questi problemi non si manifestano.
Gotcha #1 — zstd mancante su Ubuntu 22.04 LXC
Il primo ostacolo arriva quando esegui lo script di installazione ufficiale di Ollama. L'output è un errore abbastanza esplicito: zstd non trovato. L'installer usa zstd per decomprimere i binari e su Ubuntu 22.04 LXC il pacchetto non è installato di default (su 24.04 sì, da qui il silenzio nelle guide recenti).
bash
# Prima di eseguire l'installer Ollama su Ubuntu 22.04 LXC
apt update && apt install -y zstd curl
# Poi l'installer ufficiale (dalla documentazione ufficiale Ollama)
curl -fsSL https://ollama.com/install.sh | sh
Gotcha #2 — il systemd unit non viene creato in LXC unprivileged
L'installer finisce senza errori. Ma Ollama non parte come servizio. Il motivo: in ambiente LXC unprivileged, l'installer non crea il file di unità systemd. Puoi chiamare systemctl status ollama quanto vuoi — non trovi niente. Va creato a mano.
bash
# Creare il file di unità systemd per Ollama
cat > /etc/systemd/system/ollama.service << 'EOF'
[Unit]
Description=Ollama Service
After=network-online.target
[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
Environment="OLLAMA_HOST=0.0.0.0"
[Install]
WantedBy=default.target
EOF
# Ricaricare systemd e avviare il servizio
systemctl daemon-reload
systemctl enable ollama
systemctl start ollama
# Verificare che sia attivo
systemctl status ollama
Una volta che il servizio gira, l'API REST è disponibile su http://<IP_CT>:11434. Puoi verificare con curl http://localhost:11434/api/tags — deve rispondere con un JSON vuoto se non hai ancora caricato modelli.
Caricare i modelli su Ollama Proxmox LXC e verificare il setup
bash
# Scaricare i modelli testati
ollama pull qwen2:0.5b # 352 MB disco
ollama pull llama3.2:1b # 1.23 GB disco
# Verifica rapida — deve rispondere con testo generato
ollama run qwen2:0.5b "Cosa fa un container LXC su Proxmox?" --nowordwrap
# Verifica via API REST
curl -s http://localhost:11434/api/generate \
-d '{"model":"llama3.2:1b","prompt":"Hello","stream":false}' | jq .response
Se il CT ha 15 GB di disco come il mio, stai già al limite con entrambi i modelli: 352 MB + 1.23 GB + sistema base Ubuntu 22.04 LXC porta il disco vicino a 8-9 GB. Tenerlo a mente prima di pull di modelli più grandi.
Benchmark: qwen2:0.5b vs llama3.2:1b su CPU-only
Ho testato i due modelli del mio LLM locale Proxmox — CT 130 (Ollama v0.21.0, Ryzen 7 1800X, 4 vCPU, 4 GB RAM) — con richieste generate via API REST. I numeri sono rilevazioni dirette dal campo eval_rate nell'output JSON di Ollama, più misurazioni manuali del cold start.
Modelloqwen2:0.5b
Disco352 MB
RAM usata378 MB
t/s generazione15.5 t/s
Cold start170 ms
Warm start—
Modellollama3.2:1b
Disco1.23 GB
RAM usata1.38 GB
t/s generazione13.6 t/s
Cold start933 ms
Warm start467 ms
Modello
Disco
RAM usata
t/s generazione
Cold start
Warm start
qwen2:0.5b
352 MB
378 MB
15.5 t/s
170 ms
—
llama3.2:1b
1.23 GB
1.38 GB
13.6 t/s
933 ms
467 ms
ollama list e benchmark: qwen2:0.5b a 15.5 t/s (378MB RAM) vs llama3.2:1b a 13.6 t/s (1.4GB RAM)
Durante l'inferenza il load average è salito a 6.72 con 4 core — quasi 1.7 per core, nella fascia di saturazione. Tenerlo presente se il CT deve condividere il nodo con altri servizi che hanno picchi CPU.
Il test API REST più significativo: una richiesta di analisi log con llama3.2:1b ha restituito 499 token in circa 50 secondi. Con qwen2:0.5b la qualità dell'output è notevolmente inferiore — va bene per classificazioni semplici ma non per analisi con ragionamento.
Per confronto: un MacBook Pro M4 Pro arriva a circa 27 t/s su Gemma3-12B secondo il benchmark di Olares (aprile 2026). Su modelli da 1B il gap è nell'ordine di 3-4x. GPU entry-level vs CPU-only su modelli 8B: 5-30x secondo localllm.in. Se la GPU è già presente nel tuo homelab, i numeri parlano da soli — puoi approfondire l'impatto economico nella guida sui costi LLM locale con GPU.
Dove ha senso e dove no — CPU-only Ollama in produzione
Il punto di rottura per l'uso interattivo è intorno a 8-10 t/s: sotto quella soglia la chat diventa frustrante su risposte lunghe, il cursore lampeggia per secondi interi prima che arrivi testo. Con llama3.2:1b a 13.6 t/s siamo sopra, ma appena sopra. Con un modello 7B (dove CPU-only scende a 3-6 t/s secondo localllm.in) è oggettivamente inutilizzabile per una sessione di lavoro.
Dove CPU-only funziona bene:
Analisi log in batch asincrono via n8n: trigger ogni N minuti → log → Ollama API → webhook o email. 40-60 secondi di latenza sono accettabili se il risultato arriva autonomamente.
Classificazione testi e ticket in batch notturno: cron job quando il nodo è idle.
Summarization di feed RSS o email: latenza non critica, qualità sufficiente con llama3.2:1b.
Sperimentazione e sviluppo prompt: iterare offline senza costi API esterni, privacy garantita.
Dove non ha senso:
Chat interattiva con Open WebUI: lag percepibile già a 13 t/s su risposte lunghe, peggiora drasticamente sotto i 10 t/s.
Code completion nell'IDE: richiede latenza inferiore ai 2s per essere usabile, CPU-only non ci arriva.
Modelli oltre 7B: Ollama senza GPU diventa impraticabile, i tempi di attesa rendono qualsiasi use-case non operativo.
Più richieste concorrenti: un secondo utente dimezza il throughput, la coda si accumula velocemente.
Il CT 130 è il nodo Ollama CPU only del mio homelab, con un ruolo preciso: aggancio n8n per analisi log automatica. Non apro una chat. Non faccio code completion. Per quei casi il modello locale con GPU è un'altra storia — ma finché non ho hardware dedicato, questo setup con 4 core e 4 GB RAM copre la maggior parte dei task che mi interessano davvero.
Se vuoi espandere oltre llama3.2:1b mantenendo le stesse risorse, i candidati più interessanti per task tecnici sono phi4-mini (3.8B, ~2.3 GB, MMLU 67.3% su ragionamento e analisi secondo localaimaster.com) e qwen3:4b (~2.6 GB, MMLU ~70%, ottimo per task in IT e EN). Entrambi stanno nei 4 GB RAM del CT con margine.
Verifica finale — API REST e monitoraggio
Dopo l'installazione di Ollama senza GPU su Proxmox LXC l'API REST è disponibile su porta 11434. Se hai impostato OLLAMA_HOST=0.0.0.0 nel service, è raggiungibile da tutta la LAN — il che la rende utile per n8n, script bash o qualsiasi client HTTP. Tre verifiche per confermare che tutto funzioni correttamente:
Top durante inferenza: 4 core al 98% di utilizzo, processo ollama a 1.4GB RSS
bash
# 1. Servizio attivo
systemctl is-active ollama
# Output atteso: active
# 2. API raggiungibile dall'esterno del CT (sostituire 10.0.x.x con IP reale del CT)
curl -s http://10.0.x.x:11434/api/tags | jq .
# Output atteso: {"models":[...]}
# 3. Test inferenza con misurazione eval_rate
curl -s http://localhost:11434/api/generate \
-d '{"model":"llama3.2:1b","prompt":"Elenca tre vantaggi dei container LXC","stream":false}' \
| jq '{tokens: .eval_count, rate: .eval_rate, duration_s: (.total_duration / 1000000000)}'
Il campo eval_rate nell'output JSON di Ollama è il numero di token al secondo durante la generazione — quello che conta per valutare la performance reale. Il total_duration in nanosecondi include anche il load time del modello (il cold start), quindi varia molto sulla prima richiesta dopo il riavvio del servizio.
Sul monitoraggio: durante l'inferenza il carico CPU è visibile con un semplice htop sul CT — tutti e quattro i core salgono vicino al 100%. Se hai Uptime Kuma o altri monitor HTTP, un check sull'endpoint /api/tags basta per verificare che il servizio risponda.
Per il cluster Proxmox: se il tuo setup include alta disponibilità come descritto nella guida al cluster Proxmox due nodi, il CT Ollama si migra con pct migrate 130 <nodo-dest> --online senza fermare il servizio. Il modello rimane sul disco ZFS replicato.
13.6 t/s con llama3.2:1b su Ryzen 7 1800X, nessuna GPU, 4 GB RAM. È quello che Ollama Proxmox LXC dà con hardware del 2017. Non è il massimo che si può ottenere da un LLM locale — è il massimo che si può ottenere da hardware che già hai. E per analisi log asincrona, classificazione batch e sperimentazione offline, basta.
