Hugging Face Kernels é redesenhado com foco em segurança e desenvolvimento agentivo

O projeto 🤗 Kernels do Hugging Face — que visa padronizar como kernels CUDA e outros kernels customizados são empacotados, distribuídos e consumidos — recebeu uma atualização significativa. A equipe praticamente redesenhou o projeto nos últimos meses, e o resultado é um ecossistema mais seguro, mais extensível e preparado para o desenvolvimento agentivo de kernels.

Kernels como cidadãos de primeira classe no Hub

A principal novidade é um novo tipo de repositório no Hugging Face Hub chamado “kernel”. Isso permite que usuários vejam informações específicas de compute: quais aceleradores são suportados, sistemas operacionais compatíveis e versões de backend. Kernels agora têm página própria com metadados de compatibilidade, tendências de uso e conexões com modelos e aplicações que os utilizam.

Todos os kernels disponíveis podem ser navegados em huggingface.co/kernels.

Segurança reforçada em duas camadas

Kernels executam código nativo com os mesmos privilégios do processo Python que os carrega — um kernel malicioso pode causar dano real. Por isso, a segurança sempre foi prioridade máxima no projeto.

Trusted Publishers

O novo sistema de “trusted publishers” (publicadores confiáveis) faz com que, por padrão, o pacote kernels só carregue kernels de organizações verificadas pela comunidade. Para carregar kernels de publishers não confiáveis, o usuário precisa explicitamente usar o argumento trust_remote_code=True:

from kernels import get_kernel

kernel_module = get_kernel(
    "Atlas-Inference/gdn", version=1, trust_remote_code=True
)

Além disso, usuários não podem publicar repositórios de kernel por padrão — é necessário solicitar acesso, o que dá tempo para análise caso a caso.

Assinatura de código com Sigstore

A segunda camada é code signing (assinatura de código). Se as credenciais do Hub de um publisher confiável forem comprometidas, um atacante poderia fazer upload de um kernel malicioso. A assinatura de código resolve isso: o kernel é assinado com uma chave privada conhecida apenas pelo desenvolvedor e validado com uma chave pública.

O Hugging Face usa Sigstore cosign com chaves efêmeras — válidas por tempo limitado, então mesmo que vazem, o atacante tipicamente não consegue usá-las. A verificação também confirma que o kernel foi assinado por um workflow confiável do GitHub de um repositório confiável.

A assinatura já é suportada pelo kernel-builder e o comando kernels verify-signature está disponível. A verificação automática no carregamento ainda está em testes antes do rollout completo.

CLIs redesenhadas

As CLIs do kernels e kernel-builder foram separadas com responsabilidades bem definidas:

• kernels: biblioteca para carregar e preparar kernels para uso — não inclui nada relacionado a “build”
• kernel-builder: ferramenta de build com estrutura de scaffolding, builds reproduzíveis e CLI otimizada para agentes

O resultado são ferramentas mais enxutas e específicas, mais fáceis de compor em workflows automatizados.

Mais frameworks e backends

O suporte foi expandido em duas frentes importantes:

• Torch Stable ABI: desenvolvedores podem mirar uma versão específica do Torch ou qualquer versão posterior por aproximadamente dois anos. Um kernel que mira Torch 2.9 Stable ABI funciona com Torch >= 2.9.
• Apache TVM FFI: primeiro framework além do Torch com suporte. O TVM FFI é uma ABI padronizada que interopera com PyTorch, JAX e CuPy, permitindo kernels cross-framework.

Fundação para desenvolvimento agentivo de kernels

Talvez o aspecto mais visionário da atualização: kernel-builder e kernels foram projetados para suportar desenvolvimento agentivo de kernels — agentes de IA que criam, compilam, avaliam e otimizam kernels do zero.

O fluxo funciona assim:

1. Scaffolding: o kernel-builder impõe uma estrutura padronizada para o código-fonte, dando ao agente um layout de projeto previsível
2. Build reproduzível: usando Nix para builds herméticos e determinísticos
3. Benchmarking: integração com HF Jobs para executar suites de benchmark em diferentes aceleradores e gerações de hardware
4. Otimização iterativa: o feedback de performance alimenta a próxima iteração do agente
5. Skills por backend: skills específicas que capturam toolchains, caminhos de compilação e considerações de performance de cada backend

A CLI do kernel-builder foi projetada para ser agent-optimized: comandos não interativos e outputs estruturados que um agente consegue interpretar programaticamente.

Por que isso importa

O projeto Kernels resolve um problema real do ecossistema: kernels CUDA e Triton são notoriamente difíceis de distribuir de forma portável e segura. Cada framework tem seu próprio sistema de build, versões quebram compatibilidade e não há um lugar centralizado para descobrir kernels otimizados. O Hugging Face está criando esse lugar — com segurança que faz sentido para código que roda com privilégios elevados.

A direção agentiva também é significativa. Se agentes de IA conseguirem gerar kernels competitivos com os escritos à mão, o gargalo de performance em ML muda radicalmente. Não será mais “qual framework tem o kernel mais otimizado para minha operação”, mas sim “meu agente gerou um kernel para essa operação específica no meu hardware específico”.