noamaanMulla-03/transformers-issues huggingface dataset:
[docs] ko toc fix
Author: gante
Pull request: yes

# What does this PR do?

Restores green CI status after merging #39535 

👉 check docs locally: `doc-builder build transformers docs/source/ko/ --language ko --clean`
👉 check docs in CI: comment `build-doc`

Comments:
build-doc

[Building docs for all languages...](https://github.com/huggingface/transformers/actions/runs/16755710366)

I am seeing the removed lines appear in some other files?

@ydshieh we can see the removed docs in other languages because they are more outdated than the Korean docs :D the reference here is the `en` docs: on `en`, the removed entries do not exist 

(ci is failing until #39929 is merged -- will trigger the doc builder again afterwards)

build-doc

[Building docs for all languages...](https://github.com/huggingface/transformers/actions/runs/16757726176)

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

build-doc

[Building docs for all languages...](https://github.com/huggingface/transformers/actions/runs/16758530583)

[I'm fairly confident that this PR is okay, but the corresponding full doc CI is running against main, as opposed to this PR. I'm merging to test this 🤗 🤞 ]
docs: fix typo in 'quantization-aware training'
Author: nevertmr
Pull request: yes

# What does this PR do?

This PR fixes a minor typo in the documentation:
- "quantization-aware trainin" → "quantization-aware training"

## Before submitting
- [x] 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?

@jungnerd, @chelsseeey, @skwh54, @amo33, @maximizemaxwell, @D15M4S


<!-- 
Documentation: @stevhliu
 -->

Once the translation crew members listed above have checked and approved this PR, I will mention maintainer for final review and merging.

Thank you!


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39904). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
transformers serve doesn't handle OPTIONS http method
Author: alew3
Pull request: no
Labels: name: Feature request

name: bug

### System Info

I'm trying to run a model via transformers server, it's working fine via curl.

But when I try to plug an OpenWeb UI in front to connect to the server, the browsers sends first an OPTIONS http method that gets denied.

``` 
INFO:     127.0.0.1:43740 - "OPTIONS /v1/chat/completions HTTP/1.1" 405 Method Not Allowed
```



### Who can help?

_No response_

### Information

- [ ] The official example scripts
- [ ] My own modified scripts

### Tasks

- [ ] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

1. start 
```
transformers serve
```

Run openwebui and point it to transformers serve.

```
docker run -d --rm -p 3000:8080 \
-e MODEL=openai/gpt-oss-20b \
-v open-webui:/app/backend/data \
--name open-webui ghcr.io/open-webui/open-webui:main
```

Open the browser on http://localhost:3000/ 


Open Open WebUI in your browser.

Go to ⚙️ Admin Settings → Connections → OpenAI Connections.

Click ➕ Add Connection.

URL: Use your server’s API endpoint (for example, http://localhost:8000/v1 for
API Key: Leave blank unless required.
Click Save.


Try to interact with the model.

### Expected behavior

it should work :-)

Comments:
cc @gante and @LysandreJik 

Thanks @alew3, let us take a look!

Hi @alew3 -- have you tried launching `transformers serve --enable-cors`?

(openwebui, cursor, and a few other apps require this flag :) )

@gante thanks! that was the issue! closing this!
Use torch._check instead of a test to make the model Gemma3 exportable
Author: xadupre
Pull request: yes

# What does this PR do?

torch.export.export fails on a tests used to raise an exception if not true. This is replaced by torch._check to avoid torch.export.export complain about it.

Fixes # (issue)

## 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?


Comments:
cc @tugsbayasgalan

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

run-slow: aria, aya_vision, chameleon, cohere2_vision, emu3, fuyu, gemma3, got_ocr2, internvl, llava, mistral3, paligemma, paligemma2, vipllava
Fix grammatically incorrect variable name "expert_hitted" → "expert_hit" in MoE implementation
Author: Mihonarium
Pull request: no

## Description
The variable name `expert_hitted` used in the Mixture of Experts (MoE) implementations is grammatically incorrect. The past tense/past participle of "hit" is "hit", not "hitted".

## Current behavior
The codebase currently uses `expert_hitted` in:
- `src/transformers/models/gpt_oss/modular_gpt_oss.py`
- `src/transformers/models/mixtral/modular_mixtral.py`
- `src/transformers/models/ernie4_5_moe/modular_ernie4_5_moe.py`
- `src/transformers/models/qwen3_moe/modular_qwen3_moe.py`

As well as what I assume is generated code:
- `src/transformers/models/gpt_oss/modeling_gpt_oss.py`
- `src/transformers/models/mixtral/modeling_mixtral.py`
- `src/transformers/models/ernie4_5_moe/modeling_ernie4_5_moe.py`
- `src/transformers/models/qwen3_moe/modeling_qwen3_moe.py`
- `src/transformers/models/qwen2_moe/modeling_qwen2_moe.py`
- `src/transformers/models/minimax/modeling_minimax.py`

It also uses `hitted_experts` in:
- `src/transformers/integrations/mxfp4.py`

## Proposed solution
Rename all instances of `expert_hitted` to `expert_hit` and `hitted_experts` to `hit_experts` to correct the grammar while maintaining the original intent of the variable name.

## Impact
- This is a non-breaking internal variable name change
- Improves code readability
- No API changes required

## Additional context
I'll try to submit a PR to fix this.

Comments:
Ruff format & ruff check --fix
Author: jackzhxng
Pull request: yes

# What does this PR do?
`ruff format`
`ruff check --fix`

## 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?

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

run-slow: data2vec, dia, distilbert

hi @jackzhxng, we already use `ruff`, including in the CI! I think you just formatted with a different `ruff` version. Check the versions in `setup.py` and the details in `pyproject.toml`.
fix glm4v image process
Author: KeyKy
Pull request: yes

@amyeroberts , @qubvel 

Issue: shortest_edge and longest_edge in preprocess_config.json are being ignored during GLM-4V image preprocessing. Please investigate and fix.



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

run-slow: glm4v

run-slow: glm4v

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

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

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39964). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Option to tokenize messages one after the other
Author: VivienCabannes
Pull request: no
Labels: name: Chat Template

In many settings, we want to perform token-to-token interaction with an assistant, meaning that it would be beneficial to tokenize messages one after the other rather than all at once.

Assume I have:
```python
conversation = [
    {"role": "system", "content": "You are a helpful assistant"},
    {"role": "user", "content": "Hey there, how are you?"},
    {"role": "assistant", "content": "Thank you for asking, I am doing well"},
    {"role": "user", "content": "What the weather like today?"},
    {"role": "assistant", "content": "Today the weather is nice"},
]
```
I would like to have a function `tokenizer.encode_message` so that executing:
```python
tokens = []
for message in conversation:
    tokens += tokenizer.encode_message(message)
```
would result in the same behavior as executing:
```python
tokens = tokenizer.apply_chat_template(conversation, tokenize=True)
```

At the moment, this does not seem possible (but maybe I am missing the right function to do so). So far, here is my workaround:
```python
class MyDialogTokenizer:
    def __init__(self, tokenizer):
        self.tokenizer = tokenizer
        self._user_stub = {"role": "user", "content": "hello"}
        self._assistant_stub = {"role": "assistant", "content": "world"}
        self._len_prefix_assistant = len(self._encode_dialog([self._user_stub]))
        self._len_prefix_tool = len(
            self._encode_dialog([self._user_stub, self._assistant_stub])
        )

    def _encode_dialog(
        self, dialog: list[dict[str, str]], eom: bool = True
    ) -> list[int]:
        return self.tokenizer.apply_chat_template(
            dialog, tokenize=True, continue_final_message=not eom
        )

    def encode_message(self, source: str, body: str, eom: bool = True) -> list[int]:
        msg_dict = {"role": source, "content": body}
        match source:
            case "system" | "user":
                return self._encode_dialog([msg_dict], eom=eom)
            case "assistant":
                return self._encode_dialog(
                    [self._user_stub, msg_dict],
                    eom=eom,
                )[self._len_prefix_assistant :]
            case _:
                return self._encode_dialog(
                    [self._user_stub, self._assistant_stub, msg_dict],
                    eom=eom,
                )[self._len_prefix_tool :]
```

Thank you in advance

Comments:
cc @Rocketknight1 

Hello, I encountered a similar problem and wrote the above PR to try to solve it (it seems to work). I wonder if this can also solve your problem? I hope it helps.

Hey there, I am not sure the PR solve the issue as it requires the user to keep the chat history
Fix grammatical error in MoE variable name: expert_hitted → expert_hit, hitted_experts → hit_experts
Author: Mihonarium
Pull request: yes

# What does this PR do?

Fixes a grammatical error in variable naming across all Mixture of Experts (MoE) implementations. The variables `expert_hitted` and `hitted_experts` are grammatically incorrect: the past tense/past participle of "hit" is "hit", not "hitted".

Fixes #39955.

## Before submitting
- [x] 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?

## Who can review?

Anyone can review. This is a simple grammatical fix in internal variable naming. No functionality changes.

## Changes made

Renamed `expert_hitted` → `expert_hit` in:
- `src/transformers/models/gpt_oss/modular_gpt_oss.py`
- `src/transformers/models/mixtral/modular_mixtral.py`
- `src/transformers/models/ernie4_5_moe/modular_ernie4_5_moe.py`
- `src/transformers/models/qwen3_moe/modular_qwen3_moe.py`
- `src/transformers/models/gpt_oss/modeling_gpt_oss.py`
- `src/transformers/models/mixtral/modeling_mixtral.py`
- `src/transformers/models/ernie4_5_moe/modeling_ernie4_5_moe.py`
- `src/transformers/models/qwen3_moe/modeling_qwen3_moe.py`
- `src/transformers/models/qwen2_moe/modeling_qwen2_moe.py`
- `src/transformers/models/minimax/modeling_minimax.py`

Renamed `hitted_experts` -> `hit_experts` in:
- `src/transformers/integrations/mxfp4.py`


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

run-slow: ernie4_5_moe, gpt_oss, minimax, mixtral, qwen2_moe, qwen3_moe

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39959). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix `fix_and_overwrite` mode of `utils/check_docstring.py`
Author: manueldeprada
Pull request: yes

Fixed it @ydshieh :)

The script was failing to apply fixes because of a mismatch in how it reads the docstring for comparison versus how it reads it for replacement.

-   To detect a mismatch, the script reads the docstring from the `obj.__doc__` attribute. Python automatically un-indents the string provided by `__doc__`.
-   To apply a fix, the script reads the code from the source file using `inspect.getsourcelines()`, which preserves the original indentation.

The `fix_docstring` function would first try to locate the argument block within the raw source code. To ensure it had found the right place, it would compare the text from the source (with indentation) against the text from `__doc__` (without indentation). This comparison would then fail.

Probably the check we talked about is not needed anymore, maybe should we remove it? Or leave it as-is to be extra cautious?

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

Hi @manueldeprada 

I won't be available to review until next Friday.

BTW, do you mean the issue you found for 

https://github.com/huggingface/transformers/pull/38915#discussion_r2200675302



Yes, that one. Enjoy!! Its minor, it can wait for a week :)

@ydshieh gentle ping on this 🤗  Btw, I have successfully fixed a few docstrings using the new version :)

> Thanks for diving into this!
> 
> One question:
> 
> > obj.**doc** attribute. Python automatically un-indents the string provided by **doc**
> 
> Is this always? Because if so, we should have troubles at many places (before this PR) no? But we only have seen a few places.

It only affects the fixing mode, not the checks on the docstring. I guess devs have got used to fixing the docs manually (we can ask).

Every time I had to fix a doc issue in my cache refactor this issue happened, and I had to either cherry pick this or fix the docstring manually.

Also, If a docstring is placed at root level indentation, there is no difference. But it is indeed a consistent behaviour:
```
>>> def f():
...     """
...     Hello
...          World
...     """
...     
>>> repr(f.__doc__)
"'\\nHello\\n     World\\n'"
>>> import inspect
>>> inspect.getsourcelines(f)[0]
['def f():\n', '    """\n', '    Hello\n', '         World\n', '    """\n']
```
Fix MXFP4 quantizer validation to allow CPU inference with dequantize option
Author: returnL
Pull request: yes
Labels: name: for patch

# What does this PR do?

This PR fixes a bug that prevented MXFP4 models from running on CPU when `quantization_config.dequantize=True` was set.

## Problem
The validation logic in `Mxfp4HfQuantizer` checked CUDA availability before checking the `dequantize` flag, causing failures on CPU-only environments even when dequantization was enabled.

## Solution
Reordered validation checks to prioritize `dequantize` configuration:
1. Check if `dequantize` is enabled - if yes, skip GPU validations
2. Only then check CUDA availability

## Changes Made
- **Fix**: Moved `dequantize` check before CUDA validation in `quantizer_mxfp4.py`
- **Tests**: Added test cases to verify CPU inference with `dequantize=True`

## Before submitting
- [x] Did you read the contributor guideline?
- [x] Did you write any new necessary tests?

## Who can review?
@SunMarc @MekkCyber

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_39953). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Enable gpt-oss mxfp4 on older hardware (sm75+)
Author: matthewdouglas
Pull request: yes
Labels: name: for patch

# What does this PR do?

Currently the MXFP4 quantized version of gpt-oss models is restricted to newer GPUs (Hopper and Blackwell). This PR enables the MXFP4 version on Turing, Ampere, and Ada GPUs.

Tested with the gpt-oss-20b on RTX 4090 and T4.

If the user has the kernels installed but the hardware is too old, we'll fall back to dequantizing instead of raising an error.

There's additionally a fix included here for a device mismatch issue that occurred when running with `device_map="auto"` on 2x4090.

## 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).
- [x] Did you write any new necessary tests?


## Who can review?
@SunMarc @MekkCyber 

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39940). 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
README: Update Bert Japanese model card
Author: KeshavSingh29
Pull request: yes

# What does this PR do?

As mentioned in #36979 , contributing to HF model cards, specifically to Bert Japanese. 

Fixes # (issue)

## Before submitting
- [x] 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. 
- [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).
- [ ] Did you write any new necessary tests?


## Who can review?
@stevhliu

Comments:
chore: update Deformable_Detr model card
Author: arpon-kapuria
Pull request: yes

# What does this PR do?

This PR improves the model card of Deformable DETR.

## Before submitting
- [x] This PR fixes a typo or improves the docs 

## Who can review?

Anyone in the community is free to review the PR once the tests have passed. 
@stevhliu



Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_39902). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Modular fix: remove the model name in `find_file_type`
Author: yonigozlan
Pull request: yes

# What does this PR do?

Remove the model name in `find_file_type` in `modular_model_converter.py` as it can cause issues when the module name is ambiguous.
For example, in [this PR](https://github.com/huggingface/transformers/pull/32317), the model name is sam2_video (Sam2Video), and I want to use modular for its processor, Sam2VideoProcessor. The current modular associate this module to the video processor file because it contains VideoProcessor.
The fix removes the "Sam2Video" part, clearing the ambiguity.

Tested on main with `python utils/check_modular_conversion.py --fix_and_overwrite --check_all` and it doesn't break any other model!

Cc @Cyrilvallez 

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

This PR fixes several `gemma3` tests:
- on any GPU, there is a possible multi-devices error that can arise in the forward of `Gemma3Model` which was fixed by specifying the device in a tensor creation
- on AMD MI300, there are now new expectations for some generation tests

cc. @zucchini-nlp maybe because this is a multi-modal model

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

run-slow: gemma3

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