Tres millones de modelos en Hugging Face hacen de la popularidad un mal criterio de selección
Hugging Face ha superado los tres millones de modelos, pero los likes y las descargas revelan atención, no adecuación de licencia, procedencia, coste de hardware o calidad para la tarea.
Hugging Face ya tiene suficientes repositorios públicos de modelos para que elegir primero por popularidad sea un mal valor predeterminado. Su informe del ecosistema del 14 de agosto registró un crecimiento de 2,43 millones a 2,96 millones de repositorios, con un 85,6 % por debajo de 200 descargas de por vida y un 1,5 % que concentra el 99,2 % de las descargas. Un profesional no necesita una clasificación de popularidad mejor dentro de esa distribución. Necesita una forma de eliminar los modelos incompatibles antes de dedicar tiempo a evaluarlos.
Cuatro restricciones acotan la elección antes de que las puntuaciones de benchmark resulten útiles: adecuación a la tarea, permiso de uso, un artefacto ejecutable y una revisión reproducible. Un repositorio puede ser popular y aun así fallar en cualquiera de ellas.
Ese orden importa a medida que los despliegues de pesos abiertos se extienden más allá de los laboratorios de modelos. TechCrunch informó en julio de que el CEO de Hugging Face, Clément Delangue, describió un ecosistema cercano a los tres millones de modelos en el que las empresas usan varios modelos personalizados en vez de esperar a un único ganador universal de frontera. Más opciones pueden reducir la dependencia de un proveedor. También trasladan al adoptante más trabajo de selección, licencias, evaluación y mantenimiento.
La atención y la adopción responden a preguntas distintas
Hugging Face comparó los 25 repositorios de modelos con más descargas en 2026 con los 25 que tenían más likes y encontró un único solapamiento. Su informe interpreta los likes como atención en torno a un lanzamiento y las descargas como evidencia de que un artefacto se incorpora a flujos de trabajo basados en Hub. La propia nota metodológica del informe es más estricta: ninguna de las dos medidas establece directamente la calidad, la adopción comercial o la cuota de mercado.
El contador de descargas no es un contador de usuarios. Aumenta cuando Hub sirve archivos que cumplen los requisitos mediante solicitudes GET o HEAD. Los archivos que cuentan dependen de la biblioteca del modelo, y un clon completo de un repositorio GGUF puede contar más de una vez porque cada archivo GGUF es autocontenido. Las compilaciones automatizadas, los fallos de caché, las máquinas repetidas y los experimentos de una sola persona pueden producir descargas reales sin representar usuarios distintos ni despliegues de producción exitosos.
| Señal de Hub | Lo que puede indicar | Papel útil en la selección | Lo que no establece |
|---|---|---|---|
| Número de repositorios | La oferta se está ampliando | Explica por qué es necesario filtrar | Calidad, singularidad o estado de mantenimiento |
| Likes | La gente decidió expresar interés | Señal de descubrimiento y atención actual | Adecuación a la carga de trabajo o uso operativo |
| Descargas | Se solicitaron archivos que cumplen los requisitos a Hub | Evidencia aproximada de uso basado en Hub | Usuarios únicos, tareas aceptadas, seguridad o uso fuera de Hub |
| Modelos derivados | Otros repositorios declaran que se construyen sobre una base | Señal del ecosistema y las herramientas | Linaje correcto o calidad de un derivado concreto |
| Evaluaciones de la model card | Un editor o colaborador comunicó un resultado | Motivo para inspeccionar un candidato y su configuración de prueba | Rendimiento con tus entradas, tiempo de ejecución o regla de aceptación |
La popularidad sigue siendo útil. Puede sacar a la superficie candidatos, debates activos, conversiones y ejemplos. No debe permitir que se omita una restricción estricta.
Cuatro restricciones independientes acotan el catálogo
Una búsqueda de modelos produce una lista corta, no una decisión de despliegue. Un requisito estricto ausente o no resuelto puede hacer irrelevante el rendimiento posterior.
| Puerta | Evidencia que se debe registrar | Condición de aprobación | Motivo típico de rechazo |
|---|---|---|---|
| Tarea y salida | Etiqueta de pipeline, uso previsto, modalidades de entrada, forma de salida y necesidad de contexto | El artefacto admite el trabajo real y el contrato de integración | Un modelo solo de texto aparece en una lista multimodal, o se da por supuesta una salida estructurada sin probarla |
| Permiso y procedencia | Editor, model card, texto de licencia, modelo base, declaración sobre datos de entrenamiento y condiciones de acceso | El responsable del uso ha revisado las condiciones actuales y las lagunas de procedencia | Condiciones ausentes o incompatibles, modelo base poco claro o afirmación sin respaldo de que lo público significa sin restricciones |
| Tiempo de ejecución y hardware | Formato de pesos, número de parámetros o tamaño de archivo, cuantización, backend, acelerador y presupuesto de memoria | Un artefacto compatible tiene una ruta plausible en la pila objetivo con espacio para caché y estado de ejecución | Un ganador del benchmark no tiene un artefacto compatible o sus pesos consumen todo el presupuesto de memoria |
| Revisión y seguridad del artefacto | Hash completo del commit, lista de archivos, estado de seguridad y necesidad de ejecutar código | Los archivos revisados pueden recuperarse en una revisión inmutable sin código remoto no aprobado | La selección apunta a main, que es mutable; el escaneo está pendiente; o el cargador requiere código que el equipo no ha revisado |
Estas restricciones son independientes. Una licencia permisiva no hace preciso a un modelo. Un benchmark sólido no hace que su artefacto quepa en memoria. Una insignia de seguridad limpia no demuestra que el comportamiento del modelo sea seguro. Un repositorio popular puede fallar en las cuatro.
Una model card es un documento de entrada, no una verificación independiente
Hub muestra el README.md de un repositorio como su model card. Los metadatos de la model card pueden identificar la tarea, biblioteca, licencia, conjuntos de datos, modelo base, relación de versiones y resultados de evaluación. Esos campos hacen posible el filtrado y la revisión, pero los proporciona el editor o un colaborador del repositorio. La falta de detalle es evidencia de una pregunta no resuelta; el detalle presente es una afirmación que se debe contrastar con el artefacto enlazado, el artículo, las condiciones y la configuración de evaluación.
La palabra open necesita la misma precisión. Las preguntas frecuentes sobre código abierto de Hugging Face distinguen el material accesible públicamente del material cuya licencia concede derechos para usarlo, modificarlo o redistribuirlo. «Open weights» indica que los pesos están disponibles bajo ciertas condiciones. No dice cuáles son esas condiciones. Registra los términos reales del modelo, sigue la instrucción de Hub de buscar y respetar la licencia del repositorio y haz que el responsable los evalúe para el uso previsto; una etiqueta de licencia de Hub no es asesoramiento jurídico individualizado.
La procedencia también incluye la ruta de conversión. Un repositorio GGUF o MLX cuantizado puede estar mantenido por alguien distinto del editor del modelo base. La relación base_model de la model card puede conectar ambos, pero una comparación defendible aún tiene que identificar los dos repositorios, las dos revisiones, el método de conversión si se ha comunicado y cualquier evaluación del artefacto convertido.
Fija lo que se revisó
De forma predeterminada, los clientes de Hub recuperan el contenido más reciente de main. La API de descarga acepta un hash completo de commit como su revision, lo que convierte «hemos probado este modelo» en una afirmación reproducible sobre archivos concretos.
Una revisión fijada no congela el entorno que la rodea. Registra junto a ella el tiempo de ejecución, la biblioteca, el controlador, la cuantización, la plantilla de chat y la configuración. Cuando un editor publica una revisión nueva, pruébala como un candidato nuevo; no sustituyas silenciosamente en producción el artefacto revisado.
El estado de seguridad es otra entrada, no una garantía. Hugging Face dice que su escáner usa ClamAV y analiza las importaciones de los archivos pickle, mientras que su documentación sobre pickle advierte que el proceso no es infalible. Un commit firmado establece el origen, no la inocuidad. Prefiere formatos de pesos más seguros como safetensors cuando el modelo y el tiempo de ejecución los admitan, evita el código remoto no revisado y aísla la carga inicial de las credenciales y los datos de producción.
La carga de trabajo importa más que el titular de la clasificación
Una vez que las puertas reducen el campo a entre dos y cuatro modelos, ejecuta cada candidato con los mismos fixtures, revisión del harness, ajustes de ejecución, límite de salida y reglas de aceptación. Un conjunto útil de fixtures representa casos normales, fallos de alto coste, entradas largas, entradas mal formadas y casos en los que la respuesta correcta sea abstenerse o pedir más información.
Mide el trabajo completado, no un único proxy atractivo. Para un resumidor estructurado, eso podría significar salidas válidas según el esquema, fragmentos de evidencia obligatorios, recuento de fabricaciones críticas, latencia de extremo a extremo, memoria máxima y tiempo de corrección del revisor. Para embeddings, podría significar recall en un conjunto de recuperación congelado, latencia, coste de almacenamiento de vectores y fallos en consultas fuera de dominio; nuestro explicador de vectores y embeddings (español) muestra por qué una métrica de distancia útil depende de la relación que la aplicación necesita preservar.
Los resultados de evaluación de Hub pueden ayudar a elegir candidatos, pero su procedencia importa. El sistema de resultados de evaluación puede contener envíos de editores o de la comunidad, enlaces a fuentes, revisiones de conjuntos de datos e insignias de resultados verificados. Comprueba la tarea, la partición, la fecha, el framework, la revisión del modelo, los prompts, las herramientas y la configuración de salida antes de considerar comparables dos números. Después usa el resultado para diseñar tu prueba, no para saltártela. La guía más amplia de evaluación de IA explica cómo cambiar la métrica puede cambiar la decisión sobre el producto.
Las estimaciones de hardware necesitan el mismo límite. El panel de compatibilidad de hardware de Hub estima si las cuantizaciones GGUF y MLX caben en el hardware guardado en el perfil del usuario. Es un filtro previo práctico. La memoria máxima real sigue dependiendo del artefacto elegido, el contexto, la caché, el tamaño de lote, la concurrencia, el backend y otras asignaciones de ejecución. Nuestro análisis del despliegue de Qwen3.8-27B examina esos costes de memoria ocultos, mientras que el análisis del lanzamiento de llama.cpp (español) explica por qué el nombre de un canal no determina el comportamiento en tiempo de ejecución.
Después de las mediciones, elige el candidato menos costoso que supere todas las puertas estrictas y reglas de aceptación. Un modelo más grande puede justificar su coste cuando reduzca materialmente los fallos de alto impacto. Si dos candidatos superan el mismo umbral, un menor uso de memoria, un soporte de ejecución más sencillo, una procedencia más clara y un mantenimiento activo son desempates defendibles. Los likes y las descargas pueden desempatar más adelante; no deben revertir una prueba fallida.
La selección de modelos termina con una fecha de revisión
Una revisión inmutable hace reproducible un resultado, no lo mantiene actualizado para siempre. Las licencias, model cards, relaciones con el modelo base, conversiones, tiempos de ejecución, hallazgos de seguridad y modelos alternativos siguen cambiando. Mantén fijado el artefacto elegido, conserva los candidatos rechazados y los motivos, vigila el repositorio upstream y establece un desencadenante de revisión para una revisión nueva material, un aviso de seguridad, un cambio de licencia, un cambio de carga de trabajo o un fallo de producción repetido.
El hito de los tres millones de modelos es, por tanto, menos una celebración de la elección que una advertencia sobre la calidad de las decisiones. La popularidad en Hub puede indicar a un equipo dónde mirar. El permiso, la procedencia, la compatibilidad y la evidencia de la carga de trabajo—no un contador social—determinan si alguno de esos modelos pertenece a un sistema real.
Fuentes
- Hugging Face State of Open Models: Summer 2026
- TechCrunch report on the expanding open-model ecosystem
- Hugging Face model download statistics documentation
- Hugging Face model card documentation
- Hugging Face Hub download and revision documentation
- Hugging Face Hub license documentation
- Hugging Face pickle scanning documentation
- Hugging Face hardware compatibility documentation
- Hugging Face evaluation results documentation
- Hugging Face open-source FAQ