• Stefy Lanza (nextime / spora )'s avatar
    stop discarding the reason a GGUF would not load, and give every TTS backend the card's path · da335aeb
    Stefy Lanza (nextime / spora ) authored
    **Five models "won't load" and llama.cpp had said why.** The load-phase log
    callback printed only lines matching a keyword list about layers, buffers and
    devices. llama.cpp writes its diagnosis -- an unknown architecture, a missing
    tensor -- in none of those words, so it matched nothing and was dropped, while
    llama-cpp-python raised its one generic sentence: "Failed to load model from
    file: <path>". That string is all the client got, and all the log had.
    
    So every line is now kept in a 60-line ring, lines that look like a diagnosis
    are printed whether or not they mention a buffer, and the raised error carries
    llama.cpp's own words. A model this build genuinely cannot read is no longer
    indistinguishable from one that did not fit, a bad path, or a corrupt download.
    
    The retry ladder stops earlier too. It exists to answer one question -- does it
    fit? -- by moving layers to the host, and an attempt with NO layers on the GPU
    has already answered it. Three MTP/next-N checkpoints each burned six attempts
    down to n_gpu_layers=0, every one failing in a fraction of a second with the
    same message: 18 loads whose only effect was to push the reason further up the
    log. (What those three have in common is visible in their metadata --
    qwen35.nextn_predict_layers=1, blk.N.layer_output_scale.weight -- and with the
    reason no longer discarded, the next attempt will say so outright instead of
    leaving it to be inferred.)
    
    **XTTS and parler were handed an alias instead of a repo id.** _load_backend
    passed `model_path or model_name` to Kokoro and the bare `model_name` to
    everyone else, and for a card registered under an alias that name is the alias.
    Each isolated worker then failed in its own vocabulary, neither mentioning the
    cause:
    
      XTTS:   "XTTS venv could not load 'XTTS-v2': ValueError: not enough values to
              unpack (expected 4, got 1)" -- coqui splits a model name into
              type/lang/dataset/model, and the bare alias has no separator at all.
      parler: "parler-tts-mini-multilingual is not the path to a directory
              containing a file named config.json" -- the org is missing, so the
              real repo is never looked up, and the worker reports a model that IS
              cached as one to download first.
    
    Every backend that resolves a checkpoint now gets the path. The XTTS worker's
    own translation table is fixed to match on the last path segment as well, since
    it is reached by other callers too: it required a "/" before, which is precisely
    the case that does not apply.
    Co-Authored-By: 's avatarClaude Opus 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC
    da335aeb
Name
Last commit
Last update
..
admin Loading commit data...
api Loading commit data...
backends Loading commit data...
broker Loading commit data...
cluster Loading commit data...
compose Loading commit data...
frontproxy Loading commit data...
models Loading commit data...
ocr Loading commit data...
openai Loading commit data...
pipelines Loading commit data...
pydantic Loading commit data...
queue Loading commit data...
tasks Loading commit data...
util Loading commit data...
__init__.py Loading commit data...
cli.py Loading commit data...
config.py Loading commit data...
hf_cache.py Loading commit data...
main.py Loading commit data...
ocr_fleet_workers.py Loading commit data...
platform_paths.py Loading commit data...
system_app.py Loading commit data...