Hy4 Preview ma limit 1M tokenów, lecz receptury SGLang pokazują 262K

Hy4 Preview ma 1 048 576 pozycji kontekstu w konfiguracji i otwarte wagi na licencji Apache 2.0. Aktualne receptury SGLang nie pokazują jednak konfiguracji dłuższej niż 262 144 tokeny, a wariant skompresowany do 213,66 GiB wymaga wersji llama.cpp z dwiema dodatkowymi łatami. Te liczby opisują trzy różne ograniczenia: limit modelu, pamięć potrzebną na wagi i cache KV oraz dojrzałość oprogramowania do inferencji.

Kwantyzacja zmniejsza pamięć wag, ale cache KV nadal ogranicza kontekst

Co się wydarzyło

28 sierpnia 2026 r. Tencent opublikował Hy4 Preview wraz z wagami BF16 i FP8. Rdzeń modelu ma 770 mld parametrów, z czego 49 mld jest aktywowanych dla jednego tokena. Pierwsza z 78 warstw używa gęstego FFN, a pozostałe 77 zawiera po 256 ekspertów routowanych i jednego współdzielonego; dla tokena wybieranych jest ośmiu ekspertów routowanych oraz ekspert współdzielony. Poza rdzeniem znajduje się warstwa MTP o 10 mld parametrów, z 0,7 mld aktywnych, przeznaczona do dekodowania spekulacyjnego. Repozytorium i karta modelu, licencja Apache 2.0

Model używa Gated DeepSeek Sparse Attention. Indekser wybiera dla zapytania 2048 pozycji, a IndexCache pozwala kilku warstwom korzystać z wcześniej wyznaczonych indeksów. Nie usuwa to kosztu przechowywania stanu długiej sekwencji. Konfiguracja określa maksymalnie 1 048 576 pozycji, ale rzeczywisty kontekst zależy od formatu wag, liczby akceleratorów, pamięci pozostającej na cache oraz ustawionej współbieżności. Konfiguracja modelu, opis architektury i parametrów

Po premierze zespół rozwijanego przez Tencent narzędzia AngelSlim udostępnił dwa pliki GGUF. Wariant Q4_K_M zajmuje 435,20 GiB, a MIX-STQ1_0 — 213,66 GiB przy średnio 2,38 bitu na wagę. MIX-STQ1_0 nie stosuje jednego formatu do całego modelu: w części warstw projekcje ekspertów mają 1,3125 bitu na wagę, w pozostałych 2,0625, natomiast router, normalizacje, wybrane elementy uwagi i głowica wyjściowa zachowują większą precyzję. Pliki GGUF i opis doboru precyzji

Co potwierdzają źródła

Dokumentacja SGLang podaje około 1,5 TB dla wag BF16 i około 760 GB dla MXFP8. Szacuje też około 95 KB cache na token na każdą rangę tensor parallelism. Na 16 kartach H200 z BF16 zaleca kontekst 131 072 tokenów. Zweryfikowane konfiguracje dla B200, B300 i GB300 dochodzą do 262 144 tokenów. Dokumentacja wyraźnie zaznacza, że milion pozycji zapisany w modelu przekracza pulę pamięci tych receptur; nie przedstawia działającej konfiguracji 1M. Tabela pamięci i zweryfikowanych konfiguracji SGLang

Eksperymentalna ścieżka vLLM-Ascend dokumentuje znacznie krótszy kontekst na innej klasie sprzętu. Wagi W8A8 zajmują około 762 GB. Jeden węzeł Atlas 800I A3 z 16 kartami obsługuje według dokumentacji około 1K kontekstu, a udokumentowana konfiguracja dwóch węzłów ustawia 96K. Kod obsługi nie został jeszcze scalony do głównego repozytorium vLLM-Ascend, instalacja ze źródeł nie jest wspierana, a walidacja niezawodności i optymalizacja wydajności nadal trwają. To ograniczenia tej konkretnej implementacji, a nie dowód, że żadna infrastruktura nie obsłuży 1M. Eksperymentalna instrukcja vLLM-Ascend

Kwantyzacja GGUF istotnie zmniejsza koszt samych wag, lecz nie jest jeszcze standardową ścieżką wdrożenia. Pełne umieszczenie MIX-STQ1_0 wymaga około 214 GiB pamięci. Autorzy zmierzyli na ośmiu kartach H20 204,56 ± 1,42 tokena/s dla prefillu pp512 oraz 19,52 ± 0,01 tokena/s dla dekodowania tg128. Test obejmuje krótki prompt i 128 tokenów generacji, więc nie mówi, jak przepustowość zachowa się przy długim kontekście ani wielu równoczesnych żądaniach. Architektura hyv4 nie jest jeszcze obsługiwana przez standardowe llama.cpp; instrukcja przypina konkretny commit i nakłada dwie łaty, z których jedna dodaje nowy format kwantyzacji. Metoda, wymagania i pomiar GGUF

Tencent podał, że po przejściu z BF16 do MIX-STQ1_0 wyniki spadły z 83,7 do 83,2 w MCP-Atlas, z 82,9 do 81,3 w SWE-bench Multilingual, z 81,3 do 81,1 w MRCR i z 73,5 do 72,5 w IFBench. Są to wyniki zespołu związanego z modelem i kwantyzacją. Nie opublikowano jeszcze niezależnej reprodukcji tych czterech porównań, dlatego nie można zamienić ich w ogólne twierdzenie o zachowaniu określonego procentu możliwości modelu. Wyniki ogłoszone przez zespół Hy

Wewnętrzna ocena Tencent nie rozstrzyga pozycji pełnego modelu. W ślepym teście 163 pracowników firmy oceniło 203 zadania inżynierskie: średnia Hy4 wyniosła 2,99/4, GLM-5.3 — 2,92, a Kimi K3 — 2,94. Hy4 przegrywał odpowiednio 40,4% i 40,9% porównań, a publikacja nie podaje wariancji, zgodności oceniających ani pełnego zestawu zadań. Jest to użyteczny wynik wewnętrzny, lecz nie niezależny ranking. Metoda i wyniki oceny Tencent

Dwa wczesne testy zewnętrzne nie wystarczają do ustalenia pozycji modelu. OpenVibeEval ma siedem poprawnych przebiegów generowania interfejsów: model uzyskał wysokie oceny na statycznych układach, ale słabsze na zadaniach wymagających obsługi stanu, w tym 42 punkty dla edytora wektorowego i 0 w audycie dostępności terminala transakcyjnego z niepodłączonymi kontrolkami. Autor zaznacza, że porównanie z Hy3 jest obciążone zmianą harnessu. W ARI Bench jedyny z trzech wymaganych przebiegów zakończył się 4% trafień na ukrytym zbiorze mimo 92–96% na publicznej kalibracji; ponowne uruchomienie końcowego artefaktu odtworzyło 4%. To mocny sygnał błędu selekcji w tym jednym zadaniu, ale za mało do oceny całego modelu. OpenVibeEval — przebiegi i ograniczenie porównania, ARI Bench — raport z jednego przebiegu

Otwarte wagi nie oznaczają łatwego dostrajania. Oficjalna instrukcja podaje jako minimalną konfigurację LoRA 64 GPU z co najmniej 96 GB pamięci każde na ośmiu maszynach; pełne dostrajanie wymaga co najmniej 128 takich GPU na 16 maszynach. Wymagania rosną wraz z długością sekwencji i batch size. Wymagania sprzętowe dostrajania

Dla osób bez własnego klastra model jest dostępny jako usługa hostowana. 30 sierpnia OpenRouter pokazywał jednego dostawcę, cenę 0,834 USD za milion tokenów wejściowych, 2,501 USD za milion wyjściowych i 0,042 USD za milion tokenów odczytanych z cache. Mediana przepustowości wynosiła około 40 tokenów/s. Są to bieżące dane operatora routingu, które mogą zmienić się wraz z dostawcami i obciążeniem. Ceny, dostawca i metryki OpenRouter

Co mówi dyskusja

Najmocniejszy argument w dyskusji o MIX-STQ1_0 dotyczy zakresu pomiaru jakości. Cztery małe spadki benchmarków nie dowodzą, że kwant zachowuje ten sam udział możliwości w długiej sesji agentowej. Uczestnicy wskazują, że błąd kwantyzacji może być nierównomierny: pozostawać niewidoczny w krótkich odpowiedziach, a ujawniać się przy wielokrotnych wywołaniach narzędzi, edycjach kodu i długim kontekście. To technicznie uzasadniona hipoteza, ale w wątku nie ma testu Hy4, który by ją mierzył. Dyskusja o zakresie wyników kwantyzacji

Redukcja wag do 214 GiB nadal nie przenosi modelu na typowy komputer konsumencki. Pozwala rozważać maszyny z 256 GB pamięci lub kilka GPU zamiast klastra potrzebnego dla BF16. Jeden komentujący deklaruje 4,1 tokena/s na zestawie z 256 GB RAM i 32 GB VRAM, inny opisuje pojedynczą odpowiedź trwającą około 3,5 godziny. Są to relacje z pierwszej ręki bez pełnych logów, długości generacji i powtarzalnych konfiguracji. Pokazują możliwe tryby offloadu, nie stanowią benchmarku. W tym samym wątku użytkownicy zgłaszają brak standardowej obsługi i ROCm; część z nich wstrzymuje testy do czasu pojawienia się zmian w głównym llama.cpp. Relacje użytkowników i ograniczenia uruchomienia

Trzeci spór dotyczy określenia „open source”. Wagi i licencja pozwalają uruchamiać oraz modyfikować model bez korzystania z API producenta, ale publikacja nie obejmuje pełnych danych treningowych i procesu odtworzenia modelu od zera. Precyzyjniej jest więc mówić o otwartych wagach na Apache 2.0. Wątek Hacker News zawiera też przewidywania dotyczące przyszłej wersji i pozycji rynkowej, lecz nie opiera ich na nowych pomiarach. Dyskusja jest zbyt wczesna i samowybrana, by opisywać ją jako stanowisko całej społeczności. Publiczna dyskusja o premierze

Wnioski

Fakt — pewność wysoka: konfiguracja Hy4 Preview dopuszcza 1 048 576 pozycji, ale obecne zweryfikowane receptury SGLang opisują maksymalnie 262 144 tokeny, a eksperymentalna ścieżka vLLM-Ascend do 96K na dwóch węzłach.
Wniosek — pewność wysoka: liczba 1M powinna być traktowana jako limit modelu, nie domyślnie osiągalny parametr usługi. Długość działającego żądania zależy od pamięci pozostającej po załadowaniu wag, rozmiaru cache KV, równoległości i implementacji attention.
Wniosek — pewność średnia: MIX-STQ1_0 zmniejsza plik wag z około 1,5 TB w BF16 do 213,66 GiB, lecz nie wiadomo, czy zachowuje jakość w długich zadaniach agentowych. Pewność nie jest wysoka, bo cztery porównania jakości pochodzą od zespołu projektu, a runtime wymaga niescalonych łat.
Scenariusz — pewność średnia: po scaleniu obsługi hyv4 do głównych runtime'ów i publikacji niezależnych testów długiego kontekstu Hy4 może stać się praktycznym modelem dla serwerów z około 256 GB szybkiej pamięci. Nie wiadomo jeszcze, jaka będzie przepustowość przy takim offloadzie, wielu użytkownikach i kontekście liczonym w setkach tysięcy tokenów.

Czego jeszcze nie wiemy

Czy ktokolwiek odtworzył pełny kontekst 1 048 576 tokenów z poprawnym wynikiem testu typu needle-in-a-haystack lub zadaniem wymagającym użycia informacji z całej sekwencji.
Ile pamięci i czasu prefillu wymaga pojedyncze żądanie 1M w BF16, FP8 oraz MIX-STQ1_0 na konkretnych konfiguracjach sprzętowych.
Jak MIX-STQ1_0 wpływa na długie sesje programistyczne, wywołania narzędzi, języki inne niż angielski i spójność przy setkach tysięcy tokenów.
Czy wyniki MCP-Atlas, SWE-bench Multilingual, MRCR i IFBench dla skwantyzowanego modelu zostaną odtworzone przez niezależny zespół z tym samym checkpointem i ustawieniami.
Kiedy obsługa hyv4, szablonu rozmowy i formatu STQ1_0 trafi do standardowych wydań llama.cpp, vLLM i SGLang oraz które ścieżki będą miały walidację produkcyjną.
Jak szybkość około 19,5 tokena/s z krótkiego testu na 8×H20 zmienia się wraz z długością kontekstu, batch size i liczbą równoległych użytkowników.

Źródła

Źródła pierwotne

Niezależne analizy i relacje

Dyskusje publiczne

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.