Lavoro comparabile. Ipotesi esplicite.

1. Un contratto di confronto con versione

Modello e revisione esatta, precisione, quantizzazione, runtime e versione, protocollo e versione del benchmark e obiettivo di qualità devono coincidere. L’inferenza fissa inoltre le lunghezze di input/output, la dimensione del batch, la concorrenza, il caching, la base dei token e il vincolo di latenza. L’addestramento fissa il dataset e la sua revisione, la definizione del lavoro e il criterio di completamento.

Il modello di GPU, il numero di GPU, l’hardware, l’interconnessione e il parallelismo possono variare tra i risultati all’interno di quel contratto, ma ogni risultato deve conservare la configurazione misurata. Il collegamento al prezzo della v1 supporta un solo nodo. Non viene dedotta alcuna scalatura delle prestazioni hardware.

2. Una formula, unità esplicite

Per il costo orario dell’intero sistema C e un throughput aggregato compatibile T in token al secondo:

USD per 1M di token = C × 1,000,000 / (T × 3,600)

Un prezzo orario per GPU viene moltiplicato una sola volta per il numero di GPU misurato. Un prezzo orario per l’intera istanza è già un prezzo di sistema. Il throughput per GPU viene moltiplicato una sola volta per il numero di GPU misurato; il throughput aggregato viene usato direttamente. Il contratto di confronto indica se si tratta di token di input, di output o totali.

Per l’addestramento: costo per esecuzione definita = costo orario del sistema × ore di esecuzione misurate. Le GPU-hour per esecuzione vengono divise per il numero di GPU misurato per stimare le ore trascorse, esplicitamente indicate come stima contabile. Gli scenari con esecuzioni ripetute presuppongono esecuzioni identiche in sequenza.

3. Compatibilità del prezzo e costi

Un fondatore deve attestare che l’osservazione di prezzo pubblica copre esattamente la configurazione misurata e l’addebito a listino per la capacità di calcolo. Sono supportate le unità originali in USD per GPU-ora e per istanza-ora. Le altre valute e unità restano non disponibili. Un fixing aggregato KCI pubblico non può sostituire il prezzo di un sistema acquistabile.

È incluso solo l’addebito a listino per la capacità di calcolo. Sono esclusi setup, CPU/RAM fatturate separatamente, storage, rete/egress, imposte e supporto. Le istantanee di base non modellano minimi di impegno, incrementi di fatturazione, perdite di utilizzo né disponibilità; la spesa effettiva può essere più alta. Non sono prezzi dei token delle API né stime del costo totale.

4. Freschezza, esame e revisioni

Le osservazioni dei benchmark mantengono l’attuale limite di freschezza delle prestazioni di 180 giorni. Economics v1 applica un limite di 30 giorni al prezzo, per evitare di presentare vecchie osservazioni di listino come costi attuali. Sono finestre di idoneità, non punteggi di confidenza. Le classi di fonte sono: dichiarata dal provider, indipendente o interna.

L’importazione o l’acquisizione crea una bozza; un esame esplicito la approva. Il ritiro e la sostituzione approvata bloccano i nuovi calcoli. Le istantanee immutabili conservano gli input originali, le date di misurazione, le date di acquisizione, le revisioni dei benchmark, le versioni dei gruppi, la versione della formula e il momento del calcolo. La depubblicazione di una fonte può rimuovere l’accesso pubblico senza cancellare il record interno conservato.

5. Storico e strumenti decisionali

Lo storico dell’economia è un registro informativo. Non è un livello dell’Index e non viene inserito automaticamente nello storico dei fixing KCI. Le correzioni rimandano alle istantanee precedenti. Le variazioni di configurazione, versione del contratto, revisione del benchmark o formula stabiliscono segmenti separati. Non viene generata alcuna ricostruzione retroattiva dello storico.

Gli scenari di volume dell’utente mantengono le condizioni del carico di lavoro selezionato. Il tempo è stimato a partire dal throughput misurato sostenuto o da esecuzioni di addestramento identiche ripetute. Segui il link dell’offerta per esaminare i dettagli commerciali oppure apri Workload Economics per pianificare con ipotesi aggiuntive. Non viene eseguita alcuna azione di prenotazione o di approvvigionamento.

Scenari di costo e di scadenza

Lo spazio di lavoro decisionale confronta due istantanee scelte esplicitamente, con lo stesso contratto, la stessa formula, le stesse unità e la stessa copertura dei costi. Condizioni commerciali e classi di fonte diverse vengono segnalate. Input scaduti, ritirati o corretti non possono supportare un nuovo confronto.

Ore produttive = ore dell’istantanea per unità di misura × unità richieste
Ore trascorse = ore produttive / (percentuale di utilizzo / 100)
Ore fatturate = max(ore trascorse, ore minime fatturate indicate dall’utente)
Subtotale della capacità di calcolo = ore fatturate × costo orario del sistema in USD
Totale modellato = subtotale della capacità di calcolo + costi aggiuntivi in USD inseriti esplicitamente

Ogni scenario usa un solo sistema misurato e presuppone che venga fatturato anche durante i tempi di inattività. Il minimo di fatturazione cambia il costo, non il tempo di completamento. I costi aggiuntivi lasciati vuoti restano sconosciuti; non viene mostrato alcun totale modellato. Una stima della scadenza esclude code, ritardi di avvio e vincoli di capacità. Gli obblighi contrattuali completi, gli addebiti non inseriti e la disponibilità del provider restano non verificati. Il risultato non è né un TCO completo né un preventivo.

Il JSON dello scenario scaricabile conserva le istantanee esatte delle evidenze, i timestamp delle fonti e le ipotesi dell’utente. È un resoconto in un dato momento, non una garanzia di validità attuale. Aggiorna le evidenze prima di una decisione. Gli scenari non vengono salvati in un account.

6. Accesso ai dati in sola lettura

GET /api/index/economics?limit=50&format=json GET /api/index/economics?group=GROUP_UUID&format=csv

Limiti: da 1 a 100 istantanee; predefinito 50. I parametri sconosciuti, duplicati o malformati vengono rifiutati. Le risposte includono input originali, unità, fonti, timestamp, revisioni, stato attuale e codici dei motivi. Le letture applicano la visibilità pubblica, escludono gli autori e le note dell’esame e non espongono il registro interno delle esecuzioni. Le risposte limitate segnalano esplicitamente il troncamento.

Tempi di osservazione e di calcolo

Il campo effective_at dell’API registra il momento dell’osservazione del prezzo originale. calculated_at registra quando gli input esaminati sono stati combinati. Un benchmark successivo non stabilisce l’economia a una data di prezzo precedente; questo registro non ricostruisce retroattivamente le prestazioni storiche.