noamaanMulla-03/transformers-issues huggingface dataset:
[Quantization] Fix Static FP8 Quantization
Author: MekkCyber
Pull request: yes

# What does this PR do?

Fix https://github.com/huggingface/transformers/issues/42746, before downcasting to FP8 we should clamp values to the right range to avoid having NaNs

Comments:
@bot style 

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

@bot /style 

Style bot fixed some files and pushed the changes.
[core] fix fp-quant
Author: MekkCyber
Pull request: yes

# What does this PR do?

Fix fp-quant

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

@bot /style 

Style fix is beginning .... [View the workflow run here](https://github.com/huggingface/transformers/actions/runs/19971230495).

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42613&sha=946c2d
Add `add_language_codes` helper to `NllbTokenizer` for new language codes
Author: hunterschep
Pull request: yes

Add a small helper to make it safer and easier to register new NLLB language codes when fine-tuning on languages that are not part of `FAIRSEQ_LANGUAGE_CODES`. This makes it easier for low-resource language researchers to add new language code(s), without having to worry about breaking the list or the `<mask>` token. 

Concretely, it:

- Adds `NllbTokenizer.add_language_codes(...)`, a convenience wrapper around `add_special_tokens`
- Adds an integration-style test  
- Updates the `NllbTokenizer` docstring so that the new helper appears in the rendered docs.

## 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?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [x] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [x] Did you write any new necessary tests?

Tests run locally:

- `pytest tests/models/nllb/test_tokenization_nllb.py -sv`

## Who can review?

Anyone in the community is welcome to review. Tagging tokenizer maintainers who might be interested:

- @ArthurZucker
- @itazap


Comments:
Hey :) Thanks for the PR. It's great that support for new language codes can be supported. I think we can leave this feature to be covered by the existing `add_special_tokens` API:

```python
tokenizer.add_special_tokens(
    {"extra_special_tokens": ["ami_Latn"]},  # or "additional_special_tokens" if pre v5
    replace_extra_special_tokens=False  #
)
# Get token IDs if needed
token_ids = [tokenizer.convert_tokens_to_ids(code) for code in ["ami_Latn"]]
```

The existing API already handles deduplication (in `tokenization_utils_base.py`), so calling it multiple times with the same codes is safe! The main thing to remember is setting `replace_extra_special_tokens=False` to append rather than replace the existing language codes.

Thanks for identifying this use case. If you'd like, this can be added to the NLLB documentation to make it more discoverable for others.

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

run-slow: afmoe, apertus, arcee, aria

Closed in accordance with clarifying comment from collaborators, will make a clean PR to update docs
Add docstring documentation for DeepSeek V3.2 indexer parameters
Author: shuyingl
Pull request: yes

## Summary
Fixed missing docstring documentation for `output_indexer_scores` and `output_indexer_kl_target` parameters in DeepSeek V3.2 model forward methods. These parameters were causing validation errors during package installation.

## Changes
- Added `DEEPSEEK_V32_INDEXER_ARGS` constant with proper parameter documentation
- Applied `@auto_docstring(custom_args=DEEPSEEK_V32_INDEXER_ARGS)` decorator to:
  - `DeepseekV32Model.forward()`
  - `DeepseekV32ForCausalLM.forward()`
- Regenerated `modeling_deepseek_v32.py` from the modular source file

## Test Plan
- [x] Verify import of DeepseekV32Model and DeepseekV32ForCausalLM works without docstring errors
- [x] Check that auto_docstring decorator properly recognizes the custom parameters

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Comments:
Closing - created to wrong repo by mistake

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42752&sha=438ffa
Fix Qwen3Next dtype API usage
Author: SrijanUpadhyay
Pull request: yes

This PR fixes an invalid PyTorch API usage in the Qwen3Next model.

### Changes
- Replaced `torch.get_current_dtype()` with `torch.get_default_dtype()` in both modular and modeling files
- This change fixes FLA (Flash Linear Attention) compatibility when using different dtypes like float32/float16

### Technical Details
- The original code was using a non-existent PyTorch API `get_current_dtype()`
- The correct API is `get_default_dtype()` which returns the global default dtype setting
- This change ensures proper dtype handling in the Qwen3Next GatedDeltaNet normalization layer

### Testing
The changes have been tested with `make fixup` and pass the repository consistency checks.

Fix #41732 

Comments:
Yeah, if you could revert the unrelated changes this PR is good!

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

run-slow: qwen3_next

Thanks for pointing it out, i have made this pr clean and added other changes to #41734. Sorry for the delay. Please check and provide me the feedback or any further improvements.

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

This might be a naive question, but how come this didn't make it into v4.57.3? When will this be on a release version?
Simplify DeepSeek V3.2: remove redundant RoPE, inherit from V3
Author: shuyingl
Pull request: yes

## What does this PR do?

Continues applying Occam's razor to DeepSeek V3.2 by removing unnecessary code reimplementations and properly inheriting from V3.

**Changes:**
- Remove redundant `apply_rotary_pos_emb_non_interleave` and use Llama's standard `apply_rotary_pos_emb` instead (mathematically equivalent)
- Simplify RoPE application in Indexer using Llama's proven implementation with non-interleaved rotation
- Config class simplified to focus on V3.2-specific parameters
- Verified `hadamard_transform_fallback` is essential for Lightning Indexer activation rotation (kept as is)

**Impact:**
- Modular file reduced from 1349 to 824 LoC (39% reduction)
- Removes ~55 lines of redundant RoPE code
- Improves maintainability by using standard library implementations

Builds on #10 to further minimize unnecessary code divergence from V3.

Comments:
Created against wrong repo, recreating against fork

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42786&sha=05a0a4
Clarify DeepSeek V3.2 indexer weight scaling and FSDP compatibility
Author: shuyingl
Pull request: yes

## Summary
- Document weight scaling factors in Lightning Indexer (n_heads^-0.5, softmax_scale, q_scale)
- Add FSDP/gradient checkpointing notes for training consistency
- Improve clarity of warm-up training path implementation and documentation

## Details
The Lightning Indexer scaling was verified against the official DeepSeek implementation. The `q_scale` factor is FP8-specific and correctly omitted for training. FSDP compatibility is maintained since indexer outputs are consumed within the same forward pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42788&sha=6ee160
Adapt  NPU fusion operators to Qwen2.5-VL model
Author: frozenleaves
Pull request: yes

This PR is aimed at adapting the Ascend NPU fusion operators for the `Qwen2.5-VL` series models to enhance their performance on the NPU. Currently, this PR only makes **non-compatible modifications for the NPU** and does not meet the conditions for merging into the mainline. **It is only applicable to the joint innovation version for restricted customers**. If any bugs are encountered, communication and updates can be made at any time.

The modifications in this PR include enabling support for three NPU fusion operators: NPU Flash Attention, NPU RMSNorm, and NPU SwiGLU. Currently, it **only supports the Qwen2.5-VL series models**, and large-scale verification has only been conducted on the Qwen2.5-VL-7B model. Other series of the Qwen2.5-VL models (such as 32B) have not been verified, and accuracy and performance are not guaranteed.

Comments:
Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the `Ready for review` button (at the bottom of the PR page). This will assign reviewers and trigger CI.

Sorry, just read the `and does not meet the conditions for merging into the mainline` part :sweat: I'm confused why this PR was opened then? Maybe put it as draft for now?

My comments for flash attn on npu stand tho - it should work on main already!
[Quantization] Fixing last issues for a green 2026 CI hopefully
Author: MekkCyber
Pull request: yes

# What does this PR do?



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

run-slow: bitnet_integration

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42793). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
🚨🚨🚨🚨🚨🚨🚨🚨🚨 default to `"auto"` dtype
Author: ArthurZucker
Pull request: yes
Labels: name: for_v5?

# What does this PR do?
Fixes #34743 by defaulting to `auto` dtype (meaning the type saved in the config) instead of always using `torch.float32`. 

This is hugely breaking

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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=34919&sha=b40250
feat(granitemoe*): Remove logits upcast when computing loss
Author: gabe-l-hart
Pull request: yes

# What does this PR do?
When the CausalLM loss is used, the upcast is done in the loss function utils, so this is redundant.

Fixes #42709 


## 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/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Review suggestions: @ArthurZucker @Rocketknight1 @Ssukriti 


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

run-slow: granitemoe, granitemoehybrid, granitemoeshared

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

# What does this PR do?
This PR deprecates `warmup_ratio`. Instead we ask the user to use `warmup_steps` instead as we now allow passing float values. This is something that was already done for a few args like `eval_steps` .

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

we use `warmup_ratio` a lot in our recipes/configs, but when I think about it, it might make more sense to use `warmup_step` instead., I'd be curious to hear the feedback of @edbeeching @lewtun on this.

> we use warmup_ratio a lot in our recipes/configs, but when I think about it, it might make more sense to use warmup_step instead., I'd be curious to hear the feedback of @edbeeching @lewtun on this.

I don't mind keeping it if you think this will lead to too many complications ! 

> > we use warmup_ratio a lot in our recipes/configs, but when I think about it, it might make more sense to use warmup_step instead., I'd be curious to hear the feedback of @edbeeching @lewtun on this.
> 
> I don't mind keeping it if you think this will lead to too many complications !

I think it is fine as long as the warmup is the same for `warmup_ratio=0.1` vs `warmup_steps=0.1` (for example)

I agree with @edbeeching - this is a simple change we can propagate to our recipes

Perfect, I'll do the change for v5 then. 

After this PR, if users are trying to pass a `float` value for `warmup_steps`:

- transformers v4: they will receive the following error `("warmup_steps must be of type int and must be 0 or a positive integer.")`. For clarify, maybe we can catch this in TRL and raise an error ? @qgallouedec 

- transformers v5: same behavior as we had with `warmup_ratio `

@SunMarc I noticed that the deprecation messages are confusing, one says deprecation happens in v5 and another in v5.2.

Also, for clarification, if I have `warmup_ratio=0.1`, I could change it to `warmup_steps=0.1` but only if I have transformers v5, in v4, float would not be valid?

> Also, for clarification, if I have warmup_ratio=0.1, I could change it to warmup_steps=0.1 but only if I have transformers v5, in v4, float would not be valid?

Yeah, float would not be valid as this would only work with transformers v5. Also indeed, the deprecation msg are confusing. It should be v5.2.
allow registration of custom checkpoint conversion mappings
Author: winglian
Pull request: yes

# What does this PR do?

For custom modeling, this provides a clean route to adding new or overwriting existing mappings with custom mappings. Additionally, it properly memoizes the cached mappings.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?
@ArthurZucker 
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- text models: @ArthurZucker @Cyrilvallez
- vision models: @yonigozlan @molbap
- audio models: @eustlb @ebezzam @vasqu
- multimodal models: @zucchini-nlp
- graph models: @clefourrier

Library:

- generate: @zucchini-nlp (visual-language models) or @gante (all others)
- continuous batching: @remi-or @ArthurZucker @McPatate
- pipelines: @Rocketknight1
- tokenizers: @ArthurZucker and @itazap
- trainer: @SunMarc
- attention: @vasqu @ArthurZucker @CyrilVallez
- model loading (from pretrained, etc): @CyrilVallez
- distributed: @3outeille @ArthurZucker
- CIs: @ydshieh

Integrations:

- ray/raytune: @richardliaw, @amogkam
- Big Model Inference: @SunMarc
- quantization: @SunMarc @MekkCyber
- kernels: @MekkCyber @drbh
- peft: @BenjaminBossan @githubnemo

Devices/Backends:

- AMD ROCm: @ivarflakstad
- Intel XPU: @IlyasMoutawwakil
- Ascend NPU: @ivarflakstad 

Documentation: @stevhliu

Research projects are not maintained and should be taken as is.

 -->


Comments:
@ArthurZucker rebased and updated! I'm not sure why the listing is failing. It works on my end.

No worries can just be versioning issues! 

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42634). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix: add None check for extractors in video_processor_class_from_name
Author: Blaizzy
Pull request: yes

Here's a PR message for the fix:

---

# What does this PR do?

Fixes `TypeError: argument of type 'NoneType' is not iterable` when loading VLM processors without `torchvision` installed.

## The Problem

When `torchvision` is not available, the `VIDEO_PROCESSOR_MAPPING_NAMES` dictionary values are set to `None` (lines 84-87 in `video_processing_auto.py`). However, `video_processor_class_from_name()` attempts to check `if class_name in extractors` without first verifying that `extractors` is not `None`, causing the TypeError.

## The Fix

Added a `None` check before the membership test:

```python
# Before
if class_name in extractors:

# After  
if extractors is not None and class_name in extractors:
```

This allows the function to safely skip entries where the video processor class is `None` (i.e., when `torchvision` is unavailable) and continue searching through other mappings or return `None` gracefully pointing out the root cause of the error.

## Traceback

Before fix:
```bash
Traceback (most recent call last):
  File "/opt/homebrew/Caskroom/miniconda/base/envs/mlx/bin/mlx_vlm.generate", line 7, in <module>
    sys.exit(main())
  ...
  File ".../transformers/models/auto/video_processing_auto.py", line 94, in video_processor_class_from_name
    if class_name in extractors:
       ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type 'NoneType' is not iterable
```

After fix: 

```bash
  File "/Users/prince_canuma/Documents/Projects/LLMs/transformers/transformers/src/transformers/utils/import_utils.py", line 1863, in __getattribute__
    requires_backends(cls, cls._backends)
  File "/Users/prince_canuma/Documents/Projects/LLMs/transformers/transformers/src/transformers/utils/import_utils.py", line 1849, in requires_backends
    raise ImportError("".join(failed))
ImportError: 
Qwen3VLVideoProcessor requires the Torchvision library but it was not found in your environment. Check out the instructions on the
installation page: https://pytorch.org/get-started/locally/ and follow the ones that match your environment.
Please note that you may need to restart your runtime after installation.
```

## Reproduction

```bash
# In an environment without torchvision
mlx_vlm.generate --model Qwen/Qwen3-VL-2B-Instruct --prompt "Describe this image." --image "image.png"
```

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

run-slow: auto

Makes sense to me but cc @zucchini-nlp @molbap @yonigozlan to check if this is the right thing to do when we don't have `torchvision`
Add quantize for missing methods
Author: SunMarc
Pull request: yes

# What does this PR do?

This adds supports for quants methods that needs to add Quantize class. From what I saw, hqq will be the hardest to deal with ... (not fixed at all for now). The other will only require to check if the tests are passing.

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

@bot /style 

Style fix is beginning .... [View the workflow run here](https://github.com/huggingface/transformers/actions/runs/19502330740).

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

run-slow: fbgemm_fp8, higgs, hqq, quark_integration

not meant to be merged, we will add those methods back progressively !
Fixing wrong information in Mimi Docs
Author: MohamedAliRashad
Pull request: yes

```python
model_id = "kyutai/mimi"
mimi_model = MimiModel.from_pretrained(model_id)
feature_extractor = AutoFeatureExtractor.from_pretrained(model_id)

# Check your exact frame rate
total_stride = 1
for ratio in mimi_model.config.upsampling_ratios:
    total_stride *= ratio

frame_rate = mimi_model.config.sampling_rate / total_stride
print(f"Sampling Rate: {mimi_model.config.sampling_rate}")
print(f"Total Stride: {total_stride}")
print(f"ACTUAL Frame Rate: {frame_rate} Hz")
print(f"Duration per frame: {1/frame_rate:.4f} seconds")
```
The output of this code is:
```
Sampling Rate: 24000
Total Stride: 960
ACTUAL Frame Rate: 25.0 Hz
Duration per frame: 0.0400 seconds
```
So the correct frame rate is 25Hz not 12.5, also the codebooks returned are 32 not 16.

Comments:
cc @eustlb @ebezzam
[Quantization] FBgemm FP8 for XPU
Author: MekkCyber
Pull request: yes

# What does this PR do?

Fixes some issues with https://github.com/huggingface/transformers/pull/42639

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

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

run-slow: fbgemm_fp8
Better continuous batching tests
Author: remi-or
Pull request: yes

Since a lot of features have been added to continuous batching, this PR aims o refactor the associated tests so we can catch new failures. The structure of the tests used to be one test per model / attention implementation. Now we have one test backend, that makes sure the generation with and without CB is coherent. It is called in two tests:
- we test all possible set of parameters on one tiny llama model
- we test a restricted set of parameters on different architectures: full attention, sliding window, etc.

There was also an effort to regroup the streaming tests so it can use the same backend.

Overhaul, the new tests cover more ground for a lesser amount of code. And it already caught one bug: zero-sized cuda graphs failed silently, which led to slight generation divergence.

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

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=42699&sha=a43fe9