Universal model loading

mata.load(task, source) and mata.run(task, image, model=...) take the same argument in every form a model can arrive in. The task — detect, segment, classify, depth, ocr, track, vlm, embed, barcode, recognize — decides which adapter family is needed; the source decides which runtime runs it.

Nothing above that line knows the difference. A detector loaded from a hosted checkpoint and a detector loaded from a file on the machine return the same result objects, with the same bounding-box format and the same per-instance labels.

The loader reads the source string and resolves it through a fixed order of checks, so there is no ambiguity between a name and a path.

• A named alias from .mata/models.yaml (project-local) or ~/.mata/models.yaml (user-global), which can carry per-task defaults such as a detection threshold.
• A file on disk — .onnx, .pt, .pth, .bin, .trt or .engine — loaded through ONNX Runtime or TorchScript.
• A torchvision/ name such as torchvision/retinanet_resnet50_fpn or torchvision/ssd300_vgg16.
• A known engine name: easyocr, paddleocr, tesseract, pyzbar, zxing.
• A HuggingFace model ID containing a slash, such as facebook/detr-resnet-50 or IDEA-Research/grounding-dino-tiny.

Not every runtime covers every task, and MATA states the matrix plainly rather than failing halfway through a load.

• PyTorch — the full task set: detection, segmentation, classification, depth, OCR, tracking, VLM and embedding.
• ONNX Runtime — detection, classification and embedding.
• TorchScript — detection and classification.
• Torchvision — detection.
• Native engines for barcode and QR decoding: pyzbar and zxing-cpp.

The tasks you intend to run decide which formats the machine needs — nothing else about the pipeline has to change.

Models are addressed by name wherever a string is accepted — in Python, in the CLI, and in the provider map of a graph. Teams keep a catalogue in .mata/models.yaml and register aliases at runtime with mata.register_model() when the catalogue is assembled somewhere else.

A checkpoint that is not on a hub still loads: point the loader at the .pth file and give it the config and architecture it needs. Loading a model stays a catalogue entry rather than a code path.

Since v1.9.8, a first run that has to download weights says so, and lets the download progress reach the terminal instead of appearing to hang. Later runs are quiet again, with the local cache detected through is_model_cached().

Every adapter reports its load time when it finishes, for example "Model loaded on cuda (4.2s)", and mata.verbose(0) restores complete silence when a script needs it.

• First run without a cached model: "Downloading {model_id} (first run — this may take a minute)...".
• A load-time line from each adapter, for example 4.2 seconds on CUDA.
• Verbosity levels 0, 1 and 2 to control how much is printed.

Install with pip install datamata on Python 3.10 or newer, then load the first model from the CLI or from three lines of Python. There is no registration step and no build step before the first inference.

The CLI takes the same argument as the API, so a model can be tried from a terminal before it appears in a pipeline: mata run detect image.jpg --model facebook/detr-resnet-50 --conf 0.4 --save.