Zejście na słabszy model to ostatnia dźwignia, nie pierwsza
Przejście z Opus 4.8 na Sonnet 4.6 obniża ceny za token o 40 procent i przelosowuje każdą odpowiedź, jaką daje Twój produkt. To zagranie, po które większość zespołów sięga jako pierwsze, i zwykle jest przedwczesne, bo dwie większe zniżki już czekają w cenniku modelu, którego używasz dziś: prompt caching czyta powtarzany kontekst za mniej więcej jedną dziesiątą ceny wejścia, a Batch API zdejmuje równe pół z wszystkiego, co może poczekać. Żadna z nich nie zmienia ani jednej odpowiedzi. Kumulują się. A jeśli zastosujesz je najpierw, downgrade, na który się przygotowywałeś, często przestaje być potrzebny.
Żeby liczby były uczciwe, dalej pracujemy na tym samym pacjencie: chatbocie wsparcia, którego fakturę na $1,460 rozłożyliśmy na części w części pierwszej. Cztery dźwignie, zastosowane po kolei, bez zmiany modelu dla ruchu, który się liczy:
| Pozycja | Kwota |
|---|---|
| Faktura z cz. 1 | $1,460 |
| + prompt caching | $1,332 |
| + routing | $799 |
| + krótszy output | $673 |
Chatbot z części 1, cztery dźwignie później
Opus 4.8, 10,000 rozmów / mies. · dźwignie stosowane od lewej do prawej
Policzone na założeniach z części 1 (10,000 czteroturowych rozmów; blok systemowy 1,500 tokenów; pytania po 500 tokenów, odpowiedzi po 700 tokenów; Opus 4.8 po $5 / $25 za 1M). Caching używa okien 5-minutowych i respektuje minimalny cache'owalny prefiks Opus 4.8 wynoszący 4,096 tokenów, więc zaczyna się opłacać dopiero od tury 3. Routing kieruje łatwiejszą połowę rozmów na Haiku 4.5 ($1 / $5) i zmienia te odpowiedzi. Skracanie tnie odpowiedzi o ~30% przy niezmienionym wejściu, co utrzymuje szacunek po konserwatywnej stronie.
Dźwignia 1: prompt caching, zniżka ukryta w powtarzanym kontekście
Część pierwsza pokazała, że ponownie wysyłany kontekst to największa pozycja na rachunku za rozmowy: ten sam prompt systemowy i ta sama rosnąca historia, naliczane od nowa przy każdej turze. Caching uderza dokładnie w tę pozycję. Oznaczasz stabilny prefiks swojego zapytania, płacisz jednorazową dopłatę za jego zapis (1.25x ceny wejścia w warstwie 5-minutowej, 2x w warstwie 1-godzinnej), a każde kolejne zapytanie, które zaczyna się od tych samych bajtów, odczytuje go za mniej więcej jedną dziesiątą ceny.
| Warstwa cache | Dopłata za zapis | Cena odczytu | Zwraca się |
|---|---|---|---|
| 5-minutowa | 1.25x ceny wejścia, raz | ~0.1x ceny wejścia | Przy 2. użyciu prefiksu |
| 1-godzinna | 2x ceny wejścia, raz | ~0.1x ceny wejścia | Przy 3. użyciu |
Dwa uczciwe zastrzeżenia, zanim wpiszesz sobie 90 procent. Po pierwsze, zniżka dotyczy zcache'owanej części, nie całego rachunku: nasz chatbot spada z $1,460 do $1,332, cięcie o 9 procent, bo jego rozmowy są krótkie. Na Opus 4.8 nic poniżej 4,096 tokenów nie da się w ogóle zcache'ować, więc czteroturowa rozmowa przekracza ten próg dopiero w turze trzeciej; najgłębsze, najdroższe tury dostają zniżkę, wczesne nie. Po drugie, dopłata za zapis oznacza, że cache'owanie prefiksu, którego nikt nie używa ponownie, to sposób na dopłacanie. Caching błyszczy tam, gdzie kontekst jest duży albo rozmowy sięgają głęboko, czyli dokładnie tam, gdzie według części pierwszej mieszka ból.
Dźwignia 2: Batch API, równe pół ceny za wszystko, co może poczekać
Batch API to najprostsza zniżka w katalogu: zgłaszasz pracę asynchronicznie, dostajesz wyniki w ciągu minut do godzin, płacisz 50 procent standardowej ceny za każdy token w zadaniu, łącznie z tokenami z cache. Nie ma tu żadnego kompromisu na jakości; to ten sam model dający te same odpowiedzi, tyle że nie wtedy, gdy ktoś patrzy na kręcący się spinner.
Haczyk tkwi w definicji "może poczekać". Klient w trakcie rozmowy nie może, więc ruch na żywo naszego chatbota nie zyskuje na tej dźwigni nic i dlatego nie pojawia się na wodospadzie powyżej. Ale niemal każdy produkt AI niesie ze sobą cień obciążenia, które może poczekać: nocne podsumowania tych rozmów wsparcia, masowa klasyfikacja, generowanie raportów, potoki treści. Wyceniaj je osobno i domyślnie puszczaj w batchu; płacenie stawki na żywo za pracę, na którą nikt nie czeka, to najcichszy wyciek w większości rachunków.
Dźwignia 3: kieruj według trudności, nie domyślnie
Nie każda rozmowa potrzebuje Twojego najlepszego modelu. Reset hasła i pytanie o status dostawy nie wymagają Opus 4.8; wymagają poprawnego wyszukania i grzecznego zdania, co Haiku 4.5 dostarcza po $1 / $5 za milion tokenów, pięć razy taniej za token. W naszym modelu skierowanie łatwiejszej połowy rozmów na Haiku sprowadza rachunek z $1,332 do $799, największy pojedynczy krok na wodospadzie.
Traktuj tę dźwignię inaczej niż dwie poprzednie, bo to pierwsza, która zmienia odpowiedzi. Caching i batchowanie zwracają identyczne odpowiedzi; routing daje skierowanej części inny model. Dyscyplina, która trzyma to w ryzach: klasyfikuj konserwatywnie, kieruj tylko ten ruch, który tańszy model dowodnie obsługuje na Twoim własnym zbiorze testowym, i zostaw ścieżkę eskalacji z powrotem do dużego modelu w chwili, gdy rozmowa przestaje być łatwa.
Dźwignia 4: przytnij stronę wyjścia, bo nalicza się pięć razy drożej niż wejście
Każdy model Claude wycenia tokeny wyjściowe dokładnie pięć razy drożej niż wejściowe, więc długość Twoich odpowiedzi to decyzja cenowa, niezależnie od tego, czy podjąłeś ją świadomie. Odpowiedzi wsparcia napchane powtórzonymi pytaniami i uprzejmościami na koniec kosztują realne pieniądze przy skali. Polecenie asystentowi, by odpowiadał w najkrótszej formie, która w pełni rozwiązuje zgłoszenie, skraca nasze modelowe odpowiedzi o około 30 procent, a rachunek z $799 do $673, a w rodzinie Opus ustawienie effort to to samo pokrętło o poziom wyżej: przykręć je dla rutynowego ruchu, a model zużyje mniej tokenów rozumowania, żeby dojść do tego samego miejsca.
Granica jest tu nie techniczna, lecz ludzka: przytnij poniżej progu użyteczności, a odpowiedzi zaczynają brzmieć szorstko, co wraca później jako ponowne kontakty. Wytnij watę, zachowaj treść.
Skąd naprawdę bierze się te 50 do 90 procent
Nałóż dźwignie na naszego chatbota, a faktura ląduje na $673, 54 procent poniżej tego, gdzie zostawiła ją część pierwsza, przy czym trudna połowa ruchu wciąż siedzi na dokładnie tym samym modelu dającym dokładnie te same odpowiedzi. To, czy Twoja liczba wyląduje bliżej 50 czy 90, rozstrzygają dwie cechy Twojego obciążenia: ile z Twojego wejścia to powtarzany kontekst i ile z Twojej pracy może poczekać.
| Obciążenie | Zaoszczędzono |
|---|---|
| Chatbot wsparcia na żywo | -54% |
| Nocny potok dokumentów | -64% |
| Agent async, ciężki wspólny kontekst | -88% |
Głębokość cięcia zależy od kształtu
Udział zaoszczędzonego rachunku miesięcznego, modelowo per obciążenie
Trzy modelowe obciążenia, te same modele od początku do końca. Chatbot: założenia z części 1 plus trzy dźwignie powyżej ($1,460 do $673). Potok: 60,000 dokumentów miesięcznie na Sonnet 4.6 ($3 / $15), wspólny blok instrukcji 2,500 tokenów (cache'owany) plus dokument 3,000 tokenów na wejściu i 500 tokenów na wyjściu, puszczany nocą przez Batch API ($1,440 do $518). Agent: 100,000 wywołań async miesięcznie na Opus 4.8 ze wspólnym pakietem kontekstu 10,000 tokenów trzymanym w cieple, 200 na wejściu / 300 na wyjściu na wywołanie, w batchu ($5,850 do $675). Trafienia w cache wewnątrz przebiegów Batch są best effort, więc traktuj prawe końce jak sufity.
Chatbot na żywo siedzi na skromnym końcu, bo krótkie rozmowy cache'ują się późno, a żadnego ruchu na żywo nie da się wsadzić w batch. Nocny potok dokumentów wypada lepiej: jego blok instrukcji cache'uje się idealnie, a każdy token w zadaniu bierze zniżkę batchową. A asynchroniczny agent z dużym wspólnym pakietem kontekstu to kształt, dla którego te zniżki powstały; dziewięć dziesiątych jego wejścia czyta z cache, a cały przebieg idzie w batchu, więc 88 procent rachunku po prostu znika.
Sprawdzenie kwalifikacji
Zanim ruszysz nazwę modelu, przejdź swoje obciążenie po tej tabeli raz.
| Dźwignia | Czego potrzebuje Twoje obciążenie | Realna oszczędność | Uważaj na |
|---|---|---|---|
| Prompt caching | Stabilny prefiks powyżej minimum modelu, używany ponownie w oknie cache | ~90% taniej na powtarzanej części | Dopłata za zapis mści się poniżej 2-3 użyć; krótkie rozmowy cache'ują się późno |
| Batch API | Tolerancja na opóźnienie rzędu minut do godzin | Równe -50% na całym zadaniu | Nigdy dla czekającego użytkownika; trafienia w cache wewnątrz batchy są best effort |
| Routing według trudności | Wycinek ruchu, który tańszy model dowodnie obsługuje | Do 5x na skierowanym wycinku | Zmienia odpowiedzi; najpierw przetestuj jakość i zostaw ścieżkę eskalacji |
| Krótszy output + effort | Rachunki z ciężkim wyjściem (wyjście wyceniane 5x drożej niż wejście) | Proporcjonalna do cięcia | Zbyt agresywne brzmi jak szorstkie, niepełne odpowiedzi |
Przeprowadź audyt w tej kolejności: najpierw caching, jeśli jakikolwiek kontekst się powtarza, wsadź w batch wszystko, na co użytkownik nie czeka, przytnij wyjście, którego i tak nigdy nie czytałeś, a potem skieruj dowodnie łatwy wycinek. Dopiero gdy wszystkie cztery są na miejscu, pytanie o downgrade zasługuje na odpowiedź, a wtedy jest to już dużo mniejsze pytanie. A jeśli liczba, na której lądujesz, wciąż wydaje się za wysoka jak na to, co ta funkcja zarabia, pytanie brzmi już nie jak taniej ją uruchomić; brzmi, czy w ogóle powinna istnieć, i właśnie po to jest część trzecia.
