v1.2.66 - CPU offload H3 & bugfixes

What's Changed

Installer fixes

Install failed on older uv. We were passing a flag that only exists in uv 0.10 and newer, so anyone with an older uv saw unexpected argument '--no-sources-package' and the install stopped before downloading anything. Fixed, and it now works back to uv 0.4.

Large model downloads failed. The 66GB MiniMax H3 transformer could not be fetched at all: The file is too large to be downloaded using the regular download method. Hugging Face needs the hf_xet package for files that size, and our dependency floor was old enough that it was not getting installed. Fixed for fresh installs.

If you are on an existing venv and hit this, install it yourself:

cd Inline-Studio\core
uv pip install --python .venv\Scripts\python.exe hf_xet

Trainer fixes

CPU offload did nothing on MiniMax H3. The setting was in the panel but silently ignored, because we skipped it for any 4-bit base and H3 is always 4-bit. That was backwards: H3's base is small and it is the clip activations that fill the card, so this is exactly the model that needs it. Setting it to On now works.

The status said the wrong thing. Progress only updated after a step finished, so the UI showed loading model (nf4) for the whole of the first step. A slow first step looked like a stuck loader. It now says training before step one starts.

Better memory logging. The trainer now prints allocated and reserved VRAM after caching, after the base loads, and entering the loop, so a slow run can be diagnosed from the log.

Upgrading

The app reads its version from Core's installed metadata, so reinstall or it keeps showing the old one:

cd core && uv pip install --python .venv/bin/python -e . --no-deps

Full Changelog: v1.2.65...v1.2.66

What's Changed

• Honour CPU offload on H3, fix the training status, unblock large HF downloads by @imprsnst in #37

Full Changelog: v1.2.65...v1.2.66

v1.2.65 - improved cuda detection

What's Changed

The right CUDA build for your card

Two bugs, both reported after v1.2.64.

RTX 40-series and other Ada cards were told their install was broken. It was not. Those wheels
carry sm_86 kernels, and CUDA runs them on an sm_89 card perfectly well. We were matching exactly,
so every 4070, 4080, 4090, L4 and L40S owner got a warning telling them to install a CUDA build they
did not need. Fixes #33.

RTX 50-series cards were getting cu126 on a fresh install. They need cu130. The driver reported
the right capability and the Windows installer misread it.

Naming the index yourself now works

--torch-index cu130 used to print "Reusing the existing environment" and change nothing, because
an already-installed torch satisfied the requirement. It now genuinely replaces torch, and
torchvision with it, so you rarely need --recreate.

If you already have a bad install, a plain --install detects it and repairs it. A ROCm build, a
nightly or anything hand-installed is left alone and reported instead, never overwritten.

Tell us what your machine sees

.\webui.bat --print-torch-index

Prints what the driver reported and which index would be used, and installs nothing. If something
still looks wrong, that one line is what to put in a bug report.

Blackwell on an older driver

CUDA 13 needs driver R580 or newer. If yours is older, the installer now picks cu128 and says why:
it still has sm_120 but is frozen at torch 2.11, so updating the driver is worth doing when you
can. Previously that machine got a build with no kernels for it.

Clip training controls

• Clip length shows what it actually resolves to, e.g. Trains on 107 frames (4.46s) per clip.
  H3 snaps down onto its 17n+5 grid, so asking for 5 seconds trains on 4.458s. That was silent.
• New Clip window setting, start or end, for clips whose action is at the finish.

Upgrading

The app reads its version from Core's installed metadata, so reinstall or it keeps showing the old
one:

cd core && uv pip install --python .venv/bin/python -e . --no-deps

Under the hood

webui.bat now runs on a real Windows CI runner against a stubbed GPU, asserting all five wheel
decisions. There was no test workflow before, which is how these shipped. It caught two more bugs in
the fix itself before release.

Full Changelog: v1.2.64...v1.2.65

What's Changed

• Pick the right CUDA wheel per GPU, surface integer versions H3 + clip window select by @imprsnst in #34

Full Changelog: v1.2.64...v1.2.65

v1.2.64-minimax-h3-video-lora-training

MiniMax H3 LoRA training, now on video clips locally

H3 LoRAs can now train on short video clips, so the adapter learns motion instead of just appearance.

• Set Clip length (seconds) in the Trainer's Adjust panel to switch a run from stills to clips
• Leave it empty and nothing changes: stills work exactly as before
• Both write the same adapter file, and one dataset can hold images and clips together
• Clips shorter than 22 frames (0.92s at 24fps) are skipped and named in the log, not fatal
• Works on all four H3 nodes, including Reference to Video

What it costs

Measured, not projected.

Card	Images, 512px	Clips, 512px
L40S (46GB)	20.6GB · 0.63s/step	(Should work)
RTX PRO 4500 Blackwell (32GB)	20.49GB · 0.72s/step	20.9GB · 3.01s/step
L4 (24GB)	20.55GB · 1.81s/step	20.4GB · not timed
Tesla T4 (16GB)	12.7GB · 16.2s/step	not measured(Should work)

• Clips cost about 4x per step and almost nothing extra in VRAM
• The caption pass sets the peak, which is why resolution and clip length barely move it
• A 500-step clip run is roughly 27 minutes of training on a 32GB card, plus about 7 minutes to
  load the checkpoint
• Caching scales with dataset size, not step count: 173 clips takes about 20 minutes

On 16GB cards. Stills train at a 12.7GB peak, unchanged from v1.2.63.

Try it on a public dataset

The first clip LoRA was trained on
trojblue/test-HunyuanVideo-pixelart-videos,
173 short anime pixel art clips with captions.

hf download trojblue/test-HunyuanVideo-pixelart-videos \
  --repo-type dataset --local-dir ~/dataset

• Captions ship in metadata.jsonl, so convert them to NNNN.txt sidecars first
• Point Load from path at the train folder and the sidecars are picked up automatically
• 6 of the 173 clips fall under the frame floor and are skipped, leaving 167 to train on
• 500 steps at 512px with a 1 second clip length produced a usable adapter

Trainer quality of life

• Load from path: import a whole folder without a file picker, caption sidecars included
• Clips render in the dataset grid, the Load Dataset node and on canvas, instead of drawing black
• Load Dataset fills with as many thumbnails as fit, rather than a fixed 6, and grows as you
  resize the node
• Hover to play, double click to open on any dataset tile
• Copy logs, all of them or a single line, straight from the Train LoRA node, with text
  selection working inside the node
• Precache reports progress item by item, so a long cache no longer looks like a hang
• The log keeps 3000 lines instead of 400, so a failed run's setup lines survive to be copied

Fixes

• Your open project survives a page refresh and a Core restart. It used to live only in memory, so a
  reload dropped you on the launcher and a Core restart left an open tab failing every call with
  "No project is open"
• One clip below the frame floor no longer throws away a 20 minute precache. Too-short clips are
  skipped individually and the run continues
• A checkpoint the kernel cannot memory map is now refused in seconds with the exact fix in the
  message, rather than after the precache with a raw Cannot allocate memory (12) that reads like a
  corrupt download

Upgrading

The app reads its version from Core's installed metadata, so reinstall or it keeps reporting the old
one:

cd core && uv pip install --python .venv/bin/python -e . --no-deps

If you hit unable to mmap ... Cannot allocate memory on a machine with less RAM than the
checkpoint, the new preflight will tell you this:

sudo sysctl -w vm.overcommit_memory=1
# to keep it across reboots
echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-inline-studio.conf

Links

• How to train one, step by step guide
• Download Trainer
• Full benchmark tables
• MiniMax H3 weights
• Example dataset

What's Changed

• cuda version check based on hardware by @imprsnst in #29
• Minimax H3 lora training with clip dataset by @imprsnst in #30

Full Changelog: v1.2.63...v1.2.64

v1.2.63-fit-minimax-training-16gb

MiniMax H3 LoRA training on a 16GB card

Fixes the crash that blocked anyone below about 24GB in v1.2.62, and adds real numbers for small cards.

The bug: when a card cannot hold the 32B text encoder we fall back to running it from system RAM, but were still handing it GPU tensors. That surfaced as Expected all tensors to be on the same device ... index_select.

The surprise: H3 peaks lower on a small card than a big one, because the encoder never touches the GPU at all.

	L40S (46GB)	T4 (16GB, 64GB RAM)
Peak VRAM	20.6GB	12.7GB
Seconds per step	0.63	16.2
Caption pass, 26 images	1 min	19 min

So a 16GB card trains H3 where a 24GB card is merely comfortable. The cost is time rather than memory, because the encoder runs unquantised on the CPU.

To try it

• Update to 1.2.63, pick MiniMax H3 in the Trainer's Adjust panel, point it at a folder of images, hit Start. Defaults are fine
• Bring plenty of system RAM. Our test box had 64GB, and the encoder pages roughly 63GB through it
• Expect about 30 minutes before the first step on a 16GB card: 19 min of captions, 7 min loading the checkpoint. That startup is per run and does not scale with steps
• If neither your card nor your RAM can hold the encoder, you now get a clear message up front rather than a crash

Updating

If you installed with pip:

pip install --upgrade -r requirements.txt

If you cloned the repo:

git pull
cd core && uv pip install --python .venv/bin/python -e . --no-deps

The second line is only so the UI reports the new version; the pull is what carries the fix.

Restart Core either way.

Known

The 19 minute caption pass is the real cost on a small card, not the step time. Fixing it means streaming the encoder to the card in 4-bit rather than running it on CPU, which is the next thing to look at.

Full Changelog: v1.2.62...v1.2.63

v1.2.62 - Minimax H3 Lora training still only

What's Changed

Update: a 16GB card does work, from v1.2.63 onward. This release fell back to system
RAM for the text encoder but still handed it GPU tensors, so anything under about 24GB
failed with an index_select device mismatch.

MiniMax H3 LoRA training

You can now train a LoRA for MiniMax H3. It trains on still images, and the adapter applies to video.

• Learns look, style, character and lighting
• Does not learn motion or sound, because it never sees any
• Works on all four H3 nodes, including Reference to Video
• Pick MiniMax H3 in the Trainer's Adjust panel and point it at a folder of images

What it costs

Measured on an L40S, not projected.

Phase	Peak VRAM
Encoding your images	10.8GB
Encoding your captions	20.5GB
Training	11.7GB

• A run peaks at 20.6GB, and the caption pass sets it, not the training
• So 512px and 768px cost the same
• About 0.63s a step at 512px, plus roughly 7 minutes of startup
• The 62GB checkpoint loads as 11.7GB, and host RAM stays near 1.1GB
• On a card that holds the text encoder you need 24GB
• 16GB cards: this release crashes. Fixed in v1.2.63, where a 16GB card trains H3 at a 12.7GB peak. See that release for the numbers
• Auto model download support

Output Comparison(400 steps, purely testing purpose)

Context: trained a lora with a detailed skin dataset
Prompt: inline-skin-lora, detailed skin texture, A photoreal girl, 20 years old & facing camera

With LoRA vs Without LoRA

With LoRA	Without LoRA
287d1fcb-6c20-4927-a237-529b626e9a3e.mp4	MiniMax.H3.Text.to.Video.mp4

Also in this release

• Fixed two bugs in the existing trainer that affected Krea 2 and FLUX.2 4-bit runs
• Every H3 node gained a LoRA input, so adapters from the Trainer load straight in

Video clip training, planned next

Today the H3 trainer takes still images only. Clips were planned and cut, and this is why:

• schema migration
• A new av>=12 dependency
• The dataset grid accepting video, with thumbnails and a trim control
• Audio rows

Links

• How to train one, step by step
• Install
• Full benchmark tables
• MiniMax H3 weights

• Minimax h3 lora training by @imprsnst in #26

Full Changelog: v1.2.61...v1.2.62

v1.2.61 - Minimax H3 open weights

Summary

MiniMax H3 open weights now run locally on the Inline Core engine, as four nodes on the canvas. Video and its 32 kHz stereo soundtrack come out of a single denoising pass, so a take is one MP4 with the audio already in it.

Four nodes

• Text to Video, prompt only
• Image to Video, a still into motion
• First and Last Frame, pin either end or both
• Reference to Video, up to nine images, three clips and three audio clips, addressed by position in the prompt

How it runs

• Loads the original bf16 checkpoints. Nothing repacked, so a new build needs no code change.
• The modulation weights, 40 percent of the transformer, are factorised at load: 66.3 GB down to 40.3 GB.
• The conditioner steps off the card once the prompt is encoded, so the denoiser keeps the card for the whole denoise.

Measured on an L40S

• A 10 second clip at 960x544 takes about 7.2 minutes
• Peak VRAM 38.9 GB
• 46.7 GB of system RAM that cannot be reclaimed, so plan on 64 GB

Licence

Inline Studio ships no model weights. The H3 weights are licensed separately by MiniMax under a community licence that excludes several territories. Read it before you build on it.

Full writeup: https://inlinestudio.art/minimax-h3-open-weights

What's Changed

• Minimax H3 core nodes by @imprsnst in #24

Full Changelog: v1.2.6...v1.2.61

v1.2.6 - Flux 2 & Minimax H3 API

FLUX.2 & MiniMax H3

Four commits on top of main. Adds FLUX.2 to the local engine, the MiniMax H3
family as API nodes, and getting-started cards so a new project is one click from
a working graph.

FLUX.2 (local)

One node covers the whole family. Pick a checkpoint in the Adjust sidebar and it
identifies itself: klein 4B, klein 9B, either Base build, the KV variant, or dev.
Steps and guidance default to "from model", so swapping a distilled checkpoint for
its Base build moves 4 steps at guidance 1.0 to 50 at guidance 4.0 with no settings
to touch.

• Identified by content, never by filename. diffusion_models/ is shared
  across architectures, so checkpoints are read from their tensor shapes. Z-Image,
  Krea 2 and FLUX.2 sit side by side safely.
• Diffusers folders count as checkpoints. That is the only practical way to
  get the 32B dev build onto a 24 GB card, since NF4 shards stream through
  from_pretrained where from_single_file cannot quantize at all.
• Multi reference composition. Wire several images into one node and address
  them by position: "the character from image 1 wearing the jacket from image 2".
  The node numbers them on its face. No denoise strength slider, because FLUX.2
  has no img2img, a single reference is the edit.
• ControlNet, and LoRA training in the Trainer tab against Base builds.
  The trainer refuses a distilled checkpoint rather than letting a run produce a
  bad adapter hours later.
• Staged loading when the encoder and transformer cannot be co-resident. The
  prompt is encoded first and the encoder freed before the transformer loads.

MiniMax H3 (API nodes)

Three nodes: text to video, image to video, reference to video. 2K, 5 to 15
seconds, $0.26 per second, with a live estimate on the node.

• Image to video has two image ports. Wire a start frame alone, or add an end
  frame and H3 interpolates between them.
• Reference to video takes up to 9 images plus reference video and audio. The
  prompt addresses them by position, and wiring order is the numbering you see.
  Over-wired sets trim to fal's caps instead of failing at the API.
• No seed and no prompt optimizer. Neither exists in H3's schema, unlike the older
  MiniMax endpoints.

Getting-started cards

An empty canvas now offers five ways to start. Each card says how that model will
run on your specific GPU, and one click builds a prompt node wired into a model
node with settings and a prompt already filled in. Includes an API Nodes card for
anyone with no GPU.

Advice is advisory, never gating. The device policy quantizes and offloads to fit,
so every tier still says it runs.

Per-port input routing

Inputs now record which port they were wired to, so a model can declare two ports
of the same kind and tell them apart. That is what makes the end frame work.

Untagged inputs still resolve by media kind, so existing projects and drag-and-drop
behave exactly as before.

Fixes

• Wiring a Load Assets node into a Generate node drew an edge and recorded nothing.
  The request went out with an empty URL, and fal answered with a 422 that pointed
  nowhere near the cause.
• A FLUX.2 model pick stored as a full path resolved to nothing and surfaced as
  'None' is not a FLUX.2 diffusion model.
• FLUX.2's pre-flight check reported a checkpoint present when only the variant
  param resolved, so a missing file failed late and opaquely instead of at the
  guard.
• Number params in the fal Adjust panel could not be cleared. An emptied box
  snapped straight back to 0, and an out-of-range value stuck in the field while
  the request quietly used a different one.
• Prompt nodes showed empty text when something wrote the prompt just after mount.
• 21 engine tests were silently not running. They do now.

Upgrading

Projects gain a nullable handle column on first open (SCHEMA_VERSION 16 to 17).
Additive, so older builds still open projects touched by this one.

Pin the version when installing. PyPI sorts 1.2.6 below 1.2.53, so a plain
pip install still resolves to the previous release:

pip install inline-core==1.2.6 inline-studio-frontend==1.2.6

Full Changelog: v1.2.53...v1.2.6

v1.2.53 - Controlnet & Control Space

ControlNet support + Control Space

Four commits on top of main. Adds ControlNet to the local Core gen nodes, a new
3D editor to drive it, and generation recipes embedded in output images.

Control Space (new)

A full-screen 3D editor for posing OpenPose characters and framing a camera, then
rendering that as a control map. Multi-character, presets, orbit camera, output
aspect picker, pose or depth output.

Depth output builds a volumetric body: limb capsules with anatomical thickness, a
closed torso, and a skull with a face and nose along its forward axis, standing on
a ground plane against a backdrop. Facing reads straight off the pixels, and the
face hides behind the skull when a character turns away.

Pulls in three.js, @react-three/fiber and drei.

ControlNet

• Z-Image: Control input port, controlnet picker and conditioning scale.
  Loads the Fun Union checkpoint offline via a bundled config.
• Krea 2: depth control through the public Patil/Krea-2-depth-controlnet
  control-LoRA. Rank-64 on every block plus a wider input projection, so a
  VAE-encoded depth latent rides next to the noisy one.
• Apply ControlNet node: turns any image into a pose, depth or canny map.

Control maps are now typed CONTROL so they can only feed a Control input. Wiring
one into img2img was silently running image-to-image from a black map, which looked
exactly like "ControlNet not working".

Other improvements

• Drag drop generated image to load graph
• Generated assets now carries entire generation info & settings.

What's Changed

• Controlnet support: Control space & controlnet nodes by @imprsnst in #17

Full Changelog: v1.2.52...v1.2.53

1.2.5 - Krea 2 generation & LoRA training

v1.2.5

Krea 2 lands as the second local model family, for both generation and LoRA training.

Krea 2 is a 12.9B single-stream MMDiT shipped as two checkpoints that work together. RAW is the undistilled base you fine-tune, Turbo is the 8-step distilled checkpoint you generate with, and a LoRA trained on RAW applies to Turbo unchanged. Both nodes are built around that workflow.

Generation

• Krea 2 Turbo and Krea 2 RAW canvas nodes, sitting alongside Z-Image as Core builtins.
• The model popup sizes the download against your GPU and warns before a 26GB load rather than failing deep inside one.
• Reads the ComfyUI-style files from Comfy-Org/Krea-2. Only the bf16 builds load: the fp8_scaled, int8_convrot, mxfp8 and nvfp4 variants carry ComfyUI-specific scale tensors, and the node says so up front. The VAE is the diffusers-format one from Qwen/Qwen-Image, which the popup fetches for you. No Hugging Face token needed anywhere.
• img2img support, plus the usual take history and streamed progress.

LoRA training

• The trainer is now arch-aware, with z-image and krea2 each declaring its own base resolution, target modules and text-encoder handling.
• A 4-bit (nf4) frozen base puts Krea 2 LoRA training on a 16GB card. The LoRA itself stays full precision, so the only cost is base fidelity.
• New settings in the Adjust panel: base quantisation (auto, none, nf4), LoRA scope (full or attention), caption dropout, and flip augmentation.
• Settings now stage behind an Update button instead of applying as you type. A checkpoint encodes the rank, targets and base it was built with, so applying a change to a resumable run asks first, then discards that run's checkpoints. Finished LoRA files are never touched.

Training benchmarks

12 steps at rank 16, batch 1, gradient checkpointing on. The number is torch.cuda.max_memory_allocated, so leave headroom for the CUDA context and allocator slack.

Model	Base mode	Res	Base precision	L40S (46GB)	T4 (15GB)
Z-Image	De-Turbo	512	bf16	13.1GB	13.4GB
Z-Image	De-Turbo	1024	bf16	14.9GB	out of memory
Z-Image	Turbo + adapter	512	bf16	13.1GB	13.4GB
Z-Image	Turbo + adapter	1024	bf16	14.9GB	out of memory
Krea 2	RAW	512	bf16	30.4GB	out of memory
Krea 2	RAW	512	4-bit	11.7GB	11.9GB
Krea 2	RAW	1024	bf16	out of memory	out of memory
Krea 2	RAW	1024	4-bit	27.8GB	out of memory
Krea 2	Turbo + adapter	512	bf16	30.4GB	out of memory
Krea 2	Turbo + adapter	512	4-bit	11.7GB	11.9GB
Krea 2	Turbo + adapter	1024	bf16	out of memory	out of memory
Krea 2	Turbo + adapter	1024	4-bit	27.8GB	out of memory

A training adapter is free: it is fused into the base before training starts, so Turbo-plus-adapter and the undistilled base peak identically.

Note that training Krea 2 is cheaper than generating with it. Generation peaks around 36GB at 1024 with guidance on, so a 40GB+ card is the practical floor there, while the 4-bit path trains at 512 inside 12GB. Z-Image remains the low-VRAM option for generation.

Under the hood

The shared pipeline machinery moved out of the Z-Image runner into models/pipeline_runtime.py and models/loaders.py, cutting zimage/runner.py from roughly 1000 lines to 250 and giving both model families one device, dtype and offload path.

Project

• Added a code of conduct, a contributing guide, issue templates and a PR template.

Full changelog: v1.2.41...v1.2.5

What's Changed

• Krea2 generation & lora trainer by @imprsnst in #15

Full Changelog: v1.2.41...v1.2.5

v1.2.41 Z-image-lora-trainer

LoRA training

Train a LoRA on your own images without leaving the app. The new Trainer tab is a second canvas: wire up the nodes, press Start, and watch it run. The finished .safetensors lands in models/loras/, where the LoRA loader node picks it up, so you can generate with it in the Studio tab straight away.

What's in it

• A training graph. Load Dataset, Caption, Train LoRA, Graph, and a connection-less Resources node for CPU/RAM/VRAM.
• Local auto-captioning over the images that need it, with per-image progress. Captions stay editable.
• Stop and resume. Stopping flushes a checkpoint first, so Resume continues from the step it left off. Runs cut short by a crash or restart are recovered the same way.
• Live feedback on the node: step counter, streaming trainer logs, and a loss curve with loss and step values on the axes.
• Datasets and Outputs tabs in the sidebar, with drag and drop image import and a list of finished LoRAs and resumable runs.
• Custom output filename for the produced LoRA.

What's Changed

• Z image lora trainer by @imprsnst in #13

Full Changelog: v1.2.31...v1.2.41