Install XGBoost 3.4.1 Gradient Boosting Library

Why does a clean pip install still miss the GPU?

pip install xgboost finishes green. Then device="cuda" drops to CPU with “not compiled with CUDA support” or “No visible GPU.” On 3.4.1 that usually means you got the default CUDA 13.x wheel while the driver only speaks 12.x – not a broken NVIDIA stack.

This is a deployment guide for the exact stable build: XGBoost 3.4.1 (15 Aug 2026 patch after 3.4.0 on 4 Aug 2026). No Iris walkthrough, no LightGBM bake-off. Commands, platform limits, wheel picks, and the error strings people hit.

Sources stay on the project’s own rails: PyPI, conda-forge, and the official installation guide.

System requirements for 3.4.1

Python >= 3.12 (PyPI metadata for 3.4.1). Runtime deps: numpy and scipy. Some Linux GPU wheels also pull NCCL.

As of 3.4.1, GPU-capable wheels cover Linux x86_64 and Linux aarch64 (multi-node multi-GPU on Linux only) and Windows x86_64 (GPU yes, multi-node no). macOS: CPU only. No published minimum RAM; non-toy matrices want multiple GB and a modern multi-core CPU.

Windows wheels need the Visual C++ Redistributable if Visual Studio is not already there – without those DLLs the import fails after a “successful” pip. macOS needs brew install libomp or you stay single-threaded / hit OpenMP load errors. Match the NVIDIA driver to the wheel’s CUDA line (13.x on the default package).

Disk reality from PyPI 3.4.1 files: Linux manylinux wheel ~57 MB, Windows amd64 ~49 MB, macOS ~2.5 MB. Full GPU builds land roughly 50-58 MB; the cpu-only package is far smaller if you never touch CUDA kernels.

Where the bits actually live

Default path is PyPI: pip install xgboost. Want the source tarball or experimental R GPU bits? Grab assets from the v3.4.1 GitHub release. conda-forge ships py-xgboost with cpu/cuda build strings. Nightlies exist; production should pin 3.4.1.

I still burn a fresh venv every time. Half the ModuleNotFoundError threads are “pip went to one Python, import ran in another” – usually base conda mixed with system pip.

Install steps (pip first)

python3 -m venv xgb-env
source xgb-env/bin/activate # Windows: xgb-envScriptsactivate
python -m pip install --upgrade pip

Full wheel (GPU where the platform table allows):

pip install xgboost==3.4.1

CPU-only footprint:

pip install xgboost-cpu==3.4.1

The catch is older drivers. Default Linux/Windows GPU wheels target CUDA Toolkit 13.x (3.4.0/3.4.1 line uses CUDA 13.3 builds). Driver stuck on 12.x? Swap packages:

pip uninstall xgboost xgboost-cu12 -y
pip install xgboost-cu12

Conda route (lets the solver pick GPU when it can):

conda install -c conda-forge py-xgboost

Pin shape with py-xgboost=*=cpu* or *=cuda*. On macOS run brew install libomp in the same session so multi-thread OpenMP actually loads.

Source build (git clone --recursive https://github.com/dmlc/xgboost, CMake, then pip install .) works. Most people can skip it – wheels already carry the CUDA 13.3 Linux/Windows builds.

Ever notice how “just install the ML library” turns into a second project about toolchains? CUDA tags, Redistributable DLLs, Homebrew libomp – same story every major release, only the version pins move.

First-time configuration

No config file. Multi-GPU or flaky peer-to-peer links sometimes need env tweaks; NCCL_P2P_DISABLE=1 shows up in community threads for certain driver hangs. In Python the switch is device="cuda" or device="cuda:0" on the estimator/Booster.

After install, run xgboost.build_info() once. It prints compiled features, including which CUDA the binary was built against – faster than guessing from pip freeze.

Verify

import xgboost as xgb
print(xgb.__version__) # 3.4.1
print(xgb.build_info()) # CUDA flags

import numpy as np
X = np.random.rand(100, 5)
y = np.random.randint(0, 2, 100)
model = xgb.XGBClassifier(tree_method="hist", device="cuda") # drop device for CPU
model.fit(X, y)
print("fit succeeded")

CUDA warning on that fit? Wrong variant or driver – use the cu12 reinstall path above, then re-check nvidia-smi.

Common install errors and fixes

• ModuleNotFoundError: No module named ‘xgboost’ – env mismatch. Prefer python -m pip install inside the activated venv/conda env.
• XGBoost is not compiled with CUDA support / No visible GPU – default wheel expects CUDA 13. Uninstall and pip install xgboost-cu12.
• OpenMP runtime is not installed (libomp.dylib / vcomp140.dll) – macOS: brew install libomp. Windows: Visual C++ Redistributable, then reinstall the wheel.
• Segfault importing with torch (Apple Silicon) – import torch before xgboost, or set OMP_NUM_THREADS=1. Two OpenMP runtimes (Homebrew libomp vs torch’s copy) collide; GitHub issue #11500 tracks the order bug.
• conda + pip both present – one manager per env. Remove the duplicate with the tool that installed it.

Those strings match GitHub issues and install-guide notes from the 3.4.x window.

Upgrade and uninstall

pip install --upgrade xgboost==3.4.1

Or the conda equivalent. Breaks introduced in 3.4.0 (still in force for 3.4.1): column-split support removed, federated learning dropped from Python wheels, quantile/MAE leaf math revised, vector-leaf for hist completed. Older major models usually load; re-run predict on a hold-out set, especially multi-output paths.

pip uninstall xgboost xgboost-cpu xgboost-cu12 -y
# conda: conda remove py-xgboost

Delete the venv for a full wipe. Source installs can leave libxgboost.so / .dylib / .dll behind – remove those manually if imports still resolve to a ghost binary.

Is a 50-plus MB GPU wheel worth it on a laptop that will only ever run hist on CPU? Sometimes yes for one codebase path. Sometimes xgboost-cpu is the saner default and you add CUDA only on the training box.

FAQ

Does XGBoost 3.4.1 still support older Python?

No. Wheels need Python >= 3.12. Stay on an older XGBoost if you are frozen on 3.10/3.11.

CPU-only machine – which package?

pip install xgboost-cpu==3.4.1. Same sklearn-style and native APIs, tiny download next to the ~49-57 MB full wheels, no CUDA kernels on disk. The full package runs on CPU too; you just paid for GPU code you will never execute.

Will old models break on 3.4.x?

Most JSON/UBJ checkpoints load. People get surprised by the 3.4.0 removals: column-split gone, federated plugin absent from wheels. If training code still points at those paths, fix the code – the file format is not the whole story. After upgrade, one hold-out predict pass is cheaper than debugging silent metric drift from the quantile/MAE leaf revisions.

Open a terminal, make the venv, pin xgboost==3.4.1 (or cu12/cpu), print __version__ and build_info(). That is the whole next step.