XGBoost 3.2 v Pythonu 2026: Kompletní průvodce gradient boostingem pro produkci

Aktualizováno: 3. září 2026

XGBoost 3.2 (vydáno 9. února 2026) je nejrychlejší a nejstabilnější implementace gradient boostingu pro Python. Nová verze podporuje CUDA async memory pool pro efektivní GPU trénink na velkých datech, produkčně stabilní kategoriální features a Polars DataFrame nativně. Za sedm let, co posílám gradient boosting modely do produkce, se XGBoost stal defaultem, když latence, stabilita a interpretovatelnost hrají větší roli než nejnovější neuronová síť. Tento průvodce ukazuje, jak XGBoost 3.2 správně nasadit, od DMatrix po online inference.

• XGBoost 3.2 (únor 2026) přináší CUDA async memory pool pro externí paměť na GPU a stabilní podporu kategoriálních features.
• Nový balíček xgboost-cu13 na PyPI přidává CUDA 13 support; adaptivní cache automaticky rozděluje data mezi CPU a GPU pamětí.
• Early stopping s parametrem early_stopping_rounds je jediný nejúčinnější nástroj proti overfittingu, vždy ho používejte s validační sadou.
• Pro ladění hyperparametrů dává Bayesovská optimalizace přes Optuna 2–3× lepší výsledky než GridSearchCV při stejném počtu iterací.
• SHAP hodnoty lze počítat přímo přes predict(pred_contribs=True), o řád rychleji než přes shap.TreeExplainer.
• V produkci se drží při inference latence pod 5 ms na CPU pro modely s ~1000 stromy díky Array-Based Tree Traversal (od 3.1).

Co je XGBoost 3.2 a co je nového

XGBoost je implementace extreme gradient boostingu, tedy algoritmu, který sekvenčně trénuje stromy tak, že každý další strom se učí opravovat chyby předchozích. Verze 3.0 (duben 2025) byla první major release po přepsaném R balíčku a významné aktualizaci JVM balíčků. 3.1 (prosinec 2025) přidala adaptivní CUDA cache a CUDA 13 přes nový wheel xgboost-cu13, a verze 3.2 (únor 2026) je aktuální stable release.

Konkrétně 3.2 přidává tyhle klíčové věci, které v produkci reálně hrají roli:

• CUDA async memory pool: experimentální opt-in feature pro asynchronní správu paměti při externí paměti na GPU. Před 3.2 to vyžadovalo RMM plugin. Zatím jen Linux.
• Adaptivní cache pro všechna zařízení: dřív jen pro určité konfigurace, teď funguje i na GH200 a DGX Station s plnou C2C šířkou pásma. Parametr cache_host_ratio zůstává k dispozici pro případ fragmentace paměti.
• Podpora mixed GPU modelů: konfigurace host cache respektuje různé GPU v jednom stroji.
• Python 3.14 klasifikátor: oficiálně podporovaná verze.
• Explicitní nastavení GPU device ID na začátku tréninku, což umožňuje Spark executors běžet v exclusive módu.

Z předchozí 3.1 zůstávají v produkci nejužitečnější: Array-Based Tree Traversal pro rychlejší CPU inference, kategoriální features u Polars DataFrame a produkčně stabilní podpora kategoriálních dat (experimentální tag byl odstraněn).

Instalace XGBoost 3.2 s CUDA 13 a GPU podpora

Pro CPU trénink stačí klasické pip install xgboost. Wheel obsahuje binární build pro Linux (x86_64, aarch64), Windows (x86_64, aarch64) a macOS (x86_64, Apple Silicon). Pokud potřebujete GPU akceleraci, PyPI nabízí od verze 3.1 dva samostatné balíčky rozlišené podle CUDA verze:

# CPU-only build
pip install xgboost==3.2.0

# GPU build pro CUDA 12
pip install xgboost-cu12==3.2.0

# GPU build pro CUDA 13 (nový v 3.1)
pip install xgboost-cu13==3.2.0

Multi-GPU trénink funguje jen na Linuxu. Pro GPU trénink specifikujte parametr device:

import xgboost as xgb

# Automatická detekce první GPU
model = xgb.XGBClassifier(device="cuda", n_estimators=500)

# Explicitní volba GPU ordinal (druhá karta)
model = xgb.XGBClassifier(device="cuda:1", n_estimators=500)

Model natrénovaný na GPU lze načíst a použít na CPU-only stroji bez změn. Persistence formátu je device-agnostic, což se hodí, když trénujete na cloudové A100 a inferujete na levném CPU node. Podle oficiální dokumentace GPU support je pro GPU inference vhodné volat inplace_predict() místo predict(), pokud jsou data už na GPU. Ušetří to memory copy.

První model: DMatrix, XGBClassifier a scikit-learn API

XGBoost poskytuje dvě API. Nízkoúrovňové přes xgboost.train() a xgboost.Booster je flexibilnější, ale vyžaduje ruční konverzi na DMatrix. Vysokoúrovňové XGBClassifier / XGBRegressor je kompatibilní se scikit-learn a pro 90 % případů stačí. Následující příklad ukazuje binární klasifikaci na klasickém breast cancer datasetu:

import numpy as np
import xgboost as xgb
from sklearn.datasets import load_breast_cancer
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score

X, y = load_breast_cancer(return_X_y=True)
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

model = xgb.XGBClassifier(
    n_estimators=1000,
    max_depth=6,
    learning_rate=0.05,
    subsample=0.8,
    colsample_bytree=0.8,
    reg_lambda=1.0,
    objective="binary:logistic",
    eval_metric="auc",
    early_stopping_rounds=50,   # nový v 2.x, v konstruktoru, ne v fit
    tree_method="hist",         # rychlejší default od 2.0
    device="cpu",               # nebo "cuda" pro GPU
    random_state=42,
)

model.fit(X_train, y_train, eval_set=[(X_test, y_test)], verbose=False)

y_pred = model.predict_proba(X_test)[:, 1]
print(f"AUC: {roc_auc_score(y_test, y_pred):.4f}")
print(f"Nejlepší iterace: {model.best_iteration}")

Všimněte si dvou detailů, které lidé z tutoriálů z roku 2022 často ještě dělají špatně. Parametr early_stopping_rounds patří od 2.0 do konstruktoru, ne do fit(). A tree_method="hist" je od 2.0 defaultem, ale explicitně to napsat neškodí. Pořád vídám issues, kde někdo dostane pomalý exact algoritmus jen proto, že ho měl v YAML configu z roku 2019. (Sám jsem si na to naběhl loni při migraci staršího scoring service.)

Kdy použít early stopping v XGBoost

Early stopping je nejdůležitější anti-overfitting nástroj a jediný, který spolehlivě šetří výpočetní čas. Používejte ho vždy, kdy máte validační sadu. Princip je jednoduchý: trénink zastavíte, když validační metrika neroste po early_stopping_rounds po sobě jdoucích kolech. Model si automaticky zapamatuje nejlepší iteraci a predict() ji použije.

Praktický postup, který používám v produkci:

1. Nastavte n_estimators na velmi vysokou hodnotu (5000–10000). Nespoléhejte na manuální hledání "optimálního" počtu stromů.
2. early_stopping_rounds=50 až 100, méně u malých datasetů, více u velmi zašuměných.
3. Validační sadu předejte přes eval_set. Pro cross-validation použijte xgboost.cv() s early_stopping_rounds.
4. Zkontrolujte model.best_iteration. Pokud je blízko n_estimators, zvyšte strop, model se ještě učil.
5. Pro finální produkční model retrainujte na train+val s pevným počtem stromů = best_iteration × (1 + val_size/train_size). Ušetří to 5–15 % kvality.

Pozor na jeden častý omyl. Pokud používáte cross-validaci na ladění hyperparametrů (Optuna trial), early stopping v každém foldu není data leakage, protože každý fold má svoji validační sadu. Leakage vzniká teprve tehdy, když stejnou test sadu použijete i k early stoppingu i k reportování metriky. Pro produkční benchmark si nechte třetí, nedotčenou holdout sadu. (Honestně, tuhle chybu jsem viděl i v prezentacích na konferencích, není to výjimka.)

Jak ladit hyperparametry XGBoost pomocí Optuna

Bayesovská optimalizace přes Tree-structured Parzen Estimator (TPE), což je algoritmus, který stojí za Optuna pro ladění hyperparametrů, konzistentně poráží GridSearchCV a RandomizedSearchCV při stejném počtu evaluací. Ve Florek & Zagdański benchmarku (arXiv 2305.17094) TPE dominoval napříč všemi čtyřmi frameworky. Zde je produkční šablona, kterou používám:

import optuna
import xgboost as xgb
from sklearn.model_selection import StratifiedKFold
from sklearn.metrics import roc_auc_score
import numpy as np

def objective(trial: optuna.Trial) -> float:
    params = {
        "objective": "binary:logistic",
        "eval_metric": "auc",
        "tree_method": "hist",
        "device": "cpu",
        "n_estimators": 3000,
        "learning_rate": trial.suggest_float("learning_rate", 1e-3, 0.3, log=True),
        "max_depth": trial.suggest_int("max_depth", 3, 10),
        "min_child_weight": trial.suggest_float("min_child_weight", 1e-3, 10.0, log=True),
        "subsample": trial.suggest_float("subsample", 0.5, 1.0),
        "colsample_bytree": trial.suggest_float("colsample_bytree", 0.5, 1.0),
        "reg_alpha": trial.suggest_float("reg_alpha", 1e-8, 10.0, log=True),
        "reg_lambda": trial.suggest_float("reg_lambda", 1e-8, 10.0, log=True),
        "gamma": trial.suggest_float("gamma", 1e-8, 5.0, log=True),
    }
    skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
    scores = []
    for tr_idx, va_idx in skf.split(X_train, y_train):
        X_tr, X_va = X_train[tr_idx], X_train[va_idx]
        y_tr, y_va = y_train[tr_idx], y_train[va_idx]
        model = xgb.XGBClassifier(**params, early_stopping_rounds=50, random_state=42)
        model.fit(X_tr, y_tr, eval_set=[(X_va, y_va)], verbose=False)
        scores.append(roc_auc_score(y_va, model.predict_proba(X_va)[:, 1]))
    return float(np.mean(scores))

study = optuna.create_study(direction="maximize", sampler=optuna.samplers.TPESampler(seed=42))
study.optimize(objective, n_trials=50, show_progress_bar=True)
print("Nejlepší AUC:", study.best_value)
print("Nejlepší params:", study.best_params)

Klíčové hyperparametry a co skutečně dělají:

• learning_rate (0.01–0.3): menší = víc stromů potřeba, ale stabilnější. Kombinujte s early stoppingem.
• max_depth (3–10): hlubší strom = víc overfittingu. Pro tabulární data zřídka jdu nad 8.
• min_child_weight: minimální suma hessianu v listu. Vyšší hodnota znamená konzervativnější tree a méně overfittingu.
• subsample + colsample_bytree (0.5–1.0): stochastic gradient boosting. Silná regularizace, používejte kolem 0.8.
• gamma (min_split_loss): minimální redukce loss potřebná pro split. Vyšší hodnota = konzervativnější tree.
• reg_alpha a reg_lambda: L1 a L2 regularizace na listech.

Kategoriální data a podpora Polars v XGBoost 3.2

Do verze 3.1 byla podpora kategoriálních features označená jako experimentální. Od 3.1 je stable, včetně Polars DataFrame. To znamená konec ručního one-hot encodingu pro sloupce s vysokou kardinalitou (PSČ, ID produktů), XGBoost si dokáže sám vybrat rozdělení podle histogramu. Použití je přímočaré přes pandas category dtype nebo Polars Categorical:

import pandas as pd
import xgboost as xgb

df = pd.read_csv("orders.csv")
df["region"] = df["region"].astype("category")
df["product_id"] = df["product_id"].astype("category")

X = df.drop(columns=["target"])
y = df["target"]

model = xgb.XGBClassifier(
    tree_method="hist",
    enable_categorical=True,   # nutné pro kategoriální features
    max_cat_to_onehot=4,       # kategorie s do 4 unique hodnotami se one-hot
    max_cat_threshold=64,      # limit pro partition-based split
    n_estimators=1000,
    early_stopping_rounds=50,
)
model.fit(X, y, eval_set=[(X_val, y_val)], verbose=False)

V benchmarcích se CatBoost stále drží mírně vpředu u datasetů s dominantně kategoriálními features díky ordered boostingu. XGBoost 3.2 tuhle mezeru výrazně smazal. Pokud už máte XGBoost v produkci, není důvod měnit stack kvůli kategoriálním sloupcům.

Polars podpora si zaslouží samostatnou zmínku. Do 3.1 XGBoost Polars DataFrame konvertoval interně přes pandas (drahé). Od 3.1 běží konverze zero-copy přes Arrow buffer. Rozdíl na 20 GB datasetu vidím kolem 3× rychlejší DMatrix konstrukce. Pokud používáte Polars, přečtěte si moje srovnání Polars vs Pandas pro širší kontext.

Jak vysvětlit predikce XGBoost pomocí SHAP

SHAP (SHapley Additive exPlanations) je dnes de facto standard pro vysvětlování gradient boosting modelů. Pro modely nasazené v regulovaných doménách (fintech, healthcare, insurance) je to podmínka nutná. GDPR článek 22 a nadcházející EU AI Act vyžadují vysvětlitelnost automatizovaných rozhodnutí.

XGBoost má SHAP hodnoty vestavěné a jsou o řád rychlejší než shap.TreeExplainer, protože běží přímo v C++ jádru. Získáte je přes predict(pred_contribs=True):

import xgboost as xgb
import numpy as np

booster = model.get_booster()
dmatrix = xgb.DMatrix(X_test, enable_categorical=True)

# Interakční SHAP hodnoty
shap_values = booster.predict(dmatrix, pred_contribs=True)
# shape: (n_samples, n_features + 1); poslední sloupec je expected value

# Globální feature importance z |SHAP|
global_importance = np.abs(shap_values[:, :-1]).mean(axis=0)
for feat, imp in sorted(zip(X_test.columns, global_importance), key=lambda x: -x[1])[:10]:
    print(f"{feat:30s} {imp:.4f}")

Pro produkční logging jednotlivých predikcí ukládejte top-3 SHAP kontributory jako důkaz rozhodnutí. Poslouží to jako audit trail pro regulátory i debugging pro produktový tým. Nikdy neukládejte celý SHAP vektor pro každou predikci; u modelu se 100 features a 10M predikcí denně to zaplní datový lake za pár týdnů. (Nemluvím teoreticky, viděl jsem to na projektu v telekomunikacích.)

Rozdíl mezi XGBoost, LightGBM a CatBoost

Všechny tři jsou implementace gradient boosted decision trees. Liší se v tom, jak binují features, jak rostou stromy, jak zacházejí s chybějícími hodnotami a s kategoriálními daty. Následující tabulka shrnuje rozdíly, které v praxi rozhodují o výběru:

Kritérium	XGBoost 3.2	LightGBM 4.5	CatBoost 1.2
Rychlost tréninku (velká data)	Střední	Nejrychlejší (GOSS + EFB)	Střední
Přesnost po ladění	Špičková	Špičková	Špičková
Kategoriální features nativně	Ano (od 3.1 stable)	Ano	Ordered boosting (nejlepší)
Růst stromů	Level-wise (od 2.0 leaf-wise s grow_policy)	Leaf-wise	Symmetric (oblivious)
Latence inference	Nízká (Array-Based Traversal)	Nízká	Nejnižší (symmetric trees)
Spolehlivost defaultů	Střední	Střední	Výborná
Produkční ekosystém	Nejširší	Široký	Užší
GPU trénink	Vyzrálý (CUDA 13)	Vyzrálý	Vyzrálý

Praktické doporučení, které dávám juniorům v týmu: pokud nemáte konkrétní důvod jinak, začněte s XGBoost. Má největší komunitu, nejvíc Stack Overflow odpovědí a nejvíc production deploymentů. Když jsou vaše data dominantně kategoriální (víc než 60 % features), zkuste CatBoost. Když trénujete na terabajtových datech a rychlost je limit, přejděte na LightGBM. Ale nestrávte tři týdny benchmarkováním. Florek & Zagdański 2023 ukázal, že po pořádném ladění jsou všechny tři v rozsahu ±1–2 % AUC.

Produkční nasazení: latenční rozpočty a MLOps

Trénink je jen malá část skutečné práce. V produkci se řeší latence, throughput, cost-per-prediction a co se stane, když input distribution posune. Zde je kontrolní seznam, který používám před tím, než jakýkoli XGBoost model pustím do produkce:

1. Serializace: Nikdy neukládejte model přes pickle. Použijte model.save_model("model.ubj"). Nový univerzální binary JSON formát je forward-compatible a přenositelný mezi jazyky (Python, R, JVM, C++).
2. Latenční rozpočet: Pro real-time scoring cílujte pod 5 ms P99 na CPU. XGBoost 3.1+ Array-Based Tree Traversal to zvládá pro modely do ~1500 stromů. Nad tím zvažte model distillation nebo přesun na GPU.
3. Batching: Pro throughput scénáře posílejte batch 100–1000 řádků najednou. Jeden predict() call na batchi je 10–50× levnější než 1000 samostatných.
4. Serving framework: XGBoost model lze snadno nasadit přes FastAPI pro ML serving. Pro vyšší throughput použijte BentoML nebo NVIDIA Triton (podporuje XGBoost FIL backend).
5. Sledování experimentů: Loggujte každý trénink přes MLflow 3. Sledujte hyperparametry, metriky, feature importance i SHAP summary; velmi to pomůže při debug regresí za půl roku.
6. Detekce data drift: XGBoost je odolný vůči malému posunu features, ale bez monitoringu se dozvíte o katastrofě až z dashboardu byznysu. Loggujte distribuce vstupů a spouštějte KS test na denním okně proti trénovací distribuci.
7. Retraining strategy: Fixní kadence (týdně/měsíčně) nebo triggered (na drift alert). Automatizujte přes Airflow nebo Prefect. Nedělejte to ručně, pak se to nedělá.

Doporučuji nastudovat oficiální XGBoost 3.2 release notes pro kompletní seznam změn a případné breaking changes. Pro Python API details je autoritativním zdrojem Python API reference. A pokud řešíte přípravu dat před tréninkem, může se hodit průvodce scikit-learn Pipeline pro preprocessing.

Často kladené otázky

Podporuje XGBoost 3.2 GPU trénink na Apple Silicon?

Ne. GPU akcelerace v XGBoost běží výhradně přes CUDA, tedy jen na NVIDIA GPU. Apple Silicon (M1/M2/M3/M4) dostane CPU wheel s optimalizovaným ARM64 kódem, ale bez Metal Performance Shaders. Pro serious GPU trénink potřebujete NVIDIA hardware s CUDA 12 nebo 13.

Jaký je rozdíl mezi DMatrix a QuantileDMatrix?

DMatrix je klasická interní datová struktura XGBoost. QuantileDMatrix (od 2.0) přednastaví kvantilové binování a je vyžadovaná pro tree_method="hist" na GPU. Je paměťově efektivnější a rychlejší, ale nelze do ní přidávat další data. Pro standardní scikit-learn API se používá automaticky.

Kdy zvolit early stopping a kdy naopak natrénovat pevný počet stromů?

Vždy s early stoppingem, kromě finálního produkčního retraining kroku, kdy trénujete na train+val dohromady a už nemáte validační sadu. Tam použijte pevný počet stromů odvozený z best_iteration během hyperparameter search, přeškálovaný o poměr velikosti dat.

Jak zrychlit XGBoost inference v produkci pod 5 ms?

Čtyři páky: (1) omezte počet stromů pod 1500 díky early stoppingu; (2) použijte Array-Based Tree Traversal (default od 3.1); (3) batchujte predikce po 100–1000; (4) pro extrémně nízkou latenci konvertujte model do Treelite nebo NVIDIA FIL. GPU inference se vyplatí až od batch size ~10k.

Je XGBoost vhodný pro řídká (sparse) data z NLP?

Ano. XGBoost nativně podporuje scipy.sparse matice a chybějící hodnoty v jednom průchodu. Pro klasickou bag-of-words nebo TF-IDF reprezentaci s tisíci features je konkurenceschopný. Pro dense embedding vektory (BERT, sentence-transformers) obvykle vyhrávají logistic regression, MLP nebo přímo vector search, gradient boosted stromy se špatně učí lineární kombinace stovek dense features.