અનસેન્સર્ડ Hy3 મોડેલ API

મોટાભાગની "કયો મોડેલ વાપરવો" દલીલો સીલિંગ વિશે હોય છે: કયો સૌથી સારો કોડ લખે છે, સૌથી અઘરું ગણિત ઉકેલે છે, સૌથી લાંબો એજન્ટ રન જીતે છે. સ્ટ્રક્ચર્ડ પાઇપલાઇન એ રીતે કામ કરતી નથી. દિવસમાં એક લાખ ડોક્યુમેન્ટમાંથી ફિલ્ડ કાઢતી જોબને એવા મોડેલની જરૂર નથી જે એકવાર બ્રિલિયન્ટ હોય — તેને એવા મોડેલની જરૂર છે જે દર વખતે એ જ આકારમાં સાચું હોય, અને જ્યાં JSON ઑબ્જેક્ટ હોવો જોઈએ ત્યાં ક્યારેય પેરેગ્રાફ પાછો ન આપે. એ જ ગુણધર્મ છે જેના માટે Hy3-W8A16 અહીં છે.

01Hy3 શું છે, અને તે ક્યાંથી આવે છે

Hy3 એ Tencent ની Hunyuan ટીમ તરફથી ઓપન-વેઇટ્સ રિઝનિંગ અને એજન્ટિક મોડેલ છે, જે 6 જુલાઈ, 2026 ના રોજ પરમિસિવ લાયસન્સ હેઠળ પૂરેપૂરું રિલીઝ થયું, Hugging Face પર પ્રકાશિત વેઇટ્સ સાથે. તે Tencent ના અગાઉના Hunyuan-Large મિક્સ્ચર-ઓફ-એક્સપર્ટ્સ કામનો વારસો ચાલુ રાખે છે. આર્કિટેક્ચરલી તે sparse MoE છે: 295 અબજ કુલ પેરામીટર, જેમાંથી લગભગ 21 અબજ ટોકન દીઠ એક્ટિવ થાય છે 192 એક્સપર્ટ પર top-8 રાઉટિંગ દ્વારા, grouped-query attention સાથેના 80-લેયર ટ્રાન્સફોર્મર પર, વત્તા speculative decoding માટે અલગ 3.8B multi-token-prediction લેયર. નેટિવ કોન્ટેક્સ્ટ 256K છે — બરાબર 262,144 ટોકન જે અમે ખુલ્લા મૂકીએ છીએ, કંઈક મોટાનું truncation નહીં કે કંઈક નાનાનું rope-stretched extension નહીં.

એ sparsity ratio ટોકન દીઠ ચૂકવતા કોઈપણ માટે મહત્વનો આંકડો છે: Hy3 295B મોડેલનું જ્ઞાન ધરાવે છે જ્યારે દરેક forward pass માં લગભગ 21B ની ગણતરી કરે છે. એ પણ કારણ છે કે અમે તેને વધુ સંકોચવાને બદલે 8 બિટ પર સર્વ કરવાનું પોસાય એવું બનાવી શકીએ છીએ — આટલા sparse મોડેલનું 8-બિટ બિલ્ડ હજુ પણ ફિટ થાય છે અને અમારા પોતાના GPU ક્લસ્ટર પર ઝડપથી ચાલે છે.

Tencent શેમાં સારું હોવાનું જણાવે છે

Tencent ના પ્રકાશિત મૂલ્યાંકન કોષ્ટકો Hy3 ની તાકાત ચોખ્ખી રીતે એજન્ટિક સર્ચ, ટૂલ ઓર્કેસ્ટ્રેશન, અને લોંગ-કોન્ટેક્સ્ટ રિટ્રીવલ માં મૂકે છે, કાચા કોડિંગમાં નહીં. તેમના જણાવેલા આંકડા:

અમે નબળા bar જાણી જોઈને બતાવીએ છીએ. Tencent ની પોતાની સરખામણીમાં Hy3 કોડિંગ પર GLM-5.2 થી પાછળ છે — SWE-bench Verified પર 78.0 સામે 84.2, DeepSWE પર 28.0 સામે 46.2. જો તમારો વર્કલોડ સ્વાયત્ત મલ્ટિ-ફાઇલ સોફ્ટવેર એન્જિનિયરિંગ છે, તો પહેલા બાકીના મોડેલ રિસર્ચ ઇન્ડેક્સને વાંચો. જો તે ટેક્સ્ટ વાંચવાનું અને સ્ટ્રક્ચર ઉત્પન્ન કરવાનું છે, તો પ્રોફાઇલ લગભગ આદર્શ છે.

પાઇપલાઇન કામ માટે સૌથી વધુ મહત્વનો આંકડો વિશ્વસનીયતાનો છે: Tencent Hy3 નો હેલ્યુસિનેશન દર 5.4% જણાવે છે, પાછલી પેઢીના 12.5% થી ઘટીને, જ્યારે commonsense ભૂલો 25.4% થી ઘટીને 12.7% થઈ. તેમનો જણાવેલો તાલીમ સિદ્ધાંત — જ્યારે પુરાવો હોય ત્યારે જવાબ આપો, જ્યારે ન હોય ત્યારે સ્પષ્ટ કહો — બરાબર એ જ સ્વભાવ છે જે તમે નિષ્કર્ષણ મોડેલમાં ઇચ્છો છો, જે નહીં તો સોર્સ ક્યારેય ઉલ્લેખ ન કરે એવા ફિલ્ડ માટે બુદ્ધિગમ્ય મૂલ્યની શોધ કરી કાઢે.

આ સેક્શનના બધા આંકડા Tencent દ્વારા તેમના પોતાના ટેસ્ટ રનમાંથી જણાવેલા છે; લખાણ સમયે સ્વતંત્ર તૃતીય-પક્ષ વેરિફિકેશન હજુ બાકી હતું. તેમને દિશાસૂચક ગણો, નિર્ણિત નહીં.

02W8A16 નો શું અર્થ થાય છે, અને સ્ટ્રક્ચર્ડ આઉટપુટ માટે તે કેમ મહત્વનું છે

ગેટવે પરનો દરેક મોડેલ ક્વોન્ટાઇઝેશન પ્રત્યય ધરાવે છે. તે શણગાર નથી — તે તમને કહે છે કે સર્વ થયેલા વેઇટ્સ લેબે રિલીઝ કરેલા checkpoint થી કેટલા દૂર બેસે છે.

ટાયર	તે શું કરે છે	ફિડેલિટી
3BIT-REAP	3-bit વેઇટ્સ વત્તા REAP, એક એક્સપર્ટ-પ્રુનિંગ પદ્ધતિ જે ક્વોન્ટાઇઝ કરતાં પહેલાં ભાગ્યે જ રાઉટ થતા MoE એક્સપર્ટને દૂર કરે છે	સૌથી વધુ કમ્પ્રેસ્ડ
W4A16-AUTOROUND-REAP	4-bit વેઇટ્સ / 16-bit એક્ટિવેશન AutoRound મારફતે — learned રાઉન્ડિંગ જે naive round-to-nearest કરતાં ચોકસાઈ પાછી મેળવે છે — વત્તા REAP પ્રુનિંગ	મધ્યમ
W8A16	8-bit વેઇટ્સ / 16-bit એક્ટિવેશન. કોઈ પ્રુનિંગ નહીં, કોઈ learned-rounding રિપેર નહીં — વેઇટ્સ ફક્ત બમણી ચોકસાઈ પર રાખવામાં આવે છે	સૌથી ઊંચી

ક્વોન્ટાઇઝેશન drift ખરેખર ક્યાં નુકસાન કરે છે

REAP અને AutoRound naive કમ્પ્રેશન જે ગુમાવે છે એમાંથી મોટાભાગનું પાછું મેળવે છે — પણ એ વાક્યમાં "મોટાભાગનું" કામ કરી રહ્યું છે, અને બાકી રહેલું સરખી રીતે નથી પડતું. Low-bit ક્વોન્ટાઇઝેશન tails ને બગાડે છે: ઓછી-સંભાવના, ઊંચી-વિશિષ્ટતાના નિર્ણયો. પ્રોઝમાં એ લગભગ અદ્રશ્ય છે; અલગ વિશેષણ પણ સારું વાક્ય જ રહે છે. સ્ટ્રક્ચર્ડ આઉટપુટમાં એ આખી રમત છે, કારણ કે સ્કીમા ઓછી-સંભાવના નિર્ણયોની લાંબી સાંકળ છે જેમાં દરેક બરાબર સાચો હોવો જ જોઈએ:

• ટોકન-લેવલ સિન્ટેક્સ. એક closing brace, એક કૉમા, એક quote character. દરેક એક ટોકન છે, અને એક ખોટો ટોકન આખા રિસ્પોન્સને અમાન્ય કરે છે.
• Enum discipline. તમારી સ્કીમા કહે છે કે "status" એ "open" | "closed" | "pending" માંનું એક છે; drift થયેલો મોડેલ "Open" કે "pending review" પાછું આપે છે — semantically નજીક, અને બંનેમાંથી એકેય valid નહીં.
• Type discipline. number ફિલ્ડ "1,240" તરીકે પાછું આવે છે, boolean "yes" તરીકે. બંને strings તરીકે parse થાય છે અને સ્કીમામાં નિષ્ફળ જાય છે.
• Long-tail literals. દુર્લભ proper nouns, part numbers, રાસાયણિક નામ, non-Latin scripts, ચોક્કસ તારીખો — બરાબર એ ઓછી-સંભાવના પ્રદેશ જેને low-bit વેઇટ્સ ધૂંધળો કરે છે.

આમાંનું કંઈ 4-bit કે 3-bit મોડેલોને ખરાબ બનાવતું નથી; વાતચીતના કામ માટે ફિડેલિટીનો ફરક ઘણી વાર કિંમતના ફરક જેટલો લાયક નથી. પણ જ્યારે આઉટપુટનો ગ્રાહક માણસ નહીં પણ validator હોય, ત્યારે tails પરની ચોકસાઈ સીધી parse rate માં બદલાય છે — અને parse rate retry બજેટ અને p99 latency માં. W8A16 એ ટાયર છે જ્યાં તમે એ ટેક્સ ચૂકવવાનું બંધ કરો છો.

03સ્ટ્રક્ચર્ડ આઉટપુટ: json_schema અને response_format

Hy3 સ્ટ્રક્ચર્ડ-આઉટપુટ સપાટીના બંને ભાગને સમર્થન આપે છે — સ્પષ્ટપણે કહેવા યોગ્ય, કારણ કે તે કેટલોગમાં સાર્વત્રિક નથી:

મોડેલ	response_format	json_schema
Hy3 · W8A16	હા	હા
MiMo-V2.5-Pro · W8A16	હા	હા
inkling · W4A16-AUTOROUND-REAP	હા	ના
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	ના	ના

બે mechanism વચ્ચેનો ફરક લોકો ધારે છે એના કરતાં વધુ મહત્વનો છે. response_format: {"type": "json_object"} valid JSON માંગે છે અને એથી વધુ કંઈ નહીં — મોડેલ આકાર પસંદ કરે છે, એટલે બે કૉલ {"name": ...} અને {"full_name": ...} પાછા આપી શકે છે અને બંને સાચા છે. json_schema અગાઉથી આકાર પૂરો પાડે છે: named ફિલ્ડ, types, enums, required લિસ્ટ, nesting. એ એવો contract છે જેની સામે તમે કોડ લખી શકો.

OpenAI-કમ્પેટિબલ ડાયલેક્ટ પર એક minimal કૉલ:

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"]
      }
    }
  }
}

વ્યવહારુ નોંધ

• દરેક ફિલ્ડને required બનાવો અને null ને મંજૂરી આપો. Optional ફિલ્ડ silent drops ને આમંત્રણ આપે છે; required nullable ફિલ્ડ સ્પષ્ટ "હાજર નથી" ફરજ પાડે છે, જે માહિતી છે જેના પર તમે કાર્ય કરી શકો.
• Enums મુક્ત strings કરતાં વધુ સારા છે. જ્યાં પણ તમે value set બંધ કરી શકો, બંધ કરો — સ્કીમાના real-world pass rate માટે સૌથી વધુ-લિવરેજ ફેરફાર.
• 16,384-ટોકન આઉટપુટ સીલિંગની નીચે રહો. એક unbounded array mid-object પર truncate થશે. Array લંબાઈ કેપ કરો, અથવા ઇનપુટને shard કરો.
• સિસ્ટમ મેસેજ રાખો. સ્કીમા આકારને constrain કરે છે; prompt હજુ પણ semantics નિયંત્રિત કરે છે — શું "critical" ગણાય, બે તારીખ દેખાય ત્યારે કઈ જીતે, units normalize કરવા કે નહીં.
• ગમે તે થાય વેલિડેટ કરો. સ્કીમા સમર્થન pass rate વધારે છે; તે validator અને dead-letter queue ને બદલતું નથી.

04"અનસેન્સર્ડ" શા માટે ફક્ત કન્ટેન્ટનો નહીં, વિશ્વસનીયતાનો ગુણધર્મ છે

ગેટવે પર Hy3 પાસે કોઈ ઇનકાર સ્તર અને કોઈ આઉટપુટ ફિલ્ટરિંગ નથી. સામાન્ય framing કન્ટેન્ટ વિશે છે: તમે સિક્યુરિટી રિસર્ચ, malware વિશ્લેષણ, exploit write-ups, મેડિકલ અને લીગલ corpora, adult સામગ્રી, harm-reduction દસ્તાવેજીકરણ કે hostile-user transcripts ને, મોડેલ તમારા વતી નક્કી કર્યા વગર કે તે ના ઇચ્છે, પ્રોસેસ કરી શકો છો.

એક બીજું, વધુ mechanical કારણ છે કે તે મહત્વનું છે. ઇનકાર એ સ્કીમા violation છે. ના પાડતો ફિલ્ટર થયેલ મોડેલ "unavailable" ફ્લેગ સાથે તમારો ઑબ્જેક્ટ પાછો નથી આપતો — તે prose પાછું આપે છે. "હું એ વિનંતીમાં મદદ કરી શકતો નથી." એ string incident ઑબ્જેક્ટ નથી; તે તમારા validator માં નિષ્ફળ જાય છે અને genuine parse errors ની બાજુમાં dead-letter queue માં ઊતરે છે, જ્યાં હવે તમારે policy refusals ને real malformations થી અલગ પાડવા પડે છે.

વધુ ખરાબ, ઇનકાર રેન્ડમલી વહેંચાવાને બદલે કન્ટેન્ટ સાથે correlate થાય છે. જો તમારા corpus નો 4% સિક્યુરિટી incident રિપોર્ટ હોય અને મોડેલ તેમાંથી મોટાભાગનાની ના પાડે, તો તમે throughput નો 4% સરખી રીતે ગુમાવ્યો નથી — તમે એક કેટેગરી ગુમાવી છે, અને એ ડેટા પર બનેલું dashboard એ જ વસ્તુને ચૂપચાપ under-report કરે છે જેને સપાટી પર લાવવા માટે તે અસ્તિત્વમાં છે. Category-shaped છિદ્રો uniform noise કરતાં વધુ ખર્ચે છે કારણ કે તેમના પર કંઈ alert થતું નથી. ઇનકારનો રસ્તો દૂર કરો અને જે બાકી રહે છે — malformations, truncations, અસ્પષ્ટ ટેક્સ્ટ — તે વિષય સાથે uncorrelated છે, અને તેથી measurable છે.

05કોન્ટેક્સ્ટ, આઉટપુટ સીલિંગ, અને તેમનું બજેટ કેવી રીતે બનાવવું

ગેટવે પરના દરેક મોડેલ સરખી મર્યાદા શેર કરે છે:

કોન્ટેક્સ્ટ એક શેર્ડ બજેટ છે: prompt વત્તા આઉટપુટ બંને સાથે મળીને 262,144 ની અંદર ફિટ થવા જોઈએ, એટલે એક કૉલમાં વ્યવહારુ ઇનપુટ સીલિંગ લગભગ 245,000 ટોકન છે, ખૂબ ઢીલી રીતે 180,000 અંગ્રેજી શબ્દો. સ્ટ્રક્ચર્ડ કામ માટે 16,384-ટોકન આઉટપુટ કેપ વધુ કડક મર્યાદા છે અને એ છે જે લોકોને આશ્ચર્યચકિત કરે છે — રેકોર્ડ દીઠ એક ઑબ્જેક્ટ ઉત્પન્ન કરતી સ્કીમા વિન્ડો ભરાય એના ઘણા પહેલાં તેને હિટ કરે છે. બે પેટર્ન એની સામે કામ કરે છે:

• પહોળું ઇનપુટ, સાંકડું આઉટપુટ. આખો contract, filing કે log વિન્ડો કોન્ટેક્સ્ટમાં push કરો અને એક કોમ્પેક્ટ ઑબ્જેક્ટ માંગો. ઇનપુટ ટોકન આઉટપુટ ટોકનના ચોથા ભાગની કિંમતના છે, એટલે pricing ઘણું વાંચવા અને થોડું લખવાનું ઈનામ આપે છે.
• Byte counts પર નહીં, record boundaries પર chunk કરો. જ્યાં મોડેલ seam જોઈ શકે ત્યાં split કરો. મધ્ય-વાક્યમાં કપાયેલો record સ્પષ્ટ નિષ્ફળતાને બદલે confidently ખોટો ઑબ્જેક્ટ ઉત્પન્ન કરે છે.

Hy3 ની જણાવેલી long-context retrieval તાકાત — AA-LCR પર 73.4, અને MRCR long-dialogue recall પર 42.9% થી 75.1% સુધીનો કૂદકો — બરાબર એ જ ક્ષમતા છે જેના પર પહેલી પેટર્ન આધાર રાખે છે, અને સારું લખવા કરતાં અલગ કૌશલ્ય છે.

06તળિયાની કિંમત, અને ખરી પાઇપલાઇનનું અંકગણિત

Hy3 1 મિલિયન ઇનપુટ ટોકન દીઠ $0.50 અને 1 મિલિયન આઉટપુટ ટોકન દીઠ $2.00 પર બેસે છે — કેટલોગનું તળિયું, MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 અને MiniMax-M3 સાથે શેર થયેલું. પ્રતિનિધિ લોડ પર કામ કરેલું:

વર્કલોડ	ઇનપુટ / કૉલ	આઉટપુટ / કૉલ	કિંમત / કૉલ	1M કૉલ દીઠ
ફિલ્ડ નિષ્કર્ષણ	1,200	300	$0.0012	$1,200
ડોક્યુમેન્ટ વર્ગીકરણ	3,000	120	$0.0018	$1,800
સ્કીમા માટે લોંગ-ડોક સારાંશ	40,000	900	$0.0218	$21,800
ફુલ-વિન્ડો વિશ્લેષણ	240,000	2,000	$0.1240	$124,000

નિર્ણય બદલતો આંકડો headline rate નથી પણ retries પછીનો effective rate છે. જો બે મોડેલ સરખી કિંમતના હોય અને એક 6% કૉલ પર validation નિષ્ફળ જાય જ્યારે બીજો 1.5% પર, તો high-drift મોડેલ લગભગ 4.5% વધુ કૉલ ચલાવે છે — ટકી શકાય એવું. નુકસાન tail પર છે: retried કૉલ બમણો સમય લે છે, એટલે traffic ના દેખાતા હિસ્સા માટે p99 latency લગભગ બમણું થાય છે, અને જે કંઈ બે વાર નિષ્ફળ જાય એ manual કામ બની જાય છે. દિવસમાં દસ લાખ કૉલ પર એ હજારો રેકોર્ડ છે જે કોઈએ વાંચવા પડે.

એટલે તળિયાની કિંમતે 8-bit ટાયર માટેનો કેસ: અહીં તમે ફિડેલિટી માટે premium ચૂકવી રહ્યા નથી, એટલે retry અંકગણિત મફત પૈસા છે. જો 3-bit મોડેલ સસ્તું હોત તો તોલવા જેવો ખરો trade-off હોત — Hy3 કેટલોગની સૌથી સસ્તી વસ્તુ જેટલી જ કિંમતની છે.

07ત્રણ API ડાયલેક્ટ, એક મોડેલ

Hy3 ત્રણેય ગેટવે ડાયલેક્ટ પર પહોંચી શકાય એવું છે, દરેક પર સ્ટ્રીમિંગ સાથે. એ જ મોડેલ, એ જ વેઇટ્સ, એ જ મર્યાદા — તમારી પાસે પહેલેથી છે એ SDK સાથે જે મેચ થાય એ પસંદ કરો.

એન્ડપોઇન્ટ	ડાયલેક્ટ	ક્યારે વાપરવું
/v1/chat/completions	OpenAI	તમારી પાસે OpenAI SDK, LangChain કે LlamaIndex છે. base URL અહીં પોઇન્ટ કરો, મોડેલ id બદલો.
/v1/messages	Anthropic	તમે Anthropic SDK પર છો અને translation layer વગર content blocks ઇચ્છો છો.
/v1/responses	Responses	તમને typed આઉટપુટ અને server-side state સાથે નવો request આકાર જોઈએ છે.

Hy3 ટૂલ કૉલિંગ અને reasoning ને પણ સમર્થન આપે છે, reasoning_effort સહિત. નિષ્કર્ષણ કામ માટે ઉપયોગી પગલું સામાન્ય રીતે reasoning ને નીચે લાવવાનું છે: ચોખ્ખા ટેક્સ્ટ પર સારી રીતે specified સ્કીમા પર, thinking ટોકન એવા આઉટપુટ ટોકન છે જેના માટે તમે ચૂકવો છો અને latency જેમાંથી તમે રાહ જુઓ છો, marginal gain માટે. તેના બદલે effort બજેટ ખરેખર અસ્પષ્ટ ઇનપુટ પર ખર્ચો.

પૂરો request અને response સંદર્ભ, પેરામીટર લિસ્ટ, streaming semantics અને interactive playground API ડોક્યુમેન્ટેશન માં છે.

08ત્રણ W8A16 મોડેલોમાંથી પસંદ કરવું

ત્રણ મોડેલ સૌથી ઊંચી-ફિડેલિટીના ટાયર પર બેસે છે, બધા તળિયાની કિંમતે. પસંદગી મોટાભાગે modality ની છે:

મોડેલ	વિઝન	json_schema	કિંમત ઇન/આઉટ	આના માટે પસંદ કરો
Hy3 · W8A16	ના	હા	$0.50 / $2.00	ફક્ત-ટેક્સ્ટ સ્ટ્રક્ચર્ડ પાઇપલાઇન, ટૂલ ઓર્કેસ્ટ્રેશન, લોંગ-કોન્ટેક્સ્ટ રિટ્રીવલ
MiMo-V2.5-Pro · W8A16	ના	હા	$0.50 / $2.00	MiMo લાઇનની Pro ટ્યુનિંગ જોઈતું હોય એવું ફક્ત-ટેક્સ્ટ કામ
MiMo-V2.5 · W8A16	હા	હા	$0.50 / $2.00	ઇમેજ ધરાવતું કંઈપણ — સ્કેન કરેલા ડોક્યુમેન્ટ, સ્ક્રીનશોટ, ફોટોગ્રાફ

જો તમારા ઇનપુટનો કોઈ ભાગ ઇમેજ હોય તો નિર્ણય તમારા માટે લેવાઈ ગયેલો છે: Hy3 ફક્ત-ટેક્સ્ટ છે — સ્કેન કરેલા PDF, સ્ક્રીનશોટ અને ફોટોગ્રાફ MiMo-V2.5 ને મોકલો. જ્યાં ઇનપુટ ખરેખર ટેક્સ્ટ છે, ત્યાં Hy3 ની એજન્ટિક ટૂલ વપરાશ, લોંગ-કોન્ટેક્સ્ટ recall, અને ઓછો જણાવેલો હેલ્યુસિનેશન ની પ્રોફાઇલ પાઇપલાઇન કામ પર સૌથી સીધી રીતે મેપ થાય છે. ત્રણેયની કિંમત સરખી હોવાથી, થોડાસો સો real રેકોર્ડ પર બેમાંથી બે સામે તમારી સ્કીમા ચલાવો અને parse rate સરખાવો; આ ટેબલ સહિત કોઈપણ ટેબલ કરતાં એ વધુ સારી રીતે નિર્ણય કરશે.

09Hy3 ક્યાં પોતાનું સ્થાન કમાય છે

• ઊંચા-વોલ્યુમની ફિલ્ડ નિષ્કર્ષણ. Contracts, filings, incident રિપોર્ટ, transcripts, ક્લિનિકલ નોંધ, કોર્ટ રેકોર્ડ — જ્યાં પણ ડોક્યુમેન્ટ દીઠ typed ઑબ્જેક્ટ deliverable છે અને વોલ્યુમ retries ને મોંઘા બનાવે છે.
• સ્કેલ પર વર્ગીકરણ અને રાઉટિંગ. Closed enum આઉટપુટ, જ્યાં મોડેલની આખી કિંમત ક્યારેય ઓગણીસમી કેટેગરીની શોધ ન કરવામાં છે.
• સિક્યુરિટી અને threat-intel corpora. Malware write-ups, exploit disclosures અને phishing sample — એ સામગ્રી જે ફિલ્ટર થયેલા મોડેલોને ઇનકારમાં ધકેલે છે, અને જ્યાં category-shaped છિદ્ર હેતુને હરાવે છે.
• ટૂલ-કૉલિંગ એજન્ટ જે અટકવા ન જોઈએ. 8-bit argument ફિડેલિટીનો અર્થ છે કે તમારા functions ને સોંપાયેલ JSON parse થાય છે; mangled ટૂલ કૉલ એ અટકેલો એજન્ટ છે, થોડોક ખરાબ જવાબ નહીં.
• સ્ટ્રક્ચરમાં લોંગ-ડોક્યુમેન્ટ વિશ્લેષણ. આખું filing અંદર, એક કોમ્પેક્ટ ઑબ્જેક્ટ બહાર.
• કન્ટેન્ટ મોડરેશન અને પોલિસી રિસર્ચ. ફિલ્ટર થયેલો મોડેલ વાંચવાની ના પાડે એવી સામગ્રીને label કરવી એ standing trust-and-safety સમસ્યા છે; strict સ્કીમા સાથેનો unfiltered મોડેલ તેને સીધો ઉકેલે છે.

અને ક્યાં નથી કમાતું: ઇમેજ ધરાવતું કંઈપણ (MiMo-V2.5 વાપરો), અને સ્વાયત્ત મલ્ટિ-ફાઇલ સોફ્ટવેર એન્જિનિયરિંગ, જ્યાં Tencent ના પોતાના ટેબલ SWE-bench Verified પર Hy3 ને GLM-5.2 થી પાછળ અને DeepSWE પર ઘણું પાછળ મૂકે છે.

Benchmark આંકડા Tencent-જણાવેલા છે, સ્પર્ધક આંકડા સહિત; લખાણ સમયે સ્વતંત્ર વેરિફિકેશન બાકી હતું. કિંમત આંકડા અમારા પ્રકાશિત $0.50 / $2.00 દરોમાંથી ગણેલા છે. આ પાનાં પરનો કોઈ આંકડો Shannon-run benchmark કે estimate નથી.

10વારંવાર પુછાતા પ્રશ્નો

---

સોર્સ: Tencent Hunyuan મોડેલ કાર્ડ · Hy3 રિપોઝીટરી · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · Hy3 રિલીઝનું VentureBeat કવરેજ. ફાઉન્ડેશન benchmark Tencent-જણાવેલા અને સ્વતંત્ર વેરિફિકેશન બાકી હોવાથી હંગામી છે. Shannon AI નું સંચાલન Shannon Lab LLC, New Mexico, USA દ્વારા થાય છે.