Local runtime decision tree

Muse Glimmer Troubleshooting Guide

LAST REVIEWEDSOURCE-BACKED

Direct answer

Start with the first stage that fails. Unknown architecture points to a build that does not recognize Muse Glimmer; a model that is recognized and then reports out of memory points to capacity or allocation. File-integrity and companion-artifact errors form separate branches. Do not treat every loader failure as VRAM pressure.

First diagnostic split

Did the runtime recognize the architecture?

Before model allocationUnknown architecture

Investigate build provenance and whether the runtime includes the merged Muse Glimmer support.

After recognitionAllocation or out of memory

Investigate selected artifacts, context, cache allocation, offload, buffers, and available memory.

During file handlingIntegrity or companion failure

Investigate exact byte counts, incomplete downloads, file roles, and expected artifact pairing.

Symptom-led checks

Follow one branch at a time

“Unknown architecture” or unsupported model type

This message occurs before a meaningful capacity verdict. Confirm the binary's revision, package date, and embedded runtime version. Upstream Muse Glimmer support was merged at commit62bf73d25c53b8161f8a22894d4f90c4aebbd7d0 on .

  1. Record the actual runtime revision rather than the wrapper application's marketing version.
  2. Check whether that revision contains the merged support or a later retained change.
  3. If it predates the merge, replace or rebuild through the runtime's documented process before testing memory.
The model is recognized, then fails with out of memory

Recognition means the architecture path was reached. Now account for the main weights, selected companions, KV cache, runtime buffers, operating-system use, and whether the runtime reserves the full configured context.

  1. Test with a lower context allocation before changing the model file.
  2. Remove optional companions that are not needed for the workload.
  3. Compare both active and conservative capacity boundaries instead of relying on filename size alone.
  4. Record offload, cache dtype, batch settings, driver, and build revision for any reproducible report.
Artifact integrity, truncation, or unexpected file size

Compare the local file's exact byte count and filename with the official repository tree. An interrupted, renamed, or unofficially repacked artifact can fail independently of memory capacity.

  1. Identify whether the file came from Meta's official model repository.
  2. Compare exact bytes, not a rounded “GB” label.
  3. Re-download through a trusted method if the byte count differs or the transfer was interrupted.
Text loads, but an image or speculative path fails

Treat this as a companion artifact branch. Image input uses the officialmmproj-kquant.gguf companion, while DFlash usesdflash-kquant.gguf. Confirm that the chosen runtime build documents the relevant integration; this page does not invent version-sensitive flags.

  1. Prove that the main model works before adding a companion.
  2. Add one capability at a time and record which artifact introduced the failure.
  3. Verify the companion file's exact bytes against the official tree.
The model runs, but performance is unexpectedly slow

Capacity fit and speed are different questions. Record prompt length, generated length, warm-up, runtime revision, CPU/GPU offload, cache settings, and whether a DFlash path is actually active before comparing results.

Meta's launch speed bars are configuration-specific claims, not a universal throughput expectation for every device or build.

Reproducible evidence

Capture enough context for someone else to diagnose it

Useful fields

  • Exact runtime and wrapper versions, build revision, operating system, and driver.
  • Main and companion filenames, exact byte counts, and source repository.
  • Available memory, offload plan, configured context, cache type, and batch settings.
  • Complete error text plus the last successful stage, with secrets and private paths removed.

Limitations

  • Error wording varies across llama.cpp revisions, wrappers, and downstream integrations.
  • These branches identify the next check; they are not a substitute for a build-specific issue report.
  • No unverified command flags are prescribed because companion and runtime interfaces can change.
  • A successful load does not validate output quality, speed, or full-context stability.

Troubleshooting evidence

  1. Official source
    Official Muse Glimmer 30B model card
  2. Official source
    Official Muse Glimmer 30B GGUF file tree
  3. Upstream source
    llama.cpp PR #26841: Muse Glimmer support
  4. Upstream source
    llama.cpp Muse Glimmer merge commit

LOCAL INDEX · SIX TASK PAGES

Search Muse Glimmer Wiki

Results are static internal links. Queries stay in this page and are cleared when the dialog closes.

↑ ↓ move · Tab follows native order · Enter opens the focused link