Krea 2 LoRA training on a Colab T4 — looking for clean-run testers

Show and Tell
1

I built Krea 2 LoRA Studio to explore whether the full Krea 2 LoRA workflow could be made usable on a free Google Colab T4. The main engineering constraint was memory: cache preparation, base-model training and preview generation should not keep large components resident at the same time.

The notebook now provides a small browser UI and a staged workflow:

  • build reusable image-latent and caption caches, then train in a separate stage;
  • save resumable checkpoints and downloadable LoRA snapshots by step;
  • optionally generate checkpoint previews with the compact NF4 Krea 2 Turbo model (8 sampling steps, 512 px default);
  • release preview memory and check that VRAM returns before training continues.

I have completed an end-to-end Colab/T4 run through final LoRA verification and preview generation. Local CPU regression tests currently pass 27 cases; one dataset test is skipped because the private sample dataset is not part of the public repository.

For rough planning only, the runs I observed were about 8 minutes for an uninterrupted cold start, about 14m52s per 100-step segment, and about 82 seconds for two Turbo previews including model setup. These are anecdotal, settings-dependent observations, not controlled benchmarks; reconnects and cache state affected earlier runs. The repository’s BENCHMARKS.md has more context.

Project and Colab notebook: GitHub - jordanepsh/krea2-t4-lora-studio: Train and preview Krea 2 LoRAs in Google Colab with a lightweight Studio UI. · GitHub
Latest release: Release Krea 2 LoRA Studio v1.0.2 · jordanepsh/krea2-t4-lora-studio · GitHub

I would love feedback from a few people with authorized access to Krea 2 Raw and a Colab T4, especially on first-run clarity, cache behavior, resume, and checkpoint downloads. If you try it, please share the GPU/runtime, dataset size, resolution and steps, which stages completed, and a short redacted error if anything failed. Please do not post tokens, private datasets, model files, or live runtime URLs.

2

So, it’s not a complete test, but I gave it a try:

I ran a small Colab/T4 probe using the ungated unsloth/Krea-2-Raw mirror rather than the gated official Raw repo.

The useful part is that the main staged workflow completed for me:

  • 512 px / 3-image test dataset
  • latent + caption cache creation
  • cache reuse on a second pass
  • short training run
  • checkpoint save
  • resume from checkpoint
  • Turbo preview
  • preview memory release
  • training resumed again after preview
  • saved LoRA sanity check

Peak VRAM during the short training run was about 8.13 GiB on a 15 GB Tesla T4, with no OOM.

The particularly useful check for me was:

cache -> train -> checkpoint -> resume -> preview -> release preview memory -> resume training

That whole path worked.

Test details and caveats

Test setup

This was deliberately a small smoke test rather than a full training run:

  • Tesla T4, 15 GB
  • 512 px
  • 3 synthetic training images
  • 5 total training steps
  • fixed seed
  • short checkpoint/resume cycle
  • Turbo preview after step 4

For context, this also matches the intended Krea 2 workflow: Krea describes RAW as the base checkpoint for fine-tuning/LoRA training and Turbo as the fast inference model. The official Diffusers Krea 2 example follows the same RAW-for-training / Turbo-for-validation workflow.

Cache reuse

The first cache pass generated the latent/caption caches for all 3 images.

The second pass reported:

3/3 reused

with no images requiring re-encoding.

Roughly:

  • first pass: ~140 s
  • second pass: ~14 s

Those are just timings from this run, not benchmarks, but the reuse itself was clear.

I did not test cache invalidation after changing captions, resolution, dataset contents, etc.

Training / checkpoint / resume

The first short training segment completed 2 steps and saved a checkpoint.

I then resumed from that checkpoint and completed steps 3–4.

So this was not just checking that a checkpoint directory was created; I actually loaded it and continued training.

That distinction seems useful here because a training checkpoint normally represents more than just the LoRA weights. For example, Accelerate’s checkpointing machinery can persist model, optimizer, scheduler/RNG and other registered training state for continuation.

Preview → release → training again

After step 4 I generated a Turbo preview.

The actual image generation itself was only a small part of the total preview time; the cold model download/load dominated that first preview, so I would not use this as a preview-speed benchmark.

The more interesting part was memory handling:

  1. training checkpoint at step 4
  2. Turbo preview
  3. preview components released
  4. GPU usage returned to 0 MiB in the probe
  5. checkpoint 4 loaded again
  6. training continued to step 5

So the important result for me was not simply “VRAM went down”, but training actually continued afterwards.

LoRA sanity check

The final LoRA artifact had:

  • 320 tensors
  • all values finite
  • 160 lora_B tensors
  • 160/160 lora_B tensors non-zero

This is only a small artifact sanity check, not a quality evaluation. I did not run a meaningful real-dataset quality experiment, and 5 steps on 3 synthetic images obviously cannot establish training quality.

Small test-suite caveat

The probe also encountered a few errors in the local web/tunnel side of the test environment:

  • Cloudflare tunnel/DNS resolution
  • cloudflared reporting Text file busy
  • port 7860 already being in use

I would separate those from the training path itself rather than treat them as evidence that the Krea 2 training backend failed.

What I did not test

There are still several boundaries I did not cover:

  • the official krea/Krea-2-Raw Hub gate/auth path
  • Google Drive-backed / runtime-reset resume
  • a full browser first-run from dataset upload through final download
  • real-data training quality
  • long training runs
  • 1024 px or higher-load configurations
  • Hub upload/download from the UI

In particular, I used the Unsloth mirror because the official Raw repository is gated, so this should not be read as a test of the official Hub authentication path.

The mirror describes itself as an ungated mirror of krea/Krea-2-Raw and says the weights are unmodified:

So I think the result is best described as one additional T4 datapoint for the staged training workflow, rather than a complete clean-run certification.

Overall, though, the core path I was most interested in worked for me:

cache -> train -> checkpoint -> resume -> preview -> release preview memory -> resume training

Hopefully this gives you one more useful clean-run datapoint.