API do modelo Hy3 sen censura

A maioría das discusións de "que modelo debo usar" van do teito: cal escribe o mellor código, resolve as matemáticas máis difíciles, gaña a execución de axente máis longa. As canalizacións estruturadas non funcionan así. Un traballo que extrae campos de cen mil documentos ao día non precisa un modelo brillante unha vez — precisa un que sexa correcto coa mesma forma sempre, e que nunca devolva un parágrafo onde debe ir un obxecto JSON. Esa é a propiedade pola que está aquí Hy3-W8A16.

01Que é Hy3 e de onde vén

Hy3 é un modelo de razoamento e axentes de pesos abertos do equipo Hunyuan de Tencent, publicado por completo o 6 de xullo de 2026 baixo unha licenza permisiva, cos pesos publicados en Hugging Face. Continúa a liñaxe do anterior traballo de Mestura de Expertos Hunyuan-Large de Tencent. Arquitectonicamente é unha MoE dispersa: 295 mil millóns de parámetros totais, dos que arredor de 21 mil millóns se activan por token mediante enrutamento top-8 entre 192 expertos, nun transformer de 80 capas con atención de consulta agrupada, máis unha capa de predición multitoken de 3.8B aparte para a decodificación especulativa. O contexto nativo é de 256K — exactamente os 262,144 tokens que expoñemos, non un truncamento de algo maior nin unha extensión con rope de algo menor.

Esa proporción de dispersión é a cifra importante para quen paga por token: Hy3 leva o coñecemento dun modelo de 295B facendo aproximadamente a aritmética dun de 21B por pasada cara adiante. Tamén é a razón pola que podemos permitirnos servilo a 8 bits en vez de comprimilo máis — unha compilación de 8 bits dun modelo tan disperso segue cabendo e segue correndo rápido no noso propio clúster de GPU.

En que informa Tencent de que é bo

As táboas de avaliación publicadas por Tencent sitúan as forzas de Hy3 de cheo na busca con axentes, a orquestración de ferramentas e a recuperación con contexto longo, e non na programación pura. As súas cifras informadas:

Amosamos as barras febles a propósito. Hy3 queda por detrás de GLM-5.2 en programación na propia comparación de Tencent — 78.0 fronte a 84.2 en SWE-bench Verified, 28.0 fronte a 46.2 en DeepSWE. Se a túa carga de traballo é enxeñaría do software autónoma en varios ficheiros, le primeiro o resto do índice de investigación sobre modelos. Se é ler texto e emitir estrutura, o perfil é case ideal.

A cifra que máis importa para o traballo de canalización é unha de fiabilidade: Tencent informa dunha taxa de alucinación do 5.4% en Hy3, fronte ao 12.5% da xeración anterior, cos erros de sentido común caendo do 25.4% ao 12.7%. O seu principio de adestramento declarado — responder cando hai probas e dicir claramente cando non as hai — é exactamente a disposición que queres nun modelo de extracción que doutro xeito inventaría un valor plausible para un campo que a fonte nunca menciona.

Todas as cifras desta sección están informadas por Tencent a partir das súas propias probas; a verificación independente por terceiros seguía pendente no momento de escribir isto. Trátaas como orientativas, non como definitivas.

02Que significa W8A16 e por que importa para a saída estruturada

Todos os modelos da pasarela levan un sufixo de cuantización. Non é decoración — dicheche canto se afastan os pesos servidos do punto de control que publicou o laboratorio.

Nivel	Que fai	Fidelidade
3BIT-REAP	Pesos de 3 bits máis REAP, un método de poda de expertos que quita os expertos MoE pouco enrutados antes de cuantizar	O máis comprimido
W4A16-AUTOROUND-REAP	Pesos de 4 bits / activacións de 16 bits mediante AutoRound — redondeo aprendido que recupera precisión fronte ao redondeo inxenuo ao máis próximo — máis poda REAP	Intermedio
W8A16	Pesos de 8 bits / activacións de 16 bits. Sen poda, sen reparación por redondeo aprendido — simplemente os pesos levados co dobre de precisión	A máis alta

Onde dana realmente a deriva da cuantización

REAP e AutoRound recuperan a maior parte do que perde a compresión inxenua — pero "a maior parte" está a facer moito traballo nesa frase, e o residuo non cae de xeito uniforme. A cuantización de poucos bits degrada as colas: as decisións de baixa probabilidade e alta especificidade. Na prosa iso é case invisible; outro adxectivo segue sendo unha boa frase. Na saída estruturada é todo o xogo, porque un esquema é unha longa cadea de decisións de baixa probabilidade que teñen que ser exactas cada unha delas:

• Sintaxe a nivel de token. Unha chave de peche, unha coma, unha comiña. Cada unha é un token, e un só token errado invalida a resposta enteira.
• Disciplina de enumeración. O teu esquema di que "status" é un de "open" | "closed" | "pending"; un modelo con deriva devolve "Open" ou "pending review" — semanticamente preto, e válido como ningún dos dous.
• Disciplina de tipos. Un campo number volve como "1,240", un boolean como "yes". Os dous analízanse como cadeas e non cumpren o esquema.
• Literais da cola longa. Nomes propios raros, números de peza, nomes químicos, escritas non latinas, datas precisas — exactamente a rexión de baixa probabilidade que desdebuxan os pesos de poucos bits.

Nada disto fai malos aos modelos de 4 ou 3 bits; para o traballo conversacional a diferenza de fidelidade a miúdo non compensa a diferenza de prezo. Pero cando quen consome a saída é un validador e non unha persoa, a precisión nas colas convértese directamente en taxa de análise correcta — e a taxa de análise en orzamento de reintentos e latencia p99. W8A16 é o nivel no que deixas de pagar ese imposto.

03Saída estruturada: json_schema e response_format

Hy3 admite as dúas metades da superficie de saída estruturada — paga a pena dicilo explicitamente, porque iso non é universal no catálogo:

Modelo	response_format	json_schema
Hy3 · W8A16	Si	Si
MiMo-V2.5-Pro · W8A16	Si	Si
inkling · W4A16-AUTOROUND-REAP	Si	Non
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	Non	Non

A diferenza entre os dous mecanismos importa máis do que a xente supón. response_format: {"type": "json_object"} pide JSON válido e nada máis — o modelo escolle a forma, así que dúas chamadas poden devolver {"name": ...} e {"full_name": ...} e as dúas son correctas. json_schema subministra a forma por adiantado: campos nomeados, tipos, enumeracións, listas de obrigatorios, aniñamento. Iso é un contrato contra o que podes escribir código.

Unha chamada mínima no dialecto compatible con OpenAI:

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

Notas prácticas

• Fai obrigatorio cada campo e permite null. Os campos opcionais convidan a omisións silenciosas; un campo obrigatorio que admite nulo forza un "non presente" explícito, que é información sobre a que podes actuar.
• As enumeracións gañan ás cadeas libres. Onde poidas pechar o conxunto de valores, péchao — é o cambio con máis panca sobre a taxa real de acerto dun esquema.
• Mantente por debaixo do teito de 16,384 tokens de saída. Un array sen límite truncarase a medio obxecto. Limita a lonxitude dos arrays, ou fragmenta a entrada.
• Conserva a mensaxe de sistema. O esquema restrinxe a forma; o prompt segue gobernando a semántica — que conta como "crítico", que data gaña cando aparecen dúas, se hai que normalizar as unidades.
• Valida igualmente. A compatibilidade con esquemas sobe a taxa de acerto; non substitúe un validador e unha cola de mensaxes fallidas.

04Por que "sen censura" é unha propiedade de fiabilidade e non só de contido

Hy3 na pasarela non ten capa de negativas nin filtrado da saída. O enfoque habitual fala de contido: podes procesar investigación en seguridade, análise de malware, informes de exploits, corpus médicos e xurídicos, material adulto, documentación de redución de danos ou transcricións de usuarios hostís sen que o modelo decida por ti que prefire non facelo.

Hai unha segunda razón, máis mecánica, pola que importa. Unha negativa é unha violación do esquema. Un modelo filtrado que rexeita non devolve o teu obxecto cunha marca "unavailable" — devolve prosa. "Non podo axudar con esa petición." Esa cadea non é un obxecto incident; non pasa o teu validador e acaba na cola de mensaxes fallidas ao lado de erros de análise xenuínos, onde agora tes que separar as negativas por política das deformacións reais.

E o que é peor, as negativas correlacionan co contido en vez de repartirse ao azar. Se un 4% do teu corpus son informes de incidentes de seguridade e o modelo rexeita a maioría, non perdiches un 4% de rendemento de forma uniforme — perdiches unha categoría, e o panel construído sobre eses datos infórmase á baixa en silencio precisamente sobre aquilo para o que existe. Os buratos con forma de categoría custan máis ca o ruído uniforme porque nada salta por eles. Quita o camiño das negativas e o que queda — deformacións, truncamentos, texto ambiguo — non correlaciona co tema e, por tanto, é medible.

05Contexto, teito de saída e como orzamentalos

Todos os modelos da pasarela comparten os mesmos límites:

O contexto é un orzamento compartido: o prompt máis a saída teñen que caber xuntos nos 262,144, así que o teito práctico de entrada nunha soa chamada é de arredor de 245,000 tokens, moi aproximadamente 180,000 palabras en inglés. Para o traballo estruturado o límite de 16,384 tokens de saída é o máis duro e o que máis sorprende — un esquema que emite un obxecto por rexistro chega a el moito antes de que se encha a xanela. Dous patróns axudan:

• Entrada ampla, saída estreita. Mete un contrato enteiro, unha presentación ou unha xanela de rexistros no contexto e pide un só obxecto compacto. Os tokens de entrada custan a cuarta parte dos de saída, así que o prezo premia ler moito e escribir pouco.
• Fragmenta polos límites dos rexistros, non por reconto de bytes. Divide onde o modelo poida ver a xuntura. Un rexistro cortado a media frase produce un obxecto seguro de si mesmo e errado, en vez dun fallo evidente.

A forza informada de Hy3 na recuperación con contexto longo — 73.4 en AA-LCR, e un salto do 42.9% ao 75.1% na recuperación de diálogos longos de MRCR — é exactamente a capacidade da que depende o primeiro patrón, e é unha destreza distinta de escribir ben.

06Prezo chan e a aritmética dunha canalización real

Hy3 está a $0.50 por millón de tokens de entrada e $2.00 por millón de tokens de saída — o chan do catálogo, compartido con MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 e MiniMax-M3. Calculado sobre cargas representativas:

Carga de traballo	Entrada / chamada	Saída / chamada	Custo / chamada	Por 1M de chamadas
Extracción de campos	1,200	300	$0.0012	$1,200
Clasificación de documentos	3,000	120	$0.0018	$1,800
Resumo de documento longo a esquema	40,000	900	$0.0218	$21,800
Análise da xanela completa	240,000	2,000	$0.1240	$124,000

A cifra que cambia as decisións non é a tarifa de titular, senón a tarifa efectiva despois dos reintentos. Se dous modelos custan o mesmo e un falla a validación no 6% das chamadas onde o outro falla no 1.5%, o modelo con máis deriva executa arredor dun 4.5% máis de chamadas — asumible. O dano está na cola: as chamadas reintentadas tardan o dobre, así que a latencia p99 case se duplica nunha porción visible do tráfico, e o que falla dúas veces convértese en traballo manual. Cun millón de chamadas ao día iso son milleiros de rexistros que alguén ten que ler.

De aí o argumento a favor do nivel de 8 bits ao prezo chan: aquí non estás a pagar un sobreprezo pola fidelidade, así que a aritmética dos reintentos é diñeiro de balde. Se un modelo de 3 bits fose máis barato habería un intercambio real que sopesar — Hy3 custa o mesmo ca o máis barato do catálogo.

07Tres dialectos de API, un modelo

Hy3 é accesible nos tres dialectos da pasarela con streaming en cada un. Mesmo modelo, mesmos pesos, mesmos límites — colle o que encaixe co SDK que xa tes.

Endpoint	Dialecto	Úsao cando
/v1/chat/completions	OpenAI	Tes un SDK de OpenAI, LangChain ou LlamaIndex. Apunta a URL base aquí e cambia o identificador do modelo.
/v1/messages	Anthropic	Estás no SDK de Anthropic e queres bloques de contido sen capa de tradución.
/v1/responses	Responses	Queres a forma de petición máis nova con saída tipada e estado no servidor.

Hy3 tamén admite chamada de ferramentas e razoamento, incluído reasoning_effort. Para o traballo de extracción o movemento útil adoita ser baixar o razoamento: cun esquema ben especificado sobre texto limpo, os tokens de pensamento son tokens de saída que pagas e latencia que agardas, a cambio dunha ganancia marxinal. Gasta o orzamento de esforzo nas entradas xenuinamente ambiguas.

A referencia completa de peticións e respostas, as listas de parámetros, a semántica de streaming e un playground interactivo están na documentación da API.

08Como escoller entre os tres modelos W8A16

Tres modelos están no nivel de maior fidelidade, todos ao prezo chan. A elección é sobre todo de modalidade:

Modelo	Visión	json_schema	Prezo entrada / saída	Escóllelo para
Hy3 · W8A16	Non	Si	$0.50 / $2.00	Canalizacións estruturadas só de texto, orquestración de ferramentas, recuperación con contexto longo
MiMo-V2.5-Pro · W8A16	Non	Si	$0.50 / $2.00	Traballo só de texto no que queiras o axuste Pro da liña MiMo
MiMo-V2.5 · W8A16	Si	Si	$0.50 / $2.00	Calquera cousa con imaxes — documentos escaneados, capturas de pantalla, fotos

Se calquera parte da túa entrada é unha imaxe a decisión está tomada por ti: Hy3 é só de texto — manda os PDF escaneados, as capturas de pantalla e as fotografías a MiMo-V2.5. Onde a entrada sexa xenuinamente texto, o perfil de Hy3 en uso de ferramentas con axentes, recuperación con contexto longo e baixa alucinación informada é o que mellor se axusta ao traballo de canalización. Como os tres custan o mesmo, executa o teu esquema contra dous deles sobre uns centos de rexistros reais e compara as taxas de análise correcta; iso resólveo mellor ca calquera táboa, esta incluída.

09Onde Hy3 gaña o seu sitio

• Extracción de campos de alto volume. Contratos, presentacións, informes de incidentes, transcricións, notas clínicas, expedientes xudiciais — onde o entregable sexa un obxecto tipado por documento e o volume faga caros os reintentos.
• Clasificación e enrutamento a escala. Saídas con enumeracións pechadas, onde todo o valor do modelo é non inventar nunca unha décimo novena categoría.
• Corpus de seguridade e intelixencia de ameazas. Informes de malware, revelacións de exploits e mostras de phishing — o material que fai que os modelos filtrados caian en negativas, e onde un burato con forma de categoría botaría por terra o propósito.
• Axentes con chamada de ferramentas que non se poden atrancar. A fidelidade de 8 bits nos argumentos significa que o JSON que se lles pasa ás túas funcións se analiza; unha chamada de ferramenta estropeada é un axente atrancado, non unha resposta lixeiramente peor.
• Análise de documentos longos convertida en estrutura. Entra a presentación enteira, sae un obxecto compacto.
• Moderación de contido e investigación en políticas. Etiquetar material que un modelo filtrado se nega a ler é un problema permanente de confianza e seguridade; un modelo sen filtrar cun esquema estrito resólveo directamente.

E onde non: calquera cousa con imaxes (usa MiMo-V2.5) e a enxeñaría do software autónoma en varios ficheiros, onde as propias táboas de Tencent poñen a Hy3 por detrás de GLM-5.2 en SWE-bench Verified e bastante por detrás en DeepSWE.

As cifras de benchmark están informadas por Tencent, incluídas as dos competidores; a verificación independente estaba pendente no momento de escribir isto. As cifras de custo calcúlanse coas nosas tarifas publicadas de $0.50 / $2.00. Ningunha cifra desta páxina é un benchmark executado por Shannon nin unha estimación.

10Preguntas frecuentes

---

Fontes: fichas de modelo de Tencent Hunyuan · repositorio de Hy3 · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · cobertura de VentureBeat do lanzamento de Hy3. Os benchmarks da base están informados por Tencent e son provisionais á espera de verificación independente. Shannon AI está operado por Shannon Lab LLC, Novo México, EUA.