[Bug]: Repo with overlay safetensors (superseded tensors) fails duplicate-name check - index mapping not honored

[montana-rs]

Commit or version

12a5c46

Environment

Fedora 44, x86_64, Intel i5-12600KF, 16 GiB RAM, 2x RTX 3060 12GB (engine ran CPU-only for this model), Samsung 860 EVO 1TB SATA SSD (488 MB/s read). Model: DeepSeek V4 engine, overlay-carrying checkpoint (~167GB, 49 shards + 1 overlay).

Reproduction steps

1. Obtain a checkpoint that ships an overlay remap in model.safetensors.index.json: the index maps N tensor names to a separate model-overlay-*.safetensors which supersedes same-named tensors still physically present in the base shards. (Community abliterated checkpoints are distributed this way, e.g. huihui-ai's DeepSeek-V4-Flash-abliterated.)
2. Load it: coli run --model ...
3. Engine refuses with: "tensor 'layers.0.attn.wo_b.scale' is also indexed from shard 'model-00002-of-00048.safetensors' - duplicate tensor name across indexed shards, refusing"

Expected behavior

The engine should honor the safetensors index mapping: tensors whose authoritative location (per the checkpoint's own index) is the overlay are read from the overlay; the stale base-shard copies are ignored. Failing that, the error should suggest the resolution.

Actual behavior and logs

Duplicate-name check (st.h) treats any repeated name as fatal regardless of what the index says, so the checkpoint cannot load at all. HF transformers loads the same checkpoint fine because it honors the index.
Workaround (verified end-to-end): script that rewrites the base shards removing the superseded tensors, leaving the overlay copies as the only instances. After that the engine loads and runs correctly - full generation run verified (coherent output, expert hit-rate 57% warming). Happy to share the script.
Note: I understand the duplicate check guards against silent wrong-shard reads - the ask is to resolve the ambiguity via the checkpoint's own index mapping rather than refusing.

[JustVugg]

Thanks, the reproduction and the note on why the check exists made this straightforward. Fix in #1480: when two indexed shards carry the same tensor name, model.safetensors.index.json decides. The copy the index maps the name to is read and the stale one is ignored, in whichever order the directory scan meets them, and one line reports how many names were resolved that way. The index is parsed lazily on the first duplicate only, so a normal container pays nothing. Without an index, or with an index that does not list the name or maps it to a third shard, the refusal stays and now says why the index could not settle it.

Your rewritten shards keep working too: with no duplicates the index is never consulted. If you can try the branch on the abliterated checkpoint before the rewrite, the line to look for is [st] N tensor name(s) present in two shards, resolved by model.safetensors.index.json.

[montana-rs]

Verified on the exact checkpoint from this report:

• Original duplicate-carrying shard (model-00002-of-00048.safetensors) restored over our rewritten copy; overlay and index unchanged.

• PR-branch engine (57e5115) loads the checkpoint that v1.11.0 refuses, with the expected line:

  [st] 2 tensor name(s) present in two shards, resolved by model.safetensors.index.json

  (count is 2, not the full remap, because only shard 2 was restored to its duplicate-carrying state; the other 45 shards remain rewritten)

• Load proceeds normally: dense trunk resident (6.27 GiB), chat server up, API responds.

My rewritten shards also still load, as predicted --the index is never consulted when no duplicates exist.

happy to test anything else around this path!

[JustVugg]

Merged into dev (#1480, merge commit b22d83b). If you can, please try the abliterated checkpoint as distributed, without the shard rewrite, on a dev checkout: the expected line at load is [st] N tensor name(s) present in two shards, resolved by model.safetensors.index.json. Any surprise, reopen or comment here.

[montana-rs]

Both dev-branch checks pass on our setup:

• Abliterated checkpoint loaded as distributed (original duplicate-carrying shard, no rewrite): [st] 2 tensor name(s) present in two shards, resolved by model.safetensors.index.json (the copy the index maps each name to is read, the other ignored) - count 2 because only shard 2 currently carries its duplicates; the other 45 shards remain rewritten from our earlier workaround.
• Our previously rewritten shards also load, as expected.

[JustVugg]

Fixed by #1480, merged into dev on 2026-09-14 (merge commit b22d83b); ships in the next release. Closing here; reopen if the overlay checkpoint still misbehaves on a dev build.