[RFC] Qualcomm AI Engine Direct - RFC for LLMConfig ModelType (pytorch#20402)

### Summary
This PR adds an RFC proposing a structural split of base.model_class
(ModelType) in extension/llm/export/config/llm_config.py into two
explicit fields

ModelType currently mixes two kinds of identifiers with no documented
rule - architecture families (llama3_2, where size comes from
base.params/base.checkpoint) and concrete HF model ids (qwen2_5_0_5b,
which drives auto-download via HUGGING_FACE_REPO_IDS). This leads to a
split - Llama is size-agnostic in the enum while Qwen bakes the size in.

The RFC proposes two new fields on BaseConfig:

model_family: Optional[ModelFamily] - architecture (replaces the
family-style ModelType values)
model_id: Optional[str] - normalized HF model name, drives auto-download
(replaces the concrete-id-style ModelType values)
model_class becomes Optional[ModelType] = None and is retained for
backward compatibility. Call sites that unconditionally call on
model_class must be updated with a helper for resolution with model_id
and model_family.

Author: qti-mmadhava

docs/source/rfc_llm_config_modeltype.md

@@ -0,0 +1,119 @@
+# RFC: Model naming consistency in `LlmConfig`
+
+**Status:**  **RFC**
+
+**Author:** Mahesh Madhavan
+
+**Last Update:** 2026-06-10
+
+
+## Scope
+
+This RFC is scoped to the generic, backend-agnostic config in
+`extension/llm/export/config/llm_config.py` — specifically `BaseConfig` and the
+`ModelType` enum that backs `base.model_class`.
+
+## Motivation
+
+A single field, `base.model_class` (a `ModelType` enum), currently encodes **two
+different things at once**, inconsistently:
+
+* **Architecture/family** — e.g. `llama3_2`.
+* **A concrete model id** — e.g. `qwen2_5_0_5b` (the normalized HuggingFace
+  name, which also drives auto-download via `HUGGING_FACE_REPO_IDS`).
+* `static_llama` - this doesn't fall under either category, it's not a family or a specific model id.
+
+
+This RFC proposes **segregating the two types into explicit fields** so each
+has a single, clear meaning.
+
+## Proposal: two fields
+
+```diff
+ @dataclass
+ class BaseConfig:
+-    model_class: ModelType = ModelType.llama3
++    model_class: Optional[ModelType] = None
++    model_family: Optional[ModelFamily] = None
++    model_id: Optional[str] = None        # concrete upstream HF id
+     params: Optional[str] = None
+     checkpoint: Optional[str] = None
+     ...
+```
+
+### `model_family` — the architecture
+
+* An enum of **architectures/versions only**: `llama2`, `llama3`, `llama3_1`,
+  `llama3_2`, `llama3_2_vision`, `qwen2_5` etc.
+* **Optional.** When provided, this would require the checkpoint and params.
+
+### `model_id` — the concrete-model id
+
+* **Optional** string: the normalized upstream HuggingFace model name
+  (`qwen2_5_0_5b`, `phi_4_mini`).
+
+* When `checkpoint` is provided along with the `model_id`, download is skipped.
+
+* When omitted, the `model_family` + `params` + `checkpoint` fully
+  determine the export (today's model_class behavior).
+
+### How the three weight/identity inputs relate
+
+| Field | Meaning | Required | Example |
+|---|---|---|---|
+| `model_family` | which architecture/code path | optional | `llama3_2` |
+| `model_id` | which concrete HF model | optional | `qwen2_5_0_5b` |
+| `checkpoint` | explicit local weights (overrides `model_id` download) | optional | `/path/consolidated.pth` |
+| `params` | architecture dims | user-supplied | `/path/to/1b_config.json` |
+
+
+### `model_class` - existing field
+This will become optional - existing models will remain as-is, for backward compatibility
+
+## How it works — examples
+
+```yaml
+# Family + explicit local weights (today's Llama flow)
+base:
+  model_family: llama3_2
+  params: /path/to/1b_config.json
+  checkpoint: /path/to/consolidated.00.pth
+
+# Concrete id → auto-download the pinned HF checkpoint
+base:
+  model_id: qwen2_5_0_5b           # → Qwen/Qwen2.5-0.5B via HUGGING_FACE_REPO_IDS
+  params: examples/models/qwen2_5/config/0_5b_config.json
+
+# Concrete id + checkpoint override (use local weights, keep the id label)
+base:
+  model_id: qwen2_5_0_5b
+  checkpoint: /path/to/local.pth   # overrides the download
+  params: /path/to/0_5b_config.json
+```
+
+The family alone is enough to export (with user `params`/`checkpoint`); `model_id`
+adds concrete identity and enables HF auto-download.
+
+## Backward compatibility & migration
+
+
+* The `model_class` field can stay for backward compatibility, but we could eventually deprecate the `--model` arg.
+* `params`, `checkpoint`, and all other `BaseConfig` fields are unchanged.
+
+## Affected code
+
+* `extension/llm/export/config/llm_config.py` — `model_family` (new `ModelFamily` enum) + `model_id` (str)
+* `examples/models/llama/export_llama_lib.py` — read `model_family` for the
+  code-path dispatch (`:1599`, `:674`) and `model_id` for the
+  `HUGGING_FACE_REPO_IDS` lookup (`:672`).
+
+## What we're asking for
+
+1. **Agreement** on splitting `model_class` into `model_family` (architecture) +
+   `model_id` (concrete HF id).
+
+## Open questions
+* **Decision on `static_llama`** — under this split it is neither a family nor a
+ model_id. It seems like this functionally behaves the same as llama3_2. Where should this live?
+
+* Is the migration cost of a split justified, over just having an overloaded `ModelType`, and supporting both `model_family` and `model_id` through the existing `model_class`(`ModelType`)?