Tenere la bolletta del triage AI più bassa possibile

Appena il triage AI funziona, la domanda successiva è la bolletta. Ogni allerta che raggiunge un modello costa denaro, e a un volume di allerte reale quel numero sale in fretta. La maggior parte di quella bolletta è opzionale.

SocTalk tiene la maggior parte delle allerte lontane da un modello fin dall'inizio, tramite deduplicazione, coalescenza, correlazione e chiusura deterministica (vedi Come funziona), così la spesa che resta si concentra sulle allerte che hanno davvero bisogno di giudizio. Questa guida riguarda lo spingere quella spesa residua più in basso possibile, senza cedere più qualità di quanta ne abbiate misurata e senza far uscire contenuto di allerta sensibile dal vostro perimetro.

Le opzioni qui sotto sono ordinate dalla più economica e sicura alla meno. La maggior parte dei deployment non arriva mai all'ultima.

Batching e cache prima di tutto

Due funzioni gestite sulle API di frontiera tagliano il costo senza cambiare la qualità del modello.

La Batch API elabora le richieste in modo asincrono in cambio di uno sconto fisso, e l'output è identico. SocTalk vi si adatta senza sforzo. La finestra di settle trattiene già un run perché le allerte correlate si accumulino, e un run è asincrono di per sé, quindi il triage non è un percorso sensibile alla latenza.

Il prompt caching fattura la parte ripetuta di un prompt a una frazione della tariffa d'ingresso. I prompt di supervisor e di verdict di SocTalk portano un grande prefisso stabile, il prompt di sistema e le definizioni degli strumenti, con il contenuto volatile per ciascun caso in coda, quindi la frazione cacheabile è reale ed è già usata sul percorso Anthropic.

Attivate entrambe e misurate il nuovo costo per run prima di considerare qualsiasi cosa qui sotto. Nessuna delle due tocca la qualità, quindi non c'è motivo di saltarle.

Mettete un modello più economico sul lavoro più economico

Un run di triage usa un modello in due ruoli: un supervisor che instrada l'investigazione, decidendo cosa arricchire dopo e quando decidere, e un verdict che pesa le prove. L'instradamento è il compito più leggero. SocTalk risolve ciascun ruolo al proprio tier, e ogni tier punta al proprio provider, modello ed endpoint, così il router può girare su un modello più piccolo mentre il verdict mantiene il modello capace. Questa è configurazione, non nuova infrastruttura.

Modelli ospitati più economici, con un'avvertenza

Diversi provider servono modelli aperti quasi-frontiera che possono stare sotto le API di frontiera, a seconda del provider, del modello e del carico. Vanno bene per i casi ordinari, a minor rischio, dove un modello aperto quasi-frontiera basta. Per il lavoro di sicurezza il vincolo è la governance dei dati più che il prezzo: inviare allerte dei clienti a un'API di terzi, soprattutto in un'altra giurisdizione, sposta quei dati fuori dal vostro controllo. Se questo è un no netto per i vostri tenant, la sezione successiva tiene i dati dentro il vostro confine.

Self-hosting del modello

Il self-hosting è il risparmio maggiore, e l'unica opzione che tiene il contenuto delle allerte nel vostro perimetro. SocTalk consuma un modello self-hosted allo stesso modo in cui consuma un'API di frontiera, puntando un tier a un endpoint compatibile OpenAI. Classifica il backend in base al suo modello di consegna, un'API gestita a caldo, una GPU serverless che scala a zero, una GPU noleggiata sempre accesa, o un'istanza locale, così costo e scheduling si comportano correttamente per ciascuno.

Dove lo fate girare è un vero compromesso.

• Una piattaforma di GPU serverless gestita (per esempio Modal) deploya il modello dietro un endpoint compatibile OpenAI, scala a zero quando è inattiva e fattura a GPU-secondo. Pagate solo mentre gira e non c'è server da gestire, a una tariffa oraria più alta di un noleggio puro.
• Un marketplace di noleggio GPU (per esempio RunPod) noleggia GPU consumer vicine a ciò che un piccolo deployment self-hosted comprerebbe, a una tariffa oraria più bassa. In cambio gestite voi il ciclo di vita. Un pod fattura finché non lo fermate, gli avvii a freddo richiedono minuti, e la disponibilità sui livelli più economici varia.
• Un'istanza locale (per esempio Ollama) gira su hardware che già possedete, senza addebito misurato per richiesta e senza che nulla lasci la macchina, limitata dal throughput di quella singola macchina.

Ciò che fa il risparmio è l'utilizzo, non la scheda

Un server self-hosted è economico solo quando il suo batch continuo è pieno. Una richiesta alla volta lascia la GPU sottoutilizzata e rende il self-hosting più caro di quanto dovrebbe. SocTalk fa girare più investigazioni in concorrenza per worker, così ci sono più richieste in volo verso il backend contemporaneamente e il batch si riempie.

Nei nostri benchmark, riempire il batch a otto richieste concorrenti ha alzato il throughput aggregato di circa sei-otto volte rispetto a una-alla-volta e ha tagliato il costo per richiesta a circa il 13-17 per cento del caso seriale, sui run testati con L40S, A10G, L4, RTX 3090 e RTX 4090. L'utilizzo ha fatto la maggior parte del lavoro. È stata la concorrenza, non la scheda, a spostare il self-hosting da inefficiente a più economico della baseline seriale in questi run.

Quanto costa, misurato

Questi numeri vengono dai nostri benchmark di un modello aperto 7B su un insieme fisso di casi di triage a otto vie di concorrenza. Sono indicativi, non una garanzia. Il vostro modello, hardware e mix di allerte li sposteranno.

Per triage completo, il self-hosting su una GPU consumer noleggiata è risultato circa due-tre ordini di grandezza più economico di una chiamata API di frontiera non ottimizzata, e diverse volte più economico dello stesso modello su una piattaforma serverless gestita, perché la scheda noleggiata testata era sia più economica all'ora sia, in questi run, più veloce. La tariffa più alta della piattaforma gestita compra lo scalare a zero e nessuna operatività. Il prezzo più alto dell'API di frontiera compra un tier di modello gestito che può andar bene per i casi più difficili, senza infrastruttura da gestire.

La latenza è rimasta pratica. L'insieme di 12 casi si è concluso in circa un minuto su una Modal A10G e in 11-14 secondi su una RunPod 4090, entrambe a otto vie di concorrenza, invece dei diversi minuti che una stima a flusso singolo suggerisce, perché la concorrenza sovrappone le chiamate e i verdict reali stanno dentro il budget di token.

Se un modello piccolo è abbastanza buono

Il costo conta solo se il modello economico regge. Nei nostri run un modello aperto 7B ha mantenuto il contratto di triage strutturato di SocTalk: output router e verdict valido, nessun errore di schema, e verdict che hanno coinciso con un modello di ragionamento più grande su circa il 58-75 per cento di un piccolo campione di benchmark. Era più debole sull'instradamento, e sui casi sensibili all'autorizzazione a volte ha chiuso attività che non aveva alcuna autorizzazione agli atti e che sarebbe dovuta andare in escalation.

Un piccolo modello self-hosted è quindi un tier economico praticabile per la fascia ordinaria, con un modello capace dietro per i casi difficili. Se sia abbastanza buono per il vostro ambiente è una misurazione, non un'assunzione, e va fatta contro un benchmark rappresentativo prima di affidare a un modello piccolo qualsiasi decisione di chiusura. Il safety floor regge comunque. Nessun modello può chiudere su un segnale malevolo noto né su un caso correlato attivo, comunque sia stato servito.

Limiti da pianificare

• Avvii a freddo. Un backend scalato a zero o appena noleggiato non è pronto all'istante. Il download e il caricamento del modello richiedono minuti, quindi una raffica che arriva a freddo aspetta. Bene per il triage ordinario, un problema per qualsiasi cosa urgente, ed è per questo che un tier di fallback a caldo si guadagna il suo posto.
• Carico operativo sui noleggi. Una GPU noleggiata fattura finché non la fermate e non ha scalare a zero, quindi il tempo di inattività è denaro sprecato e lo smontaggio tocca a voi ricordarlo. La disponibilità sui livelli più economici varia.
• Contabilità dei costi. Un budget per token è l'unità giusta per un'API di frontiera e quella sbagliata per un backend a GPU-secondo. Contabilizzate secondo l'unità di fatturazione propria del backend quando fate self-hosting.
• La governance dei dati è uno spettro. Il mascheramento toglie i segreti prima che qualcosa parta, ma il contesto operativo, host, account, contenuto dei log, viaggia comunque verso un'API esterna. Solo il self-hosting dentro il confine tiene quel contesto nel vostro perimetro.

Scegliere dove far girare il modello

Tre domande lo risolvono. Utilizzo. Un carico stabile e ad alto utilizzo favorisce una scheda noleggiata; un carico sporadico e a raffiche favorisce una piattaforma che scala a zero o un'API gestita il cui costo a riposo è zero. Propensione operativa. Un noleggio è il più economico ma lo gestite voi; una piattaforma serverless costa di più e si gestisce da sé; un'API costa di più senza nulla da gestire. Sensibilità dei dati. Se il contenuto delle allerte non può lasciare il vostro confine, il self-hosting è l'unica risposta, e il lavoro qui sopra è come lo rendete sostenibile.

Per la maggior parte dei team l'ordine è lo stesso di questa guida. Batching e cache prima, il router su un modello più economico poi, e un tier self-hosted solo quando il volume e la necessità di residenza dei dati giustificano il gestirlo.

Disclaimer. SocTalk non è affiliata, approvata né sponsorizzata da alcun fornitore di servizi LLM o GPU. Modal, RunPod, Anthropic, OpenAI, Ollama e qualsiasi altro servizio nominato in questa guida sono menzionati solo come esempi di dove un modello può girare. Le cifre di costo e prestazioni sono nostre osservazioni di benchmark, non numeri pubblicati dai fornitori, e tutti i nomi di prodotto e i marchi appartengono ai rispettivi proprietari.