AIREITERNVIDIA Kumo Tabular은 시험 도입해볼 만한 공개 단일 테이블 모델이다. 다만 현재까지 공개된 근거만으로는 프로덕션에서 CatBoost, LightGBM, TabPFN을 대체할 이유가 충분하지 않다.
결론부터 말하면: Kumo Tabular은 시험하되, 아직 프로덕션 트래픽을 옮기지는 말 것
데이터가 이미 하나의 테이블에 정리돼 있고 레이블도 확보되어 있다면 Kumo Tabular을 테스트해볼 가치는 있다. 인컨텍스트 예측 덕분에 모델링 작업을 줄일 수 있는지 직접 확인할 수 있기 때문이다. 반면 엄격한 지연 시간, CPU 전용 서빙, 관리형 호스팅, 다중 테이블 데이터가 필요하다면 Kumo Tabular이 이를 충족한다고 가정하지 말고, 파일럿의 통과 조건으로 따로 검증해야 한다.
공식 가중치와 API 문서는 공개되어 있다. 하지만 Kumo를 대상으로 한 공개 비교 자료는 아직 제한적이다. 최종 판단은 자체 홀드아웃 데이터로 내려야 한다.
NVIDIA가 실제로 공개한 것
NVIDIA의 Kumo-Tabular 모델 카드에 따르면 이 모델은 분류와 회귀를 지원하는 사전 학습 모델이다. 공식 KumoTabular API 문서는 인컨텍스트 방식의 사용 흐름을 보여준다. 레이블이 있는 행을 컨텍스트로 제공하면, 데이터셋마다 새로운 가중치를 학습하지 않고도 쿼리 행에 대한 예측을 생성하는 방식이다.
공개 패키지는 스몰, 미디엄, 라지 버전을 제공한다. NVIDIA의 structured-data 모델 카탈로그에는 이들 버전의 파라미터 수가 약 2,700만 개에서 2억 1,600만 개에 이르는 것으로 나와 있다. 모델 카드에는 OpenMDW-1.1 라이선스와 Python 설치 및 추론 방법이 안내되어 있다. ‘공개 가중치’라는 이유만으로 사용에 제한이 없다고 판단하지 말고, 상업적 배포와 재배포 조건은 라이선스 원문에서 확인해야 한다.
이 모델을 KumoRFM과 혼동해서는 안 된다. Kumo Tabular은 단일 테이블을 대상으로 한다. NVIDIA의 Kumo Relational 개요에 따르면 KumoRFM은 관계형 데이터를 위한 별도 모델이다. Kumo Tabular 문서에도 관련 테이블 지원은 제공되지 않는다고 명시되어 있다.
| 확인할 항목 | Kumo Tabular의 답변 |
|---|---|
| 주요 작업 | 분류와 회귀 |
| 입력 형태 | 컨텍스트 행과 쿼리 행으로 구성된 하나의 테이블 |
| 데이터셋별 학습 | 인컨텍스트 예측 경로에서는 필요하지 않음 |
| 관련 테이블 | 공개 KumoTabular API에서 지원하지 않음 |
| 가중치 | Hugging Face에 공개 |
| 모델 카드에 표시된 라이선스 | OpenMDW-1.1 |
| 호스팅 추론 | Hugging Face Inference Provider가 등록되어 있지 않음 |
이 글에서 검토한 공식 모델 카드와 API 페이지에는 최대 행 수나 최대 피처 수를 한눈에 보여주는 수치가 공개되어 있지 않다. 대신 모델 설정과 작업 제한은 확인할 수 있다. 따라서 행 수, 피처 수, 컨텍스트와 쿼리의 구성, 메모리 사용량, 허용되는 클래스 수는 다른 테이블 모델에서 추정하지 말고 파일럿 과정에서 직접 기록해야 한다.
도입 가능성을 가르는 세 가지 제약
Kumo Tabular이 실제 환경에 맞는지는 다음 세 가지 운영 조건에 달려 있다.
- 데이터 형태: Kumo Tabular은 관련 테이블을 네이티브로 처리하지 못한다. 예측에 필요한 값이 고객, 주문, 상품, 고객지원 이벤트처럼 여러 테이블에 흩어져 있다면 모델을 비교하기 전에 평탄화 또는 집계 정책을 먼저 정의하고 검증해야 한다.
- 추론 규모: 공개 문서는 모델 버전과 지원 작업을 설명하지만, 프로덕션 처리량, GPU 메모리, 예측당 비용을 독립적으로 검증한 표는 제공하지 않는다. 컨텍스트 크기가 지연 시간과 메모리 사용량을 어떻게 바꾸는지 직접 측정해야 한다.
- 배포 접근성: 가중치와 Python 인터페이스는 공개되어 있지만, 이는 SLA가 제공되는 관리형 API와는 다르다. 리전별 라우팅, 쿼터 보장, 벤더 호스팅 운영이 필요한 팀이라면 이런 요구사항을 파일럿의 명시적인 통과 조건으로 삼아야 한다.
Kumo Tabular을 TabPFN 및 기존 학습 모델과 비교하는 법
이번에 검토한 자료만으로는 Kumo Tabular이 최신 TabPFN, CatBoost, LightGBM, XGBoost보다 우수하다는 신뢰할 만한 일대일 비교 결과를 확인할 수 없다. 인용한 서드파티 벤치마크는 Kumo의 성능을 입증하는 자료가 아니라, 파일럿에서 무엇을 측정할지 정하는 참고 자료다.
| 워크로드 | 우선 실행할 비교 | 평가 목적 |
|---|---|---|
| 정제된 단일 테이블, 소규모 또는 중간 규모의 레이블 데이터 | Kumo Tabular과 TabPFN | 동일한 분할에서 테이블 기반 인컨텍스트 예측을 비교 |
| 범주형 데이터가 많은 테이블 | Kumo Tabular과 CatBoost | 학습 기반 범주형 데이터 모델의 기준선으로 CatBoost 활용 |
| 안정적인 반복 배치 스코어링 | Kumo Tabular과 LightGBM 또는 XGBoost | 인컨텍스트 모델과 학습 모델 서빙 기준선 비교 |
| 여러 연결 테이블에 신호가 분산된 데이터 | 플랫 테이블 기준선과 관계형 접근 방식 | 선택한 집계 방식이 유용한 구조를 잃게 만드는지 측정 |
| 빠른 스키마 탐색 | Kumo Tabular 파일럿 | 작업별 학습 루프를 생략해 실제로 시간을 절약할 수 있는지 확인 |
AnoFox 비교 자료는 8코어 CPU 한 대에서 여러 테이블 파운데이션 모델을 측정했다. 그 결과 소규모 데이터셋 5개에서 해당 모델들이 테스트한 scikit-learn 모델보다 약 2~7% 높은 성능을 보였지만, 실행 시간은 훨씬 길어질 수 있었다. 한 이탈 예측 테스트에서는 Mitra의 웜 추론에 19.3초가 걸린 반면, 로지스틱 회귀는 0.035초가 걸렸다.
별도의 AIMultiple 벤치마크에서는 TabFM이 19개 데이터셋 중 15개에서 승리했지만, TabPFN 3 또는 TabICLv2보다 대략 40배 많은 컴퓨팅 자원을 필요로 했다. 보고된 전체 TabFM 실행 비용은 B200 GPU에서 약 $27이었고, TabPFN 3은 약 $0.65였다. 다시 말해 이 수치들은 파일럿에서 수집해야 할 측정 항목을 보여줄 뿐이며, Kumo의 결과는 아니다.
처음부터 방어 가능한 방식으로 테스트하기
고정된 홀드아웃을 사용하고, 학습 모델 기준선과 나란히 비교해 Kumo Tabular이 실제로 자리를 얻을 수 있는지 확인하자.
- 모델을 시도하기 전에 시간 기준 또는 계층화 방식의 학습/테스트 분할을 하나 정해 고정한다. 예측 과정에서 테스트 레이블이 사용되지 않도록 한다.
- 테이블 스키마를 검증한다. 타깃 열, 결측값, 범주형 열, 중복 엔터티, 예측 시점 이후에 생성된 필드를 확인한다.
- 지원되는 원본 테이블에 Kumo Tabular을 실행하면서 모델 버전, 컨텍스트와 쿼리 행 수, 피처 수, 허용된 클래스 수, 배치 크기, 하드웨어, 콜드 스타트 시간, 웜 지연 시간, 최대 메모리 사용량을 기록한다.
- 동일한 행과 타깃으로 CatBoost 또는 LightGBM을 실행한다. 전처리 시간은 학습 및 예측 시간과 분리해 기록한다.
- 작업에 맞는 지표를 비교한다. 이진 분류는 AUROC와 캘리브레이션, 불균형 다중 분류는 macro-F1, 회귀는 MAE 또는 RMSE를 사용한다.
- 더 작거나 큰 컨텍스트 샘플로 테스트를 반복한다. 성능은 안정적인데 지연 시간이 급격히 늘어난다면, 이 모델은 서빙보다 탐색 단계에 더 적합할 수 있다.
- 통과 기준을 세 가지로 미리 정한다. 최소 성능 향상 폭, 최대 p95 지연 시간, 배치당 최대 인프라 비용이다. Kumo Tabular이 세 기준을 모두 충족할 때만 다음 단계로 진행한다.
벤더 벤치마크를 데이터 누수 점검의 대체 수단으로 사용해서는 안 된다. ‘피처 엔지니어링이 필요 없다’는 말이 ‘데이터 검증도 필요 없다’는 뜻은 아니다.