9.1 Version and build information🔗ℹ

xgboost-version returns the linked XGBoost version string, and xgboost-build-info returns the build configuration as JSON (compiler flags, CUDA support, and so on):

(require xgboost)

(xgboost-version)      ; e.g. "2.1.0"

(xgboost-build-info)   ; JSON string

9.2 Process-global configuration🔗ℹ

XGBoost keeps some settings at process scope. Read and write them as JSON with xgboost-get-global-config and xgboost-set-global-config!. A common pattern is to save, change, then restore around a region of code:

(define saved (xgboost-get-global-config))

(dynamic-wind

void

(lambda ()

(xgboost-set-global-config! "{\"verbosity\":0}")

; ... quiet work ...

(void))

(lambda ()

(xgboost-set-global-config! saved)))

xgboost-register-log-callback! installs a process-global callback that receives XGBoost’s log messages as strings. Because it is process-global, treat it as shared mutable state.

9.3 Full-state snapshots🔗ℹ

save-model persists only the trained trees. A snapshot additionally captures XGBoost’s internal training caches, so a restored booster can resume per-iteration updates in lockstep with the original. booster->bytes serializes that full state and bytes->booster reconstructs it:

(train-rounds! booster dtrain 0 5)            ; train 5 rounds

(define snapshot (booster->bytes booster))

(define restored (bytes->booster snapshot))

; both continue identically from round 5

(train-rounds! booster  dtrain 5 5)

(train-rounds! restored dtrain 5 5)

A booster restored from a snapshot has an empty DMatrix cache, so pass the training data explicitly when you resume with booster-update-one-iter!.

9.4 GPU training🔗ℹ

When the native library is built with CUDA, training runs on the GPU by setting "device" to "cuda" (with "tree_method" "hist"). Check availability first with cuda-available? so code degrades gracefully on CPU-only builds:

(when (cuda-available?)

(train dtrain

#:params '((device      . "cuda")

(tree-method . "hist"))

#:objective "reg:squarederror"

#:rounds 50))

Whether cuda-available? is #t depends on the native build: the package prefers a CUDA-enabled library on Linux when one is present and falls back to the CPU build otherwise.