Subskrypcja a płatność za token mają wyraźny punkt przecięcia

Subskrypcja staje się tańsza od płatności za token, gdy jej miesięczny koszt na użyteczną próbę spada poniżej kosztu mierzonego zużyciem potrzebnego do wykonania takiej samej zaakceptowanej pracy. Brzmi to oczywiście, lecz większość porównań używa liczby promptów jako jednostki. Liczba promptów jest prawie bezużyteczna. Zespoły płacą za zaakceptowane funkcje, a między promptem a zaakceptowaną funkcją pojawiają się ponowienia, rosnący kontekst, porzucone gałęzie i minimalna liczba stanowisk.

Właściwe obliczenie zaczyna się od jednej funkcji, a nie od jednej wiadomości. Oszacuj, ilu prób wymaga funkcja, jak zużycie tokenów zmienia się po każdym niepowodzeniu i jaka część prób pochłania płatną pojemność bez stworzenia kodu, który zachowasz. Następnie rozszerz model funkcji na miesiąc i uwzględnij rzeczywiste limity subskrypcji. Punkt przecięcia to zakres, a nie uniwersalny wskaźnik ponowień, ponieważ rozmiar funkcji i zasady zarządzania kontekstem mogą przesunąć go bardziej niż cena z cennika.

Liczy się zaakceptowana funkcja

Zaakceptowana funkcja to najmniejszy element pracy, który zespół uznałby za ukończony: ekran logowania połączony z API, webhook rozliczeniowy z testami albo formularz mobilny, który poprawnie zapisuje dane. Użyj granicy, którą Twój zespół już stosuje w planowaniu. Nie uznawaj atrakcyjnego pierwszego szkicu za zaakceptowany, jeśli programista nadal musi naprawić model danych lub przepisać testy.

Dla każdej funkcji zapisuj liczbę prób do akceptacji. Próba zaczyna się, gdy model otrzymuje dość kontekstu, aby zaproponować istotną implementację, i kończy się, gdy zespół ją akceptuje, odrzuca lub zmienia kierunek. Drobne pytania uzupełniające, na przykład o lokalizację pliku, można przypisać do otaczającej je próby. Konsekwencja jest ważniejsza od idealnej taksonomii.

Podstawowy koszt rozliczany według zużycia to:

metered_feature_cost = sum(attempt_input_tokens * input_rate
                         + attempt_output_tokens * output_rate
                         + tool_charges)

Użyj stawek, które naprawdę widzisz na fakturze. Jeśli wejście z cache, tokeny rozumowania, wejście obrazów lub wywołania narzędzi mają inne stawki, zachowaj je jako osobne składniki. Uśredniona cena tokena nadaje się do szybkiego szacunku dopiero wtedy, gdy obliczysz ją na podstawie własnej struktury użycia.

Strona subskrypcji wymaga tej samej granicy:

subscription_feature_cost = allocated_monthly_subscription_cost
                            / accepted_features_within_plan

To od razu ujawnia częsty błąd. Podzielenie kosztu planu przez wszystkie czaty sprawia, że subskrypcja wygląda tanio, ponieważ nieudane i błahe czaty zawyżają mianownik. Podzielenie rachunku za tokeny wyłącznie przez udane prompty sprawia, że rozliczenie według zużycia wygląda tanio, ponieważ niepowodzenia znikają. Obie strony muszą używać zaakceptowanych funkcji.

Śledź osobno czas poprawek wykonywanych przez ludzi. Należy on do szerszej decyzji o koszcie tworzenia produktu, lecz mieszanie wynagrodzenia programisty tylko z jedną stroną zniekształci porównanie cen. Najpierw porównaj wydatki na platformę dla równoważnego rezultatu. Potem dodaj koszt pracy, jeśli jedna opcja stale zmienia czas przeglądu lub napraw.

Wskaźnik ponowień nieliniowo zmienia liczbę prób

Wskaźnik ponowień musi oznaczać prawdopodobieństwo, że próba zakończy się niepowodzeniem i będzie potrzebna kolejna, a nie odsetek funkcji, które miały jakiekolwiek ponowienie. Te definicje prowadzą do innych prognoz. Jeśli każda próba ma niezależne prawdopodobieństwo niepowodzenia r, oczekiwana liczba prób przed sukcesem wynosi:

expected_attempts = 1 / (1 - r)

Wskaźnik ponowień 20% oznacza 1,25 oczekiwanej próby. Przy 50% są to 2 próby. Przy 80% - 5 prób. Krzywa staje się coraz bardziej stroma, ponieważ każde ponowienie może także zakończyć się niepowodzeniem. Obliczenie 1 + r uwzględnia najwyżej jedno ponowienie i mocno zaniża skalę chaotycznej pracy.

Niezależność to przybliżenie. Nieudane próby często skupiają się wokół niejednoznacznych wymagań, nieznanych frameworków lub złego wyboru architektonicznego, który pozostaje w kontekście. Do praktycznej prognozy oblicz liczbę prób bezpośrednio na podstawie próbki:

observed_attempts_per_feature = total_material_attempts / accepted_features
observed_retry_rate = (total_material_attempts - accepted_features)
                      / total_material_attempts

Jeśli 40 zaakceptowanych funkcji wymagało 68 istotnych prób, liczba prób na funkcję wynosi 1,7, a zaobserwowany wskaźnik ponowień to około 41%. Ten obserwowany stosunek już uwzględnia powtarzające się niepowodzenia i jest bezpieczniejszy niż odtwarzanie przebiegu pracy z pamięci.

Nie oznaczaj każdej poprawki jako niepowodzenia. Zaplanowana sekwencja, na przykład najpierw schemat, potem API, a na końcu interfejs, zawiera wiele udanych etapów. Policz ponowienie, gdy nowa próba zastępuje lub naprawia pracę, która powinna przejść kontrolę akceptacji. To rozróżnienie ma znaczenie: iteracja to metoda tworzenia, a ponowienie to poprawianie. Traktowanie ich tak samo w cenach karze za świadomy podział pracy.

W budżecie użyj przynajmniej dwóch zakresów ponowień. Typowe funkcje mogą być bliskie medianie zespołu, a migracje, nieznane integracje i nieprecyzyjne prośby założyciela należą do zakresu wysokiej liczby ponowień. Jedna średnia ukrywa ogon rozkładu, który często zużywa limit planu.

Wzrost kontekstu często kosztuje więcej niż samo ponowienie

Powtarzane próby rzadko mają taką samą liczbę tokenów. Pierwsza próba może zawierać zwięzłą specyfikację i kilka plików. Czwarta może obejmować pierwotną prośbę, wygenerowany kod, dane o błędach, nieudane testy, poprawki i więcej kontekstu repozytorium. Przy rozliczeniu według zużycia każde ponowne wejście może być rozliczane, chyba że dostawca stosuje niższą stawkę za wejście z cache.

Modeluj wzrost wejścia na podstawie zaobserwowanych liczników tokenów albo mnożnika:

input_tokens_on_attempt_n = initial_input_tokens * growth_factor^(n - 1)
output_tokens_on_attempt_n = initial_output_tokens * output_factor^(n - 1)

Załóżmy, że pierwsza próba używa 30 000 tokenów wejściowych i 4 000 tokenów wyjściowych. Jeśli wejście rośnie o 35% na próbę, a wyjście pozostaje bez zmian, czwarta próba zawiera około 73 800 tokenów wejściowych. Pięć podobnie wyglądających dymków czatu nie tworzy pięciu takich samych rachunków.

Wzrost wykładniczy przydaje się do testów warunków skrajnych, ale wiele narzędzi obcina, streszcza, zapisuje w cache lub selektywnie ponownie ładuje kontekst. Mierz faktyczne zachowanie używanego rozwiązania. Eksportuj dane o użyciu tokenów, jeśli są dostępne, lub zapisuj liczniki na poziomie żądań przez reprezentatywny tydzień. Jeśli interfejs ukrywa tokeny, oszacuj kontekst na podstawie rozmiaru plików i historii wiadomości, a potem przetestuj niski i wysoki mnożnik zamiast udawać, że szacunek jest precyzyjny.

Występuje też efekt gałęzi. Po dwóch nieudanych próbach zespół może otworzyć nową rozmowę, aby usunąć zanieczyszczony kontekst. Zmniejsza to powtarzane wejście, lecz dodaje tokeny przygotowania i może powodować utratę decyzji obecnych tylko na czacie. Modeluj reset jako nową pierwszą próbę plus stały koszt odtworzenia kontekstu:

reset_cost = repository_context + specification + accepted_decisions

Dzięki temu higiena kontekstu zyskuje cenę. Trzymanie wszystkich niepowodzeń w jednym wątku może kosztować więcej tokenów. Resetowanie po każdym niepowodzeniu może powtarzać mapę repozytorium i specyfikację. Ekonomiczny punkt resetu zależy od szybkości wzrostu wątku oraz tego, czy cache działa między rozmowami.

W planach subskrypcyjnych kontekst nadal ma znaczenie, nawet gdy na fakturze nie ma widocznej pozycji za tokeny. Duże konteksty mogą szybciej zużywać limity użycia, wywoływać ograniczanie przepustowości lub zmniejszać liczbę funkcji ukończonych w miesięcznym planie. Traktuj użycie w pakiecie jako pojemność, a nie nieskończoną liczbę darmowych tokenów.

Wyznacz punkt przecięcia jednym równaniem

Przejrzyste porównanie wykorzystuje miesięczną liczbę zaakceptowanych funkcji jako wspólny rezultat. Zdefiniuj te zmienne:

• S: całkowity miesięczny koszt subskrypcji, w tym wymagane stanowiska.
• F: zaakceptowane funkcje miesięcznie.
• A: oczekiwana liczba prób na zaakceptowaną funkcję.
• C(A): koszt tokenów i narzędzi rozliczany według zużycia dla tych prób, z uwzględnieniem wzrostu kontekstu.
• L: maksymalna liczba zaakceptowanych funkcji, którą subskrypcja może obsłużyć przed limitami lub opłatami za nadwyżkę.

W ramach pojemności zawartej w planie subskrypcja wygrywa, gdy:

S / F < C(A), provided F <= L

Równoważnie, miesięczny punkt przecięcia liczby funkcji wynosi:

F_crossover = S / C(A)

Jeśli zespół ukończy więcej niż F_crossover porównywalnych funkcji i zmieści się w pojemności planu, subskrypcja kosztuje mniej. Jeśli ukończy mniej, tańsze jest rozliczenie według zużycia. Gdy rozmiary funkcji się różnią, oblicz całkowity koszt rozliczany według zużycia dla rzeczywistej mieszanki zamiast mnożyć jedną średnią.

Aby wyznaczyć konkretnie wskaźnik ponowień, podstaw A = 1 / (1 - r) oraz funkcję kosztu dla rosnącego kontekstu. W prostym przypadku, gdy każda próba kosztuje tyle samo c, otrzymujesz:

S / F = c / (1 - r)
r_crossover = 1 - (c * F / S)

Ten skrót działa tylko wtedy, gdy próby kosztują w przybliżeniu tyle samo. Jeśli późniejsze próby niosą więcej kontekstu, oblicz C(A) dla rozważanych wskaźników ponowień i znajdź pierwszy wskaźnik, przy którym miesięczny koszt rozliczany według zużycia przekracza S. Mały arkusz kalkulacyjny jest czytelniejszy niż wymuszanie równania w postaci zamkniętej na wielopoziomowym cache i limitach planu.

Użyj tabeli ze wskaźnikami ponowień w wierszach i miesięczną liczbą funkcji w kolumnach. Każda komórka powinna pokazywać metered_monthly_cost - subscription_monthly_cost. Wartość ujemna oznacza, że rozliczenie według zużycia jest tańsze, dodatnia - że tańsza jest subskrypcja. Dodaj drugi znacznik dla naruszeń pojemności. Korzystna finansowo komórka, która przekracza limit planu, nie pokazuje użytecznego punktu przecięcia.

Przykładowe porównanie ujawnia ukryte zmienne

Rozważ czteroosobowy zespół produktowy oceniający subskrypcję w cenie 120 USD za stanowisko miesięcznie. Plan kosztuje więc 480 USD miesięcznie. To przykładowa cena, a nie informacja o jakiejkolwiek nazwanej usłudze. Zespół spodziewa się 24 zaakceptowanych funkcji średniej wielkości w miesiącu.

Stawki rozliczane według zużycia, po uwzględnieniu rzeczywistej mieszanki wejścia, wejścia z cache i wyjścia, dają zaobserwowane 0,000006 USD za token wejściowy i 0,000018 USD za token wyjściowy. Opłaty za narzędzia są pominięte, ponieważ zespół nie używa płatnych narzędzi w tym procesie. Pierwsza próba średnio zawiera 40 000 tokenów wejściowych i 5 000 wyjściowych. Wejście rośnie o 30% przy każdym ponowieniu, a wyjście pozostaje na poziomie 5 000 tokenów.

Przy zerowej liczbie ponowień jedna funkcja kosztuje:

40,000 * $0.000006 + 5,000 * $0.000018 = $0.33

To zaledwie 7,92 USD za 24 funkcje, więc rozliczenie według zużycia wygrywa bez trudu. Przy niezależnym wskaźniku ponowień wynoszącym 50% oczekiwana liczba prób wynosi dwie. Przybliżenie dwóch prób na funkcję daje:

attempt 1: 40,000 input + 5,000 output = $0.33
attempt 2: 52,000 input + 5,000 output = $0.402
feature total: $0.732
monthly total: $17.568

Subskrypcja nadal przegrywa z dużą różnicą. Nawet pięć prób z rosnącym kontekstem kosztuje w tym przykładzie około 2,42 USD na funkcję, czyli około 58 USD miesięcznie. Sam wysoki wskaźnik ponowień nie czyni planu za 480 USD opłacalnym, gdy początkowa funkcja jest mała, a stawki za tokeny niskie.

Teraz zmień rozmiar funkcji zamiast wskaźnika ponowień. Refaktoryzacja obejmująca całe repozytorium zaczyna się od 900 000 tokenów wejściowych i 35 000 tokenów wyjściowych, a wejście rośnie o 25%. Jej pierwsza próba kosztuje 6,03 USD przy tych samych stawkach. Pięć prób kosztuje około 41,88 USD. Przy 24 takich funkcjach rozliczenie według zużycia sięga około 1 005 USD. Subskrypcja może wygrać, ale tylko jeśli jej pojemność obsłuży takie obciążenie.

Skrót zakładający równe koszty prób daje przybliżony próg przed uwzględnieniem wzrostu kontekstu. Dla $S = 480, $F = 24 i kosztu pierwszej próby $c = 6.03:

r_crossover = 1 - (6.03 * 24 / 480)
            = 0.6985

Przybliżony punkt przecięcia to wskaźnik ponowień 69,85%. Rosnący kontekst obniża ten próg, ponieważ późniejsze próby kosztują więcej niż 6,03 USD. Tabela scenariuszy umieszcza bardziej realistyczny punkt przecięcia między testowanymi wartościami, zamiast udawać precyzję do wielu miejsc po przecinku.

Ten przykład wyjaśnia także, dlaczego próg ponowień innej osoby nie jest uniwersalny. Zmiana początkowego kontekstu z 40 000 na 900 000 tokenów wpływa na decyzję znacznie bardziej niż niewielka zmiana wskaźnika niepowodzeń. Skopiuj metodę, a nie procent.

Stanowiska mogą zniwelować korzystne porównanie tokenów

Ceny subskrypcji zwykle wiążą koszt z dostępem, a rozliczenie według zużycia - z konsumpcją. Dziesięcioosobowy zespół, który okazjonalnie korzysta z promptów, może potrzebować dziesięciu stanowisk, nawet jeśli dwie osoby generują większość użycia. Ta różnica może przesunąć punkt przecięcia poza każdy realistyczny wskaźnik ponowień.

Oblicz S na podstawie rozliczanych stanowisk, a nie aktywnych użytkowników dziennych:

S = required_seats * seat_price + fixed_plan_fees

Następnie przypisz wynik do pracy, która rzeczywiście wymaga subskrypcji. Jeśli projektanci, osoby produktowe i programiści potrzebują bezpośredniego dostępu do przeglądu lub pracy z promptami, uwzględnij ich. Jeśli interesariusze jedynie czytają wyeksportowane rezultaty, a warunki dopuszczają taki proces, nie wymyślaj dla nich stanowisk. O liczbie decydują umowa i faktyczny sposób współpracy.

Wykorzystanie stanowisk zasługuje na własny wskaźnik:

seat_utilization = active_prompting_days / available_workdays

Niskie wykorzystanie nie oznacza automatycznie, że stanowisko jest marnotrawstwem. Kierownik wydań może używać narzędzia tylko w tygodniu wdrożenia, a mimo to uniknąć kosztownego przekazania pracy. Plan wymagający wielu rzadko używanych stanowisk należy jednak porównać z kontem rozliczanym według zużycia z odpowiednią kontrolą dostępu, a nie z rachunkiem za tokeny dwóch najaktywniejszych użytkowników.

Rozrost zespołu tworzy funkcję skokową. Piąta zatrudniona osoba może dodać pełną opłatę za stanowisko, wnosząc jednocześnie tylko część miesięcznego wyniku w funkcjach. Koszt rozliczany według zużycia rośnie wraz z jej faktycznym użyciem. Uruchom model dla dzisiejszej liczby osób i liczby osób oczekiwanej w okresie zobowiązania.

Roczne rabaty wymagają tego samego podejścia. Przelicz całą kwotę zobowiązania na miesięczny odpowiednik, a potem uwzględnij miesiące z niskim użyciem. Nie porównuj miesięcznej kwoty po rabacie rocznym z rachunkiem za tokeny z miesiąca największego obciążenia. Porównaj koszt roczny z rocznym obciążeniem, w tym świętami, lukami rekrutacyjnymi i spokojnymi okresami utrzymania.

Limity użycia tworzą drugi punkt przecięcia

Subskrypcja może wyglądać taniej na papierze, a mimo to nie obsłużyć obciążenia, ponieważ pojemność w pakiecie jest ograniczona, spowalniana lub regulowana zasadą dozwolonego użycia. Pierwszy punkt przecięcia jest finansowy. Drugi jest operacyjny: czy plan może ukończyć modelowane próby w wymaganym czasie.

Przedstaw limit planu w jednostce egzekwowanej przez dostawcę. Mogą to być wiadomości, ważone żądania, kredyty obliczeniowe, tokeny lub kroczące okno czasowe. Przelicz ten limit na zaakceptowane funkcje przy użyciu tego samego rozkładu prób:

feature_capacity = usable_monthly_units
                   / expected_units_per_accepted_feature

Używaj dostępnych jednostek, a nie reklamowanego maksimum. Zarezerwuj pojemność na analizę, planowanie i okazjonalny ciężki łańcuch ponowień. Jeśli wszystkie zaplanowane funkcje mieszczą się tylko wtedy, gdy każda próba zachowuje się jak mediana, plan już jest zbyt napięty.

Po przekroczeniu limitu przez zespół zwykle dzieje się jedna z czterech rzeczy: praca czeka na reset, żądania zwalniają, zaczynają się opłaty za nadwyżkę albo zespół kupuje wyższy plan. Umieść faktyczną konsekwencję w modelu. Plan doliczający rozliczaną według zużycia nadwyżkę ma taki miesięczny koszt:

hybrid_cost = subscription_cost + max(0, usage - included_usage) * overage_rate

Twardy limit wymaga innej decyzji. Jeśli blokuje dostarczenie pracy, plan jest niewykonalny, nawet gdy jego nominalny koszt jest niższy. Nie przypisuj mu wyimaginowanej wartości pieniężnej i nie uznawaj sprawy za rozwiązaną. Pokaż lukę pojemności obok ceny.

Okna użycia są równie ważne jak sumy miesięczne. Czterdzieści prób wymagających wielu ponowień podczas jednego popołudnia wydania może uderzyć w krótki limit kroczący, mimo że reszta miesiąca jest spokojna. Przetestuj najbardziej obciążony dzień i tydzień, a nie wyłącznie miesięczną średnią.

Koder.ai oferuje plany free, pro, business i enterprise, więc istotne jest porównanie planu, którego stanowiska i pojemność odpowiadają zespołowi, a nie najtańszego planu widocznego w cenniku. Tryb planowania, migawki i wycofywanie zmian mogą także zmienić zaobserwowaną liczbę ponowień, dlatego zespół powinien zmierzyć pilotaż zamiast przenosić wskaźnik ponowień z innego procesu pracy.

Mierz pilotaż bez oszukiwania samego siebie

Przydatny pilotaż zbiera wystarczająco dużo szczegółów, aby odtworzyć decyzję cenową. Dwa tygodnie mogą wystarczyć stabilnemu zespołowi, ale próbka musi obejmować zwykłą pracę i przynajmniej kilka trudnych funkcji. Jeśli okres zawiera wyłącznie dopracowane zadania demonstracyjne, wynik zaniży zarówno kontekst, jak i liczbę ponowień.

Zapisuj jeden wiersz dla każdej istotnej próby z tymi polami:

• identyfikator funkcji i przedział jej wielkości;
• numer próby oraz wynik: zaakceptowana lub odrzucona;
• tokeny wejściowe, wejściowe z cache i wyjściowe albo jednostki planu;
• reset kontekstu, opłaty za narzędzia i czas trwania okna pracy;
• stanowisko lub osoba rozpoczynająca próbę.

Zachowaj stabilny test akceptacji dla obu opcji. Jeśli w pilotażu subskrypcji funkcja jest akceptowana po krótkim spojrzeniu na wygląd, a proces rozliczany według zużycia wymaga przejścia testów, rezultaty nie są równoważne. Zapisz regułę akceptacji przed pilotażem i stosuj ją do obu opcji.

Rozdziel przyczyny ponowień. Oznacz zmianę wymagań, błąd modelu, zanieczyszczenie kontekstu, awarię narzędzia i błąd użytkownika. Tylko niektóre przyczyny zmienią się pod wpływem innego planu cenowego lub interfejsu. Wymaganie zmieniane trzy razy zużywa pojemność wszędzie. Proces z migawkami i wycofywaniem zmian może zmniejszyć koszt złej gałęzi, ale nie sprawia, że niejasne wymagania są darmowe.

Na końcu oblicz trzy widoki: medianę funkcji, funkcję z wysoką liczbą ponowień oraz rzeczywistą miesięczną mieszankę. Mediana pokazuje ekonomię rutynowej pracy. Wysoki zakres sprawdza pojemność. Mieszanka decyduje o fakturze. Raportuj wszystkie trzy, ponieważ pojedyncza średnia może opisywać miesiąc, który nigdy się nie zdarza.

Wykonaj analizę wrażliwości dla niepewnych danych wejściowych. Zwiększaj kolejno liczbę funkcji, wskaźnik ponowień, wzrost kontekstu i liczbę stanowisk. Jeśli zmiana o 10% odwraca wybór, wynegocjuj krótsze zobowiązanie albo pozostań przy rozliczeniu według zużycia, dopóki zespół nie zbierze więcej danych. Jeśli każdy wiarygodny scenariusz wskazuje tę samą opcję, decyzja jest stabilna.

Wybieraj plan według kształtu obciążenia, a nie przekonań

Płatność za token zwykle lepiej sprawdza się przy sporadycznym użyciu, małych kontekstach, zespołach eksperymentujących i pracy, która może zostać wstrzymana bez konsekwencji. Daje też czytelną cenę krańcową: nieużywane konto generuje niewielki albo zerowy koszt inferencji. Minusem jest narażenie na długie konteksty i powtarzające się niepowodzenia, zwłaszcza gdy kilku agentów lub narzędzi dodaje ukryte żądania.

Subskrypcja pasuje do stałego tempa pracy, kosztownych funkcji i zespołów, które wykorzystają większość stanowisk bez przekraczania pojemności zawartej w planie. Przewidywalność ma wartość, lecz nie ukrywaj tej wartości pod nazwą oszczędności na tokenach. Jeśli subskrypcja kosztuje o 200 USD więcej, ale usuwa zmienność faktur, której dział finansów nie akceptuje, zapisz 200 USD jako cenę przewidywalności.

Popularna rada, by zmienić plan, gdy ponowienia wydają się częste, jest błędna. Ludzie pamiętają bolesną funkcję wymagającą pięciu prób, a zapominają o tuzinie tanich sukcesów. Faktura waży tokeny, a pamięć - frustrację. Miesiąc danych na poziomie prób rozwiązuje tę rozbieżność.

Nie wybieraj subskrypcji wyłącznie dlatego, że reklamuje dostęp do nowszych modeli. Wybór modelu wpływa na koszt tylko przez pracę, którą akceptuje, tokeny, które zużywa, i reguły pojemności, które uruchamia. Bardziej zdolny model może potrzebować mniej prób, lecz kosztować więcej za token. Tańszy model może dobrze radzić sobie z drobnymi zmianami interfejsu, a tracić czas przy przekrojowej migracji danych. Podziel pilotaż według przedziału funkcji i pozwól każdej opcji używać modelu, który kompetentny operator rzeczywiście by wybrał.

Ta sama zasada dotyczy liczby agentów. Widoczny dla użytkownika prompt może uruchomić w tle agentów planowania, implementacji, przeglądu i napraw. Rozliczenie według zużycia może liczyć każde żądanie, a subskrypcja może przeliczać pracę na ważone jednostki użycia. Nie porównuj po jednej widocznej wiadomości po każdej stronie. Porównaj całą zaakceptowaną funkcję i uchwyć każdą jednostkę zużycia, którą pokazuje faktura lub plan.

Niepewność potrzebuje pozycji w budżecie, a nie pewnego siebie zgadywania. Dla każdego parametru zachowaj wartość niską, oczekiwaną i wysoką. Wartość oczekiwana powinna wynikać z pilotażu. Niska i wysoka powinny odzwierciedlać zaobserwowaną zmienność, a nie arbitralne procenty. Oblicz wszystkie trzy kombinacje, a potem ustal, który parametr zmienia decyzję. Jeśli wzrost kontekstu odwraca odpowiedź, a liczba stanowisk nie, lepsza telemetria kontekstu jest więcej warta niż kolejny tydzień dyskusji o zatrudnieniu.

Długość zobowiązania zmienia akceptowalny margines. Plan miesięczny można testować blisko oszacowanego punktu przecięcia, ponieważ zespół może szybko z niego zrezygnować. Umowa roczna potrzebuje zapasu na zmiany obciążenia. Ustal wymagany margines oszczędności przed podpisaniem, na przykład kwotę, która pokryłaby spokojniejszy kwartał albo dwa nieobsadzone stanowiska. Ten margines to decyzja biznesowa, nie część matematycznego punktu przecięcia, dlatego pokaż go osobno.

Podatek, przewalutowanie i kredyty na zobowiązane wydatki należą do warstwy faktury. Stosuj je konsekwentnie po obliczeniu surowego zużycia usługi. Kredyty, które wygasają, mogą obniżyć koszt tylko wtedy, gdy zespół prawdopodobnie wykorzysta je przed wygaśnięciem. Duże saldo niewykorzystanych kredytów nie jest oszczędnością. To opłacona z góry pojemność, której zespół nie zamienił w zaakceptowaną pracę.

Na koniec ustal, kto odpowiada za pomiar. Jeśli nikt nie sprawdza rzeczywistego użycia względem prognozy, trafny model punktu przecięcia traci aktualność, gdy zmieniają się rozmiar funkcji, modele, stawki i zatrudnienie. Przeglądaj go, gdy zmienia się cena, zespół dodaje stanowiska lub zaobserwowana liczba prób na funkcję istotnie się zmienia. To niewielkie zadanie operacyjne: zaktualizuj dane wejściowe, zachowaj poprzedni scenariusz i zapisz, dlaczego wybór nadal obowiązuje albo wymaga zmiany.

Przed zatwierdzeniem przeczytaj założenia jak obietnice operacyjne. Prognoza 30 zaakceptowanych funkcji oznacza, że produkt ma dość sprecyzowanej pracy, osoby przeglądające mogą ją ocenić, a plan może ją dostarczyć w godzinach pracy zespołu. Jeśli pojemność przeglądu ogranicza wynik do 18 funkcji, użycie liczby 30 sprawia, że subskrypcja wygląda taniej, nie tworząc większej liczby zaakceptowanych funkcji. Mianownik musi odzwierciedlać cały system dostarczania, choć porównanie kosztów obejmuje wyłącznie platformę.

Przetestuj też opcję mieszanego rozliczenia, jeśli dostawca na to pozwala. Subskrypcja dla dwóch intensywnych użytkowników plus dostęp rozliczany według zużycia dla okazjonalnych użytkowników może przewyższyć zarówno plan ze stanowiskami dla wszystkich, jak i plan całkowicie rozliczany według zużycia. Oblicz każdą grupę osobno, a potem dodaj koszty. Nie uśredniaj intensywnych i lekkich użytkowników przed naliczeniem opłat za stanowiska, ponieważ średnia nie opisuje nikogo i może ukryć możliwe do uniknięcia stanowisko.

Dział zakupów czasem prosi o jeden próg ponowień zapewniający rentowność. Podaj zakres powiązany z nazwanymi założeniami: na przykład od 55% do 65%, jeśli miesięczna liczba zaakceptowanych funkcji pozostaje między dwiema zaobserwowanymi wartościami, a kontekst rośnie w zmierzonym przedziale. Podaj także wskaźnik, przy którym zawodzi pojemność. Ta odpowiedź jest mniej schludna niż jeden procent, ale znacznie użyteczniejsza, gdy miesiąc wydania różni się od miesiąca utrzymania.

Nie uwzględniaj kosztów utopionych w decyzji o odnowieniu. Pieniądze już przeznaczone na subskrypcję nie powinny sprawiać, że następne żądanie rozliczane według zużycia wygląda na darmowe, gdy zespół decyduje, co kupić na kolejny okres. W trakcie obecnego opłaconego okresu niewykorzystana pojemność zawarta w pakiecie może jednak mieć zerowy krańcowy koszt gotówkowy. Oznacz, czy model wspiera natychmiastową decyzję o kierowaniu pracy, czy decyzję o przyszłej umowie, ponieważ te pytania używają innych granic kosztu.

Bezpieczeństwo, lokalizacja danych, eksport źródeł, wdrażanie i wycofywanie zmian mogą zdecydować, które opcje kwalifikują się do wyboru, zanim obliczysz cenę. Traktuj te wymagania jak filtry, a nie wymyślone korekty pieniężne. Usuń opcję, która nie spełnia obowiązkowego wymagania. Porównuj koszt wyłącznie między pozostałymi wyborami. Dzięki temu niska wycena tokenów nie przeważy ograniczenia, z którego zespół nie może zrezygnować.

Dokumentuj także odrzucone i porzucone funkcje. Opłaty rozliczane według zużycia pozostają, nawet gdy funkcja zostaje anulowana, a subskrypcja zużywa pojemność, której nie da się odzyskać. Przypisz te koszty do kategorii porzucenia zamiast po cichu rozkładać je na udane funkcje. Następnie wykonaj drugi widok, który przypisuje porzucenia do obszaru produktu, który je spowodował. To pokaże, czy problem cenowy nie jest w rzeczywistości problemem ze specyfikacją.

Zaokrąglaj pieniądze wyłącznie na potrzeby prezentacji. W obliczeniach zachowaj pełną liczbę tokenów i precyzję stawek, zwłaszcza gdy wejście z cache i bez cache ma inne ceny. Wskaźnik ponowień w punkcie przecięcia raportuj jednak jako zakres albo pełny procent. Wynik taki jak 62,437% sugeruje wiedzę, której dane wejściowe nie uzasadniają.

Podejmij decyzję, zapisując obok siebie dwie liczby: koszt na zaakceptowaną funkcję oraz pojemność zaakceptowanych funkcji w najbardziej intensywnym oknie użycia. Pierwsza pokazuje, gdzie finansowo przecinają się subskrypcja i płatność za token. Druga mówi, czy ten punkt przecięcia jest dostępny w praktyce. Jeśli brakuje którejkolwiek z tych liczb, arkusz opisuje cenę, a nie rzeczywiste obciążenie produkcyjne.