Liczba, przez którą AI wygląda na darmowe
Wyceń jedną pracę na dwa sposoby. Zgłoszenie do wsparcia wstępnie sklasyfikowane przez model - przeczytane, sklasyfikowane, skierowane dalej, z wygenerowanym potwierdzeniem - zużywa około 500 tokenów wejściowych i 50 wyjściowych, co na Haiku 4.5 według opublikowanych stawek daje $0.00075. To samo zgłoszenie obsłużone przez człowieka przy koszcie całkowitym $22 za godzinę i trzydziestu zgłoszeniach na godzinę kosztuje $0.73. To różnica około 978 razy, a każda liczba w niej to założenie, które możesz zmienić: zapłać $30 za godzinę, obsłuż 20 zgłoszeń, użyj większego modelu - różnica i tak pozostaje szeroka na trzy rzędy wielkości.
| Zadanie | Koszt / zadanie |
|---|---|
| AI · Haiku 4.5 | $0,00075 |
| Człowiek | $0,73 |
| Ludzie vs AI | ~978× |
Ile kosztuje jedno zadanie
Klasyfikacja zgłoszeń, model · skala logarytmiczna, każda linia siatki to 10×
Model, nie pomiar: klasyfikacja na Haiku 4.5 według opublikowanych stawek (500 tokenów wejściowych po $1 / 1M, 50 wyjściowych po $5 / 1M = $0.00075) wobec człowieka przy koszcie całkowitym $22 za godzinę obsługującego 30 zgłoszeń na godzinę ($0.73). Skala jest logarytmiczna. Stawka, przepustowość i liczby tokenów to dane wejściowe, które powinieneś zastąpić własnymi; różnica przetrwa każdy ich realistyczny zestaw.
Takie liczby sprawiają, że AI wydaje się oczywistym tak, i to właśnie przez nie właściciele firm kończą rozczarowani. Bo cena za zadanie to nie decyzja. To najmniejsza liczba w całym rachunku.
Prawdziwą bramką jest budowa
Między Tobą a tymi ułamkami centa stoi koszt stały: ktoś musi zbudować tę funkcję. Podłączyć ją do Twojego systemu zgłoszeń, napisać i przetestować prompty, obsłużyć przypadki brzegowe, postawić przed nią ekran weryfikacji, wdrożyć. Czy będzie to skrypt za $3,000, czy integracja za $20,000, zależy od zakresu, a zachowuje się to jak każda inna decyzja kapitałowa w Twojej firmie: trzeba to odzyskać z oszczędności, miesiąc po miesiącu. AI nie zniosło tej logiki; sprawiło tylko, że koszt krańcowy stał się tak mały, że budowa to praktycznie cała inwestycja. Jeśli porównujesz to z zakupem gotowego narzędzia, to osobna decyzja, ale poniższa arytmetyka działa tak samo w obu przypadkach.
Wzór na próg rentowności
Cały model mieści się w jednej linii: zwrot w miesiącach = koszt budowy ÷ (zadania miesięcznie × oszczędność na zadaniu), gdzie oszczędność na zadaniu to koszt wykonania go przez człowieka minus koszt modelu. Koszt całkowity za godzinę podzielony przez liczbę zadań na godzinę daje stronę ludzką; matematyka tokenów daje stronę AI. Trzy dane wejściowe, jedno dzielenie, i każdą z nich możesz poprawić: swoje stawki, swoją przepustowość, swoją wycenę.
Ta sama budowa przy trzech wolumenach
| Wolumen | Próg rentowności |
|---|---|
| 10,000 zadań / mies. | ~5 tygodni |
| 3,000 zadań / mies. | ~3,7 mies. |
| 300 zadań / mies. | ~3 lat |
Ta sama budowa, trzy wolumeny
Budowa $8,000; każde zadanie: AI ~$0,00075 vs człowiek ~$0,73 (model)
Skumulowany koszt wykonywania zadania przez ludzi (trzy wolumeny) wobec jednorazowej budowy za $8,000 i działania na AI. Założenia zadania jak na wykresie powyżej; użycie AI przy tych wolumenach to $0.23 do $7.50 miesięcznie, więc bursztynowa linia rysuje się płasko. Próg rentowności wypada po około 5 tygodniach przy 10,000 zadań miesięcznie, 3.6 miesiąca przy 3,000 i mniej więcej 3 latach przy 300. Podstaw własną stawkę, przepustowość i wycenę budowy; liczy się kształt.
To wykres, który rozstrzyga większość sporów o to, budować czy nie, bo jedyne, co zmienia się między trzema liniami, to wolumen. Przy 10,000 zadań miesięcznie budowa za $8,000 zwraca się w około pięć tygodni; ta sama budowa przy 300 zadaniach miesięcznie ciągnie się przez mniej więcej trzy lata, co w kategoriach oprogramowania jest zupełnie inną decyzją. Nic w modelu, promptach ani jakości się nie zmieniło. Sam wolumen przesunął odpowiedź z oczywistego tak do prawdopodobnego nie.
Tabela zwrotu
Znajdź swoją kolumnę, znajdź swoją wycenę i masz uzasadnioną pierwszą odpowiedź, zanim ktokolwiek otworzy IDE.
| 300 zadań / mies. | 1,000 / mies. | 3,000 / mies. | 10,000 / mies. | |
|---|---|---|---|---|
| Oszczędność miesięczna | $220 | $733 | $2,198 | $7,326 |
| Budowa za $3,000 zwraca się w | 13.7 mies. | 4.1 mies. | 1.4 mies. | 0.4 mies. |
| Budowa za $8,000 | 36.4 mies. | 10.9 mies. | 3.6 mies. | 1.1 mies. |
| Budowa za $20,000 | 91.0 mies. | 27.3 mies. | 9.1 mies. | 2.7 mies. |
Dwa uczciwe odczyty tej tabeli. W dół kolumny: dyscyplina zakresu się opłaca, bo przy 1,000 zadań miesięcznie różnica między budową za $3,000 a $20,000 to różnica między czterema miesiącami a dwoma latami. Wzdłuż wiersza: wolumen to dźwignia, bo ta sama budowa za $8,000 waha się od błędu zaokrąglenia po coś nie do uzasadnienia, w zależności od tego, ile zadań naprawdę przez nią przepuścisz. Gdy wycena ląduje w szarym środku, najtańszym eksperymentem jest zwykle mniejsza budowa, która testuje założenie o wolumenie, a nie większa budowa, która na nim stawia.
Kiedy cena tokenów jednak ma znaczenie
Klasyfikacja to tanie zadanie; nie każde takie jest. Praca redakcyjna, która czyta brief o długości 2,000 tokenów i pisze dokument na 1,500 tokenów na Opus 4.8, kosztuje około $0.05 na zadanie, a praca z długim kontekstem potrafi wspiąć się znacznie wyżej. Wciąż porównuje się to z $0.37 za jedną minutę ludzkiego czasu, więc różnica przetrwa, ale przy dziesiątkach tysięcy zadań linia krańcowa przestaje być ozdobą: to różnica między tokenami kosztującymi $8 miesięcznie a $500. To tutaj ukryte mnożniki z części pierwszej i dźwignie z części drugiej podpinają się pod ten model: przesuwają oszczędność na zadaniu, co skraca zwrot. Rzadko same odwracają decyzję o budowie, ale decydują o tym, jak dobra staje się dobra decyzja.
Czego ten model nie uwzględnia
Uczciwość wobec obliczeń na kopercie. Jeśli człowiek nadal sprawdza każdy wynik, Twoja oszczędność na zadaniu to różnica w czasie weryfikacji, a nie pełne $0.73, i zwrot odpowiednio się wydłuża; model zarabia na siebie tam, gdzie w pełni zamyka większość zadań, a resztę eskaluje. Błędy mają cenę, której ten wzór nie widzi, więc zadania, w których błędna odpowiedź jest kosztowna, potrzebują taniej kontroli w obiegu, zanim matematyka wolumenu cokolwiek zaczyna znaczyć. A budowa to nie ostatnia faktura: prompty się rozjeżdżają, systemy się zmieniają, ktoś utrzymuje integrację. Nic z tego nie psuje modelu; to po prostu należy do kolumny budowy, a pilotaż zaprojektowany tak, by przetestować Twoje założenie o wolumenie, to najtańszy sposób, żeby sprawdzić, jakie te liczby naprawdę są.
