API LLM gratuite: il vero confronto (e l'opzione locale)

#Perché questo confronto

Quando si crea un prototipo, il primo istinto è cercare un’API LLM gratuita: si vuole provare un’idea senza tirare fuori la carta di credito, collegare un modello a uno script e vedere se funziona. La buona notizia è che le offerte gratuite esistono e a volte sono generose. Quella meno buona è che «gratuito» può significare cose molto diverse: un piano gratuito permanente, un credito di prova con scadenza oppure un accesso fornito dalla community con velocità limitata.

L'obiettivo di questa guida non è dirti «il locale è meglio». È darti i numeri per decidere da solo: cosa permette realmente ogni offerta gratuita, cosa prende in cambio e a partire da quale volume o da quale vincolo di riservatezza un endpoint locale diventa la scelta razionale. Spesso, la risposta migliore non è scegliere solo l'una o solo l'altra opzione, ma usarle entrambe, con un instradamento in base al compito.

#Panoramica delle API LLM gratuite

Si possono classificare le offerte gratuite in quattro famiglie. Capire a quale famiglia appartiene un'offerta evita brutte sorprese quando il contatore raggiunge zero nel bel mezzo di uno sprint.

Piano gratuito permanente

Un accesso gratuito che non scade, ma con un numero massimo di richieste al minuto e al giorno. È il caso di Google AI Studio (API Gemini) o di Groq, che offrono modelli aperti (Llama, Qwen, gpt-oss) con un volume di richieste gratuito ma limitato.

Aggregatori e modelli :free

OpenRouter offre decine di modelli, alcuni dei quali con suffisso «:free». L'accesso è reale, ma la velocità di elaborazione dipende da una riserva di risorse condivisa e può calare nelle ore di punta.

Credito di prova

Un importo offerto (spesso qualche dollaro) alla creazione dell'account, che scade dopo qualche settimana. Utile per un test occasionale, inutile per un progetto che dura nel tempo.

Inferenza della community

Hugging Face Inference e servizi simili: accesso gratuito a molti modelli, ma avvio a freddo (cold start), code di attesa e velocità di elaborazione non garantita.

#Le quote reali, senza filtri

La parola «gratuito» nasconde tre limiti distinti che, insieme, determinano se l'offerta è adeguata al tuo utilizzo. Un piano può essere generoso rispetto a uno di questi limiti e molto restrittivo rispetto agli altri due.

Richieste al minuto (RPM)

Il numero di chiamate consentite al minuto. I piani gratuiti si attestano spesso intorno a qualche decina di RPM: ampiamente sufficienti per uno sviluppatore che esegue dei test, ma troppo poche per servire più utenti in parallelo.

Token al giorno (TPD)

Il vero limite determinante. Una quota giornaliera di token si esaurisce molto rapidamente quando si inviano prompt voluminosi, contesto RAG o si elaborano ripetutamente i dati di un dataset.

Velocità di generazione e latenza

Con le offerte gratuite condivise, la velocità di generazione non è mai garantita. Nelle ore di minor traffico la generazione è fluida; nei momenti di picco la latenza esplode o le richieste vengono rifiutate (errore 429).

In pratica: per la prototipazione manuale, con qualche richiesta di tanto in tanto, le quote gratuite sono ampiamente sufficienti. Appena automatizzi un'elaborazione in batch con uno script — classificare mille ticket, riassumere una casella di posta, generare test su un repository — raggiungi il limite del TPD in pochi minuti, e il throughput limitato trasforma un batch di 10 minuti in un'attesa di un'ora intervallata da errori 429.

#Quello che realmente paghi

Un'API gratuita non è priva di costi: il prezzo viene semplicemente spostato dal portafoglio ad altre voci. Tre di queste pesano molto per un progetto di sviluppo.

I tuoi dati

Su molti piani gratuiti, i prompt e le risposte vengono conservati e possono essere utilizzati per addestrare o migliorare i modelli. Ciò che è accettabile per un test con dati fittizi non lo è con codice proprietario, dati dei clienti o informazioni personali (RGPD).

Dipendenza

Costruire su una quota gratuita è come costruire su un terreno che può cedere: variazioni delle condizioni, rimozione del modello, eliminazione di un livello. Il tuo codice, i tuoi prompt e le tue impostazioni sono calibrati per un fornitore; migrare richiede tempo che non avevi previsto.

L'imprevedibilità

Latenza variabile, code di attesa, interruzioni: è difficile mantenere una promessa di qualità del servizio quando la componente centrale sfugge al tuo controllo e non offre alcuna garanzia per l'offerta gratuita.

#L'opzione locale con Ollama

Accanto alle opzioni gratuite a determinate condizioni, ci sono quelle gratuite per davvero: eseguire il modello sulla tua macchina. Ollama è lo strumento più semplice per farlo. È un daemon che scarica modelli open-weight ed espone un'API HTTP locale su http://localhost:11434, con un endpoint compatibile con OpenAI: questo significa che il codice scritto per un'API cloud spesso funziona cambiando soltanto l'URL di base.

# Installer Ollama (Linux/macOS)
curl -fsSL https://ollama.com/install.sh | sh

# Tirer et lancer un modèle 7-8B quantifié Q4_K_M
ollama pull qwen2.5:7b
ollama run qwen2.5:7b

# Le daemon écoute sur http://localhost:11434

Nel codice, l'endpoint compatibile con OpenAI si integra in tre righe. Nessuna chiave API da gestire, nessuna quota di utilizzo, nessun dato che esce dalla macchina.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # endpoint local Ollama
    api_key="ollama",  # ignoré en local, mais requis par le client
)

resp = client.chat.completions.create(
    model="qwen2.5:7b",
    messages=[{"role": "user", "content": "Explique la récursion en une phrase."}],
)
print(resp.choices[0].message.content)

Il rovescio della medaglia è l'hardware. Un modello locale ha bisogno di VRAM (o di memoria unificata su Mac Apple Silicon). Con la quantizzazione Q4_K_M, i valori di riferimento per la memoria sono facili da ricordare: un 3B sta in circa 2 GB, un 7B in circa 5 GB, un 14B in circa 9 GB, un 32B in circa 19 GB e un 70B richiede circa 40 GB. Una RTX 3060 da 12 GB esegue agevolmente modelli da 7 a 14B; una RTX 4090 da 24 GB o un Mac M4 Pro con 24-48 GB di memoria unificata permettono di utilizzare modelli da 32B.

Confidenzialità totale

Nessun prompt esce dalla macchina. Codice proprietario, dati dei clienti, informazioni personali: tutto resta presso di te, il che semplifica radicalmente la conformità al GDPR.

Nessuna quota

Nessun RPM, nessun TPD. Puoi elaborare in un ciclo diecimila documenti durante la notte senza stare a contarli e senza errori 429.

Costo marginale nullo

Una volta disponibile l’hardware, ogni richiesta è gratuita. Il costo dell’elettricità di una GPU desktop resta trascurabile rispetto a una fattura per un’API a consumo.

Stabilità

Nessuna condizione che cambia, nessun modello ritirato. La versione che hai scaricato rimane identica finché non la aggiorni.

#Il punto di svolta verso l'esecuzione in locale

La domanda utile non è «gratuito o locale?» ma «a partire da quale punto l'esecuzione locale diventa la scelta migliore?». Quattro segnali indicano che hai superato la soglia.

1. 01
   Stai elaborando dati che non puoi esporre

   Non appena nel prompt sono presenti codice proprietario, dati dei clienti o informazioni personali, la clausola sull'addestramento di un'API gratuita diventa inaccettabile. La soluzione locale risolve il problema alla radice: nulla esce.
2. 02
   Raggiungi regolarmente i limiti di quota

   Se i tuoi script terminano con errori 429, se suddividi i batch per restare sotto il TPD o se ti destreggi tra diversi account gratuiti, stai già pagando in tempo ciò che l'esecuzione in locale ti farebbe risparmiare.
3. 03
   Il volume è prevedibile e sostenuto

   Un uso regolare — generazione continua di test, pipeline RAG interna, classificazione continuativa — si ripaga rapidamente con l'esecuzione in locale. L'hardware è un costo fisso ammortizzato; l'API a consumo è un costo variabile che aumenta con il successo del progetto.
4. 04
   Vuoi una latenza controllata

   Su una macchina dedicata, la latenza dipende solo da te, non dal carico di un servizio condiviso. Per uno strumento interno usato tutto il giorno, questa prevedibilità ha un valore notevole.

#Mantenerli entrambi: il routing intelligente

L'architettura più sana per un progetto di sviluppo non è esclusiva: distribuisce ogni compito all'endpoint più adatto. Il locale gestisce il grosso del volume e tutto ciò che è sensibile; il cloud viene riservato alle attività che superano veramente le capacità del dispositivo.

Verso il locale

Attività ad alto volume, dati sensibili, cicli di elaborazione, iterazioni di sviluppo, tutto ciò che deve restare riservato. Un modello locale da 7-14B copre la stragrande maggioranza delle esigenze di sviluppo comuni.

Verso il cloud

Ragionamento complesso che richiede un modello molto grande, picco di carico occasionale o funzionalità multimodale non disponibile in locale. Si invia al cloud soltanto ciò che ne giustifica l'uso, e mai dati sensibili.

Poiché Ollama espone un'API compatibile con OpenAI, questo instradamento è semplice da programmare: due client, una regola di selezione in base al compito. Per andare oltre, un proxy come LiteLLM centralizza diversi backend dietro un'unica interfaccia, con fallback automatico dal cloud al locale (o viceversa) e monitoraggio dei costi.

from openai import OpenAI

local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
cloud = OpenAI(base_url="https://api.exemple.com/v1", api_key="VOTRE_CLE")

def router(sensible: bool, gros_raisonnement: bool):
    # Données sensibles OU volume : local par défaut
    if sensible or not gros_raisonnement:
        return local, "qwen2.5:7b"
    # Sinon, cloud pour un modèle plus puissant
    return cloud, "modele-frontiere"

client, model = router(sensible=True, gros_raisonnement=False)
resp = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Résume ce ticket interne..."}],
)

#Iniziare in locale in 4 passaggi

1. 01
   Installare Ollama

   Un comando su Linux/macOS (curl -fsSL https://ollama.com/install.sh | sh) oppure il programma di installazione ufficiale su Windows. Il daemon si avvia e rimane in ascolto su http://localhost:11434.
2. 02
   Scegliere un modello adatto alle capacità del tuo hardware

   Verifica quanta VRAM hai a disposizione e scegli un modello in Q4_K_M che ci stia lasciando un margine per il contesto: 7B (~5 GB) per 8-12 GB di VRAM, 14B (~9 GB) per 12-16 GB, 32B (~19 GB) per 24 GB. Con meno VRAM, un 3B (~2 GB) resta utile per compiti semplici.
3. 03
   Scaricare il modello e provarlo

   ollama pull qwen2.5:7b puis ollama run qwen2.5:7b pour vérifier qu'il répond. Un pull ne se fait qu'une fois ; ensuite le modèle est en cache local.
4. 04
   Collegare il tuo codice

   Punta il tuo client OpenAI esistente a http://localhost:11434/v1. Il resto del codice — messaggi, streaming, function calling — funziona come con un'API cloud, senza chiave né quota.

#Per approfondire

Una volta installato Ollama, tre guide del sito ti accompagnano naturalmente nei passi successivi a questa transizione. La guida all’integrazione dell’API REST di Ollama in Python descrive in dettaglio streaming, modalità JSON e function calling sull’endpoint locale. Il confronto dei costi di un server GPU quantifica la soglia di convenienza tra l’acquisto di hardware e le API cloud. E per gestire il routing tra locale e cloud su scala operativa, la guida LiteLLM mostra come unificare i due dietro un proxy con fallback e monitoraggio dei costi.