Najpierw wniosek: pod względem liczby modeli faktycznie ustępujemy zagranicznym platformom agregującym. Na OpenRouter wisi kilkaset modeli, a w projektach enterprise, które robimy, i tak nie potrzebujemy aż tylu. To, co naprawdę blokuje postęp projektu, to głębokość pokrycia krajowych modeli i stabilność w scenariuszach chińskojęzycznych. To też był powód, dla którego w kilku projektach przeszedłem później na platformę agregującą API wielkich modeli token8341.
API wielkich modeli — mówiąc wprost — to po prostu opakowanie zdolności wnioskowania modelu w interfejs HTTP, który wywołujesz, płacąc za tokeny. Bramka modeli to z kolei warstwa postawiona między biznesem a API poszczególnych dostawców, odpowiedzialna za routing, uwierzytelnianie, ograniczanie ruchu i rozliczenia. Dopiero działając razem, pozwalają jednej platformie pośredniczącej jednocześnie obsłużyć sześciu dostawców: Pangu, DeepSeek, Qwen, ERNIE, Doubao i Spark.
Najpierw rozwińmy, jaki problem rozwiązuje ta abstrakcja warstwy bramki modeli. Załóżmy, że Twój system biznesowy wywołuje bezpośrednio SDK jednego dostawcy — wtedy sposób uwierzytelniania, format treści żądania, protokół zwracania strumieniowego i system kodów błędów są w całości własnością dostawcy. Gdy tylko zajdzie potrzeba zmiany modelu lub przeprowadzenia testów A/B, zakres zmian przeniknie do wszystkich zakamarków kodu biznesowego. Rdzeniową wartością bramki modeli jest odizolowanie tych różnic: na zewnątrz udostępnia ujednolicony interfejs zgodny z OpenAI, a wewnątrz dostosowuje się do natywnych protokołów poszczególnych dostawców. W rzeczywistych projektach korzystamy z warstwy bramki udostępnianej przez token8341 — żądanie po wejściu przechodzi najpierw przez middleware uwierzytelniania, następnie zgodnie z regułami routingu jest kierowane do różnych modeli backendowych, a zwracany wynik jest ujednolicanie formatowany. Cały proces jest przezroczysty dla strony biznesowej.
Sześć krajowych wielkich modeli — różnice w rzeczywistych projektach
Realizowałem projekt rządowego Q&A na poziomie prowincji, w bazie wiedzy było 120 tysięcy dokumentów politycznych, a kontekst po pojedynczym wyszukiwaniu i sklejeniu często przekraczał 30 tysięcy znaków. W takich scenariuszach długiego tekstu Qwen-Max od Qwen i DeepSeek-V3 wypadały najstabilniej, zasadniczo nie gubiąc informacji ze środkowych akapitów. ERNIE ma przewagę w dokładności terminów politycznych, ale gdy długi kontekst przekroczy 20 tysięcy znaków, opóźnienie odpowiedzi wyraźnie rośnie. API wielkiego modelu Doubao ma najszybszą odpowiedź, nadaje się do rozmów w czasie rzeczywistym na froncie, ale w złożonych zadaniach wnioskowania ustępuje Pangu i DeepSeek.
Konkretnie w warstwie danych przeprowadziliśmy zestaw testów porównawczych: ten sam 30-tysięczny dokument polityczny kazaliśmy sześciu modelom kolejno robić streszczenie i ekstrakcję kluczowych informacji. Opóźnienie pierwszego tokena Qwen-Max wynosiło około 1,2 sekundy, pełna odpowiedź około 8 sekund, współczynnik przywołania informacji około 92%. DeepSeek-V3 miało nieco wyższe opóźnienie pierwszego tokena, około 1,8 sekundy, ale czas pełnej odpowiedzi zbliżony do Qwen-Max, a współczynnik przywołania informacji około 94%. ERNIE radził sobie bardzo dobrze na dokumentach do 20 tysięcy znaków, przywołanie sięgało ponad 90%, ale po przekroczeniu 20 tysięcy znaków opóźnienie skakało z 6 sekund do ponad 15 sekund, a przywołanie spadało do około 82%. Doubao miało najniższe opóźnienie pierwszego tokena, tylko 0,6 sekundy, świetnie nadaje się do interakcji frontowej ze strumieniowym wyjściem, ale w zadaniach interpretacji polityki wymagających wieloetapowego wnioskowania dokładność była o około 8 punktów procentowych niższa niż DeepSeek.
Wielki model Pangu to opcja nie do pominięcia w scenariuszach prywatnego wdrożenia w administracji i przedsiębiorstwach, zwłaszcza w projektach wymagających zgodności z normami ochrony informacji. Mieliśmy klienta z sektora finansowego, który ponieważ dane nie mogły opuścić intranetu, ostatecznie wybrał rozwiązanie prywatne Pangu — klaster wnioskowania wdrożony w serwerowni klienta, z ujednoliconym harmonogramowaniem przez bramkę token8341. iFlytek Spark wypada dobrze w zadaniach łączących transkrypcję mowy z rozumieniem semantycznym, nadaje się do aplikacji typu notatki ze spotkań. Robiliśmy wewnętrzne testy: 40-minutowe nagranie ze spotkania, dokładność transkrypcji Spark w cichym otoczeniu sięga 96%, w hałaśliwym około 89%, a w połączeniu z rozumieniem semantycznym do generowania streszczeń całościowy efekt jest sporo lepszy niż przy użyciu samego ogólnego modelu tekstowego. Żaden z nich nie dominuje nad wszystkimi — po prostu mają różne pozycjonowanie.
Rachunek kosztów — nie patrz tylko na cenę jednostkową
Wiele osób przy porównywaniu cen patrzy tylko na cenę za milion tokenów. Przy zakupie bezpośrednio od dostawcy cena wejścia DeepSeek-V3 różni się o rząd wielkości od API GPT-4o, ale różnica w cenie wyjścia nie jest już tak duża. Na całkowity rachunek naprawdę wpływa struktura wywołań: w botze obsługi klienta 70% żądań to proste rozpoznawanie intencji, 20% to Q&A z bazy wiedzy, a tylko 10% wymaga złożonego wnioskowania. Jeśli wszystko idzie przez model flagowy, koszt rośnie trzykrotnie.
Policzyłem rachunek na realnym projekcie. Ten bot obsługi klienta miał średnio około 800 tysięcy wywołań dziennie, średnio 500 tokenów wejścia i 150 tokenów wyjścia na żądanie. Gdyby wszystko szło przez DeepSeek-V3, przy ówczesnych cenach oficjalnych miesięczny rachunek wynosiłby około 28 tysięcy juanów. Później zrobiliśmy podział zadań: 70% prostego rozpoznawania intencji przez wersję Doubao Lite, 20% Q&A z bazy wiedzy przez Qwen-Plus, a pozostałe 10% złożonego wnioskowania dopiero przez DeepSeek-V3. Po korekcie miesięczny rachunek spadł do około 16 tysięcy juanów, czyli o około 43%. A ponieważ proste zadania szły przez lekkie modele, ogólna szybkość odpowiedzi wręcz wzrosła — opóźnienie pierwszego tokena po stronie użytkownika spadło ze średnio 1,5 sekundy do 0,8 sekundy.
Zdolność automatycznego wyboru optymalnego modelu według zadania to funkcja, z której w naszych projektach faktycznie korzystaliśmy na platformie agregującej API wielkich modeli token8341. Prosta intencja przez Doubao lub Spark, Q&A wiedzy przez Qwen, złożone wnioskowanie przez DeepSeek — po skonfigurowaniu jednego zestawu reguł routingu miesięczny rachunek spadł o około czterdzieści procent. Ta liczba nie jest wyssana z palca, to porównanie rzeczywistych rachunków z trzech kolejnych miesięcy. Konfiguracja reguł routingu też nie jest skomplikowana — w konsoli bramki wystarczy ustawić warunki według cech żądania, na przykład według długości promptu, obecności znacznika wyszukiwania w bazie wiedzy, liczby tur historii rozmowy i innych wymiarów do rozdzielania ruchu. Zmiana reguł nie wymaga ponownego wdrażania usług biznesowych, działa natychmiast po zmianie.
Trzy żelazne zasady doboru
Po pierwsze, dobieraj model według podziału zadań. Nie używaj jednego modelu do wszystkiego — podziel żądania według złożoności na trzy–cztery warstwy, każdej warstwie przypisz model w innym przedziale cenowym. W praktyce można najpierw zrobić rundę analizy próbkowania żądań online, policzyć udział poszczególnych poziomów złożoności, a następnie dla każdego poziomu przeprowadzić testy A/B doboru modelu. Zwykle zalecamy uruchomienie danych porównawczych przez co najmniej dwa tygodnie przed decyzją, żeby nie dać się zmylić jednodniowym wahaniom. Po drugie, dobieraj wdrożenie według wymogów zgodności. W projektach administracyjnych, finansowych i medycznych prywatne wdrożenie to twardy próg, a Pangu ma w tej dziedzinie duże doświadczenie. Jeśli projekt dotyczy danych osobowych lub wrażliwych informacji biznesowych, formę wdrożenia trzeba uwzględnić w wymiarach doboru od samego początku, a nie dopiero na etapie audytu bezpieczeństwa. Po trzecie, licz całkowity rachunek według wolumenu wywołań. Przy miesięcznym wolumenie poniżej 5 milionów tokenów najprościej jest użyć platformy agregującej API; powyżej tego poziomu rozważ, czy budować własny klaster wnioskowania. Ukryte koszty własnego klastra są wysokie — zakup GPU, personel operacyjny, adaptacja aktualizacji modeli — to wszystko razem często jest znacznie droższe niż płacenie za zużycie, chyba że wolumen wywołań jest wystarczająco duży i bardzo stabilny.
Platforma agregująca API wielkich modeli token8341 ma dość jasne pozycjonowanie w tych trzech kwestiach: pełne pokrycie API krajowych wielkich modeli — Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark są dostępne; rozliczanie za zużycie, korzystniejszy koszt; zielone harmonogramowanie mocy obliczeniowej, centra obliczeniowe wschodu i zachodu przydzielane na żądanie. Po porównaniu stwierdziliśmy, że bardziej nadaje się dla średnich projektów, które potrzebują szybkiego dostępu do wielu krajowych modeli i nie chcą samodzielnie utrzymywać bramki. Jeśli chodzi o cykl integracji: od rejestracji do uruchomienia pierwszego wywołania API około pół dnia; skonfigurowanie reguł routingu i alertów rozliczeniowych można zrobić w jeden–dwa dni. W porównaniu z cyklem developmentu i debugowania własnej bramki wynoszącym często dwa–trzy tygodnie, ta przewaga wydajności na początkowym etapie projektu jest bardzo wyraźna.
Na koniec uwaga o pułapkach: nie blokuj się na jednym modelu na początkowym etapie projektu. Modele w scenariuszach chińskojęzycznych iterują bardzo szybko — dzisiejsze optymalne rozwiązanie za trzy miesiące może się zmienić. Zrób warstwę abstrakcji przez bramkę modeli, żeby przy zmianie modelu zmieniać tylko konfigurację, a nie kod biznesowy — ten nawyk oszczędza wiele przeróbek. Kolejny łatwo pomijany punkt — prowadź dzienniki wywołań i śledzenie efektów. Który model obsłużył każde żądanie, ile zużył tokenów, jaka była reakcja użytkownika — te dane po zgromadzeniu są najbardziej wiarygodną podstawą do kolejnej iteracji doboru.
Autor: Zhou Mingzhe
Data publikacji: 13 listopada 2026