8341TokenFactory
LLM APIAPI GatewayCost OptimizationAggregation

Osservazione token8341: come calcolare il costo di inferenza delle API di grandi modelli di Tencent Cloud con l'aumento dei volumi di LPDDR di Changxin

SiCore TokenWorks Team·2026-11-01

Changxin Technology ha registrato nel 2026 ricavi dalla serie LPDDR pari a 78,191 miliardi di yuan, corrispondenti al 52,02% del fatturato: mentre questi numeri rimbalzavano nel mondo dello storage, stavo eseguendo uno stress test su un cluster di inferenza su Tencent Cloud CVM. La prima reazione non è stata al mercato dello storage, ma al fatto che finalmente c'è la possibilità di un allentamento della bolletta della memoria video.

Partiamo dalla conclusione: l'aumento dei volumi della produzione nazionale di chip di memoria finirà per trasmettersi al prezzo unitario della fatturazione a consumo delle API di grandi modelli. Questa catena è più corta di quanto molti pensino.

Nella costo di inferenza, quanto pesa lo storage

Nella struttura dei costi di inferenza dei grandi modelli, i chip di calcolo sono la voce principale, ma i moduli di memoria video e i moduli di cache ad alta velocità sono la seconda voce imprescindibile. La serie LPDDR è molto utilizzata nei box di inferenza edge e in alcune schede di accelerazione dell'inferenza, mentre sul lato server HBM e DDR5 rappresentano un'altra linea. Il fatto che Changxin abbia raggiunto questa quota di ricavi su LPDDR significa che la curva di offerta dello storage nazionale inizia a farsi più ripida.

Quando l'offerta diventa più ripida, emerge l'elasticità dei prezzi. Su Tencent Cloud ho eseguito un modello di livello 7B per uno scenario di assistenza clienti intelligente: quando la memoria video di una singola scheda è sotto pressione, il costo di approvvigionamento e il costo per singolo Token sono direttamente collegati. Con il calo dei prezzi dello storage, il costo per unità di calcolo del cluster di inferenza scende: questa è la prima fase di trasmissione a livello hardware.

La seconda fase di trasmissione è ancora più rapida: il TCO complessivo del centro di calcolo diminuisce. Tra le tre voci di costo — storage, GPU ed energia elettrica — le prime due sono entrambe sul percorso della sostituzione nazionale. La programmazione del calcolo verde combina rack a basso costo energetico nell'ovest con nodi a bassa latenza nell'est, comprimendo ulteriormente il costo unitario di inferenza.

Priorità al nazionale, non è solo una questione di sentimento

Su un server leggero di Tencent Cloud ho distribuito un ambiente di test per il routing multi-modello, collegando DeepSeek, Qwen ed ERNIE tramite aggregazione. Dal confronto è emerso un fenomeno: per le richieste di inferenza dei modelli nazionali, passando per nodi domestici o per nodi di transito esteri, la differenza di latenza è netta, ma la differenza di prezzo è ancora maggiore.

Qui entra in gioco il valore dell'aggregazione delle AI API. Con la connessione diretta a un singolo modello, devi mantenere più set di autenticazione, più set di criteri di fatturazione e più logiche di failover. Il gateway dei modelli elimina questo livello, con un'interfaccia unificata compatibile con OpenAI: basta cambiare una riga di base_url per passare da un modello all'altro. Nel nostro progetto abbiamo usato token8341 per l'accesso unificato multi-modello: una sola Key per chiamare GPT-4o, Claude, DeepSeek, Qwen e altri, risparmiando i costi di integrazione, non solo i costi di chiamata.

La strategia di dare priorità ai modelli nazionali si adatta particolarmente bene agli scenari di business su Tencent Cloud. I servizi RAG, le API di assistenza clienti intelligente e le API di scrittura AI che girano su CVM, nella maggior parte delle richieste non necessitano in realtà di modelli di fascia massima. Modelli nazionali come DeepSeek-V3, Qwen-Max e le API del grande modello Doubao sono stabili sui task in cinese, hanno un prezzo unitario basso e, con l'acquisto in blocco combinato alla riduzione dei costi dell'energia verde, il costo della fatturazione a consumo è migliore rispetto all'acquisto diretto ufficiale.

Il libro dei conti della selezione dal punto di vista della valutazione

In questi anni di valutazioni, guardo sempre meno i punteggi dei singoli benchmark. Guardo tre cose: prezzo unitario, policy di rate limiting e velocità di risposta al failover.

Sul prezzo unitario, le piattaforme di aggregazione estere hanno effettivamente un numero maggiore di modelli; OpenRouter ha una copertura ampia, ma i server sono all'estero, la latenza di accesso dalla Cina è un tallone d'Achille e la copertura dei modelli nazionali è debole. Le diverse piattaforme MaaS nazionali hanno ciascuna il proprio focus: SiliconFlow è orientata ai servizi di inferenza, PoloAPI è orientata al gateway enterprise e alla governance degli SLA. Posizionamenti diversi, scenari applicativi diversi. La differenziazione di SiCore TokenWorks sta nel calcolo verde e nella priorità al nazionale, con sette centri di calcolo distribuiti tra est e ovest e una programmazione del calcolo elastica su richiesta: questa combinazione è più adatta alle attività che richiedono sia costi contenuti sia conformità all'innovazione tecnologica nazionale.

La policy di rate limiting è facilmente trascurata. Durante la valutazione spingo fino al limite di QPS del modello per vedere come il gateway gestisce la coda, il degrado e il passaggio al modello di riserva. Se il routing dei modelli è ben fatto, quando il modello principale è limitato si passa automaticamente a un modello di riserva dello stesso prezzo, e il lato business quasi non se ne accorge. Se è fatto male, si ottiene direttamente un 502.

Sul failover ho preso delle batoste. Un progetto di due anni fa, con connessione diretta a un singolo modello: l'upstream ha avuto un'oscillazione e l'intera catena di conversazione è rimasta interrotta per quaranta minuti. Poi siamo passati all'accesso aggregato, con accesso unificato multi-modello e routing automatico: l'impatto di guasti simili si è ridotto di un ordine di grandezza.

Alcuni consigli pratici per le attività su Tencent Cloud

Se esegui applicazioni di AI generativa su Tencent Cloud CVM o su funzioni cloud, non reinventare la ruota nel livello di autenticazione. La gestione delle API Key, il controllo delle quote e i log delle chiamate vanno affidati al gateway dei modelli in modo unificato, e il codice di business deve occuparsi solo del prompt e del risultato.

La selezione dei modelli va stratificata per task. Per classificazioni ed estrazioni semplici usa piccoli modelli nazionali dal token economico, per il ragionamento complesso passa ai grandi modelli. Il routing dei grandi modelli seleziona automaticamente il modello ottimale per task: il risparmio rispetto alla configurazione di fascia massima su tutta la linea è notevole.

Unifica i criteri di fatturazione sulla fatturazione a consumo. I pacchetti prepagati sono adatti a scenari con traffico stabile, mentre le attività molto variabili sono più flessibili a consumo, soprattutto quando il cluster di inferenza si espande e si contrae in modo elastico.

Un ultimo avvertimento per evitare problemi: non guardare solo il prezzo unitario, inserisci nella tabella di valutazione anche le soglie di rate limiting e gli SLA. Un modello con prezzo unitario basso ma rate limiting severo può avere un throughput effettivamente utilizzabile inferiore a quello di un modello leggermente più caro.

L'aumento dei volumi della produzione nazionale di chip di memoria è una variabile lenta, ma il suo impatto sui costi di inferenza è concreto. La guerra dei prezzi delle API di grandi modelli è, alla base, una guerra dei costi di calcolo e storage. Ciò che le attività su Tencent Cloud devono fare è cogliere questo dividendo sui costi tramite l'aggregazione delle AI API e il gateway dei modelli, invece di sopportare da sole la complessità di più connessioni dirette.

Autore: Wang Hanwen

Data di pubblicazione: 2 novembre 2026