AIREITERNVIDIA Kumo Tabular se puede descargar públicamente y merece una prueba piloto si trabajas con una sola tabla, pero las evidencias disponibles todavía no justifican sustituir CatBoost, LightGBM o TabPFN en producción.
Conclusión práctica: prueba Kumo Tabular, pero no le entregues aún el tráfico de producción
Kumo Tabular tiene sentido cuando tus datos ya están reunidos en una tabla, las etiquetas están disponibles y quieres comprobar si la predicción en contexto reduce el trabajo de modelado. Si necesitas una latencia estricta, servir el modelo solo con CPU, alojamiento gestionado o datos repartidos entre varias tablas, conviértelo en un criterio de evaluación: no des por hecho que Kumo Tabular cumplirá esos requisitos.
Los pesos oficiales y la documentación de la API están disponibles, pero todavía hay pocas comparativas públicas específicas de Kumo. Valídalo con tu propio conjunto de prueba.
Qué ha publicado realmente NVIDIA
La ficha del modelo Kumo-Tabular de NVIDIA describe un modelo preentrenado para clasificación y regresión. La documentación oficial de la API de KumoTabular muestra un flujo de trabajo basado en contexto: las filas etiquetadas aportan el contexto y las filas de consulta reciben predicciones sin ajustar nuevos pesos para cada conjunto de datos.
El paquete público ofrece variantes pequeña, mediana y grande. El catálogo de modelos de datos estructurados de NVIDIA sitúa esas variantes entre aproximadamente 27 millones y 216 millones de parámetros. La ficha del modelo indica la licencia OpenMDW-1.1 y ofrece una ruta de instalación e inferencia en Python. Conviene revisar el texto de la licencia para comprobar las condiciones de uso comercial y redistribución; que los pesos sean públicos no significa que su uso sea ilimitado.
No hay que confundir este lanzamiento con KumoRFM. Kumo Tabular está pensado para una sola tabla. La descripción general de Kumo Relational de NVIDIA presenta KumoRFM como un modelo independiente para datos relacionales. La documentación de Kumo Tabular indica explícitamente que no admite tablas relacionadas.
| Pregunta | Respuesta de Kumo Tabular |
|---|---|
| Tareas principales | Clasificación y regresión |
| Estructura de entrada | Una tabla con filas de contexto y de consulta |
| Entrenamiento por conjunto de datos | No es necesario para la ruta de predicción en contexto |
| Tablas relacionadas | No compatibles con la API pública de KumoTabular |
| Pesos | Públicos en Hugging Face |
| Licencia indicada en la ficha del modelo | OpenMDW-1.1 |
| Inferencia alojada | No aparece ningún proveedor de inferencia de Hugging Face |
La ficha oficial del modelo y la página de la API revisadas para este artículo no publican una cifra sencilla sobre el máximo de filas o características. Sí muestran la configuración del modelo y las restricciones de las tareas, así que durante la prueba piloto conviene registrar el número de filas, el número de características, la composición del contexto y las consultas, el uso de memoria y la cantidad de clases admitidas, en lugar de inferirlos a partir de otro modelo tabular.
Las limitaciones que determinan si encaja en tu caso
La adecuación de Kumo Tabular depende de tres restricciones operativas:
- Estructura de los datos: Kumo Tabular no consume tablas relacionadas de forma nativa. Si los campos predictivos proceden de clientes, pedidos, productos y eventos de soporte, define y valida la estrategia de aplanado o agregación antes de comparar modelos.
- Escala de inferencia: La documentación pública describe las variantes del modelo y las tareas compatibles, pero no ofrece una tabla validada de forma independiente con el rendimiento en producción, la memoria GPU o el coste por predicción. Mide cómo cambian la latencia y la memoria al aumentar el tamaño del contexto.
- Acceso para el despliegue: Los pesos y la interfaz de Python son públicos, pero eso no equivale a una API gestionada con un SLA. Si necesitas enrutamiento regional, garantías de cuota u operaciones alojadas por el proveedor, conviértelos en criterios explícitos de la prueba piloto.
Cómo se compara Kumo Tabular con TabPFN y los modelos entrenados
En las fuentes revisadas no hay resultados públicos fiables y comparables en igualdad de condiciones que demuestren que Kumo Tabular supere a las versiones actuales de TabPFN, CatBoost, LightGBM o XGBoost. Los benchmarks de terceros citados sirven para diseñar la prueba piloto, no para hacer afirmaciones sobre el rendimiento de Kumo.
| Carga de trabajo | Primera comparación que conviene ejecutar | Objetivo de la evaluación |
|---|---|---|
| Tabla única limpia, con una muestra etiquetada pequeña o mediana | Kumo Tabular frente a TabPFN | Comparar la predicción en contexto nativa para datos tabulares con la misma partición |
| Tabla con muchas variables categóricas | Kumo Tabular frente a CatBoost | Usar CatBoost como referencia entrenada para datos categóricos |
| Scoring por lotes estable y repetido | Kumo Tabular frente a LightGBM o XGBoost | Comparar un modelo en contexto con modelos entrenados servidos en producción |
| Señal repartida entre tablas relacionadas | Referencia con tabla aplanada frente a un enfoque relacional | Medir si la agregación elegida pierde estructura útil |
| Exploración rápida de esquemas | Prueba piloto de Kumo Tabular | Comprobar si evitar el ciclo de ajuste específico de cada tarea ahorra un tiempo útil |
La comparativa de AnoFox midió varios modelos fundacionales tabulares en una CPU de 8 núcleos y observó que superaban a los modelos probados de scikit-learn aproximadamente entre un 2 % y un 7 % en cinco conjuntos de datos pequeños, aunque el tiempo de ejecución podía ser mucho mayor. En una prueba de abandono de clientes, la inferencia en caliente de Mitra tardó 19,3 segundos, frente a 0,035 segundos de la regresión logística.
Otro benchmark de AIMultiple concluyó que TabFM ganó en 15 de 19 conjuntos de datos, pero necesitó aproximadamente 40 veces más capacidad de cómputo que TabPFN 3 o TabICLv2. Según sus datos, una ejecución completa de TabFM costó unos 27 dólares en GPU B200, frente a unos 0,65 dólares de TabPFN 3. De nuevo, estas cifras indican qué conviene medir; no son resultados de Kumo.
Una primera prueba que puedas defender
Usa un conjunto de prueba fijo y obliga a Kumo Tabular a ganarse un puesto junto a una referencia entrenada.
- Fija una partición de entrenamiento y prueba temporal o estratificada antes de probar los modelos. Mantén las etiquetas del conjunto de prueba fuera del proceso de predicción.
- Valida el esquema de la tabla: columna objetivo, valores ausentes, columnas categóricas, entidades duplicadas y cualquier campo creado después del momento de la predicción.
- Ejecuta Kumo Tabular sobre la tabla compatible sin transformar y registra la variante del modelo, las filas de contexto y de consulta, el número de características, la cantidad de clases admitidas, el tamaño del lote, el hardware, el tiempo de arranque en frío, la latencia en caliente y el uso máximo de memoria.
- Ejecuta CatBoost o LightGBM con las mismas filas y el mismo objetivo. Registra por separado el tiempo de preprocesamiento, ajuste y predicción.
- Compara una métrica adecuada para la tarea: AUROC y calibración en clasificación binaria, macro-F1 en problemas multiclase desequilibrados y MAE o RMSE en regresión.
- Repite la prueba con una muestra de contexto más pequeña y otra más grande. Si la calidad se mantiene, pero la latencia aumenta bruscamente, el modelo puede ser más apropiado para explorar que para servir predicciones.
- Define de antemano tres criterios de aprobación: mejora mínima de la métrica, latencia p95 máxima y coste máximo de infraestructura por lote. Solo sigue adelante si Kumo Tabular cumple los tres.
No uses un benchmark del proveedor como sustituto de las comprobaciones contra fugas de información. Que no haya “ingeniería de características” no significa que puedas prescindir de validar los datos.