Geti v3: Intel's Computer Vision Platform, Split Into an App and a Python Library

The Problem Geti Targets: Fine-Tuning and Edge Export in One Loop

Most computer vision work is not training a network from scratch. It is taking a pretrained backbone, fine-tuning it on a few hundred or few thousand labeled images, and then getting the result onto hardware that has no Python and no PyTorch. Those two halves usually live in different tools, and the handoff between them is where projects stall. Geti addresses that handoff directly. The README describes it as an end-to-end platform that guides you through the model lifecycle, from dataset preparation and training to optimization and deployment, and the repository splits that lifecycle across two folders: application and library. The audience is a team that owns both the model and the device it runs on. If you only train models and hand a checkpoint to someone else, the export and optimization half of Geti is dead weight. The README also notes that v3 was a major revamp, much lighter and easier to install than v2, with v2 code living in a separate geti_v2 repository and a migration guide published in the docs. That matters if you are already running v2: this is not an in-place upgrade, it is a different application with a migration path.

Application and Library: Two Entry Points, One Engine

The architecture visible in the repository is a clean split. The application folder holds the user-facing product, shipped as a Docker container or a native Windows MSIX package. The library folder holds getitune, described as the open-source engine for model training and optimization that powers the application. Getitune is also published on PyPI, so the same engine that drives the UI is callable from Python. That is the design decision worth noticing: the GUI is a client of the engine rather than a wrapper around a separate training script. It means a recipe you tune interactively should be reproducible from a notebook, and a pipeline you script should be reproducible in the UI. The README explicitly positions getitune as the successor to OpenVINO Training Extensions (OTX), which this repository previously hosted. The otx package remains on PyPI but is marked deprecated, and the README states that getitune has a similar interface to otx and extends it with several new models. For anyone with OTX scripts in production, that is a migration with a mostly familiar API surface, not a rewrite.

The Training Loop in Code: create_engine, train, export, optimize

The README's quick-start example is the clearest statement of the intended data flow. You call list_models() to see what is available, optionally filtered by task, for example list_models(task="DETECTION"), or with return_recipes=True to get the recipe YAML paths. Then create_engine() takes four arguments in the example: model, data, work_dir and device. The model argument accepts a model name, a recipe YAML path, or an already exported IR or ONNX file. That last option is the interesting one, because it lets you re-enter the pipeline at the optimization stage with a model you exported earlier. Device accepts "auto", "cpu", "gpu" or "xpu". From there the sequence is engine.train(max_epochs=50), engine.test() for metrics, and engine.export(), which the README says defaults to OpenVINO IR. The second half is a separate engine built from the exported path, with data passed as engine.datamodule rather than the original dataset path. That second engine runs optimize(), then test() again, then predict(). The reason to test twice is that optimize() is where quantization and graph transformations happen, so the accuracy you measured after training is not the accuracy you will ship. The README does not publish accuracy deltas for that step, and you should not assume they are negligible on your own classes.

Installing: Extras Decide Which Silicon You Get

The library install is three commands in the README, and the extra you pick determines the PyTorch build. For Intel acceleration it is uv pip install "getitune[xpu]" --extra-index-url https://download.pytorch.org/whl/xpu. For NVIDIA it is uv pip install "getitune[cuda]" --extra-index-url https://download.pytorch.org/whl/cu128. Plain uv pip install getitune is CPU-only by default. Note that the CPU path is the default rather than a fallback, which tells you the project expects CPU inference to be a real deployment target, not just a development convenience. The application side has four documented routes in application/docs/install.md: the Windows MSIX app, a Docker container, an install script, and a source build for development. The README points to application/docs/upgrade.md for updating an existing installation. One constraint deserves emphasis. The PyPI package does not include Ultralytics YOLO models, because those are distributed under AGPL-3.0. To enable them you must build from source with the ultralytics extra, as described in the getitune documentation. This is a licensing boundary expressed as a packaging decision, and it is the single most likely surprise for someone who installs the package and then looks for YOLO in list_models().

Model Catalog and the Hardware Bet

The README's feature list names RF-DETR, DINOv3 DETR, YOLO26, YOLOX, D-FINE and Mask R-CNN as trainable and fine-tunable architectures. The repository topics add the training paradigms behind them: transfer learning, semi-supervised learning, self-supervised learning and incremental learning, plus neural networks compression and quantization on the optimization side. Tasks covered by the topics are image classification, object detection and image segmentation. The hardware story is stated plainly: Geti is optimized for fine-tuning and fast inference across the full Intel XPU portfolio, with CPU-only and CUDA also supported. Read that as a priority order. XPU is the path the project is built around, and CUDA support exists but is not the thing the release notes are organized around. If your fleet is Intel-based edge devices, the OpenVINO IR export and optimize() step are the payoff. If your fleet is Jetson or a discrete NVIDIA GPU, you are using the supported-but-secondary path, and the optimization step lands you in OpenVINO rather than TensorRT, which may not be what your inference server expects.

Where Geti Is the Wrong Choice

Two failure modes are visible from the material. The first is the YOLO licensing gap already described: if your plan is pip install getitune, import a YOLO recipe and ship, the package will not have it. You either build from source with the ultralytics extra and accept the AGPL-3.0 obligations that come with those weights, or you pick a different architecture from the catalog. The second is the v2 to v3 discontinuity. The README is explicit that v3 is a new application and that legacy versions live in a different repository, with a migration guide in the docs. Teams with v2 deployments and custom integrations should treat this as a migration project, not an upgrade. A third consideration is scope: this is a platform, not a library you drop into an existing training codebase. If you already have a mature PyTorch training stack with your own augmentation, distributed training and experiment tracking, adopting Geti means adopting its recipe format, its engine abstraction and its workspace layout. The README does not document how far the recipe system bends before you are fighting it, and that is exactly the kind of thing to prototype before a team-wide commitment.

Getitune Against Plain PyTorch Plus OpenVINO

The obvious alternative is doing the same work by hand: a PyTorch fine-tuning script, then the OpenVINO Model Optimizer or the openvino.convert_model API, then NNCF for quantization. That stack is more flexible and has no opinion about your project layout. The difference in approach is that Geti treats the whole sequence as one engine with a shared model registry. create_engine() accepts a model name, a recipe path, or an exported IR or ONNX, which means the training engine and the optimization engine are the same class with the same test() and predict() interface. In a hand-rolled stack you write the glue between training and conversion yourself, and you write it again when a model architecture changes. The cost of Geti's approach is that you inherit its model catalog and its recipe conventions. If your architecture is not in list_models(), you are extending the library rather than using it. The README does not describe a documented path for registering a fully custom architecture, so treat that as unverified until you check the library documentation.

Maintenance, Licensing and What to Check First

The project is Apache-2.0 and actively released: app/v3.1.0 in August 2026, app/v3.0.0 in June 2026, and 2.6.0 in October 2025. The version numbering changed between the 2.x and app/v3.x lines, which is consistent with the repository restructuring. The cadence suggests you should expect to track releases rather than pin and forget, particularly if you use the application, where the upgrade guide exists because upgrades are a supported operation. On licensing, the Apache-2.0 terms cover the repository, but the README makes clear that Ultralytics YOLO models carry AGPL-3.0 and are excluded from the PyPI package for that reason. Mixing AGPL-3.0 weights into a distributed product has consequences that vary by how you deploy, and that is a question for your own legal review rather than something the README resolves. The concrete first step is small: install the CPU-only package, run list_models(task="DETECTION") against a dataset you already have, and run the full train, export, optimize, test sequence on one model. The number that decides adoption is the gap between the metrics from the first test() and the second.

Editorial conclusion

Adopt Geti if your deployment target is Intel hardware and you want the same engine to fine-tune, export to OpenVINO IR and optimize for edge inference without stitching three toolchains together. Skip it if you need YOLO-family models from a plain pip install, since the PyPI package excludes them for AGPL-3.0 reasons and the source build with the ultralytics extra is the only path; skip it too if your inference stack is already TensorRT or ONNX Runtime on non-Intel accelerators. Before committing, verify two things against your own data: that a model in list_models() covers your task, and that the exported IR survives the optimize() step at the accuracy you need, because quantization is where edge deployments usually lose points.

Official sources

1. License: Apache-2.0
2. open-edge-platform/geti on GitHub
3. Project website
4. README
5. Releases