AIREITERNVIDIA Kumo Tabular, pilot uygulama için değerlendirilmeye değer, herkese açık şekilde indirilebilen bir tek tablo modeli. Ancak mevcut kanıtlar, üretimde CatBoost, LightGBM veya TabPFN’in yerine geçirilmesini henüz desteklemiyor.
Pratik karar: Kumo Tabular’ı deneyin, üretim trafiğini henüz taşımayın
Verileriniz zaten tek bir tabloda tutuluyorsa, etiketleriniz mevcutsa ve bağlam içi tahmin yaklaşımının modelleme işini azaltıp azaltamayacağını görmek istiyorsanız Kumo Tabular’ı test etmek mantıklı. Buna karşılık katı gecikme hedefleri, yalnızca CPU üzerinde çalışma, yönetilen barındırma veya çok tablolu veri söz konusuysa, Kumo Tabular’ın bu ihtiyaçları karşılayacağını varsaymak yerine bunları pilotun geçiş koşulları olarak ele alın.
Resmî ağırlıklar ve API dokümantasyonu mevcut; ancak Kumo’ya özel, kamuya açık karşılaştırmalar hâlâ sınırlı. Son kararı kendi holdout veriniz üzerinde doğrulayın.
NVIDIA gerçekte ne yayımladı?
NVIDIA’nın Kumo-Tabular model kartı, sınıflandırma ve regresyon için önceden eğitilmiş bir model tanımlıyor. Resmî KumoTabular API dokümantasyonu ise bağlam içi bir çalışma biçimi sunuyor: Etiketli satırlar bağlam olarak kullanılıyor, sorgu satırları içinse her veri kümesine yeniden ağırlık eğitmeden tahmin üretiliyor.
Herkese açık paket; küçük, orta ve büyük olmak üzere üç varyant sunuyor. NVIDIA’nın yapılandırılmış veri modeli kataloğunda bu varyantlar için yaklaşık 27 milyon ile 216 milyon arasında parametre listeleniyor. Model kartında OpenMDW-1.1 lisansı ile Python kurulumu ve çıkarım adımları yer alıyor. “Herkese açık ağırlıklar” ifadesini sınırsız kullanım olarak yorumlamayın; ticari dağıtım ve yeniden dağıtım koşulları için lisans metnini ayrıca inceleyin.
Bu sürümü KumoRFM ile karıştırmayın. Kumo Tabular tek bir tabloyu hedefliyor. NVIDIA’nın Kumo Relational genel bakış sayfasında KumoRFM, ilişkisel veriler için ayrı bir model olarak tanımlanıyor. Kumo Tabular dokümantasyonunda da ilişkili tablo desteğinin bulunmadığı açıkça belirtiliyor.
| Soru | Kumo Tabular’ın yanıtı |
|---|---|
| Ana görevler | Sınıflandırma ve regresyon |
| Girdi biçimi | Bağlam ve sorgu satırlarından oluşan tek tablo |
| Veri kümesine özel eğitim | Bağlam içi tahmin yolunda gerekli değil |
| İlişkili tablolar | Herkese açık KumoTabular API’sinde desteklenmiyor |
| Ağırlıklar | Hugging Face üzerinde herkese açık |
| Model kartında belirtilen lisans | OpenMDW-1.1 |
| Barındırılan çıkarım | Herhangi bir Hugging Face Inference Provider listelenmiyor |
Bu yazı için incelenen resmî model kartı ve API sayfasında, maksimum satır veya özellik sayısını belirten basit bir sınır yayımlanmıyor. Bunun yerine model yapılandırması ve görev kısıtları sunuluyor. Bu nedenle satır sayısını, özellik sayısını, bağlam ve sorgu dağılımını, bellek kullanımını ve kabul edilen sınıf sayısını başka bir tablo modelinden tahmin etmek yerine pilot sırasında kayda alın.
Uyumluluğu belirleyen operasyonel kısıtlar
Kumo Tabular’ın ihtiyaçlarınıza uyup uymadığını üç operasyonel konu belirliyor:
- Veri yapısı: Kumo Tabular, ilişkili tabloları doğal biçimde kullanamıyor. Tahmin için gereken alanlar müşteriler, siparişler, ürünler ve destek kayıtları gibi farklı tablolara yayılıyorsa modelleri karşılaştırmadan önce düzleştirme veya toplulaştırma politikanızı tanımlayıp doğrulayın.
- Çıkarım ölçeği: Herkese açık dokümantasyon model varyantlarını ve görev desteğini açıklıyor; ancak üretim aktarım hızı, GPU belleği veya tahmin başına maliyet için bağımsız biçimde doğrulanmış bir tablo sunmuyor. Bağlam boyutunun gecikme ve bellek kullanımını nasıl değiştirdiğini ölçün.
- Dağıtım erişimi: Ağırlıklar ve Python arayüzü herkese açık olsa da bu, SLA sunan yönetilen bir API ile aynı şey değil. Bölgesel yönlendirme, kota garantisi veya tedarikçi tarafından yürütülen operasyonlara ihtiyaç duyan ekipler, bu gereksinimleri pilotun açık geçiş koşulları hâline getirmeli.
Kumo Tabular, TabPFN ve eğitilmiş temel modellerin yanında nerede duruyor?
İncelenen kaynaklarda Kumo Tabular’ın güncel TabPFN, CatBoost, LightGBM veya XGBoost’u geride bıraktığını kanıtlayan güvenilir, bire bir karşılaştırma bulunmuyor. Atıf yapılan üçüncü taraf benchmark’lar, Kumo’nun performansına ilişkin iddialar değil; pilot tasarlamak için kullanılabilecek veriler.
| İş yükü | İlk yapılacak karşılaştırma | Değerlendirme amacı |
|---|---|---|
| Temiz, küçük veya orta ölçekli etiketli tek tablo | Kumo Tabular ve TabPFN | Aynı veri bölümü üzerinde tabloya özgü bağlam içi tahmini karşılaştırmak |
| Kategorik alanların ağırlıkta olduğu tablo | Kumo Tabular ve CatBoost | CatBoost’u eğitilmiş kategorik veri temel modeli olarak kullanmak |
| Kararlı ve tekrarlanan toplu skor üretimi | Kumo Tabular ve LightGBM veya XGBoost | Bağlam içi modeli, eğitilmiş model sunumuna dayalı temel yaklaşımlarla karşılaştırmak |
| Sinyalin bağlantılı tablolara yayıldığı veri | Düz tablo temel modeli ve ilişkisel yaklaşım | Seçilen toplulaştırmanın faydalı yapıyı kaybedip kaybetmediğini ölçmek |
| Şema keşfinin hızlı yapılması gereken durumlar | Kumo Tabular pilotu | Göreve özel bir eğitim döngüsünü atlamanın anlamlı zaman kazandırıp kazandırmadığını test etmek |
AnoFox karşılaştırması, çeşitli tablo temeli modellerini tek bir 8 çekirdekli CPU üzerinde ölçtü. Modeller, beş küçük veri kümesinde test edilen scikit-learn modellerini yaklaşık %2–7 oranında geride bırakırken çalışma süresi çok daha yüksek olabiliyordu. Bir churn testinde Mitra’nın sıcak çıkarım süresi 19,3 saniyeydi; lojistik regresyonda bu süre 0,035 saniye olarak ölçüldü.
Ayrı bir AIMultiple benchmark’ı, TabFM’in 19 veri kümesinin 15’inde en iyi sonucu verdiğini, ancak TabPFN 3 veya TabICLv2’ye kıyasla yaklaşık 40 kat daha fazla işlem kaynağı gerektirdiğini buldu. Bildirilen tam TabFM çalışmasının B200 GPU’lar üzerindeki maliyeti yaklaşık 27 dolardı; TabPFN 3 için bu değer yaklaşık 0,65 dolardı. Ancak bu rakamlar da Kumo sonuçları değil, toplanması gereken ölçümleri tanımlayan veriler.
Savunulabilir bir ilk test nasıl yapılır?
Sabit bir holdout kullanın ve Kumo Tabular’ın eğitilmiş bir temel modelin yanında yer almayı hak ettiğini kanıtlamasını bekleyin.
- Modelleri denemeye başlamadan önce zamana duyarlı veya katmanlı tek bir eğitim/test bölümü sabitleyin. Tahmin sırasında test etiketlerini erişime kapalı tutun.
- Tablo şemasını doğrulayın: hedef sütun, eksik değerler, kategorik sütunlar, yinelenen varlıklar ve tahmin zaman damgasından sonra oluşturulmuş alanlar.
- Kumo Tabular’ı desteklenen ham tablo üzerinde çalıştırın. Model varyantını, bağlam ve sorgu satırlarını, özellik sayısını, kabul edilen sınıf sayısını, batch boyutunu, donanımı, soğuk başlangıç süresini, sıcak gecikmeyi ve tepe bellek kullanımını kaydedin.
- CatBoost veya LightGBM’i aynı satırlar ve hedef üzerinde çalıştırın. Ön işleme süresini eğitim ve tahmin sürelerinden ayrı kaydedin.
- Göreve uygun bir metriği karşılaştırın: ikili sınıflandırmada AUROC ve kalibrasyon, dengesiz çok sınıflı çalışmalarda macro-F1, regresyonda ise MAE veya RMSE.
- Daha küçük ve daha büyük bir bağlam örneğiyle testi tekrarlayın. Kalite sabit kalırken gecikme hızla artıyorsa model, servis vermekten çok keşif çalışmaları için daha uygun olabilir.
- Üç geçiş kriterini önceden belirleyin: minimum metrik kazanımı, maksimum p95 gecikmesi ve batch başına maksimum altyapı maliyeti. Kumo Tabular’ı ancak üçünü de karşılıyorsa bir sonraki aşamaya taşıyın.
Bir tedarikçi benchmark’ını veri sızıntısı kontrollerinin yerine koymayın. “Özellik mühendisliği yok” demek, “veri doğrulaması yok” demek değildir.