• Stefy Lanza (nextime / spora )'s avatar
    fix the three payload failures the pod tests found · 95f168c7
    Stefy Lanza (nextime / spora ) authored
    None of these were placement or pod bugs: each image booted, pulled its model
    and got as far as executing. The remote machinery worked; the payloads did not.
    
    voice — torchcodec arrived as a transitive dependency of f5-tts, PyPI served the
    CUDA-13 build, and it died with 'libnvrtc.so.13: cannot open shared object file'
    after loading the model. The same class of bug as the torch pin: a CUDA-coupled
    package escaping the index. It now installs from the CUDA index with the rest,
    resolving to torchcodec 0.11.1+cu128.
    
    audio — 'No module named audiocraft'. audiocraft pins an old torch, so putting
    it in the image would drag torch backwards and undo the CUDA pin. transformers
    ships MusicGen itself, so a pod serves it through transformers instead; an
    install that has audiocraft still uses it. Melody conditioning stays
    audiocraft-only rather than silently doing something different.
    
    video — 'TextToVideoSDPipeline.__call__() got an unexpected keyword argument
    callback_on_step_end'. Older diffusers pipelines do not take it and raise inside
    the call, minutes in, with the model loaded and the GPU paid for. The kwarg is
    now added only when the pipeline's signature accepts it. The try/except that
    used to wrap it caught nothing: assigning to a dict never raises. This one bites
    local generations too, not just pods.
    Co-Authored-By: 's avatarClaude Opus 5 (1M context) <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY
    95f168c7
Dockerfile.capability-base 3.19 KB