FR
live

Immich 3.3 speeds up its AI inference and cuts RAM with one opt-in environment variable

On October 7, 2026, Immich shipped version 3.3, which introduces an opt-in revision of its machine learning models: MACHINE_LEARNING_MODEL_REVISION=v2 makes inference significantly faster and less memory-hungry across every backend, including CPU. If your photo NAS is running tight, this is the variable to add — but understand what it changes first.

A 35mm slide carousel resting on a dark table, one slide pulled halfway out and set aside, a single amber glint on its frame.

October 7, 2026. The Immich team ships v3.3.0, the stable release of the self-hosted photo manager. One variable. The headline technical change is a single configuration line: MACHINE_LEARNING_MODEL_REVISION=v2. Every backend. The optimization covers CPU inference as much as hardware acceleration. Why it matters: on a modest NAS — Immich’s core use case — this revision promises “significantly faster” inference that “uses less memory,” which concretely changes what a low-power machine can do.

What the v2 model revision actually changes

Since v3.3.0, Immich’s machine-learning container accepts an environment variable that switches to a v2 revision of the AI models. The payoff is twofold: faster inference and lower memory use. The team’s wording is understated — “after a long list of optimizations, ML is both significantly faster and uses less memory” — but it is precise on the decisive point: the effect holds across every backend, including CPU inference.

That last point is what matters for self-hosting. Most homelabs run object detection, facial recognition and semantic search on the CPU of a Synology, a mini-PC or a NUC, with no GPU. A revision that reduces memory pressure and speeds up CPU processing mechanically widens the pool of machines that can hold Immich’s AI features without thrashing. Community testing, relayed by mid-October NAS guides, describes clear gains on low-power setups — to the point that Marius Hosting now recommends the variable to unlock “massive performance optimizations” that “consume less RAM and system resources.”

Why it is opt-in, and what that implies

The opt-in choice is not trivial. Changing a model revision is not a simple toggle: it swaps the weights and inference format that feed existing search indexes and embeddings. The Immich team therefore chose not to enable it by default, leaving each user to trigger the switch knowingly.

Practically, two consequences follow. First, work already done with the v1 revision is not migrated automatically: after switching, you must re-run the relevant ML jobs (face detection, semantic-search embeddings, the new OCR models) to rebuild results with the new models. Second, the v2 revision introduces new OCR models, which improves text recognition inside photos but likewise requires re-processing the affected catalog.

The switch happens in the immich-machine-learning service definition of your docker-compose.yml, followed by recreating the container:

yaml
services:
  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:release
    environment:
      MACHINE_LEARNING_MODEL_REVISION: v2
    # ... rest of the configuration unchanged

After docker compose up -d, confirm the running version and re-run the ML jobs from Immich’s administration panel (Jobs tab), starting with Facial Recognition and Smart Search, the two heaviest consumers.

The context: a rich 3.3, but not only technical

v3.3.0 is more than a model revision. It adds people sharing — you can now share an identified person with another user in the group, with control over the direction of the share — plus birthday memories, auto-stacked mobile edits, higher-quality thumbnails, and OAuth claim syncing on every login. All of it continues the arc of a project that, with more than 115,000 GitHub stars and the backing of FUTO, has become the reference self-hosted alternative to Google Photos.

The version sequence also tells a maturation story: v3.2.4 fixed a memory leak introduced by a dependency in late September, and v3.3.0-rc introduced TensorRT inference on NVIDIA RTX GPUs. The v2 model revision joins that hardware push from the other direction — GPU acceleration on one side, and an optimization that benefits those with no GPU at all.

Verdict

The recommendation is easy to state but conditional. If you run Immich on CPU alone or on a RAM-limited NAS, enable MACHINE_LEARNING_MODEL_REVISION=v2: you get back speed and memory headroom exactly where they are scarcest, and the cost is a single re-run of the ML jobs. If you are already on an NVIDIA RTX GPU with TensorRT, or your catalog is huge and your setup stable, you can wait another release before switching — the opt-in nature means there is no urgency, and re-processing a large catalog costs real time. Either way, test on a copy of your library first, watch RAM after the switch, and keep the v1 revision documented as a fallback if any behavior surprises you.

References

The cyber brief, every Tuesday

The flaws that matter and the patches to apply, in a ten-minute read.

No spam. One-click unsubscribe.
read next

On the same topic

Home Assistant 2026.10 gives trigger IDs a real UI and rebuilds its map on OpenStreetMap

Released 7 October 2026, Home Assistant 2026.10 finally gives trigger IDs — the most powerful automation feature almost nobody used — a proper interface, and swaps its map for an OpenStreetMap vector layer after the previous provider broke every map overnight. Update, then merge the automations that duplicate the same logic across triggers.

← Back to the feed

Type at least two characters.

↑ ↓ navigate ↵ open esc dismiss