Porównywalna praca. Jawne założenia.
KCI Economics v1 to informacyjne, odtwarzalne przekształcenie sprawdzonego benchmarku i zgodnej oryginalnej ceny mocy obliczeniowej w USD. Nie zmienia metodologii fixingów KCI ani uprawnień publikacyjnych.
1. Wersjonowany kontrakt porównawczy
Model i jego dokładna rewizja, precyzja, kwantyzacja, środowisko uruchomieniowe i jego wersja, protokół benchmarku i jego wersja oraz docelowa jakość muszą być zgodne. Inferencja ustala ponadto długości wejścia/wyjścia, rozmiar partii, współbieżność, buforowanie, podstawę tokenów i ograniczenie opóźnienia. Trening ustala zbiór danych/rewizję, definicję pracy i kryterium ukończenia.
Model GPU, liczba GPU, sprzęt, połączenia i równoległość mogą się różnić między wynikami w ramach tego kontraktu, ale każdy wynik musi zachować swoją zmierzoną konfigurację. Powiązanie ceny w V1 obsługuje tylko jeden węzeł. Nie wnioskujemy o skalowaniu wydajności sprzętu.
2. Jedna formuła, jawne jednostki
Dla godzinowego kosztu całego systemu C i zgodnej łącznej przepustowości T w tokenach/sekundę:
USD za 1M tokenów = C × 1,000,000 / (T × 3,600)
Cena godzinowa za GPU jest mnożona raz przez zmierzoną liczbę GPU. Cena godzinowa za całą instancję jest już ceną systemu. Przepustowość na GPU jest mnożona raz przez zmierzoną liczbę GPU; łączna przepustowość jest używana bezpośrednio. Kontrakt porównawczy określa tokeny wejściowe, wyjściowe lub łączne.
Dla treningu: koszt zdefiniowanego przebiegu = godzinowy koszt systemu × zmierzone godziny przebiegu. GPU-hours/przebieg dzieli się przez zmierzoną liczbę GPU, aby oszacować czas rzeczywisty w godzinach, wyraźnie oznaczony jako szacunek księgowy. Scenariusze powtarzanych przebiegów zakładają kolejne identyczne przebiegi.
3. Zgodność cen i koszty
Założyciel musi poświadczyć, że publiczna obserwacja ceny obejmuje dokładnie zmierzoną konfigurację i wystawioną w cenniku opłatę za moc obliczeniową. Obsługiwane są oryginalne jednostki USD GPU/godzina i instancja-godzina. Inne waluty i jednostki pozostają niedostępne. Publiczny zagregowany fixing KCI nie może zastąpić ceny systemu możliwego do kupienia.
Uwzględniana jest wyłącznie wystawiona w cenniku opłata za moc obliczeniową. Konfiguracja, osobno rozliczane CPU/RAM, pamięć masowa, sieć/egress, podatki i wsparcie są wyłączone. Bazowe migawki nie modelują minimalnych zobowiązań, jednostek rozliczeniowych, strat wykorzystania ani dostępności; faktyczne wydatki mogą być wyższe. Nie są to ceny tokenów API ani szacunki całkowitego kosztu.
4. Aktualność, przegląd i rewizje
Obserwacje benchmarków zachowują dotychczasowy 180-dniowy limit aktualności danych o wydajności. Economics v1 stosuje 30-dniowy limit dla cen, aby nie przedstawiać starych obserwacji z cenników jako bieżących kosztów. To okna kwalifikowalności, a nie wskaźniki pewności. Klasy źródeł to: deklarowane przez dostawcę, niezależne lub wewnętrzne.
Import lub przechwycenie tworzy wersję roboczą; zatwierdza ją jawny przegląd. Wycofanie i zatwierdzone zastąpienie blokują nowe obliczenia. Niezmienne migawki zachowują oryginalne dane wejściowe, daty pomiaru, daty pozyskania, rewizje benchmarków, wersje grup, wersję formuły i czas obliczenia. Cofnięcie publikacji źródła może usunąć dostęp publiczny bez usuwania przechowywanego rekordu wewnętrznego.
5. Historia i narzędzia decyzyjne
Historia ekonomii to rejestr informacyjny. Nie jest poziomem indeksu i nie jest automatycznie wstawiana do historii fixingów KCI. Korekty odwołują się do wcześniejszych migawek. Zmiany konfiguracji, wersji kontraktu, rewizji benchmarku lub formuły wyznaczają oddzielne segmenty. Nie generujemy uzupełnień historycznych wstecz.
Scenariusze wolumenu użytkownika zachowują wybrane warunki obciążenia. Czas jest szacowany na podstawie stałej zmierzonej przepustowości lub powtarzanych identycznych przebiegów treningowych. Skorzystaj z linku do oferty, aby sprawdzić szczegóły handlowe, lub otwórz Workload Economics, aby planować z dodatkowymi założeniami. Nie są wykonywane żadne rezerwacje ani działania zakupowe.
Scenariusze kosztów i terminów
Obszar decyzyjny porównuje dwie jawnie wybrane migawki w ramach tego samego kontraktu, formuły, jednostek i zakresu kosztów. Różne warunki handlowe i klasy źródeł są ujawniane. Wygasłe, wycofane lub skorygowane dane wejściowe nie mogą stanowić podstawy nowego porównania.
Godziny produktywne = godziny migawki na jednostkę miary × żądane jednostki Czas rzeczywisty w godzinach = godziny produktywne / (procent wykorzystania / 100) Godziny rozliczane = max(czas rzeczywisty w godzinach, minimalne godziny rozliczane użytkownika) Suma częściowa mocy obliczeniowej = godziny rozliczane × godzinowa opłata systemu w USD Modelowana suma = suma częściowa mocy obliczeniowej + jawnie wprowadzone dodatkowe koszty w USD
Każdy scenariusz wykorzystuje jeden zmierzony system i zakłada, że jest on rozliczany również w czasie bezczynności. Minimalne rozliczenie zmienia koszt, a nie czas ukończenia. Niewypełnione dodatkowe koszty pozostają nieznane; modelowana suma nie jest wtedy pokazywana. Szacunek terminu nie uwzględnia kolejek, opóźnień uruchomienia ani ograniczeń dostępnej mocy. Pełne zobowiązania umowne, niewprowadzone opłaty i dostępność u dostawcy pozostają niezweryfikowane. Wynik nie jest ani pełnym TCO, ani wyceną.
Plik JSON scenariusza do pobrania zachowuje dokładne migawki dowodów, znaczniki czasu źródeł i założenia użytkownika. To raport na określony moment, a nie gwarancja bieżącej ważności. Przed podjęciem decyzji odśwież dowody. Scenariusze nie są zapisywane na koncie.
6. Dostęp do danych tylko do odczytu
GET /api/index/economics?limit=50&format=json GET /api/index/economics?group=GROUP_UUID&format=csv
Limity: 1–100 migawek; domyślnie 50. Nieznane, zduplikowane lub nieprawidłowo sformatowane parametry są odrzucane. Odpowiedzi zawierają oryginalne dane wejściowe, jednostki, źródła, znaczniki czasu, rewizje, bieżący status i kody przyczyn. Odczyty egzekwują widoczność publiczną, wykluczają osoby i notatki z przeglądu i nie ujawniają wewnętrznego rejestru obliczeń. Ograniczone odpowiedzi wyraźnie sygnalizują obcięcie.
Czas obserwacji i obliczenia
Pole API effective_at zapisuje czas obserwacji oryginalnej ceny. calculated_at zapisuje, kiedy połączono sprawdzone dane wejściowe. Późniejszy benchmark nie ustala ekonomii dla wcześniejszej daty ceny; ten rejestr nie uzupełnia wstecz historycznej wydajności.