Novita niedawno zaktualizowała cennik swoich modeli LLM. W przypadku zespołów prowadzących produkcyjne wnioskowanie (inference) za pośrednictwem tej platformy, zdanie to powinno stać się sygnałem do natychmiastowego audytu bieżących wydatków. Zmiany stawek API rzadko przychodzą w dogodnym momencie, a gdy obejmują wiele poziomów modeli, wpływ na miesięczne koszty może być dotkliwszy, niż się spodziewano.

Dlaczego ceny wnioskowania zasługują na Twoją uwagę

Większość nowoczesnych aplikacji AI nie opiera się na własnych klastrach GPU. Deweloperzy kierują zapytania do dostawców usług wnioskowania, takich jak Novita, ponieważ alternatywą jest zabezpieczenie sprzętu, zarządzanie wdrożeniami vLLM lub TGI oraz radzenie sobie z problemem "cold start" podczas nagłych skoków ruchu. Ta wygoda jest cenna, ale jest również rozliczana według zużycia. Każdy wygenerowany token powiększa rachunek, który kumuluje się w sesjach użytkowników, zadaniach w tle i narzędziach wewnętrznych.

Gdy dostawca zmienia cennik, efekt kaskadowy rozchodzi się po całym stosie technologicznym. Chatbot obsługujący dziesięć tysięcy rozmów z klientami dziennie może w ciągu tygodnia zużyć czterdzieści milionów tokenów wejściowych i dwanaście milionów tokenów wyjściowych. Zmiana stawki za milion tokenów nawet o kilka dolarów sprawia, że miesięczna różnica szybko staje się znacząca. W przypadku produktów budowanych metodą bootstrap lub zespołów operujących na niskich marżach, ta różnica może zniwelować rentowność. Asystent programowania działający jako rozszerzenie przeglądarki, potok do masowego streszczania tekstów przetwarzany w nocy czy wewnętrzne narzędzie wyszukiwania zapytające model przy każdym ładowaniu strony – wszystkie te rozwiązania dzielą tę samą podatność. Ich ekonomia jednostkowa zależy od dokładnej ceny kolejnego tokena.

Co zmieniło się w Novita

Novita wprowadziła nowe koszty, które wpływają na różne modele w swoim katalogu. Firma nie zdecydowała się na jednolitą podwyżkę lub obniżkę procentową dla wszystkich. Zamiast tego korekty różnią się w zależności od modelu, co oznacza, że Twój rachunek zmieni się w zależności od tego, z których konkretnie punktów końcowych (endpoints) korzystasz.

Jeśli Twoja aplikacja kieruje cały ruch przez jeden duży model językowy, obliczenia są proste. Porównaj starą stawkę z nową i oszacuj straty lub oszczędności. Jednak większość środowisk produkcyjnych jest bardziej złożona. Zespoły często utrzymują logikę routingu, która wysyła proste zapytania do lżejszych modeli, a potężniejsze jednostki rezerwuje do zadań wymagających złożonego rozumowania. Inni przeprowadzają testy A/B na kilku modelach, aby porównać opóźnienia i jakość. W takich scenariuszach zmiana ceny tylko jednego lub dwóch modeli może zaburzyć całą strukturę kosztów.

Konkretne kwoty za token i za zapytanie zostały przedstawione w szczegółowej analizie opublikowanej przez Narevbot na Dev.to. Dokładny cennik możesz sprawdzić tutaj: https://dev.to/narevbot/changes-to-llm-pricing-novita-3plc

Nie polegaj na pamięci ani na starym zrzucie ekranu ukrytym w dokumentacji. Pobierz aktualne dane bezpośrednio z tego źródła, zanim przygotujesz prognozy na kolejny kwartał.

Jak przeprowadzić audyt ryzyka

Zacznij od danych, a nie od założeń. Zaloguj się do panelu Novita i wyeksportuj historię zużycia z ostatnich dwóch lub trzech miesięcy. Podziel te dane według modelu oraz typu operacji. Musisz wiedzieć, które punkty końcowe pochłaniają większość budżetu i które generują najwięcej tokenów na zapytanie.

Szukaj następujących wzorców:

  • Ryzyko koncentracji. Jeśli siedemdziesiąt procent Twoich wydatków trafia do jednego modelu, a ten odnotował wzrost cen, sprawa jest pilna. Jeśli wydatki są rozproszone na osiem modeli i trzy z nich zmieniły ceny, obliczenia zajmą więcej czasu, ale ryzyko nadal jest realne.
  • Przerost tokenów (Token bloat). Sprawdź, czy Twoje prompty nie puchną od niepotrzebnego kontekstu. Długie systemowe prompty, powtarzające się przykłady typu few-shot oraz nadmiernie rozbudowane formatowanie XML zwiększają koszty wejściowe. Aktualizacja cennika to idealna okazja, aby "odchudzić" zapytania.
  • Nieefektywność wyjścia. Jeśli Twoja aplikacja prosi o długie odpowiedzi, ale wykorzystuje tylko pierwsze kilka zdań, płacisz za tokeny, które wyrzucasz. Dostosuj limity max_token oraz sekwencje stop (stop sequences).
  • Bezczynne zadania w tle. Zaplanowane zadanie, które generuje raporty lub tworzy osadzenia (embeddings) dokumentów, może działać częściej, niż to konieczne. Zweryfikuj harmonogram cron oraz rozmiar partii (batch size).