Bug: Framepack crashes on RTX 5090 (CUDA SM_120) due to missing kernel support in LLaMA and CLIP models

Nobody has claimed this yet.

#### Description

Attempting to run Framepack on a system equipped with an **NVIDIA RTX 5090 (CUDA Compute Capability: `sm_120`)** results in a crash when processing prompts. This is due to **missing compiled CUDA kernels** in `torch.embedding()` used by **LLaMA** and **CLIP** models from HuggingFace.

Even with PyTorch 2.7.0 + cu126, the runtime throws:

```
RuntimeError: CUDA error: no kernel image is available for execution on the device
```

or:

```
Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!
```

#### System Details

* **GPU**: NVIDIA RTX 5090
* **CUDA**: 12.6
* **Compute Capability**: sm\_120
* **PyTorch**: 2.7.0+cu126
* **OS**: Windows 11
* **Framepack version**: framepack\_cu126\_torch26 (latest)

#### Stack Trace Sample

```text
File ".../modeling_llama.py", line 891, in forward
inputs_embeds = self.embed_tokens(input_ids)
File ".../functional.py", line 2551, in embedding
return torch.embedding(...)
RuntimeError: CUDA error: no kernel image is available for execution on the device
```

#### Workaround Tried

* Forcing `text_encoder` and `text_encoder_2` to `.cpu()` using `deepcopy()` → still triggers CUDA kernel calls.
* Disabling LLaMA completely and feeding dummy tensors → CLIP fails next.
* Forcing entire `encode_prompt_conds()` to CPU → works, but performance suffers greatly.

#### Suggestion

Provide a config option or env variable to **run LLaMA and CLIP on CPU only**, or offer fallback mechanisms if unsupported compute capability is detected.

#### Request

Please consider supporting `sm_120` in upcoming releases, or allow a clean CPU fallback mode for unsupported architectures (even if it’s slower).

Thanks for the great work — this tool is amazing!

Start by reproducing the RTX 5090 failure while processing prompts and inspect the encode_prompt_conds() path, including the LLaMA and CLIP text encoders. The report names modeling_llama.py and PyTorch functional.py in the stack trace; done means either sm_120 runs without the missing-kernel error or both encoders have a clean CPU-only fallback.

Written by the indexing model from the issue text.