Ultralytics YOLOv3: a PyTorch take on the classic detector, with export tooling attached

What Ultralytics YOLOv3 is for, and who actually needs it

YOLOv3 frames detection as a single regression problem: bounding boxes and class probabilities come out of one forward pass over a full image. That is the framing the README states, and it explains why the model family stayed popular for latency-sensitive work long after newer detectors appeared. This repository packages three variants: YOLOv3, YOLOv3-SPP and YOLOv3-tiny. The tiny variant is the one to look at when inference has to fit on modest hardware; SPP adds a spatial pyramid pooling block to the head, which changes accuracy and cost.

The audience is narrower than the topic list suggests. If you are starting a detection project from scratch in 2026, nothing here argues you should pick YOLOv3 over a later generation. The people who get real value are those reproducing published YOLOv3 results, comparing a small detector against a modern one on their own data, or maintaining a codebase that already speaks YOLOv3 weights and needs a PyTorch path to them. The repository also reuses shared utilities from the ultralytics package, so anyone already inside that ecosystem will recognise the training and validation entry points.

How the repository is put together

The top level is deliberately flat and script-oriented: train.py, val.py, detect.py, export.py and benchmarks.py sit next to models/, utils/, data/ and hubconf.py. That layout tells you the intended workflow is running scripts from a clone rather than importing a library. The pyproject.toml says as much: most users run YOLOv3 directly from a repository clone with dependencies from requirements.txt.

hubconf.py is what makes torch.hub.load("ultralytics/yolov3", ...) work, exposing the three model names. The dependency list is short but not self-contained: requirements.txt pins torch>=1.8.0, torchvision>=0.9.0, opencv-python>=4.6.0, and pulls in ultralytics>=8.4.132 for the training and utility layer, plus ultralytics-thop>=2.1.6 for FLOPs and parameter counts. Export backends are commented out by default (coremltools, onnx, onnx-simplifier), so an export run needs those installed first. This is a thin wrapper around a shared framework plus three model definitions, not a standalone package with its own release cadence.

Installing YOLOv3 and running a first detection

The README's install path is a clone plus a requirements install, in a Python>=3.8.0 environment with PyTorch>=1.8. There is no pip package for the models themselves; the pyproject.toml exists, but the documented route is the clone.

# Clone the YOLOv3 repository
git clone https://github.com/ultralytics/yolov3

# Navigate to the cloned directory
cd yolov3

# Install required packages
pip install -r requirements.txt

After that, the fastest check is PyTorch Hub. Weights download automatically on first use, and the model name selects the variant.

import torch

# Load a YOLOv3 model (choices: 'yolov3', 'yolov3_spp', 'yolov3_tiny')
model = torch.hub.load("ultralytics/yolov3", "yolov3", pretrained=True)

# Run inference on an image (local file, URL, PIL image, OpenCV frame, or numpy array)
results = model("https://ultralytics.com/images/zidane.jpg")

# Inspect the results
results.print()  # print detections to the console
results.show()  # display the annotated image
results.save()  # save the annotated image to runs/detect/exp

results.print() writes detections to the console, results.show() opens the annotated image, and results.save() writes it under runs/detect/exp. If you prefer a command line, detect.py covers the same ground and accepts a webcam index, an image, or a video file as --source, saving output to runs/detect. The README's examples use --weights yolov3.pt, which means the weights file has to be present or downloadable in your environment.

Where this repository stops being the right answer

The release history is the first warning. The most recent release listed is v9.6.0 from 2021-11-14, described as a YOLOv5 v6.0 release compatibility update. The two before it, v9.5.0 and v9.1, are also compatibility updates tied to YOLOv5 versions. Nothing in that list suggests new detector work. The last push to the repository was on 2026-09-10, and the repository is not archived, so the code is being touched, but the release notes do not describe feature development in the model family.

The second issue is dependence on the ultralytics package. requirements.txt asks for ultralytics>=8.4.132, an open lower bound. That package moves; this repository's model definitions and utility calls have to keep matching it. A future ultralytics release that changes an internal API can break training or validation here without any commit to this repository. Pinning the version in your own environment is the obvious mitigation, and the README does not discuss it.

Finally, YOLOv3 is simply older. If your accuracy target was set by a newer detector, no amount of tooling around YOLOv3 will close that gap. The export tooling is the reason to stay, not the detector itself.

YOLOv3 against Darknet and against newer YOLO generations

The most direct alternative is the original Darknet implementation, which is where the YOLOv3 weights people search for come from. The difference is the runtime and the workflow. Darknet is C with its own configuration format and its own training loop; this repository is Python on top of PyTorch, so training, validation and export share one codebase and one set of data-loading utilities. If your deployment already runs PyTorch, or you need to hand a model to an export pipeline for ONNX, CoreML or TensorRT, the PyTorch path here removes a conversion step that Darknet would require. If you want the reference implementation and nothing else, Darknet is the shorter route.

The other comparison is against newer YOLO generations, which the ultralytics package also covers. Those models are the reason this repository's releases read as compatibility updates rather than improvements. Choosing between them is a question about your accuracy and latency budget, not about which repository has better tooling: the tooling is largely shared. Where this repository wins is when the specific YOLOv3, YOLOv3-SPP or YOLOv3-tiny architecture is the thing you need, for a paper comparison or a legacy interface.

Maintenance, licensing and the cost of staying on this branch

The last push was on 2026-09-10, so the repository is not abandoned, but the release list stops at 2021. Treat maintenance here as compatibility upkeep rather than model development, and budget accordingly: the work you will do is pinning dependencies and re-testing after ultralytics updates, not adopting new features.

The licence is AGPL-3.0, stated in pyproject.toml and in the repository's LICENSE file. That matters more than usual for a detector, because AGPL obligations attach to software offered over a network, not only to distributed binaries. The README points commercial users to an Enterprise License at Ultralytics Licensing. This is not legal advice, and whether your deployment triggers those obligations is a question for your own counsel. The practical point is that the licence, not the model, is often the deciding factor for teams embedding a detector in a product.

Editorial conclusion

Adopt it if you need a YOLOv3 baseline in PyTorch, want the tiny and SPP variants side by side, or need to export to ONNX, CoreML or TensorRT from a maintained clone. Do not adopt it if your project needs the newest detector generation or if AGPL-3.0 does not fit your distribution model. Before committing, verify that torch.hub.load can fetch the yolov3, yolov3_spp or yolov3_tiny weights in your environment, and check that your export target appears in your own run of export.py rather than in a blog post.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. ultralytics/yolov3 on GitHub