quark-torch-llm-ptq-workflow
SkillAI & modelsTorch LLM PTQ workflow for AMD Quark — from model selection to quantized output. Use when the user wants a complete PTQ pipeline: model inspection, quantization planning, script generation, and optional execution. Stops at the quantized output. Trigger for "quantize my model", "run PTQ", "run model quantization", "full quantization pipeline", "quantize Llama/Qwen/Mistral with FP8/INT4", or any request that spans more than one PTQ step. When in doubt between routing to an atomic skill vs. the workflow, prefer this workflow if the user's request implies they want to go from model to quantized output.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the quark-torch-llm-ptq-workflow skill
What this skill tells your AI
The instructions your AI receives, as published by amd/quark in .claude/skills-impl/l2-workflows/torch/quark-torch-llm-ptq-workflow/SKILL.md and read by ahel’s review.
Purpose
Chain the full PTQ path — model intake → quantization planning → manifest generation → confirmed execution — while keeping the user informed at each checkpoint. This workflow orchestrates the atomic skills so the user does not have to manually chain them. It stops at the quantized output; for a run that also validates and evaluates the result, use the quark-torch-llm-ptq-eval recipe.
Inputs
- Model path (HuggingFace ID or local directory)
- User goal (target precision, hardware, accuracy)
- Output directory for the quantized model
session_context.jsonfor user goal and constraintsenv_context.jsonfor hardware factsworkspace_context.jsonfor validated pathspytorch_install_result.jsonandquark_install_result.jsonto confirm runtime is ready
Outputs: run_manifest.yaml
Records the executed command and config. Side artifacts: quantized model files written to the user's output directory. The manifest is built in Step 3 above.
Schema: run_manifest.schema.json
Interaction Flow
- Intake →
quark-torch-model-intake→model_analysis.json - Plan →
quark-torch-quant-plan→quant_plan.json - Confirm →
run_manifest.yaml(stop for user approval) - Execute → run the confirmed command, write quantized model
CRITICAL RULES
- NEVER run
quantize_quark.pydirectly. Always go through the 4 steps below. - NEVER skip a step. Even if the user provides all details upfront, execute each step in order.
- STOP at every checkpoint and wait for user confirmation before continuing.
- Show concrete output at each step — tables, JSON, commands — not just prose descriptions.
- NEVER modify Quark's own source code or examples. The Quark repo (
quark/,examples/,tools/,docs/,tests/) is read-only from this workflow's perspective. See Upstream Quark Code is Read-Only below.
Upstream Quark Code is Read-Only
The Quark repository (quark/, examples/, tools/, docs/, tests/, pyproject.toml, requirements.txt) may be read freely but never modified. This includes "just to make the script accept my flag" patches to examples/torch/language_modeling/llm_ptq/quantize_quark.py — they break reproducibility against a clean Quark install.
When the shipped example does not cover the user's needs, write a fresh standalone script in the user's working directory (or /tmp/) that imports from quark:
# user_workspace/my_custom_ptq.py — NOT inside the Quark repo
from quark.torch import ModelQuantizer
from quark.torch.quantization.config.config import Config
# ... user-specific logic ...
Reference that script in run_manifest.yaml. The shipped quantize_quark.py stays untouched; the run remains reproducible against any Quark version. If the user actually needs an upstream Quark change, surface it as a contribution — do not silently patch their local checkout.
Required Artifact Flow
Step 1 (Intake) ──► model_analysis.json
Step 2 (Plan) ──► quant_plan.json
Step 3 (Manifest) ──► run_manifest.yaml (contains the exact command)
Step 4 (Execute) ──► quantized model output (only after user says yes)
Step 1: Model Intake
Goal: Produce model_analysis.json.
Actions
-
Locate the Quark PTQ script (
quantize_quark.py) under<Quark repo>/examples/torch/language_modeling/llm_ptq/—find / -name quantize_quark.py -path "*/llm_ptq/*" 2>/dev/null | head -1if the path is unknown. Record it for Step 3. -
Call
quark-torch-model-intakewith the model path. It handles config parsing (no weight load), supported-template matching, and risk identification (MoE, >70B, transformers version constraints) and emitsmodel_analysis.json.
Output to Show User
Render the summary from model_analysis.json:
Model Analysis:
Model path: Qwen/Qwen3-8B
Model type: qwen3
Hidden layers: 36
Linear layers: ~224 (quantization targets)
MoE: No
Exclude defaults: [lm_head]
Risks: <list>
Compatibility: OK
>>> CHECKPOINT 1: Confirm model analysis is correct before continuing
Step 2: Quantization Plan
Goal: Build quant_plan.json from the model analysis and user's stated preferences.
Actions
-
Determine the scheme. If the user stated a scheme (e.g., "FP8"), use it. Otherwise, recommend based on their priority:
Priority Recommended Scheme Algorithm Best accuracy fp8orptpc_fp8smoothquant(optional)Smallest model int4_wo_32awqorgptqCPU deployment int8none AMD MI300X/MI355X fp8oramdfp4none NVIDIA H100 fp8none GGUF export uint4_wo_32awq -
Fill the decision table. Show ALL decisions with defaults:
Decision Value Reason global_schemefp8User requested FP8 kv_cache_schemefp8Recommended for FP8 inference exclude_layers["lm_head"]Standard — lm_head stays full precision layer_quant_config{}No per-pattern overrides (or e.g. {"*self_attn*": "fp8"}if the user asked to quantize attention with a non-global scheme)algorithmnullRTN baseline (fastest) calibration_datasetpilevalFast default num_calib_data128Standard default seq_len512Standard default evaluation_intentsmokeQuick PPL check after quantization -
Ask the user if they want to change anything.
>>> CHECKPOINT 2: User MUST confirm or adjust the plan before continuing
Wait for the user to say "ok", "confirm", "looks good", "continue", or similar. If they request changes (e.g., "use smoothquant", "increase calibration to 256"), update the table and re-present.
Step 3: Manifest Generation
Goal: Translate the confirmed plan into the exact quantize_quark.py command and produce run_manifest.yaml.
Actions
-
Build the command. Map plan fields to CLI arguments:
Plan Field CLI Argument model path --model_diroutput dir --output_dirglobal_scheme--quant_schemekv_cache_scheme--kv_cache_dtype(only if non-null)layer_quant_configone --layer_quant_scheme PATTERN SCHEMEper dict entry (only if non-empty)exclude_layers--exclude_layersalgorithm--quant_algo(only if non-null)num_calib_data--num_calib_dataseq_len--seq_lenexport format --model_export(default:hf_format)data type --data_type autodevice --device cuda -
Present the exact command:
python3 <path_to_quantize_quark.py> \ --model_dir <MODEL> \ --output_dir <OUTPUT> \ --quant_scheme <SCHEME> \ --kv_cache_dtype <KV_SCHEME> \ --num_calib_data <N> \ --seq_len <LEN> \ --model_export hf_format \ --data_type auto \ --device cudaNote on
layer_quant_configpatterns. Patterns are wildcard module-name matches against the model'snamed_modules(). Common LLaMA-style picks:'*self_attn*'(attention block),'*experts*'(MoE experts — covers all expert FFN submodules in one entry),'lm_head'(output head). For models with different naming (e.g.attention,attn,self_attention, DeepSeek MLA), the pattern matches nothing silently and no override is applied — inspectnamed_modules()and adjust the pattern before running. -
Show expected output —
config.json+model.safetensors(possibly sharded) + tokenizer files +quark_profile.yamlunder<OUTPUT>/.
>>> CHECKPOINT 3: Show the command and ask "shall I run this?"
Do NOT proceed to execution unless the user explicitly confirms. Acceptable confirmations: "yes", "run it", "go", "execute", or similar.
If the user says "no" or wants changes, go back to the relevant step.
Step 4: Execute PTQ
Goal: Run the quantization command and report results.
Precondition
This step runs ONLY after the user explicitly confirms in Step 3.
Actions
-
Create the output directory:
mkdir -p <OUTPUT_DIR> -
Pick the accelerator and GPU. Read
env_context.jsonfor the backend. On ROCm, pin withHIP_VISIBLE_DEVICES(notCUDA_VISIBLE_DEVICES) —--device cudastill works on ROCm torch. On a shared host, check for a free GPU first and pin to it. -
Run the quantization command from Step 3. Monitor for:
- CUDA/ROCm OOM → suggest reducing
--num_calib_dataor using--multi_gpu - Transformers version errors → report the version mismatch
- Model loading failures → check
trust_remote_codeor model path
- CUDA/ROCm OOM → suggest reducing
-
After completion, verify outputs exist:
ls -lh <OUTPUT_DIR>/ -
Report results:
Quantization complete: Output: <OUTPUT_DIR>/ Model size: X.X GB Format: HuggingFace SafeTensors Perplexity: X.XX (wikitext)
Error Recovery
- If quantization fails, do NOT retry blindly. Report the error and suggest fixes based on
quark-torch-debugpatterns. - If OOM occurs, suggest: reduce
--num_calib_data, reduce--batch_size 1, or use--multi_gpu auto. - If transformers version is wrong, show the required version range.
Complete Example
For an end-to-end walkthrough (FP8 quantization of Qwen3-8B), see
example-fp8-qwen3-8b.md alongside this file.
Recovery
- If any upstream artifact is missing, stop and name the missing producer skill. Do not improvise a partial artifact.
- If the workflow hits a blocker (model cannot be loaded, scheme incompatible, execution fails), report it with diagnostic context rather than attempting ad-hoc fixes.
- If the user wants to change a decision mid-workflow (e.g., switch from FP8 to INT4 after seeing model analysis), go back to the relevant step — do not restart from scratch.
Signals
- GitHub stars
- 166
- Forks
- 33
- Last commit
- Aug 2026
Advanced
- Catalog kind
- skill
- Gateway key
quark-torch-llm-ptq-workflow- Source
- github.com/amd/quark