Xing4_0 dociera do SGLang: szósty PR i pierwszy podany rozmiar dla kolejnego MoE China Telecom

W odstępie dwóch godzin, 16 września 2026 r., dwa dominujące otwartoźródłowe stosy serwowania przestały się spierać o nazwę. vLLM zgłosił „[Model] Add Xing4_0 support” rano; sgl-project/sglang poszedł za nim z „feat: add Xing4_0 model support” o 10:38 UTC, a po sześciu tygodniach, w których w grze były trzy nazwy, oba frameworki mówią teraz Xing4_0. Pull request SGLang zawiera coś, czego nie zawierał żaden wcześniejszy: rozmiar. Opisuje model jako Xing4.0-29B-A4B, „MoE z 29 mld parametrów i około 4 mld aktywowanych parametrów”, i podaje polecenie uruchomienia wskazujące ścieżkę checkpointu, kontekst 262 144 tokenów oraz spekulatywne dekodowanie EAGLE. To nieopublikowany MoE China Telecom, ten sam, wokół którego od sierpnia krążą pull requesty XingChen4, i wciąż pozostaje nieopublikowany: wagi nie są publiczne, ścieżka checkpointu wskazywana w PR nie jest osiągalna dla nikogo spoza projektu, żaden dostawca nie potwierdził nazwy ani liczby, a nic w tym artykule nie zostało niezależnie zweryfikowane. Fakty zaczerpnięte z pull requestów są oznaczone jako takie; reszta to historia i wnioskowanie. Najbliższym modelem, który możesz dziś faktycznie wywołać, jest DeepSeek V4 Flash.

To tekst typu „co na razie wiemy”, aktualizowany na bieżąco, a nie pisany od nowa. Omawia sześciotygodniowy ciąg PR-ów i to, jak rozstrzygnięto kwestię nazewnictwa, co faktycznie wnoszą dwa pull requesty z 16 września, architekturę, którą pliki konfiguracyjne ujawniają teraz w prawdziwych szczegółach, oraz na co uważać w następnej kolejności. Wersja w jednym zdaniu: następny MoE China Telecom jest wystarczająco realny, by zebrać sześć integracji serwowania, wiersz tabeli w vLLM oznaczony jako TBA, wpis w dokumentacji SGLang oznaczony jako „coming soon” i podaną liczbę parametrów — a wciąż niewystarczająco realny, by uruchomić go gdziekolwiek, gdzie masz dostęp.

Sygnał: sześć integracji, trzy nazwy, sześć tygodni

Ślad zaczyna się wcześniej niż wersja tego tekstu, o której po raz pierwszy informowano, a jej dziennik commitów wciąż jest najbardziej wymownym artefaktem wycieku. Pierwszy PR do vLLM to #51237, otwarty 6 sierpnia 2026 r. pod tytułem „[WIP][Model] Add upcoming XingChen4 model support”. Jego trzy commity same opowiadają tę historię. Pierwszy nosi tytuł „Add TeleChat4 model support”. Drugi, nieco ponad godzinę później, to „chore: revert premature docs and test entry for telechat4” — dokumentacja i wpis testowy w rejestrze zostały wycofane jako przedwczesne. Trzeci, z 27 sierpnia, to „rename xingchen4”. Minutę później PR został zamknięty bez scalenia, a jedenaście minut po tym #54051 został otwarty z tym samym tytułem, tą samą gałęzią forka (supported_telechat4) i pojedynczym spłaszczonym commitem. W międzyczasie pojawiła się etykieta needs-rebase, więc wygląda to na zamknięcie i ponowne otwarcie po porządkach, a nie zmianę zdania. Wszystko zostało zgłoszone z konta GitHub zyp2014, a każdy commit został utworzony i podpisany przez zhangyp26 <zhangyp26@chinatelecom.com.cn>.

Ten drugi PR to ten, wokół którego pierwotnie powstał ten tekst, i nie jest już otwarty. #54051 został zamknięty przez samego autora 7 września 2026 r., bez scalenia. Warto jednak przytoczyć jego opis, ponieważ to zdanie przetrwało każdą zmianę nazwy i każde ponowne otwarcie:

Wagi modelu nie są jeszcze publiczne w Hugging Face Hub. Ten PR jest otwarty w celu wczesnego przeglądu kodu. Gdy wagi zostaną opublikowane, dodam wpis testowy w tests/models/registry.py, zaktualizuję docs/models/supported_models.md i oznaczę PR jako gotowy do przeglądu.

To zdanie jest kształtem całej historii: kod wyprzedza wagi. Poniższy zrzut ekranu to strona #54051 w postaci, w jakiej istniała 27 sierpnia 2026 r., w dniu jej otwarcia — datowana migawka, zachowana, ponieważ widoczne na niej żądanie ściągnięcia zostało od tego czasu zamknięte. Czytaj go jako zapis sygnału z tamtego momentu, a nie jako zapis jego obecnego statusu.

Następnie, 16 września wzorzec się powtórzył — dwa razy w ciągu jednego dnia. #57135, „[Model] Dodaj obsługę Xing4_0”, został otwarty tego ranka z tego samego konta, zyp2014, z pojedynczym commitem, którego autorem był teraz inny inżynier China Telecom — xiongji <xiongj9@chinatelecom.cn>. Zmieniono jedenaście plików, około 1 300 wstawień, nowa nazwa wszędzie i ta sama uwaga w tym samym miejscu: „Wagi modelu nie są jeszcze publicznie dostępne na Hugging Face Hub”.

Dwie godziny i dwadzieścia minut później drugi stos serwujący przestał pozostawać o jedno przemianowanie w tyle. sgl-project/sglang #39793, "feat: dodanie obsługi modelu Xing4_0", otwarty z gałęzi o nazwie support_xing4_0, a jego pojedynczy commit zawiera ten sam adres xiongji co zmiana nazwy vLLM. Czternaście plików i około 1400 wstawień, z czego nieco ponad tysiąc przypada na jeden plik modelu. To szósta integracja zgłoszona dla tego modelu w ciągu sześciu tygodni, a pierwsza zgłoszona jako niebędąca wersją roboczą: GitHub określa go jako otwarty i gotowy do przeglądu, z prośbą o dziesięciu recenzentów — a wszystkie trzy jego uruchomienia CI są już czerwone.

Strona SGLang do dziś działała tak, jak działała strona vLLM. #33982, „feat(model): add TeleChat4 model support”, został otwarty 7 sierpnia 2026 r. przez kontrybutora PaddyXj i zamknięty bez scalenia 31 sierpnia — tego samego dnia #37228, „feat: add XingChen4 model support”, został otwarty zamiast niego. Ten wciąż jest otwarty jako szkic autorstwa PaddyXj, na gałęzi o nazwie support_xingchen4, z trzema commitami i ostatnio modyfikowany 8 września. Jego lista kontrolna to najciekawszy element w obu frameworkach: model ładuje się i generuje „lokalnie, na wewnętrznych wagach” — odhaczone, wywoływanie narzędzi — odhaczone, parsowanie rozumowania — odhaczone — a publiczne CI — nie, ponieważ jest „zablokowane do czasu wydania wag”. Ktoś ma checkpoint. Nikt go nie opublikował. I w przeciwieństwie do vLLM, gdzie każde ponowne zgłoszenie najpierw zamykało poprzednika, SGLang ma teraz dwa aktywne pull requesty otwarte dla tego samego modelu, pod dwiema różnymi nazwami.

Sześć integracji w sześć tygodni nie sumuje się do silniejszej wersji tego samego sygnału; sumuje się do innego. Sześć integracji byłoby zgodne z zespołem, który iteruje. Sześć integracji pod trzema nazwami — TeleChat4, XingChen4, Xing4_0 — to zespół, który publicznie iteruje nad nazwą, pod którą model zostanie wypuszczony, podczas gdy wagi pozostają prywatne. To niezweryfikowane wnioskowanie i zarazem najbardziej doniosła rzecz, jaką obecnie pokazuje ślad PR.

Co tak naprawdę dodają te dwa wrześniowe PR-y

Pull request do vLLM to zmiana nazwy pracy z sierpnia, a nie jej przepisanie. Plik modelu to teraz vllm/model_executor/models/xing4_0.py, klasa to Xing4_0ForCausalLM, a model_type xing4_0 jest mapowany na DeepseekV3Config — tę samą konfigurację DeepSeek-V3, której używała wersja XingChen4. Co ze sobą niesie:

• Pełna implementacja modelu w vllm/model_executor/models/xing4_0.py — klasa Xing4_0ForCausalLM, z przebiegiem w przód, adapterem mHC oraz implementacją load_weights() z równoległością tensorową. Komunikat commita wskazuje, że obsługiwane są zarówno warianty DSA, jak i non-DSA, z ponownym wykorzystaniem współdzielonych operacji mhc_pre / mhc_post.

• Rejestracja Xing4_0ForCausalLM w vllm/model_executor/models/registry.py, aby vLLM rozpoznawał architekturę po nazwie.

• Parser rozumowania (vllm/reasoning/xing4_0_reasoning_parser.py) „dla wariantów obsługujących rozumowanie” oraz parser narzędzi (vllm/tool_parsers/xing4_0_tool_parser.py) do automatycznego wywoływania narzędzi.

• Rejestracja w vllm/config/speculative.py, vllm/transformers_utils/model_arch_config_convertor.py i vllm/transformers_utils/config.py — z komunikatem commita stwierdzającym, że nagłówek MTP zgodny z Deep​Seek-V3 jest włączony do dekodowania spekulacyjnego.

• Dwa pliki dokumentacji — autentycznie nowa część oraz bezpośrednie odwrócenie sierpniowej zmiany. Oryginalny commit zawierał wpis dotyczący dokumentacji i testów, który został wycofany godzinę później jako przedwczesny; wrześniowy PR przywraca dokumentację i jest oznaczony etykietami documentation, new-model i tool-calling.

Wpisy w dokumentacji vLLM to miejsce, w którym czytelnik po raz pierwszy dowiedział się czegoś konkretnego. W docs/models/supported_models.md, nowy wiersz zawiera `Xing4_0ForCausalLM` | Xing4_0 | TBA — kolumna checkpoint dosłownie mówi TBA, co jest tym samym „jeszcze nie” w innej czcionce. A w docs/features/tool_calling.md, pod nagłówkiem „Xing4_0 Models (xing4_0)”, PR dokumentuje format wywołań narzędzi modelu: wywołania są emitowane wewnątrz bloków <tool_call>...</tool_call>, w postaci albo JSON ({"name": ..., "arguments": {...}}), albo formy opartej na tagach używającej <param_key>...</param_key> i <param_value>...</param_value>. To jest poziom szczegółowości, którego wcześniejsze PR-y nie osiągnęły — szczegół implementacyjny formatu czatu modelu, zapisany w publicznej dokumentacji dużego frameworka, dla checkpointu, którego nikt nie może pobrać.

PR do SGLang jest ciekawszy, ponieważ dostarcza implementację i konfigurację, a nie wpis w rejestrze plus dokumentację. Jego wiersz w dokumentacji to pierwszy przypadek, gdy framework umieścił nazwę dostawcy we własnej dokumentacji. W docs/docs/supported-models/generative_models.mdx, nowy wiersz wymienia Xing4_0, a w kolumnie checkpointu widnieje `Xing4_0` (wkrótce) oraz opis: „model MoE firmy China Telecom z uwagą MLA i strumieniami resztkowymi mHC (Manifold-constrained Hyper-Connection); obsługuje natywne dekodowanie spekulatywne MTP, wywoływanie narzędzi i rozumowanie”. Wiersz vLLM zawierał TBA i nie wymieniał dostawcy; wiersz SGLang podaje China Telecom i mówi „wkrótce”. Żadne z tych stwierdzeń nie jest datą wydania, a wiersz w dokumentacji frameworka nie jest produktem.

Opis PR podaje liczbę, której brakowało we wszystkich poprzednich wersjach tej historii. „Ten PR dodaje obsługę Xing4.0-29B-A4B (MoE o 29 mld parametrów z ~4 mld aktywowanych parametrów).” Podaje też polecenie uruchomienia — --model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE — i stwierdza, że konfiguracja została zweryfikowana przy równoległości tensorowej 2, kontekście 262 144 tokenów i spekulacyjnym dekodowaniu EAGLE MTP, a transkrypcje odpowiedzi z rozumowaniem oraz wywołania narzędzia get_weather wklejono do opisu jako dowód. Wagi stojące za tą weryfikacją należą do samego autora: ścieżka repozytorium podana w PR nie jest publicznie dostępna, a organizacja Hugging Face, na którą wskazuje, nie wymienia żadnych publicznych modeli. Traktuj rozmiar, długość kontekstu i transkrypcje jako twierdzenia podane w PR, powiązane z prywatnym checkpointem, a nie jako pomiary, które ktokolwiek może powtórzyć. Wszystko to pochodzi z pull requesta i nie zostało odtworzone.

Pojawienie się parserów rozumowania i parserów narzędzi pod obiema nazwami ma znaczenie z tego samego powodu co w sierpniu. Parser rozumowania istnieje po to, by usuwać znaczniki myślenia z danych wyjściowych modelu — wewnętrzny łańcuch myśli, który model emituje przed udzieleniem ostatecznej odpowiedzi. Parser stworzony specjalnie dla tego modelu oznacza, że w rodzinie spodziewane są warianty zdolne do rozumowania, tak jak TeleChat3 wprowadził edycje Thinking. Parser narzędzi, wraz z obecnie udokumentowanym formatem wywołań, oznacza, że oczekuje się również natywnego wywoływania funkcji. Żaden z nich nie jest gwarancją co do finalnego produktu; oba są najsilniejszymi wskazówkami, jakie niosą PR-y na temat tego, do czego dąży China Telecom.

Co wiemy do tej pory, w pigułce.

Poniższa tabela wyników to ta zestawiona dla tego tekstu 27 sierpnia 2026 r. na podstawie PR-a vLLM w takim kształcie, w jakim wówczas był. Celowo pozostawiono ją tutaj jako datowany zapis, zamiast ją przerysowywać, ponieważ każdy jej wiersz pozostaje prawdziwy trzy tygodnie później — niewydane, wagi niepubliczne, szkielet DeepSeek, mHC residual, oba parsery uwzględnione. Tym, co się zmieniło, nie jest wartość na karcie, lecz wszystko wokół niej: cytowany przez nią PR vLLM zamknięto 7 września, praca pojawiła się ponownie pod nową nazwą 16 września, SGLang podążył za zmianą nazwy kilka godzin później, a wraz z nią pojawiła się pierwsza podana liczba parametrów. Nic na karcie nie jest błędne. Jest po prostu trzy tygodnie stara, a historia posunęła się dalej. Liczby FlagGems w jej ostatnim wierszu zostały przeniesione do nowego PR-a vLLM bez zmian, wciąż raportowane w PR i wciąż nieodtworzone.

Architektura, którą ujawniają PR-y.

Zmiana nazwy pliku nie zmienia nazwy architektury, a tekst podsumowania we wrześniowym PR do vLLM to sierpniowy tekst z Xing4_0 podstawionym w miejsce XingChen4 — zdanie w zdanie. Sygnał niosą dwa zdania:

• „Xing4_0 ponownie wykorzystuje szkielet Deep​Seek-V2/V3 (mechanizm uwagi MLA, blok MoE, opcjonalny indekser DSA).”

Zastępuje standardowe połączenie resztkowe za pomocą Manifold-constrained Hyper-Connections (mHC): strumień resztkowy jest rozszerzany do num_residual_streams równoległych strumieni, mieszanych przez zależne od wejścia, dwustochastyczne macierze generowane przez projekcję Sinkhorna-Knoppa.

Każda klauzula przekłada się na coś konkretnego. MLA to Multi-head Latent Attention, schemat kompresowanej uwagi wprowadzony przez DeepSeek w V2, który pozwala, by pamięć podręczna KV pozostawała mała; MoE to routing typu mixture-of-experts, który utrzymuje dużą liczbę parametrów przy niewielkim aktywnym śladzie. Opcjonalny indekser DSA to mechanizm DeepSeek Sparse Attention z linii V3.2 — lekki moduł oceniający, który wybiera top-k tokenów, na których należy skupić uwagę, zmniejszając koszt uwagi z kwadratowego do w przybliżeniu liniowego względem długości kontekstu. A zdanie o mHC to najważniejsza wiadomość: ten model przyjmuje architekturę rezydualną, którą sam DeepSeek wprowadził dopiero w tej generacji.

PR do SGLang jako pierwszy publikuje kształt tego rozwiązania, zamiast je opisywać. Jego plik konfiguracyjny, python/sglang/srt/configs/xing4_0.py, deklaruje 40 warstw ukrytych, wymiar ukryty 3584 i słownik 131 072 tokenów; MLA z rangą KV LoRA 512 i rangą query LoRA 768 w 32 głowicach; oraz rzadki MoE z 64 ekspertami routowanymi plus jednym ekspertem współdzielonym, routingiem top-4, punktacją sigmoidalną, współczynnikiem skalowania routowanych ekspertów 2,0 i wyborem ekspertów noaux_tc. Pola mHC również są jawne: hc_mult 4, dwadzieścia iteracji Sinkhorna-Knoppa, ograniczenie h_res na poziomie plus lub minus 30 oraz rope_theta 10 000 z maksymalnym embeddingiem pozycji 262 144. Są to wartości domyślne w integracji, która nie została jeszcze wydana, zgodnie z pull requestem — plik konfiguracyjny to deklaracja intencji, a nie karta modelu, a wartość 29B-A4B w opisie PR nie została z nich nigdzie publicznie wyprowadzona.

Jedno pole jest warte więcej niż pozostałe, ponieważ jest to pierwsze miejsce, w którym ten model w widoczny sposób przestaje być kopią DeepSeek. Konfiguracja SGLang ustawia hc_contract_for_draft, co scala strumienie mHC z powrotem do własnego rozmiaru ukrytego modelu przed końcową normalizacją i podaje ten skontraktowany tensor do głowy draftującej Eagle. DeepSeek V4 zamiast tego podaje tensor spłaszczony przez mHC o rozmiarze n-times-hidden_size. Komentarz w konfiguracji mówi o tym wprost, a jest to rodzaj szczegółu, który wychodzi na jaw dopiero wtedy, gdy implementacja została ukształtowana względem prawdziwego checkpointu — co, jak twierdzi lista kontrolna wcześniejszego PR-a SGLang, zostało zrobione, ale nie opublikowano tego.

Matematyka mHC to miejsce, w którym oba stosy różnią się implementacją, a w założeniu są zgodne. PR do vLLM zauważa, że „odpowiada współdzielonym operacjom w vllm.model_executor.layers.mhc, więc nie wprowadza się prywatnych kerneli” — ten moduł istnieje, ponieważ vLLM już obsługuje mHC dla DeepSeek V4, więc koszt przyrostowy dodania tego modelu jest niewielki. SGLang dochodzi do tego samego miejsca inną drogą: jego moduł mHC wykorzystuje sfuzjonowane kernele TileLang zarejestrowane jako niestandardowe operacje torch, a PR rozszerza istniejący kernel mhc_pre split-K, aby akceptował hc_hidden_size 14 336 obok dwóch rozmiarów, które już obsługiwał. Wyłącza także ścieżkę tf32_hc_prenorm_gemm DeepGEMM dla tej architektury, ponieważ ta ścieżka to surowe rozszerzenie C, którego torch.compile nie potrafi prześledzić; mHC zamiast tego trafia do kernela TileLang. Praktyczna przewaga jest taka sama w obu frameworkach: jeśli dziś obsługujesz DeepSeek V4 na vLLM lub SGLang, mechanizmy, które będą obsługiwać kolejny MoE China Telecom, są już zainstalowane.

mHC, sztuczka DeepSeek w centrum tego wszystkiego

Manifold-constrained Hyper-Connections warto omówić, ponieważ to absolutnie najciekawsza rzecz w tym modelu — i nie jest to wynalazek China Telecom. To wynalazek Deep​Seek.

Historia zaczyna się od Hyper-Connections, zaproponowanych przez zespół Ki​mi w 2024 roku. Standardowy Transformer utrzymuje jeden strumień rezydualny na warstwę: wejście jest dodawane do wyjścia warstwy, co daje gradientom czystą ścieżkę i pozwala sieci nauczyć się korekty rezydualnej. Hyper-Connections zastępuje ten pojedynczy strumień kilkoma równoległymi strumieniami, które są mieszane przez wyuczone macierze w każdej warstwie, dając modelowi znacznie bogatszą ścieżkę przepływu informacji. Haczyk tkwi w stabilności: nieograniczone macierze mieszające łamią właściwość odwzorowania tożsamościowego, która czyni połączenia rezydualne trenowalnymi, a przy skali biliona parametrów strata treningowa staje się niestabilna.

Wkład DeepSeek, opublikowany jako artykuł mHC w grudniu 2025 r., a następnie wykorzystany w DeepSeek V4, polegał na ograniczeniu macierzy mieszania do podwójnie stochastycznych — nieujemnych, w których każdy wiersz i każda kolumna sumują się do jedynki — wymuszanych przez projekcję Sinkhorn-Knopp podczas treningu. Macierz podwójnie stochastyczna ma promień spektralny dokładnie równy jeden, więc sygnały nie mogą być wykładniczo wzmacniane ani tłumione, gdy przechodzą przez setki warstw. To właśnie to ograniczenie zapewnia stabilność treningu w dużej skali, a projekcja jest na tyle tania, że DeepSeek zgłosił tylko około 6,7% narzutu treningowego przy czterech strumieniach rezydualnych. DeepSeek V4, wydany 24 kwietnia 2026 r., jest flagowym zastosowaniem tego rozwiązania, z raportowaną poprawą o około 15% w zadaniach rozumowania matematycznego, a do tego z kontekstem 1M tokenów.

A zatem, mówiąc wprost, te PR-y mówią: następny model China Telecom przyjmuje sprawdzony szkielet DeepSeek i najnowszy mechanizm rezydualny DeepSeek, zamiast wymyślać którykolwiek z nich od zera. To pragmatyczny wybór i niesie ze sobą subtelne potwierdzenie — drugie duże laboratorium po samym DeepSeek, które przyjmuje mHC, uważa, że ta sztuczka jest gotowa do produkcji.

PR-y nie są ukończone w kwestii mHC, a otwarte punkty uczciwie to przyznają. W PR-ach do vLLM autor zauważa, że obciążenia checkpointu (bias_pre, bias_post, bias_res) oraz ograniczenie h_res są obecnie scalone lub pominięte, a potwierdzenie przez recenzenta równoważności formuły jest „głównym pytaniem o poprawność”. Jest też niestandardowa operacja transpozycji, która utrzymuje tensor w układzie C-contiguous dla jądra TileLang — przemianowana razem ze wszystkim innym, z _xingchen4_transpose_contiguous na _xing4_0_transpose_contiguous — oraz twarde ograniczenie: równoległość potokowa nie jest obsługiwana w trybie mHC, gdy num_residual_streams jest większe niż jeden, natomiast równoległość tensorowa jest obsługiwana. Nic z tego nie dziwi w przypadku wersji roboczej, ale to ten sam niedokończony fragment, co w sierpniu, co samo w sobie jest pouczające: sześć tygodni zmian nazw nie ruszyło kwestii poprawności, a trzy czerwone przebiegi CI w najnowszym PR do SGLang to ta sama historia w innym kolorze. To, co konfiguracja SGLang rozstrzyga, to liczba strumieni. Przy hc_mult ustawionym na 4 i rozmiarze ukrytym 3 584, liczba 14 336 w łatce jądra to dokładnie cztery strumienie — a komentarz w jądrze mówi to wprost. To odczytanie było wnioskiem z samej liczby, gdy ten tekst ukazał się po raz pierwszy; teraz jest zapisane w pliku konfiguracyjnym.

Kąt przyspieszenia: FlagGems, ponownie

Drugi wątek wiąże ten model z istniejącą relacją China Telecom z Beijing Academy of Artificial Intelligence i jest to jedyny wątek, który przetrwał nienaruszony każde przemianowanie. PR do vLLM umożliwia opcjonalne przyspieszenie FlagOS/FlagGems za flagą środowiskową USE_FLAGOS, domyślnie wyłączoną, podstawiając jądra gorących ścieżek dla MoE, mechanizmu uwagi, softmax i top-k. Deklarowany zysk, z benchmarku H100 autora PR na obciążeniu o wysokiej współbieżności i długich promptach (ponad 10 tys. tokenów wejściowych, współbieżność 10): do 19,87% niższy czas do pierwszego tokenu i do 26,32% niższy czas na token wyjściowy, a inne obciążenia pozostają neutralne. Te liczby są raportowane w PR i nieodtworzone, a flaga jest domyślnie wyłączona.

Co warto odnotować, to jak niewiele zmieniła ta zmiana nazwy. Wrześniowy PR do vLLM zawiera te same liczby, tę samą wąską notkę o zakresie, że flaga znajduje się wyłącznie w pliku modelu, oraz tę samą instrukcję instalacji flagtree i flag-gems. Liczby się nie zmieniły, bo kod się nie zmienił; zmieniła się tylko etykieta. Pull requesty do SGLang w ogóle nie zawierają wątku FlagGems — zamiast tego obierają ścieżkę TileLang i DeepGEMM — co czyni z tego spór o to, do kogo należy optymalizacja warstwy serwowania, a nie o model.

To opowieść o ciągłości. TeleChat3-36B-Thinking był, według stanu na kwiecień 2026, pierwszym dużym modelem niezależnie przeniesionym do FlagOS, otwartoźródłowego stosu oprogramowania AI od BAAI. Niezależnie od tego, w jakiej formie ten model zostanie wydany, kontynuowanie tego wątku — z jądrami FlagGems wewnątrz własnej integracji z vLLM — wskazuje, że strategia krajowego stosu laboratorium obejmuje także warstwę serwowania, a nie tylko trenowanie.

Kwestia nazewnictwa i rodzina, z której się wywodzi

Do 16 września kwestia nazewnictwa była przypisem na marginesie. Teraz jest już niemal zamknięta, a dowody nadal tkwią wyłącznie w nazwach gałęzi i pozostałych ciągach znaków, a nie w oświadczeniach — ale oba frameworki zbiegły się do tej samej odpowiedzi, wychodząc z tego samego kierunku.

• Komunikaty commitów, w kolejności: „Dodaj obsługę modelu TeleChat4”, potem „chore: cofnij przedwczesną dokumentację i wpis testowy dla telechat4”, a następnie — trzy tygodnie później i minutę przed zamknięciem PR-a — „zmień nazwę xingchen4”. Commit, którego całym celem była zmiana nazwy.

Fork się rozgałęzia. Pierwsze dwa PR-y vLLM, #51237 i #54051, odgałęziono od zyp2014:supported_telechat4. Trzeci, #57135, to zyp2014:support_xing4_0. Nazwę gałęzi zmieniono w tym samym ruchu, w którym przemianowano model — a strona SGLang przeszła teraz identyczną ścieżkę w trzech krokach, od support_telechat4 przez support_xingchen4 do support_xing4_0.

• Treść #51237, w której stwierdzono, że przyspieszenie FlagGems było „dla TeleChat4”, podczas gdy w tym samym akapicie model nazwano XingChen4. Te dwie nazwy już ze sobą kolidowały w podsumowaniu samego autora z 6 sierpnia.

• Zmiana nazw plików po obu stronach. W vLLM było to xingchen4.py na xing4_0.py oraz XingChen4ForCausalLM na Xing4_0ForCausalLM; w SGLang jest to xingchen4.py na xing4_0.py oraz XingChen4Config na Xing4_0Config, na gałęzi, która wraz z nimi zmieniła nazwę. Żaden z PR-ów nie pozostawił starej nazwy nigdzie w swoim diffie.

A więc w dwóch frameworkach w grze były trzy nazwy, a wzorzec jest spójny z jednym modelem, któremu zmienia się nazwę w miarę zbliżania się do jego przyszłej nazwy publicznej. „Xing4_0” naturalnie czyta się jako Xingchen 4.0 — rodzina modelu w języku chińskim nosi markę 星辰 (Xingchen) — ale to wciąż wnioskowanie z ciągu znaków, a nie coś, co jakikolwiek PR podaje wprost. Równie dobrze może być tak, że TeleChat4 i XingChen4 są rodzeństwem w tej samej generacji, a nie jednym modelem pod dwiema nazwami, choć wspólny fork, wspólny akapit o architekturze, wspólne liczby FlagGems, wspólne otwarte pozycje, a teraz wspólna zmiana nazwy sprawiają, że trudniej to argumentować. Nikt nie potwierdził tego związku, a China Telecom nie skomentował. Zmieniło się to, że zmiana nazwy nie jest już wyborem jednego współtwórcy: dwa niezależne projekty serwujące, utrzymywane przez różne osoby, oba zmieniły etykiety swoich integracji na tę samą trzecią nazwę w odstępie krótszym niż dzień.

Samą rodzinę warto mieć na uwadze, ponieważ wyjaśnia ona ten pragmatyzm. Dotychczasowe publiczne wydania nosiły markę TeleChat:

• TeleChat-7B i TeleChat-12B – udostępnione jako open source w styczniu 2024 roku, z korpusem obejmującym bilion tokenów.

• TeleChat2-115B (wrzesień 2024), reklamowany jako pierwszy w pełni krajowy otwarty model o bilionie parametrów, a także jego mniejsze wersje 35B, 7B i 3B.

• TeleChat2-39B-A12B (marzec 2025), pierwszy MoE w tej rodzinie.

• TeleChat3-105B-A4.7-Thinking (grudzień 2025), drobnoziarnisty MoE z 105 mld parametrów łącznie i 4,7 mld aktywnych, trenowany na 15 bilionach tokenów, wraz z gęstym TeleChat3-36B oraz późniejszym TeleChat3-Coder-36B-Thinking.

Jeśli liczba 29B-A4B się utrzyma, ten model plasowałby się poniżej TeleChat3-105B-A4.7-Thinking zarówno pod względem całkowitej, jak i aktywnej liczby parametrów — mniejszy, tańszy krewniak, a nie flagowiec mający zastąpić poprzednika. To interpretacja, nie fakt; w żadnym z tych dwóch PR-ów nie napisano, do jakiego segmentu model jest adresowany. Marka Xingchen to miejsce, w którym firma lokuje swoje wysiłki w AI: Xingchen AGI Lab został formalnie utworzony w Pekinie w marcu 2026 r., bazując na tej samej rodzinie modeli, a China Telecom opisuje swój system „三全” (pełnomodalny, pełnowymiarowy, w pełni krajowy) jako obejmujący modele semantyczne, mowy, wizji i multimodalne od 1B do 1T+ parametrów. Zmiana nazwy z TeleChat na Xingchen to dokładnie to, co robi laboratorium, gdy chce, aby rodzina modeli nosiła markę laboratorium, a nie markę linii produktowej.

Czego wciąż nie wiemy

Jak na tak wczesny model, lista uczciwie przyznanych niewiadomych jest wciąż dłuższa niż lista znanych, choć w tym tygodniu zwęziła się w dwóch miejscach:

• Brak daty wydania. Pięć z sześciu integracji to wersje robocze otwarte do wczesnego przeglądu kodu, właśnie dlatego że wagi nie są publiczne. Szósta, SGLang #39793, jest otwarta do przeglądu, a nie jako wersja robocza — ale nie została scalona, wszystkie trzy jej przebiegi CI kończą się niepowodzeniem i potrzebuje recenzenta, który ją zatwierdzi. Nie ogłoszono żadnego harmonogramu.

• Liczba parametrów, ale tylko deklarowana. Wszystkie poprzednie wersje tego tekstu podawały konfigurację MoE jako nieujawnioną. PR do SGLang zmienia to na papierze: Xing4.0-29B-A4B, łącznie 29B, około 4B aktywnych. Ta liczba pochodzi z pull requesta, nie jest powiązana z żadnym publicznym checkpointem, nie potwierdza jej żaden plik konfiguracyjny i nie odtworzył jej nikt spoza projektu. Traktuj ją jako deklarację intencji, a nie specyfikację.

• Żadnych liczb benchmarkowych, ani raportowanych przez producenta, ani jakichkolwiek innych, i żadnych niezależnych wyników. Transkrypcje weryfikacyjne w PR do SGLang pokazują, jak model odpowiada na prompt wymagający rozumowania i generuje poprawnie sformułowane wywołanie narzędzia; nie mówią one jednak nic o tym, jak dobrze radzi sobie z którymkolwiek z nich.

• Brak informacji o cenie i brak potwierdzonej licencji. Każde wcześniejsze wydanie TeleChat miało licencję Apache-2.0, co napawa optymizmem, ale dla tego wydania nie podano żadnej licencji.

• Brak publicznych wag — potwierdzone, a nie założone. Na dzień 16 września 2026 r. ścieżka w Hugging Face, którą wskazuje PR SGLang, nie jest publicznie dostępna do odczytu, a organizacja, na którą wskazuje, nie wymienia żadnych publicznych modeli; najnowszym publicznym wpisem w rodzinie jest TeleChat3-Coder-36B-Thinking ze stycznia. Tabela obsługiwanych modeli vLLM podaje TBA w kolumnie checkpoint, tabela SGLang mówi „wkrótce”, a oba PR-y SGLang mają nieprzechodzące publiczne CI.

• Żadnego oficjalnego komunikatu od China Telecom — żadnej zapowiedzi, żadnych wag, żadnego potwierdzenia nazwy ani rozmiaru. Uważnie zwróć uwagę na tę asymetrię: wiersz w dokumentacji SGLang przypisuje model firmie China Telecom, ale to opis współtwórcy wewnątrz pull requesta, a nie oświadczenie firmy, a najnowszy opis PR całkowicie pomija nazwę dostawcy. Sześć integracji tworzonych dla tego modelu to jak dotąd najsilniejszy dowód, że jest prawdziwy, ale integracje bywają zamykane, a nazwy kodowe się zmieniają; dwie już zostały zamknięte. Dopóki laboratorium tego nie ogłosi, nic nie jest potwierdzone.

Właściwym odczytem tego wszystkiego nie jest sceptycyzm wobec modelu; to trafny obraz wczesnego sygnału. To, co istnieje dzisiaj, to prawdziwy artefakt inżynieryjny — sześć takich, w dwóch frameworkach — z prawdziwą architekturą i po raz pierwszy określonym kształtem. To, czego jeszcze nie ma, to cokolwiek, co można by pobrać, wywołać lub poddać benchmarkowi.

Najbliższa rzecz, którą możesz dziś uruchomić.

Tego modelu nie można nigdzie udostępnić jako usługi — ani przez API, ani lokalnie, ponieważ jego wagi nie są publiczne. Najbliższym modelem, który czytelnik może dziś faktycznie wywołać i który dzieli jego architektoniczne DNA, jest DeepSeek V4 Flash — stosuje on ten sam schemat resztkowy mHC nakładany na MLA i MoE i jest referencyjną implementacją, dla której zbudowano współdzielone moduły mHC w obu frameworkach. Strona modelu deepseek/deepseek-v4-flash w OrcaRouter podaje kontekst wynoszący 1 mln tokenów, maksymalne wyjście 384 tys. tokenów oraz ceny katalogowe: 0,15 USD za milion tokenów wejściowych i 0,29 USD za milion tokenów wyjściowych — te same liczby, które publikuje sam Deep​Seek, przekazywane bez marży (0%), więc zmiana ceny u dostawcy jest tu widoczna tego samego dnia. Jeden klucz API obejmuje cały katalog, co sprawia, że porównanie go z resztą kategorii modeli rozumujących to reguła routingu, a nie nowa integracja.

To także praktyczna odpowiedź na pytanie „jak wypróbować ten model, gdy zostanie wydany”. Zupełnie nowy, niesprawdzony checkpoint to dokładnie ten przypadek, w którym automatyczny failover ma swoje uzasadnienie: skierować do niego ułamek ruchu, zachować sprawdzony model jako fallback i pozwolić, by to warstwa routingu podejmowała decyzję, zamiast stawiać ścieżkę produkcyjną na zachowaniu z pierwszego dnia. 29B MoE z około 4B aktywnych parametrów, jeśli właśnie taki się pojawi, jest tanim kandydatem do routowania względem modelu typu frontier właśnie dlatego, że tak niewiele z niego aktywuje się na token. Jeśli nazwa zmieni się ponownie między teraz a wydaniem — a ostatnie sześć tygodni sugerują, że może — to regułę routingu przepisujesz, a nie integrację.

Często zadawane pytania

Dlaczego PR w vLLM został zamknięty?

Widzimy zamknięcie, ale nie powód. #54051 został zamknięty przez samego autora 7 września 2026 r. bez scalenia, a praca pojawiła się ponownie dziewięć dni później jako #57135 pod nową nazwą. Wcześniejszy PR w vLLM, #51237, został zamknięty i zgłoszony ponownie tego samego dnia pod tym samym tytułem, więc zamykanie i ponowne zgłaszanie to schemat tego autora, a nie oznaka problemów — ale treści PR-ów nie podają powodu i nie zamierzamy go wymyślać.

Kiedy zostanie wydany Xing4_0?

Nie ma daty. Pięć z sześciu integracji to szkice otwarte do wczesnego przeglądu kodu, a plany samych autorów zakładają dodanie wpisów testowych, aktualizację dokumentacji i oznaczenie PR-ów jako gotowych dopiero po wydaniu wag. Starsza lista kontrolna SGLang najklarowniej przedstawia stan rzeczy: „Model ładuje się i generuje (lokalnie, na wagach wewnętrznych)” jest zaznaczone, a publiczne CI jest „zablokowane do czasu wydania wag”. Nowszy PR SGLang został zgłoszony jako gotowy do przeglądu, a nie jako szkic, co jest zmianą nastawienia, a nie zmianą statusu — nie został scalony, jego CI jest czerwone, a wiersz dokumentacji z napisem „wkrótce” nie jest premierą.

Czy Xing4_0 to ten sam model co XingChen4?

Prawie na pewno tak, a PR-y pozwalają to łatwo sprawdzić: ta sama linia pochodzenia forka, ten sam akapit o architekturze, te same liczby benchmarków FlagGems, te same otwarte pozycje i zmiana nazw plików jeden do jednego w obu frameworkach — xingchen4.py na xing4_0.py, wraz z klasą config, na gałęziach przemianowanych tak, by pasowały. To ta sama praca pod nową nazwą, a od 16 września zarówno vLLM, jak i SGLang przyjęły tę nazwę. Żaden PR nie mówi jednak, jaką nazwę będzie nosić wydany checkpoint.

Czy to jest model DeepSeek?

Nie. To model China Telecom, z Xingchen AGI Lab. Powiązanie z Deep​Seek ma charakter architektoniczny: ponownie wykorzystuje szkielet Deep​Seek-V2/V3 oraz schemat resztkowy mHC, który Deep​Seek zaproponował i wdrożył w V4. Przyjęcie czyjejś architektury to nie to samo, co powiązanie obu projektów.

Co obejrzeć dalej

PR-y nadal dają konkretną listę kontrolną, a para z 16 września dodała do niej dwa punkty. Po pierwsze, wagi: każdy autor powiedział, że jego praca czeka na Hugging Face, więc pojawienie się publicznego repozytorium to wydarzenie, na którym wszystko się opiera — a PR SGLang podaje teraz dokładną ścieżkę do obserwowania — XingChen-AGI/Xing4.0-29B-A4B — która obecnie nie rozwiązuje się dla nikogo. Po drugie, same PR-y: PR vLLM wymaga potwierdzenia wzorów biasu mHC, dodania wpisu testowego do rejestru i zielonego CI; #39793 SGLang wymaga naprawy trzech czerwonych przebiegów i zatwierdzenia przez dziesięciu poproszonych recenzentów, podczas gdy starszy #37228 wciąż potrzebuje swojego wpisu testowego, swojego benchmarku przyspieszenia MTP i odblokowanego CI. Po trzecie, nowe w tym tygodniu: czy SGLang zamknie #37228 na rzecz #39793 tak, jak vLLM zawsze zamykał poprzednika przed ponownym zgłoszeniem. Dwie aktywne integracje dla jednego nieopublikowanego modelu to stan, którego nikt nie utrzymuje długo, a to, która przetrwa, mówi coś o tym, jak blisko jest to w rzeczywistości. Po czwarte, liczby: czy wydany checkpoint zgadza się z kształtem 29B-A4B, MoE z 64 ekspertami i kontekstem 262 144 tokenów, które teraz deklarują konfiguracja i opis PR-a. Po piąte, czy trzeci PR vLLM przetrwa dłużej niż jego dwa poprzednie PR-y, które przetrwały odpowiednio 21 i 11 dni, zanim zostały zamknięte bez scalenia. I obserwuj, czy parsery rozumowania opisują osobny wariant Thinking tak, jak TeleChat3 wydał swój.

Dopóki jedno z nich się nie stanie, traktuj ten model jako to, czym jest: dobrze wyspecyfikowany plan od poważnego laboratorium, przyłapanego na gorącym uczynku przygotowywania swojej infrastruktury serwowania — teraz w obu głównych otwartoźródłowych stosach serwowania, pod nazwą, którą oba przyjęły, i w rozmiarze, który podaje tylko jego własny pull request. Sama architektura sprawia, że warto go śledzić: to drugie duże przyjęcie mHC po samym Deep​Seek, z laboratorium, którego poprzednia generacja była już drobnoziarnistym modelem MoE trenowanym na krajowych chipach. Gdy wagi zostaną udostępnione, nie będzie wątpliwości, czy działa w vLLM, czy w SGLang. Oba stosy napisały ten kod trzykrotnie, pod trzema różnymi nazwami.