# Geti: Intel's end-to-end computer vision platform, and the getitune library underneath it

> Geti packages dataset preparation, training, optimization and deployment into one application for Intel XPU hardware, with a standalone Python engine called getitune for scripted workflows. The split between the two is what decides whether it fits your team.

**open-edge-platform/geti** — Build, train, optimize, and run computer vision models locally, from raw images to live inference. Open source, optimized for Intel XPU (CPU-only and CUDA also supported).

- Repository: https://github.com/open-edge-platform/geti
- Website: https://docs.geti.intel.com
- Stars: 1,344 · Forks: 479
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/open-edge-platform-geti

## What Geti actually replaces in a computer vision workflow

Most teams building an object detector do not have one problem. They have five: getting images into a consistent format, choosing and configuring an architecture, running training on whatever accelerator is available, compressing the result enough to run at the edge, and exporting it to something a runtime can load. Each step usually lives in a different repository with its own configuration format.

Geti is an attempt to put those five steps behind one interface. The repository ships two things: an application, in the application/ folder, and a training engine called getitune, in the library/ folder. The application is the graphical path, available as a Docker container or a native Windows application, and it walks through the model lifecycle from dataset preparation to deployment. The library is the same engine exposed as Python, published on PyPI, for people who would rather script the pipeline than click through it.

The intended audience is narrow in one respect and broad in another. It is narrow because the project states it is optimized for fine-tuning and fast inference across the Intel XPU portfolio, so the hardware assumption is baked in. It is broad because CPU-only and CUDA paths exist, and because the library works on ordinary datasets with no Intel hardware at all, just more slowly. If you are an engineer who has been gluing together training scripts and export tooling by hand, this is the problem the project is aimed at.

## The application and the library are two products in one repository

The first decision with Geti is which half you want, and the README is explicit that both are developed here, in application/ and library/ respectively.

The application is the full platform. It is distributed as a Docker container or a Windows MSIX package, and the README lists four supported routes: the Windows app, Docker, an install script, and building from source for development. There are install.ps1 and install.sh at the repository root, which is consistent with that script route. The application is where the guided lifecycle lives, including the incremental learning loop the project describes as its model lifecycle.

The library, getitune, is the training engine extracted from that platform. It has no UI and no dataset preparation wizard. What it gives you is a small API surface: list the available models, create an engine bound to a model and a dataset, then call train, test, export, optimize and predict. That is a much smaller thing than the application, and for anyone with an existing data pipeline it is probably the more useful half.

A practical consequence: if you adopt the application and later want the same training run in CI, you are not rewriting from scratch, because the engine underneath is the same code. The reverse is also true, which is the more interesting direction. You can prototype with getitune in a notebook and hand the resulting recipe to a colleague who only uses the GUI.

## Installing getitune and training a first model

The library installs from PyPI. The README gives three variants, and the difference between them is the accelerator backend, so pick the one matching your hardware. The XPU and CUDA variants pull PyTorch wheels from an extra index.

```bash
uv pip install "getitune[xpu]" --extra-index-url https://download.pytorch.org/whl/xpu
uv pip install "getitune[cuda]" --extra-index-url https://download.pytorch.org/whl/cu128
uv pip install getitune
```

The third line is the CPU-only default. On a machine with no supported accelerator, that is the one that will work, at the cost of training speed.

One licensing constraint is worth knowing before you start, because it changes the install command. The README states that the PyPI package does not include Ultralytics YOLO models, which are distributed under AGPL-3.0. To use those models you build from source with the ultralytics extra, as described in the getitune documentation. If your plan depends on a YOLO architecture, the plain pip install will not get you there.

Once installed, the README's quick-start example is short enough to read in full. It imports create_engine and list_models, inspects what is available, then runs a training and export cycle.

```python
from getitune.engine import create_engine
from getitune.utils import list_models

all_models = list_models()
detection_models = list_models(task="DETECTION")
recipes = list_models(return_recipes=True)

engine = create_engine(
    model="efficientnet_b0",
    data="/path/to/dataset",
    work_dir="./my_workspace",
    device="auto",
)
```

The model argument accepts a model name, a recipe YAML path, or an already exported IR or ONNX file. That last option is the one that makes the API more than a training wrapper: you can point it at an exported model and continue into optimization and prediction without going back to the original training run. The device argument takes "auto", "cpu", "gpu" or "xpu".

The remaining calls follow the lifecycle in order. engine.train(max_epochs=50) fits the model, engine.test() returns metrics, and engine.export() writes an OpenVINO IR by default. From there the README loads the exported model into a new engine, calls optimize() for edge deployment, tests the optimized model, and finally calls predict(). The prose around the example says to see the getitune documentation for the full recipe list and backend-specific options, which is where you would go once the default configuration stops being enough.

## Where the model catalog stops and you have to leave

The README's feature list names RF-DETR, DINOv3 DETR, YOLO26, YOLOX, D-FINE and Mask R-CNN for training and fine-tuning. That is a modern detection-heavy catalog, and the task filter in list_models(task="DETECTION") suggests task selection is a first-class concept rather than something you configure by hand.

The limitation is that the catalog is the product. Geti is not a framework where you bring an arbitrary PyTorch model and plug it into the training loop. You pick from what list_models() returns, or you supply a recipe. If your architecture is not in that list and no recipe covers it, the engine is the wrong tool, and no amount of configuration will change that. The README does not document an extension path for registering a custom architecture, so this is a boundary rather than a gap you can work around from the documentation alone.

The second constraint is hardware. The project is optimized for Intel XPU, and CPU-only and CUDA are supported, but the README does not claim parity between them. It gives separate install commands per backend and points to the documentation for backend-specific options, which is the honest shape of the situation: the XPU path is the one the project is built around, and the others are accommodated.

A third point the README is silent on: rollback. There is an upgrade guide, but nothing in the repository's top-level documentation describes what happens to an existing installation or its trained models when an upgrade goes wrong. If you are running Geti in a shared environment, that is something to establish yourself before the first version bump.

## How getitune differs from the OpenVINO Training Extensions it replaced

The most direct alternative here is the project's own predecessor. The README states that this repository previously hosted OpenVINO Training Extensions (OTX), that OTX is now fully replaced by getitune, and that the legacy otx package is still on PyPI but deprecated. The migration advice is explicit: getitune has a similar interface to otx and extends it with several new models. That is the actual difference in approach, and it is a modest one. This is not a redesign of the training interface, it is the same interface with a wider model set and continued maintenance.

For anyone already running otx in production, that framing matters. The migration cost is low because the interface is similar, and the reason to move is model availability rather than a new architecture. Staying on otx means staying on a package the project describes as deprecated.

A second comparison point is the application itself versus the library. They are not competitors, but choosing between them is a real decision. The application gives you dataset preparation and a guided lifecycle; the library gives you a Python API and nothing else. If your images are already curated and labeled, the application's preparation stage is overhead you are paying for. If they are not, the library leaves that work entirely to you.

For a genuinely different approach, the alternative is assembling the pipeline yourself from PyTorch, a training framework, and an export tool. That gives you arbitrary architectures and full control over every stage. What you give up is the integration: the export-to-optimize-to-predict chain in the README's example exists as a chain because one project owns all of it. Rebuilding that yourself is possible and is what most teams do before they look at something like Geti.

## Version history, licensing and the cost of keeping up

The release tags show the shape of the project's cadence. Geti v3.1.0 was tagged on 2026-08-13, v3.0.0 on 2026-06-18, and 2.6.0 on 2025-10-13. The gap between 2.6.0 and 3.0.0 is roughly eight months, and the README describes v3.0 as a major revamp that produced a much more lightweight and easier-to-install application while adding new features and models. The last push to the develop branch was on 2026-09-10, so the repository is not archived and is being worked on.

That v3.0 revamp is the main upgrade-cost story, and it is a large one. The README points to a separate geti_v2 repository for legacy versions and provides a migration guide from v2 to v3. Anyone on v2 is not looking at a routine version bump; they are looking at a migration between applications. The documentation does not describe the migration's difficulty, only that a guide exists.

Licensing is Apache-2.0, which covers the repository. The complication is the Ultralytics YOLO models, distributed under AGPL-3.0 and excluded from the PyPI package. That is not a detail you can defer: AGPL-3.0 and Apache-2.0 carry different obligations, and the project's decision to keep those models out of the published wheel means the licensing question arrives at the moment you decide to build from source with the ultralytics extra. Whether that matters for your deployment depends on how you distribute your model, which is a question for your own legal review, not something the README answers.

## Who should adopt Geti, and what to check first

Geti fits teams with Intel XPU hardware, an owned and labeled dataset, and a need to carry a model from training through quantization to an OpenVINO deployment without stitching tools together. The library path fits engineers who want that pipeline in Python and are comfortable with the API shown in the README. The application path fits people who want the same lifecycle with a UI and a dataset preparation stage.

It does not fit teams deploying to non-Intel accelerator stacks, where the hardware optimization that motivates the project does not apply. It does not fit teams whose architecture is outside the model catalog and who need to register their own. And it does not fit anyone who needs Ultralytics YOLO models from a plain pip install, because the PyPI package excludes them.

Two checks are worth running before you build anything on top of it. First, confirm your accelerator appears in the install guide for the route you intend to take, rather than assuming the CUDA or CPU path behaves like the XPU one. Second, run list_models() for your task and confirm the architecture you want is actually there, because that list is the boundary of what the engine can train. The project's own documentation hosts a step-by-step tutorial titled "Train your first model" for new users, which is the right place to start once those two answers are yes.

## Conclusion

Adopt Geti if you have Intel XPU hardware, a dataset you own, and you want training, quantization and OpenVINO export behind one interface rather than assembled from separate scripts. Skip it if your deployment target is a non-Intel accelerator stack or you need Ultralytics YOLO models without building from source, since the PyPI package excludes them for licensing reasons. Before committing, verify two things on your own machine: that your accelerator is covered by the install guide rather than assumed, and that the model you want appears in list_models() for your task, because the catalog is the real boundary of what this tool can do for you.

## FAQ

### What is Geti?

Geti is an end-to-end platform for building AI computer vision models, available as a Docker container or a native Windows application. It guides you from dataset preparation and training through optimization and deployment, and it is optimized for fine-tuning and fast inference across the Intel XPU portfolio.

### What is the Intel Open Edge Platform?

The repository does not describe the Open Edge Platform as a whole; it only shows that Geti lives under the open-edge-platform organization on GitHub. Anything beyond that would be a guess.

### What is the Intel Edge AI program?

The repository does not cover an Intel Edge AI program, so this question cannot be answered from it. Geti itself is described as optimized for the Intel XPU portfolio, which is the only hardware relationship the README states.

## Sources

- [License: Apache-2.0](https://github.com/open-edge-platform/geti/blob/develop/LICENSE)
- [open-edge-platform/geti on GitHub](https://github.com/open-edge-platform/geti)
- [Project website](https://docs.geti.intel.com)
- [README](https://github.com/open-edge-platform/geti/blob/develop/README.md)
- [Releases](https://github.com/open-edge-platform/geti/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-edge-platform-geti