—
piattaforma/mese più economica—RunPod/mese
—Baseten/mese
—Modale/mese
Diffusione dei costi: stessa tariffa GPU nominale $/ora
—
Ripartizione della fatturazione per piattaforma
Stessi input di cui sopra, applicati attraverso la logica di fatturazione distinta di ciascuna piattaforma. Le unità fatturate al giorno rappresentano la quantità grezza effettivamente addebitata da ciascuna piattaforma: secondi per RunPod e Modal, minuti per Baseten.
Costo mensile per tasso di avvio a freddo (intensità del traffico)
Stessa durata, tariffa e input buffer di cui sopra, suddivisi in base alla tariffa di avvio a freddo: quanto sono distribuite le tue richieste. La riga evidenziata è quella più vicina all'attuale tasso di avvio a freddo immesso. Guarda come può cambiare la piattaforma più economica man mano che il traffico diventa più intenso.
| Tasso di avviamento a freddo | RunPod/mese | Baseten/mese | Modale/mese | Il più economico |
|---|
Come si collega ad altri strumenti
Questo calcolatore valuta una domanda specifica e ristretta: per BURSTY, traffico di inferenza a basso QPS, in che modo la stessa tariffa nominale $/GPU ora si trasforma in fatture reali molto diverse a seconda dei meccanismi di fatturazione di una piattaforma: al secondo, al minuto con arrotondamento o al secondo più buffer di mantenimento. Non modella deliberatamente il noleggio di GPU a tariffa fissa e ad alto utilizzo, in cui si paga per ore continue indipendentemente dal modello di richiesta: per tale inquadratura, consultare la sezione Calcolatore dei costi del cloud GPU e il Calcolatore del costo di noleggio GPU, che considerano il costo della GPU come $/ora × ore utilizzate. Questo strumento esiste proprio perché i calcoli a tariffa fissa non funzionano in caso di carichi di lavoro sporadici e inclini all'avvio a freddo: uno strumento interno chiamato alcune centinaia di volte al giorno non si comporta come un'API occupata che blocca una GPU ad alto utilizzo e la differenza nella forma di fatturazione tra le piattaforme viene visualizzata solo una volta modellizzati esplicitamente gli avviamenti a freddo e i tempi di inattività anziché ipotizzare una tariffa fissa per ore.
Come funziona questa calcolatrice
IL Calcolatore di fatturazione della piattaforma GPU serverless divide il tuo traffico giornaliero in due segmenti utilizzando il metodo tasso di avviamento a freddo: richieste fredde (richieste giornaliere × tariffa partenza a freddo) sono quelle che arrivano dopo che il contenitore è stato ridimensionato a zero e devono pagare l'intero durata dell'avviamento a freddo più il durata dell'inferenza calda; calde richieste (il resto) colpisce un container già carico e paga solo la durata dell'inferenza. Ciascuna piattaforma applica quindi la propria logica di fatturazione a questi due bucket. RunPod fatture al secondo per ogni secondo in cui il contenitore è attivo (freddo o caldo), quindi la sua fattura giornaliera è semplicemente il totale dei secondi attivi ÷ 3.600 × il tuo Tariffa oraria GPU. Baseten fattura al minuto e arrotonda ogni singola invocazione al minuto intero successivo, in modo che anche una chiamata calda di 3 secondi e una chiamata fredda di 11 secondi consumino ciascuna un minuto intero fatturato; la sua fattura giornaliera corrisponde al totale dei minuti fatturati ÷ 60 × la tariffa oraria. Modale fatture al secondo come RunPod per il calcolo effettivo, ma aggiunge il buffer inattivo per mantenere caldo come secondi fatturati extra su ogni richiesta a caldo: il contenitore rimane attivo e fattura per quella finestra di buffer in modo che la richiesta successiva possa saltare il proprio avvio a freddo.
Il numero che vale la pena guardare è il ripartizione dei costi mensili tra la piattaforma più economica e quella più costosa: nell'impostazione predefinita del calcolatore (200 richieste/giorno, 3 secondi a caldo, 8 secondi con avvio a freddo, tariffa di avvio a freddo del 40%, $ 2,49/ora), lo spread è all'incirca 9-10x tra RunPod e Baseten, esattamente alla stessa tariffa oraria nominale della GPU. Questo divario non è un trucco di prezzo: è ciò che accade quando la durata tipica della chiamata di un carico di lavoro (pochi secondi) si scontra con una granularità di fatturazione creata per lavori più lunghi (un minuto intero). Più le tue chiamate sono brevi e sporadiche, più questa forma conta più della tariffa $/ora dell'adesivo. Questo strumento modella la MECCANICA documentata pubblicamente da questo tipo di piattaforme – fatturazione al secondo, arrotondamento al minuto, buffer di mantenimento – come approssimazione per mostrare la forma della differenza; controlla sempre le pagine dei prezzi attuali del fornitore prima di impegnarti, poiché le tariffe esatte e le regole di arrotondamento possono cambiare.
Domande frequenti
Perché Baseten costa più di RunPod per la stessa GPU?
Non perché la tariffa GPU sottostante sia diversa (in questo confronto entrambe vengono fatturate allo stesso $/ora), ma a causa del modo in cui ciascuna piattaforma funziona 24 ore su 24. La fatturazione serverless di RunPod è al secondo: paghi esattamente per i secondi in cui il contenitore è attivo, incluso il tempo di caricamento con avvio a freddo, e niente di più. Baseten fattura al minuto e arrotonda ogni invocazione al minuto intero successivo. Una chiamata di inferenza calda di 3 secondi viene comunque fatturata come un minuto intero di 60 secondi, e anche una chiamata con avvio a freddo di 11 secondi viene fatturata come lo stesso minuto intero, perché entrambe arrotondano a 1. Per un carico di lavoro rapido e a basso QPS in cui la maggior parte delle chiamate individuali dura solo pochi secondi, l'arrotondamento è brutale: stai effettivamente pagando per 15-20 volte più tempo di elaborazione di quello effettivamente utilizzato in ogni singola chiamata. Il divario non è un espediente dei prezzi, è un puro arrotondamento della granularità al minuto applicato a lavori molto brevi e si aggrava ogni volta che il carico di lavoro è così breve e così frequente.
Che cos'è una "partenza a freddo" e perché costa denaro?
Una piattaforma GPU serverless non mantiene un contenitore in esecuzione (e ti fattura) quando non accade nulla: riduce il contenitore a zero dopo un periodo di inattività per farti risparmiare denaro sui tempi di inattività. Il compromesso è che la richiesta successiva dopo un ridimensionamento a zero deve attendere l'avvio di un nuovo contenitore: estrarre l'immagine del contenitore, caricare i pesi del modello sulla GPU, inizializzare il runtime e solo allora avviare l'inferenza effettiva. Questo processo di caricamento è il "cold start" e su carichi di lavoro LLM o inferenza ospitati su GPU richiede comunemente da diversi secondi a decine di secondi, perché il peso dei modelli può essere di gigabyte e spostarli sulla memoria della GPU non è istantaneo. Fondamentalmente, il tempo di caricamento non è tempo di calcolo gratuito che ti viene donato: la GPU è completamente allocata e fatturata durante esso su ogni piattaforma modellata qui, esattamente come sarebbe durante l'inferenza effettiva. Quindi ogni richiesta di avvio a freddo ti costa effettivamente i secondi di avvio a freddo PIÙ i secondi di inferenza effettivi, e quanto più distribuito (esplosivo) è il tuo traffico, tanto più le tue richieste colpiscono un contenitore freddo invece che uno ancora caldo, e la maggior parte della tua bolletta totale è pura spesa di caricamento piuttosto che calcolo utile.
Dovrei utilizzare un buffer di mantenimento per il mio carico di lavoro di inferenza?
Dipende se stai ottimizzando per la latenza o per i costi e questi due obiettivi vanno in direzioni opposte per il traffico intenso. Un buffer di mantenimento (modellato qui come approccio Modal) mantiene il contenitore vivo e caricato per una finestra al termine di ogni richiesta, quindi se la richiesta successiva arriva all'interno di quella finestra salta completamente l'avvio a freddo e risponde velocemente. Si tratta di un vero vantaggio in termini di esperienza utente per il traffico sensibile alla latenza. Ma stai pagando l'intero prezzo attivo della GPU per ogni secondo di inattività in cui il contenitore rimane lì in attesa, indipendentemente dal fatto che un'altra richiesta arrivi o meno in tempo: il modello modale del calcolatore aggiunge il buffer di inattività come secondi fatturati su ogni richiesta che beneficia di un contenitore caldo. Per un traffico molto sporadico – intervalli lunghi e imprevedibili tra le chiamate – quel tempo di inattività è per lo più denaro sprecato, perché il buffer scade prima che venga comunque presentata la richiesta successiva e tu lo hai pagato per niente. I buffer di mantenimento del calore hanno più senso dal punto di vista economico quando i gap di richiesta si concentrano appena all'interno della finestra del buffer; per un traffico veramente casuale o raro, consumare l'avvio a freddo occasionale è solitamente più economico che pagare per mantenere una GPU calda nella remota possibilità che arrivi presto la chiamata successiva.
La fatturazione GPU al secondo o al minuto è migliore per il traffico intenso?
Per il traffico intermittente e di breve durata, la fatturazione al secondo è quasi sempre migliore e più breve è la tipica chiamata di inferenza rispetto a un minuto, maggiore è il vantaggio. La fatturazione al minuto che arrotonda per eccesso (come il modello di Baseten qui) addebita un minuto intero, indipendentemente dal fatto che il calcolo effettivo abbia richiesto 3 secondi o 55 secondi: la granularità della fatturazione è più grossolana del carico di lavoro, quindi le chiamate brevi vengono tassate più duramente in termini percentuali. La fatturazione al secondo (come la parte di calcolo attivo di RunPod e Modal qui) si avvicina esattamente a ciò che è stato utilizzato, quindi una chiamata di 3 secondi costa circa un ventesimo di una chiamata di 60 secondi invece dello stesso importo. La fatturazione al minuto in un unico posto smette di essere un chiaro svantaggio quando la durata tipica della chiamata è già vicina o superiore a un minuto: lo spreco di arrotondamento si riduce verso zero man mano che la durata della chiamata si avvicina alla granularità della fatturazione. Per uno strumento interno o un'API sporadica chiamata alcune centinaia di volte al giorno con risposte di più secondi, la fatturazione al minuto può facilmente rivelarsi un ordine di grandezza più costosa rispetto alla fatturazione al secondo con la stessa tariffa oraria nominale della GPU.