prepare-minimax-h3-8bit.vpipeline: quant-dit src_model is the bare repo id, but model_variant registers it as Comfy-Org/MiniMax-H3-FL2VA, so quantization always skips

[roy-vitrainer]

docs/pipelines/prepare-minimax-h3-8bit.vpipeline can never quantize. The
fetch stage registers the model under one name and quant-dit asks for a
different one, so the source is never found and the cascade drains silently.

This is the only prepare pipeline in docs/pipelines/ with the mismatch; the
two Ref2VA files already do the right thing.

Environment

• Vpipe: 0.1 (354e6f9*0)
• macOS: 26.5.1
• Hardware: Apple Silicon M5 Pro, 48 GB unified memory
• Model: Comfy-Org/MiniMax-H3, FL2VA partition, bf16 source repack

The mismatch

fetch selects the FL2VA partition with model_variant, and sets no
model_key:

"model_path": "Comfy-Org/MiniMax-H3",
"model_variant": "fl2va",

With no model_key, registration falls back to the catalogue name, which is
Comfy-Org/MiniMax-H3-FL2VA. Confirmed from /api/models/installed:

{
  "key": "Comfy-Org/MiniMax-H3-FL2VA",
  "hf_path": "Comfy-Org/MiniMax-H3",
  "model_type": "minimax-h3-fl2va"
}

But quant-dit asks for the bare repo id:

"src_model": "Comfy-Org/MiniMax-H3",

model-quantize resolves src_model with model_dir_available
(stages/model-registry.h:74), a registry-key lookup plus a stat, so the bare
id never matches:

[ERROR] ModelQuantizeStage('quant-dit'): source model 'Comfy-Org/MiniMax-H3'
        is not available (not downloaded yet?); skipping quantization

stages/model-quantize-stage.cc:2119 takes the missing-source branch and calls
signal_done() without emitting a summary, so quant-enc and
remove-dit-intermediate never fire. The pipeline drains with no output and no
further error.

Reproduction

Two single-stage pipelines, identical except for src_model, with
skip_existing: true and output_name pointed at an already-quantized model so
no real work runs:

{
  "id": "probe",
  "stages": [
    {
      "id": "quant-probe",
      "type": "model-quantize",
      "config": {
        "src_model": "Comfy-Org/MiniMax-H3",
        "output_name": "local/MiniMax-H3-FL2VA-8bit",
        "target": "dit",
        "bits": 8,
        "group_size": 64,
        "quant_modulation": true,
        "skip_existing": true
      }
    }
  ]
}

With src_model: "Comfy-Org/MiniMax-H3":

[ERROR] ModelQuantizeStage('quant-probe'): source model 'Comfy-Org/MiniMax-H3'
        is not available (not downloaded yet?); skipping quantization

With src_model: "Comfy-Org/MiniMax-H3-FL2VA":

[INFO] ModelQuantizeStage('quant-probe'): quantizing
       'Comfy-Org/MiniMax-H3-FL2VA' -> 'local/MiniMax-H3-FL2VA-8bit' (8-bit g64)
[INFO] ModelQuantizeStage('quant-probe'): output '...MiniMax-H3-FL2VA-8bit'
       already has a quantized diffusion_models; skipping

Why it is easy to miss

Three things compound:

1. The failure is an [ERROR] line in the middle of a run that then exits
   normally. There is no non-zero exit or final failure summary.
2. Re-running exits in under a millisecond, because fetch short-circuits on
   the already-registered model ('...' already registered; set overwrite_existing=true to refresh. Done.). So a second attempt looks like a
   no-op success rather than a repeat of the same failure.
3. It only bites after the 115 GB download has completed, which is 90+ minutes
   in.

Suggested fix

Match the Ref2VA prepare pipelines, which set model_key and point src_model
at it:

"model_key": "Comfy-Org/MiniMax-H3-Ref2VA",
"src_model": "Comfy-Org/MiniMax-H3-Ref2VA",

So for FL2VA:

         "model_path": "Comfy-Org/MiniMax-H3",
         "model_variant": "fl2va",
+        "model_key": "Comfy-Org/MiniMax-H3-FL2VA",
         "hf_token": "",
@@
-        "src_model": "Comfy-Org/MiniMax-H3",
+        "src_model": "Comfy-Org/MiniMax-H3-FL2VA",
         "output_name": "local/MiniMax-H3-FL2VA-8bit-dit",

The src_model change alone is sufficient. The model_key line is a no-op on
the current catalogue, since the fallback already yields the same name; it is
there so the key is pinned in the pipeline rather than depending on catalogue
naming, matching the Ref2VA files.

Happy to open a PR for this if useful.

A secondary point on the error message

Making the resolver accept the bare repo id would be wrong: Comfy-Org/MiniMax-H3
publishes both the FL2VA and Ref2VA partitions, they ship byte-identical DiT
configs and are told apart by packaging, and both register with
hf_path: Comfy-Org/MiniMax-H3. So the bare id is genuinely ambiguous and
refusing it is correct.

The message is what costs the time:

source model 'Comfy-Org/MiniMax-H3' is not available (not downloaded yet?)

The files were on disk. The problem was an unregistered key, and
(not downloaded yet?) points at the download instead of the name. Something
like "not registered in the models DB (did you mean 'Comfy-Org/MiniMax-H3-FL2VA'?)",
listing registry keys whose hf_path matches, would have made this immediate.
Separate change, and I have not written it.

Also, docs

docs/MINIMAX-H3.md references prepare-minimax-h3-4bit.vpipeline, which is
not in docs/pipelines/. The raw URL 404s, and curl -O writes a 14-byte file
containing 404: Not Found rather than failing, so it is easy to end up with a
file that is not JSON. 8-bit appears to be the only FL2VA option; Ref2VA has
both.

Seen at 354e6f9 (2026-08-27).