Add weight-coverage walker to converter test suite#527
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tests/models/test_converters.pywith a per-fixture weight-coverage check: for eachModelTestingConfigwith acheckpoint_format, materialise the Fast-LLM base model and assert everynamed_parameters()entry is consumed by some leafWeightConverteremitted bybase_model_converter_class.get_converters(config).gemma4test fixture exposed by the walker:_gemma4_block_overrides/_gemma4_mixer_overrideswere spread into bothsliding_attentionandfull_attentionblocks without per-usecopy.deepcopy. BecauseConfig._from_dictmutates its input viapop, 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
gemma4fixture aliasing bug: with the broken fixture,decoder.1(full_attention block) was silently resolving to LayerNorm +output_scale.enabled=Nonedespite 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_scaledeclared 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_dictmutate-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
bm.base_model_class(bm, DistributedConfig())— CPU-only,ParameterMetaweights, no distributed setup or NCCL. Iteratesnamed_parameters()for the canonical Fast-LLM name set.id(parameter)) sinceParameterMeta.tensor_nameisn't assigned until stage setup, which we deliberately skip.Test plan
pytest -v tests/models/test_converters.py→ 37 pass, 0 xfail--models gemma4overtests/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-existingtest_conversion[gemma4]torchscript coverage issue from Tool: evaluate layer-wise numerical-error propagation #525🤖 Generated with Claude Code