Tencent Hy4: un modelo de pesos abiertos de 770B y lo que significa para tu empresa

La respuesta directa: el 28 de agosto de 2026 Tencent publicó Hy4 preview como modelo de pesos abiertos bajo la licencia Apache 2.0, con 770 mil millones de parámetros totales, de los que solo 49 mil millones se activan por token, y una ventana de contexto de hasta un millón de tokens. En la práctica, eso significa que cualquier empresa puede descargar el modelo y ejecutarlo en su propia infraestructura sin permiso del proveedor y sin tarifa por llamada. No significa que puedas ejecutarlo en un servidor de tu oficina. La distancia entre esas dos frases decide si esta noticia te afecta o no.

Qué se anunció realmente

Antes de cualquier análisis, conviene separar los hechos publicados de la interpretación. Lo que Tencent publicó en el repositorio oficial del modelo incluye:

  • Tamaño y activación: 770 mil millones de parámetros totales, 49 mil millones activados por token, en una arquitectura de mezcla de expertos.
  • Estructura interna: 78 capas, la primera densa y el resto de mezcla de expertos con 256 expertos enrutados más un experto compartido, con ocho expertos seleccionados por token.
  • Ventana de contexto: un millón de tokens, con un tamaño de vocabulario de 120.832.
  • Licencia: Apache 2.0, una licencia permisiva que permite el uso comercial, la modificación y la redistribución.
  • Variante cuantizada: hay una versión FP8 disponible junto al modelo de precisión completa.
  • Aceleración de inferencia: una capa integrada de predicción de múltiples tokens que admite decodificación especulativa.
  • Enfoque declarado: el modelo se orienta a programación, productividad de oficina, desarrollo de videojuegos e investigación científica, más que al chat general.

Lo que no se anunció, y no debe suponerse, es ninguna promesa de superioridad sobre los modelos cerrados en tu caso concreto. Las comparaciones publicadas en benchmarks públicos no te dicen nada fiable sobre el rendimiento con tus documentos, el idioma de tus clientes y el contexto de tu sector. Esa respuesta solo llega con pruebas internas sobre tus propios datos.

Por qué la licencia Apache 2.0 no es un pequeño detalle legal

La mayor parte de la conversación sobre modelos abiertos se centra en la calidad de las respuestas, mientras que el valor real para el dueño de un negocio está en la cláusula de la licencia. Una licencia permisiva significa tres cosas prácticas: ejecutar el modelo dentro de tu infraestructura no requiere la aprobación de nadie, modificarlo y ajustarlo con tus datos está permitido, y la continuidad de tu servicio no depende de que un proveedor siga ofreciéndolo o mantenga sus precios.

Este último punto es el núcleo del asunto. Una empresa que construyó todo su servicio de atención al cliente sobre una única API carga con un riesgo silencioso: un cambio de precios, una versión retirada o un cambio en la política de uso pueden devolverla a la casilla de salida. Un modelo de pesos abiertos no elimina ese riesgo, pero te da una salida: la copia que descargaste sigue siendo tuya.

Las cuentas de hardware que el titular suele omitir

Aquí es donde el entusiasmo se convierte en números. 770 mil millones de parámetros con precisión FP8 significan aproximadamente un byte por parámetro, es decir, más de 700 gigabytes solo para los pesos del modelo antes de cualquier otra cosa. Añade la memoria de contexto, que crece con la longitud de la conversación, y una ventana de un millón de tokens implica una memoria adicional considerable en uso real; después añade redundancia para que el servicio no se caiga cuando falle un solo nodo.

La conclusión es que este es un modelo de centro de datos, no un modelo para el servidor de la oficina. Autoalojarlo es una decisión que exige hardware especializado y un equipo de operaciones que sepa repartir un modelo entre varias GPU y vigilar la latencia y la utilización. Es un coste fijo que no se reduce cuando baja tu uso, a diferencia de una API, en la que pagas lo que consumes.

La regla práctica: el autoalojamiento solo tiene sentido bajo una de dos condiciones. O tienes un uso grande y estable que hace que el coste fijo sea más barato que el consumo variable, o te enfrentas a un requisito regulatorio o contractual que impide que los datos salgan de un perímetro definido. Fuera de esas dos condiciones, el autoalojamiento suele ser una decisión emocional más que económica.

Qué hace que el diseño sea técnicamente interesante

La cifra llamativa de Hy4 no es 770 mil millones, sino 49 mil millones. Una arquitectura de mezcla de expertos significa que el modelo tiene una capacidad enorme pero activa solo una pequeña parte de sí mismo por token, así que obtienes una calidad de gama alta con un coste de cómputo más cercano al de un modelo mediano. Esta dirección arquitectónica es exactamente la que acercó los modelos abiertos a los cerrados en los últimos dos años.

Súmale un mecanismo de atención dispersa que reutiliza los índices de dispersión entre capas, y una capa integrada de predicción de múltiples tokens que permite la decodificación especulativa para acortar el tiempo de generación. En lenguaje de negocio: estos detalles reducen el coste por token y la latencia, y esos dos factores deciden si una función puede desplegarse a miles de usuarios o se queda en un experimento interno.

Tres caminos prácticos para tu empresa

  • Una API gestionada sobre un modelo cerrado: la vía más rápida para lanzar, sin carga operativa y con un coste variable que crece con el uso. El camino por defecto para los primeros seis meses de cualquier producto.
  • Hy4 a través de un proveedor que lo aloja por ti: obtienes la flexibilidad de la licencia y la posibilidad de cambiar de proveedor sin comprar hardware. Es el punto intermedio práctico que mucha gente pasa por alto.
  • Autoalojamiento completo: máximo control y máximo coste. Justificado cuando te enfrentas a un requisito estricto de residencia de datos o manejas un volumen operativo grande y estable.

Las preguntas que zanjan la decisión

Antes de gastar un solo riyal en este camino, responde con honestidad a cuatro preguntas. ¿Qué tipo de datos pasarán por el modelo, y existe alguna obligación regulatoria o contractual que impida que salgan? ¿Cuál es el volumen mensual esperado dentro de seis meses, no en la primera semana? ¿Tienes tú, o tu socio técnico, una capacidad operativa real las veinticuatro horas? ¿Y has construido en tu aplicación una capa de abstracción que te permita cambiar de modelo sin reescribir el producto?

Si la respuesta a la última pregunta es no, esa es tu prioridad antes de cualquier debate sobre qué modelo usar. La diferencia entre una empresa flexible y una atrapada no está en elegir el modelo correcto, sino en construir un sistema que mantenga la elección modificable más adelante a un coste razonable. Consulta nuestro artículo sobre una región de nube local y la residencia de datos si la residencia es tu motivo principal.

Cómo lo abordamos en Origami

Construimos las aplicaciones de nuestros clientes de modo que el modelo sea un componente reemplazable detrás de una interfaz interna unificada, y mantenemos un conjunto de evaluación con casos reales de clientes que ejecutamos contra cualquier modelo candidato antes de adoptarlo. Eso convierte noticias como el lanzamiento de Hy4 de un titular técnico en una decisión medible: ejecutar el conjunto de evaluación, comparar calidad, coste y latencia, y decidir con números y no con impresiones.

Fuentes