noamaanMulla-03/transformers-issues huggingface dataset:
🌐 [i18n-KO] Translated `attention_interface.md` to Korean
Author: songi104
Pull request: yes

<!-- PR의 제목은 "🌐 [i18n-KO] Translated `<your_file>.md` to Korean" 으로 부탁드립니다 -->
# What does this PR do?

Translated the `attention_interface.md` file of the documentation to Korean.
Thank you in advance for your review.

Part of https://github.com/huggingface/transformers/issues/20179

## Before reviewing
- [x] Check for missing / redundant translations (번역 누락/중복 검사)
- [x] Grammar Check (맞춤법 검사)
- [x]  Review or Add new terms to glossary (용어 확인 및 추가)
- [x] Check Inline TOC (e.g. `[[lowercased-header]]`)
- [x] Check live-preview for gotchas (live-preview로 정상작동 확인)

## Who can review? (Initial)

<!-- 1. 위 체크가 모두 완료된 뒤에만 KREW 팀원들에게 리뷰를 요청하는 아래 주석을 노출해주세요!-->
May you please review this PR?
<!-- @jungnerd, @luckyvickyricky, @chelsseeey, @skwh54, @amo33, @maximizemaxwell, @D15M4S -->
<!-- @harheem, @nsbg, @Youngdong2, @xhaktm00, @ssunbear, @ChoHyoungSeo, @judy-choi -->
<!-- @4N3MONE, @Kim-Ju-won, @ahnjj, @FacerAin, @ssum21, @TaskerJang, @HyunZ118 -->
@yijun-lee, @songi104, @chhaewxn, @AhnJoonSung, @jihyun-0611, @seopp, @pyapyapya

## 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#start-contributing-pull-requests),
      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? (Final)

<!-- 2. KREW 팀원들의 리뷰가 끝난 후에 아래 주석을 노출해주세요! -->
<!-- @stevhliu May you please review this PR? -->

Comments:
torch fake_tensor load hf model failed
Author: SandyWang85
Pull request: no

The error type is "TypeError: FakeTensor.__new__() got an unexpected keyword argument 'fake_device'"

The code:
import torch
from torch import nn
from torch._subclasses import FakeTensorMode
from typing import Optional, Callable, Dict, Any
from transformers import AutoModelForCausalLM, AutoTokenizer

class BaseModelLoader:
    def __init__(
        self, 
        model_provider: Optional[Callable],
        model_kwargs: Dict[str, Any] = {},
        fake_device_str: str = "cpu"  
    ) -> None:
        self.model_provider = model_provider
        self.model_kwargs = model_kwargs
        self.device_str = fake_device_str

    def load(self) -> Optional[nn.Module]:
        raise NotImplementedError("")

class ShadowModelLoader(BaseModelLoader):
    
    def __init__(
        self, 
        model_provider: Optional[Callable],
        model_kwargs: Dict[str, Any] = {},
        fake_device_str: str = "cpu"
    ) -> None:
        super().__init__(model_provider, model_kwargs, fake_device_str)
        torch.__future__.set_swap_module_params_on_conversion(False)

    def load(self) -> Optional[nn.Module]:
       
        with FakeTensorMode() as fake_mode:
            model = self.model_provider(**self.model_kwargs) if self.model_provider else None
            if model is None:
                return None

            self._configure_fake_tensors(model, self.device_str)            
            return model

    def _configure_fake_tensors(self, model: nn.Module, device_str: str):
        device = torch.device(device_str)
        for name, param in model.named_parameters():
            if hasattr(param, 'fake_device'):
                param.fake_device = device  

def get_huggingface_model(model_name: str) -> nn.Module:
    return AutoModelForCausalLM.from_pretrained(
        model_name,
        torch_dtype=torch.float32,
        low_cpu_mem_usage=True
    )

if __name__ == "__main__":
    model_config = {
        "model_name": "gpt2"  
    }

    loader = ShadowModelLoader(
        model_provider=get_huggingface_model,
        model_kwargs=model_config,
        fake_device_str="cpu"
    )

    model = loader.load()

Comments:
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.
Revert FA2 kwargs construction
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

As per title, discussed internally


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

> So if I understand the PR correctly we're moving back to prepare during generate instead of during the fa forward? 👀

yep, to be explicit + a lil faster than computing in FA2 utils per layer

Morning @zucchini-nlp. I have a question here 🖐️ 
>yep, to be explicit + a lil faster than computing in FA2 utils per layer

What about BART-based models? They use three types of attention: `encoder self-attention`, `decoder self-attention`, and `decoder cross-attention`, each with different fa2 `kwargs`. `encoder self-attention` can be skipped since it’s computed only once at the start, but my concern is with `decoder self-attention` and `decoder cross-attention`.

edit for more clearer: If we initialize fa kwargs during generation, can we set different kwargs for `decoder self-attention` and `decoder cross-attention`?

@ducviet00 You're right that in this form it won't work for Bart but it also doesn't support the `attention_backend` flag so it should not even enter the preparation path and it has the usual calls as before 

It has to be changed in the future then tho, I agree! 

Yay, CI is green finally
🌐 [i18n-KO] Translated `auto_docstring.md` to Korean
Author: chelsseeey
Pull request: yes

# What does this PR do?

Translated the `auto_docstring.md` file of the documentation to Korean.
Thank you in advance for your review.

Part of https://github.com/huggingface/transformers/issues/20179

## Before reviewing
- [x] Check for missing / redundant translations (번역 누락/중복 검사)
- [x] Grammar Check (맞춤법 검사)
- [x] Review or Add new terms to glossary (용어 확인 및 추가)
- [x] Check Inline TOC (e.g. `[[lowercased-header]]`)
- [x] Check live-preview for gotchas (live-preview로 정상작동 확인)

## Who can review? (Initial)

May you please review this PR?
@4N3MONE, @yijun-lee, @jungnerd , @harheem 

## 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#start-contributing-pull-requests),
      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? (Final)

<!-- 2. KREW 팀원들의 리뷰가 끝난 후에 아래 주석을 노출해주세요! -->
<!-- @stevhliu May you please review this PR? -->


Comments:
Would you mind resolving the conflict before we merge please? 🤗
refactor(modeling_llama): make RotaryEmbedding default path explicit
Author: pco111
Pull request: yes

# What does this PR do?

This PR refactors `LlamaRotaryEmbedding` to make the initialization for the default `rope_type` more explicit, as suggested in issue #39753.

Instead of relying on the `ROPE_INIT_FUNCTIONS` dictionary for the default case, the code now uses a direct call to `_compute_default_rope_parameters`. The dictionary lookup is reserved for non-default `rope_type` values. This change improves code readability and maintainability by making the default execution path clearer, aligning with the "explicit is better than implicit" philosophy.

<!-- Remove if not applicable -->

Fixes #39753


## 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. (Link: https://github.com/huggingface/transformers/issues/39753)
- [ ] 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). (Not applicable, as this is an internal refactor with no user-facing changes).
- [ ] Did you write any new necessary tests? (Not applicable, existing tests cover this refactoring).


## Who can review?

@ArthurZucker @gante

Comments:
~~Hi @ArthurZucker, thanks for the feedback! I agree with your proposal and tried several revisions today, but I haven't been able to pass the CI test. Since I may not have enough time to completely solve this problem recently, I'm afraid I have to temporarily close this PR and come back later. Thank you for your review! 😃~~

Sorry, but let me give it a couple more tries😂

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

run-slow: arcee, aria, bamba, bitnet, cohere, cohere2, csm, deepseek_v3, dia, diffllama, doge, dots1, emu3, ernie4_5, ernie4_5_moe, evolla

Hey @pco111 👋 

@zucchini-nlp is working on a larger refactor of RoPE, which may conflict with this PR 🤔  

(@zucchini-nlp can you confirm whether this part of the problem can be worked on independently?)
Update Glm4V processor and add tests
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

As per title, the processor has no tests and currently user-defined `size` isn't being used when processing images/videos

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39988). 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: glm4v
New dynamic cache for sliding window attention
Author: Cyrilvallez
Pull request: yes
Labels: name: run-benchmark

# What does this PR do?

This supersedes https://github.com/huggingface/transformers/pull/33619 to introduce a new `DynamicSlidingWindowCache`.  

This cache behaves the exact same way as `DynamicCache`, and contrarily to `SlidingWindowCache` (static variant), we can correctly continue generation from an existing cache instance (fully filled or not), with more than 1 new token added to the sequence (e.g. for prefix caching).

In order for this to work I had to do the following main modifications:

- I introduced `get_past_seen_tokens()`, which should replace `get_seq_length()` (almost) everywhere. This is because once the cache is filled, the 2 will not longer provide the same information, so we need to correctly differentiate to recreate the `cache_position`
- for every cache class except `DynamicSlidingWindowCache`, both `get_past_seen_tokens` and `get_seq_length` will return the same value, so no issue there
- For every generative model using sliding window, I modified the 4d causal mask creation for the new cache class for both sdpa and eager, and correctly sliced the 2d mask for FA2

Once `generate` no longer returns legacy cache by default (tuples), we can make this class the default for generative models with sliding window. We cannot do it before because we would lose the information of the past seen tokens if the cache is full.  

It also makes a nice precedent to support the same features with the static variant in a subsequent PR.


Comments:
Ok @ArthurZucker it has been a long time on the side but it's now ready for final review!

Slow tests for Mistral are all good (4 failing but similar on main)

Hey! As we discussed offline, not super super sure we need this. The big blocker for me is that you are changing a lot of model forward, which is something we try to avoid !
Improve CI/CD by completing migration from setup.py to pyproject.toml
Author: ParagEkbote
Pull request: no

Since the release of [PEP 621](https://peps.python.org/pep-0621/), the .toml file has been increasingly adopted for simpler usage and its enhanced functionality. I believe that by adopting the .toml file for packaging and managing dependencies as well, we can also make the process of publishing future release versions simpler as well.

For the upcoming release of transformers v.5.0, I think that the CI/CD practices of the project can move beyond the allennlp package, which has been in read-only mode for a couple of years. WDYT?

cc: @ydshieh, @ivarflakstad

Comments:
Hi @ParagEkbote 

Thank you for requesting this 👍 

I am open to it, but other team members are more involved with release process, so I can't speak for all of them.

Actually, would you like to expand a bit more to explain why using a single `pyproject.toml`is a better approach than the current apporach. What advantages it brings for CI/CD and for release process?

Thanks for reaching out so soon @ydshieh :)

Firstly, we could reduce the number of config files needed. Also as described in the [pyproject.toml spec](https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#dependencies-optional-dependencies), there is sufficient support for declaring the dependencies in the .toml file itself. As for the why, setup-tools also recommends keeping the project dependencies in a declarative config instead of setup.py as seen [here](https://setuptools.pypa.io/en/latest/userguide/quickstart.html#transitioning-from-setup-py-to-declarative-config). 

This can help simplify CI/CD to consume all of your dependencies and tooling in a single `pyproject.toml` file.


Also, which team members could I ping for more context/awareness about the release process?

cc @ArthurZucker @Cyrilvallez and @LysandreJik to see if this would help the release process and overall the library maintenance

Hey! In general, I'm in favor as it's the current best practice to use `pyproject.toml`! But I'll let @ArthurZucker and @LysandreJik decide as I'm the junior-most on the release process!

Down for it! @LysandreJik ? 

After analyzing the setup.py file further, I noticed that it handles a variety of tasks beyond publishing packages and handling dependencies. 

We could use [tox](https://tox.wiki/en/3.26.0/index.html#) as a task runner for general maintenance commands (updating version files, syncing dependencies and pre-release checks) and `pyroject.toml` for dependency management and publishing packages. We could have the `Makefile` as a wrapper while tox maintains the logic and isolation. WDYT?

Sounds like a lot more changes! Let's leave it as that for now 😉 

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: resolve dropout type error in DogeDecoder
Author: wubingheng111
Pull request: yes

Fix: #40079
Fixed TypeError where dropout() received tuple instead of Tensor in DogeDecoderLayer when using MoE configuration. The MLP forward method returns a tuple (hidden_states, router_logits) for MoE layers, but the subsequent dropout operation expected only a Tensor.

- Extract hidden_states from tuple before dropout when using MoE
- Ensure consistent tensor handling in both MLP and MoE configurations

Fixes issue where model.generate() failed with:
TypeError: dropout(): argument 'input' (position 1) must be Tensor, not tuple
@ArthurZucker  @gante @LoserCheems 

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

run-slow: doge
Re-apply make style
Author: Cyrilvallez
Pull request: yes

# What does this PR do?



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

run-slow: mxfp4

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40106). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix an annoying flaky test
Author: zucchini-nlp
Pull request: yes

# What does this PR do?

As per title, trying to download the image from `picsum` times out if we run the test many times, so I moved the image to HF hub. AFAIK we can make many subsequent requests to hub downloads when testing

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

> AFAIK we can make many subsequent requests to hub downloads when testing

this is only valid if we are using HF's related methods I believe (something similar to `from_pretrained`).

When it is in user prompt, do you know what methods are used to download images? (pure python `request` ..?) 

Ah, then I am not sure if this helps with issues because of too many requests. The chat template script uses simple `requests` to download the file 

Oke, let's merge and see if it becomes less flaky

PR #40000 😱 

Congratulation! You should tweet this!
Replace `logger.warning` with `logger.warning_once` in `GradientCheckpointingLayer`
Author: qgallouedec
Pull request: yes

You get thousands of this warning during training otherwise 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40091). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Switch the order of args in StaticCache (for BC and future logic)
Author: Cyrilvallez
Pull request: yes

# What does this PR do?

As per the title.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_40100). 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: llama
Update boxes expectations for OWLViT test
Author: mihaidusmanu
Pull request: yes

# What does this PR do?

While working on a related PR #40023, I noticed some OWLViT tests were failing on main on my local machine.
Seems to be some minor differences in the predicted boxes so I simply updated them to the latest values (the other outputs seem correct).
Not sure if this is hardware-related or something that slipped through at some point - I'm running on a RTX 4080 SUPER on WSL (pip torch 2.7.1 cuda 12.6, os cuda version 12.9)

## 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?

## Who can review?

Maybe @amyeroberts @qubvel @ArthurZucker 

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

run-slow: owlvit

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

@mihaidusmanu it's ok, you might have it fail on your hardware, the most important for us is to make it pass on the CI

cc @ydshieh 

run-slow: owlvit

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

models: ['models/owlvit']
quantizations: [] ...

New values fail on CI, closing this PR

yeah, the values on main pass on CI runners (A10)
Default to dequantize if cpu in device_map for mxfp4
Author: MekkCyber
Pull request: yes
Labels: name: for patch

# What does this PR do?

For mxfp4 gptoss model, if no cuda device is available and the model is prequantized we default to dequantizing it after raising a warning so that it can run on cpu


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39993). 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: mxfp4
[docs] Add reference to HF-maintained `custom_generate` collections
Author: gante
Pull request: yes

# What does this PR do?

- Add reference to HF-maintained `custom_generate` collections
- Rename "custom decoding method" -> "custom generation method" in the docs

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39894). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
🌐 [i18n-KO] Translated `auto_docstring.md` to Korean
Author: chelsseeey
Pull request: yes

# What does this PR do?

Translated the `auto_docstring.md` file of the documentation to Korean.
Thank you in advance for your review.

Part of https://github.com/huggingface/transformers/issues/20179

## Before reviewing
- [X] Check for missing / redundant translations (번역 누락/중복 검사)
- [X] Grammar Check (맞춤법 검사)
- [X] Review or Add new terms to glossary (용어 확인 및 추가)
- [X] Check Inline TOC (e.g. `[[lowercased-header]]`)
- [X] Check live-preview for gotchas (live-preview로 정상작동 확인)

## Who can review? (Initial)

May you please review this PR?
@jungnerd, @luckyvickyricky, @chelsseeey, @skwh54, @amo33, @maximizemaxwell, @D15M4S 
<!-- @harheem, @nsbg, @Youngdong2, @xhaktm00, @ssunbear, @ChoHyoungSeo, @judy-choi -->
<!-- @4N3MONE, @Kim-Ju-won, @ahnjj, @FacerAin, @ssum21, @TaskerJang, @HyunZ118 -->
<!-- @yijun-lee, @songi104, @chhaewxn, @AhnJoonSung, @jihyun-0611, @seopp, @pyapyapya -->

## 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#start-contributing-pull-requests),
      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? (Final)

<!-- 2. KREW 팀원들의 리뷰가 끝난 후에 아래 주석을 노출해주세요! -->
<!-- @stevhliu May you please review this PR? -->

Comments: