MiniMax H3 PR 12: minimal starter bundle (~59 GB) via explicit-file installer sources

[lstein]

Summary

PR 12 of the MiniMax H3 stack (base: minimax-h3/10-viewer-video-reveal, #149). Makes H3 installable by ordinary users without pulling hundreds of gigabytes: a starter bundle whose three entries total ~59 GB — versus ~498 GB for a naive MiniMaxAI/MiniMax-H3 pull, or ~120 GB for the full working set.

Entry	Source	Size
MiniMax H3 Components	MiniMaxAI/MiniMax-H3::modular_model_index.json+transformer/config.json+tokenizer+processor+vae+audio_vae	~11 GB
MiniMax H3 Text Encoder (int8)	Comfy-Org/MiniMax-H3::text_encoders/qwen3vl_32b_minimax_h3_int8_convrot.safetensors	~27 GB
MiniMax H3 FL2VA Transformer (int8, pruned)	Comfy-Org/MiniMax-H3::diffusion_models/minimax_h3_fl2va_pruned_int8_convrot.safetensors	~21 GB

The transformer entry depends on the other two, so a one-click install yields a working video+audio setup. The int8 single files are the ones PRs #145/#146 taught the loader node to consume; the slim folder supplies everything else the loader sources from the main model (tokenizer, processor, video VAE, audio VAE — schedulers are constructed from vendored constants and need no files).

1. Installer: explicit-file entries in ::a+b sources

The slim folder was previously inexpressible (see the TODO this PR deletes): filter_files kept only files inside listed subfolders, so the root modular_model_index.json was dropped and identification failed. Now an entry in a multi-entry list that names a repo file exactly is an explicit request: included verbatim, bypassing the extension prefilter, variant scoring and the config-only-folder pruning (which would otherwise drop the bare transformer/config.json). _multifile_download places explicit files at their repo-relative paths — the pre-existing relative_to() matching would have flattened transformer/config.json to the model root, because relative_to() of a path against itself yields ..

Deliberately scoped: single-entry sources and pure-folder lists (the five existing ::text_encoder+tokenizer-style starter sources) select the same files and land in the same layout as before.

2. Probe: components_only on the H3 diffusers config

True when transformer/ holds no weight shards. The slim source still downloads transformer/config.json (a few KB), so the existing variant identification (FL2VA vs Ref2VA) works unchanged and the folder probes as a normal minimax-h3/fl2va main. New identification fixture for the slim layout; the full-layout fixture now also asserts components_only: false.

3. Loader guards

Requesting the Transformer or TextEncoder submodel from a components-only install now fails with "select a single-file … in the MiniMax H3 Model Loader" instead of a cryptic missing-shard error from inside diffusers/transformers.

4. Linear UI readiness

A components-only main blocks enqueue (Generate and Canvas) until both single-file overrides are selected, following the Krea-2 non-diffusers precedent. The Advanced-settings selects from #145/#146 are the fix the messages point at.

License

The starter entries live in their own commit (feat(models): MiniMax H3 starter bundle…) so a release can drop them: the MiniMax H3 Community License restricts use by territory (excludes the US, EU, UK and South Korea, extending to outputs) and requires prominent "MiniMax H3" attribution — kept verbatim in every name/description.

Review

A fresh-context adversarial review differential-fuzzed old-vs-new filter_files across three repo corpora and every pre-existing source form (0 mismatches), traced both path conventions to every caller, round-tripped the new source strings through the real parser, and attacked the resume/restart mappings, probe computation, loader guards, readiness narrowing and starter integrity. Two MED findings, both fixed in the third commit:

1. The launchpad's initial-state model picker (unlike the generation accordion) didn't filter H3 single-file transformers out of the primary-main list, so a fresh bundle install invited selecting the transformer as the main model — enqueue succeeded and the queue item failed at load. The filter is now a shared isSecondarySlotMainModelConfig() used by both pickers.
2. Uninstalling a selected single-file override left a stale key in params that passed the new readiness gate and failed at invoke time; a modelsLoaded handler now clears the two override params when their model disappears (Krea-2 precedent).

Deliberately left (LOW/INFO, with reasoning): the synthesized install-folder name changes for dotted folder entries (v1.5 → v1) — selection and layout are unaffected and no such source exists; explicit files covered by a co-listed nested folder entry inherit the folder's pre-existing flattening — no production source lists nested folders; a single-entry explicit non-weights file (repo::transformer/config.json alone) still selects nothing — pre-existing single-entry semantics, and the shipped source always uses the multi-entry form.

Testing

• filter_files: 5 new cases (slim selection, files-only lists, prefilter bypass for weights-file entries, nonexistent entries, pure-folder regression).
• _multifile_download: layout test pinning explicit-file placement and the synthesized folder name.
• Loader guards: 3 boundary tests (components-only raises for both submodels; weights present passes through).
• Identification: new slim-layout fixture (components_only: true), full suite green (91).
• Frontend: pnpm lint:tsc, eslint, prettier, vitest (1725) green; openapi.json/schema.ts regenerated for the new config field.
• Manual (queued, will report here): install the bundle from Starter Models on a clean instance; verify the slim folder probes as minimax-h3/fl2va (components), readiness blocks until both overrides are picked, and t2v produces a video with audio.

🤖 Generated with Claude Code