GPTQModel/AWQ compatibility shim and tiny checkpoint evidence example

[MLPulse]

Hi GPTQModel maintainers,

I work on InvarLock, a verification/evidence tool for comparing an edited subject checkpoint against a fixed baseline. We have two optional integration examples that use GPTQModel, and I would appreciate a quick sanity check on a compatibility shim plus our GPTQ/AWQ wording.

Version / scope:

• InvarLock tag: v0.12.1
• InvarLock optional dependency floor: gptqmodel>=7.0.0
• Example type: small deterministic integration evidence, not a benchmark
• Generated runtime artifacts capture backend versions, runtime manifest, verifier result, and command lines

Examples:

• GPTQModel example:
  https://github.com/invarlock/invarlock/tree/v0.12.1/examples/integrations/gptqmodel

• AWQ example:
  https://github.com/invarlock/invarlock/tree/v0.12.1/examples/integrations/awq

The concrete compatibility question:

In the v0.12.1 examples, InvarLock calls _patch_gptqmodel_transformers_hub_compat() before importing GPTQModel. The helper patches the current Transformers / Hugging Face Hub environment like this:

• if transformers.utils.hub.create_repo is missing, set it from huggingface_hub.create_repo
• if transformers.utils.hub.list_repo_tree is missing, set it from huggingface_hub.HfApi().list_repo_tree

We added this because our current integration environment could otherwise fail during GPTQModel import/load under newer Transformers/Hub combinations.

What the examples do:

1. GPTQModel path:
   tiny deterministic Llama-style HF baseline -> GPTQModel quantization -> materialized GPTQ subject checkpoint -> InvarLock comparison through our hf_gptq adapter

2. AWQ path:
   tiny deterministic Llama-style HF baseline -> GPTQModel AWQ flow -> materialized AWQ subject checkpoint -> InvarLock comparison through our hf_awq adapter

The examples intentionally use tiny deterministic checkpoints rather than realistic model-quality examples. The goal is to keep the integration evidence cheap to rerun in CUDA/container CI and easy to inspect.

Questions:

1. Is this compatibility shim expected in current GPTQModel + Transformers/Hub environments, or is there a better way we should handle it?
2. Is "GPTQModel AWQ flow" the right way to describe the AWQ example?
3. Are there GPTQModel/AWQ metadata fields you would recommend capturing in external_edit_summary.json, checkpoint_refs.json, or backend_inventory.json for downstream reviewers?

What InvarLock is not claiming:

• not a benchmark of GPTQModel quality or speed
• not a production quantization recipe
• not upstream endorsement
• not deployment approval

The intended claim is narrower: "this subject checkpoint was produced by the external backend, loaded through the relevant adapter path, compared against the baseline, and packaged with verifier/report/runtime evidence."

Happy to adjust any wording that reads like endorsement or over-claiming.