Shannon 3.1

De meeste modelreleases vragen u een capaciteitsclaim op goed vertrouwen aan te nemen en te wachten tot een benchmarktabel de discussie beslecht. Deze is makkelijker te controleren: open twee tabbladen, zet dezelfde prompt in shannon-3 en shannon-3.1, en kijk. Het verschil in hoe snel het antwoord binnenkomt is niet subtiel, en het is geen renderingtruc. Shannon 3.0 werd met opzet afgeremd. Shannon 3.1 niet.

01Wat er werkelijk is veranderd in Shannon 3.1

Shannon 3.0 introduceerde datgene wat deze familie definieert: een iteratieve redeneerlus. Het model antwoordt niet bij zijn eerste gedachte. Het denkt, schrijft een concept, toetst dat concept aan de vraag en verbetert het. Lite doorloopt die lus één keer; Pro doorloopt de volledige lus, inclusief een kennisoogststap voordat het een concept schrijft. Dat ontwerp wordt uitvoerig beschreven in het onderzoeksartikel over Shannon 3, en daaraan is in 3.1 niets veranderd.

Wat wel veranderde, is de machinerie eronder. Shannon 3.0 werd geserveerd via een externe inferentie-aanbieder — een verstandige manier om een model te lanceren, en een beperkende manier om er een te draaien. U erft dan de serveerconfiguratie van iemand anders, de wachtrij van iemand anders, het contextplafond van iemand anders en het idee van iemand anders over hoeveel tokens per seconde u mag hebben. Shannon 3.1 draait op ons eigen GPU-cluster, op een serveerstack die wij configureren, en elk kerngetal in dit artikel volgt uit die ene beslissing.

	Shannon 3.0	Shannon 3.1
Waar het draait	Externe aanbieder	Ons eigen GPU-cluster
Contextvenster	32,768	196,608
Uitvoerstreaming	Gedoseerd / afgeremd	Volle motorsnelheid
Gewichten	Standaard van de aanbieder	4-bit NVFP4
Decodering	Standaard	Speculatief
Redeneerlus	Denken → concept → nakijken → verbeteren	Ongewijzigd
Weigeringslaag	Geen	Geen
Model-id's	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Waarom Shannon 3.1 10-15x sneller aanvoelt

Het snelheidscijfer is het getal waar mensen het eerst naar vragen, dus het loont om precies te zijn over waar het vandaan komt. Er zijn twee onafhankelijke bijdragen, en de grootste is de minst spectaculaire van de twee.

Wij hebben de snelheidsrem verwijderd

De uitvoer van Shannon 3.0 liep door een doseerlaag. Tokens verlieten de engine, werden vastgehouden en werden volgens een schema aan uw verbinding vrijgegeven. Dat was geen ongeluk en geen bug. Wanneer een gedeelde inferentie-aanbieder de flessenhals is, vlakt het doseren van de uitvoer de belasting af, houdt het één lange generatie ervan af een slot te monopoliseren en laat het de stroom in een voorspelbaar, leesbaar ritme aankomen in plaats van in stoten. Het is een verdedigbare technische keuze, en ze kostte elke gebruiker echte kloktijd bij elk afzonderlijk antwoord.

Shannon 3.1 heeft geen snelheidsrem en geen gedoseerde weergave. Tokens worden naar uw stroom geschreven zodra de engine ze produceert. Als de engine snel genereert, ziet u het snel genereren. Er zit geen afvlakkende buffer tussen het model en uw terminal, uw chatvenster of uw SSE-lezer. Voor een lang antwoord — een analyse van 2.000 tokens, een bestand met gegenereerde code — verklaart dit alleen al het grootste deel van de verbetering die u zult merken.

Een eerlijk gevolg: de stroom komt nu in stoten. Speculative decoding (hieronder) verzendt geaccepteerde tokens in korte reeksen, dus tekst kan in zichtbare brokken binnenkomen in plaats van in een metronomisch woord-voor-woordritme. Als u uw interface rond de vloeiende cadans van 3.0 hebt gebouwd, blijft die werken — de volgorde en de inhoud van de tokens zijn onaangetast — maar u wilt misschien uw eigen afvlakking aan de clientkant terugbrengen als u het typemachine-effect mooier vond. Wij denken dat de meeste mensen liever de seconden terugkrijgen.

De engine zelf werd sneller

De rem weghalen helpt alleen als wat erachter zit snel is. De tweede bijdrage is de serveerstack die in sectie 03 wordt beschreven: 4-bit NVFP4-gewichten en speculative decoding op FP4-native versnellers van de huidige generatie in ons eigen cluster. Samen verhogen die het plafond dat het weghalen van de rem blootlegt.

Relatieve end-to-end antwoordlatentie, interne evaluatie van Shannon Lab, september 2026. De bandbreedte weerspiegelt promptlengte en tier: korte prompts op Lite zitten aan de onderkant, lange generaties op Pro aan de bovenkant.

03Wat speculative decoding werkelijk doet

"Speculative decoding" wordt als marketingterm gebruikt, dus hier is het mechanisme, ronduit.

Een taalmodel produceert normaal één token per voorwaartse doorloop. Die doorloop wordt niet gedomineerd door rekenwerk maar door geheugenbandbreedte — de gewichten moeten gelezen worden om ook maar iets te berekenen, en dat lezen duurt veel langer dan het rekenen zelf. De GPU staat het grootste deel van de tijd op het geheugen te wachten met inactieve rekeneenheden. 500 tokens genereren betekent die latentie 500 keer achtereen betalen.

Speculative decoding valt dat sequentiële deel aan. Een klein, goedkoop conceptmodel stelt een korte reeks waarschijnlijke volgende tokens voor — zeg vier of acht. Het hoofdmodel evalueert die hele reeks vervolgens in één gebundelde voorwaartse doorloop, wat nauwelijks meer kost dan het evalueren van één token, omdat het dure deel (het lezen van de gewichten) hoe dan ook maar één keer gebeurt. Elk voorgesteld token waarmee het hoofdmodel het eens is, wordt geaccepteerd en meteen verzonden. Bij de eerste onenigheid wordt de reeks afgekapt en hervat de normale decodering vanaf dat punt.

Het acceptatiepercentage doet het werk. Bij voorspelbare tekst — standaardformuleringen, codestructuur, het bindweefsel van een betoog — gokt het conceptmodel goed en landen er lange reeksen ineens. Bij werkelijk moeilijke tokens daalt de acceptatie en zakt het systeem netjes terug naar gewone token-voor-tokendecodering. Dat is precies de asymmetrie die u wilt: het versnelt de makkelijke stukken en raakt de moeilijke niet aan.

Waarom 4-bit gewichten in dezelfde alinea thuishoren

Omdat de flessenhals geheugenbandbreedte is, is het verkleinen van de gewichten een directe snelheidsknop en niet slechts een besparing op geheugengebruik. NVFP4 is een 4-bits drijvendekommaformaat met fijnmazige schaling per blok, en dat is wat het in staat stelt nauwkeurigheid te behouden waar oudere 4-bits integerkwantiseringen die verloren. Ruwweg een kwart van de bytes die per voorwaartse doorloop gelezen moeten worden betekent evenredig minder wachttijd op geheugen, en het laat veel meer ruimte over voor de KV-cache voor lange context die een venster van 196K vereist.

De twee versterken elkaar in plaats van simpelweg op te tellen: minder bytes per doorloop, en minder doorlopen per verzonden token. Dat is wat ongeremde streaming op volle snelheid betaalbaar maakt om te serveren in plaats van een kostenpost die we via doseren zouden moeten terugverdienen — precies wat de doseerlaag op 3.0 aan het doen was.

04196,608 tokens: wat een 6x groter venster mogelijk maakt

Shannon 3.0 had een venster van 32,768 tokens: een werksessie, geen document. Ruwweg 70-80 pagina's proza, min wat de redeneerlus voor zijn eigen denkwerk verbruikt, min uw systeemprompt, min het gesprek tot dan toe. Echt werk liep voortdurend tegen die muur aan, en de omwegen — opdelen in stukken, samenvatten, retrieval over uw eigen materiaal — tasten allemaal juist datgene aan wat u probeerde te behouden. 196,608 tokens is een andere categorie probleem.

Concreet is dat in de orde van 400-500 pagina's tekst, of een middelgrote codebase met zijn tests en zijn README, of een jaar aan vergadernotities van één project, of een compleet contractdossier met alle bijlagen — in één gesprek vastgehouden, in één vraag aanspreekbaar, zonder opdeellaag tussen u en het materiaal.

• Vragen over een hele repository. Laad de code en vraag waarom een bug de productie haalt, in plaats van de drie bestanden te plakken die u toch al verdacht. Het model kan het bestand vinden waaraan u niet had gedacht.
• Analyse van lange documenten zonder retrieval. Retrieval is een lossy voorfilter dat bepaalt wat het model mag zien. Bij 196K kunt u die stap vaak overslaan en het model alles laten lezen, waarmee een hele klasse van fouten verdwijnt waarbij de juiste passage nooit werd opgehaald.
• Gesprekken die samenhangend blijven. Een lange werksessie laat haar eigen begin niet langer stilletjes vallen. Randvoorwaarden die u in bericht drie stelde, gelden nog in bericht tachtig.
• Ruimte voor de redeneerlus. Het denken, concipiëren en nakijken van de lus verbruikt zelf context. Op 3.0 concurreerden die stappen met uw materiaal om een schaars budget. Op 3.1 passen ze ruim, en dat is mede waarom de kwaliteitswinst en de vensteruitbreiding tegelijk aankwamen.
• Grote gemengde invoer. Afbeeldingen, geëxtraheerde documenttekst en code in één beurt, zonder te moeten uitzoeken welke daarvan u zich kunt veroorloven mee te sturen.

Eén eerlijke kanttekening die voor elk langecontextmodel geldt, het onze inbegrepen: een groot venster is een capaciteit, geen garantie op gelijkmatige aandacht over de hele lengte. Structuur helpt nog steeds. De vraag achteraan zetten, uw documenten labelen en het model vertellen waar het naar moet zoeken verbeteren de resultaten meetbaar bij 150K tokens, op een manier die bij 5K simpelweg niet speelt.

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

De twee tiers verschillen in hoeveel van de redeneerlus ze doorlopen, en dat is het enige verschil dat telt bij de keuze ertussen.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
Redeneren	Eén doorloop	Volledige lus + kennisoogst
Zelfcontrole	Nee	Ja
Contextvenster	196,608	196,608
Streaming	Volle snelheid, ongeremd	Volle snelheid, ongeremd
Vision & documenten	Ja	Ja
Tool voor beeldgeneratie	Ja	Ja
Geschikt voor	Het meeste werk, hoog volume	Moeilijke vragen, eerste concept niet genoeg

Gebruik standaard Lite. Eén doorloop van een goed redeneermodel handelt de grote meerderheid van echte verzoeken af, en op 3.1 is het snel genoeg dat u de lus niet langer voelt als wachttijd. Grijp naar Pro wanneer de vraag er een is waarbij een eerste antwoord meestal op een leerzame manier fout is: architecturale afwegingen, adversariële analyse, alles waarbij u een bekwame collega er een nachtje over zou laten slapen. De zelfcontrolestap van Pro is geen versiering — het is het model dat zijn eigen fouten vindt voordat u dat hoeft te doen.

06De 32% intelligentiewinst, en hoe u die moet lezen

De eigen evaluatie van Shannon Lab zet Shannon 3.1 op 32% meer intelligentie dan Shannon 3.0. We willen duidelijk zijn over wat dat wel en niet is.

Het is ons cijfer, uit onze interne evaluatiesuite, gemeten op taken die wij representatief achten voor wat mensen deze modellen daadwerkelijk voorleggen. Het is geen benchmark van een derde partij, en we bouwen geen ranglijsttabel rond één intern totaalcijfer en publiceren geen uitsplitsing per benchmark — een uitsplitsing suggereert een mate van externe vergelijkbaarheid die een interne suite niet heeft.

Wat we wel zeggen, is waar de winst vandaan komt, want dat deel is niet mysterieus. Een groter contextvenster betekent dat er minder materiaal weggegooid hoeft te worden voordat het model erover redeneert, en een flink deel van de schijnbare domheid in lange sessies is in werkelijkheid gewoon geheugenverlies. Een serveerstack die wij beheren betekent dat het model draait met de configuratie die wij bedoeld hebben, in plaats van met een standaardinstelling van een aanbieder. En de redeneerlus — ongewijzigd van ontwerp — heeft nu ruimte om echt binnen het venster te draaien, in plaats van geperst te worden tegen een plafond van 32K dat het met uw invoer deelde.

07Vision, documenten en beeldgeneratie

Shannon 3.1 leest afbeeldingen en documenten. Schermafbeeldingen, diagrammen, foto's, gescande pagina's, PDF's en tekstdocumenten kunnen het gesprek in en worden samen met al het andere meegewogen. Gecombineerd met het venster van 196K maakt dit hele-documentworkflows praktisch: een lang rapport met zijn grafieken in één beurt, zonder vooraf te beslissen welke pagina's het model mag zien.

Beeldgeneratie en beeldbewerking zijn in de chat beschikbaar als tool. Vraag om een afbeelding en het model roept de tool inline aan, in hetzelfde gesprek, met de context van alles wat tot dan toe is besproken. Bewerken werkt op dezelfde manier — geef het een afbeelding en beschrijf de wijziging. Er is geen aparte modus om naar over te schakelen en geen aparte interface om te leren.

08Shannon 3.1 aanroepen vanuit de API

Shannon 3.1 is beschikbaar op alle drie de API-dialecten, met streaming op elk ervan. Dezelfde modellen, drie verzoekvormen — kies degene die past bij de SDK die u al gebruikt.

Endpoint	Vorm	Streaming
/v1/chat/completions	OpenAI-compatibel	Ja
/v1/messages	Anthropic-compatibel	Ja
/v1/responses	Responses	Ja

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

Vervang "shannon-3.1" door "shannon-3.1-pro" om de volledige redeneerlus te draaien. Als u al shannon-3 aanroept, is migreren een kwestie van de model-id en verder niets: de verzoek- en antwoordvormen zijn ongewijzigd, en bestaande streamingclients blijven werken. Het enige gedragsverschil om op te rekenen is de stotende stroom uit sectie 02 — dezelfde tokens, dezelfde volgorde, alleen eerder en in minder gelijkmatige brokken.

De volledige parameterreferentie, authenticatie, foutsemantiek en een interactieve playground vindt u in de API-documentatie. Andere modelkaarten en technische uiteenzettingen staan in Shannon research.

09Nog altijd ongecensureerd, en daarin onveranderd

Shannon 3.1 heeft geen weigeringslaag en geen inhoudsfiltering op de uitvoer. Dit is dezelfde houding als bij de rest van de Shannon-lijn en ze veranderde niet met de verhuizing naar ons eigen cluster — als er iets is, maakt het beheren van de serveerstack het juist makkelijker te garanderen, want er zit geen tussenliggende aanbieder met een eigen beleid tussen het model en u.

Het is de moeite waard dit ronduit te zeggen, want het is de voor de hand liggende vraag bij een release die het hele uitvoerpad heeft veranderd: het verwijderen van de doseerlaag betekende niet dat er een moderatielaag voor in de plaats kwam. Niets inspecteert, herschrijft of poortwachtert de stroom. Wat het model produceert, is wat er aankomt. Shannon 3.1 is, voor zover wij weten, het snelste ongecensureerde AI-model dat beschikbaar is met een contextvenster van deze omvang — en die twee eigenschappen hangen samen, want beide komen voort uit het draaien van onze eigen infrastructuur in plaats van het huren van compliance-gevormde capaciteit bij iemand anders.

Ongecensureerd is niet hetzelfde als onverantwoordelijk. Het gebruik valt onder ons beleid voor verantwoord gebruik, en de verplichting die hoort bij een model dat lastig materiaal wél aangaat, is dat u er verantwoordelijk mee omgaat.

10Voer de vergelijking zelf uit

Elke bewering hier is in ongeveer twee minuten te controleren, en het is ons liever dat u het controleert dan dat u ons gelooft.

1. Kies een prompt uit werk dat u werkelijk doet. Lang is beter — dat belast zowel het venster als de streaming.
2. Draai die op shannon-3. Noteer hoe lang het duurt tot het eerste token en hoe lang tot het antwoord af is.
3. Draai dezelfde prompt op shannon-3.1. Noteer dezelfde twee getallen.
4. Lees daarna beide antwoorden, negeer de klok, en beslis welk antwoord u had willen hebben.

Het snelheidsverschil zal onmiddellijk en overduidelijk zijn. Het kwaliteitsverschil is het verschil waar u even bij stil moet staan — het valt het duidelijkst op bij lange invoer, waar 3.0 stilletjes met minder van uw materiaal werkte dan u dacht.

11Veelgestelde vragen

---

De prestatie- en intelligentiecijfers in dit artikel zijn eigen metingen van Shannon Lab uit interne evaluatie, september 2026, en worden vermeld als productcijfers en niet als benchmarkresultaten van derden. Contextvenster, model-id's en API-beschikbaarheid zijn productspecificaties. Shannon AI wordt geëxploiteerd door Shannon Lab LLC, New Mexico, VS. Verder lezen: Shannon 3 · Shannon research-index · API-documentatie.