PyTorch / TensorFlow / JAX

This page covers the blessed path for running the major Python machine-learning frameworks (PyTorch, TensorFlow, JAX) on InterGenOS, and how that path relates to the GPU acceleration stack the system already provides.

InterGenOS is a built-from-source distribution. The guiding principle holds here as everywhere else: you should end up with a machine you understand, can modify, and can trust. ML tooling is no exception, and nothing on this page bypasses the system’s signed Secure Boot chain, dm-verity integrity, or the safety posture of the local assistant.

What ships today

InterGenOS is assembled across seven package tiers — toolchain, core, base, desktop, extra, compute, ai — in a 21-phase build.

PyTorch is a first-party package. The ai tier carries 56 package definitions: the two that ship on the installed image are the InterGen assistant and the llama.cpp inference engine, and the remaining 54 are the model-tooling stack, marked mirror-only because they are training apparatus rather than something every desktop needs. That stack is built from source like everything else and installed from the repository when you want it:

alongside the supporting set (datasets, diffusers, peft, trl, safetensors, tokenizers, xformers, and their dependencies). Versions drift; derive the current set from the package tree or the synced index.

TensorFlow and JAX are not packaged. That was confirmed with three differently-shaped searches of the package tree — a path glob, a package-name field search, and a description search — and all three came back empty. For those two, the virtual-environment path below is the way to run them.

The shipping AI layer on the installed image is the local assistant stack:

• InterGen is a tiered, hardware-detected, offline-first local assistant built on an on-device model with zero telemetry. It probes the GPU and its dedicated VRAM and selects an appropriately sized model; system RAM is reported but does not decide the tier. Inference is served locally over an HTTP API by a llama-server subprocess from llama.cpp.
• InterGen Sentinel is a pluggable security scanner. Its default configuration runs entirely on-device: a fast local-rules pass plus an optional deep pass backed by a small local Qwen classifier. Six named cloud providers (Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), DeepSeek), plus any custom OpenAI-compatible endpoint you supply, are opt-in only; none is configured by default.

This matters for ML work because the assistant’s inference path (llama.cpp serving a quantized on-device model) is independent of the Python framework stack you would use for training or general tensor compute. Running a framework does not interfere with InterGen, and InterGen does not depend on one.

The blessed path

There are two paths, and which one is right depends on the framework.

For PyTorch and the model-tooling stack, install the packaged build. It is built from source in the same pipeline as the rest of the system, carries the same file-level hashes, and is verifiable by pkm verify like any other package — none of which is true of a wheel pulled from an external index. It is mirror-only, so it is not on your machine until you install it:

sudo pkm install pytorch

For TensorFlow and JAX, use a project-local Python virtual environment rather than installing into the system Python. This keeps framework dependencies out of the verified system image, leaves the integrity-checked base untouched, and makes each project reproducible and disposable.

The general shape of that path is:

1. Confirm your GPU is detected and the acceleration runtime is present (see the other GPU pages in this section).
2. Create a per-project virtual environment.
3. Install the framework build that matches your accelerator into that environment.
4. Verify the framework can see the GPU before you rely on it.

Each framework distributes accelerator-specific builds. You install the build that matches the GPU and runtime on your machine; a CPU-only build will run but will not use the GPU.

GPU detection vs. framework GPU support

A working desktop GPU under GNOME 49 on Wayland (the desktop InterGenOS ships today) is not the same thing as a framework-visible compute device. Verify both layers:

• The system sees the GPU (kernel driver loaded, device present).
• The framework sees the GPU (its own device query reports the accelerator).

Use each framework’s built-in device check after installation:

• PyTorch exposes a runtime check for accelerator availability and device count.
• TensorFlow can list the physical compute devices it has registered.
• JAX reports the active backend and the devices bound to it.

If the system sees the GPU but the framework does not, the mismatch is almost always between the framework build you installed and the accelerator runtime on the host. Reinstall the framework build that matches your runtime rather than changing the system.

Staying inside the security posture

Two things to keep in mind:

• Frameworks pull large dependency trees from external indexes. That is content crossing into your machine. Treat third-party model weights and packages with the same care as any other untrusted download, and prefer pinned, hash-checked installs inside the project environment. This is the concrete reason to prefer the packaged PyTorch where it covers your need: it arrives through the signed index with per-file hashes rather than from an external wheel index.
• InterGen’s safety classifier still applies to assistant-driven actions. If you ask the local assistant to set up or manage a framework environment, state-changing steps are surfaced for confirmation and destructive operations are refused outright. Having the assistant manage your environment does not weaken that boundary.

Related pages

• Frequently asked questions
• Forge install guide