Ollama o LM Studio: conta più la configurazione

Per eseguire e servire modelli linguistici in locale, scegli Ollama se preferisci amministrare il servizio tramite comandi e API; scegli LM Studio se vuoi gestirlo anche da un’interfaccia grafica. Il benchmark sui server locali indica che la configurazione può incidere sulla velocità più del nome del programma. Per una scelta quotidiana pesano quindi anche accesso al server, automazione e gestione dei modelli.

Le specifiche API di Ollama indicano un server locale e indirizzi compatibili con client OpenAI e Anthropic, senza chiave per le richieste locali. La documentazione del server LM Studio descrive l’avvio dalla scheda Developer o dalla CLI, oltre a endpoint compatibili con OpenAI e Anthropic. LM Studio può dunque servire anche flussi automatizzati: la GUI è un’opzione di gestione, non un vincolo per ogni chiamata.

Che cosa misura il benchmark

Nel benchmark di Mozilla.ai, una diversa toolchain degli shader Vulkan ha aumentato del 63,3% l’elaborazione del prompt con Qwen3.5 9B sullo stesso Steam Deck OLED. I ricercatori hanno ricompilato llama.cpp e llamafile: quel guadagno non è una misura diretta del divario fra Ollama e LM Studio. Il risultato rende però concreta la ragione per cui una graduatoria ricavata da una singola macchina non vale automaticamente per le altre.

Nel confronto principale i programmi servivano gli stessi file GGUF, mentre il test attraversava un Mac Studio, un sistema Linux con GPU NVIDIA e Steam Deck. Contesto e uso della GPU erano impostati in modo comparabile; ciascun programma conservava le proprie impostazioni predefinite per il batching. Poiché i percorsi GGUF condividono il nucleo llama.cpp, molte differenze nell’elaborazione del prompt erano contenute, mentre build, costi del runtime e impostazioni potevano spostare i risultati. Su Steam Deck, inoltre, il runtime distribuito con LM Studio arrivava già compilato: l’utente non poteva applicargli direttamente la modifica della toolchain provata sulle altre build.

Il test separa l’elaborazione del prompt dalla generazione dei token di risposta. La prima misura quanto rapidamente il server assorbe l’input e diventa rilevante con documenti o conversazioni lunghe; la seconda incide sulla velocità con cui appare una risposta durante la chat. I valori riportati riguardano il throughput con il server già avviato. Non comprendono caricamento del modello, memoria, consumi o richieste concorrenti, che possono cambiare l’esperienza di un’app usata ogni giorno.

Interfaccia, automazione e compatibilità API

LM Studio offre un percorso immediato per chi alterna l’uso interattivo dei modelli e quello tramite API: il server si avvia nell’app, ma può partire anche con il comando lms. Dispone inoltre di API REST e librerie client. Ollama si inserisce bene in un flusso in cui script e applicazioni chiamano un servizio locale; la configurazione del servizio passa anche dalle variabili d’ambiente. La distinzione utile riguarda il modo in cui preferisci amministrare il lavoro, non la possibilità esclusiva di automatizzarlo.

La compatibilità con OpenAI e Anthropic permette in entrambi i casi di indirizzare client esistenti verso un server locale. Occorre comunque impostare l’indirizzo corretto e scegliere un modello disponibile nel programma. Una forma di richiesta compatibile non rende identici il catalogo dei modelli, tutte le funzioni degli endpoint o le risposte: se un’integrazione dipende da una funzione specifica, è quella funzione a determinare se il cambio di server è semplice.

Anche la gestione dei pesi conta. Nel benchmark, fissare lo stesso file GGUF rendeva più leggibile l’effetto del runtime; in un uso normale, due installazioni possono invece caricare formati o quantizzazioni differenti. Su Apple Silicon il confronto con gli artefatti MLX è ancora meno isolato: i pesi usati dai programmi differivano e Ollama attivava automaticamente la decodifica speculativa, mentre LM Studio non la attivava in quel percorso. Attribuire l’intero scarto dei token al secondo al solo server darebbe un’indicazione fuorviante.

Accesso locale, rete e modelli in memoria

Le impostazioni del server LM Studio comprendono la richiesta di un token API, l’accesso dagli altri dispositivi della rete locale, il caricamento dei modelli al momento della richiesta e lo scaricamento di quelli inutilizzati. Sono controlli distinti: aprire il server alla rete cambia chi può raggiungerlo, mentre il caricamento su richiesta cambia quanta memoria resta occupata. Se più dispositivi devono usare lo stesso server, l’opzione di autenticazione integrata è una differenza concreta.

Le FAQ di Ollama indicano che il servizio ascolta per impostazione predefinita sull’indirizzo locale, che OLLAMA_HOST può modificarne l’indirizzo di ascolto e che keep_alive controlla la permanenza di un modello in memoria. Questo consente di mantenere pronto un modello richiamato spesso oppure di liberare risorse dopo una richiesta. Esporre il servizio oltre il computer richiede una scelta esplicita sull’indirizzo e su come proteggere l’accesso; l’assenza di una chiave nelle richieste locali non equivale a un controllo degli utenti della rete.

Caricare i modelli quando servono può essere utile su una macchina con memoria limitata o quando si alternano modelli diversi. Ha però un costo sulla prima richiesta dopo lo scaricamento: un test che misura soltanto il ritmo di generazione, con il modello già pronto, non mostra quell’attesa. Tenere il modello in memoria favorisce invece richieste ripetute, ma lascia occupate risorse che potrebbero servire ad altro. Questa differenza può essere più percepibile di un piccolo scarto nel throughput.

Quando la velocità cambia la scelta

Per una chat personale, la continuità con cui arrivano i token di risposta può avere più peso della velocità su un prompt molto lungo. Per un’app che invia documenti estesi, l’elaborazione dell’input può diventare la parte dominante. Se più client condividono la stessa macchina, entrano in gioco anche memoria disponibile e richieste in coda: sono esigenze d’uso che il benchmark sul throughput non ha misurato. Il dato pertinente dipende quindi dal carico previsto, oltre che dall’hardware.

Ollama resta una scelta lineare per chi vuole costruire attorno a un servizio locale configurato tramite comandi e chiamato da script. LM Studio è adatto a chi desidera controllare i modelli dalla GUI senza rinunciare a CLI e API, e offre controlli integrati per token e caricamento su richiesta. Quando le prestazioni sono decisive, il confronto sensato usa lo stesso modello, la stessa quantizzazione e un carico rappresentativo sulla macchina destinata a eseguirlo: il risultato ottenuto altrove descrive quella combinazione, non una proprietà permanente dei due programmi.