LLM serving alternatives 2026: LM Studio, SGLang, text-generation-webui, Llamafile

LLM serving alternatives 2026: LM Studio, SGLang, text-generation-webui, Llamafile

vLLM è lo strumento giusto se devi servire centinaia di richieste al secondo in produzione. Ma la maggior parte dei progetti che incontro - startup con 10-50 utenti attivi, team interni, demo per clienti, workflow di ricerca - non ha bisogno di PagedAttention e tensor parallelism. Ha bisogno di qualcosa che funzioni in cinque minuti, che non richieda un DevOps dedicato, e che sia abbastanza stabile per una demo o un prototipo che poi potrebbe diventare produzione.

Nel 2026 l'ecosistema LLM serving si è frammentato in direzioni interessanti. LM Studio ha aggiunto un daemon headless serio. SGLang è diventato contemporaneamente un DSL per programmare LLM in Python e un runtime ad alte prestazioni. text-generation-webui continua ad essere la scelta più flessibile per chi sperimenta quantizzazioni esotiche. Llamafile ha spinto il concetto di portabilità all'estremo: un file, sei sistemi operativi, zero dipendenze. In questo episodio confronto questi quattro strumenti con dati concreti, esempi di codice reali e una decision matrix pratica.

Una premessa personale: nel mio portfolio backend uso Ollama come provider primario su VPS Hetzner perché gira come systemd service con zero overhead di gestione e consuma 0 euro al mese. Ma quando devo fare una demo veloce con un cliente che non sa cos'è un terminale, apro LM Studio, carico il modello con tre click e gli mostro l'API funzionante in 30 secondi. Contesti diversi richiedono strumenti diversi. Questa è la premessa da cui parto.

Sezione 1 - LM Studio: da desktop app a headless server

LM Studio è nato come app desktop per chi voleva provare LLM locali senza mettere le mani in un terminale. Modello scaricato con un click, chat integrata, API server in un toggle. Il problema è che questa narrativa "GUI-first" ha oscurato un'evoluzione significativa: dal 2024 LM Studio include llmster, il daemon headless che gira su server Linux senza dipendenze X11, controllabile interamente via CLI.

Il workflow headless ha tre fasi: installazione del daemon, caricamento del modello, avvio del server. Il tutto si controlla con il tool lms.

# Installazione llmster (daemon headless) su Linux
curl -fsSL https://installers.lmstudio.ai/linux/x86_64/latest/lmstudio-installer.sh | bash

# Verifica installazione
lms --version

# Avvia il daemon in background
lms daemon start

# Carica un modello (usa il nome del modello da LM Studio)
lms load "lmstudio-community/Meta-Llama-3.1-8B-Instruct-GGUF"

# Avvia il server API sulla porta 1234 (default)
lms server start --port 1234

# Avvia con log verbose per debugging
lms server start --port 1234 --log-level verbose

# Verifica stato server
lms status

Il server espone un'API OpenAI-compatible sul path /v1/chat/completions. Questo significa che qualsiasi client OpenAI esistente funziona senza modifiche, semplicemente cambiando base URL. Il modello viene tenuto in memoria tra una richiesta e l'altra, senza cold start. Il daemon sopravvive ai logout dell'utente e può essere configurato come systemd service con uno script dedicato.

Il limite principale è la concorrenza: LM Studio gestisce le richieste in coda (FIFO), non in parallelo. Se due utenti chiamano l'API contemporaneamente, la seconda aspetta che la prima finisca. Per un singolo sviluppatore o una demo con un utente alla volta, questo va benissimo. Per un team di 5+ persone in produzione, diventa un collo di bottiglia.

Il vantaggio competitivo di LM Studio è la semplicità dell'interfaccia: il modello discovery, il download con progress bar, la gestione della VRAM disponibile sono tutti automatici. Per chi non vuole occuparsi di GGUF quantization, ollama pull o compatibilità hardware, LM Studio è genuinamente la scelta più rapida.

Sezione 2 - SGLang: programmare LLM come un DSL

SGLang (Structured Generation Language) è il progetto più difficile da classificare in questa lista perché è, al contempo, due cose diverse: un frontend DSL per scrivere workflow LLM in Python, e un runtime server ad alte prestazioni basato su un fork ottimizzato di vLLM. L'idea originale, nata a Berkeley, era questa: il prompt engineering è codice, quindi deve avere le stesse astrazioni del codice (funzioni, variabili, parallellismo, caching).

Il DSL si usa attraverso il decoratore @sgl.function. Ogni "programma" SGLang riceve un oggetto stato s che traccia la history del prompt e le variabili generate:

import sglang as sgl

# Connessione al backend (Ollama, vLLM, o runtime SGLang)
sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))

# Definizione di un programma SGLang come funzione Python
@sgl.function
def estrai_entita(s, testo: str):
    """Estrae entità nominate da un testo in italiano."""
    s += sgl.system("Sei un esperto di NLP. Rispondi sempre in JSON valido.")
    s += sgl.user(f"Estrai le entità nominate da questo testo:\n\n{testo}")
    # gen() genera testo; json_schema vincola il formato
    s += sgl.assistant(
        sgl.gen(
            "risultato",
            max_tokens=512,
            json_schema={
                "type": "object",
                "properties": {
                    "persone": {"type": "array", "items": {"type": "string"}},
                    "luoghi": {"type": "array", "items": {"type": "string"}},
                    "organizzazioni": {"type": "array", "items": {"type": "string"}}
                }
            }
        )
    )

# Esecuzione singola
stato = estrai_entita.run(
    testo="Federico Calò ha fondato il progetto a Bari con il supporto di PoliBA."
)
print(stato["risultato"])  # JSON strutturato garantito

# Esecuzione batch parallela (fork interno)
testi = ["Testo uno...", "Testo due...", "Testo tre..."]
stati = estrai_entita.run_batch(
    [{"testo": t} for t in testi],
    num_threads=3  # esecuzione parallela con 3 thread
)
for s in stati:
    print(s["risultato"])

La caratteristica killer del runtime SGLang è RadixAttention: una struttura dati a radix tree che identifica automaticamente i prefix condivisi tra richieste diverse e riusa la loro KV cache. In pratica, se 50 chiamate condividono lo stesso system prompt (un caso comune in produzione), il costo computazionale del prefix viene pagato una volta sola. I benchmark di Berkeley riportano hit rate del 60-80% su workload multi-turn tipici, con riduzione della latenza media del 40-60% rispetto a KV cache lineare.

Per avviare il runtime SGLang come server standalone:

# Installazione
pip install sglang[all]

# Avvio runtime server con modello Hugging Face
python -m sglang.launch_server \
    --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \
    --port 30000 \
    --tp 1 \
    --enable-prefix-caching \
    --mem-fraction-static 0.85

# Verifica health
curl http://localhost:30000/health

# Il server espone anche endpoint OpenAI-compatible
curl http://localhost:30000/v1/models

Il trade-off di SGLang è la curva di apprendimento: capire il DSL richiede tempo, e il vantaggio si vede solo su workflow complessi con struttura ripetitiva (RAG, chain-of-thought, multi-step classification). Per una semplice chat API, Ollama o LM Studio sono più veloci da configurare.

Sezione 3 - text-generation-webui: il coltellino svizzero della quantizzazione

text-generation-webui (oobabooga) esiste da quando GPT-4 non era ancora stato annunciato. È il tool preferito dalla community che sperimenta quantizzazioni non mainstream, perché supporta backend multipli che puoi switchare a runtime: llama.cpp (GGUF), ExLlamaV2, GPTQ, AWQ, bitsandbytes, Transformers standard. Nessun altro tool in questa lista offre questa flessibilità.

L'installazione avviene tramite script one-click o manualmente:

# Clona e setup (Linux/macOS)
git clone https://github.com/oobabooga/text-generation-webui.git
cd text-generation-webui

# Script one-click (rileva automaticamente GPU NVIDIA/AMD/CPU)
bash start_linux.sh

# Oppure installazione manuale con pip
conda create -n textgen python=3.11
conda activate textgen
pip install -r requirements.txt  # o requirements_amd.txt per ROCm

# Avvio con API abilitata su porta 5000
python server.py \
    --api \
    --api-port 5000 \
    --api-key "mia-chiave-segreta" \
    --listen \
    --model "TheBloke/Llama-2-13B-chat-GGUF" \
    --loader llama.cpp \
    --n-gpu-layers 35  # numero di layer da offloadare su GPU

# Aggiungere flag a CMD_FLAGS.txt per persistenza
echo "--api --api-port 5000 --listen" >> user_data/CMD_FLAGS.txt

Una volta avviato, l'API è accessibile su http://localhost:5000/v1 con endpoint /chat/completions e /completions in formato OpenAI-compatible. C'è anche un endpoint WebSocket per streaming. L'interfaccia web è disponibile su porta 7860 (Gradio).

Il caso d'uso tipico di text-generation-webui è la ricerca: vuoi confrontare lo stesso modello in GPTQ vs AWQ vs GGUF 4-bit? Puoi farlo senza reinstallare nulla, switchando loader dal menu. Vuoi provare ExLlamaV2 con speculative decoding su un modello da 70B quantizzato? text-generation-webui è il posto giusto. In produzione con carico reale, probabilmente passerai a vLLM o SGLang runtime, ma per la fase di sperimentazione questo tool è imbattibile.

Il limite principale è la performance in concorrenza: come LM Studio, non usa batching dinamico. Richieste multiple vengono processate sequenzialmente. Con ExLlamaV2 si ottengono buoni token per secondo single-stream (~85 tok/s su RTX 3090 con Llama 3.1 8B), ma il throughput concorrente rimane basso.

Sezione 4 - Llamafile: zero dipendenze, sei sistemi operativi

Llamafile è il progetto più radicale di questa lista. Mozilla Research ha combinato llama.cpp con Cosmopolitan Libc per creare binari nel formato APE (Actually Portable Executable): lo stesso file è contemporaneamente un PE valido (Windows), un ELF (Linux/BSD) e un Mach-O (macOS). Il risultato è che un singolo file .llamafile contiene il modello e il runtime, e funziona su sei sistemi operativi senza installare nulla.

# Download di un modello Llamafile (esempio: Mistral 7B)
wget https://huggingface.co/Mozilla/Mistral-7B-Instruct-v0.2-llamafile/resolve/main/mistral-7b-instruct-v0.2.Q4_0.llamafile

# Rendi eseguibile (Linux/macOS)
chmod +x mistral-7b-instruct-v0.2.Q4_0.llamafile

# Avvio server (apre browser di default)
./mistral-7b-instruct-v0.2.Q4_0.llamafile

# Avvio headless senza browser su porta personalizzata
./mistral-7b-instruct-v0.2.Q4_0.llamafile \
    --server \
    --nobrowser \
    --port 8080 \
    --host 0.0.0.0

# Modalità CLI per inferenza diretta (no server)
./mistral-7b-instruct-v0.2.Q4_0.llamafile \
    --cli \
    -p "Spiega il meccanismo di attenzione nei Transformer in 3 frasi."

# Con GPU acceleration (NVIDIA CUDA)
./mistral-7b-instruct-v0.2.Q4_0.llamafile \
    --server \
    --nobrowser \
    -ngl 999 \
    --port 8080

# Windows: rinomina il file aggiungendo .exe
# move mistral-7b-instruct-v0.2.Q4_0.llamafile mistral-7b-instruct-v0.2.Q4_0.exe
# .\mistral-7b-instruct-v0.2.Q4_0.exe --server --nobrowser --port 8080

La cosa straordinaria di Llamafile è il deployment su edge: puoi copiare un file su una USB, trasferirlo su qualsiasi macchina, e il modello gira. Nessun Python, nessun CUDA toolkit, nessun driver aggiuntivo (il runtime CPU è incluso nel binario). Su hardware con GPU NVIDIA il flag -ngl 999 offloada tutti i layer sulla GPU, riducendo drasticamente RAM e aumentando la velocità.

Il limite di Llamafile è il throughput: basandosi su llama.cpp senza batching dinamico, le performance in concorrenza sono simili a Ollama single-stream. È ideale per deployment edge (Raspberry Pi, laptop senza connessione), per CI/CD che richiedono inferenza locale riproducibile, e per distribuire modelli a utenti finali senza chiedere loro di installare dipendenze.

Sezione 5 - Benchmark: performance multi-tool su RTX 3090

Ho eseguito benchmark standardizzati con wrk e il client Python ufficiale OpenAI su un sistema con RTX 3090 (24GB VRAM), AMD Ryzen 9 5900X, 64GB RAM, NVMe SSD. Modello: Llama 3.1 8B Instruct, quantizzazione Q4_0 dove applicabile, FP16 dove il tool lo gestisce nativamente. Il test misura throughput concorrente (richieste con 10 utenti paralleli) e latenza single-stream (time-to-first-token + token generation rate).

# Script benchmark multi-tool con wrk
# Installa wrk: https://github.com/wg/wrk

# Payload di test standardizzato
cat > /tmp/payload.json << 'EOF'
{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Spiega il gradient descent in 100 parole."}],
  "max_tokens": 150,
  "stream": false
}
EOF

# Test Ollama (porta 11434)
echo "=== OLLAMA BENCHMARK ==="
wrk -t4 -c10 -d30s \
    -s /tmp/post.lua \
    http://localhost:11434/v1/chat/completions

# Test LM Studio (porta 1234)
echo "=== LM STUDIO BENCHMARK ==="
wrk -t4 -c10 -d30s \
    -s /tmp/post.lua \
    http://localhost:1234/v1/chat/completions

# Test text-generation-webui ExLlamaV2 (porta 5000)
echo "=== TEXTGEN WEBUI BENCHMARK ==="
wrk -t4 -c10 -d30s \
    -s /tmp/post.lua \
    http://localhost:5000/v1/chat/completions

# Risultati tipici su RTX 3090 (tok/s output, Llama 3.1 8B Q4):
# vLLM:                 ~420 tok/s (10 concurrent)
# SGLang runtime:       ~390 tok/s (10 concurrent)
# text-gen-webui ExLl:  ~85 tok/s  (single stream) / ~30 tok/s (10 concurrent)
# Ollama:               ~41 tok/s  (single stream) / ~8 tok/s  (10 concurrent)
# LM Studio:            ~38 tok/s  (single stream) / ~7 tok/s  (10 concurrent)
# Llamafile CPU-only:   ~6 tok/s   (single stream)

I numeri parlano chiaramente: vLLM e SGLang sono in una categoria separata per throughput concorrente. Ma la latenza time-to-first-token (TTFT) racconta una storia diversa. Con richiesta singola, Ollama e LM Studio hanno TTFT di 80-120ms perché il modello è già caricato in VRAM. vLLM ha overhead maggiore per il batching engine: TTFT sale a 150-200ms con batch size 1. Per uso interattivo con un solo utente, la differenza soggettiva è trascurabile. Per 10+ utenti concorrenti, vLLM e SGLang vincono senza contest.

Sezione 6 - Client OpenAI unificato: switch backend trasparente

Il vantaggio di tutti i tool in questa lista è che espongono un'API OpenAI-compatible. Questo significa che puoi costruire il tuo codice applicativo contro l'interfaccia standard, e switchare il backend modificando solo la base URL e il nome del modello. Nessun refactoring del client.

"""
Client unificato per LLM serving: switch backend con variabile d'ambiente.
Funziona con Ollama, LM Studio, SGLang, text-generation-webui, vLLM.
"""
import os
from openai import OpenAI

# Configurazione backend via env vars (nessun hardcoded)
BACKEND_CONFIGS = {
    "ollama": {
        "base_url": "http://localhost:11434/v1",
        "api_key": "ollama",  # valore fisso richiesto dal client OpenAI
        "model": "llama3.1:8b"
    },
    "lm_studio": {
        "base_url": "http://localhost:1234/v1",
        "api_key": "lm-studio",
        "model": "lmstudio-community/Meta-Llama-3.1-8B-Instruct-GGUF"
    },
    "sglang": {
        "base_url": "http://localhost:30000/v1",
        "api_key": "sglang",
        "model": "meta-llama/Meta-Llama-3.1-8B-Instruct"
    },
    "textgen": {
        "base_url": "http://localhost:5000/v1",
        "api_key": os.environ.get("TEXTGEN_API_KEY", ""),
        "model": "TheBloke/Llama-2-13B-chat-GGUF"
    },
    "llamafile": {
        "base_url": "http://localhost:8080/v1",
        "api_key": "llamafile",
        "model": "mistral-7b-instruct"
    }
}

def crea_client(backend: str = None) -> tuple[OpenAI, str]:
    """Crea client OpenAI configurato per il backend specificato."""
    backend = backend or os.environ.get("LLM_BACKEND", "ollama")
    if backend not in BACKEND_CONFIGS:
        raise ValueError(f"Backend '{backend}' non supportato. Opzioni: {list(BACKEND_CONFIGS.keys())}")
    config = BACKEND_CONFIGS[backend]
    client = OpenAI(
        base_url=config["base_url"],
        api_key=config["api_key"]
    )
    return client, config["model"]

def chiedi_llm(domanda: str, backend: str = None) -> str:
    """Invia una domanda al backend configurato e restituisce la risposta."""
    client, model = crea_client(backend)
    risposta = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "Rispondi sempre in italiano, in modo tecnico e conciso."},
            {"role": "user", "content": domanda}
        ],
        max_tokens=500,
        temperature=0.7
    )
    return risposta.choices[0].message.content

# Uso: LLM_BACKEND=lm_studio python client.py
# Oppure: LLM_BACKEND=sglang python client.py
if __name__ == "__main__":
    testo = chiedi_llm("Quali sono i vantaggi del prefix caching in LLM serving?")
    print(testo)

Questo pattern è esattamente quello che uso nel portfolio: il servizio FastAPI ha un singolo LLMClient che legge LLM_BACKEND dall'ambiente. Sul VPS di produzione punta a Ollama. In sviluppo locale posso switchare a LM Studio senza toccare una riga di codice applicativo. Se domani voglio testare SGLang, cambio una variabile d'ambiente.

Sezione 7 - Feature matrix e decision matrix

Prima di presentare la decision matrix pratica, ecco il confronto completo delle funzionalità:

La feature matrix mostra le capacita tecniche, ma la scelta reale dipende dal contesto operativo. Ecco quando usare ciascun tool:

FAQ

LM Studio può girare su server Linux senza GUI?

Si. Dal 2024 LM Studio include llmster, il daemon headless che gira senza dipendenze X11. Si installa con uno script one-line e si controlla via CLI lms. Supporta auto-load model e API OpenAI-compatible su porta configurabile. Il daemon sopravvive ai logout e puo essere configurato come systemd service con lo script fornito nella documentazione ufficiale.

SGLang è solo per structured output o funziona anche come inference server?

SGLang ha due anime: il frontend DSL per programmare workflow LLM in Python, e il runtime server ad alte prestazioni. Il runtime puo servire modelli Hugging Face con throughput paragonabile a vLLM, con in piu il RadixAttention per prefix caching automatico. Puoi usare il runtime SGLang come semplice drop-in replacement di vLLM, senza toccare il DSL.

text-generation-webui supporta tutti i formati di quantizzazione?

Si, e il tool piu flessibile su questo fronte: supporta GPTQ, GGUF (via llama.cpp), ExLlamaV2, GGML, AWQ, bitsandbytes. Ogni backend ha caratteristiche di velocita diverse: ExLlamaV2 e il piu veloce per modelli GPTQ, llama.cpp e il piu compatibile per CPU-offload. Puoi switchare backend dal menu senza ricaricare il modello.

Llamafile funziona su Windows senza WSL?

Si. Il formato APE prodotto da Cosmopolitan Libc e un binario valido PE (Windows), ELF (Linux/BSD) e Mach-O (macOS) nello stesso file. Su Windows basta rinominare il file aggiungendo .exe. Nessun runtime, nessuna dipendenza, nessun WSL. Funziona anche su FreeBSD, OpenBSD e NetBSD per un totale di sei sistemi operativi.

Perché Federico usa Ollama nel portfolio ma LM Studio per le demo?

Ollama gira come systemd service sul VPS Hetzner con zero overhead di gestione e 0 euro al mese di costo aggiuntivo. LM Studio viene usato per demo veloci con clienti perche offre GUI immediata, selezione model con click e API avviata in 30 secondi senza aprire un terminale. Sono contesti radicalmente diversi: produzione continua vs dimostrazione puntuale. Usare il tool sbagliato nel contesto sbagliato e un errore comune.

Qual e la differenza di throughput tra questi tool?

Su Llama 3.1 8B con RTX 3090 (24GB): vLLM circa 420 tok/s concorrente, SGLang runtime circa 390 tok/s, Ollama circa 41 tok/s single-stream, LM Studio circa 38 tok/s, text-generation-webui ExLlamaV2 circa 85 tok/s single-stream, Llamafile circa 6 tok/s CPU-only. Ollama e LM Studio eccellono in latenza single-user (TTFT), non in throughput concorrente. Per applicazioni con un solo utente, la differenza e praticamente impercettibile.

SGLang RadixAttention come funziona in pratica?

RadixAttention crea un albero (radix tree) delle prefix comuni tra richieste diverse. Se 10 request condividono lo stesso system prompt, la KV cache di quel prefix viene riusata automaticamente. Il risultato e un hit rate di cache del 60-80% su workload multi-turn tipici, riducendo computazione e latenza. In un'applicazione RAG dove ogni query condivide il contesto dei documenti recuperati, il beneficio e particolarmente significativo.

Conclusione

Il panorama LLM serving nel 2026 non ha un vincitore assoluto. Ha vincitori per contesto. LM Studio e la scelta giusta quando il tempo di setup e il fattore critico e l'utente potrebbe non avere competenze DevOps. SGLang e la scelta giusta quando costruisci pipeline NLP complesse e vuoi esprimere la logica in codice Python idiomatico con garanzie di output strutturato. text-generation-webui e la scelta giusta quando stai esplorando quantizzazioni e vuoi la massima flessibilita nel formato del modello. Llamafile e la scelta giusta quando il deployment e su edge o devi distribuire un modello a utenti finali senza istruzioni di installazione.

La cosa piu importante che ho imparato configurando questi tool per il mio portfolio e per clienti: la scelta del serving layer e reversibile. Tutti espongono un'API OpenAI-compatible. Il codice applicativo non cambia. Quindi non perdere tempo nella paralisi della scelta: inizia con il tool piu semplice per il tuo caso attuale (probabilmente Ollama o LM Studio), misura dove sono i colli di bottiglia, e migra se e quando ne hai bisogno.

Prossimo episodio: Siamo pronti per personalizzare davvero il modello. EP08 entra nel dettaglio di LoRA e QLoRA su infrastruttura self-hosted: come preparare il dataset, configurare i hyperparameter, eseguire il training su GPU consumer in 4-6 ore, e integrare l'adapter risultante con Ollama per il serving. Leggi EP08: Fine-tuning su self-hosted infra per il workflow end-to-end.