noamaanMulla-03/transformers-issues huggingface dataset:
is_flash_attn_2_available() gives packaging.version.InvalidVersion: Invalid version: 'N/A'
Author: dylanprins
Pull request: no
Labels: name: bug

### System Info

Hi!

I don't have Flash Attention 2 installed, but I do have Flash Attention 3 installed. I get a versioning error while it should just skip FA2 and continue with 3:

```
File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/transformers/models/qwen2_5_vl/modeling_qwen2_5_vl.py", line 1386, in __init__
    super().__init__(config)

  File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/transformers/modeling_utils.py", line 1277, in __init__
    self.config._attn_implementation_internal = self._check_and_adjust_attn_implementation(
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/transformers/modeling_utils.py", line 1791, in _check_and_adjust_attn_implementation
    and not (is_flash_attn_2_available() or is_flash_attn_3_available())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/transformers/utils/import_utils.py", line 889, in is_flash_attn_2_available
    return version.parse(flash_attn_version) >= version.parse("2.1.0")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/packaging/version.py", line 56, in parse
    return Version(version)
           ^^^^^^^^^^^^^^^^
  
File "x/miniconda3/envs/animateai/lib/python3.11/site-packages/packaging/version.py", line 202, in __init__
    raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: 'N/A'
```

N/A is the version set by transformers at the start of the search.


### Who can help?

@vasqu @ArthurZucker @CyrilVallez

### Reproduction

Steps to reproduce:

1. Only install flash attention 3
2. Use dev code (installed from source)

### Expected behavior

The code should run with FA3

Comments:
Fix InvalidVersion exception in is_flash_attn_2_available
Author: ayushm98
Pull request: yes

Fixes #42999

## Summary
When  package is not installed or its version cannot be determined,  returns  as the version string. This caused  to raise  exception.

## Changes
Added a check for  before attempting to parse the version, returning  early if the version cannot be determined.

## Test Plan
- Tested with flash_attn not installed - should return False without exception
- Tested with flash_attn 2.x installed - should work as before
- Tested with flash_attn 3.x only installed - should properly skip FA2 check and allow FA3 to be used

Comments:
Closing as #43004 has been merged to fix this
Fix duplicate words typos in comments and docstrings
Author: raimbekovm
Pull request: yes

Fixes duplicate word typos found in code comments and docstrings.

Changes:
- "for for" → "for" in stopping_criteria.py
- "of of" → "of" in omdet_turbo config
- "or or" → "or" in maskformer
- "to to" → "to" in switch_transformers (2 files) and clap (2 locations)
- "is is" → "is" in dia processing
- "independant" → "independent" in quantizer

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

run-slow: clap, dia, maskformer, omdet_turbo, switch_transformers, finegrained_fp8

ty
Missing import of torch in distilbert docs
Author: PredictiveManish
Pull request: no

https://github.com/huggingface/transformers/blob/a7f29523361b2cc12e51c1f5133d95f122f6f45c/docs/source/en/model_doc/distilbert.md?plain=1#L42-L49

Issue: `torch` import is missing

Solution: Simple adding an `import torch` in docs.  




Comments:
Fix InvalidVersion error when flash_attn version cannot be determined
Author: lukepayyapilli
Pull request: yes

## Problem

When `flash_attn_3` is installed without `flash_attn` (v2), calling `is_flash_attn_2_available()` raises:
```
packaging.version.InvalidVersion: Invalid version: 'N/A'
```

This happens because the `flash_attn` module is importable but its version cannot be determined, so `_is_package_available` returns `"N/A"`, which `version.parse()` cannot handle.

## Fix

Wrap version parsing in `try/except packaging.version.InvalidVersion`, returning `False` when the version is unparseable. This matches the existing pattern in `is_torch_available()` (lines 112-119).

## Note for maintainers

This fix works but is somewhat repetitive - the same try/except pattern now exists in three places. A cleaner long-term solution might be:

1. A `_parse_version_safe()` helper used across the file
2. Having `_is_package_available` return `None` instead of `"N/A"` for undetermined versions
3. Auditing other `version.parse()` calls that could hit similar issues

Happy to refactor if preferred, but kept this minimal to match existing patterns.

Fixes #42999

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43004). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix InvalidVersion error when flash_attn version is N/A
Author: majiayu000
Pull request: yes

# What does this PR do?

Fixes #42999

This PR handles the case where `flash_attn` package is installed but `__version__` attribute is not available, resulting in version being "N/A". When `version.parse("N/A")` is called, it raises `packaging.version.InvalidVersion`.

The fix adds a check for "N/A" version in the following functions:
- `is_flash_attn_2_available()`
- `is_flash_attn_greater_or_equal_2_10()`
- `is_flash_attn_greater_or_equal()`

## 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. Issue: #42999
- [ ] 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?

@vasqu @ArthurZucker @CyrilVallez (mentioned in the issue)

Comments:
Closing as #43004 has been merged to fix this
Add expected outputs to DetrForSegmentation docstring example
Author: raimbekovm
Pull request: yes

Adds missing expected outputs to the `DetrForSegmentation` forward() docstring example.

  The example now shows:
  - `panoptic_seg.shape` → `torch.Size([300, 500])`
  - `len(panoptic_segments_info)` → `5`

  The other DETR models (`DetrModel` and `DetrForObjectDetection`) already have expected outputs in their examples, but this one was missing them.

  Related to #16292

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

run-slow: detr

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43035). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix warnings poping up with `fixup` and `pytest`
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

As per the title. I'm getting too annoyed to see them all the time, high-time to fix them

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43109). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
docs: clarify tokenizer decoder behavior in v5 (#43066)
Author: kowshik-thatinati
Pull request: yes

Hey team 👋

Just adding a small clarification regarding the `decoder` property in AutoTokenizer for Transformers v5.

So basically, in v5, the decoder object might look different compared to v4. 
This is because the internal tokenizer backend has been redesigned. 
But don’t worry — the output of `tokenizer.decode(...)` stays the same, so functionality isn’t affected.

What this PR does:
1. Adds a comment in `tokenization_utils_base.py` near the `decoder` property for reference.
2. Adds a note in the docs (`tokenizer_notes.rst`) to explain this behavior for users.

Hope this helps avoid confusion for anyone upgrading to v5 🙂  

Closes #43066


Comments:
View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43104&sha=831ce6

Hi 👋  
This PR only adds a clarification in docs and a code comment explaining the tokenizer decoder behavior in v5.  
No functional changes involved.

Please let me know if any changes are needed. Thanks!


Hey, thanks for pointing that out 🙏
You’re right — the fix can be much smaller.

I’ll reduce this PR to only the minimal clarification needed (no extra docs / changes) and update it accordingly.
Thanks for the review!
Sequential Sampling
Author: jiosephlee
Pull request: no
Labels: name: trainer

name: Feature request

### Feature request

Add the ability to change the default sampler (which is Random) to other Samplers e.g. Sequential Sampler

### Motivation

All huggingface trainers default to random sampling, and there is no way to allow sequential sampling, which is valuable when the user has a custom data curriculum, for instance.


### Your contribution

Existing PR: https://github.com/huggingface/transformers/pull/42265#issue-3639924358 


Comments:
cc @SunMarc 

we will most likely add an arg to have more flexibility for the sampler ! see pr
Enable passing block_size and bf16_stochastic_round to torchao optimizers via TrainingArguments
Author: klae01
Pull request: no
Labels: name: Feature request

### Feature request

Currently, when using torchao optimizers such as AdamW4bit and AdamW8bit through the Trainer, the optimizer-specific arguments block_size and bf16_stochastic_round cannot be configured by the user.

Although these optimizers support such arguments, the Trainer does not pass them through, and the optimizers therefore always fall back to their default values.

This feature request proposes allowing users to configure these arguments via --optim_args in TrainingArguments, in the same way other optimizer-specific parameters are already supported.

https://github.com/huggingface/transformers/pull/42972

### Motivation

When training large models with low-bit optimizers, parameters such as block_size and bf16_stochastic_round can have a significant impact on numerical stability, performance, and memory efficiency.

Exposing these parameters through TrainingArguments improves transparency, configurability, and consistency with how other optimizer arguments are handled in Trainer.

### Your contribution

Passes block_size and bf16_stochastic_round from TrainingArguments.optim_args to torchao optimizers.

Comments:
cc @SunMarc 

will be fixed soon !
Support block_size and bf16_stochastic_round keyword arguments for torchao optimizers
Author: klae01
Pull request: yes


# What does this PR do?

This PR enables the configuration of `block_size` and `bf16_stochastic_round` arguments for torchao optimizers (AdamW4bit, AdamW8bit) within the Trainer.

Previously, these arguments were not passed to the optimizer, relying on default values. Now, users can specify them via optim_args in TrainingArguments.


## 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.
- [ ] 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?

@SunMarc

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42972). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Silence pytest warnings due to sentencepiece version
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

As per the title. Finally localized why they would pop up when running `pytest` on some envs

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43118). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
gpt-oss is not working with flash-attention
Author: pushkar-hue
Pull request: yes

When initializing `gpt-oss` model with `attn_implementation="flash_attention_2"` or `"flash_attention_3"` would result in silent failures and garbage generation output as reported in #42533.

`gpt-oss` models rely on attention sinks which are not yet implemented for the `flash_attention` as suggested the safest path is to strictly block unsupported attention backends rather than failing silently or assuming a fallback.

@vasqu can you see if this is what you had in mind?

Comments:
@vasqu I have fixed the styling issues and added the test case as requested.

However, the test currently fails in CI because `flash_attn` is not installed in the environment. This causes the library to raise an `ImportError` before it reaches my new `ValueError` check.

Can you check if the tests look good now? let me know if there's anything else I need to change. Thanks for your suggestions.

Gpt oss pretty important so wanna keep @ArthurZucker in the loop if this is ok

@vasqu @ArthurZucker I have moved the validation inside config as suggested. Can see if this looks good? please let me know if there's anything else I need to do or if i'm missing something.


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

run-slow: gpt_oss

@pushkar-hue sorry for the delays, we were off for the holidays, I pushed a fix to make this work with all of our functions, see https://github.com/huggingface/transformers/pull/42736#discussion_r2662432027

Merging now and thx for the contribution :hugs: 


The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42736). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[SAM3] Fix MPS race condition in add_point_inputs
Author: vykhovanets
Pull request: yes

# What does this PR do?

For Apple Sillicon this PR enables SAM2 and SAM3 inference on MPS device.

## Problem
SAM2/SAM3 video inference produces "no object" masks on MPS (all values = -1024), while CPU inference was correct.

## Root Cause
`non_blocking=True` in `add_point_inputs` causes a race condition: the CPU source tensor gets garbage collected before the async copy to MPS completes, corrupting `point_coords` and `point_labels`.

## Fix
Change `non_blocking=True` to `non_blocking=False` in `add_point_inputs`.

For my tests MPS inference is **1.78x faster** on and now produces identical masks to CPU.

Why change is made in SAM2 code: because the sam3 code is generated with [utils/modular_model_converter.py](utils/modular_model_converter.py) and change in sam2 code is propagated there.


Comments:
Hi @SangbumChoi! Can you please look through my PR, it adds MPS support for SAM3

@vykhovanets It seems simple change but one question is why only applying optimization in `add_point_inputs` only?

Good question @SangbumChoi! After additional testing it seems like `add_points_inputs` is the only place where this race-condition happens.

I checked, there is also `add_mask_inputs` function, but input_masks are already on the MPS device before its invocation(`process_new_mask_for_video_frame`), that is why `non_blocking=True` in `add_mask_inputs` is a no-op. 

![Screenshot 2025-12-26 at 12 37 42](https://github.com/user-attachments/assets/43d1d6e7-34a7-452f-9512-05c141de5d6e)



Thanks for finding the root cause. I can confirm that before this fix, when using sam3_tracker_video on MPS I always get the same -1024 value in the mask, whereas on CPU I get the right mask. 

After your fix it works perfectly. 



@atultw as far as I know CUDA can implicitly synchronize, and this race-condition is due to different memory handling by MPS, but we shouldn't introduce additional checks, because `non_blocking=False` hardens execution - that is good for all platforms, and additionally it won't make execution slower because input points are tiny tensors. 

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43042). 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: edgetam_video, sam2_video, sam3_tracker_video
🚨 Fix EfficientNet image processor default interpolation to BICUBIC
Author: lukepayyapilli
Pull request: yes

## Summary
Fix default interpolation from NEAREST to BICUBIC in both `EfficientNetImageProcessor` and `EfficientNetImageProcessorFast` to match the original EfficientNet implementation.

## Details
The original EfficientNet implementation uses BICUBIC interpolation for image preprocessing:
https://github.com/tensorflow/tpu/blob/master/models/official/efficientnet/preprocessing.py

However, both HuggingFace `EfficientNetImageProcessor` and `EfficientNetImageProcessorFast` defaulted to NEAREST, causing differences in preprocessing outputs compared to the original implementation.

## Changes
- `image_processing_efficientnet.py`: Changed default `resample` from `NEAREST` to `BICUBIC`
- `image_processing_efficientnet_fast.py`: Changed default `resample` from `NEAREST` to `BICUBIC`

Fixes part of #28180

Comments:
cc @yonigozlan @molbap

Could I get a review of this one? Thanks!

cc: @Rocketknight1 @yonigozlan @molbap 

run-slow: efficientnet

This comment contains `run-slow`, running the specified jobs: 

models: ["models/efficientnet"]
quantizations: []

## CI Results
[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/20718259467)

✅ No failing test specific to this PR 🎉 !


Thanks @molbap!

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

run-slow: efficientnet

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_42956). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fixed EfficientNet interpolation method to match the original implementation
Author: ammarjmahmood
Pull request: yes

# What does this PR do?

Fixes the default interpolation method for EfficientNet image processor from `NEAREST` to `BICUBIC` to match the original TensorFlow implementation.

## Motivation

As pointed out in #28180 to check the models in the list, the EfficientNet image processor was using `NEAREST` interpolation , but the [original TensorFlow implementation](https://github.com/tensorflow/tpu/blob/master/models/official/efficientnet/preprocessing.py#L86-L91) uses `BICUBIC` by default.

The `_resize_image()` function in the original code explicitly uses `tf.image.resize_bicubic` as the default resize method.

## Changes

- Changed default `resample` parameter from `PIL.Image.NEAREST` to `PILImageResampling.BICUBIC`
- All related docstrings (lines 69, 136, 154)

Fixes #28180 (partial - for EfficientNet model)

---

## Before submitting
- [x] Did you read the contributor guideline
- [x] Was this discussed via a Github issue - Yes, #28180
- [x] Documentation updated (docstrings changed)
- [ ] New tests written (not needed - bug fix)

cc @yonigozlan @molbap (vision models reviewers)

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

run-slow: efficientnet, metaclip_2

Hi, Please let me know if anything else is needed for this merge. Thanks

Sorry it looks like these changes were already merged... Thanks for opening this PR
now transformers is support Rust ,why not to develop java /scala3
Author: mullerhai
Pull request: no

HI, 

we need transformers for langchain4j, please support us

Comments:
I encourage all of the people who just paste Github issues into their code agents without reading them to try this one 😅 

> I encourage all of the people who just paste Github issues into their code agents without reading them to try this one 😅 

？？？



This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.
Fix crash in device_map='auto' when CPU is missing from inferred max_memory
Author: pallavisharma6802
Pull request: yes
Labels: name: Code agent slop

## What does this PR do?
Fixes a crash when using `device_map="auto"` in environments where `"cpu"` is missing from the inferred `max_memory` dictionary.

### Bug
When `max_memory` is not explicitly provided, `accelerate.get_max_memory()` may return a dictionary without a `"cpu"` key (depending on the backend/environment).  
`_get_device_map` then unconditionally scales `"cpu"` memory, resulting in a `KeyError`.

### Fix
- Guard access to `"cpu"` in `inferred_max_memory` before applying the scaling factor.
- Preserve existing behavior when `"cpu"` is present.

### Tests
- Added `tests/utils/test_device_map_cpu_guard.py` to ensure `device_map="auto"` does not crash when `"cpu"` is absent from `max_memory`.

Fixes #42994


## Before submitting
- [x] Did you read the contributor guideline?
- [x] Did you write any new necessary tests?


## Who can review?
@Cyrilvallez 


Comments:
Thanks for the report! This PR adds a defensive fix for the `device_map="auto"` crash and includes a regression test.
Happy to make any adjustments if needed.


Good point! this assumption does originate from `accelerate.get_max_memory()`.

That said, `_get_device_map` in Transformers currently treats the returned `max_memory` as an internal contract and applies additional logic on top of it, so guarding here avoids a hard crash regardless of how `max_memory` is produced (including older or external Accelerate versions).

I agree that Accelerate could also be hardened, and I’m happy to open a follow-up issue/PR there if that’s preferred. In the meantime, this keeps Transformers robust against missing `"cpu"` entries without changing behavior when it is present.


Humm, could you provide an example of a situation where `cpu` is not present in `inferred_max_memory`? I don't think it can be missing 🤔

Thanks for the question. That’s fair!

I don’t currently have a minimal standalone repro showing `"cpu"` missing directly from `accelerate.get_max_memory()` itself. What I observed was the `KeyError` happening in Transformers’ `_get_device_map` when using the inferred `max_memory` in my setup, which suggests `"cpu"` was absent at that stage. But I agree that if `get_max_memory()` guarantees a `"cpu"` entry by contract, then this guard may be too broad / misplaced.

If `"cpu"` is indeed invariant on the Accelerate side, I’m happy to adjust this PR to better reflect that contract (e.g. narrow the guard to the specific failing path or replace it with an assertion + update the test). I can also try to extract a minimal repro to confirm where `"cpu"` drops out (if it does). Let me know what you’d prefer.