Sammenligneligt arbejde. Eksplicitte antagelser.

1. En versioneret sammenligningskontrakt

Model og præcis revision, præcision, kvantisering, runtime og version, benchmarkprotokol og version samt kvalitetsmål skal matche. Ved inferens fastlægges desuden input-/outputlængder, batchstørrelse, samtidighed, caching, tokengrundlag og latenstidskrav. Ved træning fastlægges datasæt/revision, arbejdsdefinition og fuldførelseskriterium.

GPU-model, antal GPU’er, hardware, interconnect og parallelitet kan variere mellem resultater inden for den kontrakt, men hvert resultat skal bevare sin målte konfiguration. Prisbinding i V1 understøtter kun en enkelt node. Der udledes ingen skalering af hardwareydeevne.

2. Én formel, eksplicitte enheder

For systemets samlede timeomkostning C og kompatibel samlet throughput T i tokens/sekund:

USD pr. 1M tokens = C × 1,000,000 / (T × 3,600)

En timepris pr. GPU ganges én gang med det målte antal GPU’er. En timepris for en hel instans er allerede en systempris. Throughput pr. GPU ganges én gang med det målte antal GPU’er; samlet throughput bruges direkte. Sammenligningskontrakten angiver input-, output- eller samlede tokens.

Ved træning: omkostning pr. defineret kørsel = systemets timeomkostning × målte timer for kørslen. GPU-hours/kørsel divideres med det målte antal GPU’er for at estimere forløbne timer, eksplicit mærket som et regnskabsmæssigt estimat. Scenarier med gentagne kørsler forudsætter sekventielle, identiske kørsler.

3. Priskompatibilitet og omkostninger

En stifter skal attestere, at den offentlige prisobservation dækker præcis den målte konfiguration og det listede gebyr for regnekraft. Oprindelige enheder i USD GPU/time og instance-time understøttes. Andre valutaer og enheder forbliver ikke tilgængelige. En offentlig samlet KCI-fixing kan ikke træde i stedet for en systempris, der kan købes.

Kun det listede gebyr for regnekraft medtages. Opsætning, separat faktureret CPU/RAM, lagring, netværk/egress, skat og support er udeladt. Basissnapshots modellerer ikke minimumsbindinger, faktureringsintervaller, udnyttelsestab eller tilgængelighed; det faktiske forbrug kan være højere. Det er hverken API-tokenpriser eller estimater af de samlede omkostninger.

4. Aktualitet, gennemgang og revisioner

Benchmarkobservationer bevarer det eksisterende loft på 180 dage for aktualitet af ydelsesdata. Economics v1 anvender et prisloft på 30 dage for at undgå at præsentere gamle listeobservationer som aktuelle omkostninger. Det er kvalifikationsvinduer, ikke konfidensscorer. Kildeklasserne er udbyderdeklareret, uafhængig eller intern.

Import eller registrering opretter en kladde; en eksplicit gennemgang godkender den. Tilbagetrækning og godkendt erstatning blokerer nye beregninger. Uforanderlige snapshots bevarer oprindelige input, måledatoer, indhentningsdatoer, benchmarkrevisioner, gruppeversioner, formelversion og beregningstidspunkt. Tilbagetrækning af en kildes offentliggørelse kan fjerne den offentlige adgang uden at slette den bevarede interne post.

5. Historik og beslutningsværktøjer

Økonomihistorikken er en informativ log. Den er ikke et indeksniveau og indsættes ikke automatisk i KCI-fixinghistorikken. Rettelser henviser til tidligere snapshots. Ændringer i konfiguration, kontraktversion, benchmarkrevision eller formel danner separate segmenter. Der genereres ingen historisk tilbageudfyldning.

Brugerens volumenscenarier bevarer de valgte workloadbetingelser. Tiden estimeres ud fra vedvarende målt throughput eller gentagne identiske træningskørsler. Følg linket til tilbuddet for at undersøge de kommercielle detaljer, eller åbn Workload Economics for at planlægge med yderligere antagelser. Der foretages ingen reservation eller indkøbshandling.

Scenarier for omkostninger og deadlines

Beslutningsarbejdsområdet sammenligner to eksplicit valgte snapshots under samme kontrakt, formel, enheder og omkostningsdækning. Forskellige kommercielle vilkår og kildeklasser oplyses. Udløbne, tilbagetrukne eller rettede input kan ikke danne grundlag for en ny sammenligning.

Produktive timer = snapshot-timer pr. metrisk enhed × anmodede enheder
Forløbne timer = produktive timer / (udnyttelsesprocent / 100)
Fakturerede timer = max(forløbne timer, brugerens minimum af fakturerede timer)
Subtotal for regnekraft = fakturerede timer × systemets timegebyr i USD
Modelleret total = subtotal for regnekraft + eksplicit indtastede yderligere omkostninger i USD

Hvert scenarie bruger ét målt system og forudsætter, at det faktureres i tomgangstid. Faktureringsgulvet ændrer omkostningerne, ikke fuldførelsestiden. Yderligere omkostninger, der efterlades tomme, forbliver ukendte; der vises ingen modelleret total. Et deadline-estimat udelader kø, opstartsforsinkelser og kapacitetsbegrænsninger. Fuldstændige kontraktlige forpligtelser, ikke-indtastede gebyrer og udbyderens tilgængelighed forbliver ikke verificeret. Resultatet er hverken en fuld TCO eller et pristilbud.

Scenarie-JSON’en til download bevarer de præcise evidenssnapshots, kildetidsstempler og brugerens antagelser. Det er en rapport på et givet tidspunkt, ikke en garanti for aktuel gyldighed. Opdater evidensen før en beslutning. Scenarier gemmes ikke på en konto.

6. Skrivebeskyttet dataadgang

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

Grænser: 1–100 snapshots; standard 50. Ukendte, duplikerede eller fejlformaterede parametre afvises. Svarene indeholder oprindelige input, enheder, kilder, tidsstempler, revisioner, aktuel status og årsagskoder. Læsninger håndhæver offentlig synlighed, udelader gennemgangsaktører/-noter og eksponerer ikke den interne kørselslog. Afgrænsede svar markerer eksplicit afkortning.

Observations- og beregningstidspunkter

API-feltet effective_at registrerer tidspunktet for den oprindelige prisobservation. calculated_at registrerer, hvornår de gennemgåede input blev kombineret. En senere benchmark etablerer ikke økonomi på en tidligere prisdato; denne log udfylder ikke historisk ydeevne bagud.