NVIDIA lanza el modelo fundacional tabular de pesos abiertos Kumo Tabular: predicción sin entrenamiento en una sola pasada y primer puesto autoinformado en cuatro benchmarks
Según un blog oficial de NVIDIA publicado el 29 de septiembre de 2026, la empresa lanzó el modelo fundacional tabular Kumo Tabular, con tres tamaños de 28 a 215 millones de parámetros, publicado bajo la licencia OpenMDW-1.1 y disponible en Hugging Face, que no requiere entrenamiento ni ingeniería de características y realiza clasificación y regresión con una sola pasada hacia adelante; el blog afirma que ocupa el primer puesto en cuatro benchmarks como TabArena.
Qué ha cambiado
Según un blog oficial de NVIDIA publicado el 29 de septiembre de 2026, NVIDIA lanzó el modelo fundacional tabular Kumo Tabular, perteneciente a la serie de modelos Kumo Structured, cuyos pesos ya están disponibles en Hugging Face y cuyo código asociado se publica a través de una biblioteca de código abierto para datos estructurados. El modelo se preentrena íntegramente con tablas sintéticas generadas artificialmente: cada tabla de entrenamiento se muestrea de un modelo causal estructural, mediante grafos causales aleatorios y funciones de extracción aleatorias se generan columnas numéricas, columnas categóricas y la variable objetivo, mientras que los nodos restantes permanecen ocultos; después se aplican postprocesamientos como correlación de columnas, truncamiento de valores atípicos e inyección de valores faltantes, y se descartan mediante un conjunto de árboles las tablas sin señal aprendible. La arquitectura es un Transformer orientado a estructuras tabulares, con atención por columnas, atención por filas y atención de contexto; los valores numéricos y categóricos se incorporan mediante incrustaciones de características de Fourier y los valores faltantes no se imputan; las filas de contexto se atienden entre sí y las filas de consulta solo atienden a las filas de contexto, por lo que las claves y valores del contexto pueden calcularse una vez y reutilizarse; además se introduce una temperatura de atención sensible a la longitud, que escala cada consulta logarítmicamente con el número de claves para mantener la atención nítida en tablas grandes de decenas de miles de filas. El modelo se ofrece en tres versiones Small/Medium/Large, con aproximadamente 28 a 215 millones de parámetros; el entrenamiento de clasificación y el de regresión son dos modelos independientes, que usan respectivamente pérdida de entropía cruzada y pérdida de cuantiles, y la regresión produce 999 cuantiles para dar una predicción puntual y una estimación de incertidumbre. El blog afirma que ocupa el primer puesto en TabArena con un ELO de 1950 y que es 17 veces más rápido que LimiX-2 en un entorno de evaluación unificado con una sola RTX 6000 Pro; que obtuvo 1418 ELO y una puntuación de Improvability del 7.78% en BeyondArena, ocupando el primer puesto; que ocupa el primer puesto en la clasificación combinada de precisión de clasificación, pérdida logarítmica de clasificación y RMSE de regresión en TALENT; y que en ScoringBench las versiones Large y Medium ocupan el primer y segundo puesto respectivamente. El blog también indica que el modelo solo admite columnas numéricas y categóricas, que una sola pasada hacia adelante cubre como máximo 10 categorías y que las múltiples categorías se extienden mediante codificación de salida con corrección de errores de la biblioteca.
Impacto para desarrolladores
El impacto directo para los desarrolladores es que cambia la forma de abordar el modelado tabular: Kumo Tabular no tiene una interfaz de inferencia REST, sino que se invoca en un entorno de Python a través de una nueva biblioteca nativa de GPU, la primera ejecución descarga los pesos desde el Hub, la entrada son filas de contexto con etiquetas más filas de consulta a predecir, y no se actualizan pesos, no se hace ingeniería de características ni búsqueda de hiperparámetros. Si lo afirmado en el blog se sostiene, los escenarios más afectados primero son tareas tabulares con escasez de etiquetas y necesidad de una línea base rápida, como predicción de abandono, predicción de demanda y puntuación de riesgo, porque lo que elimina es toda la canalización de entrenamiento, no el tiempo de entrenamiento. Según la descripción del blog, la predicción depende solo del contexto y de la propia fila de consulta, no de otras filas de consulta del mismo lote, lo que significa que las claves y valores del contexto pueden almacenarse en caché y reutilizarse, calculando el contexto una sola vez en puntuaciones continuas; pero también significa que la calidad y la cobertura del contexto determinan directamente la salida, y elegir mal las filas de contexto es más difícil de detectar que elegir mal un hiperparámetro. Hay que tener en cuenta que el modelo no aparece en el catálogo en línea actual de KimiSeek, por lo que no puede invocarse a través de la API de este sitio y solo puede desplegarse localmente o en un servicio de GPU propio; las cifras del blog como la velocidad 17 veces mayor o el ELO de 1950 son autoinformadas por el fabricante, y el protocolo de evaluación y la partición de datos no se detallan en el texto, por lo que no pueden extrapolarse directamente a datos de negocio concretos; OpenMDW-1.1 es una licencia y no una conclusión de que "los pesos abiertos equivalen automáticamente a uso comercial", por lo que deben leerse y confirmarse los términos concretos. Conviene tratar Kumo Tabular como un candidato complementario y no como un reemplazo incondicional de los árboles de gradiente boosting existentes: es más prudente hacer primero experimentos comparativos en escenarios de tablas pequeñas y medianas, con suficientes filas etiquetadas y predominantemente columnas numéricas y categóricas.
Integración y evaluación
Las siguientes son recomendaciones condicionales, no conclusiones ya confirmadas por el fabricante. Primero, si se debe habilitar una ruta de inferencia local con GPU: el hecho reportado que hay que identificar es que el modelo se ejecuta localmente en forma de pesos a través de una biblioteca de código abierto y depende de un entorno con GPU. La elección a tomar es añadir una nueva ruta de inferencia local o seguir usando los modelos de árbol entrenados tarea por tarea; la condición clave que cambia la elección es si el equipo ya dispone de GPU utilizables, si hay suficientes tareas tabulares y si el coste de entrenamiento por tarea es suficientemente alto; el criterio de evaluación medible es comparar en un conjunto de validación propio la precisión o el error de regresión de ambos, registrando también la latencia de inferencia y el uso de memoria de GPU; si la inferencia local no ofrece ventaja en precisión y la latencia no es aceptable, no vale la pena mantener una nueva ruta por ella. Segundo, la elección del número de filas de contexto: el hecho reportado es que la tercera fase de entrenamiento amplía el contexto a 60000 filas y diseña específicamente una temperatura de atención sensible a la longitud. La elección a tomar es cuántas filas de contexto invertir en cada predicción; la condición previa es el tamaño de la tabla y el presupuesto de latencia, ya que a mayor contexto mayores son el coste de memoria y de tiempo; el criterio de evaluación es, con un conjunto de consultas fijo, medir precisión y latencia con cientos, miles y decenas de miles de filas de contexto, para ver si la precisión mejora al crecer el contexto y si la curva de latencia es aceptable; si la precisión se satura antes de tiempo, seguir añadiendo contexto solo desperdicia memoria de GPU. Tercero, el límite de adopción bajo deriva de distribución: el hecho reportado es que el blog advierte que la precisión puede degradarse cuando las distribuciones de las filas de consulta y de contexto difieren o cuando la tabla supera ampliamente el rango de entrenamiento. La elección a tomar es situar el modelo en tareas controladas de distribución similar o en tareas de distribución abierta entre periodos y canales; la condición previa es si se puede construir y mantener un grupo de muestras de contexto cercano al de producción; el criterio de evaluación es construir un conjunto de validación claramente alejado de la distribución de entrenamiento y observar si el error y el intervalo de cuantiles de salida del modelo aumentan en la misma medida y si la calibración sigue siendo válida; si el intervalo pierde calibración, conviene volver a un modelo con entrenamiento supervisado o reducir el alcance de uso. Cuarto, tareas con más de 10 categorías de clasificación: el hecho reportado es que una sola pasada hacia adelante admite como máximo 10 clases y que, si se supera, la biblioteca debe extenderlo a cualquier número de clases mediante codificación de salida con corrección de errores, lo que equivale a dividir la tarea en varios problemas binarios. La elección a tomar es usar directamente el modelo o elegir otra alternativa; la condición previa es si la cardinalidad de la columna objetivo y la latencia de predicción pueden aceptar un coste multiplicado; el criterio de evaluación es medir por separado el error y el tiempo de la subtarea multiclase y comparar con la solución existente antes de decidir.
Límites y cuestiones pendientes
Hay que dejar claro que Kumo Tabular no aparece actualmente en el catálogo en línea de KimiSeek y no puede invocarse a través de este sitio; lo descrito en el blog es la ruta de despliegue local del fabricante que publica pesos y una biblioteca de código abierto en Hugging Face, y ambas cosas no deben confundirse. Los rankings de benchmarks, ELO, multiplicadores de velocidad y tamaños de parámetros del texto provienen de resultados autoinformados por NVIDIA en su blog, sin reproducción independiente; el entorno de evaluación es una sola RTX 6000 Pro, y cambiar el hardware o la partición de datos podría dar conclusiones distintas. OpenMDW-1.1 es un acuerdo de licencia y los pesos abiertos por sí mismos no constituyen ninguna autorización; si cumple tus condiciones de uso comercial debe comprobarse leyendo el texto original de la licencia. El modelo solo admite columnas numéricas y categóricas; el texto, las imágenes y las marcas de tiempo dependen de un preprocesamiento integrado para convertirse en características; una sola pasada hacia adelante admite como máximo 10 clases y, si se supera, requiere codificación de salida con corrección de errores. El propio blog también reconoce que la precisión puede degradarse fuera del rango de entrenamiento o cuando las distribuciones de consulta y contexto no coinciden, por lo que antes de ponerlo en producción es imprescindible validar la precisión y la calibración con datos de validación propios. Además, el blog afirma que la receta de entrenamiento y el generador de datos artificiales se publicarán pronto, pero en el momento de publicación de ese artículo no eran públicos, por lo que reproducir por completo el proceso de entrenamiento sigue siendo inviable.
Ilustraciones de la noticia original
