Skip to content

Conversation

@shengliangxu
Copy link
Contributor

@shengliangxu shengliangxu commented Dec 6, 2025

What does this PR do?

Type of change: ?

new feature Jira: [OMNIML-3212]

Overview: ?

  1. start a new config system using yaml/yml files. The config system adopts Hydra style override, using the defaults tag, but we implement it by ourselves by simply merging the configs using OmegaConf

  2. implement the quantization configs using the new config system, but not actually in use.

  3. make sure the configs from the new config system match the exisiting configs

  4. pipe through config_file based hf_ptq script

  5. testted hf_ptq using both builtin and extenal config file

The config files are not actually in use in this PR, except the hf_ptq.py script accepts a quantization config name corresponding to a config filename

Testing

python examples/llm_ptq/hf_ptq.py \
    --pyt_ckpt_path=Qwen/Qwen3-8B \
    --export_path=qwen3-8B_fp8 \
    --qformat=fp8 \
    --kv_cache_qformat=fp8 \
    --calib_size=16 \
    --batch_size=0 \
    --trust_remote_code \
    --export_fmt=hf
python examples/llm_ptq/hf_ptq.py \
    --pyt_ckpt_path=Qwen/Qwen3-8B \
    --export_path=nvfp4_awq \
    --qformat=nvfp4_awq_full \
    --kv_cache_qformat=fp8 \
    --calib_size=16 \
    --batch_size=0 \
    --trust_remote_code \
    --export_fmt=hf

@copy-pr-bot
Copy link

copy-pr-bot bot commented Dec 6, 2025

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@codecov
Copy link

codecov bot commented Dec 6, 2025

Codecov Report

❌ Patch coverage is 76.47059% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.52%. Comparing base (9409412) to head (c5f657e).
⚠️ Report is 6 commits behind head on main.

Files with missing lines Patch % Lines
modelopt/torch/opt/config.py 31.57% 13 Missing ⚠️
modelopt/torch/quantization/config.py 93.87% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #657      +/-   ##
==========================================
- Coverage   74.66%   74.52%   -0.15%     
==========================================
  Files         183      183              
  Lines       18550    18467      -83     
==========================================
- Hits        13851    13763      -88     
- Misses       4699     4704       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@shengliangxu shengliangxu force-pushed the shengliangx/config_yaml branch 3 times, most recently from d5cba37 to 9c326f8 Compare December 9, 2025 17:59
@shengliangxu shengliangxu self-assigned this Dec 11, 2025
1. start a new config system using yaml/yml files. The config system
   adopts Hydra style override, using the defaults tag, but we implement
   it by ourselves by simply merging the configs using OmegaConf

2. implement the quantization configs using the new config system, but
   not actually in use.

3. make sure the configs from the new config system match the exisiting configs

4. pipe through config_file based hf_ptq script

5. testted hf_ptq using both builtin and extenal config file

Signed-off-by: Shengliang Xu <[email protected]>
and they block custom quantization config

Signed-off-by: Shengliang Xu <[email protected]>
Signed-off-by: Shengliang Xu <[email protected]>
@shengliangxu shengliangxu force-pushed the shengliangx/config_yaml branch from 9c326f8 to 2650434 Compare December 18, 2025 01:06
@shengliangxu shengliangxu marked this pull request as ready for review December 18, 2025 01:32
@shengliangxu shengliangxu requested review from a team as code owners December 18, 2025 01:32
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we keep this in modelopt/config/quantization/ instead of modelopt/torch/quantization/config?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on this. Since we already have modelopt/torch/quantization/config.py, can we move them to modelopt/torch/quantization/config_yamls/ or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I want to make the builtin configs first class citizens. The configs are data, I want to put all built-in configs in one centralized place rather than scatter them around in code folders.

And I plan to convert all modelopt configs to be config file based.

The quantization configs are now under modelopt/config/quantization/, other configs will be placed in correponding sub-folder of modelopt/config.

The actual sub-dirs of each config type may change, but overall the idea of put all of them in a central place will be kept.

@realAsma
Copy link
Contributor

Overall design looks great to me.

Can we make the yaml file flexible to add more methods such as auto_quantize or sparsity? the sparsity + quantization will be very important in future Cc @kaix-nv

Should we have one more level to the yaml file based on the high level API:

quantize: # Arguments to mtq.quantize API
     quant_cfg:
          ....

     algorithm:
        ....

sparsify: # Arguments to mts.sparsify
    config:
        ....

@shengliangxu
Copy link
Contributor Author

Overall design looks great to me.

Can we make the yaml file flexible to add more methods such as auto_quantize or sparsity? the sparsity + quantization will be very important in future Cc @kaix-nv

Should we have one more level to the yaml file based on the high level API:

quantize: # Arguments to mtq.quantize API
     quant_cfg:
          ....

     algorithm:
        ....

sparsify: # Arguments to mts.sparsify
    config:
        ....

This is just 1/N of the changes. The use of the new config system is just limited to one use case just for illustration. More broader adaption will be in follow-up changes.

@shengliangxu
Copy link
Contributor Author

The more I think about it, the more I feel it may be worth a design review of itself. I'll put together a more thorough design doc and share it.

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.

4 participants