Hy3 es un modelo MoE solo de texto para codificación, razonamiento, trabajo de contexto largo y agentes. Para una primera integración, use un endpoint alojado compatible con OpenAI, envíe una solicitud normal de Chat Completions y evalúe el único flujo de trabajo que realmente automatizaría. No lo estandarice hasta que siga su esquema de herramientas y mantenga las restricciones que importan en sus entradas largas.
Los detalles del proveedor a continuación fueron verificados el 14 de julio de 2026. DeepInfra documenta el modelo como tencent/Hy3 en su endpoint OpenAI-compatible Chat Completions. SiliconFlow también enumera Hy3 bajo el mismo ID de modelo. Los precios, límites y alias del proveedor pueden cambiar, así que confirme la página en vivo del proveedor antes de ponerlo en producción.
Comienza con una llamada a la API alojada de Hy3
DeepInfra publica esta solicitud mínima para su endpoint Hy3 alojado. Reemplace el token con su propio token de proveedor; no lo coloque en el código del navegador ni en una aplicación cliente.
curl "https://api.deepinfra.com/v1/openai/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DEEPINFRA_TOKEN" \
-d '{
"model": "tencent/Hy3",
"messages": [
{"role": "user", "content": "Devuelve tres comprobaciones de aceptación de API."}
]
}'
La respuesta utiliza la estructura estándar de Chat Completions. Analice los campos de respuesta y facturación de esta manera:
{
"id": "chatcmpl-...",
"object": "chat.completion",
"model": "tencent/Hy3",
"choices": [{
"message": {"role": "assistant", "content": "..."},
"finish_reason": "stop"
}],
"usage": {
"prompt_tokens": 0,
"completion_tokens": 0,
"total_tokens": 0
}
}
Lee choices[0].message.content para la respuesta y usage para la contabilización de tokens. Agrega "stream": true solo después de que funcione una solicitud sin streaming; DeepInfra documenta el streaming como eventos enviados por el servidor que terminan con [DONE].
Las opciones de proveedores en la tabla son deliberadamente limitadas. Son rutas de acceso público verificadas, no un ranking de precios.
Proveedor | Detalle de acceso verificado | Qué confirmar antes de producción |
|---|---|---|
| Precio actual, límites de la cuenta, compatibilidad con herramientas y términos de datos | |
API compatible con OpenAI; modelo | Endpoint actual, precio, límites de velocidad y el alcance de la clave API | |
El 14 de julio, su página enumeraba | Si el alias sigue disponible, sus límites y el proveedor enrutado |
El anuncio de lanzamiento de Tencent del 6 de julio de 2026 presentó Hy3 como un modelo Mixture-of-Experts de pesos abiertos. Su anuncio oficial de precios y la tarjeta del modelo lo convierten en un candidato para una evaluación alojada, pero una página de API no es evidencia de que se ajuste a una carga de trabajo de producción.
Qué es Hy3, y qué no es
Hy3 es un modelo MoE de 295B de parámetros con 21B de parámetros activos por token. La tarjeta oficial del modelo Hy3 enumera 192 expertos con enrutamiento top-8, una base de 80 capas, una capa MTP, una ventana de contexto de 256K tokens y una licencia Apache 2.0.
Esos números describen un modelo de texto diseñado para razonamiento, programación, conversaciones prolongadas y agentes que usan herramientas. No convierten a Hy3 en un modelo de imágenes ni de OCR. Un flujo de trabajo cuya entrada principal sea una factura escaneada, una captura de pantalla, una foto de producto o un gráfico necesita un modelo de visión o de OCR antes de necesitar Hy3. Mantener clara esa frontera evita un error de arquitectura común: pedirle a un modelo de texto capaz que recupere información que nunca recibió.
Tencent posiciona Hy3 para codificación, trabajo de oficina, modelado financiero, trabajo de frontend y desarrollo de juegos. Trátalos como cargas de trabajo candidatas, no como una clasificación universal.
Lee las afirmaciones del benchmark con sus limitaciones
El anuncio de lanzamiento de Tencent informa de una evaluación ciega con 270 expertos realizando tareas de trabajo en la que Hy3 obtuvo 2.67 sobre 4 y GLM-5.1 obtuvo 2.51 sobre 4. La misma fuente afirma que la precisión de SWE-Bench Verified de Hy3 varió en menos de cuatro puntos porcentuales entre los esqueletos de CodeBuddy, Cline y KiloCode. Estos son resultados informados por Tencent, no una garantía independiente de que Hy3 supere a un rival nombrado en su entorno.
Artificial Analysis es otro punto de referencia para mediciones a nivel de modelo. Lee los números de benchmark como insumos para la selección de modelos, no como un sustituto de los criterios de aceptación a nivel de aplicación.
Elige el modo de razonamiento según el costo del fallo
Hy3 expone no_think, low y high esfuerzo de razonamiento en sus ejemplos oficiales de servicio. La elección debe seguir el coste de una respuesta incorrecta, no el prestigio de usar un modelo de razonamiento.
Carga de trabajo | Comenzar con | Qué medir antes de escalar |
|---|---|---|
Clasificación, extracción de texto limpio o enrutamiento simple |
| Etiqueta o valores de campo correctos, latencia y tokens de salida |
Cambios de código limitados, resúmenes con múltiples reglas o una secuencia de herramientas |
| Tasa de aprobación de pruebas, argumentos válidos de herramientas y ediciones humanas |
Depuración de varios archivos, planificación con restricciones en conflicto o razonamiento numérico |
| Tasa de tareas completadas, reintentos, tokens totales y tiempo de revisión |
Conserve no-think para trabajo acotado
no_think es el modo de respuesta directa predeterminado. Es la base adecuada cuando la fuente ya está estructurada, la respuesta tiene una forma conocida y una respuesta más lenta no aportaría un razonamiento útil. Por ejemplo, un flujo de trabajo de soporte que elige un estado documentado y llama a una función debería probarse primero en este modo. Añade un esquema JSON estricto y rechaza las respuestas que tengan campos adicionales en lugar de esperar que una cadena de razonamiento más larga repare un contrato impreciso.
Usa razonamiento bajo o alto cuando un error cambia la siguiente acción
Mueve a low cuando el modelo deba reconciliar varias reglas o hacer un cambio acotado al código. Reserva high para trabajos en los que una decisión intermedia débil cause un reintento costoso: diagnosticar un fallo entre archivos, elegir un orden de operaciones o verificar cálculos antes de una llamada a una herramienta.
El equilibrio es medible. Compara la tarea completada en su totalidad: la latencia de la solicitud, el número de tokens de salida, los reintentos de llamadas a herramientas, los fallos de las pruebas y los minutos que un revisor pasa corrigiendo la respuesta. Un modo que parece más reflexivo pero duplica los tokens sin reducir el tiempo de revisión no es la mejor configuración para producción.
Realiza una prueba de API de cuatro partes antes de adoptar Hy3
Esta prueba crea evidencia para su sistema en lugar de un veredicto genérico del modelo. Use tareas reales pero no sensibles. Congele los prompts, los esquemas y los criterios de aprobación antes de ejecutar los modelos para que no cambie las reglas después de leer una respuesta.
Pruebe la ruta de solicitud con una llamada autohospedada mínima
El siguiente ejemplo sigue el patrón oficial de servicio autohospedado compatible con OpenAI de Hy3. Utiliza un endpoint local compatible con vLLM y el nombre de modelo configurado por ese servidor. Los ID de modelo alojados son específicos del proveedor; use la tabla de proveedores anterior para los ID alojados verificados.
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8000/v1",
api_key="EMPTY",
)
response = client.chat.completions.create(
model="hy3",
messages=[
{"role": "user", "content": "Enumera las comprobaciones de aceptación para una llamada de herramienta JSON."}
],
temperature=0.9,
top_p=1.0,
extra_body={
"chat_template_kwargs": {"reasoning_effort": "low"}
},
)
print(response.choices[0].message.content)
Haz que esta llamada trivial funcione antes de evaluar un agente complicado. Separa un problema de autenticación, endpoint, plantilla o nombre de modelo de un problema de calidad del modelo. Registra el proveedor, la revisión del modelo si está disponible, el modo de razonamiento, la marca de tiempo, los tokens de entrada, los tokens de salida y el tiempo transcurrido en cada prueba.
Prueba la salida estructurada y las llamadas a herramientas con tu esquema real
La llamada a herramientas no debe calificarse como "el modelo eligió una acción plausible". Envíe un esquema explícito y valide los argumentos devueltos en su aplicación. Este es un fragmento de solicitud al estilo OpenAI; confirme con el proveedor el soporte exacto de parámetros de herramienta antes de depender de él.
{
"model": "tencent/Hy3",
"messages": [
{"role": "user", "content": "Comprueba el estado del incidente INC-1042."}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_incident",
"description": "Busca un incidente por su identificador.",
"parameters": {
"type": "object",
"properties": {"incident_id": {"type": "string"}},
"required": ["incident_id"],
"additionalProperties": false
}
}
}
]
}
Para esta solicitud, una decisión de herramienta correcta significa una llamada get_incident cuyo incident_id sea exactamente INC-1042. Tu código debe rechazar un campo faltante, una cadena de argumento JSON malformada o una herramienta inesperada antes de que toque el sistema downstream. Inspecciona cinco cosas:
La herramienta seleccionada está permitida para la tarea.
Todos los argumentos requeridos están presentes y tienen el tipo correcto.
Los ID, fechas y cantidades provienen del contexto proporcionado en lugar de ser inventados.
El modelo solicita un valor requerido que falta en lugar de adivinarlo.
Un error de herramienta conduce a una reparación acotada o a una ruta de escalamiento, no a un bucle.
Ejecuta suficientes ejemplos para incluir entradas válidas, solicitudes ambiguas, campos faltantes y una respuesta de herramienta que falle deliberadamente. Un JSON confiable en el caso feliz es útil; un comportamiento confiable cuando el sistema rechaza un argumento es lo que evita que un agente cree trabajo para un operador.
Prueba el contexto largo para la retención de restricciones, no la longitud del encabezado
El contexto de 256K de Hy3 solo es valioso cuando los hechos relevantes sobreviven en el formato de tu prompt. Crea una prueba a partir de un repositorio representativo, un paquete de políticas o un hilo de historial de clientes. Coloca varias restricciones específicas en distintas ubicaciones, añade distractores realistas y pide una respuesta que deba citar o transformar esas restricciones.
Califique la recuperación exacta, el cumplimiento de cada restricción nombrada, las afirmaciones no respaldadas y el costo total de la solicitud. Luego repita con su capa de recuperación de producción habilitada. Esto expone si un fallo corresponde al modelo, al chunking, al ranking de recuperación o al código de ensamblaje del prompt. Pasar un solo documento grande pegado no es evidencia suficiente para desactivar las guardrails.
Prueba la carga de trabajo que justificaría una migración
Elige una tarea en la que un mejor resultado del modelo tenga un valor comercial claro: reparar una prueba fallida en varios archivos, extraer obligaciones de una política larga o completar una operación interna de varios pasos con herramientas. Compara la ruta de producción actual y Hy3 bajo el mismo tiempo límite y la misma regla de revisión.
Registre la tasa de tareas completadas, la latencia p50 y p95, los tokens de entrada y salida, el número de reintentos de herramientas y el tiempo de corrección del revisor. Aquí también es donde la retroalimentación mixta de la comunidad resulta útil. No decida a partir de una afirmación de que Hy3 es excepcional o decepcionante en abstracto. Decida a partir de la tarea que realmente pagaría por automatizar.
¿API alojada o autoalojamiento?
Use primero una API alojada cuando estés evaluando el modelo, el tráfico todavía sea incierto, o tu equipo no disponga ya de la capacidad GPU necesaria. Esto acorta el camino hacia las pruebas anteriores y mantiene la disponibilidad del proveedor separada de la lógica de tu aplicación.
Aloje usted mismo solo cuando tenga una razón concreta de control, privacidad, volumen o latencia, y la infraestructura para respaldarlo. La tarjeta oficial del modelo recomienda ocho GPUs H20-3e u otras GPUs de gran memoria para servir Hy3, con recetas vLLM o SGLang. Esa es la recomendación de Tencent para servicio en producción, no una afirmación de que un portátil de consumo ofrezca una implementación equivalente. Mida el coste de las reservas de GPU, las actualizaciones, la supervisión, el batching y la responsabilidad de guardia frente a la factura del servicio alojado antes de tratar los pesos abiertos como infraestructura gratuita.
Elija este camino | Cuando es la mejor opción | Principal riesgo a tener en cuenta |
|---|---|---|
Hosted API | Evaluación rápida, demanda variable, equipo de plataforma pequeño | Los ID de modelo del proveedor, los límites, la disponibilidad y el precio pueden cambiar |
Self-hosted Hy3 | Fuerte necesidad de control de datos o volumen sostenido con operadores experimentados | Hardware de alta memoria, complejidad de servicio, planificación de capacidad y soporte operativo |
Los precios y la disponibilidad pueden cambiar más rápido que el peso
Tencent publicó los precios de la API Hy3 a 1 RMB por millón de tokens de entrada, 4 RMB por millón de tokens de salida y 0.25 RMB por millón de tokens de entrada en caché el 6 de julio. Úsalo como un punto de referencia fechado y luego confirma el precio real del endpoint antes de lanzar. El nivel gratuito de un proveedor, el crédito introductorio o un alias temporal de modelo gratuito son disponibilidad para un experimento, no una promesa permanente de coste unitario.
Para una comprobación de costo simple, 100 solicitudes diarias que contienen 20K tokens de entrada y 1K tokens de salida usan 2M tokens de entrada y 0.1M tokens de salida. Al precio de referencia publicado por Tencent, eso equivale a 2.4 RMB por día, o aproximadamente 72 RMB por 30 días. Si los 2M tokens de entrada califican para precios en caché, el mismo cálculo es de 0.9 RMB por día. Esta es una estimación basada solo en tokens: excluye el margen del proveedor, los límites del nivel gratuito, los reintentos y cualquier contexto que añada su aplicación.
Al elaborar el presupuesto de una prueba, incluya el contexto recuperado, el prompt del sistema, las definiciones de herramientas, los reintentos y la salida producida por la configuración de razonamiento elegida. No elija Hy3 cuando la entrada clave sea visual, cuando una implementación local ligera sea un requisito estricto, o cuando la aplicación no pueda validar los argumentos de las herramientas y los efectos secundarios posteriores.
Para un agente con mucho texto que necesita una gran ventana de contexto, razonamiento configurable y pesos abiertos, Hy3 es un modelo razonable para evaluar. Consérvelo solo cuando reduzca el tiempo de corrección a un costo total aceptable.
Preguntas frecuentes
¿Hy3 es multimodal?
No. Hy3 es un modelo de entrada de texto y salida de texto. Use un modelo de visión o OCR cuando la tarea comience con imágenes, escaneos o capturas de pantalla.
¿Qué es la ventana de contexto de Hy3?
La ficha del modelo de Tencent indica una ventana de contexto de 256K tokens. Un límite de contexto largo no garantiza que se recuperen o sigan los hechos relevantes, así que valídalo con material fuente representativo.
¿Con qué modo de razonamiento de Hy3 debería empezar?
Empieza con no_think para trabajos acotados y sensibles a la latencia. Pasa a low o high solo cuando el coste del fallo de la tarea y la mejora medida justifiquen los tokens y el tiempo adicionales.
¿Puedo autoalojar Hy3?
Sí. Tencent proporciona orientación de implementación para vLLM y SGLang, y recomienda ocho GPU de gran memoria para el servicio. El autoalojamiento debe seguir una decisión de capacidad y operaciones, no solo la licencia de pesos abiertos.
¿Es una API Hy3 gratuita un plan de precios permanente?
No. El acceso gratuito depende del proveedor y puede terminar o cambiar sus límites. Confirma las condiciones vigentes del proveedor y la tarifa de pago antes de comprometer un flujo de trabajo de producción.