Shannon 3.1

De fleste modeludgivelser beder dig tage en påstand om ydeevne på troen og vente på, at en benchmarktabel afgør diskussionen. Denne her er lettere at efterprøve: åbn to faneblade, giv den samme prompt til shannon-3 og shannon-3.1, og se med. Forskellen på, hvor hurtigt svaret ankommer, er ikke subtil, og det er ikke et renderingstrick. Shannon 3.0 var bremset med vilje. Det er Shannon 3.1 ikke.

01Hvad der reelt blev ændret i Shannon 3.1

Shannon 3.0 indførte det, der definerer denne familie: en iterativ ræsonneringsløkke. Modellen svarer ikke på sin første indskydelse. Den tænker, skriver et udkast, gennemgår sit eget udkast op mod spørgsmålet og forbedrer det. Lite kører ét gennemløb af den løkke; Pro kører hele løkken, inklusive et videnshøst-trin, før den skriver udkastet. Det design er beskrevet i detaljer i Shannon 3-forskningsartiklen, og intet af det er ændret i 3.1.

Det, der er ændret, er maskineriet nedenunder. Shannon 3.0 blev serveret gennem en tredjeparts inferensvært — en fornuftig måde at lancere en model på og en begrænsende måde at drive den på. Du arver en andens serverkonfiguration, en andens kø, en andens kontekstloft og en andens opfattelse af, hvor mange tokens pr. sekund du må få. Shannon 3.1 kører på vores egen GPU-klynge, på en serveringsstak vi selv konfigurerer, og hvert eneste hovedtal i denne artikel følger af den ene beslutning.

	Shannon 3.0	Shannon 3.1
Hvor den kører	Tredjepartsvært	Vores egen GPU-klynge
Kontekstvindue	32,768	196,608
Output-streaming	Pacet / hastighedsbegrænset	Fuld motorhastighed
Vægte	Værtens standard	4-bit NVFP4
Afkodning	Standard	Spekulativ
Ræsonneringsløkke	Tænk → udkast → gennemgang → forbedring	Uændret
Afvisningslag	Ingen	Ingen
Model-id'er	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

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

Hastighedstallet er det, folk spørger til først, så det er værd at være præcis om, hvor det kommer fra. Der er to uafhængige bidrag, og det største af dem er det mindst glamourøse.

Vi fjernede hastighedsspærren

Shannon 3.0's output passerede gennem et pacing-lag. Tokens forlod motoren, blev holdt tilbage og blev frigivet til din forbindelse efter en tidsplan. Det var hverken et uheld eller en fejl. Når en delt inferensvært er flaskehalsen, udjævner pacing af output belastningen, forhindrer en lang generering i at lægge beslag på en plads og får strømmen til at ankomme i en forudsigelig, læsbar rytme frem for i stød. Det er et forsvarligt ingeniørvalg, og det kostede hver eneste bruger reel tid på hvert eneste svar.

Shannon 3.1 har ingen hastighedsspærre og ingen pacing af visningen. Tokens skrives til din strøm, efterhånden som motoren producerer dem. Genererer motoren hurtigt, ser du den generere hurtigt. Der er ingen udjævningsbuffer mellem modellen og din terminal, dit chatvindue eller din SSE-læser. For et langt svar — en analyse på 2.000 tokens, en fil med genereret kode — står dette alene for hovedparten af den forbedring, du vil bemærke.

En ærlig konsekvens: strømmen er nu stødvis. Spekulativ afkodning (se nedenfor) sender accepterede tokens ud i korte serier, så teksten kan ankomme i synlige klumper i stedet for i en metronomisk kadence med ét ord ad gangen. Har du bygget brugerflade op omkring 3.0's jævne kadence, virker den stadig — tokenrækkefølge og indhold er uændrede — men du vil måske genindføre din egen udjævning på klientsiden, hvis du foretrak skrivemaskineeffekten. Vi tror, de fleste hellere vil have sekunderne tilbage.

Selve motoren blev hurtigere

At fjerne spærren hjælper kun, hvis det, der ligger bag den, er hurtigt. Det andet bidrag er den serveringsstak, der beskrives i afsnit 03: 4-bit NVFP4-vægte og spekulativ afkodning på nuværende generation af FP4-native acceleratorer i vores egen klynge. Tilsammen hæver de det loft, som fjernelsen af spærren blotlægger.

Relativ svarlatens fra ende til anden, Shannon Labs interne evaluering, september 2026. Spændet afspejler promptlængde og niveau: korte prompts på Lite ligger tæt på den lave ende, lange genereringer på Pro tæt på den høje.

03Hvad spekulativ afkodning faktisk gør

»Spekulativ afkodning« bliver brugt som et marketingord, så her er mekanismen, ligeud.

En sprogmodel producerer normalt ét token pr. fremadgående gennemløb. Det gennemløb domineres ikke af regnekraft, men af hukommelsesbåndbredde — vægtene skal læses, før noget som helst kan beregnes, og at læse dem tager langt længere tid end selve matematikken. GPU'en bruger det meste af sin tid på at vente på hukommelsen med regneenhederne i tomgang. At generere 500 tokens betyder at betale den ventetid 500 gange, sekventielt.

Spekulativ afkodning angriber den sekventielle del. En lille, billig udkastmodel foreslår en kort række sandsynlige næste tokens — lad os sige fire eller otte. Hovedmodellen evaluerer så hele rækken i ét enkelt samlet gennemløb, hvilket koster knap nok mere end at evaluere ét token, fordi den dyre del (at læse vægtene) sker én gang under alle omstændigheder. Hvert foreslået token, hovedmodellen er enig i, accepteres og sendes ud med det samme. Ved den første uenighed afkortes rækken, og normal afkodning genoptages derfra.

Acceptraten gør arbejdet. På forudsigelig tekst — standardformuleringer, kodestruktur, bindevævet i et argument — gætter udkastmodellen godt, og lange rækker lander på én gang. På reelt svære tokens falder accepten, og systemet falder elegant tilbage til almindelig afkodning ét token ad gangen. Den asymmetri er præcis den, man ønsker sig: den accelererer de lette dele og rører ikke de svære.

Hvorfor 4-bit-vægte hører til i samme afsnit

Fordi flaskehalsen er hukommelsesbåndbredde, er det en direkte hastighedshåndtag at skrumpe vægtene — ikke blot et spørgsmål om hukommelsesforbrug. NVFP4 er et 4-bit flydende-komma-format med finkornet skalering pr. blok, og det er dét, der lader det bevare nøjagtighed, hvor ældre 4-bit heltalskvantisering mistede den. Cirka en fjerdedel så mange bytes at læse pr. gennemløb betyder proportionalt mindre tid brugt på at vente på hukommelsen, og det efterlader langt mere plads til den KV-cache til lang kontekst, som et 196K-vindue kræver.

De to forstærker hinanden snarere end blot at lægges sammen: færre bytes pr. gennemløb og færre gennemløb pr. udsendt token. Det er dét, der gør uspærret streaming ved fuld hastighed økonomisk muligt at levere frem for en omkostning, vi skulle hente hjem gennem pacing — hvilket er præcis, hvad pacing-laget lavede på 3.0.

04196,608 tokens: hvad et 6x vindue åbner op for

Shannon 3.0 havde et vindue på 32,768 tokens: en arbejdssession, ikke et dokument. Cirka 70-80 siders prosa, minus det ræsonneringsløkken bruger på sin egen tænkning, minus din systemprompt, minus samtalen indtil videre. Rigtigt arbejde ramte den mur konstant, og løsningerne udenom — opdeling i bidder, opsummering, retrieval over dit eget materiale — forringer alle netop det, du forsøgte at bevare. 196,608 tokens er en anden kategori af problem.

Konkret er det i størrelsesordenen 400-500 siders engelsk tekst, eller en mellemstor kodebase med dens tests og dens README, eller et års mødereferater fra ét projekt, eller et fuldt kontraktsæt med alle bilag — holdt i én samtale, adresserbart i ét spørgsmål, uden et opdelingslag mellem dig og materialet.

• Spørgsmål til hele repositoriet. Indlæs koden og spørg, hvorfor en fejl når produktion, i stedet for at indsætte de tre filer, du allerede havde mistanke til. Modellen kan finde den fil, du ikke tænkte på at tage med.
• Analyse af lange dokumenter uden retrieval. Retrieval er et tabsgivende forfilter, der afgør, hvad modellen får lov at se. Ved 196K kan du ofte springe det over og lade modellen læse alt, hvilket fjerner en hel klasse af fejl, hvor det rigtige afsnit aldrig blev hentet frem.
• Samtaler, der forbliver sammenhængende. En lang arbejdssession taber ikke længere stiltiende sin egen begyndelse. Begrænsninger, du satte i besked tre, gælder stadig i besked firs.
• Plads til ræsonneringsløkken. Løkkens egen tænkning, udkast og gennemgang bruger kontekst. På 3.0 konkurrerede de trin med dit materiale om et knapt budget. På 3.1 er der rigelig plads til dem, og det er en del af grunden til, at kvalitetsløftet og det større vindue kom samtidig.
• Store blandede input. Billeder, udtrukket dokumenttekst og kode i én tur, uden at skulle sortere i, hvad du har råd til at tage med.

Ét ærligt forbehold, der gælder enhver model med lang kontekst, vores inklusive: et stort vindue er en kapacitet, ikke en garanti for ensartet opmærksomhed hen over det. Struktur hjælper stadig. At placere spørgsmålet til sidst, at navngive dine dokumenter og at fortælle modellen, hvad den skal lede efter, forbedrer alle sammen resultaterne målbart ved 150K tokens på en måde, de simpelthen ikke gør ved 5K.

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

De to niveauer adskiller sig i, hvor meget af ræsonneringsløkken de kører, og det er den eneste forskel, der betyder noget, når du skal vælge mellem dem.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
Ræsonnement	Ét gennemløb	Hele løkken + videnshøst
Selvgennemgang	Nej	Ja
Kontekstvindue	196,608	196,608
Streaming	Fuld hastighed, uden spærre	Fuld hastighed, uden spærre
Vision & dokumenter	Ja	Ja
Værktøj til billedgenerering	Ja	Ja
Bedst til	Det meste arbejde, høj volumen	Svære spørgsmål, hvor første udkast ikke rækker

Brug Lite som standard. Ét gennemløb af en god ræsonneringsmodel klarer det store flertal af virkelige forespørgsler, og på 3.1 er den hurtig nok til, at løkken ikke længere er noget, man mærker at vente på. Grib til Pro, når spørgsmålet er af den slags, hvor et første svar som regel er forkert på en lærerig måde: arkitektoniske afvejninger, kontradiktorisk analyse, alt hvor man gerne ville have en kompetent kollega til at sove på det. Pro's selvgennemgangstrin er ikke pynt — det er modellen, der finder sine egne fejl, før du skal.

06De 32% i intelligens, og hvordan tallet skal læses

Shannon Labs egen evaluering placerer Shannon 3.1 på en forbedring i intelligens på 32% over Shannon 3.0. Vi vil gerne være tydelige om, hvad det er, og hvad det ikke er.

Det er vores tal, fra vores interne evalueringssuite, målt på opgaver, vi anser for repræsentative for det, folk faktisk kommer til disse modeller med. Det er ikke et tredjeparts-benchmark, og vi bygger ikke en ranglistetabel op omkring et enkelt internt samletal eller udgiver en opdeling pr. benchmark — en opdeling ville antyde en grad af ekstern sammenlignelighed, som en intern suite ikke har.

Det, vi vil sige, er, hvor gevinsten kommer fra, for den del er ikke mystisk. Et større kontekstvindue betyder, at mindre materiale skal kasseres, før modellen ræsonnerer over det, og en stor del af tilsyneladende dumhed i lange sessioner er i virkeligheden bare hukommelsestab. En serveringsstak, vi selv styrer, betyder, at modellen kører med den konfiguration, vi tilsigtede, frem for en værts standardindstilling. Og ræsonneringsløkken — uændret i design — har nu plads til rent faktisk at køre inde i vinduet i stedet for at blive presset op mod et 32K-loft, den delte med dit input.

07Vision, dokumenter og billedgenerering

Shannon 3.1 læser billeder og dokumenter. Skærmbilleder, diagrammer, fotografier, scannede sider, PDF'er og tekstdokumenter kan indgå i samtalen og indgå i ræsonnementet på lige fod med alt andet. Kombineret med 196K-vinduet er det dét, der gør arbejdsgange med hele dokumenter praktisk mulige: en lang rapport og dens grafer i én tur, uden på forhånd at skulle afgøre, hvilke sider modellen må se.

Billedgenerering og -redigering er tilgængelige i chatten som et værktøj. Bed om et billede, og modellen kalder værktøjet inline, i den samme samtale, med konteksten fra alt det, I har talt om indtil nu. Redigering fungerer på samme måde — giv den et billede, beskriv ændringen. Der er ingen særskilt tilstand at skifte til og ingen særskilt grænseflade at lære.

08Kald Shannon 3.1 fra API'et

Shannon 3.1 er tilgængelig på alle tre API-dialekter, med streaming på hver af dem. Samme modeller, tre forespørgselsformater — vælg det, der passer til det SDK, du allerede har.

Endpoint	Format	Streaming
/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." }
  ]
}

Skift "shannon-3.1" ud med "shannon-3.1-pro" for at køre hele ræsonneringsløkken. Kalder du allerede shannon-3, består migreringen af model-id'et og intet andet: forespørgsels- og svarformaterne er uændrede, og eksisterende streaming-klienter bliver ved med at virke. Den ene adfærdsforskel, du skal forvente, er den mere stødvise strøm beskrevet i afsnit 02 — samme tokens, samme rækkefølge, blot hurtigere fremme og i mindre jævne klumper.

Fuld parameteroversigt, autentificering, fejlsemantik og en interaktiv legeplads findes i API-dokumentationen. Andre modelkort og tekniske gennemgange findes i Shannon research.

09Stadig ucensureret, og uændret på det punkt

Shannon 3.1 har intet afvisningslag og ingen indholdsfiltrering på output. Det er den samme holdning som i resten af Shannon-serien, og den ændrede sig ikke med flytningen til vores egen klynge — om noget gør det lettere at garantere, når vi styrer serveringsstakken, fordi der ikke sidder en mellemliggende vært med sin egen politik mellem modellen og dig.

Værd at sige rent ud, fordi det er det oplagte at undre sig over ved en udgivelse, der har ændret hele outputvejen: at fjerne pacing-laget betød ikke, at der blev indsat et moderationslag i stedet. Intet inspicerer, omskriver eller spærrer strømmen. Det, modellen producerer, er det, der ankommer. Shannon 3.1 er, så vidt vi ved, den hurtigste ucensurerede AI-model, der findes med et kontekstvindue af den størrelse — og de to egenskaber hænger sammen, eftersom begge stammer fra, at vi driver vores egen infrastruktur i stedet for at leje compliance-formet kapacitet af andre.

Ucensureret er ikke det samme som uden ansvar. Brug er reguleret af vores politik for ansvarlig brug, og forpligtelsen, der følger med en model, som vil gå ind i svært materiale, er, at du gør det ansvarligt.

10Kør sammenligningen selv

Hver eneste påstand her kan efterprøves på cirka to minutter, og vi vil hellere have, at du tjekker efter, end at du tror os.

1. Vælg en prompt fra arbejde, du faktisk laver. Lang er bedre — den udfordrer både vinduet og streamingen.
2. Kør den på shannon-3. Notér, hvor længe der går til første token, og hvor længe der går, før svaret er færdigt.
3. Kør den identiske prompt på shannon-3.1. Notér de samme to tal.
4. Læs så begge svar, glem uret, og afgør hvilket ét du helst ville have haft.

Hastighedsforskellen vil være umiddelbar og indlysende. Kvalitetsforskellen er den, der er værd at dvæle ved — den viser sig tydeligst på lange input, hvor 3.0 stille og roligt arbejdede med mindre af dit materiale, end du troede.

11Ofte stillede spørgsmål

---

Tal for ydeevne og intelligens i denne artikel er Shannon Labs egne målinger fra intern evaluering, september 2026, og er angivet som produkttal snarere end resultater fra tredjeparts-benchmarks. Kontekstvindue, model-id'er og API-tilgængelighed er produktspecifikationer. Shannon AI drives af Shannon Lab LLC, New Mexico, USA. Relateret læsning: Shannon 3 · Shannon research-oversigt · API-dokumentation.