Ile kontekstu potrzebuje Qwen: 60k, 120k, 150k czy 250k?

Qwen3.8-27B odnalazł trzy wskazane fakty zarówno w wejściu 50k, jak i 230k tokenów. Krótsza próba trwała 59,3 s, dłuższa 563,4 s. Przy takim zadaniu dziewięciokrotnie dłuższe oczekiwanie nie przyniosło dodatkowej poprawnej odpowiedzi.

W osobnej naprawie kodu najlepiej sprawdził się profil 150k na zmodyfikowanym vLLM. Był znacznie szybszy od profilu 120k na llama.cpp, choć zmienił się przy tym cały zestaw: serwer, wagi i pamięć KV. Poniżej oddzielamy te dwa testy i pokazujemy, jak dobierać kontekst do pracy. Każdy wiersz pomiarów pochodzi z jednego przebiegu na jednej karcie.

Oficjalne 262k a nasze konfiguracje lokalne

Qwen3.8-27B ma natywne okno 262 144 tokenów. Karta modelu opisuje też rozszerzenie do miliona tokenów przez YaRN. Na RTX 3090 nie uruchamialiśmy wariantu milionowego, dlatego nie wliczamy tego rozszerzenia do wyniku eksperymentu.

W ścieżce llama.cpp użyliśmy trzech praktycznych konfiguracji:

To porównanie odpowiada na pytanie, co mieści się na jednej karcie 24 GB. Nie izoluje samego limitu kontekstu, ponieważ konfiguracje różnią się formatem wag, precyzją pamięci KV i wielkością paczki. Te parametry dobraliśmy razem, aby uruchomić każdy wariant na tym samym GPU.

Odnajdywanie faktów w długim wejściu

W syntetycznym materiale umieściliśmy dokładne wartości blisko początku, środka i końca. Zadanie wymagało zwrócenia wszystkich trzech wartości. „Fakty zwrócone” w tabeli to liczba poprawnie odtworzonych wartości z trzech, a 3/3 oznacza, że ta konkretna próba wyszukiwania zakończyła się powodzeniem. Taki wynik pokazuje odnalezienie przygotowanych faktów. Nie mówi, jak model poradzi sobie z dowolnym długim dokumentem.

„Tokeny wejścia” to liczba tokenów przed odpowiedzią. Przetwarzanie wejścia mierzy szybkość przygotowania tego materiału, generowanie mierzy szybkość tworzenia odpowiedzi, a czas całkowity obejmuje cały przebieg. Maks. VRAM to najwyższe zaobserwowane zużycie pamięci karty. Wariant 250k miał 4,6 razy więcej tokenów niż 60k, a trwał 9,5 razy dłużej i zużył 23 623 MiB z 24 GB.

Co kompresja historii zmienia w pracy agenta

Długie zadanie programistyczne może zapełnić okno szybciej niż sugeruje sam rozmiar repozytorium. Historia agenta obejmuje instrukcje systemowe, definicje narzędzi, wywołania, ich wyniki oraz odpowiedzi. Po przekroczeniu użytecznego limitu system kompresuje wcześniejszy przebieg, a agent może ponownie czytać pliki i odtwarzać zależności.

W jednym zapisanym przebiegu agentowym Codex przyznał 87 ze 100 punktów według kryteriów Syntalith: za poprawność, testy regresji, zgodność, dyscyplinę zakresu, weryfikację i dokumentację. Ocena wskazywała na istotną, niedeterministyczną wadę ścieżki awaryjnej. To wynik jednej pracy według konkretnych kryteriów i nie jest procentem niezawodności modelu. Sama kompresja nie przesądza o błędzie; koszt pojawia się wtedy, gdy trzeba wielokrotnie odbudowywać ten sam kontekst.

Dlaczego 250k nie rozstrzyga wyboru

W teście wyszukiwania każda konfiguracja zwróciła 3/3 przygotowanych faktów. Najdłuższa konfiguracja osiągnęła jednak 28,05 tok./s generowania i 563,4 s czasu całkowitego, wobec 49,24 tok./s i 59,3 s przy 60k. Poza tym testem nie mierzyliśmy jakości odpowiedzi na dowolnych dokumentach, więc wynik nie uzasadnia tezy, że większe okno poprawia jakość inżynierską.

Większe okno może także zwiększyć koszt wyszukiwania w historii. Sesję warto kontynuować, gdy poprzednie rozumowanie jest potrzebne, a niezależne zadanie rozpoczynać od świeżego kontekstu.

Dlaczego zachowaliśmy 150k do kolejnych prób

Wybrana konfiguracja zmodyfikowanego vLLM przyjmowała do 150 000 tokenów i używała Qwen Code 0.21.13 przy medium. W zadaniu naprawy dwóch ścieżek obsługi błędów json.Marshal zakończyła pracę bez kompresji w 502,14 s. OpenAI Codex ocenił zmianę na 100 ze 100 punktów według kryteriów Syntalith: poprawność 40/40, testy regresji 20/20, zgodność 15/15, dyscyplina zakresu 10/10, weryfikacja 10/10 i dokumentacja 5/5. Oznacza to brak odjęć w tej pojedynczej ocenie; nie jest to audyt zewnętrzny ani miara powtarzalności.

To samo polecenie i ta sama baza na konfiguracji llama.cpp 120k otrzymały od Codex 98 z 100 punktów, wykonały jedną kompresję i trwały 1468,76 s. Porównujemy tu całe konfiguracje: silnik, format wag, pamięć KV, ścieżkę serwowania i limit kontekstu. To praktyczne porównanie dwóch gotowych stosów. Nie izoluje wpływu zmiany 120k na 150k.

Jak dobrać okno w firmie

Najpierw zmierz rzeczywisty pakiet wejściowy:

kontekst zadania = instrukcje systemowe
  + definicje narzędzi
  + dokumenty lub kod wejściowy
  + historia odpowiedzi i wyników narzędzi
  + zapas na odpowiedź

Wybierz najmniejsze okno, które obejmuje 95. percentyl długości pakietu oraz bezpieczny zapas. Powtarzalna analiza dokumentów może mieścić się w 60k. Długa zmiana w repozytorium może wymagać 120k albo kompresji. System wiedzy firmy często zyska więcej na wyszukaniu kilku trafnych fragmentów niż na ładowaniu 250k przy każdym pytaniu.

Co mierzy Syntalith

W ramach wdrożenia prywatnego LLM Syntalith sprawdza długość rzeczywistych wejść, jakość po skróceniu materiału i czas oczekiwania w kolejce. Na tej podstawie dobieramy okno kontekstu, pamięć oraz sposób wyszukiwania dokumentów. Taki test pozwala ocenić potrzebny sprzęt przed zakupem.

Pełne pomiary eksperymentu są w publicznym zestawieniu JSON.