Najpierw wniosek: wzrost rachunku w osiemdziesięciu procentach przypadków nie wynika ze wzrostu wolumenu. Prowadziłem projekt inteligentnej obsługi klienta — w pierwszej połowie zeszłego roku miesięczny rachunek utrzymywał się stabilnie w okolicach 8000 juanów, a w czwartym kwartale skoczył do 23000 juanów, podczas gdy wolumen wywołań wzrósł w tym samym okresie tylko o 40%. Gdzie poszły dodatkowe pieniądze? Wyciągnąłem logi wywołań z trzech miesięcy i zagregowałem je według czterech wymiarów: typu zadania, długości wejścia, długości wyjścia i liczby ponownych prób. Problem był jasny — cztery ukryte czarne dziury kosztowe jednocześnie wypuszczały krew.

Najpierw definicja, żeby później się nie rozjechać. Struktura kosztów API modeli wielkoskalowych to w istocie suma trzech części: „tokeny wejściowe + tokeny wyjściowe + nieefektywne tokeny powstałe przy nieudanych ponownych próbach". Rozliczanie za zużycie to tylko sposób wyceny — nie odpowiada za oszczędzanie twoich pieniędzy. O rachunku naprawdę decyduje strategia routingu i strategia zarządzania kontekstem na bramie modeli.

Czarna dziura pierwsza: flagowy model wykonuje prostacką robotę

To najdroższa pozycja. W tym systemie obsługi klienta były trzy typy zadań: klasyfikacja zgłoszeń, tagowanie emocji i rozpoznawanie intencji — około 120 tysięcy wywołań dziennie. Wtedy, dla wygody, wszystko szło przez ten sam flagowy model. A jaka jest trudność tych trzech typów zadań? Daj mi dwustuznakową wiadomość użytkownika i rozstrzygnij, czy to „zapytanie o logistykę", czy „zwrot po sprzedaży" — mały model radzi sobie z tym stabilniej niż duży, bo przestrzeń etykiet jest po prostu niewielka.

Przeprowadziłem ponowną ocenę według zadań — dla zadań klasyfikacji zamieniłem model na średniej wielkości, dokładność spadła z 96,2% do 95,7%, różnica 0,5 punktu, a cena jednostkowa różniła się o rząd wielkości. Ta jedna pozycja pozwala ściąć czterdzieści procent rachunku.

Czarna dziura druga: pełna historia kontekstu wstrzykiwana od nowa

Obsługa klienta to rozmowa wieloturnowa, średnio 7,3 tury. Deweloperzy dla uproszczenia przy każdej turze wklejali pełną historię. Pierwsza tura: 800 tokenów wejściowych, siódma tura: już 4200 tokenów wejściowych, i przy każdej turze płacisz ponownie za poprzednie sześć. Ta krzywa kosztów jest kwadratowa — gdy wolumen rośnie, wszystko eksploduje.

Co gorsza, większość treści w historii nie ma żadnej wartości dla bieżącej tury. Użytkownik w trzeciej turze powiedział „chcę zwrócić towar", w siódmej pyta „kto płaci za przesyłkę" — cały ten wcześniejszy small talk i opis produktu to martwe tokeny.

Czarna dziura trzecia: mnożenie przez nieudane ponowne próby

Ta jest najtrudniejsza do zauważenia. Gdy upstream ogranicza ruch lub kończy się timeout, SDK domyślnie ponawia próbę trzy razy. Problem w tym, że ponowione żądanie często wysyła ten sam długi kontekst jeszcze raz w całości. Policzyłem — około 11% tokenów w rachunku pochodziło z nieudanych ponownych prób, a sześćdziesiąt procent tych wywołań ostatecznie i tak się nie powiodło — czyste palenie pieniędzy. Jeśli ponowne próby nie mają kontroli backoff i idempotencji, jedna awaria może ci wygenerować trzykrotne nieefektywne zużycie.

Czarna dziura czwarta: nieobcięte wyjście strumieniowe

Tokeny wyjściowe są zwykle droższe niż wejściowe. Wtedy odpowiedzi obsługi klienta nie miały ustawionego max_tokens, model od czasu do czasu „popuszczał wodze" — wyjaśnienie zwrotu, które dałoby się zamknąć w dwóch zdaniach, zamieniał w numerowaną instrukcję procesu. W rozkładzie długości wyjścia P99 było ponad sześciokrotnie większe niż P50. Tych nadmiarowych znaków użytkownik w ogóle nie czyta, a płacisz jak za zboże.

Pięć działań tamujących krwawienie

Po pierwsze, hierarchiczny routing modeli. Zbudowałem trzy poziomy według zadań: prosta klasyfikacja idzie do małego modelu, standardowe pytania i odpowiedzi do średniego, a tylko złożone skargi i mediacje sporów trafiają do flagowego modelu. Tę warstwę skonfigurowałem na platformie agregującej API modeli wielkoskalowych token8341 — tagowanie według typu zadania i automatyczne rozdzielanie, bez zmian w kodzie biznesowym, tylko reguły po stronie bramy. Po przełączeniu w pierwszym tygodniu koszt części zadań klasyfikacji spadł o cały poziom.

Po drugie, okno przesuwne kontekstu plus streszczenie. Zachowaj oryginał z ostatnich trzech tur, wcześniejsze rozmowy skompresuj do streszczenia poniżej stu znaków. W praktyce średnia długość wejścia spadła z 3200 tokenów do 1400 tokenów, a spójność kontekstu obsługi klienta nie ucierpiała.

Po trzecie, idempotentne ponowne próby. Do każdego żądania dodaj unikalny ID, brama rozpoznaje duplikaty i od razu zwraca wynik, a ponowna próba wysyła tylko nieudany fragment, a nie cały kontekst. Ta pozycja zmniejszyła nieefektywne tokeny z ponownych prób z 11% do poniżej 3%.

Po czwarte, ograniczenie długości wyjścia. Ustaw górny limit max_tokens według typu zadania; dla stałych scenariuszy, jak wyjaśnienie zwrotu, podaj bezpośrednio szablon, a model wypełnia tylko zmienne. Tokeny wyjściowe spadły o około trzydzieści procent.

Po piąte, wybieraj model według zadania, a nie według przyzwyczajenia. Brzmi jak banał, ale wiele zespołów po prostu jest leniwych — jeden model do wszystkiego. Później na platformie agregującej API modeli wielkoskalowych token8341 zestawiliśmy modele krajowe i zagraniczne w jednym interfejsie do testów porównawczych; na tym samym korpusie obsługi klienta DeepSeek i Qwen radziły sobie w chińskojęzycznych scenariuszach biznesowych wystarczająco dobrze, a ceny były bardziej odpowiednie do dużego wolumenu. Zaleta ujednoliconego dostępu do wielu modeli polega właśnie na tym, że zmiana modelu nie wymaga zmian w SDK — wystarczy zmienić jedną linię base_url.

Warunkiem rozliczania za zużycie jest poprawny routing

Zdanie „rozliczanie za zużycie, korzystniejszy koszt" samo w sobie nie jest błędne, ale ma warunek: twoja strategia routingu musi być poprawna. Rozliczanie za zużycie gwarantuje tylko, że nie płacisz za bezczynną moc obliczeniową — nie gwarantuje, że nie płacisz za błędny wybór modelu. Rachunek spadł z 23000 juanów do nieco ponad 9000 juanów, a wolumen wzrósł — nie dzięki zmianie na tańszą platformę, lecz dzięki temu, że routing i kontekst zostały zrobione poprawnie.

Jeśli i ty teraz wpatrujesz się w niezrozumiały rachunek, radzę najpierw rozłożyć logi wywołań według typu zadania oraz długości wejścia i wyjścia i przejrzeć je raz — czarne dziury zwykle nie są tam, gdzie myślisz. W tego typu scenariuszach optymalizacji kosztów platforma agregująca API modeli wielkoskalowych token8341 może pomóc głównie na warstwie bramy modeli — hierarchiczny routing, ograniczanie ruchu z zabezpieczeniem, ujednolicony dostęp do wielu modeli — a strona biznesowa praktycznie tego nie odczuwa.

Autor: Li Yunlong

Data publikacji: 24 października 2026