Skip to content

Add weight-coverage walker to converter test suite#527

Merged
jlamypoirier merged 5 commits into
mainfrom
jlp_weight_coverage_walker
May 29, 2026
Merged

Add weight-coverage walker to converter test suite#527
jlamypoirier merged 5 commits into
mainfrom
jlp_weight_coverage_walker

Conversation

@jlamypoirier
Copy link
Copy Markdown
Collaborator

@jlamypoirier jlamypoirier commented May 27, 2026

Summary

  • Extends tests/models/test_converters.py with a per-fixture weight-coverage check: for each ModelTestingConfig with a checkpoint_format, materialise the Fast-LLM base model and assert every named_parameters() entry is consumed by some leaf WeightConverter emitted by base_model_converter_class.get_converters(config).
  • Tied parameters (e.g. MTP head output weights sharing a single LM-head weight) count as covered when any group member has a converter, matching the export-time behaviour where one shared weight is serialised once.
  • Fixes a long-standing aliasing bug in the gemma4 test fixture exposed by the walker: _gemma4_block_overrides / _gemma4_mixer_overrides were spread into both sliding_attention and full_attention blocks without per-use copy.deepcopy. Because Config._from_dict mutates its input via pop, the shared sub-dicts were emptied after the first block resolved, silently corrupting the second.

Why

The strict HF-side coverage check landed by #523 catches an HF dict carrying a key with no Fast-LLM consumer. There was no symmetric Fast-LLM-side check — a model parameter without a converter is silently skipped by ExternalStateDictCheckpointHandler._convert_state_dict, so its trained value is lost on HF export. This walker closes that gap statically.

What the walker surfaced

A gemma4 fixture aliasing bug: with the broken fixture, decoder.1 (full_attention block) was silently resolving to LayerNorm + output_scale.enabled=None despite the dict explicitly setting RMSNorm + enabled=True. The walker flagged 9 missing model params (LayerNorm biases, a spurious norm_2 module) and 1 phantom converter (output_scale declared for a block that had no such param). All symptoms of the aliasing bug, not converter declaration gaps. With per-spread deepcopy, both blocks resolve as intended and the walker is green with no xfail.

The underlying Config._from_dict mutate-input behaviour is a footgun that affects any caller spreading shared sub-dicts into multiple sibling configs — worth a follow-up but out of scope here.

Implementation notes

  • Uses bm.base_model_class(bm, DistributedConfig()) — CPU-only, ParameterMeta weights, no distributed setup or NCCL. Iterates named_parameters() for the canonical Fast-LLM name set.
  • Tied-group resolution uses object identity (id(parameter)) since ParameterMeta.tensor_name isn't assigned until stage setup, which we deliberately skip.
  • Walker is parametrised over every fixture with a checkpoint format (not just one per format) so format-specific variations get coverage. ~37 tests, all under 0.7s combined locally.

Test plan

  • Local: pytest -v tests/models/test_converters.py → 37 pass, 0 xfail
  • Cluster sweep with --models gemma4 over tests/models/: walker passes for gemma4; all other gemma4 tests (test_checkpoint_and_eval, test_resume, test_resume_frozen, test_model_simple, test_and_compare_model[*], test_frozen_weights) pass with the new resolved config; only failure is the pre-existing test_conversion[gemma4] torchscript coverage issue from Tool: evaluate layer-wise numerical-error propagation #525

🤖 Generated with Claude Code

jlamypoirier and others added 5 commits May 27, 2026 15:53
For each test fixture with a checkpoint format, materialise the Fast-LLM
base model (CPU, ParameterMeta — no distributed setup) and assert every
parameter is consumed by some leaf WeightConverter emitted by
base_model_converter_class.get_converters(config). Runtime-tied parameters
count as covered when any group member has a converter, matching export
behaviour. Gemma4 is xfailed against pre-existing coverage gaps in its
declarations.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Fold the xfail-or-bare decision into the parametrize comprehension so the
gemma4 case is visible in one place, and drop the now-redundant inline
``MODEL_CONFIGS`` import from the existing llama export test.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…xfail

The gemma4 fixture spread ``_gemma4_block_overrides`` and ``_gemma4_mixer_overrides``
into both ``sliding_attention`` and ``full_attention`` blocks without per-use
deepcopy. Dict-spread copies top-level keys but values are shared references, so
the two blocks' nested override dicts aliased. ``Config._from_dict`` then
mutates its input via ``pop`` when extracting fields, emptying the shared
sub-dicts after the first block's resolution. The second block silently fell
back to type defaults: LayerNormalizationConfig where the fixture said
RMSNormalizationConfig, ``output_scale.enabled=None`` where it said ``True``.

The walker xfail on ``test_format_weight_coverage[gemma4]`` had been blamed
(in PR description and the prior xfail reason) on three converter declaration
gaps; investigation showed those were all symptoms of the fixture aliasing.
With the per-spread deepcopy, both blocks resolve as intended (RMSNorm
everywhere, no LayerNorm biases, ``output_scale.enabled=True``), and the
walker passes for gemma4 without any converter changes.

The underlying ``Config._from_dict`` mutate-input behaviour is a footgun
beyond this fixture and is worth addressing separately.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
``BaseModelConfig.get_base_model`` calls ``base_model_class(...)`` then
``set_model_names(model)``, which populates every ``ParameterMeta.tensor_name``
by walking ``named_parameters()``. Going through that path drops the
``id()``-keyed mapping the walker used and matches the canonical engine
construction step that establishes the name correspondence converters consume
via ``fast_llm_name``.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…comment

Match the no-abbreviations convention for new code, and remove a comment that
restated its adjacent loop — the why-it-works (a shared weight is serialised
once on export) already lives in the function docstring.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@jlamypoirier jlamypoirier merged commit 9ea570e into main May 29, 2026
2 of 3 checks passed
@jlamypoirier jlamypoirier deleted the jlp_weight_coverage_walker branch May 29, 2026 16:40
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.

1 participant