noamaanMulla-03/transformers-issues huggingface dataset:
Fix epoch logging for iterable dataloaders
Author: lilin-1
Pull request: yes

**What does this PR do?**
- Fixes incorrect fractional `epoch` progress logging when training with iterable dataloaders that do not provide a length (`__len__`). When the dataloader length is unknown, the previous logic divided by the total training plan (`max_steps * gradient_accumulation_steps`), producing misleading values like `0.05 → 0.5 → 1.05`. This PR makes `epoch` an integer counter in such cases, while preserving the existing fractional progress for dataloaders with a known length.
- Fixes #41913

**Motivation and Context**
- With iterable datasets without `__len__`, `steps_in_epoch` is set to `args.max_steps * args.gradient_accumulation_steps`, which is the global training plan, not the number of steps in the current epoch. As a result, logs show fractional `epoch` increments that do not reflect the actual pass over the dataset, confusing users and tooling that rely on `epoch` semantics.
- This change aligns the `epoch` field with its core meaning when the true epoch length is unknown: a pass counter (integer), while keeping the original fractional behavior when the epoch length is known.

**Changes**
- One-line change in the trainer to gate fractional epoch calculation on the presence of a dataloader length:
  - `src/transformers/trainer.py:2596`
  - Before: `self.state.epoch = epoch + (step + 1) / steps_in_epoch`
  - After: `self.state.epoch = epoch if len_dataloader is None else epoch + (step + 1) / steps_in_epoch`

**Before vs After**
- Before (iterable dataloader without `__len__`):
  - Logs: `epoch=0.05, 0.10, …, 0.50` then `1.05, 1.10, …, 1.50`
  - Fractional progress derived from global `max_steps`, not real per-epoch steps
- After:
  - Iterable dataloader without `__len__`: `epoch` is an integer (0 for first pass, 1 for second, etc.)
  - Dataloader with `__len__`: unchanged; `epoch` shows fractional progress with correct per-epoch denominator

**Backward Compatibility**
- No change for standard dataloaders with `__len__`; fractional logging remains as-is
- Callbacks or dashboards that expect fractional `epoch` values with unknown-length dataloaders will now see integers; these should rely on `global_step` for fine-grained progress in such scenarios
- `global_step`, optimizer scheduling, and LR schedulers are unaffected

**Dependencies**
- None

**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 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 https://discuss.huggingface.co/? Please add a link to it if that's the case. Fixes #41913
- [ ] Did you make sure to update the documentation with your changes? Here are the https://github.com/huggingface/transformers/tree/main/docs, and https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation.
- [ ] Did you write any new necessary tests?

**Who can review?**
- Trainer: @SunMarc

Comments:
opt-125m is missing weight for embed and lm_head when use_safetensors=True
Author: xin3he
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 4.57.3
- Platform: Linux-5.4.0-169-generic-x86_64-with-glibc2.35
- Python version: 3.12.9
- Huggingface_hub version: 0.36.0
- Safetensors version: 0.5.3
- Accelerate version: 1.11.0
- Accelerate config:    not found
- DeepSpeed version: 0.17.5
- PyTorch version (accelerator?): 2.9.0+cu128 (CUDA)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using distributed or parallel set-up in script?: <fill in>
- Using GPU in script?: <fill in>
- GPU type: NVIDIA A100-SXM4-80GB


### Who can help?

@ArthurZucker @Cyrilvallez

### Information

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

### Tasks

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

### Reproduction

I found that the lm_head is not loaded correctly for `opt-125m` while llama3.2 1B is fine.

```python
import transformers
import torch
model = transformers.AutoModelForCausalLM.from_pretrained("facebook/opt-125m", torch_dtype=torch.float16, use_safetensors=True)

>>> print(model.lm_head.weight)
Parameter containing:
tensor(..., device='meta', size=(50272, 768), dtype=torch.bfloat16,
       requires_grad=True)

```

### Expected behavior

Expecting weights are loaded correctly.

Comments:
Hey! can you try on `v5.0.0rc2` please? 

It's resolved, thank you @ArthurZucker
Grouped beam search from config params
Author: zucchini-nlp
Pull request: yes
Labels: name: for patch

# What does this PR do?

Ensures that we can fallback to hub-based group generation from generation args, even if the custom generate is not passed. And, I updated the version in deprecation cycle. I don't think we will break it for v5 yet


```python

from transformers import BartForConditionalGeneration, GenerationConfig
import torch

model_id = "hf-internal-testing/tiny-random-bart"
model = BartForConditionalGeneration.from_pretrained(model_id)
gen_config = GenerationConfig(
    num_beams=4,
    do_sample=False,
    max_new_tokens=10,
    min_new_tokens=10,
    num_beam_groups=2,
    diversity_penalty=0.0001,
    use_cache=True,
)

input_ids = torch.tensor([[model.config.bos_token_id]])
out = model.generate(input_ids, generation_config=gen_config, trust_remote_code=True)

```

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

Test failures not related
SAM 3 missing point prompting
Author: kliyer-ai
Pull request: no
Labels: name: Feature request

### Feature request

SAM 3, similar to SAM 2, also supports prompting using points. However, it doesn't seem to be supported for SAM 3 currently. Can we get support for it?

### Motivation

Positive and negative point prompting would be very valuable for using SAM 3 effectively.

### Your contribution

I'm just wondering if there is a reason that this is not included for SAM 3? 

Comments:
Meta's SequenceGeometryEncoder in their sam3 repo sam3/model/geometry_encoders.py already supports point prompts with three encoding paths (direct projection, pooled features, position encoding) + label embeddings and optional "encode boxes as points". Sam3GeometryEncoder here is essentially the same shape but currently only implements boxes. 

I can try implementing it(see below)

UPD: Actually, there are 2 APIs right now. This distinction did not exist for SAM2 as far as I know. So right now SAM3 has
- PCS (Sam3Model): Uses a Text/Concept Encoder. It doesn't expect points; it expects semantic vectors.
- PVS (Sam3TrackerModel): Uses a Prompt Encoder (like SAM 2). It expects points/boxes.

You can use `Sam3TrackerModel` right now and give points. 
Can someone else confirm this? There won't be any need to extending PCS part by accepting input points and passing them into the geometry encoder?

Hey @rbSparky,

You are right, thanks for bringing this to my attention! I overlooked the "Tracker" model for Sam3.

If I use the tracker versions `from transformers import Sam3TrackerProcessor, Sam3TrackerModel` the API is exactly the same as SAM2, and I can just drop it in my existing SAM2 code.

I think with that we can close the issue.

Nick

What is weird is that purely based on some qualitative explorations, SAM2 seems to perform better than SAM3 for single point prompting...

SAM2
<img width="720" height="405" alt="Image" src="https://github.com/user-attachments/assets/1c82e1e7-51d7-40d8-88d4-a410185c1f2a" />

SAM3
<img width="720" height="405" alt="Image" src="https://github.com/user-attachments/assets/fabf504c-e4b7-42e2-94ee-6ed9278ee468" />

Perhaps something is not yet properly implemented?
Single-scale image input support for SAM3 Mask Decoder
Author: Enq666
Pull request: no
Labels: name: Feature request

### Feature request

The current SAM3 Mask Decoder still expects multi-scale image features (usually FPN levels P2–P4). The original SAM3 code already supports single-scale image-feature input.

### Motivation

The decoder should accept only one level of image features.

### Your contribution

The decoder should accept only one level of image features.

Comments:
Hey @Enq666 I identified a gap in the SAM3 implementation where single-scale inference was impossible, limiting its use in custom pipelines. I reverse-engineered the logic to match the original research code, implemented a polymorphic forward pass, and ensured 100% backward compatibility with existing checkpoints. I also added defensive logging to prevent silent user errors. Please review. Thanks!

cc @nielsrogge @molbap @yonigozlan - there's an LLM PR at #43044 as well
[`Generate`] Allow custom config values in generate config
Author: vasqu
Pull request: yes

As per title, followup to a series of PRs that address the new config logic
- #43000
- #42958
- #42702

tl;dr: custom values in an uploaded generation config are ignored atm

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43181). 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=43181&sha=cb4bda

Finally got it
Improve error message for AutoTokenizer loading invalid tokenizers (#41553)
Author: sangeethae111
Pull request: yes
Labels: name: Code agent slop

-	Summary
Fixes #41553 by improving the error message raised when `AutoTokenizer.from_pretrained()` fails to load a tokenizer.
-	What I Changed
- Improved exception handling to provide clearer, more actionable error messages.
- Added a unit test to ensure the improved error message is raised when an invalid tokenizer is provided.
-	 Why This Change Is Needed
The previous error message did not clearly explain whether the failure was caused by an invalid model name, missing tokenizer files, or configuration issues. This change improves developer experience and reduces confusion during debugging process.
-	 Testing
			Added a unit test that attempts to load an invalid tokenizer and checks the error message.
•	Ran ‘pytest tests/models/auto/test_tokenizer_error_message.py’ command in VS code terminal.
•	Verified no regression in existing tokenizer tests.
•	All tests passed successfully.

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

run-slow: auto

View the CircleCI Test Summary for this PR:

https://huggingface.co/spaces/transformers-community/circle-ci-viz?pr=43070&sha=597ccb
compileable=>compilable
Author: cyyever
Pull request: yes

# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

This PR fixes compileable to compilable in source code.
 

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

run-slow: bamba, bloom, codegen, falcon_h1, falcon_mamba, gpt_neo, gpt_neox_japanese, gptj, granitemoehybrid, jamba, kosmos2_5, lfm2, lfm2_moe, longt5, mamba, mllama

View the CircleCI Test Summary for this PR:

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

This is giving me flashbacks to English class, where my teacher called me up on "aging" being the American spelling, with "ageing" being the UK one. "Compilable" is probably a rare enough word that there is no authority on this - are we sure it's the correct form for both UK and US English?
fix(qwen2_5_omni): allow custom Token2Wav noise initialization
Author: osasisorae
Pull request: yes
Labels: name: Code agent slop

# What does this PR do?

- I exposed `Qwen2_5OmniDiTConfig`/`BigVGANConfig` at the top level so the test suite (and user code) can import them directly.
- I added an instance-level `_prepare_initial_state` helper to `Qwen2_5OmniToken2WavDiTModel` so callers/tests can pass their own noise tensors; the modular + generated implementations now share that logic.
- I regenerated `modeling_qwen2_5_omni.py` via `utils/modular_model_converter.py` and added regression tests (`Token2WavSamplingTest`) to cover both the default and custom-noise paths.
- Fixes #43079.

## 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, Pull Request section?
- [x] Was this discussed/approved via a Github issue or the forum? (linked above)
- [ ] Did you make sure to update the documentation with your changes?
- [x] Did you write any new necessary tests?

## Testing
- `PYTHONPATH=src pytest tests/models/qwen2_5_omni/test_modeling_qwen2_5_omni.py -k Token2WavSamplingTest`

## Dependencies
- None.

## Who can review?
Anyone interested in Qwen2.5 Omni audio/token2wav internals. Tagging @zucchini-nlp for visibility.


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

run-slow: qwen2_5_omni

This seems like it adds huge amounts of code complexity for a small bug! Not sure we want this PR as a result
Fix failing `Pix2StructIntegrationTest`
Author: Sai-Suraj-27
Pull request: yes

# What does this PR do?

Fixes this failing [Pix2StructIntegrationTest](https://github.com/huggingface/transformers/actions/runs/20706072009/job/59437072135#step:14:1929).

<img width="1336" height="178" alt="image" src="https://github.com/user-attachments/assets/796b73c0-1406-400b-8f01-1a7b8af65978" />



## 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?
@vasqu

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

run-slow: pix2struct

run-slow: pix2struct

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

models: ["models/pix2struct"]
quantizations: []

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

✅ No failing test specific to this PR 🎉 !


The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43229). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Fix missing UTF-8 encoding in check_repo.py for Windows compatibility
Author: aarushisingh04
Pull request: yes

## What does this PR do?

This PR fixes an inconsistent file-opening pattern in `utils/check_repo.py` by explicitly specifying `encoding="utf-8"` when reading Python source files.

Several utilities in `utils/` already open files with an explicit UTF-8 encoding, but this particular code path relied on the platform default. On Windows, this can lead to `UnicodeDecodeError` or inconsistent behavior when parsing Python files containing non-ASCII characters.

This change aligns the implementation with existing patterns across the repository and improves cross-platform robustness without altering any functional logic.

---

## Before submitting
- [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? (Not required for a small mechanical fix)
- [ ] Did you make sure to update the documentation with your changes? (Not applicable)
- [ ] Did you write any new necessary tests? (Not required for this change)

---

## Who can review?

@ydshieh or anyone else in the community after the checks have passed!


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43123). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
[Tokenizer] Change default value of return_dict to True in doc string for apply_chat_template
Author: kashif
Pull request: yes

# What does this PR do?

This pull request makes a minor update to the `apply_chat_template` function in `src/transformers/tokenization_utils_base.py`, changing the default value of the `return_dict` parameter from `False` to `True` in the docstring to match the default value.

<!-- Remove if not applicable -->

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).
- [ ] 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?

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:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_43223). 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=43223&sha=344e90
Fix Qwen3OmniMoe Talker loading and config initialization
Author: Krish2002
Pull request: yes

## What does this PR do?

This PR fixes two issues that prevented the model
`Qwen/Qwen3-Omni-30B-A3B-Instruct` from loading correctly with
`AutoModelForMultimodalLM`.

---

## Fix 1: `AttributeError: Qwen3OmniMoeTalkerForConditionalGeneration has no attribute 'lm_head'`

### Issue
`Qwen3OmniMoeTalkerForConditionalGeneration` deletes `lm_head` in its `__init__`
method, but it inherits `_tied_weights_keys` from its parent class
(`Qwen3MoeForCausalLM`), which references `lm_head.weight`.

During model loading, `mark_tied_weights_as_initialized()` attempts to access
`lm_head.weight`, resulting in an `AttributeError`.

### Fix
Explicitly set `_tied_weights_keys = {}` for
`Qwen3OmniMoeTalkerForConditionalGeneration`, since this model does not use tied
weights.

This change is implemented in:
- `src/transformers/models/qwen3_omni_moe/modular_qwen3_omni_moe.py`

---

## Fix 2: `AttributeError: ... object has no attribute 'initializer_range'`

### Issue
Several composite config classes were missing the `initializer_range` attribute:
- `Qwen3OmniMoeTalkerConfig`
- `Qwen3OmniMoeCode2WavConfig`
- `Qwen3OmniMoeConfig`

When `_initialize_missing_keys()` runs during model loading, it may call
`_init_weights()` for modules that are not loaded from the checkpoint.
`_init_weights()` expects `self.config.initializer_range`, which caused an
`AttributeError`.

### Fix
Add an `initializer_range` parameter (default: `0.02`) and store it as an
attribute in the affected config classes.

This change is implemented in:
- `src/transformers/models/qwen3_omni_moe/modular_qwen3_omni_moe.py`

---

## Breaking changes

None.

---

## Tests

Added a unit-level regression test in:

tests/models/qwen3_omni_moe/test_configuration_and_loading.py



The test verifies that:
- `Qwen3OmniMoeTalkerForConditionalGeneration` has empty tied weight keys.
- `Qwen3OmniMoeTalkerConfig`, `Qwen3OmniMoeCode2WavConfig`, and
  `Qwen3OmniMoeConfig` all define the `initializer_range` attribute.

Additionally, verified locally that the model loads successfully using the
following reproduction script:

```python
from transformers import AutoModelForMultimodalLM
import torch

model = AutoModelForMultimodalLM.from_pretrained(
    "Qwen/Qwen3-Omni-30B-A3B-Instruct",
    torch_dtype=torch.bfloat16,
    attn_implementation="flash_attention_2",
)


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

run-slow: qwen3_omni_moe

cc @zucchini-nlp

resolved in #43084, closing as duplicate