Add GB10/SM121 Hub-kernel path for Qwen3.6 Gated DeltaNet
Author: AzeezIsh
Pull request: yes

On a DGX Spark (GB10, compute capability 12.1) the `fla` and `causal_conv1d` fast paths have no SM121 build, so Qwen3.6 falls back to the slow pure-torch Gated DeltaNet (`is_fast_path_available=False`). Register a compute-capability- gated Hub kernel (`Atlas-Inference/gdn`) for the Qwen3.6 GDN layers so GB10 users get a fast path automatically; every other GPU keeps the existing path.

- Decorate `Qwen3_5GatedDeltaNet` (Qwen3.6-27B dense) and `Qwen3_5MoeGatedDeltaNet` (Qwen3.6-35B-A3B) with `@use_kernel_forward_from_hub(...)` in the modular files; regenerate modeling via the modular converter.
- Add two `CUDAProperties(min=121, max=121)`-gated entries in `integrations/hub_kernels.py`.

The kernel is a stateless `kernels` layer: it reuses the host module's projections, gated RMSNorm, and out_proj and replaces only the conv1d and gated-delta-rule cores. Output parity vs the torch fallback is cosine >= 0.9999 on GB10; a full-model greedy `generate()` produces identical token IDs.

# What does this PR do?

The two decorators in the `modular_*.py` files (with `modeling_*.py` regenerated by the converter) plus the two gated entries in `integrations/hub_kernels.py`.

**Verified on GB10 (SM121), bf16:**
- Layer parity vs the torch fallback through a real `DynamicCache` (prefill + 8 decode), using the published Hub kernel `Atlas-Inference/gdn@v0`: 27B `0.999970`, 35B-A3B `0.999967` reproduced on a second, clean box via an unauthenticated Hub pull.
- Decorator path (this PR's mechanism): `kernel_layer_name` set, `kernelize()` swaps the forward, parity unchanged.
- Full-model greedy `generate()` (`Qwen3_5MoeForCausalLM`): identical token IDs vs the torch fallback, GDN layers confirmed swapped to the Atlas kernel.

Context: follow-up to huggingface/kernels-community#866 (@sayakpaul asked to show how the Atlas SM121 kernels can be used in transformers). No overlapping PR exists. One non-blocking follow-up for reviewers: the mapped kernel currently needs `trust_remote_code=True` until `Atlas-Inference` is added to the `kernels` trusted-publisher allowlist (or the layer is hosted under `kernels-community`)

## Code Agent Policy

- [x] I confirm that this is not a pure code agent PR.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request), Pull Request section?
- [x] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Coordinated via huggingface/kernels-community#866.
- [ ] Did you make sure to update the documentation with your changes?
- [x] Did you write any new necessary tests? (Parity/generate tests were run on GB10 hardware and in-repo unit tests aren't included since the path needs a real SM121 GPU and a Hub fetch.)

## Who can review?

@drbh (kernels integration) and @Cyrilvallez (text models / Qwen3.6).


Comments:
I believe I've addressed your comments @vasqu just wanted to bring up some blockers for the `use_kernels=True` path for qwen3_5, both independent of this kernel. Firstly the `Atlas-Inference/gdn` entry needs `trust_remote_code=True` for now, can drop it once Atlas-Inference is an allow-listed kernel publisher. `use_kernels=True` also currently crashes on qwen3_5 rotary, the attention is decorated `@use_kernelized_func(apply_rotary_pos_emb)` but the function lacks `@use_kernel_func_from_hub`, and the only rotary Hub kernel (kernels-community/rotary) is uncompatible with qwen3_5's partial rotary (shape mismatch 128 vs 64). I feel this needs a maintainer decision, happy to help look into this

Hey @AzeezIsh :wave: 

Yes that's true, I think we also need to slightly rewrite the logic in transformers (as we limited this quite a bit before trusted kernels was a thing), see https://github.com/huggingface/transformers/blob/94246e689c03551bd97624d436de4c7e2d937063/src/transformers/integrations/hub_kernels.py#L430-L434
I'm working on upgrading the minimum kernels version so we can use the proper in-built feature (see #46039 for syncing to latest kernels)

Yes the issue is known (#46399). The underlying issue is that modular always inherited that decorator so we need something that disallows it. I will try working on it to unblock this. 

For the second issue: #46440 - this should fix the problem allowing non inheritance where needed

**CI Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46423)

> We are good to merge I just fixed some small nits on my side; mainly pinning to an explicit commit to be on the safe side ([93b6eda](https://github.com/huggingface/transformers/commit/93b6edaaa31952178f63f64e678f8d116fc8b7f7))
> 
> Lmk if that's ok, then I merge 🤗

Looks great to me @vasqu, please feel free to merge!

**[For maintainers]** Suggested jobs to run (before merge)

run-slow: qwen3_5, qwen3_5_moe

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46423). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Let's go :partying_face: thanks a lot for sticking through

Thanks so much @vasqu, plan to push more work up for DGX along with the Strix Halo too. Likely need to enable that arch (gfx1151) to run transformers as well! Will link an issue/PR for this to follow up :)

Yep, dont hesitate to cc me. If idk, I can at least forward internally as well :hugs: 

Btw @AzeezIsh https://github.com/huggingface/kernels/releases/tag/v0.16.0 might be interesting for you as well, we will also adopt kernels signing bit by bit :hugs: