Hy-MT2-1.8B: traducción multilingüe open source que cabe en 440 MB

Por Iván Vázquez Caballero • 27 de mayo de 2026 •9 min lectura

Hy-MT2-1.8B: traducción multilingüe open source que cabe en 440 MB

📌 TL;DR — Tencent ha publicado el 21 de mayo de 2026 la familia Hy-MT2, una serie de modelos de traducción multilingüe open source con tamaños de 1.8B, 7B y 30B parámetros. El modelo más pequeño, Hy-MT2-1.8B, soporta 33 idiomas y con cuantización extrema (AngelSlim a 1.25 bits) se reduce a unos 440 MB, acelerando la inferencia aproximadamente 1.5 veces. Para empresas con necesidades de localización, atención multilingüe o privacidad de datos, esto abre una vía concreta para salir de la dependencia de APIs de traducción comerciales. Los benchmarks son internos, así que hay que validar en el propio dominio antes de migrar nada a producción.

Por qué un modelo de traducción de 440 MB merece atención

La traducción automática lleva años siendo un servicio de pago por uso: mandas texto a una API, recibes la traducción, pagas por carácter. Funciona. Pero tiene tres problemas reales para muchas empresas:

Coste a volumen. Si procesas millones de palabras al mes —catálogos de producto, tickets de soporte, contratos— el gasto en APIs comerciales escala rápido.
Privacidad y regulación. Enviar datos de clientes o documentos confidenciales a un servicio cloud de terceros no siempre es compatible con GDPR o con las políticas internas de ciertos sectores.
Latencia. En aplicaciones donde la traducción está en el camino crítico de la experiencia de usuario —chat en tiempo real, subtítulos, asistentes— el round-trip a una API añade decenas o cientos de milisegundos.

Hy-MT2-1.8B no resuelve estos problemas de forma mágica, pero los hace abordables para equipos que no tienen infraestructura de IA a gran escala.

Qué es Hy-MT2 y qué lo diferencia

Hy-MT2 es una familia de modelos de traducción multilingüe desarrollada por Tencent Hunyuan, publicada como open source en Hugging Face y ModelScope el 21 de mayo de 2026, junto con su paper en arXiv y un nuevo benchmark llamado IFMTBench [1][2][9].

La familia tiene tres tamaños:

1.8B — el modelo que nos ocupa, orientado a despliegue en dispositivos con recursos limitados.
7B — equilibrio entre rendimiento y coste computacional.
30B-A3B — arquitectura MoE (Mixture of Experts), máximo rendimiento.

El concepto central de la familia es el "fast-thinking": modelos diseñados para responder rápido en escenarios de uso real complejos, no solo en benchmarks académicos de traducción limpia [4][9][10]. Esto es relevante porque los benchmarks estándar de traducción (BLEU, COMET) miden calidad sobre textos bien formados, pero en producción te llegan frases incompletas, mezcla de idiomas, terminología específica de dominio y contexto ambiguo.

33 idiomas y seguimiento de instrucciones

Hy-MT2-1.8B soporta traducción entre 33 idiomas y está diseñado para seguir instrucciones de traducción formuladas en múltiples lenguas [4][9][10]. Esto último importa más de lo que parece: no es solo "traduce esto", sino que puedes indicarle tono, registro, terminología preferida o restricciones de estilo dentro del prompt, y el modelo está entrenado para respetarlas.

La técnica que lo hace caber en 440 MB

El dato más llamativo del lanzamiento es la cuantización. Mediante una técnica llamada AngelSlim a 1.25 bits, el modelo de 1.8B parámetros pasa de su tamaño completo a aproximadamente 440 MB, con una aceleración de inferencia de alrededor de 1.5 veces [1][2][3][4][9][10].

Para entender qué significa esto: un modelo en precisión completa (float32) ocupa 4 bytes por parámetro. A 16 bits (half precision), 2 bytes. La cuantización a 1.25 bits lleva eso a menos de 0.2 bytes por parámetro, con la pérdida de calidad que eso implica. El truco está en que para tareas específicas y bien acotadas como la traducción, esa pérdida puede ser aceptable si el modelo está bien entrenado para esa tarea desde el principio.

Existen variantes cuantizadas del Hy-MT2-1.8B en formatos GGUF (1.25 a 2 bits), orientadas a ejecución con llama.cpp u otros runtimes ligeros [1][5][8]. Esto significa que puedes ejecutarlo con Ollama en un portátil, en un servidor sin GPU dedicada, o en hardware de edge industrial.

Qué dicen los benchmarks (y qué no dicen)

Aquí hay que ser preciso porque los números que circulan tienen un origen concreto.

Según los propios autores del paper, los resultados son los siguientes [1][3][4][9][10]:

Los modelos de 7B y 30B superan a modelos abiertos como DeepSeek-V4-Pro y Kimi K2.6 en modo fast-thinking en los benchmarks evaluados.
El modelo de 1.8B supera en conjunto a APIs comerciales de Microsoft y Doubao para traducción.

Estas afirmaciones provienen de benchmarks internos de los autores. Aún falta validación independiente y comparativas de terceros en producción.

Esto no significa que los resultados sean falsos. Significa que hay que leerlos con el mismo criterio que aplicarías a cualquier paper donde la empresa que publica el modelo también diseña y ejecuta las evaluaciones. El benchmark IFMTBench que acompañan al lanzamiento es un paso en la dirección correcta —publicar el benchmark para que otros puedan replicarlo—, pero la validación independiente en dominios específicos todavía no existe.

La conclusión práctica es esta: no migres nada a producción basándote en los benchmarks del paper. Úsalos como señal de que vale la pena evaluar el modelo en tu caso concreto.

Casos de uso reales donde esto tiene sentido

E-commerce con catálogo multilingüe

Una tienda online que vende en varios mercados europeos puede tener decenas de miles de fichas de producto que necesitan traducción continua cuando se actualizan descripciones, precios o especificaciones. Con una API comercial, ese volumen tiene un coste mensual recurrente. Con un modelo self-hosted como Hy-MT2-1.8B ejecutándose en un servidor propio, el coste marginal de traducir más texto es prácticamente cero una vez amortizada la infraestructura.

Soporte multilingüe con privacidad de datos

Una empresa de software B2B que atiende clientes en varios idiomas y maneja datos sensibles de sus clientes (contratos, configuraciones, incidencias) puede necesitar traducción para sus agentes de soporte sin que esos datos salgan de su infraestructura. Un modelo on-premise resuelve eso sin necesidad de acuerdos de procesamiento de datos adicionales con proveedores externos.

Aplicaciones con traducción en tiempo real

En aplicaciones de comunicación, atención al cliente por chat o herramientas de colaboración, la latencia de traducción afecta directamente a la experiencia. Ejecutar el modelo localmente elimina el round-trip de red y permite respuestas en decenas de milisegundos en lugar de cientos.

Flujos de traducción asistida (pre-traducción + post-edición)

En sectores como el legal, el médico o el técnico, la traducción automática rara vez es suficiente por sí sola. Pero como primera pasada que un traductor humano revisa y corrige, puede multiplicar la productividad. Hy-MT2-1.8B puede encajar bien aquí: suficientemente bueno para reducir el trabajo del traductor, suficientemente ligero para ejecutarse en la infraestructura de una agencia de traducción sin coste de API.

Lecciones accionables

Evalúa Hy-MT2-1.8B como alternativa self-hosted antes de renovar contratos con APIs de traducción. Si tu volumen mensual de texto traducido es alto o tienes restricciones de privacidad, el análisis de coste-beneficio puede salir a favor del modelo local incluso considerando el coste de infraestructura.
Usa las variantes GGUF (1.25–2 bits) para prototipar rápido. Con llama.cpp u Ollama puedes tener el modelo funcionando en un portátil en menos de una hora. Eso es suficiente para hacer una primera evaluación de calidad en tu dominio específico sin invertir en infraestructura.
Diseña tus propios benchmarks antes de tomar decisiones de producción. Coge una muestra representativa de tus textos reales —fichas de producto, tickets de soporte, contratos, lo que sea tu caso— y compara la salida de Hy-MT2-1.8B con la de la API que usas actualmente. Los benchmarks del paper no te dicen nada sobre tu dominio concreto.
Considera el modelo como backbone de un flujo de pre-traducción + post-edición humana. En dominios donde la calidad es crítica, no plantees la IA como sustituto del traductor, sino como acelerador. El modelo hace el 80% del trabajo, el humano revisa y corrige. La combinación puede ser más eficiente que cualquiera de las dos opciones por separado.
Monitoriza la evolución de la familia Hy-MT2. Los modelos de 7B y 30B-A3B son más capaces y, según los autores, compiten con los mejores modelos abiertos en traducción. Si el 1.8B no alcanza la calidad que necesitas pero la dirección es correcta, los modelos mayores pueden ser la respuesta cuando tu infraestructura lo permita.

Mi lectura

Hy-MT2-1.8B es un lanzamiento técnicamente sólido en un área donde el open source ha estado históricamente por detrás de las APIs comerciales. La apuesta por la cuantización extrema y los formatos GGUF indica que Tencent está pensando en despliegue real, no solo en benchmarks de laboratorio.

Lo que me parece más interesante no es el modelo en sí, sino la señal que manda: la traducción especializada está dejando de ser un servicio de pago obligatorio. Hace tres años, si necesitabas traducción de calidad en producción, no había alternativa real a DeepL o Google Translate. Hoy tienes opciones open source que, en dominios específicos y con la evaluación correcta, pueden ser competitivas.

El matiz importante es ese "en dominios específicos y con la evaluación correcta". La traducción general de textos variados sigue siendo difícil para modelos pequeños. Pero si tu caso de uso es acotado —un tipo de documento, un par de idiomas, un registro concreto— un modelo de 440 MB entrenado específicamente para traducción puede sorprenderte.

Lo que no haría es asumir que los benchmarks del paper se trasladan directamente a producción. Eso nunca es verdad, con ningún modelo, de ninguna empresa.

Fuentes

¿Estás evaluando si tiene sentido incorporar traducción automática en tu producto o flujo de trabajo? Si llevas un negocio y quieres analizar si una solución self-hosted como esta puede reducir costes o resolver un problema de privacidad, en alfia.es trabajamos exactamente eso. Si eres desarrollador y quieres entender cómo integrar modelos de lenguaje especializados en aplicaciones reales, echa un vistazo a las formaciones disponibles en ivanvazquez.dev/formaciones. Y si tienes una pregunta concreta, escríbeme.