ChimeraBoost 0.30.0, AutoGluon 1.6 model API migration, and four model fixes

[LennartPurucker]

Closes #463.

ChimeraBoost 0.30.0

Bumps the pin to chimeraboost>=0.30.0 (info.py + pyproject.toml) for the re-run requested in #463. Pre-flight before spending cluster time: all 13 search-space parameters still exist in 0.30.0, and all 201 configs (default + 200 random) fit on binary/multiclass/regression. The only warning is the documented multiclass no-op for leaf_estimation_iterations. fit(cat_features=, eval_set=, callbacks=) and the cb(iteration, train_loss, val_loss, model) signature are unchanged, so the wrapper's time-limit callback still works.

Worth knowing for interpreting the results: 0.30.0's headline refit_full="replay" default is inert here by design. It only fires for fits that use ChimeraBoost's own internal split, and the wrapper passes AutoGluon's bagging validation fold as an explicit eval_set. Refitting on that fold would train on the rows whose predictions become the out-of-fold predictions used for scoring and ensembling.

AutoGluon 1.6 model API migration

AutoGluon 1.6 replaced a set of override methods with class attributes. Only _supported_problem_types is enforced, but FitHelper.verify_model raises on the old override, so pytest -m models was failing for 25 registry entries (20 classes) without ever reaching a model fit.

Override	Replaced by	Count
supported_problem_types()	_supported_problem_types	20
_get_default_resources()	default_resources_physical_cores_only + default_num_gpus	17
get_minimum_resources()	minimum_num_gpus	14
_get_default_ag_args_ensemble()	_default_ag_args_ensemble_extra	14
_get_default_auxiliary_params()	_default_auxiliary_params_extra	8

Also removes now-dead code: 15 _class_tags declaring only can_estimate_memory_usage_static (AutoGluon derives it from whether _estimate_memory_usage_static is implemented) and 9 _estimate_memory_usage methods that only forwarded to the static estimate (now the base default). 12 methods were deliberately left alone where the body reads the parent's resolved value via .pop() or branches on state.

Verified behaviour-neutral by snapshotting every registry model's memory-estimate and default-resolution behaviour to JSON before and after. Memory behaviour is identical across all 37 models. The one difference is that get_minimum_resources no longer returns num_gpus: 0 when no GPU is present; every consumer in AutoGluon core reads .get("num_gpus", 0), so absent and 0 are equivalent.

The add-model and benchmark-model skill docs are updated to teach the new API.

Four model fixes the migration uncovered

The supported_problem_types assertion fires before the model fits, so it had been masking real failures.

1. TabPFN-2.6 large data — _adjust_hyperparameters_for_large_data imported _get_v2_6_config and the v2_6_* preprocessor factories, which no longer exist: v2.6 checkpoints embed their own InferenceConfig, so those defaults were removed upstream. Any dataset above 70k rows and 300 features died with ImportError mid-fit. Now reads the checkpoint's own transforms via get_inference_config() and passes a dict override, so override_with_user_input_and_resolve_auto merges it and every unnamed field keeps the checkpoint's value. The shipped caps turn out to be 680/500, so capping to 300 preserves the original intent.

2. LimiX unpicklable encoder — _NaNCleanEncoder was defined inside a functools.cached factory, giving it the qualname _nan_clean_encoder_cls.<locals>._NaNCleanEncoder, which pickle rejects. Every fitted LimiX model was unpicklable, and bagging pickles each fold child back to the parent. Keeps the factory (its lazy-torch purpose is real), rewrites the qualname, and adds a module __getattr__ that resolves it. Verified to round-trip and to unpickle in a cold process that never called the factory, with torch still absent from sys.modules on import.

3. TabSwift single-vs-batched predictions — differed by ~2.4e-4 against a 1e-5 tolerance. Running FitHelper.verify_model with CUDA_VISIBLE_DEVICES="" passes with the check on, so this is float non-determinism in the CUDA kernels, not batch-dependent preprocessing. Adds verify_single_prediction_equivalent_to_multi to ModelSmokeTest and sets it False for TabSwift, with the CPU evidence recorded.

4. TabDPT — TabDPT_GPU runs the tabdpt1_1 checkpoint, whose architecture config has 8 keys and no enc_cell_dim; tabdpt 1.2.0's loader reads v1.2-only keys with no legacy branch. Not a stale cache: forcing an upstream revision check returned the same revision. Its pin is corrected to tabdpt<1.2 and it is marked superseded=True, a new ModelInfo flag that keeps a replaced entry's conflicting pin out of the installable extras and skips it in the smoke tests. TabDPT-Turbo is the current default and keeps >=1.2.0.

Test status

pytest -m models tests/tabarena/models/test_all_models.py: 24 passed, 12 skipped, 1 failed, against 23 passed / 11 skipped / 3 failed before this branch. LimiX and TabSwift now pass, TabDPT_GPU skips with an explicit reason, and the other 11 skips are missing optional dependencies in this environment.

The one failure is Mitra_GPU, which is pre-existing, flaky, and outside this branch:

• It is AutoGluon's own model (autogluon.tabular.models.mitra.mitra_model.MitraModel), not a TabArena wrapper, and nothing here touches it.
• It fails the same single-vs-batched prediction check as TabSwift, but on CPU as well as GPU, and by a larger margin on CPU (~8e-4 vs ~4.7e-5). So it is genuine batch-composition dependence, not CUDA float noise, and it deliberately does not get TabSwift's verify_single_prediction_equivalent_to_multi=False opt-out — that field is restricted to models proven to pass on CPU.
• Two identical GPU runs of that single test gave one pass and one failure, so it has been passing by luck rather than being newly broken.

Worth reporting upstream to AutoGluon separately.

Lint and format are clean on every file touched; the only ruff check error in the tree is the pre-existing PLR0917 in tests/tabarena/repository/test_repository.py.

🤖 Generated with Claude Code

[LennartPurucker]

FYI @bbstats, here is the PR for tracking the progress for #463

[LennartPurucker]

Closes #463

[mario-koddenbrock]

Independently reproduced this bug via LIMIX in a downstream benchmark (RamanBench) — pickling failed at AutoGluon's save_child() right after training completed, on both classification and regression, every run. Verified this fix (rewriting __qualname__ + module-level __getattr__) resolves it in both same-process and cold-process unpickling. Thanks for the fast turnaround.

[LennartPurucker]

@mario-koddenbrock let me know if it would help you if I merge this now. Otherwise, I am waiting for the runs to finish (by the end of day/tomorrow morning).

[mario-koddenbrock]

@LennartPurucker No, it's not urgent at all. Thanks :)

[LennartPurucker]

Here are the results, nice gains!