NVIDIA lança Kumo Tabular, modelo de base tabular de pesos abertos: previsão em uma única passagem direta sem treinamento e primeiro lugar autodeclarado em quatro benchmarks
Segundo o blog oficial da NVIDIA publicado em 29 de setembro de 2026, a empresa lançou o modelo de base tabular Kumo Tabular, com três tamanhos entre 28 milhões e 215 milhões de parâmetros, publicado sob a licença OpenMDW-1.1 e disponibilizado no Hugging Face; sem necessidade de treinamento ou engenharia de recursos, basta uma única passagem direta para classificação e regressão, e o blog afirma que ele ocupa o primeiro lugar em quatro benchmarks, incluindo o TabArena.
O que mudou
Segundo o blog oficial da NVIDIA publicado em 29 de setembro de 2026, a NVIDIA lançou o modelo de base tabular Kumo Tabular, pertencente à série Kumo Structured, com pesos já disponíveis no Hugging Face e código correspondente publicado por meio da biblioteca de código aberto para dados estruturados. O modelo é pré-treinado inteiramente em tabelas sintéticas: cada tabela de treinamento é amostrada de um modelo causal estrutural, gerando colunas numéricas, colunas categóricas e a variável alvo por meio de um grafo causal aleatório e funções de amostragem aleatórias, mantendo os demais nós ocultos, seguido de pós-processamento como correlação de colunas, truncamento de valores atípicos e injeção de valores ausentes, além de uma verificação com conjunto de árvores para eliminar tabelas sem sinal aprendível. A arquitetura é um Transformer voltado para estruturas tabulares, utilizando atenção por coluna, atenção por linha e atenção de contexto; valores numéricos e categóricos passam por incorporação de características de Fourier, e valores ausentes não são preenchidos; as linhas de contexto prestam atenção umas às outras, enquanto a linha de consulta presta atenção apenas às linhas de contexto, de modo que as chaves e valores do contexto podem ser calculados uma vez e reutilizados; além disso, introduz uma temperatura de atenção sensível ao comprimento, que escala cada consulta de forma logarítmica com o número de chaves para manter a atenção afiada em tabelas grandes com dezenas de milhares de linhas. O modelo divide-se em três tamanhos Small/Medium/Large, com cerca de 28 milhões a 215 milhões de parâmetros; classificação e regressão são treinadas como dois modelos independentes, usando perda de entropia cruzada e perda de quantil, respectivamente, com a regressão emitindo 999 quantis para fornecer previsão pontual e estimativa de incerteza. O blog afirma que ele ocupa o primeiro lugar no TabArena com ELO 1950 e é 17 vezes mais rápido que o LimiX-2 em um ambiente de avaliação unificado com uma única RTX 6000 Pro; no BeyondArena obteve 1418 ELO e 7,78% de pontuação de Improvability, ficando em primeiro lugar; no TALENT ficou em primeiro lugar na classificação combinada de acurácia de classificação, perda logarítmica de classificação e RMSE de regressão; e no ScoringBench, Large e Medium ficaram em primeiro e segundo lugares, respectivamente. O blog também esclarece que o modelo suporta apenas colunas numéricas e categóricas, cobrindo no máximo 10 categorias em uma única passagem direta, com múltiplas categorias expandidas pela biblioteca por meio de codificação de saída com correção de erros.
Impacto para desenvolvedores
O impacto direto para os desenvolvedores é que a forma de abordar a modelagem tabular mudou: o Kumo Tabular não tem interface de inferência REST, mas é chamado em ambiente Python por meio de uma nova biblioteca nativa de GPU, baixando os pesos do Hub na primeira execução, com entrada composta por linhas de contexto rotuladas mais a linha de consulta a prever, sem atualização de pesos, sem engenharia de recursos e sem busca de hiperparâmetros. Se o que o blog afirma se confirmar, os cenários mais afetados inicialmente são tarefas tabulares com rótulos escassos e necessidade de uma linha de base rápida, como previsão de churn, previsão de demanda e pontuação de controle de risco, porque o que se elimina é todo o pipeline de treinamento, e não o tempo de treinamento. Conforme descrito no blog, a previsão depende apenas do contexto e da própria linha de consulta, não das outras linhas de consulta do mesmo lote, o que significa que as chaves e valores do contexto podem ser armazenados em cache e reutilizados, calculando o contexto apenas uma vez na pontuação contínua; mas isso também significa que a qualidade e a cobertura do contexto determinam diretamente a saída, e escolher a linha errada de contexto é mais difícil de perceber do que escolher o hiperparâmetro errado. É preciso observar: o modelo não aparece no catálogo atual do KimiSeek, não pode ser chamado pela API deste site e só pode ser implantado localmente ou em um serviço de GPU próprio; números como a velocidade 17 vezes maior e o ELO 1950 no blog são declarações do fabricante, e o protocolo de avaliação e a divisão dos dados não são detalhados no texto, não podendo ser extrapolados diretamente para dados de negócios específicos; a OpenMDW-1.1 é uma licença, e não uma conclusão de que "pesos abertos equivalem automaticamente a uso comercial", sendo necessário ler os termos específicos para confirmar. Trate o Kumo Tabular como um candidato complementar, e não como substituto incondicional das árvores de boosting de gradiente existentes: em cenários com tabelas pequenas e médias, linhas rotuladas suficientes e predominância de colunas numéricas e categóricas, é mais prudente fazer primeiro experimentos comparativos.
Integração e avaliação
As sugestões a seguir são condicionais e não conclusões já confirmadas pelo fabricante. Primeiro, se vale implementar um caminho de inferência local em GPU: o fato relatado a identificar é que o modelo é executado localmente na forma de pesos por meio da biblioteca de código aberto e depende de ambiente com GPU. A escolha a fazer é adicionar um novo caminho de inferência local ou continuar usando modelos de árvore treinados tarefa a tarefa; a premissa que altera a escolha é se a equipe já tem GPUs disponíveis e se o número de tarefas tabulares é suficiente e o custo de treinamento por tarefa é alto; o critério de avaliação mensurável é comparar a acurácia ou o erro de regressão dos dois em um conjunto de validação próprio, registrando também a latência de inferência e o uso de memória de GPU; se a inferência local não tiver vantagem de acurácia e a latência for inaceitável, não vale a pena manter um novo caminho para ela. Segundo, a escolha do número de linhas de contexto: o fato relatado é que a terceira fase de treinamento expandiu o contexto para 60000 linhas e projetou especificamente uma temperatura de atenção sensível ao comprimento. A escolha a fazer é quantas linhas de contexto investir em cada previsão; a premissa é o tamanho da tabela e o orçamento de latência, pois quanto maior o contexto, maior o custo de memória e tempo; o critério de avaliação é, com um conjunto de consultas fixo, medir acurácia e latência usando contextos de centenas, milhares e dezenas de milhares de linhas, observando se a acurácia melhora com o aumento do contexto e se a curva de latência é aceitável; se a acurácia saturar precocemente, continuar adicionando contexto só desperdiça memória de GPU. Terceiro, os limites de adoção sob desvio de distribuição: o fato relatado é que o blog alerta que a precisão pode cair quando as distribuições das linhas de consulta e de contexto são diferentes ou quando a tabela está muito além do escopo de treinamento. A escolha a fazer é colocar o modelo em tarefas controladas de mesma distribuição ou em tarefas de distribuição aberta entre períodos e canais; a premissa é se é possível construir e manter um pool de amostras de contexto próximo ao ambiente de produção; o critério de avaliação é construir um conjunto de validação claramente fora da distribuição de treinamento, observar se o erro e o intervalo de quantis da saída do modelo aumentam simultaneamente e se a calibração ainda se mantém; se o intervalo ficar descalibrado, deve-se voltar a um modelo com treinamento supervisionado ou reduzir o escopo de uso. Quarto, tarefas de classificação com mais de 10 categorias: o fato relatado é que uma única passagem direta cobre no máximo 10 classes, e além disso a biblioteca precisa expandir por codificação de saída com correção de erros para qualquer número de classes, o que equivale a dividir a tarefa em vários problemas de classificação binária. A escolha a fazer é usar o modelo diretamente ou escolher outra solução; a premissa é se a cardinalidade da coluna alvo e a latência de previsão aceitam o custo multiplicado; o critério de avaliação é medir separadamente o erro e o tempo das subtarefas multiclasse e decidir após comparar com as soluções existentes.
Limites e pontos a confirmar
É preciso deixar claro: o Kumo Tabular atualmente não aparece no catálogo online do KimiSeek e não pode ser chamado por este site; o que o blog descreve é o caminho de implantação local do fabricante, que publica pesos e biblioteca de código aberto no Hugging Face, e as duas coisas não devem ser confundidas. As posições nos benchmarks, o ELO, os múltiplos de velocidade e o tamanho dos parâmetros citados no texto vêm de resultados autoreportados no blog da NVIDIA, sem reprodução independente, e o ambiente de avaliação foi uma única RTX 6000 Pro; trocar o hardware ou a divisão dos dados pode levar a conclusões diferentes. A OpenMDW-1.1 é um contrato de licença, e o fato de os pesos serem abertos não constitui autorização alguma; se ela atende às suas condições de uso comercial deve ser verificado lendo o texto original da licença. O modelo suporta apenas colunas numéricas e categóricas; texto, imagens e timestamps dependem de pré-processamento interno para conversão em características, e uma única passagem direta cobre no máximo 10 classes, exigindo codificação de saída com correção de erros além disso. O próprio blog também admite que a precisão pode cair fora do escopo de treinamento ou quando as distribuições de consulta e contexto não coincidem, portanto, antes de entrar em produção, é imprescindível validar a acurácia e a calibração com dados de validação próprios. Além disso, a receita de treinamento e o gerador de dados sintéticos foram anunciados no blog como de publicação próxima, mas até a data de publicação do texto não estavam públicos, e a reprodução completa do processo de treinamento ainda não é viável.
Ilustrações da notícia original
