fvcore: the shared computer vision toolkit behind Detectron2 and SlowFast

What it actually is: shared plumbing, not a model

`fvcore` describes itself as a light-weight core library holding the functionality common to computer vision frameworks built at FAIR. The README names its consumers explicitly: Detectron2, PySlowFast and ClassyVision. Read that as a dependency list rather than a marketing line. When three frameworks of different scope and different release cadences all import the same flop counter and the same scheduler, the counter has been tested against architectures nobody designed it for, which is a better durability argument than any number of internal unit tests.

The repository also makes a quality claim worth repeating verbatim in spirit: all components are type-annotated, tested and benchmarked. Type annotations in a research library matter more than they do in application code, because research code gets read months later by someone who did not write the config that produced it, and an unannotated helper that silently expects a dict of a particular shape costs an afternoon.

Maintenance is attributed to the computer vision team at FAIR rather than to a named maintainer list, and the license is Apache 2.0. For a library sitting underneath a detection stack, the license matters: Apache 2.0 carries an explicit patent grant, which is the part that matters when a piece of shared infrastructure ends up inside a commercial product built on top of a public research framework.

Five features, and only one of them is about speed

The README's feature list is short enough to quote, which makes the omissions informative. Alongside the basic utilities, fvcore ships common PyTorch layers, functions and losses in `fvcore.nn`. Then it lists four tools that are more than conveniences.

The first is a hierarchical, per-operator flop counting tool, with the implementation notes in `docs/flop_count.md`. The word per-operator is doing real work there. A single scalar flop total tells you that a model got more expensive; a per-operator breakdown tells you which module to look at. The second is recursive parameter counting, which walks a module tree rather than asking you to pass every submodule by hand. The third recomputes BatchNorm population statistics, exposed as `update_bn_stats`. The fourth is a stateless, scale-invariant hyperparameter scheduler in `fvcore.common.param_scheduler`.

Notice that none of the four is a model, a dataset or a training loop. This is a deliberate boundary. Anything that grows into a framework starts carrying opinions about your experiment, and opinions are what make shared research code hard to depend on. BatchNorm recalculation sits at the edge of that boundary, and it is arguably the most practically useful entry in the list for anyone fine-tuning a pretrained detector on a new domain, because the running mean and variance in a checkpoint describe the original data and nothing else.

Four installation routes, and they are not equivalent

fvcore requires PyTorch and Python 3.6 or newer. The README then gives four ways to install, and picking between them is a real decision rather than a formality.

The first three target the continuously built channel:

pip install -U fvcore
conda install -c fvcore -c iopath -c conda-forge fvcore
pip install -U 'git+https://github.com/facebookresearch/fvcore'

The PyPI and git routes are described as updated nightly, which means the version you get is a moving target rather than a fixed release. That suits a research group tracking upstream, and it suits nobody who needs a reproducible environment for a paper or a production inference job. There is also no tag list to choose from, since the material for this repository carries no published releases, so the choice is between tracking master or freezing a commit yourself.

The fourth route is a local clone, and it is the one to use when you intend to read the code rather than only call it:

git clone https://github.com/facebookresearch/fvcore
pip install -e fvcore

Note that the editable install points at the `fvcore` directory, which is both the package directory and the repository name. That is unusual enough to be worth checking after installation, since an editable install against the wrong path produces an import that silently resolves somewhere else.

The dependency list tells you what you are signing up for

`setup.py` is more informative than the README on installation weight. The runtime requirements are numpy, yacs, pyyaml, tqdm, termcolor, Pillow, tabulate and iopath, with a declared floor on several of them: yacs at 0.1.6, pyyaml at 5.1, termcolor at 1.1 and iopath at 0.1.7. There is also a conditional requirement on the dataclasses backport for Python below 3.7, which is the tell that the project still supports the 3.6 line it advertises.

Only one optional extra is declared, an `all` group pulling in shapely, and shapely is a geometry library, so its presence points at the parts of fvcore that work with polygons rather than tensors. If your use is flop counting and parameter counting, shapely is not needed and you can skip the extra.

The dependency list also predicts the shape of the API. yacs is a configuration system built around typed, nested config objects, and it shows up in the signature style of the scheduler and the config helpers. tabulate and termcolor appear in the table and progress output respectively, so the logging in this library is meant to be read by a person watching a training run. Pillow and iopath together handle image loading through a path abstraction, which is the part of fvcore that overlaps with Detectron2's own data loading rather than replacing it.

None of this is heavy in the way a full framework is, but it is not a single-file drop-in either. Budget for the install before you decide to vendor the one function you actually wanted.

A nightly build that edits your source file

The version logic in `setup.py` is the most surprising thing in a file this short, and it is worth reading before you wire fvcore into any pipeline that pins versions.

`get_version()` opens `fvcore/__init__.py`, scans for the line beginning with `__version__`, and splits on `=` to extract the value. If the environment variable `BUILD_NIGHTLY` is set to 1, it takes today's date, formats it as a compact eight digit string, and appends it as a `.post` suffix, producing a version that sorts after the release it was built from. It then rewrites `__init__.py`, dropping the existing version line and appending the new one.

The comment explains the ordering intent: pip can compare a `.post` suffix numerically, so a build such as `1.1.post1234` is correctly treated as newer than `1.1`. The rewrite is done so the built artifact reports the nightly version rather than the release version.

The practical consequence is that running the documented nightly build command in a working tree modifies a tracked source file. If your process asserts that a clean tree means a clean build, that assertion will fail on the version line, and it will fail in a way that looks like an accidental edit rather than an intended one. The supported path is to treat the tree as dirty during packaging, or to run the nightly build from a throwaway copy. It is a small thing, and it is exactly the kind of thing that costs an afternoon if you hit it during a release.

What the repository layout says about what is public

The top level of the repository is short: `fvcore/`, `docs/`, `tests/`, `io_tests/`, `packaging/`, `setup.py`, `setup.cfg`, `linter.sh`, `.flake8`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md` and a `.github/` directory.

Three entries in that list are load bearing for how much you can trust a change. A separate `io_tests/` directory means input and output paths get their own test suite rather than being incidental assertions inside unit tests, which is consistent with a library whose job includes reading files and whose failure mode is a confusing error deep inside someone else's training script. `linter.sh` alongside `.flake8` means style is checked by an invoked script rather than left to whatever the contributor has configured, so formatting complaints in review are mechanical rather than editorial. And `docs/` exists as a first class directory, which is where `flop_count.md` lives.

The presence of `packaging/` is worth noting against the nightly scheme described above. It suggests packaging is handled by more than the bare `setup.py`, so if you are reproducing a build it is worth looking there rather than assuming the sdist command in the `setup.py` comment is the whole story.

The last push recorded for the repository is dated 19 August 2026, and it is not archived. That is a fact about the snapshot rather than a promise about maintenance, and it is the kind of thing worth re-checking yourself if you are about to depend on it, because a shared internal library can go quiet without being marked archived.

Editorial conclusion

fvcore earns its place in the stack for the parts that every vision project otherwise reimplements badly. The flop counter decomposes per operator rather than reporting one number, so a regression in a model shows up as a change in a named layer instead of a vague increase. Recomputing BatchNorm statistics matters for anyone transferring weights between domains, since the running statistics that ship with a checkpoint describe the original training distribution. The scheduler is stateless and scale invariant, which is the behaviour you want when resuming from a checkpoint and when sweeping batch sizes. What you give up by depending on it is a heavier install than a single module would need: numpy, Pillow, tabulate and iopath come along whether or not you touch the flops code, and Python support is declared as 3.6 or newer. The four install routes in the README cover nightly and pinned use, and the local clone path is the one to use if you intend to read the sources rather than just call them.

Frequently asked questions

Official sources

1. facebookresearch/fvcore on GitHub
2. Issues
3. License: Apache-2.0
4. README