Hugging Face acaba de publicar una renovación importante de Kernels que afecta desde la forma en que se publican en el Hub hasta cómo se construyen, firman y optimizan con agentes. ¿Te interesa saber qué cambia para desarrolladores, usuarios con aceleradores y para quienes quieren automatizar optimizaciones con agentes? Aquí te lo explico paso a paso.
Kernels como nuevo tipo de repositorio
Ahora hay un nuevo tipo de repositorio en el Hub llamado kernel. ¿Por qué importa? Porque Kernels son primero-class citizens: puedes ver qué aceleradores, sistemas operativos y versiones de backend soporta cada kernel, lo que hace mucho más sencillo decidir si un kernel va a funcionar en tu hardware.
Los kernels se vuelven más descubribles y también permiten analizar tendencias entre kernels, modelos y aplicaciones.
Seguridad y reproducibilidad: Nix, firmas y publicadores confiables
Los kernels corren código nativo con los mismos privilegios del proceso Python que los carga. Eso significa que la seguridad no es opcional. Hugging Face reforzó varias capas:
Reproducibilidad con Nix: construcciones herméticas y recetas puras que permiten recompilar un kernel y verificar que coincide con el código público.
Proveeduría (provenance): el SHA1 del commit se embebe en el kernel para trazar su origen.
Publicadores confiables (trusted publishers): solo se cargan kernels de publicadores confiables por defecto. Si quieres cargar un kernel de un repositorio no verificado, debes optar explícitamente con trust_remote_code=True.
Publicar un repositorio como kernel no está abierto por defecto: hay que solicitar el acceso desde la configuración de cuenta. Esto permite revisar casos con cuidado.
Firmado de código con Sigstore
Para protegerse contra compromisos del Hub, se añadió code signing. En resumen:
Un kernel se firma con una clave privada que solo conoce el desarrollador.
La verificación usa la clave pública disponible, así un atacante que suba un kernel malicioso no podrá firmarlo.
Se usa Sigstore cosign con claves efímeras para reducir el riesgo cuando una clave se filtra.
Además, se verifica que la firma provenga de un workflow de GitHub confiable.
La utilidad kernel-builder ya soporta signing, y existe kernels verify-signature para comprobar firmas. Por ahora, la carga automática no verifica firmas en tiempo de carga hasta que se termine de probar el flujo.
Antes, muchas utilidades estaban mezcladas entre kernels y kernel-builder. Ahora hay una separación clara:
kernels: biblioteca para cargar y preparar kernels en tiempo de ejecución.
kernel-builder: CLI y herramientas enfocadas en construir kernels y en forzar una estructura reproducible.
Esto hace que cada herramienta sea más ligera y específica, y más fácil de integrar en flujos automatizados o agentes.
Más frameworks y backends: Torch Stable ABI y TVM FFI
Se amplió la cobertura de frameworks y backends:
Soporte para la Torch Stable ABI: permite que un kernel que apunta a una versión estable de Torch (por ejemplo Torch 2.9 Stable ABI) funcione con Torch >= 2.9 durante aproximadamente dos años.
Apache TVM FFI: se añade como el primer framework distinto de Torch. TVM FFI es una ABI que facilita interoperar con PyTorch, Jax, CuPy y otros, permitiendo kernels más portables entre frameworks.
Base para desarrollo agentico de kernels
Hugging Face está construyendo herramientas pensando en workflows donde un agente genera, construye, mide y optimiza kernels de forma iterativa.
kernel-builder impone una estructura de proyecto reproducible que los agentes pueden esperar y aprovechar.
Las CLIs son pensadas para ser agent-friendly: comandos no interactivos y salidas fáciles de parsear.
Hay habilidades (skills) específicas por backend que capturan toolchains, rutas de compilación y consideraciones de rendimiento.
El objetivo es que un agente pueda:
Scaffoldear un kernel.
Ejecutar build reproducible.
Lanzar benchmarks (integración con HF Jobs).
Analizar resultados y reoptimizar.
La integración con HF Jobs facilita ejecutar suites de benchmark en distintos hardware y comparar contra una línea base.
Ejemplos prácticos y utilidades
¿Quieres saber si un kernel es compatible antes de intentar cargarlo? Usa has_kernel():
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
# Devuelve True o False
Si necesitas entender por qué un kernel fue rechazado, get_kernel_variants() te da decisiones detalladas:
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})")
Salida de ejemplo (depende de tu máquina):
torch212-cxx11-cu130-aarch64-linux: compatible
torch210-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))
Compatibilidad binaria y manylinux
Un detalle técnico que causó dolores fue la decisión previa de linkar libstdc++ estáticamente para cumplir manylinux y evitar incompatibilidades. Resultado: problemas por inicializaciones globales cuando conviven varias versiones de libstdc++ (por ejemplo, la de PyTorch y la del kernel), lo que puede causar corrupción de datos y segfaults.
Solución adoptada:
Ahora los kernels linkean libstdc++ dinámicamente.
Para mantener compatibilidad con versiones antiguas, las compilaciones usan la toolchain oficial manylinux_2_28.
Esto reduce las colisiones entre runtimes y mejora la estabilidad en entornos heterogéneos.
Miscelánea: instalación, Terraform y system cards
Hay un script de instalación que prepara el entorno de kernel-builder en un clic, útil si no quieres armar todo manualmente.
Si prefieres instancias efímeras en la nube, hay una guía con Terraform para desplegar entornos reproducibles.
Al publicar un kernel se genera una system card que expone información útil: interfaces, uso y metadatos. Esa system card funciona como front matter del kernel en el Hub.
Reflexión final
Este conjunto de cambios hace que el ecosistema de kernels sea más seguro, reproducible y preparado para automatizaciones avanzadas con agentes. Si trabajas con aceleradores o desarrollas código nativo para ML, estas mejoras te ayudan a reducir riesgos y a acelerar ciclos de optimización.
¿Y tú? Si ya tienes kernels en producción, vale la pena revisar las nuevas prácticas de firma, las políticas de publicadores y cómo ajustar tus pipelines de build para manylinux_2_28. Si quieres empezar a experimentar, la instalación rápida y los ejemplos has_kernel/get_kernel_variants facilitan dar los primeros pasos.
Agradecimientos: gracias a Aritra por la revisión de la publicación.
