Shannon 3.1

Większość premier modeli prosi, byś przyjął deklarację o możliwościach na wiarę i czekał, aż tabela benchmarków rozstrzygnie spór. Tę łatwiej sprawdzić: otwórz dwie karty, wpisz ten sam prompt do shannon-3 i shannon-3.1 i patrz. Różnica w tym, jak szybko przychodzi odpowiedź, nie jest subtelna i nie jest sztuczką z renderowaniem. Shannon 3.0 był celowo dławiony. Shannon 3.1 nie jest.

01Co faktycznie zmieniło się w Shannon 3.1

Shannon 3.0 wprowadził to, co definiuje tę rodzinę: iteracyjną pętlę rozumowania. Model nie odpowiada po pierwszej myśli. Myśli, szkicuje, ocenia własny szkic względem pytania i go poprawia. Lite wykonuje jeden przebieg tej pętli; Pro wykonuje pełną pętlę, wraz z krokiem zbierania wiedzy przed szkicowaniem. Ten projekt jest szczegółowo opisany w artykule badawczym o Shannon 3 i nic z tego nie zmieniło się w 3.1.

Zmieniła się maszyneria pod spodem. Shannon 3.0 był serwowany przez zewnętrznego hosta inferencyjnego — rozsądny sposób na premierę modelu i krępujący sposób na jego prowadzenie. Dziedziczysz cudzą konfigurację serwowania, cudzą kolejkę, cudzy sufit kontekstu i cudze wyobrażenie o tym, ile tokenów na sekundę wolno Ci mieć. Shannon 3.1 działa na naszym własnym klastrze GPU, na stosie serwującym, który sami konfigurujemy, a każda kluczowa liczba w tym artykule wynika z tej jednej decyzji.

	Shannon 3.0	Shannon 3.1
Gdzie działa	Zewnętrzny host	Nasz własny klaster GPU
Okno kontekstu	32,768	196,608
Strumieniowanie wyjścia	Tempowane / ograniczane	Pełna prędkość silnika
Wagi	Domyślne u hosta	4-bitowe NVFP4
Dekodowanie	Standardowe	Spekulatywne
Pętla rozumowania	Myśl → szkicuj → sprawdź → popraw	Bez zmian
Warstwa odmów	Brak	Brak
Identyfikatory modeli	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Dlaczego Shannon 3.1 sprawia wrażenie 10-15x szybszego

Liczba dotycząca prędkości jest tą, o którą ludzie pytają najpierw, więc warto precyzyjnie powiedzieć, skąd się bierze. Są dwa niezależne wkłady, a większy z nich jest tym mniej efektownym.

Usunęliśmy ogranicznik prędkości

Wyjście Shannon 3.0 przechodziło przez warstwę tempowania. Tokeny opuszczały silnik, były przetrzymywane i wypuszczane do Twojego połączenia według harmonogramu. To nie był przypadek ani błąd. Kiedy wąskim gardłem jest współdzielony host inferencyjny, tempowanie wyjścia wygładza obciążenie, nie pozwala długiej generacji zmonopolizować slotu i sprawia, że strumień dociera w przewidywalnym, czytelnym rytmie zamiast zrywami. To dająca się obronić decyzja inżynierska, która kosztowała każdego użytkownika realny czas przy każdej pojedynczej odpowiedzi.

Shannon 3.1 nie ma ogranicznika prędkości ani tempowania ujawniania. Tokeny są zapisywane do Twojego strumienia w miarę, jak silnik je produkuje. Jeśli silnik generuje szybko, widzisz, że generuje szybko. Między modelem a Twoim terminalem, oknem czatu czy czytnikiem SSE nie ma bufora wygładzającego. Przy długiej odpowiedzi — analizie na 2 000 tokenów, pliku wygenerowanego kodu — samo to odpowiada za większość poprawy, którą zauważysz.

Uczciwa konsekwencja: strumień jest teraz zrywany. Dekodowanie spekulatywne (poniżej) emituje zaakceptowane tokeny w krótkich seriach, więc tekst może docierać widocznymi porcjami, a nie w metronomicznym rytmie słowo po słowie. Jeśli zbudowałeś interfejs wokół płynnego rytmu 3.0, nadal będzie działać — kolejność i treść tokenów są bez zmian — ale możesz chcieć przywrócić własne wygładzanie po stronie klienta, jeśli wolałeś efekt maszyny do pisania. Sądzimy, że większość ludzi wolałaby odzyskać sekundy.

Sam silnik stał się szybszy

Usunięcie ogranicznika pomaga tylko wtedy, gdy to, co za nim stoi, jest szybkie. Drugim wkładem jest stos serwujący opisany w sekcji 03: 4-bitowe wagi NVFP4 i dekodowanie spekulatywne na akceleratorach obecnej generacji z natywnym FP4 w naszym własnym klastrze. Razem podnoszą sufit, który odsłania usunięcie ogranicznika.

Względne opóźnienie odpowiedzi od początku do końca, wewnętrzna ewaluacja Shannon Lab, wrzesień 2026. Zakres odzwierciedla długość promptu i warstwę: krótkie prompty na Lite plasują się przy dolnej granicy, długie generacje na Pro przy górnej.

03Co naprawdę robi dekodowanie spekulatywne

„Dekodowanie spekulatywne” bywa używane jako słowo marketingowe, więc oto mechanizm, wprost.

Model językowy normalnie produkuje jeden token na przebieg w przód. W tym przebiegu dominuje nie arytmetyka, lecz przepustowość pamięci — żeby cokolwiek policzyć, trzeba odczytać wagi, a ich odczyt trwa znacznie dłużej niż same obliczenia. GPU spędza większość czasu, czekając na pamięć, z bezczynnymi jednostkami obliczeniowymi. Wygenerowanie 500 tokenów oznacza zapłacenie tego opóźnienia 500 razy, sekwencyjnie.

Dekodowanie spekulatywne atakuje właśnie część sekwencyjną. Mały, tani model roboczy proponuje krótką serię prawdopodobnych kolejnych tokenów — powiedzmy cztery albo osiem. Model główny ocenia następnie całą tę serię w jednym wsadowym przebiegu w przód, który kosztuje ledwie więcej niż ocena jednego tokena, bo kosztowna część (odczyt wag) i tak następuje raz. Każdy proponowany token, na który model główny się zgadza, zostaje zaakceptowany i natychmiast wyemitowany. Przy pierwszej niezgodności seria zostaje ucięta i od tego miejsca wraca zwykłe dekodowanie.

Pracę wykonuje współczynnik akceptacji. Na tekście przewidywalnym — szablonowym, na strukturze kodu, na spoiwie argumentacji — model roboczy zgaduje dobrze i długie serie lądują naraz. Na naprawdę trudnych tokenach akceptacja spada, a system łagodnie degraduje się do zwykłego dekodowania token po tokenie. To właśnie ta asymetria jest pożądana: przyspiesza łatwe fragmenty i nie dotyka trudnych.

Dlaczego 4-bitowe wagi należą do tego samego akapitu

Skoro wąskim gardłem jest przepustowość pamięci, zmniejszenie wag jest bezpośrednią dźwignią prędkości, a nie tylko zajętości pamięci. NVFP4 to 4-bitowy format zmiennoprzecinkowy z drobnoziarnistym skalowaniem per blok, i to właśnie pozwala mu utrzymać dokładność tam, gdzie starsze schematy kwantyzacji całkowitoliczbowej 4-bit ją traciły. Mniej więcej jedna czwarta bajtów do odczytu na przebieg w przód oznacza proporcjonalnie mniej czasu czekania na pamięć i zostawia znacznie więcej zapasu dla pamięci podręcznej KV długiego kontekstu, której wymaga okno 196K.

Te dwa efekty raczej się mnożą, niż tylko dodają: mniej bajtów na przebieg i mniej przebiegów na wyemitowany token. To właśnie sprawia, że nieograniczane strumieniowanie z pełną prędkością jest opłacalne w serwowaniu, a nie kosztem, który musielibyśmy odzyskiwać tempowaniem — czyli dokładnie tym, co robiła warstwa tempowania w 3.0.

04196,608 tokenów: co odblokowuje 6x większe okno

Shannon 3.0 miał okno 32,768 tokenów: sesję roboczą, nie dokument. Mniej więcej 70-80 stron prozy, minus to, co pętla rozumowania zużywa na własne myślenie, minus Twój prompt systemowy, minus dotychczasowa rozmowa. Prawdziwa praca uderzała w tę ścianę bez przerwy, a obejścia — dzielenie na fragmenty, streszczanie, wyszukiwanie po własnym materiale — degradują to, co próbowałeś zachować. 196,608 tokenów to problem innej kategorii.

Konkretnie to rząd wielkości 400-500 stron tekstu, albo średniej wielkości baza kodu wraz z testami i plikiem README, albo rok notatek ze spotkań jednego projektu, albo pełen zestaw umów ze wszystkimi załącznikami — utrzymywany w jednej rozmowie, adresowalny jednym pytaniem, bez warstwy fragmentacji między Tobą a materiałem.

• Pytania o całe repozytorium. Wczytaj kod i zapytaj, dlaczego błąd trafia na produkcję, zamiast wklejać trzy pliki, które już podejrzewałeś. Model potrafi znaleźć plik, o którego dołączeniu nie pomyślałeś.
• Analiza długich dokumentów bez wyszukiwania. Wyszukiwanie to stratny filtr wstępny, który decyduje, co modelowi wolno zobaczyć. Przy 196K często można je pominąć i pozwolić modelowi przeczytać wszystko, co eliminuje całą klasę awarii, w której właściwy fragment nigdy nie został znaleziony.
• Rozmowy, które zachowują spójność. Długa sesja robocza nie gubi już po cichu własnego początku. Ograniczenia ustawione w trzeciej wiadomości nadal obowiązują w osiemdziesiątej.
• Miejsce na pętlę rozumowania. Własne myślenie, szkicowanie i przegląd pętli zużywają kontekst. W 3.0 te kroki konkurowały z Twoim materiałem o skąpy budżet. W 3.1 mieszczą się wygodnie, i to jest część powodu, dla którego wzrost jakości i powiększenie okna przyszły razem.
• Duże wejścia mieszane. Obrazy, wyekstrahowany tekst dokumentów i kod w jednej turze, bez decydowania, na które z nich Cię stać.

Jedno uczciwe zastrzeżenie, które dotyczy każdego modelu z długim kontekstem, także naszego: duże okno to pojemność, a nie gwarancja równomiernej uwagi na całej jego długości. Struktura nadal pomaga. Umieszczenie pytania blisko końca, oznaczanie dokumentów i powiedzenie modelowi, czego ma szukać, mierzalnie poprawiają wyniki przy 150K tokenów w sposób, w jaki po prostu nie robią tego przy 5K.

05Lite i Pro: shannon-3.1 i shannon-3.1-pro

Obie warstwy różnią się tym, jak dużą część pętli rozumowania wykonują, i to jedyna różnica istotna przy wyborze między nimi.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
Rozumowanie	Pojedynczy przebieg	Pełna pętla + zbieranie wiedzy
Samodzielny przegląd	Nie	Tak
Okno kontekstu	196,608	196,608
Strumieniowanie	Pełna prędkość, bez ogranicznika	Pełna prędkość, bez ogranicznika
Wizja i dokumenty	Tak	Tak
Narzędzie generowania obrazów	Tak	Tak
Najlepsze do	Większości pracy, dużych wolumenów	Trudnych pytań, gdy pierwszy szkic nie wystarcza

Domyślnie używaj Lite. Jeden przebieg dobrego modelu rozumującego obsługuje zdecydowaną większość realnych zapytań, a w 3.1 jest na tyle szybki, że pętla przestaje być czymś, na co się czeka. Sięgnij po Pro, gdy pytanie należy do tych, w których pierwsza odpowiedź zwykle myli się w pouczający sposób: kompromisy architektoniczne, analiza adwersaryjna, wszystko, co chciałbyś, żeby kompetentny kolega przespał. Krok samodzielnego przeglądu w Pro nie jest ozdobą — to model znajdujący własne błędy, zanim musisz to zrobić Ty.

0632% wzrostu inteligencji i jak to czytać

Własna ewaluacja Shannon Lab plasuje Shannon 3.1 o 32% wyżej pod względem inteligencji niż Shannon 3.0. Chcemy jasno powiedzieć, czym to jest, a czym nie.

To nasza liczba, z naszego wewnętrznego zestawu ewaluacyjnego, mierzona na zadaniach, które uznajemy za reprezentatywne dla tego, z czym ludzie faktycznie przychodzą do tych modeli. To nie jest benchmark zewnętrzny i nie budujemy wokół pojedynczego wewnętrznego agregatu tabeli rankingowej ani nie publikujemy rozbicia na poszczególne benchmarki — takie rozbicie sugerowałoby poziom zewnętrznej porównywalności, którego wewnętrzny zestaw nie ma.

Powiemy natomiast, skąd bierze się ten wzrost, bo akurat to nie jest tajemnicze. Większe okno kontekstu oznacza, że mniej materiału trzeba odrzucić, zanim model zacznie nad nim rozumować, a spora część pozornej niedomogi intelektualnej w długich sesjach to w istocie amnezja. Stos serwujący, który kontrolujemy, oznacza, że model działa z konfiguracją, jaką zamierzyliśmy, a nie z domyślną u hosta. A pętla rozumowania — niezmieniona w projekcie — ma teraz miejsce, by naprawdę zadziałać wewnątrz okna, zamiast tłoczyć się pod sufitem 32K, który dzieliła z Twoim wejściem.

07Wizja, dokumenty i generowanie obrazów

Shannon 3.1 czyta obrazy i dokumenty. Zrzuty ekranu, diagramy, fotografie, zeskanowane strony, pliki PDF i dokumenty tekstowe mogą trafić do rozmowy i być analizowane razem ze wszystkim innym. W połączeniu z oknem 196K to właśnie czyni praktycznymi przepływy pracy na całych dokumentach: długi raport i jego wykresy w jednej turze, bez decydowania z góry, które strony model może zobaczyć.

Generowanie i edycja obrazów są dostępne w czacie jako narzędzie. Poproś o obraz, a model wywoła narzędzie w miejscu, w tej samej rozmowie, z kontekstem wszystkiego, co dotąd omówiono. Edycja działa tak samo — podaj obraz, opisz zmianę. Nie ma osobnego trybu, w który trzeba się przełączać, ani osobnego interfejsu do nauczenia.

08Wywoływanie Shannon 3.1 z API

Shannon 3.1 jest dostępny we wszystkich trzech dialektach API, ze strumieniowaniem w każdym z nich. Te same modele, trzy kształty zapytań — wybierz ten, który pasuje do SDK, które już masz.

Endpoint	Kształt	Strumieniowanie
/v1/chat/completions	Zgodny z OpenAI	Tak
/v1/messages	Zgodny z Anthropic	Tak
/v1/responses	Responses	Tak

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

Zamień "shannon-3.1" na "shannon-3.1-pro", aby uruchomić pełną pętlę rozumowania. Jeśli już wywołujesz shannon-3, migracja to identyfikator modelu i nic więcej: kształty zapytań i odpowiedzi są bez zmian, a istniejący klienci strumieniowi działają dalej. Jedyna różnica w zachowaniu, jakiej należy się spodziewać, to bardziej zrywany strumień opisany w sekcji 02 — te same tokeny, ta sama kolejność, docierające wcześniej i w mniej równych porcjach.

Pełny wykaz parametrów, uwierzytelnianie, semantyka błędów i interaktywny plac zabaw znajdują się w dokumentacji API. Pozostałe karty modeli i opracowania techniczne są w badaniach Shannon.

09Nadal bez cenzury i pod tym względem bez zmian

Shannon 3.1 nie ma warstwy odmów ani filtrowania treści na wyjściu. To ta sama postawa co w reszcie linii Shannon i nie zmieniła się wraz z przejściem na nasz własny klaster — jeśli już, kontrola nad stosem serwującym ułatwia jej zagwarantowanie, bo między modelem a Tobą nie stoi pośredni host z własną polityką.

Warto powiedzieć to wprost, bo to oczywista wątpliwość przy wydaniu, które zmieniło całą ścieżkę wyjścia: usunięcie warstwy tempowania nie oznaczało wstawienia w jej miejsce warstwy moderacji. Nic nie inspekcjonuje, nie przepisuje ani nie bramkuje strumienia. To, co produkuje model, jest tym, co dociera. Shannon 3.1 jest, o ile nam wiadomo, najszybszym dostępnym modelem AI bez cenzury z oknem kontekstu tej wielkości — a te dwie własności są powiązane, bo obie biorą się z prowadzenia własnej infrastruktury zamiast wynajmowania mocy w kształcie narzuconym przez cudzą zgodność regulacyjną.

Brak cenzury to nie to samo co brak odpowiedzialności. Korzystanie reguluje nasza Polityka Odpowiedzialnego Użytkowania, a zobowiązanie, które przychodzi z modelem gotowym zmierzyć się z trudnym materiałem, polega na tym, że Ty mierzysz się z nim odpowiedzialnie.

10Przeprowadź porównanie samodzielnie

Każde twierdzenie z tego artykułu da się sprawdzić w jakieś dwie minuty i wolimy, żebyś sprawdził, niż nam uwierzył.

1. Wybierz prompt z pracy, którą naprawdę wykonujesz. Dłuższy jest lepszy — obciąża i okno, i strumieniowanie.
2. Uruchom go na shannon-3. Zanotuj, ile trwa do pierwszego tokena i ile do ukończenia odpowiedzi.
3. Uruchom identyczny prompt na shannon-3.1. Zanotuj te same dwie liczby.
4. Potem przeczytaj obie odpowiedzi, ignorując zegar, i zdecyduj, którą chciałbyś dostać.

Różnica w prędkości będzie natychmiastowa i oczywista. To różnica w jakości jest tą, przy której warto się zatrzymać — najwyraźniej widać ją przy długich wejściach, gdzie 3.0 po cichu pracował na mniejszej części Twojego materiału, niż Ci się wydawało.

11Najczęściej zadawane pytania

---

Liczby dotyczące wydajności i inteligencji podane w tym artykule to własne pomiary Shannon Lab z wewnętrznej ewaluacji, wrzesień 2026, i są podawane jako dane produktowe, a nie wyniki benchmarków zewnętrznych. Okno kontekstu, identyfikatory modeli i dostępność w API to specyfikacje produktu. Shannon AI jest prowadzone przez Shannon Lab LLC, Nowy Meksyk, USA. Powiązane materiały: Shannon 3 · indeks badań Shannon · dokumentacja API.