NVlabs RADIO with C-RADIOv4: PyTorch Vision Features

What RADIO solves for vision pipelines

NVlabs/RADIO addresses the need to represent an image with both a global summary and spatial information that retains the relationship between image regions. The repository describes its family as agglomerative vision foundation models. That wording matters for the intended user: RADIO is aimed at engineers and researchers who need a reusable visual encoder inside experiments, feature analysis systems, retrieval pipelines, segmentation work, or downstream model prototypes.

The repository presents C-RADIOv4 as a model family, including C-RADIOv4-H and C-RADIOv4-SO400M. The README says the teacher set was updated to SigLIP2-g-384, DINOv3-7B, SAM3, and other components. It also links research on RADIOv2.5, AM-RADIO, PHI-S, and FeatSharp. The code is an official PyTorch implementation, and the repository layout includes examples for nearest-neighbor classification, feature distribution, feature visualization, zero-shot ImageNet evaluation, video features, and model statistics.

This is a research-oriented visual representation project rather than a complete application with a command-line interface or a documented web service. The main interface shown in the README is Python code that loads a model through Torch Hub and calls it with a normalized image tensor.

C-RADIOv4 loading and tensor flow

The documented C-RADIOv4 path starts by selecting a model version and loading the `radio_model` entry point from `NVlabs/RADIO`. The returned model is moved to CUDA and switched to evaluation mode. An image is opened with PIL, converted to RGB, converted to a tensor, moved to CUDA, and scaled from the 0 to 255 pixel range into the 0 to 1 range that RADIO expects.

The README then selects a supported resolution with `get_nearest_supported_resolution` and applies bilinear interpolation. The model receives a batch dimension and returns two values named `summary` and `spatial_features`. By default, spatial features use an NLC layout, with the final dimension combining height and width. Passing `feature_fmt='NCHW'` produces the conventional four-dimensional image layout instead.

RADIO also performs internal normalization of the input range, as stated in the README. Applications that already have a preprocessing pipeline can request a preprocessor with `make_preprocessor_external`. In that mode, the model does not change the input. The caller applies the conditioner and passes `cond_x` to the model. This separation is useful when image normalization belongs in an existing data processing service rather than inside the backbone call.

For CUDA workloads, the README documents bfloat16 autocasting around the model invocation. It specifically calls this important for fast performance with self attention, but it does not provide a standalone CPU example or document compatibility for other accelerator types.

A first C-RADIOv4 image inference tutorial

The README does not document a separate `pip install` command for the project. It directs users to Torch Hub, so the first documented use is a Python process with the repository's model entry point available. The following example follows the README's loading, image preprocessing, supported-resolution selection, and inference sequence. It expects a CUDA device and the `assets/cradio_v4.png` file from the repository.

from PIL import Image
import torch
from torch.nn import functional as F
from torchvision.transforms.functional import pil_to_tensor

model_version = 'c-radio_v4-h'
model = torch.hub.load('NVlabs/RADIO', 'radio_model', version=model_version, progress=True, skip_validation=True, force_reload=True)
model.cuda().eval()

x = Image.open('assets/cradio_v4.png').convert('RGB')
x = pil_to_tensor(x).to(dtype=torch.float32, device='cuda')
x.div_(255.0)
x = x.unsqueeze(0)
nearest_res = model.get_nearest_supported_resolution(*x.shape[-2:])
x = F.interpolate(x, nearest_res, mode='bilinear', align_corners=False)
summary, spatial_features = model(x)

After execution, `summary` is the global representation and `spatial_features` contains the spatial representation in NLC format by default. The code also downloads model assets through the Torch Hub call. The README recommends `force_reload=True` at least once for users who have used RADIO through Torch Hub before, because the flag reloads the source code as well.

Spatial outputs, precision, and teacher adaptors

The feature-format choice is explicit. Passing `feature_fmt='NCHW'` is the documented option when downstream spatial handling expects height and width as separate dimensions. The README includes an assertion that checks the resulting tensor has four dimensions. This avoids making callers reverse-engineer whether the final dimensions represent token positions or image regions.

Mixed precision is also part of the public usage path. The documented call wraps inference in CUDA autocasting with bfloat16. It returns the same summary and spatial feature pair while changing the execution dtype. The README does not quantify memory use, latency, or accuracy changes, so those effects cannot be inferred from the project description.

C-RADIOv4 can load one or more teacher adaptors through `adaptor_names`. The example uses `siglip2-g`. With an adaptor loaded, the result is a dictionary. The `backbone` entry contains the usual RADIO features, while each loaded adaptor has its own summary and feature pair. The `siglip2-g` adaptor is documented as supporting text tokenization and encoding. The example tokenizes an image caption, encodes it with `normalize=True`, computes cosine similarity against the adaptor image summary, and prints the similarities. This makes the adaptor path relevant to tasks that need image-text alignment rather than only image embeddings.

The exact available adaptors depend on the selected model and the README says they may be specified through `adaptor_names`. It does not give a complete compatibility matrix for every checkpoint, so adaptor availability should be verified before it is treated as a stable interface.

Repository examples and maintenance constraints

The repository layout indicates a broad research workspace rather than a minimal package. Examples include `knn_classification.py`, `feature_distribution.py`, `visualize_features.py`, `zero_shot_imagenet.py`, `model_stats.py`, `position_predictor.py`, and video-feature tooling. The root also contains tests such as `test_example.py`, `test_hubconf.py`, `test_hf.py`, and `test_video_mode.py`. This gives users several concrete starting points, although the README excerpt does not document a setup command for running every example.

The repository is not archived, and its last push was on 2026-10-06. That supports treating the source as recently changed, but the repository has no GitHub releases. Consequently, there is no documented release-based upgrade path or tagged-version migration policy in the available repository description. The README uses model identifiers such as `c-radio_v4-h` and `c-radio_v4-so400m`, but does not present them as GitHub releases.

The licence status needs separate attention. The README badge displays `NC`, while GitHub classifies the repository licence as a custom licence that cannot be categorized. The repository includes a `LICENSE` file, and the README links NVIDIA Research licensing inquiries. The README does not support making a legal determination about commercial use, redistribution, or model weights. Check those files and the linked licence terms before incorporating the code or checkpoints.

Limitations and a concrete alternative

RADIO is a feature backbone with research examples, not a turnkey image-processing service. Its primary documented path depends on Torch Hub, CUDA, model downloads, and a repository image for the tutorial. The README does not document a package installation command, CPU inference recipe, container image, or a rollback procedure. A deployment requiring pinned local files and a conventional package manager would therefore need additional work beyond the documented usage.

A real alternative is to use a conventional single-purpose vision encoder in PyTorch and design the downstream representation directly for the task. That approach may be simpler when an application needs one global embedding, does not require RADIO's summary plus spatial output pair, and has no need for a teacher adaptor. The trade-off is that it does not provide the particular C-RADIOv4 model family or the documented adaptor path. RADIO is more relevant when its multi-output representation and research foundation-model setup are requirements, not merely convenient alternatives to a basic encoder.

Editorial conclusion

Researchers and engineers building image feature pipelines should evaluate RADIO when summary features, spatial features, multiple input resolutions, or teacher adaptors are useful. It is less suitable when a package-level offline installation, a conventional deployment pipeline, or a documented non-CUDA path is required. Verify first that the selected C-RADIOv4 checkpoint, adaptor dependencies, licence terms, and CUDA environment match the intended use. For a new CUDA workflow, the first check should be whether the Torch Hub loading example and the required model assets work in the target environment.

Frequently asked questions

Official sources

1. Issues
2. NVlabs/RADIO on GitHub
3. README