ultralytics/yolov3: The Classic Detector, Packaged for PyTorch Pipelines
PyTorch implementation of YOLOv3, YOLOv3-SPP, and YOLOv3-tiny for real-time object detection with training, validation, inference, and multi-format export.
At a glance
- What is it?
- Ultralytics maintains a PyTorch implementation of YOLOv3, YOLOv3-SPP and YOLOv3-tiny with training, validation, inference and export tooling, shared utilities pulled from the ultralytics package, and an AGPL-3.0 licence. It is a reasonable choice if you specifically need the v3 architecture and its export paths; it is the wrong choice if you want current model accuracy.
- Who is it for?
- Adopt ultralytics/yolov3 if you need the v3 architecture specifically, have an existing pipeline built around its weight files or export targets, or want a small detection model you can fine-tune on a custom dataset. Do not adopt it if you are starting fresh and only care about accuracy per unit of compute, since the same maintainer ships newer architectures.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What ultralytics/yolov3 actually packages
YOLOv3 frames detection as a single regression problem: the network predicts bounding boxes and class probabilities directly from a full image in one forward pass, rather than proposing regions and classifying them in separate stages. That is the framing the README gives, and it is the reason the family is associated with real-time use.
This repository is not a new model. It is a maintained home for three classic detection models (YOLOv3, YOLOv3-SPP and YOLOv3-tiny) plus the surrounding tooling: training, validation, inference and export. It also reuses shared utilities from the separate ultralytics package rather than vendoring everything locally, which matters when you try to reason about what a bug fix will and will not reach.
The audience is narrow and specific. You are fine-tuning a detector on your own labelled data, or running a pretrained checkpoint over images and video, or exporting weights into a runtime format for edge deployment. The topics list on the repository names the same set of concerns: computer-vision, deep-learning, inference, model-export, model-training, object-detection, and the runtimes onnx, tensorrt and coreml, alongside edge-ai.
The three model variants and what separates them
The repository exposes three choices, named in the README as 'yolov3', 'yolov3_spp' and 'yolov3_tiny'. The naming is the whole selection interface: the PyTorch Hub entry point takes one of those strings.
The tiny variant is the one to reach for when the deployment target is constrained. It is the smallest of the three and the one most likely to be paired with an edge runtime, which is consistent with the edge-ai topic and the export targets listed. The SPP variant adds a spatial pyramid pooling block to the base architecture, a change that alters the receptive field behaviour of the network. The README does not quantify any accuracy or latency difference between the three, and I am not going to invent one. If you need to choose between them for a specific task, the honest answer is that you have to measure on your own data.
What the repository does give you is a single code path for all three. Training scripts, validation scripts and export scripts are shared, so switching variants is a matter of changing a model name rather than rewriting a pipeline. That consistency is the practical value of the packaging.
Installation and the pinned dependency floor
The install path is short. Clone the repository, change into it, install from the requirements file:
git clone https://github.com/ultralytics/yolov3 cd yolov3 pip install -r requirements.txt
The README states the environment requirement as Python>=3.8.0 with PyTorch>=1.8. Those are floors, not pins, and that distinction is where most installation trouble will come from. PyTorch has moved a long way since 1.8, and a requirements file that expresses only a lower bound will happily pull in whatever the resolver considers current. If you are installing into an existing environment with a different torch build, expect to spend time on the resolver before you spend time on detection.
There is also a Docker image published under the ultralytics/yolov3 name, referenced by a badge in the README, and a Colab notebook linked from the top of the repository. Neither is described in the excerpted material beyond their existence, so treat them as starting points to inspect rather than as documented workflows.
Inference through PyTorch Hub versus detect.py
There are two entry points, and they suit different jobs.
The first is PyTorch Hub. The README gives this example:
import torch model = torch.hub.load("ultralytics/yolov3", "yolov3", pretrained=True) results = model("https://ultralytics.com/images/zidane.jpg")
Weights download automatically on first use. The model call accepts a local file, a URL, a PIL image, an OpenCV frame or a numpy array, which is what makes this path useful inside an existing Python service: you can hand it a frame you already decoded rather than writing to disk first. Results expose print(), show() and save(), with save() writing annotated output to runs/detect/exp.
The second is the command line script. The README shows the pattern:
python detect.py --weights yolov3.pt --source 0 python detect.py --weights yolov3.pt --source img.jpg python detect.py --weights yolov3.pt --source vid.mp4
with --source 0 meaning webcam. Output goes to runs/detect. The script downloads models automatically. My read is that detect.py is the faster path for one-off inspection and batch jobs over a directory of files, while the Hub route is the one to embed. The repository does not present them as interchangeable, and the fixed output directory convention in both cases is worth knowing before you run anything in a directory you care about.
Export targets and the deployment story
Export is where this repository earns its keep for edge work. The topic list names onnx, tensorrt and coreml, and the description states multi-format export as a first-class capability alongside training, validation and inference. The practical consequence is that a model trained here does not have to be served by PyTorch.
That matters because the tiny variant plus a runtime-specific export is the combination people actually deploy. A Core ML export puts the model into an Apple device pipeline. A TensorRT export targets NVIDIA inference. ONNX sits in the middle as the interchange format most other runtimes accept.
What the material does not give is any statement about which export formats are fully supported versus experimental, or what precision each export produces. Those are exactly the details that determine whether an export is usable, and they are not in the README excerpt. Verify them against the documentation site before you build a deployment plan around a specific format. I would treat the export feature as real but under-specified here.
Release cadence and what the version numbers tell you
This is the section to read carefully before adopting.
The three most recent releases are v9.6.0 (2021-11-14), described as a YOLOv5 v6.0 release compatibility update for YOLOv3; v9.5.0 (2021-04-12), a YOLOv5 v5.0 compatibility update; and v9.1 (2021-01-13), labelled YOLOv5 forward compatibility updates. Every one of those release notes describes compatibility work with a sibling project, not new detection capability. The last push timestamp on the repository is 2026-09-10, so the code is being touched, but the tagged releases have not moved in years.
That combination is the central fact about this project. It is maintained in the sense that it receives commits and shares utilities with the ultralytics package. It is not evolving in the sense that the model itself is getting better. Anyone adopting it should assume the architecture is frozen and plan accordingly: pin a commit, pin your torch version, and do not expect the accuracy ceiling to move.
There is a second-order risk in the shared-utilities design. Because the repository reuses code from the ultralytics package, a change over there can affect behaviour here without a corresponding release. Pinning the repository alone may not be sufficient to reproduce a result.
AGPL-3.0 and the commercial licence route
The repository is licensed AGPL-3.0. The README states plainly that commercial use requires an Enterprise License, requested through the Ultralytics licensing page.
AGPL-3.0 is a copyleft licence with a network-use clause. For a project that is itself open source under a compatible licence, that is unremarkable. For a company embedding the detector inside a closed product, or exposing it as part of a hosted service, the obligation is the thing to resolve before writing code, not after. The README's own pointer to an enterprise licence is the clearest signal that the maintainer expects this question to come up.
I am not giving legal advice and cannot assess your situation. The concrete step is to determine whether your use triggers the network clause and, if it does, whether an enterprise licence or a differently licensed implementation is the better answer. The licence identifier is AGPL-3.0; that is the fact to take to whoever handles this for you.
When a different detector is the better answer
The honest alternative is not a different YOLOv3 fork. It is a newer architecture from the same maintainer, which is what the release notes themselves point at: every recent tagged release of this repository is described as a compatibility update for a YOLOv5 release. That tells you where development effort went.
The difference in approach is not superficial. YOLOv3 is the architecture this repository implements, with the three variants described above and the export paths built around them. The newer line is a different set of model definitions, and adopting it means a different set of weight files, a different training configuration surface, and a different compatibility matrix with the runtimes you export to. If your only requirement is detection accuracy on a modern dataset, there is no reason to start with v3.
Where v3 still makes sense is when something downstream is pinned to it. An existing exported model in a shipped product. A benchmark you need to reproduce against published v3 numbers. A very small model budget where the tiny variant's size is the constraint you are optimizing against. Those are legitimate reasons. 'It is what I found first' is not, given that the same organisation publishes the successor.
Editorial conclusion
Adopt ultralytics/yolov3 if you need the v3 architecture specifically, have an existing pipeline built around its weight files or export targets, or want a small detection model you can fine-tune on a custom dataset. Do not adopt it if you are starting fresh and only care about accuracy per unit of compute, since the same maintainer ships newer architectures. Before committing, verify that the release you pin still resolves against your installed PyTorch and that your intended export target is covered, because the most recent tagged release predates several years of upstream changes.
Community notes