Travail comparable. Hypothèses explicites.

1. Un contrat de comparaison versionné

Le modèle et sa révision exacte, la précision, la quantification, le runtime et sa version, le protocole de benchmark et sa version, ainsi que l’objectif de qualité doivent correspondre. L’inférence fixe également les longueurs d’entrée/sortie, la taille de lot, la concurrence, la mise en cache, la base des tokens et la contrainte de latence. L’entraînement fixe le jeu de données et sa révision, la définition du travail et le critère d’achèvement.

Le modèle de GPU, le nombre de GPU, le matériel, l’interconnexion et le parallélisme peuvent varier d’un résultat à l’autre au sein de ce contrat, mais chaque résultat doit conserver sa configuration mesurée. Le rattachement du prix en v1 ne prend en charge qu’un seul nœud. Aucune mise à l’échelle des performances matérielles n’est déduite.

2. Une formule, des unités explicites

Pour un coût horaire C du système complet et un débit agrégé compatible T en tokens/seconde :

USD par 1M de tokens = C × 1,000,000 / (T × 3,600)

Un prix horaire par GPU est multiplié une seule fois par le nombre de GPU mesuré. Un prix horaire pour l’instance entière est déjà un prix de système. Le débit par GPU est multiplié une seule fois par le nombre de GPU mesuré ; le débit agrégé est utilisé tel quel. Le contrat de comparaison précise s’il s’agit des tokens d’entrée, des tokens de sortie ou du total des tokens.

Pour l’entraînement : coût par exécution définie = coût horaire du système × heures d’exécution mesurées. Le nombre de GPU-hours par exécution est divisé par le nombre de GPU mesuré afin d’estimer les heures écoulées, expressément présentées comme une estimation comptable. Les scénarios à exécutions répétées supposent des exécutions identiques successives.

3. Compatibilité des prix et coûts

Un fondateur doit attester que l’observation de prix publique couvre exactement la configuration mesurée et le tarif catalogue de la capacité de calcul. Les unités d’origine en USD par GPU/heure et par heure d’instance sont prises en charge. Les autres devises et unités restent indisponibles. Un fixing agrégé KCI public ne peut pas se substituer au prix d’un système achetable.

Seul le tarif catalogue de la capacité de calcul est inclus. Sont exclus : les frais de mise en service, le CPU/RAM facturé séparément, le stockage, le réseau/egress, les taxes et le support. Les instantanés de base ne modélisent ni les minimums d’engagement, ni les incréments de facturation, ni les pertes d’utilisation, ni la disponibilité ; les dépenses réelles peuvent être plus élevées. Il ne s’agit ni de prix de tokens d’API ni d’estimations du coût total.

4. Fraîcheur, examen et révisions

Les observations de benchmark conservent le plafond de fraîcheur des performances existant, fixé à 180 jours. Economics v1 applique un plafond de 30 jours aux prix, afin d’éviter de présenter d’anciennes observations de prix catalogue comme des coûts actuels. Ce sont des fenêtres d’éligibilité, et non des scores de confiance. Les classes de source sont : déclarée par le fournisseur, indépendante ou interne.

L’importation ou l’acquisition crée un brouillon ; un examen explicite l’approuve. Le retrait et le remplacement approuvé bloquent tout nouveau calcul. Les instantanés immuables conservent les entrées d’origine, les dates de mesure, les dates d’acquisition, les révisions du benchmark, les versions des groupes, la version de la formule et le moment du calcul. La dépublication d’une source peut supprimer l’accès public sans effacer l’enregistrement interne conservé.

5. Historique et outils de décision

L’historique des Economics est un registre informatif. Ce n’est pas un niveau de l’Index et il n’est pas automatiquement intégré à l’historique des fixings KCI. Les corrections renvoient aux instantanés antérieurs. Les changements de configuration, de version du contrat, de révision du benchmark ou de formule définissent des segments distincts. Aucune reconstitution rétroactive de l’historique n’est générée.

Les scénarios de volume de l’utilisateur conservent les conditions de la charge de travail sélectionnée. Le temps est estimé à partir du débit mesuré soutenu ou d’exécutions d’entraînement identiques répétées. Suivez le lien de l’offre pour examiner les détails commerciaux ou ouvrez Workload Economics afin de planifier avec des hypothèses supplémentaires. Aucune action de réservation ou d’approvisionnement n’est effectuée.

Scénarios de coût et d’échéance

L’espace de travail décisionnel compare deux instantanés sélectionnés explicitement, selon le même contrat, la même formule, les mêmes unités et la même couverture des coûts. Les conditions commerciales et les classes de source différentes sont indiquées. Les entrées expirées, retirées ou corrigées ne peuvent pas servir de base à une nouvelle comparaison.

Heures productives = heures de l’instantané par unité de mesure × unités demandées
Heures écoulées = heures productives / (pourcentage d’utilisation / 100)
Heures facturées = max(heures écoulées, heures minimales facturées définies par l’utilisateur)
Sous-total de la capacité de calcul = heures facturées × coût horaire du système en USD
Total modélisé = sous-total de la capacité de calcul + coûts supplémentaires en USD saisis explicitement

Chaque scénario utilise un seul système mesuré et suppose qu’il est facturé y compris pendant les périodes d’inactivité. Le minimum de facturation modifie le coût, pas le délai d’achèvement. Les coûts supplémentaires laissés vides restent inconnus ; aucun total modélisé n’est affiché. Une estimation de l’échéance exclut les files d’attente, les délais de démarrage et les contraintes de capacité. L’ensemble des obligations contractuelles, les frais non saisis et la disponibilité des fournisseurs restent non vérifiés. Le résultat n’est ni un TCO complet ni un devis.

Le JSON du scénario téléchargeable conserve les instantanés exacts des preuves, les horodatages des sources et les hypothèses de l’utilisateur. Il s’agit d’un rapport à un instant donné, et non d’une garantie de validité actuelle. Actualisez les preuves avant toute décision. Les scénarios ne sont pas enregistrés dans un compte.

6. Accès aux données en lecture seule

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

Limites : 1–100 instantanés ; 50 par défaut. Les paramètres inconnus, en double ou mal formés sont rejetés. Les réponses incluent les entrées d’origine, les unités, les sources, les horodatages, les révisions, le statut actuel et les codes de motif. Les lectures appliquent la visibilité publique, excluent les auteurs et les notes d’examen, et n’exposent pas le registre interne des exécutions. Les réponses bornées signalent explicitement la troncature.

Moments d’observation et de calcul

Le champ effective_at de l’API enregistre le moment de l’observation du prix d’origine. calculated_at enregistre le moment où les entrées examinées ont été combinées. Un benchmark postérieur n’établit pas les Economics à une date de prix antérieure ; ce registre ne reconstitue pas rétroactivement les performances historiques.