DeepDetect: a Torch training runtime that ships as both a CLI and a REST server

The problem DeepDetect takes on, and who it is built for

Most teams that train a model end up with two separate systems: one for training and one for serving. DeepDetect's answer is to keep both behind one API surface. The README describes it as a deep learning runtime, a command-line tool, and a REST server for training and inference, and says the focus is on practical model operations: create services, train models, run predictions, monitor jobs, and keep model repositories organised on the filesystem. That last item matters more than it reads. There is no database dependency in the model storage path, so a model repository is a directory tree, and moving a trained model between machines is a filesystem operation.

The audience is narrower than the topic list suggests. The CLI packages focused workflows for YOLOX object detection and SegFormer semantic segmentation, and the README names four first CLI profiles: yolox, segformer, torchvision-detector, and external-pytorch-detector. If your job is one of those four shapes, the CLI is the intended entry point. If it is not, you are working through the Torch API or the REST server, which is a different level of effort.

The supported data types are broad: images, text, CSV and tabular data, time series, sparse or SVM-style data, object-detection boxes, and segmentation masks. That breadth is the reason the project exists in this form. A team doing image classification and a team doing time series forecasting can use the same service model, the same repository layout, and the same JSON request and response payloads.

How the runtime, the CLI and the server fit together

There are two distinct Python surfaces and the README warns against confusing them. The Python wheel embeds the DeepDetect runtime in the current Python environment and provides the deepdetect CLI. The Python REST client under clients/python is a separate thing: it talks to a running DeepDetect server over HTTP. Installing the wheel does not give you a server, and installing the client does not give you a runtime.

The wheel itself has two mutually exclusive variants. deepdetect-cpu and deepdetect-gpu both provide import deepdetect, so they cannot coexist in the same environment. That is a packaging decision with a practical consequence: switching between CPU and CUDA work means rebuilding the environment, not toggling a flag. The GPU path is opt-in at the command level too, since the README says to add --gpu to the train and infer commands when running the GPU wheel.

On the backend side, Torch is the primary backend for both training and inference. TensorRT is available for optimised inference with exported or compatible models. The README is explicit that Caffe-format protobufs and prototxt files may appear as compatibility or model-format details, but Caffe is not an active runtime backend. Anyone arriving from an older DeepDetect deployment should read that sentence twice, because it changes what migration looks like.

Model storage is filesystem-based, and services are backed by local model repositories. Training jobs can run asynchronously and be inspected for status. The CLI emits structured events for automation alongside human-readable terminal output, which is the mechanism that lets the same command serve an interactive session and a pipeline.

Getting a first run: wheels, profiles and YAML configs

Installation is a pip command against a custom index. The README gives this example for the CPU wheel:

python -m pip install --extra-index-url https://www.deepdetect.com/download/wheels/simple deepdetect-cpu

The GPU variant substitutes deepdetect-gpu. After installation, three inspect commands show what the packaged CLI actually contains:

deepdetect inspect models deepdetect train yolox --help deepdetect infer segformer --help

Runs are driven by YAML config files, and the README is careful about them: the default examples are starting points, and dataset, weight and repository paths should be replaced before a real run. The example invocations name the shipped defaults directly, for instance deepdetect train yolox --config bindings/python/deepdetect/cli/yolox-default.yaml, with the same config reused for inference against an image path.

The repository also ships a quickstart preparation script that builds a tiny dataset and model repository under a chosen output directory, taking --output and --force. The README's example writes to /tmp/deepdetect-yolox-quickstart and prints a Sample image path that the subsequent infer command consumes. The training command in that walkthrough uses --terminal live, and the inference command adds --visualize and --output to write a detections image. Visdom is started separately with python -m visdom.server -port 8097, which implies the live terminal mode expects a Visdom instance reachable on that port. Config precedence, monitoring and output formats are documented in bindings/python/deepdetect/cli/CLI_SPEC.md rather than in the README, so that file is the one to read before wiring the CLI into anything automated.

Where the packaged CLI stops and the API begins

The gap between the CLI profiles and the Torch API is the most important thing to understand before adopting DeepDetect. The CLI packages YOLOX and SegFormer workflows. The broader Torch API supports more: image classification with TorchVision-style classifiers including ResNet, VGG, DenseNet, MobileNet, ShuffleNet and SqueezeNet; object detection with YOLOX, Faster R-CNN and RetinaNet; semantic segmentation with SegFormer; language and traced models such as BERT and GPT-2; time series with recurrent, N-BEATS, transformer and time-transformer templates; and vision transformers such as ViT and Visformer.

So a time series project is supported by the runtime but is not one of the four CLI profiles. Reaching it means going through the API reference in docs/api.md for service parameters, connectors, templates and request and response details. That is a real step up in effort, and it is the point where DeepDetect stops feeling like a CLI and starts feeling like a server you have to configure. The README does not claim otherwise, but the topic list and the capability list together can give the impression that everything is equally packaged. It is not.

The external-pytorch-detector profile is worth noting for a different reason. It is described as an external PyTorch detection worker entrypoint, which suggests a pattern where the detection model runs in a separate process rather than inside the DeepDetect runtime. The README does not explain the boundary further, so anyone relying on that profile should read the CLI specification and the default YAML before assuming how the worker is launched and supervised.

Deployment choices and what each one costs you

The README lays out four deployment paths and is fairly direct about when each applies. The Python wheel and CLI are for local training, in-process inference and automation-friendly workflows. The server is for a long-running REST service, remote clients, asynchronous jobs behind an HTTP API, or a dedicated serving process. Docker is for containerised serving and reproducible service environments, documented in docs/docker.md. Building from source is for a custom C++ build, server options, TensorRT support, or local development changes, starting from docs/source.md.

The cost of each path differs in ways the README only implies. The wheel gives you in-process inference, which means no network hop and no separate process to supervise, but it also means the model lives inside your Python process. The server gives you a stable HTTP boundary and asynchronous jobs, at the cost of running and monitoring another service. Docker adds reproducibility. Source builds add the ability to enable TensorRT, which the wheel path does not appear to expose as a documented option in the material here.

TensorRT support is the clearest example of a capability that is real but gated. The README states TensorRT is available for optimised inference with exported or compatible models, and separately lists source builds as the path for TensorRT support. The repository topics include tensorrt-conversion and tensorrt-inference, which suggests conversion tooling exists, but the README does not document a conversion command. Treat TensorRT as a source-build feature to investigate rather than a wheel feature to assume.

Licence and the maintenance question

DeepDetect is distributed under the GNU Lesser General Public License v3.0, per the README, with the full text in COPYING. The repository metadata reports the licence as NOASSERTION, which is a GitHub classification artefact rather than a contradiction, but it does mean automated licence scanners may not resolve the licence from repository metadata alone. If your organisation gates dependencies on machine-readable licence detection, point the scanner at COPYING instead of trusting the metadata field. This is a description of what the repository contains, not legal advice; the LGPL has obligations around relinking and distribution that are worth checking with someone qualified before you ship a modified build.

The maintenance picture is active. The last push recorded is 2026-08-28, and three releases landed in the three months before it: v0.28.0 in June, v0.29.0 later in June, v0.30.0 in August. That cadence matters for a project whose value proposition is a single API surface across many model families, because model families move. It also means the CLI profiles and the YAML defaults can change between minor versions, so pinning the wheel version is the safer default for anything automated.

The upgrade cost concentrates in two places. First, the wheel variant constraint: because deepdetect-cpu and deepdetect-gpu are mutually exclusive, an environment cannot hold both, so testing a GPU upgrade means a separate environment. Second, the YAML configs: the README treats the shipped defaults as starting points to be edited, which means your edited copies are yours to maintain across upgrades rather than files that update themselves. There is no documented migration tool for config files in the material here.

Alternatives and the actual difference in approach

The obvious alternative for the training side is PyTorch directly. The difference is not the model code, since DeepDetect uses Torch as its primary backend. The difference is what surrounds the model: DeepDetect supplies a service abstraction, a filesystem model repository, asynchronous job handling, a REST API with JSON payloads, and a CLI with structured events. PyTorch supplies none of that, and a team using PyTorch directly builds its own serving layer, its own job tracking, and its own model versioning on the filesystem. If you already have that layer, DeepDetect's main contribution is smaller than it looks.

For serving specifically, the alternative is a dedicated inference server that loads exported models and exposes an HTTP or gRPC endpoint, with training handled entirely elsewhere. That split is cleaner when training and serving have different owners or different hardware pools. DeepDetect's design assumes the opposite: the same runtime trains and serves, and the service and repository concepts are shared between the two. That is a genuine architectural difference, not a packaging detail. It reduces the number of moving parts for a small team and increases the coupling for a large one.

On the model-format axis, the alternative is an export-first workflow where you train in whatever framework you prefer and convert to an inference format. DeepDetect supports TensorRT for optimised inference with exported or compatible models, so it can sit downstream of that workflow, but the README positions Torch as the primary backend, which means the intended path is to stay inside DeepDetect rather than export out of it. Which of these fits depends on whether you want the runtime to own the model lifecycle or just the serving step.

Editorial conclusion

Adopt DeepDetect if you want a single process that trains and serves models over one API surface, and if your work sits inside the model families the Torch backend already lists: YOLOX, Faster R-CNN, RetinaNet, SegFormer, the TorchVision classifiers, BERT, GPT-2, the time series templates. Do not adopt it if you need a workflow the CLI does not package, or if you expect Caffe to be a live backend; the README states plainly that Caffe is not an active runtime backend and that Caffe protobufs appear only as compatibility or model-format details. Before committing, run deepdetect inspect models against your installed wheel variant and confirm that the profile you need is listed, then check that the default YAML under bindings/python/deepdetect/cli/ points at paths you can replace with your own dataset, weights and repository.

Official sources

1. Issues
2. jolibrain/deepdetect on GitHub
3. Project website
4. README
5. Releases