SubQ AI wyjaśnione: jak dobry jest LLM z oknem kontekstu 12 mln?

5 maja 2026 r. mały startup z Miami o nazwie Subquadratic wypuścił model SubQ. Zespół jest niewielki, ale zebrał 29 mln dolarów finansowania zalążkowego i twierdzi, że model potrafi przetworzyć do 12 milionów tokenów w pojedynczym przebiegu.

Padły też inne, brzmiące śmiało deklaracje, jak ta, że ich model jest do 52 razy bardziej wydajny niż FlashAttention przy 1 mln tokenów i osiąga wydajność w kodowaniu podobną do Claude Opus przy kosztach rzędu ok. 1/20.

To duże stwierdzenia, więc warto je rozłożyć na czynniki i sprawdzić, co faktycznie się dzieje. W tym tekście omówię, czym jest SubQ, jak działa jego architektura oraz co wczesne informacje i społeczności deweloperskie sugerują na temat tych twierdzeń.

Czym jest SubQ?

SubQ to LLM Subquadratic, wypuszczony 5 maja 2026 r., zbudowany wokół jednego kluczowego wyróżnika: okna kontekstu o wielkości 12 milionów tokenów. To pierwszy model, który firma dostarczyła, a wraz z nim zestaw odważnych deklaracji dotyczących efektywności i kosztów, które już wywołały znaczną dyskusję. 

Model nie jest jeszcze publicznie dostępny — dostęp do API, SubQ Code i SubQ Search jest obecnie ograniczony do wczesnego dostępu wyłącznie przez listę oczekujących.

Został zbudowany w oparciu o coś, co nazywa się SSA, skrót od Subquadratic Sparse Attention.

Zamiast porównywać każdy token z każdym innym tokenem — jak działa standardowa, gęsta uwaga — SSA stosuje podejście selektywne. Dla każdego tokena model wybiera najbardziej istotne tokeny i oblicza relacje tylko w obrębie tej podgrupy.

To ma dwa oczywiste skutki.

• Po pierwsze, zmniejsza liczbę obliczeń, co bezpośrednio poprawia efektywność i obniża koszty. 
• Po drugie, wybór zależy od treści. Oznacza to, że model nie patrzy tylko na sąsiednie tokeny. Może pobrać istotne tokeny z dowolnego miejsca w sekwencji, nawet jeśli są daleko od siebie.

Co wyróżnia SubQ?

W praktyce architektura SSA sprawia, że model skupia się na tym, co rzeczywiście ma znaczenie, zamiast przetwarzać wszystko jednakowo. Zamierzony efekt to podobna dokładność jak przy pełnej uwadze, ale przy istotnie niższych wymaganiach obliczeniowych i pamięciowych.

Przyjrzyjmy się najpierw bliżej gęstej uwadze, a następnie porównajmy oba podejścia.

Problem skalowania kwadratowego w transformerach

Dzisiejsze modele, takie jak GPT, Claude i Gemini, opierają się na gęstej uwadze. W dużym uproszczeniu oznacza to, że każdy token jest porównywany z każdym innym tokenem w wejściu. Wraz ze wzrostem długości wejścia liczba porównań rośnie kwadratowo.

Weźmy długi dokument i wyobraźmy sobie, że model musi wygenerować ostatnie słowo. Spogląda on wstecz na każdy token w tym dokumencie, buduje relacje, a następnie decyduje, co będzie dalej. Dlatego gęsta uwaga działa dobrze. Uwzględnia wszystko.

Ale ta siła ma swoją cenę. Gdy rozmiar wejścia rośnie, wymagania obliczeniowe i pamięciowe gwałtownie wzrastają i tworzą ograniczenia okna kontekstu. W prostych słowach, skaluje się to jako O(n²), gdzie n to liczba tokenów.

Z tego powodu większość modeli pozostaje w praktycznych granicach. W standardowych modelach normą jest 128 tys. tokenów, a najsilniejsze modele, takie jak Claude Opus, osiągają maksymalnie 1 mln w oknie kontekstu.

Aby to obejść, większość systemów opartych na AI unika podawania modelowi pełnych zbiorów danych. Zamiast tego polegają na technikach takich jak:

• RAG (Retrieval-Augmented Generation): Przechowuj dane zewnętrznie, pobieraj tylko istotne fragmenty i przekazuj je do modelu.
• Dzielenie na fragmenty (chunking): Podziel duży tekst na mniejsze części i wysyłaj do modelu tylko odpowiednie fragmenty.
• Strategie streszczania: Kompresuj długie treści i podawaj do modelu podsumowania zamiast pełnego tekstu.

Jeśli chce Pan/Pani głębiej zrozumieć mechanizmy uwagi, warto zajrzeć do tego samouczka o mechanizmie uwagi w LLM. Aby zdobyć praktyczne doświadczenie z klockami nowoczesnych LLM, polecam nasz kurs Modele Transformer w PyTorch.

Jak SubQ pozycjonuje się inaczej

Gęsta uwaga rośnie kwadratowo wraz z rozmiarem wejścia, podczas gdy SSA została zaprojektowana tak, by skalować się poniżej kwadratu, bliżej O(n·k) zamiast O(n²), gdzie k to liczba tokenów wybieranych na krok. Gdy k pozostaje małe względem n, jest to znacznie bardziej wydajne niż pełna uwaga.

Wykres uwagi kwadratowej vs liniowej pokazujący gęste połączenia każdy-z-każdym w porównaniu z rzadkimi, selektywnymi połączeniami.

Oczywistą obawą jest tu dokładność. Jeśli model patrzy tylko na część wejścia, może pominąć ważne relacje. Ten kompromis zwykle właśnie uzasadnia istnienie gęstej uwagi.

SubQ twierdzi, że ten kompromis nie występuje w praktyce. Według nich model zwraca uwagę na wszystkie niezbędne tokeny, nawet jeśli są daleko od bieżącego tokena, i utrzymuje podobną dokładność jak czołowe modele.

Jak działa Subquadratic Sparse Attention?

Wiemy już, że zamiast porównywać każdy token z każdym innym, SSA wybiera tylko te tokeny, które mają znaczenie w sekwencji, i oblicza uwagę nad tymi pozycjami. Przyjrzyjmy się, jak dokonuje tego wyboru.

Jak SSA wybiera istotne relacje

SSA stosuje trasowanie zależne od treści. Mówiąc prosto, wybiera tokeny na podstawie ich istotności względem bieżącego tokena. Oblicza wynik podobieństwa między tokenami, coś w rodzaju similarity(query_i, key_j), i zachowuje tylko najlepsze k tokenów o najwyższych wynikach do obliczenia uwagi.

Z czasem model uczy się priorytetyzować znaczące tokeny i ignorować szum. Obejmuje to słowa kluczowe, ważne byty i tokeny niosące silne sygnały kontekstowe.

To zależy nie tylko od treści — SSA zachowuje też relacje strukturalne w sekwencji. Na przykład pobliskie tokeny zawsze otrzymują uwagę dzięki lokalnym wzorcom uwagi, a pewne globalne tokeny są zaprojektowane tak, by obejmować całą sekwencję.

SSA obejmuje również hierarchiczne i klastrowe techniki uwagi. Na przykład grupuje podobne tokeny i oblicza uwagę z najbardziej istotnymi klastrami. Oznacza to, że model nie musi oceniać każdego tokena indywidualnie — może najpierw rozumować na poziomie grup, a następnie, w razie potrzeby, przybliżyć się do tokenów w obrębie tych klastrów.

Trening pod kątem wyszukiwania w długim kontekście

Duże okno kontekstu samo w sobie nie czyni cudów. Nawet jeśli damy modelowi 12 mln tokenów, musi on jeszcze umieć skutecznie użyć tego kontekstu. SSA jest szkolona właśnie w tym celu:

• Wstępne trenowanie: Model bazowy jest uczony na ogromnych, zróżnicowanych zbiorach danych z reprezentacjami długiego kontekstu. 
• Dostrajanie nadzorowane: Następnie model jest szkolony na ustrukturyzowanych zadaniach, w tym rozumowaniu i generowaniu kodu. 
• Uczenie ze wzmocnieniem: Zamiast ograniczać model do rozważania pobliskich tokenów (uwaga lokalna), ten etap ma skłonić go do używania istotnych tokenów z całego tekstu (uwaga globalna).

Etap uczenia ze wzmocnieniem jest szczególnie ważny w korporacyjnych zastosowaniach do kodowania. Pozwala on modelowi rozważać szerszy kontekst naraz — w tym przypadku cały kod — podczas generowania wyników.

Benchmarki i wydajność SubQ

Należy zauważyć, że „SubQ 1M-Preview” odnosi się do wersji testowanej przy 1 mln tokenów. Pełne okno kontekstu 12 mln jest dostępne przez API.

W trzech benchmarkach, które Subquadratic zdecydował się upublicznić, SubQ 1M-Preview rywalizuje z Claude Opus 4.7, GPT-5.5 i Gemini 3.1 Pro. 

Jednak dobór benchmarków jest wąski: dokładnie trzy testy, wszystkie skupione na wyszukiwaniu w długim kontekście i kodowaniu — dwóch obszarach, do których SubQ jest wprost zaprojektowany. Szersze ewaluacje w zakresie ogólnego rozumowania, matematyki, wielojęzyczności i bezpieczeństwa nie zostały opublikowane.

Pełna karta modelu na stronie jest oznaczona jako „wkrótce”, więc można oczekiwać więcej benchmarków w ogólnych zastosowaniach.

Na ten moment oto wyniki dla wyszukiwania w długim kontekście i zastosowań kodowania:

Co pokazują liczby

RULER 128K: SubQ uzyskuje 95% w porównaniu do 94,8% Opus 4.7. Choć różnica w dokładności jest pomijalna, kluczowy jest tu koszt: Subquadratic twierdzi, że uruchomienie tej ewaluacji na SubQ kosztowało ok. 8 dolarów, wobec ok. 2600 dolarów na Opus przy tej samej długości kontekstu.

MRCR v2 (8-needle, 1M): Ten benchmark sprawdza, czy model poprawnie wydobywa i śledzi 8 oddzielnych faktów osadzonych w kontekście o długości 1 mln tokenów. SubQ pokazuje wynik badawczy 83%, ale wynik produkcyjny spada do 65,9%. Ta ok. 17-punktowa różnica między laboratorium a działaniem wdrożonym jest zauważalna i nie do końca wyjaśniona. Mimo to pozostaje konkurencyjny względem GPT-5.5 (74,0%) i wyraźnie przed Claude Opus 4.7 (32,2%) oraz Gemini 3.1 Pro (26,3%).

SWE-Bench Verified: SubQ osiąga 81,8%, wyprzedzając Opus 4.6 z wynikiem 80,8%, lecz za Opus 4.7 z 87,6%. Różnice względem Opus 4.6 są niewielkie i wrażliwe na konfigurację harnessu. W porównaniu z Opus 4.7 i GPT-5.5 SubQ jest wyraźnie z tyłu.

Przy 12 milionach tokenów: Zgłaszano, że SubQ osiąga ponad 90% w zadaniach „igła w stogu siana” przy kontekście 12 mln, choć liczba ta nie została potwierdzona oficjalnymi benchmarkami. Żaden inny model z czołówki nie był testowany przy takiej długości, więc nie ma bezpośredniego punktu odniesienia. To najciekawszy architektonicznie rezultat premiery, a zarazem taki, który wymaga niezależnej replikacji, zanim wyciągniemy wnioski.

Co SubQ oznacza dla RAG, agentów kodujących i kosztów AI

Jeśli architektura SubQ obroni się w skali, zmieni sposób budowania systemów LLM. Dłuższy kontekst stanie się praktyczny, ograniczając potrzebę agresywnego dzielenia, wyszukiwania i optymalizacji tokenów. Przyjrzyjmy się tym zmianom bliżej.

Gdy RAG staje się opcjonalny

Przez ostatnie dwa lata Retrieval-Augmented Generation (RAG) był domyślną odpowiedzią na fundamentalne ograniczenie LLM: modele nie mogą czytać wszystkiego naraz. Jeśli baza wiedzy jest większa niż okno kontekstu, dzieli się dokumenty, embedduje je, przechowuje w bazie wektorowej, pobiera najbardziej istotne części i przekazuje tylko te fragmenty do modelu wraz z poleceniem.

Cały ten ekosystem istnieje, ponieważ kontekst jest zasobem deficytowym.

Gdy model może wiarygodnie przetwarzać miliony tokenów w pojedynczym przebiegu, wiele warstw inżynieryjnych wokół wyszukiwania staje się mniej koniecznych dla wybranych przepływów pracy. Zamiast poświęcać czas na decydowanie, które fragmenty pobrać, system może wchłonąć materiał źródłowy bezpośrednio i rozumować nad nim end-to-end.

Niemniej poza samym oknem kontekstu RAG nadal ma znaczenie w następujących aspektach:

• Pamięć między sesjami: LLM nie pamiętają niczego po zakończeniu sesji. Jeśli użytkownik wraca później, model zaczyna od zera. Systemy wyszukiwania (lub bazy danych) przechowują ważne informacje, jak wcześniejsze decyzje, dokumenty czy dane użytkownika, aby model mógł je wykorzystać w przyszłych interakcjach.
• Uprawnienia i kontrola dostępu: Systemy wyszukiwania potrafią egzekwować zasady typu „ten użytkownik ma dostęp tylko do danych swojego zespołu”. Dzięki temu model otrzymuje wyłącznie dokumenty, do których użytkownik ma prawo, co zapobiega przypadkowym wyciekom danych.
• Audytowalność: W środowiskach korporacyjnych nie wystarczy podać odpowiedzi — trzeba pokazać, dlaczego jest poprawna. Systemy wyszukiwania mogą wskazać dokładne dokumenty lub źródła, co pozwala zespołom weryfikować wyniki i diagnozować problemy.
• Ustrukturyzowane zarządzanie wiedzą: Firmy stale dodają, aktualizują i usuwają dokumenty. Systemy wyszukiwania wykorzystują embeddingi i indeksowanie do organizowania tych danych, aby model mógł szybko znaleźć najnowsze i najistotniejsze informacje bez każdorazowego ponownego przetwarzania całości.

Aby poznać nowe, ciekawe podejście do dodawania trwałej pamięci agentom AI, proszę przeczytać nasz samouczek Supermemory, w którym nauczą się Państwo tworzyć trenera ćwiczeń z pamięcią krótką i długą.

Przepływy pracy kodowania z długim kontekstem

Obecnie większość modeli kodujących nie widzi całej bazy kodu. Dlatego dokładamy warstwy: wyszukiwanie plików, dzielenie na fragmenty, ranking i wieloetapowe planowanie — tylko po to, by utrzymać właściwy kontekst w oknie i budować relacje między plikami.

Ale dzięki 12-milionowemu kontekstowi SubQ cała baza kodu jest ładowana do modelu naraz. To w istotny sposób upraszcza projektowanie agentów.

• Planowanie staje się globalne: Model może rozumować o architekturze, zależnościach i interakcjach między plikami, nie tracąc kontekstu.
• Wykonanie jest bardziej spójne: Zmiany w wielu plikach można skoordynować w jednym przebiegu, zamiast dokonywać ich inkrementalnie.
• Przegląd jest bardziej wiarygodny: Model może weryfikować własne zmiany względem całej bazy kodu, redukując niespójności.

Ekonomia kosztów

W standardowych transformerach uwaga skaluje się kwadratowo z długością sekwencji. Jeśli podwoimy kontekst, koszt nie tylko się podwaja — może stać się czterokrotnie wyższy.

SubQ twierdzi, że przełamuje ten kompromis.

• Raportuje ~1/20 kosztu w porównaniu z modelami z czołówki (Claude Opus)
• Oraz do ~1000× redukcji obliczeń przy kontekście 12 mln tokenów

Jeśli potwierdzi się to w produkcji, przetwarzanie długiego kontekstu przestaje być kosztownym wyjątkiem i staje się czymś, z czego można korzystać rutynowo.

Jednak wraz z tanim oknem kontekstu model powinien też efektywnie wykorzystywać informacje ładowane do jego kontekstu. Na podstawie benchmarków SubQ deklaruje porównywalną dokładność przy znacznie niższym koszcie, ale na ostateczne wnioski jest za wcześnie.

Jak mogę uzyskać dostęp do SubQ?

SubQ nie jest jeszcze publicznie dostępny. Wszystkie trzy produkty — podstawowe API, SubQ Code i SubQ Search — znajdują się obecnie w prywatnej becie, a dostęp wymaga wniosku o wczesny dostęp przez stronę SubQ.

Z perspektywy dewelopera API zaprojektowano tak, by integracja była prosta. Obsługuje:

• strumieniowanie odpowiedzi
• wywoływanie narzędzi/funkcji
• punkty końcowe kompatybilne z OpenAI

To oznacza, że jeśli Państwa stack już współpracuje z API w stylu OpenAI, zwykle nie ma potrzeby przepisywania integracji.

SubQ Code jest pozycjonowany jako agent do kodowania w wierszu poleceń, natomiast SubQ Search skupia się na wyszukiwaniu w długim kontekście na potrzeby głębszych prac badawczych. Można je traktować jako wersje SubQ narzędzi Claude Code i Perplexity. 

Cennik żadnego z tych narzędzi nie jest jeszcze transparentny. Nie ma publicznie dostępnych stawek per-token, co utrudnia niezależną weryfikację deklaracji kosztowych firmy.

Sceptycyzm i otwarte pytania

W ciągu kilku godzin od premiery w mediach społecznościowych i na forach, takich jak Hacker News, pojawiło się już sporo sceptycyzmu i mieszanych reakcji. Dyskusja jest podzielona — część widzi w tym prawdziwy przełom, inni porównują to do „AI Theranos” (nawiązanie do nieudanej firmy testującej krew, która składała fałszywe deklaracje technologiczne).

Większość wątpliwości skupia się na: 

• Deklarują okno kontekstu 12 mln, ale udostępnione benchmarki są wszystkie przy 1 mln.
• Nazwali firmę Subquadratic, ale w niektórych miejscach wspominają o skalowaniu zbliżonym do O(1). Przy O(1) można by oczekiwać znacznie więcej niż 12 mln tokenów w oknie kontekstu. Nawet O(log n) pozwoliłoby na większe limity.

Podobna narracja pojawiła się przy Magic.dev w 2024 r. Firma składała silne deklaracje dotyczące bardzo dużych okien kontekstu — do 100 mln tokenów — i dużych zysków efektywności, zwłaszcza w przepływach pracy związanych z kodowaniem. 

Oferta była niemal identyczna: załaduj całe bazy kodu, ogranicz złożoność wyszukiwania i uprość projektowanie agentów. Ale rezultat — przynajmniej publicznie — był bardziej stonowany. Mimo zebrania ok. 500 mln dolarów, na początku 2026 r. wciąż brakuje szerokiej, realnej widoczności lub adopcji.

Co zostało zweryfikowane

Twierdzenia SubQ nie są czysto teoretyczne. Subquadratic podaje, że benchmarki RULER, MRCR v2 i SWE-Bench Verified były uruchamiane przez zewnętrzną usługę testową, pokazując silne wyniki w wyszukiwaniu w długim kontekście i konkurencyjne rezultaty w zadaniach kodowania. 

Jednak wyniki te nie zostały jeszcze niezależnie odtworzone przez zewnętrznych badaczy, a zakres ewaluacji jest wąski. Wszystkie trzy benchmarki podkreślają dokładnie obszary, do których SubQ jest zbudowany (wydobywanie sygnałów z dużego kontekstu i operowanie na kodzie).

Kolejny istotny szczegół to architektura. CTO potwierdził, że SubQ nie trenuje modeli od zera, lecz bazuje na otwartoźródłowych modelach bazowych (prawdopodobnie z rodzin takich jak DeepSeek lub Kimi). To praktyczny wybór dla małego zespołu. Przyspiesza iteracje i zmniejsza koszty treningu. Oznacza to też, że kluczową innowacją nie jest sam model bazowy, lecz mechanizm uwagi i projekt systemu wokół niego.

Wnioski końcowe

SubQ już jest — i to z dość odważnymi deklaracjami. Kierunek jest jasny: zdjąć ograniczenie okna kontekstu i pozwolić modelom przetwarzać znacznie większe wejścia. Pozycjonują go jako dorównującego lub przewyższającego modele z czołówki w kodowaniu i wyszukiwaniu w długim kontekście, przy znacznie niższym koszcie.

Niemniej to wciąż wczesny etap. Czekamy na pełną kartę modelu, aby uzyskać lepszy wgląd w szersze możliwości i testy. Produkty zbudowane na nim — SubQ Code i API — również nie są jeszcze publicznie dostępne. Z niecierpliwością czekam na możliwość praktycznego przetestowania tych narzędzi i sprawdzenia, jak deklaracje wypadają w produkcji.