noamaanMulla-03/transformers-issues huggingface dataset:
Why the calculation of train_batch_size unrelated to split_batches
Author: mklpr
Pull request: no

In the calculation of `train_batch_size` property in transformers/training_args.py,  the formula used is `train_batch_size = self.per_device_train_batch_size * max(1, self.n_gpu)`. When `split_batches` is set to `False`, this is easy to understand: the number of samples on each GPU multiplied by the number of GPUs equals the actual `batch_size`. However, when `split_batches` is set to `True`, the log message shows that **Using `split_batches=True` in `accelerator_config` will override the `per_device_train_batch_size` , Batches will be split across all processes equally when using `split_batches=True`.** My understanding is that when `split_batches=True`, the sample size on each GPU is `per_device_train_batch_size // n_gpu`, so the actual `batch_size`  is just `per_device_train_batch_size`, without multiplying by n_gpu, why  the calculation of `train_batch_size` property unrelated to split_batches, did I understand something wrongly? Thanks.

```python
    @property
    def train_batch_size(self) -> int:
        """
        The actual batch size for training.
        """
        train_batch_size = self.per_device_train_batch_size * max(1, self.n_gpu)
        return train_batch_size
```

```python
            if self.accelerator_config.split_batches:
                logger.info(
                    "Using `split_batches=True` in `accelerator_config` will override the `per_device_train_batch_size` "
                    "Batches will be split across all processes equally when using `split_batches=True`."
                )
```

Comments:
I looked at the `train_batch_size` property in `training_args.py` and confirmed there's no `split_batches` check. The same issue exists in `eval_batch_size`. The fix would be to check `self.accelerator_config.split_batches` and return `self.per_device_train_batch_size` directly when it's True. Happy to submit a PR, is this still open?

I've submitted a PR for this issue: https://github.com/huggingface/transformers/pulls?q=is%3Aopen+author%3AMinuriRajapakse

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.

> I looked at the `train_batch_size` property in `training_args.py` and confirmed there's no `split_batches` check. The same issue exists in `eval_batch_size`. The fix would be to check `self.accelerator_config.split_batches` and return `self.per_device_train_batch_size` directly when it's True. Happy to submit a PR, is this still open?

Hi, just a quick question — does this PR include both the fix for `train_batch_size` and the fix for `eval_batch_size`? Thanks!

Hi @manyifire! Yes, PR #45694 fixes both `train_batch_size` and `eval_batch_size`. The PR is open and ready for review and CI is passing except for one unrelated flaky test. Feel free to check it out!
CI Test PEFT integration CI
Author: BenjaminBossan
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46891)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46891)
<!-- ci-dashboard-badge:end -->

This is a PR to test if the PEFT integration CI works.

**DO NOT MERGE**

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

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46891)
**Latest run:** [28522235369:1](https://github.com/huggingface/transformers/actions/runs/28522235369)
**Result:** `failure` | **Jobs:** 15 | **Tests:** 58,189 | **Failures:** 64 | **Duration:** 18h 18m

<!-- ci-dashboard-recap:end -->

Closing in favor of clean PR #47021
[Bugfix] [Offloading] Save disk-offloaded buffers, Save converted weights
Author: kylesayrs
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46902)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46902)
<!-- ci-dashboard-badge:end -->

## Purpose ##
* Parlay two bugfixes in one for the purpose of enabling the saving of models with disk offloaded weights
  * Fix saving models which are disk offloaded with `offload_buffers=True`
  * Fix saving models which are disk offloaded with weight conversions

## Changes ##
* Replace `get_parameter` call with `get_parameter_or_buffer` call
* Expand `load_offloaded_parameter` to load a state dict of all weights associated with the checkpoint weight
  * checkpoint weight (all/any) -> model weight (one) -> reverted weights (all)
  * By using this loaded state dict to update the original state dict, we avoid redundant loading of offloaded weights
* Loosen requirements for `is_offloaded` flag
  * This is backwards compatible safe, as full disk offloaded was never supported in previous releases anyways

## Testing ##
Able to save disk-offloaded models with conversion mappings now

```python3
from transformers import AutoModelForCausalLM

# Load model with full disk offload
model = AutoModelForCausalLM.from_pretrained(
    "inference-optimization/DSV4-tiny-empty",
    device_map="auto",
    max_memory={},
    offload_folder="offload_folder",
)

# Save the model
model.save_pretrained("tmp_save")
```

Used these changes to quantize [RedHatAI/DeepSeek-V4-Pro-NVFP4-FP8](https://huggingface.co/RedHatAI/DeepSeek-V4-Pro-NVFP4-FP8) and [RedHatAI/GLM-5.2-NVFP4-FP8](https://huggingface.co/RedHatAI/GLM-5.2-NVFP4-FP8)

## Suggested Reviewers ##
* @SunMarc @zucchini-nlp @ArthurZucker

Comments:
<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46902)
**Latest run:** [28566046728:2](https://github.com/huggingface/transformers/actions/runs/28566046728)
**Result:** `failure` | **Jobs:** 14 | **Tests:** 72,772 | **Failures:** 1 | **Duration:** 16h 25m

<!-- ci-dashboard-recap:end -->

Hey @kylesayrs! I took the liberty to open https://github.com/huggingface/transformers/pull/47018 to fix the issue, I believe it is simpler and more robust in general!
Let me know if something is still unclear
Use standard arg names in Mllama
Author: zucchini-nlp
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=46977)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46977)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

as per title, this inconsistency is forcing us to completely override forward when copying attention with modular

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=46977)
**Latest run:** [28432436279](https://github.com/huggingface/transformers/actions/runs/28432436279)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

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

run-slow: mllama

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_46977). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
Building AI-Automated Vulnerability Discovery Systems - Lessons from Using Advanced LLMs
Author: Exploit-Garbage
Pull request: no

Hi Hugging Face team,

Transformers has been foundational to the AI revolution. I want to share how we're leveraging advanced language models for an unexpected application: **automated cybersecurity vulnerability discovery**.

**Project**: 0day Rubbish  
**Repository**: https://github.com/Exploit-Garbage/0day-Rubbish

**What we've built**:
An AI-powered system that uses multiple state-of-the-art LLMs (GPT-5.5, Claude Opus 4.8, DeepSeek V4) to:
- Analyze software architectures and identify potential vulnerability patterns
- Perform intelligent fuzzing guided by semantic understanding
- Generate and validate proof-of-concept exploits
- Produce comprehensive technical documentation automatically

**Key Insights on AI for Security**:
1. **Multi-Model Ensemble**: Combining different LLMs improves accuracy—each model has unique strengths in pattern recognition
2. **Semantic Code Analysis**: LLMs excel at understanding code intent and identifying logical flaws that traditional static analysis misses
3. **Automated Exploit Generation**: From vulnerability identification to working PoC, AI can handle the entire pipeline
4. **Real-World Validation**: AI-discovered vulnerabilities must be tested against actual deployments, not just theoretical analysis

**First Result**: Cisco CUCM RCE Chain (CVSS 9.8)
- Discovered entirely through AI automation
- 6-stage exploitation chain
- Fully working exploit with complete documentation

**Why this matters for the AI community**:
This demonstrates a novel, high-impact application of LLMs beyond traditional NLP tasks. It shows how AI can:
- Augment human expertise in specialized domains
- Scale security research beyond manual limitations
- Accelerate the identification and remediation of critical vulnerabilities

We're passionate about advancing the intersection of AI and cybersecurity. Would love to connect with others exploring similar applications of transformers in security contexts.

Learn more: https://github.com/Exploit-Garbage/0day-Rubbish

Best regards,
0day Rubbish Team

Comments:
ci: pin GitHub Actions to full commit SHAs
Author: XananasX7
Pull request: yes

## Summary

Pin all unpinned GitHub Actions to immutable full-length commit SHAs.

**Why:** Mutable tags (`@v3`, `@main`, etc.) can be silently redirected to malicious commits. SHA-pinning ensures the exact reviewed code runs in CI.

**Changes:** 1 reference(s) across 1 workflow file(s). Each retains its version tag as an inline comment.

**References:**
- [GitHub: Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
- [OpenSSF Scorecard: Pinned-Dependencies](https://securityscorecards.dev)

*Automated security hardening PR.*

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/28310319373) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.
ci: pin GitHub Actions to full commit SHAs
Author: XananasX7
Pull request: yes

## Summary

Pin all unpinned GitHub Actions to immutable full-length commit SHAs.

**Why:** Mutable tags (`@v3`, `@main`) can be silently redirected to malicious commits. SHA-pinning ensures reviewed code runs in CI — defense-in-depth against supply-chain attacks.

**Changes:** 1 reference(s) across 1 workflow file(s). Version tags retained as inline comments.

**References:**
- [GitHub: Security hardening for GitHub Actions](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
- [OpenSSF Scorecard: Pinned-Dependencies](https://securityscorecards.dev)

*Automated security hardening PR.*

Comments:
Thank you for your contribution 🤗!

## CI Security Gate — automatic approval blocked

This PR was **not** automatically approved for CI because the security gate failed.

**Possible reasons:**
- The PR touches 50 or more files — only PRs with fewer than 50 changed files are automatically approved
- A changed file is outside the allowed directories (`src/`, `tests/`, `docs/`, `utils/`), has a disallowed extension (only `.py`, `.txt`, `.md` permitted outside `tests/` and `docs/`), or is not `.md`/`.yml` inside `docs/`
- A new high-severity security issue was detected in the changed Python files (Bandit check)

See the [workflow run](https://github.com/huggingface/transformers/actions/runs/28310378854) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.
Fix off-by-one in sliding_window_mask_function right window boundary
Author: zaid646
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47010)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47010)
<!-- ci-dashboard-badge:end -->

Fixes #46305

**Bug:** `sliding_window_mask_function` uses strict less-than (`< right_window_size`) for the right context boundary, so `right_window_size=4` attends to only 3 future frames instead of 4. This is a 25% reduction in effective right-context.

According to the Moonshine v2 paper (arXiv:2602.12241): "a right window of w_right=4 implies an algorithmic lookahead of 4×20 ms = 80 ms". At 50 Hz, 4 frames = 80 ms, but the code gives 3 frames = 60 ms.

**Fix:** Change `< right_window_size` to `<= right_window_size`.

**Files changed:**
- `moonshine_streaming/modular_moonshine_streaming.py` (source)
- `moonshine_streaming/modeling_moonshine_streaming.py` (generated)
- `gemma4/modeling_gemma4.py` (standalone copy of the same function)

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

run-slow: gemma4, moonshine_streaming

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47010)
**Latest run:** [28539079285:2](https://github.com/huggingface/transformers/actions/runs/28539079285)
**Result:** `success` | **Jobs:** 1 | **Tests:** 2 | **Failures:** 0 | **Duration:** 24s

<!-- ci-dashboard-recap:end -->
Fix dtype casting for quantized Gemma4 vision/audio embedders
Author: zaid646
Pull request: yes
Labels: name: Code agent slop

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47008)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47008)
<!-- ci-dashboard-badge:end -->

Fixes #46932

Applies the same fix from PR #46904 (gemma4_unified) to the non-unified Gemma4 module. The existing code casts inputs to `layer.weight.dtype`, which returns `torch.uint8` for quantized `Linear4bit` layers, corrupting inputs. This fix uses `weight.dtype` only when it is a floating-point type.

**Changes:**
- `Gemma4VisionPatchEmbedder.forward()`: guard dtype cast with `is_floating_point` check
- `Gemma4AudioSubSampleConvProjectionLayer.forward()`: same guard

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

run-slow: gemma4

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47008)
**Latest run:** [28538876416:2](https://github.com/huggingface/transformers/actions/runs/28538876416)
**Result:** `success` | **Jobs:** 2 | **Tests:** 10 | **Failures:** 0 | **Duration:** 43s

<!-- ci-dashboard-recap:end -->
DeepSeek MLA: absorb low-rank up-projection into Q for eager/SDPA (V2/V3/V3.2)
Author: zaid646
Pull request: yes
Labels: name: Code agent slop

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47011)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47011)
<!-- ci-dashboard-badge:end -->

## Summary

The standard MLA forward materializes the full decompressed K and V tensors (e.g., `kv_lora_rank=512` -> `num_heads * (qk_nope_head_dim + v_head_dim)` = up to 32768) before calling the attention interface. This is wasteful for eager/SDPA: the `kv_b_proj` up-projection can be absorbed into the Q-nope and output projections, working entirely in the compressed `kv_lora_rank` space.

This PR applies the **absorbed attention** optimization to all three MLA model families:
- **DeepSeek-V2** (`modular_deepseek_v2.py`)
- **DeepSeek-V3** (`modular_deepseek_v3.py`)
- **DeepSeek-V3.2 (DSA)** (`modular_deepseek_v32.py`)

### How it works

Split `kv_b_proj.weight` into two sub-matrices:
- `W_uk` maps compressed k to the nope key-subspace
- `W_uv` maps compressed k to the value subspace

**Forward:**
absorbed_q = q_nope @ W_uk^T
scores = absorbed_q @ compressed_k^T + RoPE scores
output = softmax(scores) @ compressed_k @ W_uv^T

Full K/V is **only** materialized when a KV-cache update is required. Flash-attention and decode steps with pre-existing caches keep the original expanded path.

### Testing

- Unit tests verify the absorbed path matches the standard expansion to 1e-5 for V2, V3, and V3.2
- Full model forward (no MoE, eager mode) produces valid logits with no NaN
- Cache path tested: prefill (absorbed) + decode (standard) round-trip matches no-cache baseline exactly
- Flash-attention and decode-with-cache paths are unchanged (fall through to the original expansion)

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

run-slow: deepseek_v2, deepseek_v3, deepseek_v32

<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47011)
**Latest run:** [28571225644:2](https://github.com/huggingface/transformers/actions/runs/28571262895)
**Result:** `failure` | **Jobs:** 1 | **Tests:** 1 | **Failures:** 0 | **Duration:** 2s

> **Code quality check failed**: test jobs were skipped. Fix the code quality issues and push again to run tests.

<!-- ci-dashboard-recap:end -->

@huggingface/transformers-maintainers both `Check repository consistency` and `Check code quality` keep failing with a self-hosted runner infrastructure error:

> Executing the custom container implementation failed. Please contact your self hosted runner administrator.

This isn't a code issue — the runner itself can't execute custom containers. Could someone re-trigger CI or check the runner setup? First commit was bd242ac, empty commit 42507cd also failed the same way. Thanks!
CI Add PEFT integration tests
Author: BenjaminBossan
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47021)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47021)
<!-- ci-dashboard-badge:end -->

Follow up to #46891 to create a clean PR.

# What does this PR do?

Add PEFT integration tests to test fetcher, extend unit test. See https://github.com/huggingface/transformers-test-ci/pull/74 for more context.

Comments:
<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47021)
**Latest run:** [28580556635](https://github.com/huggingface/transformers/actions/runs/28580556635)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_47021). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.
TST Skip PEFT tests if PEFT version is too low
Author: BenjaminBossan
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47027)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47027)
<!-- ci-dashboard-badge:end -->

# What does this PR do?

Two PEFT tests fail with the current PEFT release v0.19 but the failure is already fixed on main. Therefore, skip those tests unless v0.20+ is found, which is the next PEFT release.

Fixes https://github.com/huggingface/transformers/actions/runs/28604971769/job/84823334564?pr=46960#step:17:575

## Code Agent Policy

- [x] I confirm that this is not a pure code agent PR.

Comments:
<!-- ci-dashboard-recap:start -->

---

### CI recap

**Dashboard:** [View test results in Grafana](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47027)
**Latest run:** [28607230334](https://github.com/huggingface/transformers/actions/runs/28607230334)
**Result:** `success` | Grafana metrics are not available yet.

<!-- ci-dashboard-recap:end -->

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