Maya Bennett
Hugging Face ha lanzado actualizaciones importantes para su proyecto Kernels, introduciendo un tipo de repositorio dedicado, medidas de seguridad mejoradas, interfaces de línea de comandos rediseñadas, soporte ampliado para frameworks y las bases para el desarrollo de kernels impulsado por agentes.
Los Kernels se convierten en un tipo de repositorio de primera clase
El Hub de Hugging Face ahora incluye un nuevo tipo de repositorio llamado "kernel". Este cambio permite a los usuarios ver directamente los aceleradores, sistemas operativos y versiones de backend compatibles. Por ejemplo, los detalles de compatibilidad de un kernel ahora se muestran de manera destacada:
Todos los kernels disponibles se pueden explorar en https://huggingface.co/kernels. Convertir los kernels en ciudadanos de primera clase en el Hub mejora su visibilidad y ayuda al ecosistema de IA a identificar tendencias entre kernels, modelos y aplicaciones.
La seguridad recibe un gran impulso
Los kernels ejecutan código nativo con los mismos privilegios que el proceso de Python que los carga, lo que hace que la seguridad sea una prioridad máxima. El proyecto siempre ha enfatizado la reproducibilidad: los usuarios pueden recompilar un kernel y verificar que coincida con el código fuente público usando Nix para compilaciones herméticas y entornos aislados. El SHA1 de Git del código fuente está incrustado en el kernel para mejorar la procedencia.
Las incorporaciones recientes incluyen editores de kernels de confianza y firma de código.
Editores de kernels de confianza
Con el nuevo tipo de repositorio, Hugging Face introdujo "editores de confianza". Por defecto, el paquete de kernels solo carga kernels de organizaciones en las que la comunidad confía. Los usuarios pueden optar por cargar kernels de otras fuentes usando el argumento trust_remote_code:
from kernels import get_kernel
kernel_module = get_kernel(
"Atlas-Inference/gdn", version=1, trust_remote_code=True
)
La publicación de repositorios de kernels está restringida por defecto. Los usuarios y organizaciones deben solicitar acceso desde la configuración de su cuenta, lo que permite al equipo revisar cada solicitud individualmente.
Firma de kernels
La firma de código protege contra credenciales comprometidas del Hub. Un kernel se firma con una clave privada conocida solo por el desarrollador y se valida con una clave pública. Incluso si un atacante compromete las credenciales de un editor de confianza, no puede firmar un kernel malicioso sin la clave privada.
El proyecto utiliza cosign de Sigstore para firmar con claves privadas efímeras que son válidas por un tiempo limitado. También verifica que el kernel fue firmado por un flujo de trabajo de GitHub de confianza desde un repositorio confiable. La firma de kernels ya es compatible con kernel-builder, y el comando kernels verify-signature está disponible. La verificación de firma al cargar aún no se aplica, a la espera de más pruebas. Las notas preliminares de configuración están en las notas de la versión 0.16.0 de kernels: https://github.com/huggingface/kernels/releases/tag/v0.16.0.
CLIs renovadas
Las utilidades que antes estaban mezcladas entre kernels y kernel-builder se han separado. La biblioteca kernels ahora se centra únicamente en cargar y preparar kernels, mientras que kernel-builder se encarga de compilarlos. Esto hace que ambas herramientas sean más ligeras y enfocadas.
La CLI mejorada también sienta las bases para el desarrollo de kernels con agentes.
Soporte más amplio para frameworks y backends
Se ha ampliado el soporte para frameworks. Los cambios clave incluyen:
Soporte para la ABI estable de Torch, lo que permite a los desarrolladores de kernels apuntar a una versión específica de Torch o cualquier versión posterior durante unos dos años. Por ejemplo, un kernel que apunta a Torch 2.9 Stable ABI es compatible con Torch >= 2.9.
Ahora se admite Apache TVM FFI junto con Torch. TVM FFI es una ABI estandarizada que funciona con PyTorch, Jax, CuPy y otros, lo que permite que los kernels se ejecuten en múltiples frameworks.
Base para el desarrollo de kernels con agentes
kernel-builder y kernels admiten el desarrollo de kernels con agentes, donde un agente crea un kernel optimizado desde cero. Juntos, habilitan un flujo de trabajo para que los agentes creen, compilen, evalúen y optimicen kernels de forma iterativa.
El desarrollo de kernels con agentes aún es nuevo, por lo que unos fundamentos simples y claros son importantes. kernel-builder impone una estructura reproducible para crear y compilar kernels, dando a los agentes un diseño de proyecto predecible. Su CLI está optimizada para agentes con comandos no interactivos y salidas fáciles de interpretar mediante programación. Las habilidades específicas de cada backend ayudan a los agentes a navegar por las idiosincrasias de los diferentes backends.
Compilar un kernel con éxito es solo el primer paso: debe ofrecer aceleraciones reales sobre una línea base en el hardware objetivo. La integración con HF Jobs facilita la evaluación comparativa, permitiendo a los agentes ejecutar conjuntos de pruebas, recopilar resultados de rendimiento y compararlos con una línea base en diferentes configuraciones de hardware.
A continuación se muestran algunos ejemplos de kernels aumentados con agentes que ilustran los tipos de kernels que se pueden desarrollar y evaluar a través de este flujo de trabajo.
Actualizaciones varias
Configuración del entorno
Ahora un script de instalación proporciona una configuración con un solo clic para compilar kernels con kernel-builder. Para instancias efímeras, hay disponible una guía de configuración de Terraform.
Tarjeta de sistema para kernels
Después de compilar kernels, se crea una tarjeta de sistema para cada kernel, que expone información útil, incluido cómo usarlo y sus interfaces. Cuando se sube al Hub, esta tarjeta se convierte en la portada del kernel:
Comprobaciones de compatibilidad de kernels
Use el método has_kernel() para verificar si un kernel es compatible en su sistema:
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
Devuelve un booleano. Para obtener más detalles sobre por qué un kernel no es compatible, use get_kernel_variants():
from kernels import get_kernel_variants, VariantAccepted
for decision in get_kernel_variants("kernels-community/activation", version=1):
name = decision.variant.variant_str
if isinstance(decision, VariantAccepted):
print(f"{name}: compatible")
else:
print(f"{name}: rejected ({decision.reason})")
Debería imprimir (dependiendo de su máquina):
torch212-cxx11-cu130-aarch64-linux: compatible
torch210-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch211-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch212-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch211-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch210-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch29-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
…
Mejora del soporte para manylinux_2_28
Kernel-builder ha apuntado a manylinux_2_28 casi desde el principio. Anteriormente, usaba un conjunto de herramientas gcc moderno compilado con glibc 2.28 y libstdc++ enlazada estáticamente. Sin embargo, esto causaba problemas cuando estaban involucradas múltiples versiones de libstdc++ —como la que PyTorch enlaza dinámicamente y la que un kernel enlaza estáticamente. Algunos kernels que usaban funcionalidades como expresiones regulares de C++ desencadenaban inicializaciones globales, lo que provocaba corrupción de datos y segfaults.
Para solucionarlo, el equipo ha actualizado el enfoque para evitar tales conflictos, garantizando una mayor estabilidad.
Estas actualizaciones posicionan al proyecto Kernels para una adopción más amplia y casos de uso más avanzados, incluidos flujos de trabajo de optimización impulsados por agentes. Con una seguridad mejorada, una mayor visibilidad y soporte entre frameworks, Hugging Face está sentando las bases para un ecosistema de kernels más robusto y flexible.
