Partiamo dalla conclusione: quando la bolletta sale, nell'80% dei casi non è il volume a salire. Ho seguito un progetto di servizio clienti intelligente: nella prima metà dell'anno scorso la bolletta mensile era stabile intorno agli 8000 yuan, nel quarto trimestre è saltata a 23000 yuan, mentre nello stesso periodo il volume di chiamate è cresciuto solo del 40%. Dove sono finiti i soldi in più? Ho estratto i log di chiamata di tre mesi e li ho aggregati secondo quattro dimensioni: tipo di attività, lunghezza dell'input, lunghezza dell'output, numero di tentativi. Il problema era chiarissimo: quattro buchi neri nascosti di costo stavano sanguinando contemporaneamente.
Prima una definizione, per evitare fraintendimenti. La struttura dei costi delle API per grandi modelli è, in sostanza, la somma di tre parti: «token di input + token di output + token invalidi generati dai tentativi falliti»; la fatturazione a consumo è solo una modalità di tariffazione, non è che ti aiuti a risparmiare. A determinare davvero la bolletta sono la strategia di routing e la strategia di gestione del contesto sul gateway dei modelli.
Buco nero uno: il modello di punta fa il lavoro grosso
Questa è la voce più costosa. Quel sistema di servizio clienti aveva tre tipi di attività: classificazione dei ticket, etichettatura delle emozioni, riconoscimento delle intenzioni, per un totale di circa 120.000 chiamate al giorno. All'epoca, per comodità, passavano tutte dallo stesso modello di punta. Ma che difficoltà hanno questi tre tipi di attività? Dammi un messaggio utente di duecento caratteri e dimmi se è «richiesta sulla logistica» o «rimborso post-vendita»: un piccolo modello fa questo lavoro in modo più stabile di un grande modello, perché lo spazio delle etichette è limitato.
Ho rieseguito la valutazione per attività: per la classificazione, passando a un modello di taglia media, l'accuratezza è scesa dal 96,2% al 95,7%, 0,5 punti in meno, con un prezzo unitario inferiore di un ordine di grandezza. Solo questa voce può tagliare il 40% della bolletta.
Buco nero due: la cronologia del contesto reinserita per intero
Il servizio clienti è una conversazione multi-turno, con una media di 7,3 turni. Gli sviluppatori, per semplicità, inserivano ogni volta la cronologia completa. Al primo turno l'input era di 800 token, al settimo turno l'input diventava di 4200 token, e ogni turno pagava di nuovo per i sei turni precedenti. Questa curva di costo è di tipo quadratico: appena il volume sale, esplode.
Il problema maggiore è che gran parte della cronologia non ha alcun valore per il turno corrente. L'utente al terzo turno aveva detto «voglio fare il reso», al settimo chiede «chi paga la spedizione»: tutte quelle convenevoli e descrizioni del prodotto precedenti sono token sprecati.
Buco nero tre: l'amplificazione dei tentativi falliti
Questo è il più nascosto. Quando l'upstream applica limiti di frequenza o va in timeout, l'SDK per impostazione predefinita ritenta tre volte. Il problema è che le richieste di nuovo tentativo spesso reinviano per intero lo stesso lungo contesto. Ho calcolato che circa l'11% dei token in bolletta proveniva dai tentativi falliti, e di queste chiamate alla fine il 60% falliva comunque: puro spreco. Se i tentativi non hanno backoff e controllo di idempotenza, un singolo guasto può amplificare fino a tre volte il consumo invalido.
Buco nero quattro: output in streaming non troncato
I token di output di solito costano più di quelli di input. All'epoca le risposte del servizio clienti non avevano un max_tokens impostato, e il modello ogni tanto «si lasciava andare»: una spiegazione di rimborso che si poteva dire in due frasi diventava un paragrafo di procedura numerata. Nella distribuzione della lunghezza dell'output, il P99 era più di sei volte il P50. Quelle parole in più gli utenti non le leggono nemmeno, ma si pagano lo stesso.
Cinque azioni per fermare l'emorragia
Primo, routing gerarchico dei modelli. Ho creato tre livelli per attività: la classificazione semplice va al modello piccolo, le domande e risposte standard al livello intermedio, solo i reclami complessi e la mediazione delle controversie arrivano al modello di punta. Questo livello l'ho configurato su SiCore TokenWorks, che instrada automaticamente in base ai tag del tipo di attività, senza modificare il codice di business, aggiungendo solo regole lato gateway. Dopo il passaggio, nella prima settimana la parte di costo delle attività di classificazione è scesa direttamente di un livello.
Secondo, finestra scorrevole sul contesto più riassunto. Si mantengono gli ultimi tre turni di testo originale, le conversazioni precedenti vengono compresse in un riassunto entro cento caratteri. In pratica la lunghezza media dell'input è scesa da 3200 token a 1400 token, senza compromettere la coerenza del contesto del servizio clienti.
Terzo, tentativi idempotenti. Ogni richiesta porta un ID univoco, il gateway riconosce le richieste duplicate e riutilizza direttamente il risultato, e il nuovo tentativo reinvia solo il frammento fallito invece dell'intero contesto. Questa voce ha ridotto i token invalidi da tentativi dall'11% a meno del 3%.
Quarto, vincolo sulla lunghezza dell'output. Si imposta un limite max_tokens per tipo di attività; per scenari fissi come le spiegazioni di rimborso si fornisce direttamente un template e il modello compila solo le variabili. I token di output sono calati di circa il 30%.
Quinto, scegliere il modello per attività, non per abitudine. Sembra una banalità, ma molti team sono semplicemente pigri e usano un solo modello per tutto. In seguito su SiCore TokenWorks abbiamo messo modelli nazionali e modelli esteri nella stessa interfaccia per test comparativi: sullo stesso corpus di servizio clienti, DeepSeek e Qwen se la cavano più che bene negli scenari di testo cinese, con prezzi più adatti ai grandi volumi. Il vantaggio dell'accesso unificato a più modelli sta proprio qui: cambiare modello non richiede modificare l'SDK, basta cambiare una riga di base_url.
Il prerequisito della fatturazione a consumo è un routing corretto
La frase «fatturazione a consumo, costi migliori» di per sé non è sbagliata, ma ha un prerequisito: la tua strategia di routing deve essere corretta. La fatturazione a consumo garantisce solo che non paghi per capacità inattiva, non garantisce che non paghi per una scelta sbagliata del modello. La bolletta è tornata da 23000 yuan a poco più di 9000 yuan, con volumi persino aumentati, non grazie al cambio con una piattaforma più economica, ma perché abbiamo fatto bene due cose: routing e contesto.
Se anche tu stai guardando una bolletta incomprensibile, ti consiglio di dividere prima i log di chiamata per tipo di attività e lunghezza di input/output e dare un'occhiata: di solito i buchi neri non sono dove pensi. L'ambito in cui SiCore TokenWorks può essere d'aiuto in scenari di ottimizzazione dei costi come questo è soprattutto il livello del gateway dei modelli: routing gerarchico, limiti di frequenza come rete di sicurezza, accesso unificato a più modelli, cose che dal lato business sono quasi impercettibili.
Autore: Li Yunlong
Data di pubblicazione: 24 ottobre 2026