fix(models): read the nested quantization block in deepseek::ModelArgs

[rapsealk]

Summary

deepseek::ModelArgs silently dropped the MLX-style nested "quantization": {"group_size": .., "bits": ..} block — the struct only declared flat top-level group_size / bits fields, so the inheritance the three DeepSeek-OCR loaders perform in vlm_deepseekocr.rs accomplished nothing and the accessors always fell back to 64 / 4. This adds the nested field (reusing deepseek_v2::Quantization, whose presence is why the byte-identical inheritance in vlm_deepseek_vl2.rs already worked) and makes group_size() / bits() prefer nested-then-flat-then-default.

Related issues

Closes #975

Type of change

• fix — bug fix

Test plan

• New regression tests in src/models/deepseek_tests.rs:
  • model_args_reads_inherited_nested_quantization_block — drives the same language_config insert the OCR loaders perform (including the extra "mode" key real checkpoints carry) and asserts the declared pair survives deserialization.
  • model_args_reads_flat_quantization_keys — the flat spelling keeps loading with its declared values.
  • model_args_nested_quantization_beats_flat_keys — pins the documented precedence.
  • model_args_defaults_without_quantization_declaration — no declaration keeps 64 / 4, which is what the two in-tree DeepSeek-OCR checkpoints rely on.
• cargo fmt --all -- --check
• cargo clippy --all-targets --features metal,accelerate -- -D warnings
• cargo test --profile test-fast --features metal,accelerate models::deepseek / vision::unlimited_ocr — 7 + 3 passed (full --release suite not run on this machine; see notes)
• Validated with a real checkpoint: not run — no Metal toolchain on this machine (CPU-only build via MLXCEL_BUILD_METAL=OFF). Both in-tree OCR checkpoints declare exactly {group_size: 64, bits: 4}, i.e. the fallback values, so the resolved pair — and therefore OCR output — is unchanged for them by construction. Happy to run the confirmation if a maintainer prefers it before merge.

Notes for reviewers

• DeepSeekModel::load needs no change: it deserializes the whole config.json into ModelArgs, so a plain deepseek checkpoint's nested block is now picked up through the same field.
• Issue fix(models): deepseek::ModelArgs silently drops an inherited quantization block #975's optional item 3 (factoring the ~dozen private Quantization copies under src/models/ into one shared struct) is deliberately left out — that's a cross-family refactor and a separate PR per the one-logical-change rule. Reusing deepseek_v2::Quantization here at least stops these two siblings from diverging again.
• One nuance inherited from deepseek_v2: Quantization's fields are required, so a quantization block missing group_size/bits now fails deserialization instead of being ignored. That matches deepseek_v2's existing behavior for the same block and MLX exports always write both keys.

Checklist

• PR title uses a Conventional Commits prefix
• One logical change per PR
• Updated docs/ — not needed (no user-facing behavior change for in-tree checkpoints)
• Updated // Used by: ... comments — no shared function modified
• No secrets, credentials, or .env files committed

🤖 Generated with Claude Code

[inureyes]

Thanks for catching this, the diagnosis here is exactly right and matches what #975 describes.

I have opened #1016 for the same issue and it supersedes this PR, so I wanted to explain rather than leave it hanging. Three things pushed it toward a separate branch instead of building on this one:

• The shared type. fix(models): deepseek::ModelArgs silently drops an inherited quantization block #975 asks specifically that no sixtieth private Quantization struct be added, and that models::config::QuantizationArgs either be adopted or the reason recorded in code. This PR reuses deepseek_v2::Quantization, which is reasonable but keeps the family-local copies growing. fix(models): read the declared quantization block in deepseek::ModelArgs #1016 adopts the shared type, which also removes its "no production callers yet" status.
• Optional fields and the declared mode. deepseek_v2::Quantization has required group_size / bits and no mode, so a partially declared block becomes a hard deserialization failure (as your PR body notes) and the declared mode stays invisible to this family. QuantizationArgs keeps all three optional and its get_mode() runs the allowlist added in fix(core): bound the declared quantization mode string, not just group_size and bits #973 / fix(core): bound the declared quantization mode string at load #1006, both of which landed after this branch's base. fix(models): read the declared quantization block in deepseek::ModelArgs #1016 uses that to refuse a block-float mode at load, which this affine-only family would otherwise reinterpret.
• Verifying all three loaders. The acceptance criteria ask for the inheritance to be checked at each of the three DeepSeek-OCR sites. fix(models): read the declared quantization block in deepseek::ModelArgs #1016 collapses the triplicated language_config fixup into one helper and tests it once per loader.

It is also a fork branch, so completing it in place would have meant force-pushing over your work.

For what it is worth, the real-checkpoint runs confirmed your reasoning about the in-tree checkpoints: models/deepseek-ocr-4bit and models/deepseek-ocr-2-4bit both declare exactly {group_size: 64, bits: 4}, and their OCR output is byte-identical before and after.

[inureyes]

Closing as superseded by #1016, which merged as a86e6340a. The diagnosis in this PR was correct and is credited in the comment above; the separate branch was needed because this one predates #1006 (the quantization-mode allowlist) and because completing it in place would have meant force-pushing over your fork. Thanks for finding it.