Ocensurerat Hy3-API

De flesta diskussioner om ”vilken modell ska jag använda” handlar om taket: vilken som skriver bäst kod, löser den svåraste matematiken, vinner den längsta agentkörningen. Strukturerade pipelines fungerar inte så. Ett jobb som utvinner fält ur hundratusen dokument om dagen behöver ingen modell som är briljant en gång — det behöver en som är korrekt i samma form varje gång, och som aldrig returnerar ett stycke prosa där ett JSON-objekt hör hemma. Det är den egenskapen Hy3-W8A16 finns här för.

01Vad Hy3 är, och var modellen kommer ifrån

Hy3 är en resonemangs- och agentmodell med öppna vikter från Tencents Hunyuan-team, släppt i sin helhet den 6 juli 2026 under en tillåtande licens, med vikterna publicerade på Hugging Face. Den fortsätter linjen från Tencents tidigare arbete med Hunyuan-Large och Mixture-of-Experts. Arkitektoniskt är den en gles MoE: 295 miljarder parametrar totalt, varav ungefär 21 miljarder aktiveras per token via top-8-routing över 192 experter, på en transformer med 80 lager och grouped-query attention, plus ett separat lager för multi-token-prediktion på 3,8B för spekulativ avkodning. Den inbyggda kontexten är 256K — exakt de 262 144 tokens vi exponerar, inte en avkortning av något större eller en rope-sträckt utvidgning av något mindre.

Det glesa förhållandet är det viktiga talet för alla som betalar per token: Hy3 bär kunskapen hos en modell på 295B samtidigt som den gör ungefär lika mycket aritmetik som en modell på 21B per framåtpassning. Det är också därför vi har råd att servera den med 8 bitar i stället för att komprimera den hårdare — ett 8-bitarsbygge av en så här gles modell får fortfarande plats och kör fortfarande snabbt på vårt eget GPU-kluster.

Vad Tencent rapporterar att den är bra på

Tencents publicerade utvärderingstabeller placerar Hy3:s styrkor tydligt inom agentisk sökning, verktygsorkestrering och återvinning i lång kontext snarare än i ren kodning. Deras rapporterade siffror:

Vi visar de svaga staplarna med flit. Hy3 ligger efter GLM-5.2 på kodning i Tencents egen jämförelse — 78,0 mot 84,2 på SWE-bench Verified, 28,0 mot 46,2 på DeepSWE. Om din arbetsbelastning är autonom mjukvaruutveckling över flera filer, läs resten av forskningsindexet över modeller först. Om den handlar om att läsa text och avge struktur ligger profilen nära det ideala.

Siffran som betyder mest för pipelinearbete är en tillförlitlighetssiffra: Tencent rapporterar Hy3:s hallucinationsfrekvens till 5,4 %, ned från 12,5 % i föregående generation, med fel i sunt förnuft nedgångna från 25,4 % till 12,7 %. Deras uttalade träningsprincip — svara när det finns belägg, säg rakt ut när det inte finns några — är precis den läggning du vill ha i en utvinningsmodell som annars hittar på ett rimligt värde för ett fält som källan aldrig nämner.

Alla siffror i det här avsnittet är rapporterade av Tencent från deras egna testkörningar; oberoende verifiering från tredje part var fortfarande under arbete när detta skrevs. Behandla dem som riktningsgivande, inte avgjorda.

02Vad W8A16 betyder, och varför det spelar roll för strukturerad utdata

Varje modell på gatewayen bär ett kvantiseringssuffix. Det är ingen dekoration — det talar om hur långt de serverade vikterna ligger från den kontrollpunkt labbet släppte.

Nivå	Vad den gör	Trohet
3BIT-REAP	3-bitars vikter plus REAP, en metod för expertbeskärning som slänger sällan använda MoE-experter före kvantiseringen	Mest komprimerad
W4A16-AUTOROUND-REAP	4-bitars vikter / 16-bitars aktiveringar via AutoRound — inlärd avrundning som återvinner träffsäkerhet jämfört med naiv avrundning till närmaste — plus REAP-beskärning	Mellan
W8A16	8-bitars vikter / 16-bitars aktiveringar. Ingen beskärning, ingen reparation med inlärd avrundning — vikterna bärs helt enkelt med dubbel precision	Högst

Var kvantiseringsdriften faktiskt gör ont

REAP och AutoRound återvinner det mesta av det som naiv komprimering förlorar — men ”det mesta” gör ett tungt jobb i den meningen, och resten fördelar sig inte jämnt. Lågbitskvantisering försämrar svansarna: besluten med låg sannolikhet och hög specificitet. I prosa är det nästan osynligt; ett annat adjektiv ger fortfarande en fin mening. I strukturerad utdata är det hela poängen, eftersom ett schema är en lång kedja av beslut med låg sannolikhet som vart och ett måste bli exakt rätt:

• Syntax på tokennivå. En avslutande klammer, ett kommatecken, ett citattecken. Vart och ett är en token, och en enda felaktig token ogiltigförklarar hela svaret.
• Enum-disciplin. Ditt schema säger att "status" är en av "open" | "closed" | "pending"; en driven modell returnerar "Open" eller "pending review" — semantiskt nära, och giltigt som ingetdera.
• Typdisciplin. Ett number-fält kommer tillbaka som "1,240", ett boolean som "yes". Båda tolkas som strängar och faller på schemat.
• Litteraler i den långa svansen. Ovanliga egennamn, artikelnummer, kemiska namn, icke-latinska skriftsystem, exakta datum — precis den region med låg sannolikhet som lågbitsvikter suddar ut.

Inget av detta gör 4-bitars- eller 3-bitarsmodeller dåliga; för samtalsarbete är trohetsskillnaden ofta inte värd prisskillnaden. Men när det är en validerare snarare än en människa som konsumerar utdatan omvandlas precision i svansarna direkt till andel som tolkas — och den andelen till budget för omförsök och p99-latens. W8A16 är nivån där du slutar betala den skatten.

03Strukturerad utdata: json_schema och response_format

Hy3 stöder båda halvorna av ytan för strukturerad utdata — värt att säga uttryckligen, eftersom det inte gäller genomgående i katalogen:

Modell	response_format	json_schema
Hy3 · W8A16	Ja	Ja
MiMo-V2.5-Pro · W8A16	Ja	Ja
inkling · W4A16-AUTOROUND-REAP	Ja	Nej
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	Nej	Nej

Skillnaden mellan de två mekanismerna spelar större roll än folk antar. response_format: {"type": "json_object"} ber om giltig JSON och inget mer — modellen väljer formen, så två anrop kan returnera {"name": ...} och {"full_name": ...} och båda är korrekta. json_schema anger formen i förväg: namngivna fält, typer, enums, listor över obligatoriska fält, nästling. Det är ett kontrakt du kan skriva kod mot.

Ett minimalt anrop i den OpenAI-kompatibla dialekten:

POST /v1/chat/completions

{
  "model": "Hy3-W8A16",
  "messages": [
    {"role": "system", "content": "Extract fields from the incident report. Use null for anything not stated."},
    {"role": "user", "content": "<report text>"}
  ],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "incident",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "severity":  {"type": "string", "enum": ["low","medium","high","critical"]},
          "component": {"type": "string"},
          "occurred_at": {"type": ["string","null"], "description": "ISO-8601"},
          "affected_users": {"type": ["integer","null"]},
          "indicators": {
            "type": "array",
            "items": {"type": "object", "properties": {
              "kind":  {"type": "string", "enum": ["ip","domain","hash","cve"]},
              "value": {"type": "string"}
            }, "required": ["kind","value"]}
          }
        },
        "required": ["severity","component","occurred_at","affected_users","indicators"]
      }
    }
  }
}

Praktiska noteringar

• Gör varje fält obligatoriskt och tillåt null. Valfria fält bjuder in till tysta bortfall; ett obligatoriskt fält som tillåter null tvingar fram ett uttryckligt ”finns inte”, vilket är information du kan agera på.
• Enums slår fria strängar. Överallt där du kan sluta värdemängden, gör det — den enskilt mest verkningsfulla ändringen för ett schemas verkliga godkännandegrad.
• Håll dig under utdatataket på 16 384 tokens. En obegränsad array kommer att kapas mitt i ett objekt. Sätt tak på arraylängder, eller dela upp indatan.
• Behåll systemmeddelandet. Schemat styr formen; prompten styr fortfarande semantiken — vad som räknas som ”kritiskt”, vilket datum som vinner när två dyker upp, om enheter ska normaliseras.
• Validera ändå. Schemastöd höjer godkännandegraden; det ersätter inte en validerare och en dead letter-kö.

04Varför ”ocensurerad” är en tillförlitlighetsegenskap, inte bara en innehållsfråga

Hy3 på gatewayen har inget vägranslager och ingen filtrering av utdata. Den vanliga inramningen handlar om innehåll: du kan bearbeta säkerhetsforskning, analys av skadlig kod, beskrivningar av sårbarheter, medicinska och juridiska korpusar, vuxet material, dokumentation om skadereducering eller transkript från fientliga användare utan att modellen bestämmer åt dig att den hellre låter bli.

Det finns ett andra, mer mekaniskt skäl till att det spelar roll. En vägran är en schemaöverträdelse. En filtrerad modell som avböjer returnerar inte ditt objekt med en flagga "unavailable" — den returnerar prosa. ”Jag kan tyvärr inte hjälpa till med den förfrågan.” Den strängen är inget incident-objekt; den faller på din validerare och hamnar i dead letter-kön bredvid genuina tolkningsfel, där du nu måste skilja policyvägranden från verkliga formfel.

Värre är att vägranden korrelerar med innehåll i stället för att fördela sig slumpmässigt. Om 4 % av din korpus är säkerhetsincidentrapporter och modellen avböjer de flesta av dem, har du inte förlorat 4 % av genomströmningen jämnt — du har förlorat en kategori, och instrumentpanelen som byggts på den datan underrapporterar tyst precis det den finns till för att visa. Hål som har formen av en kategori kostar mer än jämnt brus, eftersom ingenting larmar om dem. Ta bort vägransvägen och det som återstår — formfel, avkortningar, tvetydig text — är okorrelerat med ämne, och därmed mätbart.

05Kontext, utdatatak och hur du budgeterar dem

Varje modell på gatewayen delar samma gränser:

Kontexten är en gemensam budget: prompt plus utdata måste rymmas inom 262 144 tillsammans, så det praktiska indatataket i ett anrop ligger på ungefär 245 000 tokens, mycket grovt räknat 180 000 engelska ord. För strukturerat arbete är utdatataket på 16 384 tokens den hårdare gränsen och den som överraskar folk — ett schema som avger ett objekt per post når det långt innan fönstret fylls. Två mönster fungerar mot det:

• Bred indata, smal utdata. Tryck in ett helt kontrakt, en hel inlaga eller ett helt loggfönster i kontexten och be om ett enda kompakt objekt. Indatatokens kostar en fjärdedel av vad utdatatokens gör, så prissättningen belönar att läsa mycket och skriva lite.
• Dela på postgränser, inte på byteantal. Klyv där modellen kan se skarven. En post som kapas mitt i en mening ger ett självsäkert felaktigt objekt i stället för ett uppenbart misslyckande.

Hy3:s rapporterade styrka i återvinning ur lång kontext — 73,4 på AA-LCR, och ett hopp från 42,9 % till 75,1 % på MRCR för minne i långa dialoger — är precis den förmåga som det första mönstret vilar på, och en annan färdighet än att skriva bra.

06Golvpris, och aritmetiken i en verklig pipeline

Hy3 ligger på $0.50 per miljon indatatokens och $2.00 per miljon utdatatokens — katalogens golv, delat med MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 och MiniMax-M3. Räknat igenom på representativa laster:

Arbetsbelastning	Indata / anrop	Utdata / anrop	Kostnad / anrop	Per 1M anrop
Fältutvinning	1 200	300	$0.0012	$1 200
Dokumentklassificering	3 000	120	$0.0018	$1 800
Långt dokument sammanfattat till schema	40 000	900	$0.0218	$21 800
Analys över hela fönstret	240 000	2 000	$0.1240	$124 000

Talet som ändrar beslut är inte listpriset utan den effektiva kostnaden efter omförsök. Om två modeller kostar lika mycket och den ena faller på valideringen i 6 % av anropen där den andra faller i 1,5 %, kör modellen med hög drift ungefär 4,5 % fler anrop — uthärdligt. Skadan ligger i svansen: omförsökta anrop tar dubbelt så lång tid, så p99-latensen ungefär fördubblas för en synlig del av trafiken, och det som faller två gånger blir manuellt arbete. Vid en miljon anrop om dagen är det tusentals poster som någon måste läsa.

Därav argumentet för 8-bitarsnivån till golvpris: du betalar ingen premie för trohet här, så aritmetiken kring omförsök är gratis pengar. Om en 3-bitarsmodell vore billigare fanns det en verklig avvägning att väga — Hy3 kostar lika mycket som det billigaste i katalogen.

07Tre API-dialekter, en modell

Hy3 är nåbar på alla tre gateway-dialekterna med strömning på var och en. Samma modell, samma vikter, samma gränser — välj den som matchar det SDK du redan har.

Slutpunkt	Dialekt	Använd när
/v1/chat/completions	OpenAI	Du har ett OpenAI-SDK, LangChain eller LlamaIndex. Peka bas-URL:en hit och byt modell-id.
/v1/messages	Anthropic	Du använder Anthropics SDK och vill ha innehållsblock utan ett översättningslager.
/v1/responses	Responses	Du vill ha den nyare förfrågningsformen med typad utdata och tillstånd på serversidan.

Hy3 stöder också verktygsanrop och resonemang, inklusive reasoning_effort. För utvinningsarbete är det oftast klokt att skruva ned resonemanget: på ett välspecificerat schema över ren text är tänketokens utdatatokens som du betalar för och latens som du väntar ut, för en marginell vinst. Lägg budgeten för resonemang på genuint tvetydig indata i stället.

Fullständig referens för förfrågningar och svar, parameterlistor, semantik för strömning och en interaktiv lekplats finns i API-dokumentationen.

08Att välja bland de tre W8A16-modellerna

Tre modeller ligger på nivån med högst trohet, alla till golvpris. Valet handlar mest om modalitet:

Modell	Vision	json_schema	Pris in / ut	Välj den för
Hy3 · W8A16	Nej	Ja	$0.50 / $2.00	Strukturerade pipelines med enbart text, verktygsorkestrering, återvinning i lång kontext
MiMo-V2.5-Pro · W8A16	Nej	Ja	$0.50 / $2.00	Textarbete där du vill ha Pro-trimningen av MiMo-släktet
MiMo-V2.5 · W8A16	Ja	Ja	$0.50 / $2.00	Allt med bilder — skannade dokument, skärmbilder, foton

Om någon del av din indata är en bild är beslutet redan fattat åt dig: Hy3 hanterar endast text — skicka skannade PDF-filer, skärmbilder och fotografier till MiMo-V2.5. Där indatan verkligen är text mappar Hy3:s profil av agentisk verktygsanvändning, minne i lång kontext och låg rapporterad hallucination mest direkt mot pipelinearbete. Eftersom alla tre kostar lika mycket: kör ditt schema mot två av dem på några hundra verkliga poster och jämför andelen som tolkas; det avgör saken bättre än någon tabell, inklusive den här.

09Där Hy3 förtjänar sin plats

• Fältutvinning med hög volym. Kontrakt, inlagor, incidentrapporter, transkript, kliniska anteckningar, domstolshandlingar — överallt där ett typat objekt per dokument är leveransen och volymen gör omförsök dyra.
• Klassificering och routning i skala. Utdata med slutna enums, där modellens hela värde är att aldrig hitta på en nittonde kategori.
• Korpusar för säkerhet och hotunderrättelser. Beskrivningar av skadlig kod, publicerade sårbarheter och nätfiskeprover — materialet som får filtrerade modeller att vägra, och där ett kategoriformat hål omintetgör hela syftet.
• Verktygsanropande agenter som inte får stanna. Trohet på 8 bitar i argumenten betyder att den JSON som lämnas till dina funktioner går att tolka; ett förvanskat verktygsanrop är en stoppad agent, inte ett något sämre svar.
• Analys av långa dokument till struktur. Hela inlagan in, ett kompakt objekt ut.
• Innehållsmoderering och policyforskning. Att märka upp material som en filtrerad modell vägrar läsa är ett stående problem inom trust and safety; en ofiltrerad modell med ett strikt schema löser det direkt.

Och där den inte gör det: allt med bilder (använd MiMo-V2.5), och autonom mjukvaruutveckling över flera filer, där Tencents egna tabeller placerar Hy3 efter GLM-5.2 på SWE-bench Verified och långt efter på DeepSWE.

Benchmarksiffrorna är rapporterade av Tencent, inklusive konkurrenternas tal; oberoende verifiering pågick fortfarande när detta skrevs. Kostnadssiffrorna är beräknade utifrån våra publicerade priser $0.50 / $2.00. Ingen siffra på den här sidan är en benchmark körd av Shannon eller en uppskattning.

10Vanliga frågor

---

Källor: Tencent Hunyuans modellkort · Hy3-kodförrådet · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · VentureBeats bevakning av Hy3-släppet. Grundmodellens benchmarks är rapporterade av Tencent och preliminära i väntan på oberoende verifiering. Shannon AI drivs av Shannon Lab LLC, New Mexico, USA.