noamaanMulla-03/transformers-issues huggingface dataset:
[Offloading] [Bugfix] Fix fully offloaded model saving
Author: kylesayrs
Pull request: yes

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47336)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47336)
<!-- ci-dashboard-badge:end -->

## Purpose ##
* Fix full model saving for fully-disk-offloaded models

## Changes ##
* Apply suggestions from https://github.com/huggingface/transformers/pull/47018

## Testing ##
* Fixes #47333

## Suggested Reviewers ##
* @Cyrilvallez @SunMarc 

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=47336)
**Latest run:** [29396754706:2](https://github.com/huggingface/transformers/actions/runs/29396778708)
**Result:** `failure` | **Jobs:** 1 | **Tests:** 6 | **Failures:** 0 | **Duration:** 11s

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

looks good
Add Cosmos3 Edge model support
Author: atharvajoshi10
Pull request: yes
Labels: name: New model

<!-- ci-dashboard-badge:start -->
[![CI](https://transformers-ci.lor-e.huggingface.cool/badge/pr?pr=47181)](https://transformers-ci.lor-e.huggingface.cool/d/pytest-observability-by-pr/pytest-observability-branch?var-pr=47181)
<!-- ci-dashboard-badge:end -->

## What does this PR do?
This PR adds a support for Cosmos3 Reasoner model (not released yet).

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

Can we also merge with main / resolve the conflicts please

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

run-slow: auto, cosmos3_edge

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/29522715941) for the exact violations.

A maintainer can review and manually approve CI if a finding is a false positive.

run-slow: cosmos3_edge

[Workflow Run ⚙️](https://github.com/huggingface/transformers/actions/runs/29523120158)

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

models: ["models/cosmos3_edge"]
quantizations: []

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

### Commit Info
| Context | Commit | Description |
|---------|--------|-------------|
| RUN | [d68e69f1](https://github.com/huggingface/transformers/commit/d68e69f17f39b4ead5a47c92195d96ecc66c9a35) | workflow commit (merge commit) |
| PR | [02ee54c2](https://github.com/atharvajoshi10/transformers/commit/02ee54c2da9679a4ca08ce3bd298702e59727f1d) | branch commit (from PR) |
| main | [d9cb3939](https://github.com/huggingface/transformers/commit/d9cb3939ae0afa867de1f3102e7e3014c2502308) | base commit (on `main`) |

✅ No failing test specific to this PR 🎉 👏 !


<!-- 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=47181)
**Latest run:** [29522716882:2](https://github.com/huggingface/transformers/actions/runs/29522716882)
**Result:** `success` | **Jobs:** 15 | **Tests:** 172,160 | **Failures:** 0 | **Duration:** 14h 36m

<!-- ci-dashboard-recap:end -->
Fix Cosmos 3 Edge Patch packing order
Author: atharvajoshi10
Pull request: yes

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

Fix patch packing order

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

run-slow: cosmos3_edge

<!-- 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=47399)
**Latest run:** [29655331441:2](https://github.com/huggingface/transformers/actions/runs/29655331441)
**Result:** `success` | **Jobs:** 3 | **Tests:** 107 | **Failures:** 0 | **Duration:** 2m 25s

<!-- ci-dashboard-recap:end -->
Add GGUF loading support for Phi-2 (#33260)
Author: vibhorxpandey
Pull request: yes

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

## What this does

Adds Phi-2 to the architectures supported by GGUF checkpoint loading, following the
protocol in #31175. Addresses a checklist item in #33260 (claimed
[here](https://github.com/huggingface/transformers/issues/33260#issuecomment-5012418261)).

- Map the `phi2` config keys and register the GPT-2 BPE tokenizer converter
  (`integrations/ggml.py`)
- Add `PhiTensorProcessor` to split the fused `attn_qkv` projection into separate
  `q_proj` / `k_proj` / `v_proj` (weight and bias), since transformers' Phi uses
  separate projections
- Remap `phi` -> `phi2` for the gguf-py tensor name map, rename the loaded
  `model_type` `phi2` -> `phi`, and derive `partial_rotary_factor` from
  `rope.dimension_count` (Phi-2 uses partial rotary embeddings)
- Add a Phi-2 integration test and list Phi2 in the GGUF docs

## Testing

```
RUN_SLOW=1 pytest tests/quantization/ggml/test_ggml.py -k test_phi2
```

Verified locally on CPU with `TheBloke/phi-2-GGUF` (`phi-2.Q2_K.gguf`): the checkpoint
loads as `PhiForCausalLM` with `partial_rotary_factor=0.4`, the split q/k/v projections
have the expected shapes, and greedy decoding produces coherent text. The test's
`EXPECTED_TEXT` was generated on CPU (fp32) — please confirm it on a CUDA runner and let
me know if it needs adjusting.

## AI assistance

This change was written with AI assistance (Claude Code) and reviewed line-by-line by me.

cc @SunMarc @LysandreJik @ArthurZucker

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

run-slow: ggml

<!-- 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=47400)
**Latest run:** [29656238678:2](https://github.com/huggingface/transformers/actions/runs/29656238678)
**Result:** `success` | **Jobs:** 15 | **Tests:** 170,936 | **Failures:** 0 | **Duration:** 14h 34m

<!-- ci-dashboard-recap:end -->
[i18n-<languageCode>] Translating docs to <languageName>
Author: diplrcdi-cmd
Pull request: no
Labels: name: WIP

Duplicate of #33260 <!--
Note: Please search to see if an issue already exists for the language you are trying to translate.
-->

Hi!

Let's bring the documentation to all the <languageName>-speaking community 🌐 (currently 0 out of 267 complete)

Who would want to translate? Please follow the 🤗 [TRANSLATING guide](https://github.com/huggingface/transformers/blob/main/docs/TRANSLATING.md). Here is a list of the files ready for translation. Let us know in this issue if you'd like to translate any, and we'll add your name to the list.

Some notes:

* Please translate using an informal tone (imagine you are talking with a friend about transformers 🤗).
* Please translate in a gender-neutral way.
* Add your translations to the folder called `<languageCode>` inside the [source folder](https://github.com/huggingface/transformers/tree/main/docs/source).
* Register your translation in `<languageCode>/_toctree.yml`; please follow the order of the [English version](https://github.com/huggingface/transformers/blob/main/docs/source/en/_toctree.yml).
* Once you're finished, open a pull request and tag this issue by including #issue-number in the description, where issue-number is the number of this issue. Please ping @stevhliu for review.
* 🙋 If you'd like others to help you with the translation, you can also post in the 🤗 [forums](https://discuss.huggingface.co/).

## Get Started section

- [ ] [index.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/index.md) https://github.com/huggingface/transformers/pull/20180
- [ ] [quicktour.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/quicktour.md) (waiting for initial PR to go through)
- [ ] [installation.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/installation.md).

## Tutorial section
- [ ] [pipeline_tutorial.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/pipeline_tutorial.md)
- [ ]  [autoclass_tutorial.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/autoclass_tutorial.md)
- [ ]  [preprocessing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/preprocessing.md)
- [ ]  [training.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/training.md)
- [ ]  [accelerate.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/accelerate.md)
- [ ]  [model_sharing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_sharing.md)
- [ ]  [multilingual.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/multilingual.md)

<!--
Keep on adding more as you go 🔥
-->


Comments:
device_map loading OOMs on conversion-op transients: WeightConverter contiguous() runs on destination GPU, unbudgeted by max_memory packing
Author: SelfSL
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.14.1
- Platform: Linux-6.17.0-1007-aws-x86_64-with-glibc2.39
- Python version: 3.12.3
- Huggingface_hub version: 1.24.0
- Safetensors version: 0.8.0
- Accelerate version: 1.14.0
- Accelerate config: not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.12.0a0+git220ecc2 (CUDA)
- Using distributed or parallel set-up in script?: No (single process; accelerate device_map="auto" across 8 GPUs)
- Using GPU in script?: Yes
- GPU type: NVIDIA B300 SXM6 AC (x8, 268.59 GB each)
Supplementary: transformers 5.14.1; torch 2.12.0a0 cu12.9; 8x NVIDIA B300 (268.59 GB); model: Inkling-975B (bf16, converted checkpoint with WeightConverter ops).

### Who can help?

@CyrilVallez (model loading) @SunMarc (Big Model Inference / device_map)

### Information

- [ ] The official example scripts
- [x] 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

Mechanism: for checkpoints with registered conversion ops (`WeightConverter` + `Interleave`/`Chunk`), the op chain (incl. `.contiguous()`) executes on the tensor's **destination GPU** during load (`core_model_loading.py`, v5.14.x). For a large converted tensor this is a ~2x transient (source view + contiguous output). `max_memory` packing budgets only the resident parameter bytes, so when a GPU is packed near its cap, the **last large converted tensor assigned to it OOMs** even though the final resident model fits.
 
Observed (Inkling 975B, `device_map="auto"`, `max_memory={i:"240GiB"}`): fused-expert tensors (`gate_up_proj`, [256, 6144, 6144] bf16 ≈ 18 GiB; ~36 GiB transient with conversion) OOM reproducibly at the last MoE layer packed onto each GPU — failing layers {18, 27, 36, 45, 54, 63}, i.e. one per device boundary. Trimmed traceback:
```
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 18.00 GiB (GPU 2; ...)
  File ".../transformers/core_model_loading.py", line 202, in convert
    tensor = op(tensor).contiguous()
```
Workaround that confirms the accounting gap: lowering `max_memory` headroom by ~1x-largest-converted-tensor per GPU loads cleanly (wasting that memory at steady state).

### Expected behavior

`device_map` packing should account for conversion-op transients, e.g.: (a) subtract the largest per-device converted-tensor transient from each device budget during packing; or (b) execute conversion ops on CPU (or the source buffer) above a size threshold and move the converted result; or (c) document that converted checkpoints require ~largest-tensor headroom. Happy to provide full logs or test a patch.

Comments:
Silent conversion skip on model_type mismatch: loading a converted checkpoint via the wrong Auto class yields randomly-initialized weights that generate fluently
Author: SelfSL
Pull request: no
Labels: name: bug

### System Info

- `transformers` version: 5.14.1
- Platform: Linux-6.17.0-1007-aws-x86_64-with-glibc2.39
- Python version: 3.12.3
- Huggingface_hub version: 1.24.0
- Safetensors version: 0.8.0
- Accelerate version: 1.14.0
- Accelerate config: not found
- DeepSpeed version: not installed
- PyTorch version (accelerator?): 2.12.0a0+git220ecc2 (CUDA)
- Using distributed or parallel set-up in script?: No (single process; reproduces with device_map="auto" or single GPU)
- Using GPU in script?: Yes
- GPU type: NVIDIA B300 SXM6 AC
Supplementary: transformers 5.14.1; torch 2.12.0a0 cu12.9; model: Inkling-975B (multimodal, `model_type: inkling_mm_model`, converted checkpoint).


### Who can help?

@CyrilVallez (model loading / conversion mapping) @zucchini-nlp (multimodal)
 


### Information

- [ ] The official example scripts
- [x] 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

Checkpoint conversion mappings are resolved by the **loaded class's** expectations; when a user loads a converted checkpoint through a class whose naming doesn't match (e.g. `AutoModelForCausalLM` on a checkpoint whose weights live under the multimodal layout), no conversion table applies and every checkpoint tensor fails to match:
 
```python
from transformers import AutoModelForCausalLM
m = AutoModelForCausalLM.from_pretrained(PATH_TO_INKLING, dtype="bfloat16")  # multimodal ckpt
out = m.generate(**tok("The capital of France is", return_tensors="pt"), max_new_tokens=8)
# -> fluent but random text ("empatan ..."); no error raised
```
Symptoms in the log: "load" completes in seconds for a 1.9 TB checkpoint; conversion progress shows `0it`; the only signals are symmetric MISSING/UNEXPECTED key warnings (easily lost in noise) — then the model **generates fluent garbage** from random init. Cost of the failure mode: it looks like a working model with bad weights, sending users into weight-level debugging instead of a one-line class fix.

### Expected behavior

Hard error (or at minimum a prominent warning) when: the checkpoint's `config.model_type` has a registered conversion mapping, AND the resolved class matches ~0% of checkpoint tensors. "You loaded a `<model_type>` checkpoint via `<class>`; its weights require the `<other class>` conversion mapping" would turn hours of debugging into seconds. Secondary question: is the absence of a text-only `AutoModelForCausalLM` load path for this checkpoint layout an intentional policy or an omission?

Comments:
Add LoMa keypoint detector & matcher
Author: tcourat
Pull request: no
Labels: name: New model

### Model description

LoMa revisits local (sparse) feature matching from a data-driven perspective. In particular, the authors focus on (i) curating a large and diverse training data mixture together with scalable training recipes for both descriptors and matchers, and (ii) increasing training compute along two axes: data scale (the number and diversity of image pairs) and model capacity (the number of parameters).

LoMa outperforms previous sparse feature matcher and is even competitive with top semi-dense or dense matchers.

There are also rotation-invariant variants, LoMa RotMatch and LoMa RotDesc&Match.

### Open source status

- [x] The model implementation is available
- [x] The model weights are available

### Provide useful links for the implementation

Papers : https://arxiv.org/abs/2604.04931
https://arxiv.org/abs/2604.11809 (rotation invariant)

Code : https://github.com/davnords/LoMa



Comments:
@tcourat  hope you are well. I am intrested  to take on this feature to add new model.. Hope you will give chance to contribute to this feature.

> [@tcourat](https://github.com/tcourat) hope you are well. I am intrested to take on this feature to add new model.. Hope you will give chance to contribute to this feature.

Feel free to start working on it !

@tcourat  can I contribute to this feature ?


Hi everyone, I would love to take this on and add LoMa to `transformers`! 

I'll get started on the conversion script and modeling files, using the existing `LightGlue` implementation as a reference. 

@zucchini-nlp @Cyrilvallez @Rocketknight1 - could you please assign this issue to me? 

Thanks!

cc @guarin @molbap 

Hi maintainers (@zucchini-nlp, @guarin, @molbap),

I'd appreciate some guidance on the intended initial scope for this integration before I proceed further with the implementation.

I propose supporting LoMa with SuperPoint first. My reasoning is that DaD, DeDoDe-v2, DISK, and ALIKED are not currently native `transformers` models, and relying on remote detector code (as older implementations did) is no longer the preferred pattern in the library. SuperPoint is already well-supported and provides a solid, native baseline.

Additionally, regarding the descriptor network: Would maintainers prefer the new DeDoDe-style descriptor network to be implemented as a reusable, standalone component (paving the way for a future, dedicated DeDoDe integration), or should it be kept local/encapsulated within the LoMa implementation for now?

Happy to adjust the architecture based on your feedback before writing the full modeling code!
[serge] integration failure triage - 2026-07-17
Author: github-actions[bot]
Pull request: no

<!-- serge-triage-run:integration-failure-triage:2026-07-17 -->

Automated **integration-failure triage** for the daily CI window `2026-07-09 → 2026-07-17`.

This issue was generated by AI-assisted automation. The grouping, summaries, and recommended follow-up can be incomplete or misleading; verify the failures before acting.

Serge dispatched one task per failure group below — each opens or updates its own PR on a `serge/fix/itf-<fingerprint>` branch. This table is refreshed in place as Serge runs: a group links its `#<pr>` when opened, shows `🚫 no fix` when Serge found no safe change, `⚠️ task failed` on error, or `(pending)` while still running (a late PR links on the next nightly run).

## Dispatched failure groups

| Model | Error | Occurrences | PR |
| --- | --- | --- | --- |
| `musicgen_melody` | output_mismatch — tensor values differ (16) | 16 | 🚫 no fix |
| `whisper` | other — other (13), shape/size mismatch (1) | 14 | 🚫 no fix |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | #47281 |
| `hunyuan_vl` | other — other (12) | 12 | 🚫 no fix |
| `minimax_m3_vl` | other — other (12) | 12 | 🚫 no fix |
| `diffusion_gemma` | output_mismatch — tensor values differ (6), list output differs (4) | 10 | 🚫 no fix |
| `glm_ocr` | output_mismatch — list output differs (10) | 10 | 🚫 no fix |
| `deepseek_v32` | other — other (8) | 8 | 🚫 no fix |
| `higgs_audio_v2` | other — tensor values differ (8) | 8 | 🚫 no fix |
| `mamba2` | OOM — other (8) | 8 | 🚫 no fix |
| `mllama` | other — other (8) | 8 | 🚫 no fix |
| `mpt` | load_error — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | 🚫 no fix |
| `recurrent_gemma` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `vision_encoder_decoder` | other — other (8) | 8 | 🚫 no fix |
| `voxtral` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `gemma` | output_mismatch — list output differs (7) | 7 | 🚫 no fix |
| `whisper` | output_mismatch — list output differs (5), tensor values differ (2) | 7 | 🚫 no fix |
| `bridgetower` | other — other (6) | 6 | 🚫 no fix |

_Generated 2026-07-18T02:21:04+00:00._

Comments:
Superseded by #47406 — closing this stale nightly integration-failure triage issue. Open PRs stay linked from the current issue.
[serge] integration failure triage - 2026-07-18
Author: github-actions[bot]
Pull request: no

<!-- serge-triage-run:integration-failure-triage:2026-07-18 -->

Automated **integration-failure triage** for the daily CI window `2026-07-10 → 2026-07-18`.

This issue was generated by AI-assisted automation. The grouping, summaries, and recommended follow-up can be incomplete or misleading; verify the failures before acting.

Serge dispatched one task per failure group below — each opens or updates its own PR on a `serge/fix/itf-<fingerprint>` branch. This table is refreshed in place as Serge runs: a group links its `#<pr>` when opened, shows `🚫 no fix` when Serge found no safe change, `⚠️ task failed` on error, or `(pending)` while still running (a late PR links on the next nightly run).

## Dispatched failure groups

| Model | Error | Occurrences | PR |
| --- | --- | --- | --- |
| `musicgen_melody` | output_mismatch — tensor values differ (16) | 16 | 🚫 no fix |
| `whisper` | other — other (13), shape/size mismatch (1) | 14 | 🚫 no fix |
| `edgetam` | import_or_config — other (12) | 12 | #47122 |
| `glm46v` | other — other (12) | 12 | #47281 |
| `minimax_m3_vl` | other — other (12) | 12 | 🚫 no fix |
| `diffusion_gemma` | output_mismatch — tensor values differ (6), list output differs (4) | 10 | 🚫 no fix |
| `glm_ocr` | output_mismatch — list output differs (10) | 10 | 🚫 no fix |
| `deepseek_v32` | other — other (8) | 8 | 🚫 no fix |
| `higgs_audio_v2` | other — tensor values differ (8) | 8 | 🚫 no fix |
| `hunyuan_vl` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `mamba2` | OOM — other (8) | 8 | 🚫 no fix |
| `mllama` | other — other (8) | 8 | 🚫 no fix |
| `moshi` | other — other (8) | 8 | 🚫 no fix |
| `mpt` | load_error — other (8) | 8 | 🚫 no fix |
| `peft_integration` | other — other (8) | 8 | 🚫 no fix |
| `recurrent_gemma` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `vision_encoder_decoder` | other — other (8) | 8 | 🚫 no fix |
| `voxtral` | output_mismatch — list output differs (8) | 8 | 🚫 no fix |
| `gemma` | output_mismatch — list output differs (7) | 7 | 🚫 no fix |
| `whisper` | output_mismatch — list output differs (5), tensor values differ (2) | 7 | 🚫 no fix |

_Generated 2026-07-19T01:45:52+00:00._

Comments: