AIREITERO NVIDIA Kumo Tabular pode ser baixado publicamente e merece um piloto em dados de tabela única, mas as evidências disponíveis ainda não justificam substituir CatBoost, LightGBM ou TabPFN em produção.
Veredito prático: pilote o Kumo Tabular, mas não migre o tráfego de produção ainda
Vale testar o Kumo Tabular quando seus dados já estão reunidos em uma única tabela, os rótulos estão disponíveis e você quer descobrir se a predição em contexto reduz o trabalho de modelagem. Latência rígida, execução apenas em CPU, hospedagem gerenciada ou dados distribuídos em várias tabelas devem ser tratados como critérios de validação — não como requisitos que o Kumo Tabular necessariamente atenderá.
Os pesos oficiais e a documentação da API estão disponíveis, mas ainda há poucas comparações públicas específicas do Kumo. Valide o modelo no seu próprio conjunto de teste.
O que a NVIDIA realmente lançou
O model card do Kumo-Tabular da NVIDIA descreve um modelo pré-treinado para classificação e regressão. Já a documentação oficial da API KumoTabular apresenta um fluxo de inferência em contexto: as linhas rotuladas servem como contexto, enquanto as linhas de consulta recebem predições sem que novos pesos sejam ajustados para cada conjunto de dados.
O pacote público oferece variantes pequena, média e grande. O catálogo de modelos de dados estruturados da NVIDIA lista aproximadamente 27 milhões a 216 milhões de parâmetros entre essas variantes. O model card informa a licença OpenMDW-1.1 e fornece um caminho de instalação em Python e de inferência. Leia os termos da licença para entender as condições de uso comercial e redistribuição; “pesos públicos” não significa uso irrestrito.
Não confunda esse lançamento com o KumoRFM. O Kumo Tabular foi desenvolvido para uma única tabela. A visão geral do Kumo Relational da NVIDIA descreve o KumoRFM como um modelo separado, voltado para dados relacionais. A documentação do Kumo Tabular informa explicitamente que o suporte a tabelas relacionadas não está disponível.
| Questão | Resposta do Kumo Tabular |
|---|---|
| Principais tarefas | Classificação e regressão |
| Formato de entrada | Uma tabela com linhas de contexto e de consulta |
| Treinamento por conjunto de dados | Não é necessário no fluxo de predição em contexto |
| Tabelas relacionadas | Não são compatíveis com a API pública do KumoTabular |
| Pesos | Públicos no Hugging Face |
| Licença indicada no model card | OpenMDW-1.1 |
| Inferência hospedada | Nenhum Hugging Face Inference Provider está listado |
O model card oficial e a página da API consultados para este artigo não publicam um limite simples de linhas ou de atributos. Eles informam a configuração do modelo e as restrições de tarefa. Por isso, número de linhas, quantidade de atributos, composição do contexto e das consultas, uso de memória e número de classes aceitas devem ser registrados durante o piloto — e não deduzidos a partir de outro modelo tabular.
As restrições que determinam se ele se encaixa no seu cenário
A adequação do Kumo Tabular depende de três restrições operacionais:
- Formato dos dados: o Kumo Tabular não consome tabelas relacionadas de forma nativa. Se os atributos preditivos vêm de clientes, pedidos, produtos e eventos de suporte, defina e valide a política de achatamento ou agregação antes de comparar os modelos.
- Escala de inferência: a documentação pública descreve as variantes do modelo e as tarefas compatíveis, mas não apresenta uma tabela validada de forma independente com throughput de produção, memória de GPU ou custo por predição. Meça como o tamanho do contexto altera a latência e o consumo de memória.
- Acesso para implantação: os pesos e a interface em Python são públicos, mas isso é diferente de contar com uma API gerenciada e um SLA. Equipes que precisam de roteamento regional, garantias de cota ou operação hospedada pelo fornecedor devem transformar esses requisitos em critérios explícitos do piloto.
Como o Kumo Tabular se compara ao TabPFN e aos modelos treinados
Não há, nas fontes analisadas, um resultado público confiável e comparável em condições equivalentes que prove que o Kumo Tabular supera o TabPFN atual, o CatBoost, o LightGBM ou o XGBoost. Os benchmarks de terceiros citados ajudam a desenhar o piloto, mas não sustentam afirmações de desempenho do Kumo.
| Cenário | Primeira comparação a executar | Objetivo da avaliação |
|---|---|---|
| Tabela única limpa, com amostra rotulada pequena ou média | Kumo Tabular versus TabPFN | Comparar a predição em contexto nativa para tabelas usando a mesma divisão |
| Tabela com muitos atributos categóricos | Kumo Tabular versus CatBoost | Usar o CatBoost como baseline treinado para dados categóricos |
| Scoring em lote estável e recorrente | Kumo Tabular versus LightGBM ou XGBoost | Comparar um modelo em contexto com baselines de serving baseados em modelos treinados |
| Sinal distribuído entre tabelas relacionadas | Baseline de tabela achatada versus abordagem relacional | Medir se a agregação escolhida descarta estrutura útil |
| Exploração rápida de esquemas | Piloto do Kumo Tabular | Testar se evitar um ciclo de treinamento específico da tarefa economiza tempo suficiente |
A comparação da AnoFox avaliou vários modelos fundacionais tabulares em uma CPU de 8 núcleos e descobriu que eles superaram os modelos testados do scikit-learn em cerca de 2–7% em cinco conjuntos de dados pequenos, embora o tempo de execução pudesse ser muito maior. Em um teste de churn, a inferência aquecida do Mitra levou 19,3 segundos, contra 0,035 segundo da regressão logística.
Um benchmark separado da AIMultiple concluiu que o TabFM venceu em 15 de 19 conjuntos de dados, mas exigiu aproximadamente 40 vezes mais computação que o TabPFN 3 ou o TabICLv2. O custo informado para uma execução completa do TabFM foi de cerca de US$ 27 em GPUs B200, contra aproximadamente US$ 0,65 do TabPFN 3. Mais uma vez, esses números servem para definir o que medir; eles não são resultados do Kumo.
Como fazer um primeiro teste defensável
Use um conjunto de teste fixo e faça o Kumo Tabular conquistar seu espaço ao lado de um baseline treinado.
- Defina uma única divisão temporal ou estratificada de treino e teste antes de experimentar os modelos. Mantenha os rótulos do conjunto de teste indisponíveis durante a predição.
- Valide o esquema da tabela: coluna-alvo, valores ausentes, colunas categóricas, entidades duplicadas e qualquer campo criado depois do instante da predição.
- Execute o Kumo Tabular na tabela bruta compatível, registrando a variante do modelo, as linhas de contexto e de consulta, a quantidade de atributos, o número de classes aceitas, o tamanho do lote, o hardware, o tempo de inicialização a frio, a latência aquecida e o pico de memória.
- Execute CatBoost ou LightGBM usando as mesmas linhas e o mesmo alvo. Registre o tempo de pré-processamento separadamente do tempo de treinamento e de predição.
- Compare uma métrica adequada à tarefa: AUROC e calibração para classificação binária, macro-F1 para cenários multiclasses desbalanceados e MAE ou RMSE para regressão.
- Repita o teste com uma amostra de contexto menor e outra maior. Se a qualidade permanecer estável, mas a latência crescer muito, o modelo pode ser mais adequado para exploração do que para serving.
- Defina antecipadamente três critérios de aprovação: ganho mínimo de métrica, latência p95 máxima e custo máximo de infraestrutura por lote. Só avance se o Kumo Tabular cumprir os três.
Não use um benchmark do fornecedor como substituto para as verificações contra vazamento de dados. “Sem engenharia de atributos” não significa “sem validação dos dados”.