Migrare dalle API OpenAI a un LLM locale: guida tecnica, costi e rischi

Cosa significa migrare da API OpenAI a un LLM locale, e quanto codice va riscritto?

Significa far rispondere un modello open-weight, installato su un server dell'azienda, alle stesse chiamate che oggi l'applicazione invia a OpenAI. Se il codice usa chat/completions o embeddings, le modifiche sono spesso minime. Con Ollama l'indirizzo locale è http://localhost:11434/v1/. Il client chiede comunque una chiave API, che Ollama ignora (documentazione Ollama):

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1/", api_key="ollama")
risposta = client.chat.completions.create(
    model="nome-modello-locale",
    messages=[{"role": "user", "content": "Riassumi questa procedura"}],
)

Ollama supporta /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models e gli endpoint audio. Dalla versione 0.13.3 supporta anche /v1/responses, ma senza stato lato server (Ollama). Il comando ollama cp crea un alias con il nome di un modello OpenAI: durante i test l'applicazione può continuare a chiedere "gpt-4o" e ricevere la risposta dal modello locale. vLLM copre completions, chat/completions (con chat template), Responses, embeddings e audio. La sua documentazione è segnata come "developer preview".

La compatibilità riguarda il formato delle chiamate, non la qualità delle risposte. Cambiare l'indirizzo richiede poco tempo. Per capire se il nuovo modello risponde bene servono invece prove strutturate. Nella pagina sulla migrazione dalle API spiego come imposto questa valutazione.

Quali funzioni delle API OpenAI non si ritrovano in Ollama e vLLM?

Mancano alcuni parametri e lo stato lato server. Alcune impostazioni vanno inoltre spostate nella configurazione del server. La tabella riassume le differenze indicate nelle documentazioni di Ollama e vLLM:

Due dettagli pesano più di quanto sembri. Con Ollama la cronologia della conversazione deve gestirla l'applicazione, perché su Responses mancano previous_response_id e conversation. vLLM applica di default il file generation_config.json del modello: anche a parità di prompt, le risposte possono differire da quelle di OpenAI.

Anche chi resta in cloud deve aspettarsi modifiche. Con la versione API 2026-10-21, Anthropic ha rimosso temperature, top_p e top_k, che ora restituiscono un errore 400 (Anthropic, deprecazioni).

Perché i ritiri dei modelli OpenAI rendono la decisione urgente?

Perché chi usa gpt-4o o gpt-4.1 deve migrare comunque entro il 14 gennaio 2027. Il calendario è nella pagina delle deprecazioni di OpenAI:

Il 30 novembre 2026 spariscono anche i prompt riutilizzabili (v1/prompts), Evals e Agent Builder. Dal 6 gennaio 2027 i clienti esistenti non potranno più avviare nuovi job di fine-tuning (OpenAI). Altri fornitori si comportano allo stesso modo: Anthropic promette "at least 60 days' notice" e ritira claude-sonnet-4-5 il 30 novembre 2026 (Anthropic). Con un modello open-weight in azienda, invece, è l'azienda a decidere quando cambiarlo. Ho analizzato i costi dei cambi forzati nell'articolo sul vendor lock-in nell'AI.

Quanto costano oggi le API OpenAI rispetto a un LLM locale?

I modelli piccoli di OpenAI costano poco, e con volumi bassi il locale raramente conviene. Il conto cambia con i contesti lunghi, con i livelli prioritari e con volumi alti e costanti. La tabella riporta i prezzi Standard per contesti fino a 272K token, consultati il 28/10/2026 sulla pagina prezzi di OpenAI:

Sulla stessa pagina si trovano altre condizioni:

• oltre 272K token di contesto i prezzi circa raddoppiano: gpt-6-sol passa a 4 $ in input e 15 $ in output;
• Fast, il nuovo nome di Priority, costa il doppio dello Standard;
• gli endpoint regionali aggiungono il 10% per i modelli idonei usciti dal 5 marzo 2026;
• Batch e Flex costano la metà dello Standard.

OpenAI indica il prezzo promozionale di gpt-5.6-sol come valido almeno fino al 21 novembre 2026: dopo quella data va ricontrollato. Anche Google raddoppia i prezzi: Gemini 4 Argon dal 1° dicembre 2026, i modelli Flash dal 1° gennaio 2027 (Google). Ne parlo nell'articolo sui prezzi delle API di Gemini.

I listini cambiano, quindi ogni confronto va rifatto con i prezzi del giorno e i propri volumi reali. Il metodo completo è nella pagina sui costi dell'AI in locale.

Quali dati restano da OpenAI, per quanto tempo, e cosa cambia con un LLM locale?

Per impostazione predefinita le API non usano i dati per l'addestramento: "data sent to the OpenAI API is not used to train or improve OpenAI models", salvo adesione esplicita. Alcuni dati però vengono conservati (OpenAI):

Anche con la Zero Data Retention, il materiale sospetto di abuso su minori viene conservato per una revisione umana. Con la Safety Retention, i contenuti segnalati possono essere conservati e rivisti. L'endpoint UE eu.api.openai.com richiede l'approvazione MAM o ZDR e l'emendamento Modified Retention. Restano comunque esclusi i dati di sistema, come account, metadati e fatturazione (OpenAI).

Due episodi recenti, riportati da fonti secondarie, mostrano dove nasce il problema. Secondo WMAR-2 News, al Johns Hopkins Bayview sono stati coinvolti circa 3.182 pazienti. Un dipendente aveva caricato un foglio di calcolo su uno strumento AI pubblico non approvato. Secondo Tech Times UK, il servizio 302.ai, gestito da una società di Hong Kong, ha lasciato oltre 144.000 log di chat su uno storage Azure pubblico, chiuso l'8 settembre 2026. In nessuno dei due casi la causa indicata è il modello in sé.

Un LLM locale elimina il passaggio dei dati verso un fornitore esterno, ma non è sicuro in automatico. Secondo la documentazione di vLLM, --api-key protegge solo /v1, /v2 e /inference, mentre endpoint come /invocations restano senza autenticazione. Servono una rete isolata, un'autenticazione davanti al server e i log degli accessi. Per l'analisi dei rischi è utile il documento sugli LLM pubblicato nel programma di esperti dell'EDPB (aprile 2025). Non è una posizione ufficiale del comitato. Gli obblighi che restano in ogni caso sono nella pagina su AI e GDPR.

Quali modelli open-weight possono sostituire GPT, e come si verifica la qualità?

Esistono candidati per diverse taglie di hardware, ma la qualità va misurata sui propri casi d'uso. Ecco alcuni modelli arrivati di recente su Ollama, secondo le note di rilascio:

Per Flint, Recursive dichiara il 54,9% su Terminal-Bench 2.1 e il 74,2% su SWE-bench Verified (Ollama). Sono numeri del produttore: aiutano a scegliere cosa provare, ma non bastano per decidere. Mistral Large 4 è in anteprima, con la dicitura "Open weights are coming soon" e senza licenza indicata (Mistral). Meglio non pianificare una migrazione su pesi che non si possono ancora scaricare, e verificare la licenza di ogni modello.

Per la verifica servono quattro elementi:

• un set di prova ricavato dai casi reali, con i dati anonimizzati;
• gli stessi prompt inviati al modello attuale e ai candidati locali;
• criteri scritti prima del test: correttezza, formato, tempi di risposta;
• una revisione umana sui casi in cui un errore costa davvero.

Quando conviene restare sulle API OpenAI invece di migrare?

Il cloud resta spesso la scelta più sensata in tre casi: volumi bassi o irregolari, bisogno di capacità di frontiera, mancanza delle competenze per gestire un server. gpt-6-luna costa 0,10 $ in input e 0,50 $ in output per milione di token, e il Batch costa la metà (OpenAI, consultata il 28/10/2026). Con questi prezzi, sui piccoli volumi un server proprio difficilmente conviene. Le competenze sono un limite reale. Secondo l'ISTAT, consideriamo le imprese con almeno 10 addetti che hanno valutato l'AI senza adottarla: il 58,6% indica competenze insufficienti, il 43,2% privacy e protezione dei dati, il 43,0% costi elevati.

Spesso la strada più ragionevole è intermedia: i flussi sensibili restano sul server interno, quelli generici vanno in cloud, con la stessa interfaccia compatibile. Ne parlo nell'articolo su come integrare un'AI privata con ERP e CRM. In entrambi i casi serve una governance. Il D.Lgs. 179/2026, in vigore dal 23 ottobre 2026, designa AgID e ACN come autorità nazionali per l'AI.

Da dove partire con la migrazione dalle API OpenAI?

Quando affianco un'azienda in questa valutazione parto dall'inventario:

1. Inventario. Per ogni applicazione si elencano modelli, endpoint e parametri usati, con le date della pagina delle deprecazioni.
2. Classificazione. I flussi si ordinano per sensibilità dei dati e volume di token. Quelli sensibili e voluminosi sono i primi candidati al locale.
3. Pilota su un solo flusso. Si usa Ollama o vLLM, con un alias per non toccare il nome del modello nel codice (Ollama). Davanti al server serve un'autenticazione propria, perché --api-key non basta (vLLM).
4. Confronto. Qualità e costo si misurano sul set di prova. Se i risultati non reggono, serve un piano pronto per tornare in cloud.
5. Regole d'uso. Accessi, registri, policy e formazione riducono il rischio di casi come il foglio caricato su uno strumento non approvato.

Vuoi capire quali flussi conviene spostare e quali lasciare in cloud? Puoi partire dalla valutazione: guardiamo insieme volumi, dati e scadenze, senza vendere hardware né licenze.