Gestione dei costi della codifica IA su larga scala

Gli strumenti di programmazione basati su AI offrono un valore immenso: in Databricks, la programmazione agentica ha migliorato in modo misurabile ogni metrica di velocità che monitoriamo e, in alcuni team, ha generato guadagni di produttività di un ordine di grandezza. Ma quasi tutte le aziende che distribuiscono strumenti di AI su scala hanno urtato contro lo stesso muro: costi in crescita esponenziale. Questa curva è insostenibile: se non controllata, finirà per superare i ricavi. L'esplosione della spesa ha lasciato le imprese in una situazione paradossale: da un lato, il desiderio di spingere al massimo la trasformazione dell'AI e mettere strumenti potenti nelle mani dei dipendenti, e dall'altro, la necessità di fare i conti con un profilo di costo aggregato che rischia di vanificare o addirittura invertire gli stessi guadagni di efficienza offerti dall'AI.

Fortunatamente, molti dei primi utilizzatori su larga scala hanno concordato su una serie di approcci che risolvono questo enigma, raggiungendo un "duplice mandato": (a) fornire un ampio accesso agli strumenti di AI, con il minimo attrito, e (b) mantenere i costi aggregati entro un budget approssimativamente fisso per utente. Questo post illustra tecniche collaudate di gestione dei costi, basate sulla nostra esperienza in Databricks e su conversazioni con diverse altre aziende natie digitali, tra cui Stripe, Coinbase, Uber e Ramp. La tabella seguente riassume le tecniche attuali e i risparmi associati; i numeri sono indicativi, basati su un'indagine informale tra i team di sviluppo:

Alcune di queste tecniche possono essere facilmente implementate con software che molte aziende già utilizzano. Altre richiedono una nuova infrastruttura, in particolare le tecniche che modificano i client degli utenti finali o spostano il traffico tra i modelli. In Databricks, abbiamo reso open source o disponibile gratuitamente i nostri componenti infrastrutturali chiave: un meta-harness per l'utente finale (Omnigent) e il nostro AI Gateway (Unity AI Gateway). Per completezza, questo post copre anche il software utilizzato da altre aziende con cui abbiamo parlato.

La "frontiera dell'efficienza" per i modelli di programmazione

La singola leva di costo più importante consiste nello spostare la spesa per la programmazione verso modelli più efficienti man mano che vengono rilasciati. Questo punto merita una discussione, poiché la semplice spiegazione di "modelli più economici" nasconde in realtà una relazione sfumata tra costo e qualità del modello.

Nel linguaggio comune, il termine modello di frontiera significa "il modello a più alta intelligenza" e i frontier labs si concentrano principalmente sul progresso dell'intelligenza di picco. I modelli di frontiera possono ora risolvere problemi inediti in matematica o sicurezza informatica. Ma quando l'AI viene distribuita su scala, un tipo diverso di frontiera conta di più: la frontiera dell'efficienza. La frontiera dell'efficienza è definita dall'insieme di modelli che presentano il miglior rapporto prezzo/prestazioni per un determinato livello di intelligenza. La maggior parte della programmazione quotidiana non richiede dimostrazioni matematiche o intuizioni inedite sulla sicurezza, quindi ciò che conta complessivamente è il costo dei modelli che soddisfano lo standard di qualità per il tipico lavoro di ingegneria del software. Questa "frontiera dell'efficienza" sta avanzando molto più rapidamente della frontiera dell'intelligenza, con nuovi modelli rilasciati quasi settimanalmente che offrono una migliore intelligenza per unità di prezzo rispetto ai modelli precedenti.

Leva di costo n. 1: passaggio a modelli open source e a costo inferiore

L'adozione rapida di modelli più recenti e più efficienti offre i maggiori risparmi sui costi rispetto a qualsiasi altra tecnica. Ma per cogliere questi vantaggi, un'azienda deve prima sapere quali modelli superano effettivamente quelli già in uso. Questo può essere difficile perché i benchmark pubblici non sono molto efficaci nell'indicare le prestazioni reali nei compiti di programmazione. Per valutare i nuovi modelli, molte aziende hanno creato valutazioni automatizzate che ritengono più rappresentative del proprio mix di sviluppo interno. Databricks ha recentemente pubblicato un esempio di tale benchmark, in cui abbiamo osservato un rapporto prezzo/prestazioni altamente competitivo per i modelli GLM. Questo benchmark ci ha spinto a distribuire GLM internamente agli sviluppatori. Spesso, i nuovi modelli non fanno avanzare la frontiera dell'efficienza e le valutazioni producono frequentemente risultati negativi: Stripe ha riscontrato che Opus 4.7 non migliorava in modo significativo la qualità rispetto a Opus 4.6, a fronte di un aumento dei costi. Di conseguenza, hanno deciso di non rendere disponibile Opus 4.7 internamente. Databricks ha riscontrato regressioni di costo simili confrontando Opus 5.0 con 4.8.

Flessibilità di harness e modelli

Poiché i vantaggi maggiori derivano dal passaggio a nuovi modelli, l'adozione di strumenti per l'utente finale che consentano la flessibilità dei modelli sta diventando un componente critico per contenere i costi. Lo strumento più comunemente utilizzato in combinazione con un particolare modello è chiamato harness. I modelli di frontiera proprietari sono sempre più co-progettati per funzionare bene con harness specifici, il che significa che determinati harness "funzionano meglio" con determinati modelli. Se un'azienda desidera preservare l'indipendenza dal modello, esistono all'incirca due approcci:

Chiedere agli utenti di cambiare harness. Un approccio consiste nel fornire agli sviluppatori un set di harness (Claude Code, Codex o Cursor) e poi chiedere loro di passare da un harness all'altro quando un'azienda desidera migrare la spesa verso modelli a costo inferiore. Questo consente agli utenti di lavorare nel loro harness preferito quando possibile, ma lo svantaggio di questo approccio è che i costi di transizione per un singolo sviluppatore possono essere elevati. Se i costi di transizione diventano troppo elevati, l'harness stesso diventa di fatto un vincolo (lock-in) a una famiglia di modelli, limitando la capacità di spostare la spesa verso modelli più competitivi.

Utilizzare un meta-harness. Un approccio nuovo e sempre più diffuso consiste nell'utilizzare un meta-harness che offre un'esperienza utente comune agli sviluppatori, smistando al contempo le richieste agli harness sottostanti (sia proprietari che open source). Questo approccio consente l'indipendenza sia dal modello che dall'harness, riducendo al contempo i costi di transizione per gli sviluppatori. In Databricks, questa è la modalità predefinita per gli sviluppatori che utilizzano Omnigent. Alcune aziende con cui abbiamo parlato hanno sviluppato meta-harness interni personalizzati che si integrano con la loro toolchain di sviluppo.

Leva di costo n. 2: routing dinamico di richieste e task

Invece di chiedere agli utenti di scegliere autonomamente i modelli adatti al task, un numero crescente di ricerche suggerisce che la selezione automatica di modelli e strumenti possa ottimizzare ulteriormente l'efficienza dei flussi di lavoro di programmazione agentica. Gli approcci di routing si dividono all'incirca in tre categorie:

• Routing a livello di richiesta: un proxy stateful si interpone tra un client (come un harness di programmazione) e i modelli di base sottostanti. Il proxy tenta di instradare le richieste al modello a costo più basso in grado di rispondere a ciascuna richiesta di inferenza. Il routing per i casi d'uso agentici deve anche tenere conto del caching lato server, poiché un hit di cache a freddo comporta un costo molto elevato per carichi di lavoro con contesti di grandi dimensioni. Una nuova ondata di prodotti sta mostrando primi risultati promettenti per il routing. Alcuni esempi sono: Cursor Router, l'AutoRouter di OpenRouter, la funzionalità Router di Ramp e la funzionalità Smart Routing di Databricks in Unity AI Gateway.
• Routing a livello di task (Meta Harness): un processo lato client smista i task dell'utente a diversi harness in base alla complessità del task stesso. Un task utente potrebbe essere "rinomina questo componente da X a Y" (un task semplice) o un task aperto come "Esplora considerazioni di progettazione che ridurrebbero la latenza" (un task complesso). Il dispatcher, spesso chiamato Meta Harness, esamina quale livello di modello sottostante è richiesto per un task e poi delega l'intero task end-to-end a quel modello. Omnigent è un esempio di Meta Harness che supporta questo pattern.
• Pattern di escalation/delega: un singolo harness accoppia due modelli (un modello costoso ad alta intelligenza e un modello worker economico). In alcuni approcci, come lo strumento Advisor di Claude, il modello più economico gestisce il processo ed effettua un'escalation quando ritiene che un task richieda maggiore potenza di calcolo. Esiste anche il pattern inverso: in Devin Fusion di Cognition, il modello a costo più elevato costituisce il ciclo principale ed esternalizza selettivamente il lavoro a un modello più economico.
  I risultati interni di Databricks suggeriscono che lo Smart Router del nostro AI Gateway è in grado di ridurre costantemente il costo medio dei task di oltre il 30%, eguagliando approssimativamente la qualità del modello più costoso nel set di lavoro. Altre aziende con cui abbiamo parlato hanno riscontrato risultati simili.

Leva di costo n. 3: dare visibilità, sistemi di allerta e budget agli sviluppatori

Potrebbe sorprendere il fatto che questo intero articolo non sia iniziato e finito con "Assegna agli utenti un budget mensile e non pensarci più". I budget rigidi, in cui l'utilizzo viene completamente interrotto al raggiungimento di una specifica soglia di spesa, vengono spesso utilizzati solo come ultima risorsa in tutte le aziende con cui abbiamo parlato. Ci sono due motivi per cui i budget rigidi per i token non sono particolarmente efficaci per la gestione della spesa legata all'AI: In primo luogo, se uno sviluppatore raggiunge il limite del proprio budget, interrompere l'accesso agli strumenti di AI sarebbe deleterio per la produttività. Né l'azienda né il dipendente desiderano un simile risultato. In secondo luogo, almeno alcuni degli utenti con "spese elevate" sono in realtà coloro che hanno ottenuto enormi incrementi di efficienza grazie all'AI e stanno producendo risultati straordinari. Scoraggiare questi utenti sarebbe controproducente.

Invece di un limite rigido di spesa per l'utente, la maggior parte delle aziende sta adottando un approccio più sfumato e progressivo, incentrato sulla visibilità per gli utenti finali e su un aumento graduale dei controlli all'aumentare della spesa.

1. Visibilità: ogni azienda con cui abbiamo parlato disponeva di un meccanismo per fornire un feedback quasi istantaneo agli utenti sulla loro spesa corrente, e molte offrivano anche suggerimenti o insight specifici su come ridurre i costi utilizzando modelli meno costosi. È importante che gli utenti possano visualizzare la propria spesa su tutti gli strumenti, poiché potrebbero voler orientare la scelta verso lo strumento che garantisce il ROI più elevato.

   

   Una dashboard per sviluppatori su Databricks che mostra la spesa attiva

2. Soglie di spesa: agli sviluppatori può essere richiesto di intraprendere azioni o richiedere approvazioni a livelli di spesa crescenti. La forma più semplice di soglia di spesa è quella che può essere autorizzata autonomamente e funge da avviso del fatto che il tasso di spesa sta superando una determinata soglia. In Databricks, abbiamo riscontrato che le soglie ad autorizzazione autonoma sono un meccanismo utile per prevenire spese accidentali o involontarie. Possono essere introdotte ulteriori soglie che richiedono un'approvazione esplicita del budget (spesso attraverso la catena di gestione).
3. Passaggio a un livello inferiore (downshifting): se uno sviluppatore raggiunge una soglia di spesa, può essere reindirizzato a un modello a costo inferiore anziché essere completamente escluso dall'accesso ai token. Poiché i modelli a costo più basso sono drasticamente meno costosi rispetto ai modelli di intelligenza di frontiera, questa tecnica consente agli sviluppatori di continuare a lavorare senza incorrere in ingenti spese correnti.
4. Sospensione: nei casi limite, la maggior parte dei sistemi conserva la capacità di sospendere completamente gli utenti da qualsiasi accesso ai token. Come indicato sopra, si tratta spesso solo di una misura temporanea e del punto di partenza per un confronto su come sfruttare l'AI in modo efficiente.

Leva di costo n. 4: riduzione del sovraccarico di token

Quando un utente digita una richiesta relativamente semplice in un agente di codifica AI (come "Analizza e correggi questo bug"), tale agente raccoglie successivamente un'enorme quantità di contesto pertinente, richiama numerosi strumenti, effettua ricerche nella codebase e integra competenze o informazioni di sistema fornite dall'azienda. Nel momento in cui avviene la costosa inferenza del LLM, la richiesta iniziale dell'utente rappresenta solo una frazione trascurabile dei dati inseriti nel sistema di AI, il che significa che i costi sono dominati da un contesto che l'utente non ha incluso esplicitamente. Le tecniche per ridurre il sovraccarico del contesto sono ancora nuove, ma si stanno esplorando diversi approcci promettenti, tra cui:

• Forzare una compattazione (compressione) più frequente del contesto attivo.
• Utilizzare harness "meno prolissi" (più efficienti in termini di token) o ottimizzare gli harness esistenti per generare un minore sovraccarico di token.
• Sottoporre ad audit gli strumenti più diffusi e ridurne la verbosità.
• Incoraggiare gli sviluppatori a suddividere le attività in unità di lavoro individuali più piccole, riducendo l'ambito del contesto.

Quando i contesti diventano di grandi dimensioni, anche il caching dei prompt svolge un ruolo significativo nelle prestazioni complessive. Sia i LLM proprietari che quelli open source dispongono di impostazioni che consentono di abilitare il caching dei prompt e di regolare la durata di memorizzazione della cache. Le scritture in cache hanno un costo, ma le letture memorizzate nella cache possono ridurre drasticamente il costo per inferenza. Questo compromesso dipende dal carico di lavoro specifico di un'azienda, pertanto l'ottimizzazione manuale delle impostazioni predefinite della cache per aumentare il tasso complessivo di risposte positive (cache hit rate) può portare a drastici miglioramenti del costo complessivo.

In Databricks, un'ottimizzazione relativamente semplice del nostro harness e delle impostazioni di caching ha portato a una riduzione di quasi il 50% del numero di token generati e dei costi associati, senza alcun degrado della qualità riscontrato dagli sviluppatori. Continuiamo a esplorare tecniche in questo ambito e riteniamo che sia ancora possibile un'ulteriore e significativa ottimizzazione.

Una drastica riduzione dei token per sessione grazie all'eliminazione di chiamate di inferenza estranee e alla riduzione delle scritture in cache.

Il design pattern AI Gateway

Le tecniche sopra descritte presentavano molti requisiti tecnici impliciti: per sfruttare rapidamente i nuovi modelli, le aziende devono disporre di una posizione centrale in cui viene gestito il "menu dei modelli" e gli utenti finali devono disporre di una toolchain che supporti la combinazione di modelli diversi. Per fornire visibilità sul budget tra più strumenti di AI, deve esistere una funzionalità unificata di osservabilità dei costi. Per gestire il sovraccarico del contesto, le aziende hanno bisogno di un modo per osservare gli output tipici delle chiamate agli strumenti (toolcall) e imporre la compressione o la compattazione. Queste esigenze vengono risolte collettivamente da una nuova classe di software infrastrutturale, definibile come AI Gateway. Un AI gateway è una posizione centrale in cui avviene tutto ciò che segue:

1. Gestione della capacità e proxying dell'accesso ai modelli sottostanti (sia modelli proprietari che OSS).
2. Tracciamento e applicazione del budget, incluse policy di budget complesse come livelli di controllo progressivi e il passaggio a modelli inferiori (downshifting).
3. Gestione della configurazione per gli strumenti degli utenti finali, per applicare allow-list dei modelli, impostazioni di compattazione e altri aspetti gestiti localmente.
4. Registrazione delle tracce delle sessioni di codifica per l'analisi dell'efficienza e il benchmark a valle.

In Databricks, facciamo grande affidamento su Unity AI Gateway per tutte queste funzionalità.

In sintesi

La crescita esponenziale dei costi di codifica legati all'AI non è inevitabile, è un problema di engineering e governance risolvibile. Le aziende che sono riuscite a contenerla condividono una strategia comune: perseguire incessantemente la frontiera dell'efficienza piuttosto che quella dell'intelligenza, adottare strumenti che preservino la flessibilità dei modelli, instradare il lavoro in modo intelligente verso il modello idoneo più economico, sostituire i budget rigidi con la visibilità e controlli progressivi, e tagliare il sovraccarico di token che domina la spesa reale. Nessuna di queste tecniche richiede di sacrificare i guadagni di produttività che hanno reso conveniente l'adozione dell'AI fin dall'inizio; insieme, consentono alle organizzazioni di soddisfare il duplice mandato di un accesso ampio e con pochi ostacoli entro un limite di costo prevedibile.

Sta emergendo un insieme di nuove astrazioni infrastrutturali per fornire alle aziende gli strumenti per gestire i propri costi. In Databricks, abbiamo rilasciato i componenti chiave del nostro stack di gestione dei costi come prodotti open source o software gratuiti: il nostro Unity AI Gateway per la gestione centrale e Omnigent per gli strumenti di sviluppo. Migliaia di aziende utilizzano questi componenti ogni giorno. Invitiamo altre aziende a condividere i propri risultati e a confrontare le tecniche man mano che questo panorama tecnologico si evolve rapidamente.

Ringraziamenti: si ringraziano i responsabili delle infrastrutture di Uber, Stripe, Coinbase e Ramp che hanno fornito commenti e recensioni per questo articolo. Si ringrazia Thrive Capital per il feedback su una prima bozza di questo articolo.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale