The transformers fallback keeps MusicGen working on a pod, but it is not the
same thing: audiocraft has melody conditioning and AudioGen, and transformers
has neither. Supporting it is not a matter of adding a requirement — it pins
torch==2.1.0, torchvision==0.16.0 and torchtext==0.16.0, and torch 2.1.0 has no
build for the CUDA these images run, so installing it beside the server would
leave the pod with no working GPU torch at all.

So it gets its own venv and is driven as a subprocess, the same answer
parler-tts and the OCR engines already use here. AudiocraftModel deliberately
wears audiocraft's own interface (set_generation_params / generate /
generate_with_chroma / sample_rate) so the generation path cannot tell whether
the library is in this process, in a venv next door, or absent.

The venv is baked into the audio image rather than built on first use: a pod is
rented by the second, and pip-installing a library during a cold start costs
more than carrying the layer.

Order of preference: in-process audiocraft, then the isolated venv, then
transformers — which needs no venv but cannot do melody.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY