Hugging Face lanza Skill que convierte Transformers a MLX | Keryc
En 2026 la automatización de código ya no es solo autocompletar: los agentes pueden tomar una especificación corta y generar soluciones completas. ¿Genial? Sí. ¿Problemas? También. Hugging Face presentó una Skill y un arnés de pruebas para convertir modelos de transformers a mlx-lm, con la ambición de que un modelo llegue a MLX casi en cuanto aparece en Transformers.
Qué hicieron y por qué
La idea central es sencilla: cuando un modelo aterriza en transformers, debería estar disponible en mlx-lm poco después. Para lograrlo crearon una Skill que guía a un agente para leer la implementación en transformers, escribir la versión en MLX, ejecutar pruebas y generar un PR listo para revisión.
¿Por qué hace falta esto? Porque los agentes son ya capaces de abrir PRs, pero suelen fallar en entender las convenciones implícitas de proyectos grandes. transformers es un repositorio pensado para ser legible por humanos: archivos modelados para leerse de arriba abajo, jerarquías planas, y decisiones de diseño que no siempre están documentadas.
Los agentes, por su parte, no tienen ese contexto. Tienden a refactorizar, generalizar prematuramente, introducir cambios que rompen contratos implícitos y cometer errores sutiles de rendimiento o numerics. El resultado: una avalancha de PRs y los mismos mantenedores para revisarlos.
Cómo funciona la Skill (técnico)
La Skill es un conjunto de instrucciones (una receta para agentes) que automatiza el flujo de portado sin pretender reemplazar al humano. Dado un prompt como "convertir la arquitectura olmo_hybrid a MLX", la Skill:
Crea un entorno virtual y prepara instalaciones editables de mlx-lm y transformers.
Descubre y descarga variantes relevantes desde el Hub usando el hf CLI.
Lee el código de transformers y genera la implementación en MLX.
Ejecuta tests automatizados: comparaciones numéricas, ejemplos de generación, verificaciones de dtype desde cabeceras safetensors, y comparaciones por capa para localizar divergencias.
Atención a detalles que suelen fallar: RoPE mal configurados que degradan en secuencias largas, contaminación a float32 que mata la velocidad de inferencia, campos de config que varían entre variantes y manejo de inferencia distribuida para modelos gigantes.
La Skill no declara éxito hasta que una batería de comprobaciones pasa satisfactoriamente. Además, genera un reporte exhaustivo para el PR: resumen de variantes, diferencias arquitectónicas, ejemplos de generación y logs con datos crudos en JSON.
Para contribuidores y revisores
La Skill está diseñada tanto para quien quiere contribuir como para quien revisa. Para el contribuidor automatiza el trabajo pesado: descubrir checkpoints, diffear configs, inferir dtype, y ejecutar pruebas por capa. Para el revisor produce un PR honesto: declara que fue asistido por agente, sigue las convenciones de mlx-lm (idiomático, sin refactors innecesarios) y adjunta mucha más señal que el PR promedio.
Un par de reglas culturales incluidas en la Skill son clave: no uses comentarios para explicar código en lugar de escribir código claro; no propongas refactors globales; no toques utilidades compartidas sin aprobación. Son pequeñas restricciones que ahorran a los revisores horas de trabajo.
Importante: la Skill no es una puerta a la aceptación automática. El ciclo típico sigue siendo humano-humano: PR, revisión, iteración. Si no estás dispuesto a participar en ese ciclo, no abras el PR solo porque un agente lo hizo por ti.
El arnés de pruebas no agente
Para evitar depender de la palabra del LLM, crearon un arnés de pruebas separado y no agente. Beneficios:
Reduce la incertidumbre por alucinaciones o complacencia de LLMs.
Garantiza reproducibilidad: cualquiera puede clonar el repo del arnés y correr las pruebas.
Ofrece transparencia: reportes, detalles por modelo y dumps de inputs/outputs en JSON están guardados.
Las pruebas no son un gate automático. Muchas comprobaciones son cuantitativas simples (¿es el dtype correcto?), pero otras son cualitativas y requieren criterio humano (¿es aceptable un 4% de diferencia en logits?). El arnés aporta evidencia; la decisión final sigue siendo humana.
Cómo probarlo ahora
Si quieres experimentar con la Skill en tu máquina:
Ejecuta: uv run https://raw.githubusercontent.com/huggingface/transformers-to-mlx/main/install_skill.py
Luego agrega la Skill con: uvx hf skills add --claude
Los desarrolladores usaron Claude Code para probar la Skill; el enfoque funciona con otros agentes de código como Codex, aunque no lo han probado exhaustivamente. Si lo haces con otro agente, te piden feedback.
Limitaciones y caminos a futuro
La Skill ya funciona bien para LLMs en mlx-lm, pero hay áreas abiertas:
mlx-vlm: modelos visión-lenguaje viven en otro repo con convenciones distintas y necesitan processors para preprocesar imágenes.
llama.cpp: el port exige portar procesadores a C++ y aceptar diferencias numéricas inevitables.
Ampliar la batería de pruebas y explorar automatizar su ejecución en la infraestructura de Hugging Face.
Soporte para subir modelos cuantizados: la Skill prueba cuantización pero no hace el upload durante la revisión.
Tests específicos para modelos de "thinking": aún no existen pruebas que validen estructura de razonamiento.
Reflexión final
El cuello de botella en el open source no es escribir código rápido: es entender un codebase y cambiarlo sin romper contratos con sus usuarios. Los agentes pueden acelerar el trabajo si les enseñamos lo que importa. Esta Skill es un ejemplo pragmático: automatiza tareas repetitivas y recoge evidencia para ayudar a revisores, pero respeta que la decisión final debe ser humana.
Si quieres aprender portando en local, la Skill es una excelente herramienta educativa: apunta la Skill a tu fork de mlx-lm, convierte modelos, y compara tu salida con la implementación aceptada cuando llegue al repo oficial. Haciendo esto unas cuantas veces aprenderás mucho sobre transformers, MLX y arquitecturas de lenguaje.
