Núcleo TokenSpeed

O TokenSpeed-kernel é um subsistema de código aberto, projetado para resolver a complexidade dos backends na inferência de LLM (Large Language Models). Ele introduz uma API limpa e um sistema de registro que desacopla o runtime de alto nível do código de hardware específico de baixo nível. Neste artigo, fornecemos uma análise técnica do TokenSpeed-kernel e mostramos como ele ajuda os desenvolvedores a trabalhar com núcleos de alta performance para inferência de LLM em multi-silício. Os modelos de LLM e o hardware de inferência estão evoluindo a uma velocidade impressionante. Servir esses modelos de forma eficiente não é mais apenas uma questão de encontrar um kernel de atenção ou MoE rápido; os motores de inferência modernos precisam se mover rapidamente entre modelos, formatos de quantização, gerações de GPU e backends de fornecedores sem transformar o runtime em um labirinto de casos especiais. Essas APIs são agnósticas de plataforma e solução.

Essa é a motivação por trás do TokenSpeed-kernel: fornecer uma API limpa e estruturada para maximizar a flexibilidade. A interface entre o kernel e o runtime permanece genérica, enquanto os desenvolvedores de kernel obtêm estrutura suficiente para se especializar profundamente para cada plataforma. Utilizamos o GPT-OSS como um exemplo concreto para demonstrar esse design na prática. O runtime chama as mesmas APIs públicas do TokenSpeed-kernel, independentemente da plataforma; os caminhos AMD e NVIDIA obtêm seu desempenho a partir de kernels plugáveis por trás dessas APIs. Para o AMD GPT-OSS 120B, essa abordagem atinge o desempenho de linha de frente usando kernels Gluon, mostrando que a estratificação não compromete o desempenho do backend. O resultado é uma clara divisão de foco: os desenvolvedores de kernel podem se concentrar em melhorar o desempenho do kernel, enquanto os desenvolvedores de runtime podem se concentrar em melhorar a lógica de backend.

A separação limpa também tornou possível publicar o TokenSpeed-kernel como pacotes independentes que podem ser instalados e utilizados por si só (ou em conjunto ou separadamente para diferentes kernels), e não apenas como um componente TokenSpeed entrelaçado. O objetivo é que os pacotes de kernel sejam úteis para o ecossistema mais amplo: uma coleção de kernels portáteis e performáticos com uma superfície pública genérica. Isso inclui os kernels Gluon que discutiremos posteriormente, pois a AMD apoia todos no ecossistema – um ecossistema saudável é bom para a AMD e a comunidade. Os kernels decidem se uma pilha de serviço é rápida ou lenta. Atenção, roteamento MoE, GEMMs de especialista, comunicação, quantização e amostragem todos funcionam em kernels, e esses kernels definem a latência, o throughput e a eficiência de hardware de todo o sistema.

A parte difícil é que “o melhor kernel” raramente é uma resposta fixa. Ele depende da arquitetura do modelo, do formato do tensor, do formato de quantização, da geração de GPU, da disponibilidade da biblioteca do fornecedor, das restrições de implantação e se uma chamada está servindo tráfego de decodificação ou pré-preenchimento. Com o tempo, os motores acumulam caminhos para cobrir tudo isso: kernels em árvore, invólucros de bibliotecas de fornecedores, kernels experimentais, caminhos rápidos específicos de arquitetura e fallbacks históricos. Sem um sistema de kernel claro e uma fronteira dura em torno dele, a lógica de seleção de backend vaza para o código do modelo e o código do runtime. Essa vazamento é caro. Adicionar um novo modelo pode exigir tocar em caminhos de runtime não relacionados. Adicionar um novo alvo de silício pode significar passar verificações de dispositivo por meio de camadas de modelo. O desenvolvimento de kernel se torna mais difícil porque os detalhes do comportamento do modelo, o despacho do runtime, a seleção de backend e os detalhes de implementação do kernel estão entrelaçados por trás de uma fronteira não clara.

O TokenSpeed-kernel é projetado para manter essa complexidade em um só lugar. O sistema de kernel é construído em torno de três princípios práticos: primeiro, o suporte a multi-silício deve ser fundamental. O sistema de kernel deve entender as capacidades da plataforma diretamente, em vez de tratar as verificações de hardware como condicionais dispersas. A mesma operação pode ter múltiplas soluções para diferentes alvos de silício; todas devem competir por meio de um sistema de seleção. Segundo, a portabilidade e o desempenho devem coexistir. Um novo modelo precisa de um caminho portátil para executar em diferentes alvos de silício o mais rápido possível, e então pode gradualmente adquirir kernels mais otimizados. O TokenSpeed-kernel mantém caminhos portáteis Triton ao lado de opções focadas no desempenho: Gluon para AMD, CuteDSL para NVIDIA e invólucros de fornecedores onde eles são a ferramenta certa.

Terceiro, a iteração rápida de kernel precisa de guardrails. O desenvolvimento de kernel se move rapidamente quando o caminho da ideia à adoção é curto. O TokenSpeed-kernel mantém esse loop apertado com dependências magras, benchmarks e perfis independentes que tornam os kernels selecionados visíveis. A mesma estrutura fornece ao desenvolvimento de kernel para agentes de IA uma fronteira de trabalho mais clara: experimente um kernel, verifique-o, benchmark-o e registre-o sem reformatar o código do modelo. O TokenSpeed-kernel também revisita ativamente as dependências que complicam as compilações ou bloqueiam a iteração, aparando-as ou isolando-as quando necessário. Esses princípios levam a um design em camadas. Em um alto nível, o sistema de kernel em camadas é mostrado no diagrama a seguir. De cima para baixo, a pilha separa o que o runtime pede do como cada backend executa isso. O runtime entra por meio de uma API pública genérica; o selet