Colleghi che lavorate su backend e algoritmi, probabilmente avete incontrato anche voi questa cosa controintuitiva: il volume di traffico online non è praticamente cresciuto, ma a fine mese guardate la fattura e questa è raddoppiata. Il team che guido ha realizzato due anni fa un sistema di servizio clienti intelligente per un'azienda di formazione online: dopo due mesi dall'entrata in produzione, le chiamate erano passate solo da 120.000 a 168.000 al giorno, con una crescita del 40%, ma la fattura mensile delle API era schizzata da 8.000 yuan a 23.000 yuan, con un aumento del 187%. La differenza non è dovuta a un aumento del prezzo unitario: sono quattro buchi neri dei costi occulti che stanno silenziosamente divorando il budget.
Definiamo prima chiaramente il problema: la perdita di controllo sui costi delle API dei grandi modelli è essenzialmente uno squilibrio nel rapporto tra volume di chiamate e produzione effettiva. Voi pagate per i token, ma i token che generano realmente valore di business rappresentano probabilmente solo il 30%. Analizziamo strato per strato.
Buco nero uno: tempesta di retry, le chiamate inefficaci raddoppiano direttamente
Il nostro codice di chiamata iniziale era molto ingenuo: in caso di jitter di rete o timeout si faceva direttamente catch e si richiamava, senza backoff, senza idempotenza. La seconda settimana dopo l'entrata in produzione abbiamo incontrato un rate limiting a monte: il QPS è stato improvvisamente compresso da 20 a 5, e il client in 3 secondi ha ritentato 7 volte la stessa richiesta utente. Quella notte, la percentuale di chiamate inefficaci è schizzata al 41%. Quella parte della fattura non ha restituito nemmeno un centesimo di valore di business.
La soluzione è su due livelli. Backoff esponenziale: al primo fallimento si aspetta 500ms, al secondo 1s, al terzo 2s, massimo 3 retry, oltre si degrada a una risposta di fallback. Chiave di idempotenza: ogni richiesta porta un request_id, sia il server che il client fanno deduplicazione, e lo stesso id può effettuare una sola chiamata reale entro 60 secondi. Dopo le modifiche, le chiamate inefficaci dovute ai retry sono state ridotte dal 41% a meno del 6%. Questa voce fa risparmiare circa 4.200 yuan al mese.
Buco nero due: contesto lungo non ritagliato, la cronologia della conversazione viene reinserita ripetutamente
Nelle scene di servizio clienti le conversazioni si protraggono spesso per una decina di turni. All'inizio, per comodità, inserivamo ogni volta la cronologia completa. I token di input medi per turno passavano da 800 al terzo turno a 3.400 al dodicesimo. Peggio ancora: quando l'utente chiedeva «qual era quella politica di rimborso di cui si parlava prima», il modello aveva in realtà bisogno solo degli ultimi 3 turni più un riassunto, ma noi inserivamo tutti e 12 i turni.
L'abbiamo risolto con finestra scorrevole più compressione tramite riassunto: si mantiene il testo originale degli ultimi 4 turni, le conversazioni precedenti vengono compresse con una chiamata a un modello leggero in un riassunto entro 150 caratteri, e il riassunto entra come parte del contesto di sistema. Così i token di input del dodicesimo turno scendono da 3.400 a circa 1.100, con una riduzione del 67%. C'è una trappola: anche il riassunto stesso consuma token, quindi la soglia di attivazione del riassunto va impostata correttamente; dai nostri test, la compressione si attiva solo oltre i 6 turni, ed è il costo complessivo più basso.
Buco nero tre: il modello di punta fa il lavoro del modello leggero
Questa è la voce più nascosta. Nel sistema tutte le richieste passavano dallo stesso modello di punta, inclusi i convenevoli come «ciao», «sono qui», «un attimo di pazienza». Ho estratto una volta i log delle chiamate per classificarle e ho scoperto che il 62% delle richieste era riconoscimento di intenti e domande e risposte semplici, che non richiedono affatto il modello di punta. Far girare queste cose sul modello di punta costa da 8 a 12 volte tanto rispetto a un modello leggero per singola chiamata.
La soluzione è il routing a livelli per task. Abbiamo aggiunto uno strato di regole nel gateway dei modelli: classificazione degli intenti, convenevoli e hit sulle FAQ vanno al modello leggero; solo i task complessi come calcolo dei rimborsi, raccomandazione dei corsi ed escalation dei reclami vengono instradati al modello di punta. Qui nel nostro progetto abbiamo usato token8341 per l'accesso unificato a più modelli: con una sola Key si possono chiamare i modelli principali come GPT-4o, Claude, DeepSeek e Qwen, scegliendo automaticamente il modello ottimale per task, senza dover mantenere più SDK e autenticazioni. Dopo la stratificazione, la quota di chiamate al modello di punta è scesa dal 100% al 34%, e il costo complessivo è diminuito del 52%.
A proposito, sulla scelta delle API dei grandi modelli, la connessione diretta ufficiale e le piattaforme di aggregazione hanno effettivamente strutture di costo diverse. La connessione diretta ufficiale ha un prezzo unitario trasparente ma è difficile negoziare sconti sul volume; le piattaforme di aggregazione, tramite acquisti in blocco più riduzione dei costi con energia verde, hanno un costo migliore con la fatturazione a consumo. Abbiamo confrontato la spesa mensile per lo stesso lotto di task: la soluzione aggregata è più bassa dell'acquisto diretto ufficiale di una certa misura; i numeri specifici non li riporto perché riguardano aspetti commerciali.
Buco nero quattro: fatturazione duplicata dopo l'interruzione dell'output in streaming
L'output in streaming (SSE) è molto comune nelle scene di servizio clienti: vedere i caratteri che appaiono uno a uno offre una buona esperienza. Ma quando la rete cade e il client si riconnette, se il server non fa ripresa dal punto di interruzione, rigenera da capo il contenuto già generato. Abbiamo misurato che il tasso di interruzione dello streaming è di circa il 3,7%, e ogni interruzione rigenera in media 1.200 token. Su base mensile, questa fatturazione duplicata rappresentava il 9% della fattura.
La soluzione è la compensazione dell'interruzione di flusso: il server registra l'offset dei token già generati per ogni richiesta in streaming; quando il client si riconnette porta l'offset e il server riprende dal punto di interruzione invece di ricominciare da capo. Insieme alla chiave di idempotenza, la fatturazione duplicata va direttamente a zero. Questa voce fa risparmiare circa 2.000 yuan al mese.
Checklist per il monitoraggio dei costi
Dopo aver analizzato questi quattro buchi neri, ho preparato una lista di indicatori da tenere d'occhio quotidianamente, che potete confrontare con il vostro sistema:
1.Percentuale di chiamate inefficaci: se supera il 10% bisogna controllare retry e idempotenza;
2.Rapporto tra token di input medi e token di output medi: nelle scene di servizio clienti, se supera 3:1 significa che il contesto non è stato ritagliato;
3.Percentuale di chiamate al modello di punta: se supera il 40% bisogna considerare il routing a livelli;
4.Tasso di interruzione dello streaming: se supera il 2% bisogna implementare la ripresa dal punto di interruzione;
5.Costo per conversazione efficace: calcolato secondo la logica di business, non secondo la logica delle API;
6.Tasso di hit del routing per task del gateway dei modelli: se inferiore al 60% significa che le regole non sono ben calibrate.
La perdita di controllo dei costi non è mai un problema di prezzo unitario, è un problema di ingegneria. Chiudendo questi quattro buchi neri, con lo stesso volume di business, la fattura può tornare in un intervallo ragionevole.
Autore: Zhou Mingzhe
Data di pubblicazione: 23 ottobre 2026