Shannon 3.1

De fleste modellutgivelser ber deg ta en påstand om kapasitet på tro, og vente på at en benchmark-tabell skal avgjøre saken. Denne er lettere å sjekke: åpne to faner, gi den samme prompten til shannon-3 og shannon-3.1, og se på. Forskjellen i hvor raskt svaret kommer, er ikke subtil, og det er ikke et rendringstriks. Shannon 3.0 var strupet med vilje. Shannon 3.1 er det ikke.

01Hva som faktisk er endret i Shannon 3.1

Shannon 3.0 innførte det som definerer denne familien: en iterativ resonneringssløyfe. Modellen svarer ikke på sin første tanke. Den tenker, skriver et utkast, vurderer sitt eget utkast opp mot spørsmålet, og forbedrer det. Lite kjører én runde av den sløyfen; Pro kjører hele sløyfen, inkludert et kunnskapsinnhentingssteg før den skriver utkastet. Den utformingen er beskrevet i detalj i forskningsartikkelen om Shannon 3, og ingenting av det er endret i 3.1.

Det som er endret, er maskineriet under. Shannon 3.0 ble servert gjennom en tredjeparts inferensvert — en fornuftig måte å lansere en modell på, og en begrensende måte å drifte den på. Du arver noen andres serveringskonfigurasjon, noen andres kø, noen andres kontekstak og noen andres oppfatning av hvor mange tokens per sekund du får lov til å ha. Shannon 3.1 kjører på vår egen GPU-klynge, på en serveringsstakk vi konfigurerer selv, og hvert eneste hovedtall i denne artikkelen følger av den ene beslutningen.

	Shannon 3.0	Shannon 3.1
Hvor den kjører	Tredjepartsvert	Vår egen GPU-klynge
Kontekstvindu	32,768	196,608
Strømming av utdata	Taktet / hastighetsbegrenset	Full motorhastighet
Vekter	Vertens standard	4-bits NVFP4
Dekoding	Standard	Spekulativ
Resonneringssløyfe	Tenk → utkast → gjennomgang → forbedring	Uendret
Avvisningslag	Ingen	Ingen
Modell-ID-er	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Hvorfor Shannon 3.1 føles 10-15x raskere

Hastighetstallet er det folk spør om først, så det er verdt å være presis på hvor det kommer fra. Det er to uavhengige bidrag, og det største av dem er det minst glamorøse.

Vi fjernet hastighetssperren

Utdataene fra Shannon 3.0 gikk gjennom et pacing-lag. Tokens forlot motoren, ble holdt tilbake, og ble sluppet ut til tilkoblingen din etter en tidsplan. Dette var ikke et uhell eller en feil. Når en delt inferensvert er flaskehalsen, jevner takting av utdataene ut belastningen, hindrer at én lang generering legger beslag på en plass, og får strømmen til å ankomme i en forutsigbar, lesbar rytme i stedet for i støt. Det er et forsvarlig ingeniørvalg, og det kostet hver eneste bruker reell klokketid på hvert eneste svar.

Shannon 3.1 har ingen hastighetssperre og ingen takting av visningen. Tokens skrives til strømmen din etter hvert som motoren produserer dem. Hvis motoren genererer raskt, ser du at den genererer raskt. Det er ingen utjevningsbuffer mellom modellen og terminalen din, chattevinduet ditt eller SSE-leseren din. For et langt svar — en analyse på 2,000 tokens, en fil med generert kode — står dette alene for mesteparten av forbedringen du vil merke.

En ærlig konsekvens: strømmen kommer nå i støt. Spekulativ dekoding (se under) sender ut aksepterte tokens i korte serier, så tekst kan ankomme i synlige klumper i stedet for i en metronomisk kadens på ett ord om gangen. Hvis du har bygget grensesnitt rundt den jevne kadensen til 3.0, vil det fortsatt fungere — rekkefølgen og innholdet i tokenene er upåvirket — men du vil kanskje gjeninnføre din egen utjevning på klientsiden hvis du foretrakk skrivemaskineffekten. Vi tror de fleste heller vil ha sekundene tilbake.

Selve motoren ble raskere

Å fjerne sperren hjelper bare hvis det som ligger bak sperren, er raskt. Det andre bidraget er serveringsstakken beskrevet i seksjon 03: 4-bits NVFP4-vekter og spekulativ dekoding på FP4-native akseleratorer av nyeste generasjon i vår egen klynge. Til sammen hever disse taket som fjerningen av sperren blottlegger.

Relativ svarlatens fra ende til ende, intern evaluering hos Shannon Lab, september 2026. Spennet gjenspeiler promptlengde og nivå: korte prompter på Lite ligger nær den lave enden, lange genereringer på Pro nær den høye.

03Hva spekulativ dekoding faktisk gjør

«Spekulativ dekoding» brukes gjerne som et markedsføringsord, så her er mekanismen, rett fram.

En språkmodell produserer normalt ett token per fremoverpassering. Den passeringen domineres ikke av regnearbeid, men av minnebåndbredde — vektene må leses for å beregne noe som helst, og å lese dem tar langt lengre tid enn matematikken gjør. GPU-en bruker mesteparten av tiden på å vente på minnet mens regneenhetene står ledige. Å generere 500 tokens betyr å betale den latensen 500 ganger, sekvensielt.

Spekulativ dekoding angriper den sekvensielle delen. En liten, billig utkastmodell foreslår en kort serie sannsynlige neste tokens — si fire eller åtte. Hovedmodellen evaluerer så hele serien i én enkelt samlet fremoverpassering, som koster knapt mer enn å evaluere ett token ville gjort, fordi den dyre delen (å lese vektene) skjer én gang uansett. Hvert foreslåtte token som hovedmodellen er enig i, aksepteres og sendes ut umiddelbart. Ved første uenighet kuttes serien, og vanlig dekoding gjenopptas derfra.

Aksepteringsraten gjør jobben. På forutsigbar tekst — standardformuleringer, kodestruktur, bindevevet i et resonnement — gjetter utkastmodellen godt, og lange serier lander på én gang. På virkelig vanskelige tokens faller aksepteringen, og systemet degraderer elegant tilbake til vanlig dekoding ett token om gangen. Den asymmetrien er den du ønsker: den akselererer de lette delene og rører ikke de vanskelige.

Hvorfor 4-bits vekter hører hjemme i samme avsnitt

Fordi flaskehalsen er minnebåndbredde, er det å krympe vektene en direkte hastighetsspak, ikke bare en spak for minneforbruk. NVFP4 er et 4-bits flyttallsformat med finkornet skalering per blokk, og det er nettopp det som lar formatet holde på nøyaktigheten der eldre 4-bits heltallskvantiseringer mistet den. Om lag en fjerdedel av bytene å lese per fremoverpassering betyr proporsjonalt mindre tid brukt på å vente på minnet, og det gir langt mer takhøyde for den KV-cachen med lang kontekst som et 196K-vindu krever.

De to virker sammen snarere enn bare å legges sammen: færre byte per passering, og færre passeringer per token som sendes ut. Det er dette som gjør usperret strømming i full hastighet økonomisk mulig å servere i stedet for en kostnad vi måtte ha hentet inn igjen gjennom takting — som er nøyaktig det pacing-laget gjorde på 3.0.

04196,608 tokens: hva et 6x vindu åpner opp

Shannon 3.0 hadde et vindu på 32,768 tokens: en arbeidsøkt, ikke et dokument. Grovt regnet 70-80 sider prosa, minus det resonneringssløyfen bruker på sin egen tenkning, minus systemprompten din, minus samtalen så langt. Reelt arbeid traff den veggen konstant, og omveiene — oppdeling, oppsummering, gjenfinning i ditt eget materiale — forringer alle nettopp det du forsøkte å bevare. 196,608 tokens er en annen kategori problem.

Konkret er det i størrelsesorden 400-500 sider engelsk tekst, eller en mellomstor kodebase med testene og README-filen sin, eller et år med møtenotater fra ett prosjekt, eller et fullt kontraktssett med alle vedlegg — holdt i én samtale, adresserbart i ett spørsmål, uten et oppdelingslag mellom deg og materialet.

• Spørsmål om hele kodebaser. Last inn koden og spør hvorfor en feil når produksjon, i stedet for å lime inn de tre filene du allerede mistenkte. Modellen kan finne filen du ikke tenkte på å ta med.
• Analyse av lange dokumenter uten gjenfinning. Gjenfinning er et tapsgivende forfilter som bestemmer hva modellen får lov til å se. Ved 196K kan du ofte hoppe over det og la modellen lese alt, noe som fjerner en hel klasse av feil der det riktige avsnittet aldri ble hentet fram.
• Samtaler som holder sammenhengen. En lang arbeidsøkt mister ikke lenger stille sin egen begynnelse. Begrensninger du satte i melding tre, gjelder fortsatt i melding åtti.
• Plass til resonneringssløyfen. Sløyfens egen tenkning, utkastskriving og gjennomgang bruker kontekst. På 3.0 konkurrerte disse stegene med materialet ditt om et knapt budsjett. På 3.1 får de god plass, noe som er en del av grunnen til at kvalitetsgevinsten og vindusøkningen kom samtidig.
• Store, blandede inndata. Bilder, uttrukket dokumenttekst og kode i én og samme tur, uten å måtte prioritere hva du har råd til å ta med.

Ett ærlig forbehold som gjelder alle modeller med lang kontekst, våre inkludert: et stort vindu er en kapasitet, ikke en garanti for jevn oppmerksomhet over hele vinduet. Struktur hjelper fortsatt. Å plassere spørsmålet nær slutten, merke dokumentene dine og fortelle modellen hva den skal se etter, forbedrer alt sammen resultatene målbart ved 150K tokens på en måte de rett og slett ikke gjør ved 5K.

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

De to nivåene skiller seg i hvor mye av resonneringssløyfen de kjører, og det er den eneste forskjellen som betyr noe når du skal velge mellom dem.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
Resonnering	Én runde	Hele sløyfen + kunnskapsinnhenting
Selvgjennomgang	Nei	Ja
Kontekstvindu	196,608	196,608
Strømming	Full hastighet, usperret	Full hastighet, usperret
Syn & dokumenter	Ja	Ja
Verktøy for bildegenerering	Ja	Ja
Best til	De fleste oppgaver, høyt volum	Vanskelige spørsmål, første utkast holder ikke

Bruk Lite som standard. Én runde av en god resonneringsmodell håndterer det store flertallet av reelle forespørsler, og på 3.1 er den rask nok til at sløyfen ikke lenger er noe du merker at du venter på. Grip til Pro når spørsmålet er et der det første svaret vanligvis er feil på en lærerik måte: arkitektoniske avveininger, adversariell analyse, alt der du ville ønsket at en kompetent kollega sov på det. Pros selvgjennomgangssteg er ikke pynt — det er modellen som finner sine egne feil før du må gjøre det.

06Intelligensgevinsten på 32%, og hvordan den skal leses

Shannon Labs egen evaluering plasserer Shannon 3.1 på 32% bedre intelligens enn Shannon 3.0. Vi vil være tydelige på hva det er og ikke er.

Det er vårt tall, fra vår interne evalueringspakke, målt på oppgaver vi anser som representative for det folk faktisk bringer til slike modeller. Det er ikke en tredjeparts benchmark, og vi konstruerer ingen ledertabell rundt ett enkelt internt aggregat og publiserer ingen oppdeling per benchmark — en slik oppdeling antyder et nivå av ekstern sammenlignbarhet som en intern pakke ikke har.

Det vi vil si, er hvor gevinsten kommer fra, for den delen er ikke mystisk. Et større kontekstvindu betyr at mindre materiale må forkastes før modellen resonnerer over det, og en god del tilsynelatende dumhet i lange økter er egentlig bare hukommelsestap. En serveringsstakk vi kontrollerer, betyr at modellen kjører med den konfigurasjonen vi hadde tenkt, i stedet for en verts standardoppsett. Og resonneringssløyfen — uendret i utforming — har nå plass til faktisk å kjøre inne i vinduet i stedet for å bli klemt mot et tak på 32K som den delte med inndataene dine.

07Syn, dokumenter og bildegenerering

Shannon 3.1 leser bilder og dokumenter. Skjermbilder, diagrammer, fotografier, skannede sider, PDF-er og tekstdokumenter kan gå inn i samtalen og bli resonnert over sammen med alt annet. Kombinert med 196K-vinduet er det dette som gjør arbeidsflyter for hele dokumenter praktiske: en lang rapport og diagrammene i den i én tur, uten å bestemme på forhånd hvilke sider modellen får lov til å se.

Bildegenerering og bilderedigering er tilgjengelig i chat som et verktøy. Be om et bilde, og modellen kaller verktøyet fortløpende, i den samme samtalen, med konteksten av alt som er diskutert så langt. Redigering fungerer på samme måte — gi den et bilde, beskriv endringen. Det finnes ingen egen modus å bytte til og ikke noe eget grensesnitt å lære.

08Å kalle Shannon 3.1 fra API-et

Shannon 3.1 er tilgjengelig på alle tre API-dialektene, med strømming på hver av dem. Samme modeller, tre forespørselsformer — velg den som passer SDK-en du allerede har.

Endepunkt	Form	Strømming
/v1/chat/completions	OpenAI-kompatibel	Ja
/v1/messages	Anthropic-kompatibel	Ja
/v1/responses	Responses	Ja

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

Bytt "shannon-3.1" med "shannon-3.1-pro" for å kjøre hele resonneringssløyfen. Hvis du allerede kaller shannon-3, er migreringen modell-ID-en og ingenting annet: forespørsels- og svarformene er uendret, og eksisterende strømmeklienter fortsetter å virke. Den ene atferdsforskjellen du skal vente deg, er den mer støtvise strømmen beskrevet i seksjon 02 — samme tokens, samme rekkefølge, som kommer tidligere og i mindre jevne klumper.

Full parameterreferanse, autentisering, feilsemantikk og en interaktiv lekegrind finnes i API-dokumentasjonen. Andre modellkort og tekniske artikler finnes i Shannon research.

09Fortsatt usensurert, og uendret på det punktet

Shannon 3.1 har ingen avvisningslag og ingen innholdsfiltrering på utdataene. Dette er den samme holdningen som i resten av Shannon-serien, og den ble ikke endret med flyttingen til vår egen klynge — om noe gjør kontroll over serveringsstakken det lettere å garantere, fordi det ikke finnes noen mellomliggende vert med sin egen policy mellom modellen og deg.

Verdt å si rett ut, fordi det er det opplagte man lurer på ved en utgivelse som endret hele utdataveien: å fjerne pacing-laget betydde ikke å sette inn et modereringslag i stedet. Ingenting inspiserer, omskriver eller sperrer strømmen. Det modellen produserer, er det som kommer fram. Shannon 3.1 er, så vidt vi vet, den raskeste usensurerte AI-modellen som er tilgjengelig med et kontekstvindu av denne størrelsen — og de to egenskapene henger sammen, siden begge kommer av at vi kjører vår egen infrastruktur i stedet for å leie compliance-formet kapasitet av noen andre.

Usensurert er ikke det samme som uansvarlig. Bruk styres av vår policy for ansvarlig bruk, og forpliktelsen som følger med en modell som vil gå inn i vanskelig materiale, er at du gjør det på en ansvarlig måte.

10Kjør sammenligningen selv

Hver påstand her kan sjekkes på omtrent to minutter, og vi vil heller at du sjekker enn at du tror oss.

1. Velg en prompt fra arbeid du faktisk gjør. Lang er bedre — den setter både vinduet og strømmingen på prøve.
2. Kjør den på shannon-3. Merk deg hvor lenge det tar til første token, og hvor lenge det tar til svaret er ferdig.
3. Kjør den identiske prompten på shannon-3.1. Merk deg de samme to tallene.
4. Les så begge svarene, uten å se på klokken, og avgjør hvilket du ville ha villet ha.

Hastighetsforskjellen vil være umiddelbar og åpenbar. Kvalitetsforskjellen er den det er verdt å bli sittende med — den viser seg klarest på lange inndata, der 3.0 stille arbeidet med mindre av materialet ditt enn du trodde.

11Ofte stilte spørsmål

---

Ytelses- og intelligenstallene i denne artikkelen er Shannon Labs egne målinger fra intern evaluering, september 2026, og oppgis som produkttall snarere enn som resultater fra tredjeparts benchmarker. Kontekstvindu, modell-ID-er og API-tilgjengelighet er produktspesifikasjoner. Shannon AI drives av Shannon Lab LLC, New Mexico, USA. Videre lesning: Shannon 3 · Shannon research-indeks · API-dokumentasjon.