Skip to content

chore: bump mlx-swift-lm for the non-indexed weights fix (#118) - #122

Merged
solderzzc merged 3 commits into
mainfrom
claude/bump-mlx-swift-lm-118-fix
Aug 6, 2026
Merged

chore: bump mlx-swift-lm for the non-indexed weights fix (#118)#122
solderzzc merged 3 commits into
mainfrom
claude/bump-mlx-swift-lm-118-fix

Conversation

@solderzzc

Copy link
Copy Markdown
Member

Fixes #118 by picking up SharpAI/mlx-swift-lm#43 (e60ccfd).

What the submodule fix does

loadWeights swept the model directory recursively, so any .safetensors in a subdirectory was merged into the model's weights. mlx-community/Qwen3.6-27B-OptiQ-4bit ships optiq/mtp.safetensors, which is not in model.safetensors.index.json. That made Qwen35.sanitize conclude the checkpoint stores zero-centered norms and add 1 to every RMSNorm weight — corrupting every normalization. The model loaded without error and generated noise.

Two changes upstream:

  1. When a weight index exists, only load the files it lists. MTP add-ons stay loadable under SWIFTLM_MTP_ENABLE.
  2. Apply the norm shift only when the weights actually look zero-centered — needed because with MTP explicitly enabled the add-on is loaded by design and the fingerprint fires again.

Verified on this commit

mlx-community/Qwen3.6-27B-OptiQ-4bit:

case before after
text path '},-idthlaf�(aren系_1!' 'Tokyo'
text path, SWIFTLM_MTP_ENABLE=1 noise 'Tokyo'
vision path Unhandled keys ["mtp"] loads past it¹

¹ then stops on that repo's missing processor_config.json — a separate packaging gap.

Log line confirming the filter: [loadWeights] skipping optiq/mtp.safetensors: not listed in model.safetensors.index.json

No behaviour change for mlx-community/Qwen3.5-4B-4bit or mlx-community/Qwen3.6-35B-A3B-4bit.

CI expectation

This does not turn CI green on its own. The four persistently red checks have separate causes, both now filed: #120 (Gemma 4 KV-shared layers, blocks the three integration_matrix jobs) and #121 (DFlash rope_theta).

🤖 Generated with Claude Code

solderzzc and others added 3 commits August 6, 2026 13:39
Picks up SharpAI/mlx-swift-lm#43 (e60ccfd), which stops loadWeights from
sweeping .safetensors that the weight index does not list, and guards the
Qwen35 RMSNorm shift on the weights actually looking zero-centered.

Fixes #118. mlx-community/Qwen3.6-27B-OptiQ-4bit previously loaded without
error and generated noise, because its out-of-index optiq/mtp.safetensors made
sanitize add 1 to every norm weight. Verified against that model on this
commit: the text path answers correctly with MTP disabled and enabled, and the
vision path no longer fails with `Unhandled keys ["mtp"]`. No change for
Qwen3.5-4B-4bit or Qwen3.6-35B-A3B-4bit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Re-points the bump at 717d77f9, which now carries both upstream fixes:
- #43: non-indexed .safetensors ignored + RMSNorm shift guard (fixes #118)
- #44: Gemma 4 KV-shared layers + quantizable scaled projections (fixes #120)

With #44 included, the audio and omni integration jobs pass locally; opencode
reaches its npm-install step (already continue-on-error). dflash remains red
until #121 is fixed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@solderzzc
solderzzc merged commit 8aad37d into main Aug 6, 2026
@solderzzc
solderzzc deleted the claude/bump-mlx-swift-lm-118-fix branch August 6, 2026 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OptiQ mixed-precision models produce garbage output (Qwen3.6-27B-OptiQ-4bit)

1 participant