Skip to content

fix(kimi_k25): honour the quantization flag - #3633

Open
akx wants to merge 1 commit into
NVIDIA-NeMo:mainfrom
akx:k25-quant
Open

fix(kimi_k25): honour the quantization flag#3633
akx wants to merge 1 commit into
NVIDIA-NeMo:mainfrom
akx:k25-quant

Conversation

@akx

@akx akx commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

What does this PR do ?

Removes a hardcoded quantization = True in the Kimi-K2.5 state-dict adapter that ignored the checkpointer's flag, and fixes the dequantize_base_checkpoint auto-detection it was compensating for (composite models keep quantization_config on text_config).

Changelog

  • kimi_k25_vl/state_dict_adapter.py: drop the override; convert_single_tensor_to_hf
    now honours quantization= like the other adapters (Kimi-K3 is the in-tree reference).
  • _transformers/infrastructure.py: config_has_quantization() checks the top-level config and its sub-configs (sub_configs, text_config, language_config, llm_config)

Before your PR is "Ready for review"

Pre checks:

  • Make sure you read and followed Contributor guidelines
  • Did you write any new necessary tests?
    • Yep!
  • Did you add or update any necessary documentation?
    • none needed

Additional Information

@akx
akx requested a review from a team as a code owner August 22, 2026 15:31
@copy-pr-bot

copy-pr-bot Bot commented Aug 22, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

…ig in sub-configs

KimiK25VLStateDictAdapter.convert_single_tensor_to_hf read its `quantization`
kwarg and then unconditionally overwrote it with True.

The checkpointer passes the flag deliberately (True only for the base-checkpoint load
when checkpoint.dequantize_base_checkpoint is set, False for saves) so the override
made the INT4 layout the only loadable K2.5 checkpoint and re-packed experts to
INT4 on every consolidated save
(while the saved config.json has its quantization_config stripped).

The override masks a second problem: dequantize_base_checkpoint is
auto-resolved from hasattr(model.config, "quantization_config"),
but composite models keep it on the language sub-config (K2.5: text_config),
so the auto-detect returned False for exactly the checkpoint that needs it.
Resolve it through the sub-configs as well.

Net effect: INT4 K2.5 still loads with no config change (auto-detected),
BF16 K2.5 checkpoints become loadable,
and saves honour the flag like every other adapter (like Kimi-K3).

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Aarni Koskela <akx@iki.fi>
@HuiyingLi

Copy link
Copy Markdown
Contributor

/claude review

@claude

claude Bot commented Aug 22, 2026

Copy link
Copy Markdown
Contributor

LGTM

@HuiyingLi

Copy link
Copy Markdown
Contributor

Removing the hardcoded quantization = True makes sense. However, Automodel owns KimiK25VLConfig, and it is missing the upstream behavior that promotes text_config.quantization_config to the top level:

if getattr(self.text_config, "quantization_config", None) is not None:
    self.quantization_config = self.text_config.quantization_config

Can we fix the Kimi config instead of changing common infrastructure?

Also, BF16 export must remove the nested text_config.quantization_config; otherwise reload will still treat the saved BF16 weights as INT4. Please also test that the exported BF16 checkpoint can be loaded successfully.

@svcnvidia-nemo-ci svcnvidia-nemo-ci added the waiting-on-customer Waiting on the original author to respond label Aug 23, 2026
@akx

akx commented Aug 23, 2026

Copy link
Copy Markdown
Contributor Author

Can we fix the Kimi config instead of changing common infrastructure?

I'm all ears for a better fix!

Please also test that the exported BF16 checkpoint can be loaded successfully.

Unfortunately I don't currently have access to infrastructure to test this with right now (this was found as a side-effect of LoRA training on pre-emptible 2x 8xB200 nodes). I also found out the hard way that vLLM doesn't support LoRAs on Kimi K2.5 yet. 😅

@svcnvidia-nemo-ci svcnvidia-nemo-ci removed the waiting-on-customer Waiting on the original author to respond label Aug 23, 2026
@HuiyingLi

Copy link
Copy Markdown
Contributor

What about fixing it entirely in KimiK25VLConfig like this:

 elif isinstance(text_config, dict):
+    text_config = text_config.copy()
+    quantization_config = text_config.pop("quantization_config", None)
+    if quantization_config is not None:
+        kwargs.setdefault("quantization_config", quantization_config)
     text_config = DeepseekV3Config(**text_config)

@svcnvidia-nemo-ci svcnvidia-nemo-ci added the waiting-on-customer Waiting on the original author to respond label Aug 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-request waiting-on-customer Waiting on the original author to respond

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants