INFTY wraps a base optimizer in a continual-learning layer instead of replacing it

The core idea is a wrapper, not a replacement optimizer

INFTY is described as a flexible and user-friendly optimization engine tailored for Continual AI, and the parenthetical in the README is the key design statement: existing libraries treat optimizers as defaults configuration.

The way INFTY differs is visible in the custom usage section. The base optimizer is still yours, built with optim.SGD, and INFTY wraps it:

from infty import optim as infty_optim

base_optimizer = optim.SGD(
                filter(lambda p: p.requires_grad, self._network.parameters()), 
                lr=self.args['lrate'], 
                momentum=0.9, 
                weight_decay=self.args['weight_decay']
            )
optimizer = infty_optim.C_Flat(params=self._network.parameters(), base_optimizer=base_optimizer, model=self._network, args=self.args)

So the entry point takes three things: the parameters, the base optimizer you already built, and the model. That shape is what makes it portable. You are not asked to adopt an INFTY training loop, you are asked to replace one line where you construct your optimizer.

The second step in that section is that you implement a create_loss_fn function which returns a closure that calculates the loss. The wrapper needs a way to evaluate the objective, and the closure is how you give it one.

The features list frames the design in three words. Generality, with built-in continual learning friendly optimization algorithms across a wide range of scenarios, models, methods and learning paradigms. Usability, described as a portable, plugin-style design that allows easy replacement of fixed options inside existing pipelines. And utilities, with built-in diagnostic visualization tools for investigating optimization behaviour.

Three algorithms, mapped to three distinct failure modes

The README states that INFTY has implemented three mainstream algorithms currently, and the case descriptions are more informative than the count.

The first category is generalizability support, which promotes unified and flat loss landscapes to enhance adaptation across tasks over time. The README notes these methods can be applied to most architectures and training platforms, either from scratch or with pre-trained models, and points at the C_Flat paper.

The second is backpropagation-free support, which focuses on gradient approximation when backpropagation is not feasible. The README recommends combining these with pre-trained models to get better initialisation and faster convergence, and points at ZeroFlow.

The third is multi-objective support, which mitigates gradient interference between old and new task objectives, with gradient manipulation applied solely to shared parameters, and points at UniGrad_FS.

That third one is the most interesting for a practitioner, because it describes the actual continual learning pathology. When a model learns a new task, the gradients for the new objective collide with the ones that preserved the old tasks, and the damage is concentrated in the parameters that serve both. Applying the correction only to the shared parameters is a targeted intervention rather than a global one.

The three algorithms map onto three different reasons a continual learning run goes wrong, and the case section is still marked as ongoing updates.

The scenarios span classification, diffusion and vision-language models

The case section is organised by scenario rather than by algorithm, and that is where the scope of the project becomes clear.

Scenario 1 is typical continual learning, and the three cases above sit under it. Scenario 2 is continual text-to-image diffusion, where the README says INFTY empowers CIDM, with a tiny demo showing how it can be applied to train Concept-Incremental text-to-image Diffusion Models, and points at the CIDM origin repository.

Scenario 3 is vision-language continual learning, described as support for multi-modal continual learning, ready for VLMs and AVLMs, with the origin repository given as DMNSP.

That third scenario comes with a results table in the README comparing DMNSP against the same method with INFTY added, over ten tasks with an average column, and the README bolds the better number in each row. The averages are close, 87.61 against 87.85, and in several columns the INFTY variant is not the higher one. That is worth reading carefully rather than as a marketing claim, since the honest summary is that the gain is small and uneven.

The compatibility list in the introduction names the broader surface: various continual AI settings such as parameter-efficient tuning based continual learning, continual PEFT, continual diffusion and continual VLM, and diverse models such as ResNet, Transformer, ViT, CLIP and Diffusion.

The initial version of INFTY has been released, with a note that the pre-print is still to be updated, and the documentation site is linked from the badges along with the PyPI package, the arXiv identifier 2508.18860 and PyTorch.

Two install routes, and the launcher scripts need an extra

Installation is either from PyPI or from source, and the two routes differ in a way that matters for the launcher scripts.

pip install infty

Or from a source checkout, in a dedicated conda environment:

conda create -n infty python=3.8

conda activate infty

git clone https://github.com/THUDM/INFTY.git

cd infty && pip install .

The quick start then needs the extras:

cd infty 

pip install ".[examples]"

bash workdirs/scripts/run_memo_cflat_esd_full.sh
bash workdirs/scripts/run_ease_zo_all_parallel.sh
bash workdirs/scripts/run_wa_conflicts_all_parallel.sh

mkdir -p ../scripts

The scripts come from the PILOT repository, and hyperparameters for the specific methods live in the configuration files under workdirs/infty_configs/. The script names indicate what each one runs, with a full run for one method, a zoo of optimizers in parallel, and a conflicts variant in parallel.

The extras themselves are substantial, and they are worth reading before you install. The examples extra pulls in easydict, Pillow, PyYAML, scikit-learn, a pinned timm at 0.6.13 and umap-learn, and the pinned timm version is the kind of detail that will decide whether your existing code runs without changes.

The runtime dependencies are lighter: torch at 2.4.0 or newer, torchvision, numpy, matplotlib, scipy, seaborn and tqdm. The package requires Python 3.8 or newer and the classifiers list Python 3.8 through 3.11.

Public beta, and the split between the package API and the workdirs

The status line in the README is specific and worth reading twice. INFTY is in public beta, the documented APIs under infty.optim and infty.plot are intended for real-world experimentation and stable incremental releases, and experiment scripts and benchmark integrations under workdirs/ may evolve faster than the public package APIs.

That is an unusually clear statement of which parts you can depend on. The two names it names, infty.optim and infty.plot, are the contract. Everything in workdirs/ is a laboratory, and the launcher scripts in the quick start live there.

The release history supports the reading. There is one published release, v0.1.2 on 2026-05-21, and the version in pyproject.toml is also 0.1.2, with the classifier Development Status :: 4 - Beta. The last push was on 2026-09-01 and the repository is not archived.

The packaging is a src/ layout with setuptools, so the import name is infty even though the repository is INFTY. The build backend is setuptools.build_meta requiring setuptools 45 and wheel, and the package discovery is rooted at src/.

The documentation infrastructure is a small project of its own. There is a mkdocs.yml, a Makefile.docs, a sphinx_docs/ directory, a theme_overrides/ directory, requirements-docs.txt, a .readthedocs.yml and a DOC_SITE_SETUP.md, along with a bootstrap_doc_site_repo.sh script, which suggests the docs are generated into a separate repository rather than served from the source tree.

The licence is MIT, recorded in the pyproject.toml and with a LICENSE file at the root, so the code carries no copyleft obligation. That is a licensing note rather than legal advice, and it does not cover the pre-trained models or datasets you bring to it.

Where a plain optimizer plus a replay buffer is the better trade

The obvious wrong-tool case is a problem with a single task, or a small number of tasks, where the machinery of continual learning is not what is holding you back. If your model does not forget because you are not actually training it sequentially, wrapping the optimizer adds a layer you do not need.

The second case is a research question that has already been answered. INFTY is an aggregation of three published methods, and the README links each one to its paper. If you need to reproduce a specific result, using the original method directly gives you the original code and the original hyperparameter search, and INFTY is a reimplementation that has been given a different set of defaults.

The third case is a hard constraint on environments. The dependencies are torch, torchvision, numpy, matplotlib, scipy, seaborn and tqdm, and the examples extra adds a pinned timm at 0.6.13, which is an old pin. A pinned old version of a model library is a common source of conflicts with the rest of your stack, and the README does not explain why that version was chosen.

The alternative in the same space is to implement the method you need as a small optimizer subclass yourself, or to use an existing continual learning framework that already has a training loop and the replay or regularisation you need. The difference in approach is that INFTY sits at the optimizer level and leaves your loop alone, which is a genuine advantage when you already have one, and a limitation when you do not.

The most important thing to verify before adopting it is scope. Three algorithms covering three failure modes is a starting set, not a toolkit in the general sense, and the case section is explicitly marked as ongoing updates.

Editorial conclusion

Adopt INFTY if you are doing continual learning on PyTorch and want to try the published methods without rewriting your training loop, since it wraps the optimizer you already use. Do not adopt it as a stable dependency, because the package is at 0.1.2 in public beta and the README warns that anything under workdirs/ may change faster than the public API. Verify first that your scenario is covered by the three implemented methods, that the pre-trained model path works for your setup, and that the diagnostic plotting utilities under infty.plot give you what you need, since those are the parts the project treats as stable.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. THUDM/INFTY on GitHub