Grok 4.6 har 500 000 tokens – men Azure dokumenterar 200 000

Samma modellnamn står på två offerter. Den ena lovar ett kontextfönster på 500 000 tokens. Den andra sätter gränsen vid 200 000. Båda heter Grok 4.6.

Det är inte en fotnot för utvecklare. Det avgör vilka dokument som ryms, hur mycket modellen kan svara och om lösningen ni har sålt ens går att köra på vald molnplattform.

Samma modellnamn, två olika produkter

SpaceXAI beskriver Grok 4.6 med 500 000 tokens både på Amazon Bedrock och i sin lansering för Microsoft Foundry. Microsofts egen implementeringsguide, uppdaterad den 26 augusti, dokumenterar däremot ett totalt kontextfönster på 200 000 tokens för grok-4.6 version 1.

En molnrutt är den endpoint och kommersiella leverans genom vilken modellen används. Rutten kan ändra kontext, verktyg, kvoter, geografi, supportvillkor och fakturering även när modellnamnet är oförändrat.

Det gör inte någon av sidorna automatiskt fel om modellens underliggande kapacitet är större än den aktuella endpointens gräns. Men för köparen är Microsofts dokumenterade endpoint det kontrakt som går att planera mot tills dokumentationen eller tjänsten ändras.

Källa: SpaceXAI – Grok 4.6 on Microsoft Foundry och Microsoft – Deploy and use Grok models in Microsoft Foundry.

Skillnaden på 300 000 tokens är inte kosmetisk

Ta ett underlag på 190 000 tokens: avtal, bilagor, historik och instruktioner. I ett kontextfönster på 500 000 tokens upptar det 38 procent. I Foundrys dokumenterade fönster upptar samma underlag 95 procent.

Microsoft skriver dessutom att indata och genererad utdata delar på de 200 000 tokenplatserna. Ett underlag på 190 000 lämnar därför högst 10 000 tokens till synligt svar och resonemang, även om den angivna maximala utdata är 128 000. Ett jobb som fungerar i en 500 000-tokensrutt kan behöva delas, komprimeras eller byggas om på Foundry.

Det är här modelljämförelser ofta går fel. En benchmark kan säga något om kvalitet. Den säger inget om huruvida just er kombination av underlag, verktyg och svar ryms genom den endpoint ni tänker köpa.

Källa: Microsoft – token limits and context window for Grok 4.6 och SpaceXAI – Grok 4.6 on Amazon Bedrock.

Samma listpris döljer olika leveranser

På ytan ser priset samordnat ut. SpaceXAI anger för Bedrock 2 dollar per miljon indatatokens, 0,50 dollar för cachelagrad indata och 6 dollar per miljon utdatatokens. Microsofts lansering anger samma tre nivåer för Global Standard.

Men samma radpris gör inte rutterna ekonomiskt likvärdiga. Om 200 000-gränsen kräver fler anrop, hårdare komprimering eller ett separat hämtningslager förändras både utvecklingskostnaden och felbilden. Om en större rutt tar hela underlaget i ett anrop kan den vara billigare att driva trots samma tokenpris. Det omvända kan också gälla om den större kontexten uppmuntrar onödigt stora promptar.

Det relevanta måttet är alltså inte pris per token i en lansering. Det är kostnad per godkänt resultat i målmiljön, inklusive extra anrop, cacheträffar, verktygskörningar och omarbete.

Källa: Microsoft – Grok 4.6 comes to Microsoft Foundry Models och SpaceXAI – Bedrock-prissättning.

Molnrutten bestämmer mer än kontexten

Foundry-erbjudandet är Public Preview utan preview-SLA. Microsoft dokumenterar bara Global Standard för Grok 4.6, vilket innebär att bearbetning kan ske globalt; Data Zone Standard finns inte för denna version vid publiceringen. Rutten stöder Chat Completions och Responses, text och bild som indata, funktionsanrop, strömning och JSON. Microsoft påpekar samtidigt att vissa alternativ från SpaceXAI, bland annat live search, inte gäller på Azure-hostade driftsättningar.

Bedrock-lanseringen är däremot märkt som generellt tillgänglig i stödda AWS-regioner och marknadsför 500 000 tokens. Det bevisar inte att varje AWS-konto, region, verktyg eller guardrail har exakt samma beteende. Det måste läsas tillbaka i den region och det konto som ska bära kundlösningen.

Två molnrutter kan därför ge olika svar på fyra affärsfrågor: Får arbetslasten plats? Var behandlas den? Vilka funktioner finns? Vilket driftlöfte kan ni ge kunden?

Källa: Microsofts Foundry-guide och SpaceXAI:s Bedrock-lansering.

Kundofferten bör namnge endpointen

"Vi använder Grok 4.6" är inte längre en tillräcklig arkitekturbeskrivning. Den lämnar öppet om ni menar SpaceXAI:s API, Bedrock, Foundry eller en annan partner – och därmed vilken kontext, geografi, kvot och supportnivå som faktiskt gäller.

En offert blir mer ärlig om den namnger modellversion, leverantörsrutt, driftsättningstyp och de gränser som verifierats i kundens konto. Då kan ni också prissätta förändringen: vad händer om en preview blir GA, om ett regionalt alternativ tillkommer eller om kontextgränsen höjs?

Detta är en inköpsfråga lika mycket som en teknikfråga. Den som bara jämför modellnamn riskerar att köpa en kapacitet som finns i marknadsföringen men inte i den endpoint som organisationen får använda.

Köp bevis från rutten ni faktiskt ska driva

Dokumentationen kan hinna konvergera efter publiceringen av denna artikel. Det ändrar inte slutsatsen. Innan en kundlösning prissätts bör samma representativa arbetslaster köras genom den avsedda endpointen, med faktisk modellversion, region, verktyg och kvot. Spara accepterad indatastorlek, tillgänglig utdata, verktygsbeteende, svarstid och fakturarad.

Om resultaten skiljer sig är det inte modellen som har "misslyckats". Ni har hittat att distributionsrutten är en del av produkten.

För en lösning där molnrutt, kostnad och endpointbeteende måste jämföras före offert kan Verktygssmide hjälpa till att bygga och mäta en avgränsad utvärdering. Målet är inte att utse en universell vinnare, utan att välja den rutt som faktiskt håller ert löfte till kunden.