Okno kontekstu 1M w GLM to cecha definiująca obecnego flagowego modelu GLM i nie jest flagą w konfiguracji. Podniesienie użytecznego limitu z 200 000 do 1 000 000 tokenów wymagało zmian w architekturze uwagi, w dekodowaniu spekulatywnym i w stosie serwującym — trzech odrębnych elementów inżynierii, które dają użyteczne okno dopiero razem.
Ta strona wyjaśnia każdy z nich prostym językiem, z dołączonymi opublikowanymi liczbami. W skrócie: współdzielony indekser obniża obliczenia na token 2,9× przy długości kontekstu 1M, przeprojektowana warstwa multi-token-prediction podnosi długość akceptacji w dekodowaniu spekulatywnym o około 20%, a zestaw zmian w pamięci i kernelach nie pozwala, by pojemność KV-cache stała się ścianą. Wszystkie liczby zgodnie z publikacją autorów modelu.
Naiwnym problemem długiego kontekstu jest kwadratowy koszt uwagi, a sparse attention rozwiązuje go w zasadzie tak, że każdy token zwraca uwagę na wybrany podzbiór wcześniejszych tokenów, a nie na wszystkie. Ale sparse attention potrzebuje indeksera — lekkiego mechanizmu decydującego, na które tokeny warto zwrócić uwagę — a uruchamianie go w każdej warstwie przywraca koszt rosnący z długością kontekstu. Przy 200 000 tokenów ten narzut jest znośny. Przy milionie już nie.
Drugi problem polega na tym, że powyżej kilkuset tysięcy tokenów wąskim gardłem przestają być obliczenia. Stają się nim pojemność KV-cache, efektywność kerneli długokontekstowych i narzut po stronie CPU — czyli problem pamięci i systemów, a nie matematyki. Model może być architektonicznie zdolny do okna miliona tokenów i wciąż być niemożliwy do serwowania, jeśli cache się nie mieści albo szeregujący się zatyka.
IndexShare to odpowiedź architektoniczna. Zamiast by każda warstwa transformera liczyła własne indeksy top-k, każde cztery warstwy współdzielą jeden lekki indekser. Znajduje się on w pierwszej z czterech warstw, a jego indeksy top-k są wykorzystywane przez pozostałe trzy — co usuwa iloczyn skalarny indeksera i selekcję top-k z trzech na cztery warstwy.
Opublikowany rezultat to 2,9× redukcja liczby FLOP-ów na token przy długości kontekstu 1M, bez raportowanego kompromisu jakościowego na dużych dystansach. IndexShare stosowano od etapu mid-training przy długości sekwencji 128K, a nie doklejano na etapie inferencji — i to ma znaczenie: schemat współdzielenia wprowadzony dopiero przy serwowaniu tworzyłby rozjazd między sposobem trenowania modelu a sposobem jego działania.
Multi-token prediction przyspiesza generowanie, szkicując kilka tokenów naprzód, a następnie je weryfikując; jego skuteczność mierzy długość akceptacji — ile naszkicowanych tokenów średnio przechodzi weryfikację. W poprzedniej generacji warstwa MTP cierpiała na niedopasowanie między KV-cache używanym podczas treningu a tym używanym przy inferencji, co ograniczało długość akceptacji do 4,56 w 7 krokach MTP.
Obecny projekt uruchamia indekser raz, na pierwszym kroku szkicowania, i wykorzystuje te indeksy w kolejnych krokach, współdzieląc zarówno indeksy, jak i stan KV. Dodanie rejection sampling do ścieżki dekodowania spekulatywnego oraz kompleksowej straty typu total variation podnosi długość akceptacji do 5,47 — o mniej więcej 20% więcej tokenów akceptowanych w jednym przebiegu weryfikacji. Opublikowana ablacja znajduje się poniżej.
| Punkt odniesienia | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + Rejection Sampling | 5.29 |
| + kompleksowa strata TV | 5.47 (+20%) |
Wszystkie liczby na tej stronie to wyniki opublikowane przez autorów modelu. glmmodel.com je raportuje; nie przeprowadza tych ewaluacji.
Stronę systemową adresują trzy zmiany. Zarządzanie pamięcią oparte na LayerSplit daje drobniejszą kontrolę nad tym, jak stan modelu jest dzielony i zrównoleglany, więc alokacja cache przestaje być decyzją zero-jedynkową. Prace nad kernelami skalującymi się do długich kontekstów są skoordynowane z potokiem transferu cache, dzięki czemu obliczenia i ruch pamięci nakładają się, zamiast następować po sobie. Wreszcie zarządzanie cache po stronie CPU, szeregowanie żądań i strojenie ścieżek runtime usuwają narzut niewidoczny przy krótkim kontekście, a dominujący przy długim.
Raportowany efekt jest taki, że przewaga w przepustowości rośnie wraz z kontekstem — im dłuższy prompt, tym większa różnica względem naiwnej ścieżki serwowania. To właśnie ta właściwość zamienia okno kontekstu 1M ze specyfikacji w coś, co realnie da się uruchomić pod obciążeniem.
Względna przewaga w przepustowości wraz ze wzrostem długości kontekstu, zgodnie z opisem autorów modelu.
Przeczytaj benchmarki modeli GLM, a potem sprawdź działający model w praktyce. Playground powyżej jest darmowy i niczego od Ciebie nie wymaga; jeśli chcesz pełniejszego zestawu narzędzi AI, darmowy plan naszego partnera zaczyna się tutaj.