Production, 2026-10-28: Krea-2-Turbo answered one request and then 500ed.

    RuntimeError: Expected all tensors to be on the same device, but got
    index is on cuda:0, different from other tensors on cpu

The offload moved the encoder to the CPU and the pipeline is CACHED, so the
next request met an encoder that was no longer where encode_prompt indexes.
_free's docstring even said the encoder "waits in host RAM ... the next
request needs it again" -- and nothing ever brought it back.

What turned that into a 500 rather than a skipped optimisation: the side
effect outlives this function. The bail-out path returns the original kwargs
and lets the pipeline generate "the ordinary way", but the ordinary way calls
the SAME encoder, so it hit the same mismatch and the request failed anyway.
A fallback that leaves the thing it fell back to broken is not a fallback.

So the offload is a per-request cycle -- bring the encoder on, encode, move it
off -- and every bail-out restores the encoder first, because each one hands
the request to a path that needs it on the GPU.

The regression test drives a pipeline that really refuses to encode off-device
and asserts the SECOND request still works; without the restore it reproduces
the production message exactly. A second test pins the weaker promise that any
bail-out leaves the encoder where the ordinary path can use it.

Found by the operator mid-render, not by the suite: every check so far ran one
request per model against a freshly started engine, which is the one case that
cannot fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC