Lokalny model czy API? Oszczędność znika przy złym wykorzystaniu

Firmie opłaca się uruchomić model u siebie, gdy ma dostatecznie duży, przewidywalny ruch, potrafi wykorzystać kupioną moc i uzyskuje odpowiedzi wymagające niewielu poprawek. Jeśli GPU przez znaczną część czasu czeka na żądania, pozorna oszczędność na pojedynczym użyciu znika. Przy nierównym obciążeniu i trudniejszych zadaniach API może dać niższy koszt zaakceptowanego wyniku.

Wybór nie sprowadza się do ceny tokena. Trzeba zestawić amortyzację sprzętu, energię, pracę administratora, opłaty API po uwzględnieniu cache oraz czas ludzi poprawiających wyniki. Model lokalny ma dodatkową wartość tam, gdzie dane muszą pozostać w firmowej infrastrukturze; wariant hybrydowy pozwala podzielić zadania, jeśli zasady dotyczące danych dopuszczają użycie API.

Pełny koszt własnej infrastruktury

Własny model wymaga sprzętu, zasilania, miejsca i osób, które go uruchomią oraz utrzymają. Miesięczny rachunek obejmuje amortyzację, stały pobór energii, licencje, aktualizacje, monitorowanie i czas administratora. Rezerwacja GPU na wyłączność oznacza koszt także wtedy, gdy nie przychodzi żadne żądanie; współdzielenie zasobu rozkłada go na więcej zadań, lecz wymaga sprawdzenia, czy ich szczyty ruchu nie występują jednocześnie.

W badaniu kosztów inferencji niedociążenie tego samego GPU H100 podnosiło efektywny koszt od 2,5 do 24 razy przy niskim i umiarkowanym ruchu. Dlatego do kalkulacji potrzebne są zarówno rzeczywista liczba żądań, jak i ich rozkład w ciągu dnia. Średnia miesięczna nie pokazuje, ile mocy trzeba utrzymywać na godziny szczytu ani jak długo pozostaje ona bezczynna.

Cache zmienia rachunek za API

W API osobno liczą się tokeny wejściowe, wyjściowe i wejście odczytane z cache. Dokumentacja cache OpenAI wskazuje, że ponowne użycie zgodnego początku żądania może obniżyć cenę tokenów wejściowych nawet o 90%, przy czym stawki i zasady zapisu zależą od modelu. Stałe instrukcje lub definicje narzędzi umieszczone przed zmienną treścią zwiększają szansę ponownego użycia; zmiana początku żądania albo przerwa przekraczająca czas życia wpisu ją ogranicza.

Do arkusza należy więc przenieść rzeczywisty podział zużycia na zwykłe wejście, odczyty i zapisy cache oraz wyjście. Katalogowa cena za milion tokenów pomnożona przez cały ruch może zawyżyć koszt powtarzalnych zapytań. Z kolei założenie stałej skuteczności cache może go zaniżyć, gdy zadania mają krótkie, różne konteksty albo pojawiają się sporadycznie.

Jakość odpowiedzi też ma cenę

W studium agentów programistycznych cache obniżył zrealizowany koszt API o 88,6%, poniżej zamortyzowanej stawki jednostkowej współdzielonego zasobu lokalnego; przy założeniach dla rynku tajwańskiego pełny koszt lokalny był jednak o 40,1% niższy przy współdzieleniu GPU i o 43,8% wyższy przy dedykowanej rezerwacji, a udział commitów naprawczych wynosił 74,9% lokalnie wobec 45,9% w chmurze. Niższa cena tokenów API i niższy pełny koszt współdzielonej infrastruktury dotyczą różnych miar, więc oba wyniki mogą być prawdziwe jednocześnie.

Porównanie było obserwacyjne i obejmowało różne modele oraz narzędzia. Różnicy w liczbie napraw nie da się zatem przypisać wyłącznie miejscu uruchomienia modelu. Dla firmy istotne jest własne zadanie: ile wyników przechodzi kontrolę, ile wymaga ponownego wywołania modelu i ile pracy zajmuje korekta. W obsłudze dokumentów może to być sprawdzenie pól, w programowaniu przegląd i naprawa kodu, a w komunikacji z klientem redakcja odpowiedzi przed wysłaniem.

Prywatność i działanie bez sieci

Lokalna inferencja pozwala przetwarzać treść w infrastrukturze firmy, o ile także logi, integracje i kopie danych pozostają w wyznaczonym środowisku. Porównanie Tom’s Guide pokazało działanie lokalnego modelu bez internetu oraz lepsze wyniki usługi chmurowej w trudnych zadaniach i wyszukiwaniu bieżących informacji. Był to test codziennego użycia, więc nie zastępuje oceny firmowego procesu i wybranych modeli.

Przesłanie danych do API wymaga oceny konkretnych warunków dostawcy, nie ogólnego założenia o chmurze. Według zasad przetwarzania danych OpenAI treści przesłane do API domyślnie nie służą do trenowania modeli, lecz logi monitorowania nadużyć mogą zawierać zapytania i odpowiedzi oraz być przechowywane do 30 dni; ograniczenie tej retencji podlega dodatkowym warunkom. Znaczenie mają również używany punkt API, ustawienia przechowywania danych i ewentualne usługi zewnętrzne połączone z aplikacją.

Kalkulator progu opłacalności

Jednostką porównania powinno być zaakceptowane zadanie, a okresem ten sam miesiąc po obu stronach. Oznacz stały koszt lokalny jako F: amortyzację sprzętu, stałą część energii, utrzymanie, licencje i czas administratora. Koszt zmienny lokalnego zadania, l, obejmuje energię zużytą podczas pracy, ponowne uruchomienia oraz średni koszt kontroli i poprawek. Analogiczny koszt API, a, zawiera tokeny według faktycznych stawek po cache, pozostałe opłaty oraz pracę potrzebną do uzyskania akceptowanego wyniku.

Jeśli a przewyższa l, próg opłacalności własnej infrastruktury wynosi F / (a − l) zaakceptowanych zadań miesięcznie. Powyżej progu lokalny wariant może być tańszy, o ile zainstalowana moc obsłuży ten ruch przy wymaganym czasie odpowiedzi. Jeśli a jest równe l lub od niego mniejsze, wzrost liczby zadań sam nie pokryje stałego kosztu lokalnego. Do arkusza trzeba też wpisać pojemność konfiguracji przy dopuszczalnym opóźnieniu: stosunek rzeczywistego ruchu do tej pojemności pokazuje planowane wykorzystanie sprzętu.

Przykład jest wyłącznie założeniem rachunkowym: F wynosi 12 000 zł miesięcznie, koszt zaakceptowanego zadania przez API to 1,50 zł, a lokalnie 0,30 zł. Próg wynosi wtedy 10 000 zadań. Jeśli poprawki zwiększą koszt lokalny o 0,60 zł na zadanie, próg rośnie do 20 000 zadań. Przy konfiguracji zdolnej obsłużyć 40 000 takich zadań miesięcznie wymagane wykorzystanie wzrasta z 25% do 50%. Wynik ma sens tylko przy jednakowej definicji zaakceptowanego zadania i kosztach pracy liczonych w tej samej walucie oraz za ten sam okres.

Kiedy podzielić ruch między lokalny model i API

API pasuje do niepewnego lub zmiennego wolumenu, zwłaszcza gdy zadania wymagają jakości, której dostępna konfiguracja lokalna nie zapewnia bez kosztownych poprawek. Własny model zyskuje przy stabilnym ruchu, dobrym wykorzystaniu mocy i potrzebie zatrzymania danych w firmie. O wyborze rozstrzyga pełny koszt zaakceptowanych wyników przy wymaganej jakości i czasie odpowiedzi.

Wariant hybrydowy może kierować powtarzalne lub poufne zadania lokalnie, a trudniejsze do API, jeśli pozwalają na to reguły przetwarzania danych. W takim rachunku dochodzi koszt utrzymania obu ścieżek, klasyfikacji żądań oraz przekierowania zadania po nieudanej odpowiedzi. Podział ma ekonomiczny sens wtedy, gdy poprawa wykorzystania sprzętu i jakości wyników przewyższa tę dodatkową pracę.

Przeczytaj także:

• ChatGPT czy Claude do kodowania? Wynik zależy od rodzaju zadania