AIREITERNVIDIA Kumo Tabular — общедоступная модель для работы с одной таблицей, которую имеет смысл протестировать. Но имеющихся данных пока недостаточно, чтобы рекомендовать замену CatBoost, LightGBM или TabPFN в продакшене.
Практический вывод: тестировать Kumo Tabular можно, переводить на неё продакшен-трафик — пока нет
Kumo Tabular стоит проверить, если данные уже собраны в одной таблице, целевая переменная доступна, а вы хотите понять, действительно ли предсказания по контексту сокращают объём ручной работы с моделированием. Жёсткие требования к задержке, работа только на CPU, управляемый хостинг или данные в нескольких таблицах лучше сразу считать отдельными критериями допуска к тесту, а не предполагать, что Kumo Tabular им автоматически соответствует.
Официальные веса и документация API доступны, однако публичных сравнений именно для Kumo пока немного. Окончательный вывод стоит делать на собственном отложенном наборе.
Что именно выпустила NVIDIA
В карточке модели Kumo-Tabular NVIDIA описывает предобученную модель для классификации и регрессии. Официальная документация API KumoTabular показывает сценарий предсказаний по контексту: размеченные строки используются как контекст, а для строк запроса модель выдаёт предсказания без дообучения новых весов под каждый конкретный датасет.
В открытом пакете доступны варианты small, medium и large. В каталоге моделей для структурированных данных NVIDIA указывает примерно от 27 до 216 миллионов параметров в зависимости от варианта. В карточке модели указана лицензия OpenMDW-1.1, а также приведён способ установки через Python и запуска инференса. Перед коммерческим использованием и распространением проверьте текст лицензии: наличие публичных весов ещё не означает отсутствие ограничений.
Не стоит путать этот релиз с KumoRFM. Kumo Tabular рассчитана на одну таблицу. В обзоре Kumo Relational NVIDIA описывает KumoRFM как отдельную модель для реляционных данных. В документации Kumo Tabular прямо указано, что связанные таблицы не поддерживаются.
| Вопрос | Ответ для Kumo Tabular |
|---|---|
| Основные задачи | Классификация и регрессия |
| Формат входных данных | Одна таблица со строками контекста и запроса |
| Обучение под каждый датасет | Для предсказаний по контексту не требуется |
| Связанные таблицы | Не поддерживаются в публичном API KumoTabular |
| Веса | Доступны на Hugging Face |
| Лицензия, указанная в карточке модели | OpenMDW-1.1 |
| Хостинг инференса | Провайдер Inference Provider от Hugging Face не указан |
В официальных карточке модели и странице API, изученных для этой статьи, нет простого указания максимального числа строк или признаков. При этом доступны конфигурация модели и ограничения по задачам. Поэтому во время пилота нужно отдельно зафиксировать число строк и признаков, состав контекста и запроса, потребление памяти и допустимое число классов, а не переносить ограничения другой табличной модели.
Ограничения, от которых зависит пригодность модели
Пригодность Kumo Tabular определяется тремя практическими ограничениями:
- Структура данных: Kumo Tabular не работает со связанными таблицами напрямую. Если признаки приходят из данных о клиентах, заказах, товарах и обращениях в поддержку, до сравнения моделей нужно определить и проверить правила объединения и агрегации.
- Масштаб инференса: В открытой документации описаны варианты моделей и поддерживаемые задачи, но нет независимо подтверждённой таблицы с производительностью в продакшене, объёмом GPU-памяти или стоимостью одного предсказания. Измерьте, как размер контекста влияет на задержку и потребление памяти.
- Доступ для развёртывания: Веса и интерфейс Python доступны публично, но это не то же самое, что управляемый API с SLA. Если команде нужны маршрутизация по регионам, гарантированные квоты или операции на стороне провайдера, эти требования следует заранее включить в критерии пилота.
Как Kumo Tabular выглядит на фоне TabPFN и обучаемых базовых моделей
В изученных источниках нет надёжного сравнения по принципу «один к одному», которое доказывало бы превосходство Kumo Tabular над актуальными TabPFN, CatBoost, LightGBM или XGBoost. Указанные сторонние бенчмарки помогают спланировать пилот, но не подтверждают показатели Kumo.
| Сценарий | С чего начать сравнение | Что проверяем |
|---|---|---|
| Чистая одна таблица, небольшой или средний размеченный набор | Kumo Tabular против TabPFN | Сравнить предсказания по контексту на одной и той же выборке |
| Таблица с большим количеством категориальных признаков | Kumo Tabular против CatBoost | Использовать CatBoost как обучаемую базовую модель для категориальных данных |
| Стабильный повторяющийся пакетный скоринг | Kumo Tabular против LightGBM или XGBoost | Сравнить модель по контексту с базовыми моделями, которые обучаются и затем обслуживают запросы |
| Сигнал распределён по связанным таблицам | Базовая модель на плоской таблице против реляционного подхода | Понять, не теряется ли полезная структура после агрегации |
| Быстрое исследование схемы данных | Пилот Kumo Tabular | Проверить, экономит ли отказ от отдельного цикла обучения под задачу действительно полезное время |
В сравнении AnoFox несколько табличных foundation-моделей тестировали на одном 8-ядерном CPU. На пяти небольших датасетах они обошли проверенные модели scikit-learn примерно на 2–7%, но могли работать значительно дольше. В одном из тестов на отток пользователей тёплый инференс Mitra занял 19,3 секунды против 0,035 секунды у логистической регрессии.
В отдельном бенчмарке AIMultiple TabFM победила на 15 из 19 датасетов, однако потребовала примерно в 40 раз больше вычислительных ресурсов, чем TabPFN 3 или TabICLv2. По приведённым данным, полный запуск TabFM стоил около $27 на GPU B200, тогда как TabPFN 3 — около $0,65. И здесь речь идёт о параметрах, которые стоит измерить в собственном тесте, а не о результатах Kumo.
Как провести первый тест без натяжек
Используйте фиксированный отложенный набор и заставьте Kumo Tabular конкурировать с обучаемой базовой моделью на равных условиях.
- Заранее зафиксируйте один временной или стратифицированный сплит train/test. Во время предсказаний тестовые метки должны оставаться недоступными.
- Проверьте схему таблицы: целевой столбец, пропуски, категориальные признаки, дубликаты сущностей и все поля, созданные после момента, на который делается предсказание.
- Запустите Kumo Tabular на исходной поддерживаемой таблице. Зафиксируйте вариант модели, строки контекста и запроса, число признаков, допустимое число классов, размер батча, аппаратную конфигурацию, время холодного старта, тёплую задержку и пиковое потребление памяти.
- Запустите CatBoost или LightGBM на тех же строках и с той же целевой переменной. Время подготовки данных учитывайте отдельно от времени обучения и предсказаний.
- Выберите метрику под задачу: AUROC и калибровку для бинарной классификации, macro-F1 для несбалансированной многоклассовой задачи, MAE или RMSE для регрессии.
- Повторите тест с меньшим и большим объёмом контекста. Если качество остаётся стабильным, а задержка резко растёт, модель может лучше подходить для исследования, чем для сервинга.
- Заранее определите три критерия прохождения: минимальный прирост метрики, максимальную задержку p95 и максимальную стоимость инфраструктуры на пакет. Переводите Kumo Tabular на следующий этап только при выполнении всех трёх условий.
Бенчмарк от поставщика не заменяет проверку на утечки. Отсутствие feature engineering не означает отсутствие валидации данных.