Maya Bennett
A Hugging Face lançou atualizações significativas em seu projeto Kernels, introduzindo um tipo de repositório dedicado, medidas de segurança aprimoradas, interfaces de linha de comando reformuladas, suporte expandido a frameworks e a base para o desenvolvimento de kernels orientado por agentes.
Kernels se tornam um tipo de repositório de primeira classe
O Hugging Face Hub agora conta com um novo tipo de repositório chamado "kernel". Essa mudança permite que os usuários vejam diretamente os aceleradores, sistemas operacionais e versões de backend suportados. Por exemplo, os detalhes de compatibilidade de um kernel agora são exibidos em destaque:
Todos os kernels disponíveis podem ser navegados em https://huggingface.co/kernels. Tornar os kernels cidadãos de primeira classe no Hub melhora a descoberta e ajuda o ecossistema de IA a identificar tendências entre kernels, modelos e aplicações.
Segurança ganha um grande impulso
Kernels executam código nativo com os mesmos privilégios do processo Python que os carrega, tornando a segurança uma prioridade máxima. O projeto sempre enfatizou a reprodutibilidade — os usuários podem recompilar um kernel e verificar se ele corresponde ao código-fonte público usando Nix para builds herméticos e sandboxes isolados. O SHA1 do Git de origem é incorporado ao kernel para melhorar a proveniência.
As adições recentes incluem editores de kernel confiáveis e assinatura de código.
Editores de kernel confiáveis
Com o novo tipo de repositório, a Hugging Face introduziu "editores confiáveis". Por padrão, o pacote kernels só carrega kernels de organizações em que a comunidade confia. Os usuários podem optar por carregar kernels de outras fontes usando o argumento trust_remote_code:
from kernels import get_kernel
kernel_module = get_kernel(
"Atlas-Inference/gdn", version=1, trust_remote_code=True
)
A publicação de repositórios de kernel é restrita por padrão. Usuários e organizações devem solicitar acesso nas configurações da conta, permitindo que a equipe analise cada solicitação individualmente.
Assinatura de kernel
A assinatura de código protege contra credenciais comprometidas do Hub. Um kernel é assinado com uma chave privada conhecida apenas pelo desenvolvedor e validado com uma chave pública. Mesmo que um invasor comprometa as credenciais de um editor confiável, ele não pode assinar um kernel malicioso sem a chave privada.
O projeto usa o cosign do Sigstore para assinar com chaves privadas efêmeras que são válidas por um tempo limitado. Ele também verifica se o kernel foi assinado por um fluxo de trabalho confiável do GitHub de um repositório confiável. A assinatura de kernel já é suportada pelo kernel-builder, e o comando kernels verify-signature está disponível. A verificação de assinatura no carregamento ainda não é aplicada, pendente de mais testes. Notas de configuração preliminares estão nas notas de lançamento do kernels 0.16.0: https://github.com/huggingface/kernels/releases/tag/v0.16.0.
CLIs reformuladas
Utilitários que antes estavam misturados entre kernels e kernel-builder foram separados. A biblioteca kernels agora foca exclusivamente em carregar e preparar kernels, enquanto o kernel-builder lida com a construção. Isso torna ambas as ferramentas mais enxutas e focadas.
A CLI melhorada também estabelece a base para o desenvolvimento de kernels orientado por agentes.
Suporte mais amplo a frameworks e backends
O suporte a frameworks foi estendido. As principais mudanças incluem:
Suporte ao Torch Stable ABI, permitindo que desenvolvedores de kernel segmentem uma versão específica do Torch ou qualquer versão lançada após ela por cerca de dois anos. Por exemplo, um kernel direcionado ao Torch 2.9 Stable ABI suporta Torch >= 2.9.
O Apache TVM FFI agora é suportado junto com o Torch. O TVM FFI é uma ABI padronizada que funciona com PyTorch, Jax, CuPy e outros, permitindo que kernels sejam executados em vários frameworks.
Base para desenvolvimento de kernels orientado por agentes
O kernel-builder e os kernels suportam o desenvolvimento de kernels orientado por agentes, onde um agente cria um kernel otimizado do zero. Juntos, eles possibilitam um fluxo de trabalho para agentes scaffolding, construção, benchmarking e otimização iterativa de kernels.
O desenvolvimento de kernels orientado por agentes ainda é novo, então fundamentos simples e claros são importantes. O kernel-builder impõe uma estrutura reproduzível para scaffolding e construção de kernels, dando aos agentes um layout de projeto previsível. Sua CLI é otimizada para agentes com comandos não interativos e saídas fáceis de interpretar programaticamente. Habilidades específicas de backend ajudam os agentes a navegar pelas idiossincrasias de diferentes backends.
Construir um kernel com sucesso é apenas o primeiro passo — ele deve proporcionar acelerações reais em relação a uma linha de base no hardware alvo. A integração com o HF Jobs facilita o benchmarking, permitindo que agentes executem suítes de benchmark, coletem resultados de desempenho e comparem com uma linha de base em diferentes configurações de hardware.
Abaixo estão alguns exemplos de kernels aumentados por agentes que ilustram os tipos de kernels que podem ser desenvolvidos e avaliados por meio deste fluxo de trabalho.
Atualizações diversas
Configuração de ambiente
Um script de instalação agora fornece configuração com um clique para construir kernels com o kernel-builder. Para instâncias efêmeras, um guia de configuração do Terraform está disponível.
Cartão do sistema para kernels
Após construir kernels, um cartão do sistema é criado para cada kernel, expondo informações úteis, incluindo como usá-lo e suas interfaces. Quando enviado ao Hub, este cartão se torna a matéria frontal do kernel:
Verificações de compatibilidade de kernel
Use o método has_kernel() para verificar se um kernel é compatível no seu sistema:
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
Ele retorna um bool. Para mais detalhes sobre por que um kernel não é suportado, 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})")
Deve imprimir (dependendo da sua 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))
…
Suporte aprimorado ao manylinux_2_28
O kernel-builder tem como alvo o manylinux_2_28 quase desde o início. Anteriormente, ele usava um toolchain gcc moderno compilado com glibc 2.28 e libstdc++ vinculada estaticamente. No entanto, isso causava problemas quando várias versões da libstdc++ estavam envolvidas — como a vinculada dinamicamente pelo PyTorch e a vinculada estaticamente por um kernel. Alguns kernels que usam funcionalidades como regexes C++ acionavam inicializações globais, levando a dados corrompidos e segfaults.
Para corrigir isso, a equipe atualizou a abordagem para evitar tais conflitos, garantindo maior estabilidade.
Essas atualizações posicionam o projeto Kernels para uma adoção mais ampla e casos de uso mais avançados, incluindo fluxos de trabalho de otimização orientados por agentes. Com segurança aprimorada, descoberta e suporte entre frameworks, a Hugging Face está estabelecendo as bases para um ecossistema de kernels mais robusto e flexível.
