Self-hosted LLM stack: alternative Ollama 2026

1. Landscape 2026: dove siamo con inference engine

A inizio 2026, il self-hosted inference si divide in 4 macrocategorie:

• Ollama - "Zero-config LLM" orientato consumer/developer. Interfaccia REST semplice, built-in quantization, 1.5M+ GitHub stars. Dominante su single-machine setups.
• vLLM - "Production-grade serving engine" di Berkeley/LMSYS. PagedAttention revolutionaria, multi-GPU parallelization, 30k+ GitHub stars. Scalability tier primario.
• llama.cpp - "Leggerissimo, C-only inference." Quantization spinta (2-bit), 50kB binary, CPU-only viable. Ggml-based ecosystem.
• Text Generation Inference (TGI) - Hugging Face production engine. Continuous batching, token streaming, Docker-native. Enterprise focus.

Nel 2026 il criterio di scelta è semplice: se PMI EU con <100 req/sec, valuta Ollama; se scaling >500 req/sec o multi-GPU, vai vLLM; se constraint memoria VRAM <8GB, llama.cpp è salvagente.

2. Ollama: la scelta sicura per developer (setup corrente)

Ollama resta la baseline per 80% dei self-hosted deployments sotto 2026. Perché? Tre ragioni:

• Zero friction onboarding: `ollama pull llama3.1:8b && ollama serve` → REST API su port 11434 in 2 minuti. Curve learning assente. Perfetto per MVP e prototype.
• Quantization nativa: Library GGML integrata, auto-seleziona Q4_K_M vs Q5_K_M vs FP16 basato su VRAM disponibile. Senza configurazione manuale.
• Streaming JSON response support: `stream: true` parametro consente token-by-token generation ideale per UI/UX frontend.

Benchmark Ollama su CCX23 (4vCPU, 16GB RAM):

Verdict Ollama: Best per <10 req/sec concurrent, single-machine, Italia/EU governance strict. Memory footprint moderate 2-6GB. Maintenance burden minimal. Upgrade path a vLLM se scale richiesto.

3. vLLM: il power-user choice per throughput

vLLM (Berkeley LLM Serving Engine) dal 2023 ha introdotto PagedAttention, una rivoluzione negli algoritmi di caching del KV. Idea: tokenize output come pagine di RAM, swap in/out le pagine meno usate senza copy memoria. Risultato: 20-40% latency reduction + 10x memory efficiency vs naive KV caching.

vLLM è production-grade se PMI PMI EU richiede:

• Batch inference multi-query parallelo (10-50 req simultanee)
• Multi-GPU scaling (TP=tensor parallelism, PP=pipeline parallelism)
• Token streaming per LLM-per-token UI feedback
• Metriche Prometheus/monitoring built-in

Setup vLLM su CCX23 (single GPU scenario non applicabile; richiede GPU. Simuliamo con CPU-only baseline):

# Install vLLM (richiede PyTorch + CUDA toolkit se GPU)
pip install vllm==0.4.2

# Start vLLM server (CPU fallback)
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-2-7b-hf \
  --max-num-seqs=10 \
  --max-model-len=4096 \
  --dtype float16 \
  --port 8000

# Client example
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-2-7b-hf",
    "prompt": "Explain AI in Italian",
    "max_tokens": 100,
    "temperature": 0.3,
    "stream": true
  }' | jq '.'

vLLM benchmark vs Ollama (same hardware, Llama 3.1 8B Q4):

Verdict vLLM: Migliore se batch concurrency >5 req/sec, multi-GPU planning, EU data governance. Setup Docker via HuggingFace Inference Endpoints. Trade-off: config più complessa, learning curve 1-2 weeks.

4. llama.cpp: il minimalist edge case

llama.cpp (Georgi Gerganov, C++ single-threaded inference) esiste per un caso d'uso: VRAM <8GB, CPU-only devices, 2-bit quantization estrema.

Perché extremism? Llama.cpp supporta 2-bit (I2) e 3-bit quantization che vLLM/Ollama non fanno ancora robustly. Trade-off: accuracy loss 5-15% su tasks semantiche, ma se workload è "classify document in category", 2-bit è viable.

# Build llama.cpp from source
git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make -j$(nproc)

# Convert HF model to GGML format (Llama 3.1 8B)
python3 convert.py ../models/llama-3.1-8b

# Quantize to 2-bit (extreme compression)
./quantize ../models/llama-3.1-8b.gguf \
  ../models/llama-3.1-8b-I2.gguf I2

# Run inference server (minimal deps)
./server -m ../models/llama-3.1-8b-I2.gguf \
  -ngl 0 \
  --port 8000

# Size comparison
ls -lh ../models/llama-3.1-8b*.gguf
# F32: 33GB, Q8: 8.5GB, Q4_K_M: 4.7GB, I2: 2.1GB (!!)

llama.cpp benchmark (I2 vs Q4):

Verdict llama.cpp: Use only se VRAM <3GB è hard constraint, o edge device (RPi 5, Jetson Nano). Per PMI EU server scenario, trade-off accuracy/speed non giustificato. Production-ready: no (maintenance burden C++, community smaller).

5. Text Generation Inference (TGI) Hugging Face

TGI (Text Generation Inference) è il motore Hugging Face per production inference. Differenzia vLLM per:

• Docker-first design: Immagine pre-built per tutte le GPU/CPU, no pip hell
• Continuous batching + token streaming: Rispetto a vLLM, scheduler è più aggressive su dynamic batching
• OpenAI API compliance: Drop-in replace per OpenAI client libraries (Python, JS, Go)
• Quantization via bitsandbytes: Native 4-bit, 8-bit, gptq integration
• HuggingFace Hub native: Auto-download modelli da HF, permissioning via token

# Pull + run TGI Docker (no GPU variant)
docker run --rm \
  -p 8000:80 \
  -e MODEL_ID=meta-llama/Llama-2-7b-hf \
  -e QUANTIZE=bitsandbytes \
  ghcr.io/huggingface/text-generation-inference:2.0

# Client (Python)
from openai import OpenAI

client = OpenAI(
    api_key="whatever",
    base_url="http://localhost:8000/v1"
)

response = client.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    prompt="Spiega AI",
    max_tokens=100,
    stream=True
)

for chunk in response:
    print(chunk.choices[0].text, end='')

TGI benchmark (Docker, CPU baseline):

Verdict TGI: Best per enterprise adoption + existing OpenAI integrations. Docker containerization riduce ops friction. Support team Hugging Face corporate. Trade-off: meno community activity vs vLLM, meno tutorials.

6. EU Sovereignty constraints: quale stack per GDPR/data residency

Tutti e 4 i motori sopra sono EU-friendly se installati on-prem Hetzner/OVH. Nessun cloud call-home, nessun data exfil a US. Ma discriminant è:

• Ollama: Download modelli da HuggingFace (US) una sola volta al setup. After, 100% local. Dato personale: NON trasmesso.
• vLLM: Idem Ollama. Modelli da HF, inference local. Prometheus/logging opzionale (self-managed).
• llama.cpp: Zero cloud dependencies dopo build. Locale assoluto.
• TGI: Docker image da ghcr.io (GitHub Containers, Microsoft US). Richiede pull una volta. Modelli da HF. After, local.

Se GDPR Article 32 (data processing on-prem only) non negoziable, scegli Ollama o llama.cpp. vLLM/TGI su container own-managed interno è viable, ma ops overhead aumenta.

7. Qual è la scelta ottimale per PMI EU 2026?

Matrice decisionale finale:

8. Hybrid approach: Ollama primary + vLLM failover

Per PMI risk-averse, ibrido è ottimale:

# FastAPI routing intelligente
from fastapi import FastAPI
import httpx
import os

app = FastAPI()

OLLAMA_URL = os.getenv("OLLAMA_URL", "http://localhost:11434")
VLLM_URL = os.getenv("VLLM_URL", "http://vllm-gpu:8000")

@app.post("/api/query")
async def query_hybrid(request: QueryRequest):
    """
    1. Try Ollama (fast, local CPU)
    2. On timeout/error, fallback to vLLM (batch queue)
    """

    try:
        # Attempt Ollama (sub-second overhead, streaming)
        async with httpx.AsyncClient(timeout=2.0) as client:
            resp = await client.post(
                f"{OLLAMA_URL}/api/generate",
                json={
                    "model": "llama3.1:8b",
                    "prompt": request.query,
                    "stream": True
                }
            )
            return StreamingResponse(
                resp.aiter_bytes(),
                media_type="text/event-stream"
            )
    except (httpx.TimeoutException, httpx.ConnectError):
        # Fallback: vLLM (may have lower throughput but higher accuracy queue)
        print("[FALLBACK] Ollama unavailable, using vLLM queue")
        async with httpx.AsyncClient() as client:
            resp = await client.post(
                f"{VLLM_URL}/v1/completions",
                json={
                    "model": "llama-3.1-8b",
                    "prompt": request.query,
                    "max_tokens": 100,
                    "stream": True
                }
            )
            return StreamingResponse(
                resp.aiter_bytes(),
                media_type="text/event-stream"
            )

Benefici approccio ibrido:

• Ollama prima choice: <100ms overhead per request, deterministic
• vLLM fallback: cala latency end-to-end se Ollama sotto carico
• Zero user-facing latency increase: client riceve first-token stesso timer
• Operational insurance: 1 sistema down ≠ API down

9. FAQ comuni (12)

Q1: Posso migrare setup Ollama a vLLM senza riscrivere app?

A: Parzialmente. vLLM non supporta Ollama JSON schema identico. Adapter layer necessario in FastAPI (~50 righe). Vedi articolo 1280 per deep dive vLLM production.

Q2: Quale quantization scegliere per Ollama se VRAM limitata?

A: Ollama auto-seleziona. Se VRAM <5GB, usa Q4_K_M (4.7GB). Se <3GB, Q3_K_M (3.3GB, accuracy -3%). Se <2GB, llama.cpp I2 è unica opzione.

Q3: vLLM supporta streaming tokens come Ollama?

A: Sì, via SSE (Server-Sent Events). Parametro `stream: true` in request, client riceve token-by-token. Identico UX Ollama.

Q4: EU data residency: è TGI su Hetzner GDPR compliant?

A: Sì se deployment completamente on-prem. Docker pull una volta, after zero external calls. Modelli HuggingFace cached local.

Q5: Cost comparison annuale su Hetzner CCX23?

A: Ollama/vLLM/TGI: €293/anno (€24.49/mese CCX23). llama.cpp: €0 se own machine. ROI vs OpenAI API: break-even a 50k queries/mese.

Q6: Multi-language support: quale motore meglio per Italian RAG?

A: Ollama, vLLM, TGI: tutti agnostic. Dipende embedding model (sentence-transformers all-MiniLM-L6-v2 supporta 50+ lingue). llama.cpp: idem.

Q7: Can llama.cpp run quantized model con bitsandbytes 4-bit?

A: No. llama.cpp è GGML-native (GGUF format). Bitsandbytes è PyTorch-only (vLLM/TGI). Due ecosistemi incompatibili.

Q8: Quale engine ha best per token counting accuracy pre-inference?

A: TGI: built-in Rust tokenizer matches modello esatto. vLLM: tiktoken library. Ollama: approximation (±5% error). Importante per SLA latency prediction.

Q9: vLLM tensor parallelism su 2 GPU Hetzner: è worth?

A: Sì se Llama 3.1 70B model. Distributed TP riduce memoria per GPU. Su 8B: no, single GPU sufficiente.

Q10: Posso runare Ollama + vLLM in container Docker Compose?

A: Sì. Ollama: `docker pull ollama/ollama`, espone port 11434. vLLM: ghcr.io image, port 8000. Compose orchestration facile.

Q11: EU cloud provider alternativa a Hetzner?

A: OVH (Francia), Contabo (Germania), Vultr (Olanda). Tutti offer CCX-equivalent machines. Hetzner però best price/perf 2026.

Q12: Se Ollama down, client riceve error o fallback graceful?

A: Dipende app implementazione. Consiglio circuit breaker (Resilience4j Java, tenacity Python). Vedi sezione 8 hybrid approach.

10. Conclusione: roadmap scelta engine 2026

PMI EU nel 2026 ha landscape diverse ma convergente su open-source on-prem. Ollama rimane entry-point ottimale per 90% dei casi: semplicità, zero config, GDPR native, community support. vLLM diventa necessaria a scale 50+ req/sec con GPU disponibile. TGI per enterprise con OpenAI integrations. llama.cpp per edge/mobile case specifici.

Roadmap suggerita:

1. Start Ollama 2-4 settimane, validate workload
2. Monitor latency/throughput metrics
3. If <5 req/sec sustained, stay Ollama con caching Redis
4. If 5-50 req/sec, migrate vLLM single GPU
5. If >50 req/sec, vLLM multi-GPU TP

Nessuna scelta è "forever lock-in": APIgap tra stack è minimale (REST/OpenAI compliant). Switching cost <2 settimane engineering time.