Cos'è Ollama?

Ollama è un runtime open source che scarica, gestisce ed esegue modelli linguistici direttamente su un computer locale, senza passare da un servizio cloud. Ha condiviso per anni le fondamenta con llama.cpp e ne ha ereditato il formato dei pesi, GGUF, ma sta spostando l'inferenza su un motore proprio scritto in Go sopra la libreria tensoriale ggml, nato per dare ai modelli multimodali lo stesso trattamento di quelli testuali: i modelli più recenti girano lì, molti modelli testuali passano ancora dal runner llama.cpp. Sopra aggiunge lo strato che rende l'esperienza vicina a un normale programma: una riga di comando per scaricare un modello, una ricetta di build chiamata Modelfile con cui si fissano prompt di sistema, template e parametri, e un'API REST su localhost con uno schema proprio e un endpoint compatibile con quello OpenAI, così un'app scritta per quell'interfaccia funziona cambiando solo l'endpoint. Carica i pesi in memoria, li tiene pronti fra una richiesta e l'altra e li scarica quando non servono.

Leggi anche: LLM locale · Un LLM locale è un modello linguistico con pesi aperti che gira su hardware tuo con un runtime come Ollama, così prompt e risposte non escono dalla tua rete.

Dove si colloca e quando sceglierlo

Ollama nasce per la singola macchina e per un carico che non deve scalare: uno sviluppatore che vuole provare un modello senza mandare dati a un provider esterno, un prototipo che deve dimostrare una funzionalità prima di decidere l'infrastruttura definitiva, un'integrazione veloce di un endpoint locale dentro un'applicazione già esistente grazie alla compatibilità con lo schema OpenAI. In questi scenari il vantaggio è l'immediatezza: nessun cluster da configurare, nessuna GPU dedicata da allestire, un comando per avere un modello che risponde. È lo stesso terreno di un LLM eseguito in locale in generale, di cui Ollama è oggi lo strumento più diffuso per l'avvio rapido.

Quando non sceglierlo

Il limite arriva con la concorrenza, e non è l'assenza di parallelismo: Ollama accetta richieste simultanee, il numero massimo è una variabile d'ambiente e l'eccesso finisce in coda. È che quel parallelismo costa memoria in modo lineare, perché ogni slot si porta dietro il proprio contesto, invece di condividere la memoria fra le richieste come fa un motore di inferenza. Passare dal prototipo locale a un servizio che deve rispondere a decine o centinaia di richieste in parallelo non è quindi un aggiornamento di configurazione, è un cambio di componente. Il confronto diretto tra Ollama e i motori di inferenza enterprise, con i numeri di throughput e latenza sotto carico, è trattato nella voce su vLLM, SGLang e llama.cpp.

Un esempio enterprise

Un team di sviluppo di una PMI vuole valutare se un modello linguistico più piccolo, eseguito in locale, riesce a classificare i ticket di supporto in ingresso prima di deciderne l'adozione su scala. Uno sviluppatore installa Ollama sul proprio portatile, scarica un modello compatto e lo interroga tramite l'API REST locale da uno script di prova, senza inviare i testi dei ticket a un servizio esterno e senza coinvolgere l'infrastruttura IT per un test che deve durare pochi giorni. Se il risultato convince, il passo successivo è tecnico e organizzativo insieme: portare il modello su un motore di inferenza pensato per il traffico reale, non semplicemente aumentare le risorse della stessa macchina.

Perché conta per chi decide

Il punto che la maggior parte delle guide introduttive non dice è che Ollama parte con un default prudente, l'ascolto sul solo localhost, ma la sua API locale non prevede autenticazione di default. Basta la modifica che chiunque fa al primo test da un'altra macchina, cambiare l'indirizzo di ascolto in 0.0.0.0, oppure l'esecuzione in un container, perché quell'istanza diventi un servizio di inferenza aperto a chiunque raggiunga quella porta: non c'è una password da aggiungere, solo un firewall o un reverse proxy da mettere davanti. È una delle ragioni per cui endpoint Ollama compaiono nei censimenti di shadow AI: strumenti installati per comodità individuale che finiscono per esporre un canale non censito verso dati aziendali o verso un modello non governato. Chi decide non deve vietare lo strumento, che resta legittimo per prototipazione e sviluppo, ma deve sapere che un'istanza locale visibile in rete è un rischio concreto e non un'ipotesi teorica, e che il salto a un uso in produzione con più utenti va pianificato come cambio di piattaforma, non come una crescita naturale dello stesso setup.