Kiedy nasz dostawca AI wycofał model
Zmiana modelu, puste odpowiedzi bez błędów i rachunek, który nagle był kilka razy wyższy. Co się zepsuło i dlaczego przyczynę było tak trudno dostrzec.

W lipcu 2026 kilka funkcji przestało działać jednocześnie: czat AI, odpowiedzi AI w ticketach, podsumowania ticketów, kreator serwerów, a do tego moderacja i tłumaczenie pomysłów i zgłoszeń błędów.
Przyczyną nie był nasz kod. Nasz dostawca AI wycofał model, z którego korzystaliśmy.
Część pierwsza: modelu nie ma
To oczywista część i szybko ją naprawiono. Dostawca wycofuje model, wpisujesz następcę, gotowe.
Właściwy incydent zaczął się potem.
Część druga: puste odpowiedzi, bez błędów
Po zmianie odpowiedzi przychodziły. Tylko czasem były puste. Nie ucięte, nie uszkodzone, tylko całkowicie puste, bez żadnego błędu.
Przyczyna tkwi w różnicy, której nie zdradza nazwa modelu: następca to model rozumujący. Przed właściwą odpowiedzią najpierw zapisuje wewnętrzny tok myślenia w osobnym polu. Oba korzystają z tego samego budżetu tokenów.
Jeśli budżet zostanie zużyty na myślenie, wraca odpowiedź, która formalnie jest w porządku: dostawca zgłasza "osiągnięto długość", a pole treści jest puste. Żadnego błędu, żadnej wskazówki, nic, co zobaczyłby try/catch.
Odtworzyliśmy to prawdziwym testem: budżet pięciu tokenów wystarcza, żeby każde zapytanie dawało pustą odpowiedź.
Część trzecia: rachunek
W najdroższym miejscu wywołania, kreatorze serwerów AI, ustawiliśmy hojny budżet, bo tam powstają długie odpowiedzi. Myślenie nie trafiało więc na żaden limit, tylko po prostu trwało.
Skutki przyszły z dwóch stron naraz. Zapytania trwały tak długo, że wpadały w limity czasu. I kosztowały kilka razy więcej, bo za każdym razem płaciło się za cały niewidoczny tok myślenia. Na koniec przyszedł komunikat o błędzie, którego nie planowaliśmy: niewystarczające saldo.
Poprawka to jedna linijka. Myślenie można wyłączyć w treści zapytania, a model zachowuje się wtedy znowu jak stary. Od tamtej pory ta linijka należy do każdego miejsca wywołania, a jest ich w repozytorium więcej niż kilka.
Część czwarta: co znaleźliśmy przy sprzątaniu
Skoro i tak dotyka się każdego miejsca wywołania AI, to się mu przygląda. Tak wyszedł drugi temat, niezwiązany z incydentem, ale podobnie kosztowny.
Dostawcy biorą znacznie mniej za prompt, którego początek pozostaje niezmieniony i może zostać obsłużony z pamięci podręcznej. Różnica między trafieniem a chybieniem jest mniej więcej trzydziestokrotna.
Tego rabatu nie dostaje się przez flagę. Sprawdziliśmy to konkretnie: pole w treści zapytania przeznaczone do tego miało zerowy efekt, pamięć podręczna i tak działa automatycznie. Jedyną dźwignią jest kolejność w prompcie, od stabilnego do zmiennego.
Cztery miejsca, gdzie zrobiliśmy dokładnie odwrotnie:
Zmienna wartość wewnątrz stałego bloku instrukcji. Sprawdzanie duplikatów zgłoszeń błędów miało nazwę modułu w tekście instrukcji. To dawało skądinąd identycznemu blokowi osobny wpis w pamięci podręcznej dla każdego modułu. Wartość należy do zmiennej części, gdzie i tak się zmienia.
Nowe przed stabilnym. To samo sprawdzenie wysyłało nowe zgłoszenie błędu przed maksymalnie pięćdziesięcioma kandydatami do porównania. Przez to największy prompt API był stale całkowitym chybieniem.
Dane konkretnego użytkownika w stałej części. Publiczny czat AI miał notatki o pojedynczym użytkowniku w bloku instrukcji, czyli przed wspólną historią kanału. Przez to każdy użytkownik w tym samym kanale miał własny początek, a za wspólną historię płaciło się osobno dla każdego.
Przesuwane okno historii. Wysyłanie ostatnich N wiadomości przy każdej wiadomości przesuwa początek przy każdej wiadomości. Cała historia jest wtedy stałym chybieniem. Właściwe podejście to przycinanie blokami, czyli rzadko i porządnie.
Do tego jeden szczegół, który wygląda na czepialstwo, ale nim nie jest: lista w prompcie posortowana tylko według jednego kryterium może przy remisach zmieniać kolejność. Jedna zamieniona linijka w środku bloku instrukcji kosztuje trafienie dla wszystkiego, co jest za nią. Sortowania w promptach potrzebują jednoznacznego kryterium rozstrzygającego.
Co z tego wynieśliśmy
Zmiana modelu to nie zmiana konfiguracji. Nazwa wygląda jak wartość w zmiennej. Kryło się za nią inne zachowanie, a to zachowanie zepsuło nasz kod, a nie interfejs.
Niebezpieczna była cicha awaria. Zniknięcie starego modelu było widoczne od razu i naprawione w kilka minut. Puste odpowiedzi wracały jako formalnie poprawne i mogły tak pozostać dowolnie długo.
Mierzalność należy do miejsca wywołania. Teraz w każdym z nich logujemy odsetek trafień w pamięci podręcznej. Dobrze zbudowane miejsce po pierwszym zapytaniu ustala się na wysokim poziomie, źle zbudowane zostaje na zerze. Widać to w linijce logu i nigdzie indziej, bo działają oba.
I niewygodny wniosek: korzystanie z cudzego modelu oznacza, że część twojego produktu zależy od decyzji podjętej gdzie indziej. Dlatego od sierpnia każdy serwer może skierować funkcje AI na własny endpoint, zamiast polegać na naszym.
Więcej artykułów
Pod okiem 4000 serwerów Discord: Grafana, PostHog i to, co nam pokazały
Pętla, która po cichu generowała połowę naszego ruchu, trzy miliony bezsensownych zapytań dziennie i atak, który skończył się po minucie. Co widzi nasz monitoring, a czego celowo nie widzi.
Za kulisamiCzego nauczył nas bot na ponad 2000 serwerach Discord
Cztery rzeczy, które w dużej skali działają inaczej, niż się wydaje przy pisaniu kodu.
Za kulisamiDlaczego prawie wszystko w AlphaCloud pozostaje darmowe
Większość botów Discord zamyka najprzydatniejsze funkcje za subskrypcją. My celowo tego nie robimy, i ma to mniej wspólnego z hojnością, niż się wydaje.