Issue 44704 has a specific API path (`AutoProcessor.from_pretrained` → `cached_file`) and a clear failure mode, making it the cleanest representative among otherwise unrelated reports.

Issue 44704 is the most concrete, narrowly scoped bug report in the set and best serves as a representative issue, but the cluster is too heterogeneous to justify a strong canonical duplicate choice.

Both involve loading failures, but one is Sentence Transformers loading and the other is a MacOS bus error with a CLIP model; different symptom and likely different root cause.

Dequantized model saving and pipeline-parallel generation output errors are unrelated code paths and not the same underlying bug.

TF32 configuration guidance and a `torch.split()` return issue in `GlmMoeDsaIndexer` are distinct concerns with no clear shared defect.

Both touch processor/chat-template behavior, but one is missing kwargs in `from_pretrained` while the other crashes on assistant tool-call messages; different failure modes.

Tokenizer offset changes across versions and a batched `apply_chat_template` crash are different bugs in different layers.

Generation kwargs handling after `sync_gpus` is unrelated to a categorical cardinality runtime error.

Python version compatibility and incorrect pipeline-parallel LLM output are not the same underlying issue.

Both involve generation/cache mechanics, but one is about post-`sync_gpus` kwargs propagation and the other about recurrent state resets in a specific model file; too different to merge.

Wrong `offset_mapping` for Qwen3 tokenizer and failure to load `cjvt/sleng-bert` are separate problems.

Saving dequantized models and invalid `GenerationConfig` for GLM-5 are unrelated bugs, even if both mention GLM-family models.

Summary: This cluster is mostly a set of unrelated Transformers bug reports that only share broad subsystem vocabulary (tokenizers, generation, processors, loading, GLM/Qwen models). None of the soft pairs look like true duplicates or mergeable PR-equivalents from the titles alone.


No single issue is a good global representative because the reports do not share one underlying failure mode.

No clear canonical issue: the set is heterogeneous, spanning distinct model-specific bugs, tokenizer regressions, and API/import problems.

Different problems: one is label propagation into text config, the other is training collapse with flash_attention_3.

Different code paths and symptoms: example script multi-label output vs Gemma 4 multimodal token type defaults.

Both are import-related, but one is a specific AutoImageProcessor import failure and the other is a broader upgrade-related import breakage.

Unrelated: missing embed_tokens.weight during UMT5 loading vs AutoProcessor not forwarding kwargs to cached_file.

Same SAM3 area, but distinct bugs: wrong model class warning vs missing fpn_position_embeddings attribute.

Different topics entirely: DSA indexer activation issue vs GLM-5 RoPE implementation discussion.

Both mention tokenizer regressions, but one is a general version-to-version tokenization change and the other is Deepseek-specific incorrect output.

No shared bug: LayoutLMv3 box validation messaging vs Sentence Transformers loading hang.

Different failure modes: position_ids buffer access error vs tokenizer_class mismatch in saved config.

Summary: These issues are mostly unrelated single-bug reports across different models and utilities; no duplicate cluster emerges from the titles/descriptions alone.


Both touch tokenizer/chat-template surfaces, but one is Qwen3 offset_mapping and the other is multimodal assistant_masks; different failure modes and likely different fixes.

Missing config.rms_norm_eps causing precision drift is unrelated to a wrong position_ids docstring; one is a runtime bug, the other is documentation.

AutoImageProcessor import failure and a transformers>=5.1.0 model-loading failure are different APIs and different code paths.

torch.compile/SDPA failure for Bamba-9B-v2 is unrelated to reading position_ids after buffer registration; different subsystems.

TF32 API settings guidance and FineGrainedFP8 accuracy problems are about different features and distinct bugs.

Saving dequantized Ministrals/Devstrals and gguf_file breaking from_pretrained are both save/load related, but they involve different models and different failure points.

Tensor parallel training bug and empty multi-label classification example output are not the same underlying issue.

Custom token IDs being lost on save/load is unrelated to position_ids buffer access errors.

Qwen3-VL-Moe / transformers 5.0 compatibility and tokenizer_class mismatch on save_pretrained are distinct bugs; shared serialization context is too broad.

Both mention moe-related models, but one is a transformers 5.0 compatibility issue and the other is an FP8 save_pretrained bug; not the same code-path problem.

Summary: This cluster is heterogeneous: the items are mostly unrelated issue reports across tokenization, multimodal chat templating, save/load, precision/config, and training/runtime bugs. None of the soft pairs look like true duplicates, so no edge is accepted.


Both are import failures, but they involve different missing symbols in different code paths: Qwen2.5-VL class export vs HybridCache export. Not the same underlying bug.

One is a dtype mismatch on embeddings between train/eval, the other is incorrect LLM output under pipeline parallelism. Related to model execution, but not the same defect.

Tokenization differences across versions and flash-attention generation failure are distinct problems with different subsystems and failure modes.

Both mention quantization/save_pretrained, but one is dequantized Ministral/Devstral saving and the other is FP8 MOE save_pretrained. Different model/setup and likely different code paths.

VitPose import breakage and Ministral flash-attention failure are unrelated model-specific bugs.

Saving dequantized weights and MXFP4 loading falling back to bf16 are both quantization-related, but they are different behaviors and not the same bug.

Sentence-transformers import breaking with latest transformers and an AuxRequest version-check bug in flex_attention are different import-time issues in different modules.

Both are import-related, but one is a missing nn symbol during sentence-transformers import and the other is a non-existent image_utils import. Not the same issue.

FSDP2/PEFT optimizer-state corruption and missing GenerationMixin cache during chunked prefill affect different subsystems and code paths.

Both are version-related import errors, but one is a specific missing layer_type_validation symbol and the other is a broad upgrade report with many import failures. Too generic to treat as the same bug.

Summary: These issues are mostly unrelated regressions spanning imports, model loading, quantization, training, and generation behavior. Several share broad themes like "import errors" or "save/load problems," but none look like the same concrete bug or fix target.


No global best issue stands out as a representative duplicate target; the set is too heterogeneous to safely collapse around one issue.

No single issue is canonical here because the items are not duplicates of one another; they span distinct bug reports and subsystems.

Different failures: VRAM leakage in multi-dataloader use vs bfloat16 dtype mismatch in inference.

Both mention GLM-5, but one is GenerationConfig validation and the other is RoPE implementation; different concrete bugs.

Optimizer SGD arguments being ignored is unrelated to trainer.evaluate() failing after training.

Example-script multi-label empty outputs and SigLIP2 HF/JAX discrepancy are different models and different code paths.

Import failure for transformers.onnx is unrelated to a LayoutLMv3 error-message clarity issue.

TF32 API behavior and a missing image-processor method are unrelated problems.

Multi-label example output bug does not match a pipeline translation-task error message regression.

Both are tokenizer bugs, but they affect different models and symptoms: offset_mapping vs incorrect tokenization results.

These are separate version-check bugs in different areas: Python support vs PyTorch import gating.

Tokenizer loading regression and Qwen3 offset_mapping corruption are not the same underlying defect.

Summary: No soft-edge pair looks like the same underlying bug or change; the cluster is a mix of unrelated issues across tokenizers, model implementations, training, version checks, and error messaging.


If one issue had to be kept as the most concrete standalone report, issue 43931 is the strongest bug-style writeup, but it is not representative of the whole cluster as a duplicate target.

No clear canonical issue: the items span unrelated bugs, regressions, docs, and version-check problems, so collapsing them into one issue would be incorrect.

Both mention Qwen3/model loading, but one is a weight-shape mismatch in Qwen3-VL and the other is incorrect output under pipeline parallelism; different code paths and symptoms.

Different models and failures: GLM-5 invalid GenerationConfig versus Qwen3.5 flash-attention generation issues.

Unrelated areas: qwen3_omni_moe feature-extraction helper behavior versus flex_attention PyTorch version checking.

One is a question about the 50GB save_pretrained shard limit; the other is a Qwen3.5 MoE from_pretrained regression.

Both are model-loading/runtime complaints, but one is a VRAM leak in multithreaded dataloaders and the other is a separate reproduction of issue 38071.

Docs still referencing pipeline() and an AuxRequest/flex_attention version check bug are unrelated.

Both are tokenizer-related, but one is wrong offset_mapping for Qwen3 and the other is runtime post-processor updates when special tokens change.

Different video-processing failures: batched shape handling versus AutoProcessor crashing without torchvision.

Both involve compatibility/type-checking regressions, but they are distinct failures: init_empty_weights argument handling versus PretrainedConfig type checking.

Package version pinning for PEFT is unrelated to the PyTorch version check in flex_attention.

Summary: This cluster is heterogeneous and does not look like a true duplicate set. The soft pairs mostly share broad subsystem keywords (tokenizers, Qwen3, video, version checks) but describe different bugs, models, or product areas.


If one issue must be chosen, 45216 is the most concrete and self-contained regression report, and it has a nearby follow-up in 45310, but it only represents a narrow slice of this mixed cluster.

No single canonical issue fits well because the cluster does not center on one bug; the items are mostly unrelated transformer regressions across different subsystems.

Both are import failures, but they concern different missing symbols and likely different breakages.

VRAM leakage in multi-threaded Qwen3ForCausalLM use is unrelated to Blip2 dtype loading behavior.

Tokenizer mapping None handling and a Mistral regex patch crash are different code paths and failure modes.

Flash-attention training degeneration is unrelated to a Qwen3.5 save_pretrained checkpoint regression.

A Qwen3 VRAM leak and an Apple Silicon caching_allocator_warmup TypeError are distinct bugs.

Missing qwen3next projections and Qwen3.5 from_pretrained errors are different model/loader issues.

An import error for configuration_utils and a feature-extraction helper issue do not match the same underlying defect.

TF32 API guidance and MLA layernorm epsilon precision are unrelated concerns.

AutoImageProcessor import failure and sentence-transformers nn NameError are separate import-time regressions.

A sam3_video vs sam3_tracker config warning and a MobileLLM key error are different model-loading problems.

Summary: This cluster is highly heterogeneous: the issues span unrelated import errors, model-loading regressions, dtype propagation, backend-specific crashes, and tokenizer/model architecture bugs. No soft-edge pair looks like the same underlying defect or change, so none should be merged as duplicates.


45278 is the best single issue to anchor the cluster because it has the widest symptom surface and is the clearest umbrella-style regression report among mostly unrelated issues.

Issue 45278 is the broadest and most representative open report here: it describes a version-upgrade-related wave of import failures after moving from 4.57.0 to 5.5.0.

Different problems: packaging/backend dependency omission vs broken vitpose models; no shared concrete code path.

Both are model-load failures, but one is a GenerationConfig validation error for GLM-5 and the other is an unrecognized-model/config issue for OLMo; distinct root causes.

Both mention chat/completions, but one is a general request-acceptance regression and the other is a Qwen3.5 streaming-inference failure; not enough evidence they are the same bug.

A specific missing import from image_utils is not the same as a broad post-upgrade import-error report.

3d_parallel.py runtime failure and a testing_utils bug are unrelated.

Tokenizer decoder-type mismatch and tokenization-output differences are related to tokenizers but do not look like the same concrete defect.

Phi-4 multimodal model loading failure is a model-specific issue, not the same as generic import errors after upgrade.

GenerationMixin chunked_prefill cache behavior and testing_utils are different subsystems and symptoms.

Removal of tie_embeddings_and_encoder_decoder and unexpected position-id keys are different regressions with different failure modes.

Broken vitpose models and protobuf-masked tokenizer errors are unrelated.

Summary: This cluster is noisy and mostly contains distinct Transformers v5 regressions across unrelated areas (packaging, model loading, tokenization, generation, API handling, and tests). I did not find a convincing duplicate pair; the best anchor is the broad import-regression report.


issue:43452 is the clearest standalone bug report here, with a concrete failing from_pretrained code path and broad user impact.

Different bugs: one is a crash loading video models via AutoProcessor without torchvision; the other is about max_shard_size in save_pretrained.

Both mention GLM, but the failures are unrelated: missing image-patch method vs a config.rms_norm_eps precision issue in MLA q_a_layernorm.

Both involve flash attention, but they affect different code paths and symptoms: Ministral-3 inference failure vs degenerate training in sequence classification.

These are different warnings with different causes: bf16 compilation precision warning vs sam3_video/sam3_tracker model-type mismatch.

vitpose model breakage and quantized model saving failure are unrelated issues in different areas.

Different GLM bugs: torch.split return values in a MoE indexer versus the RoPE implementation.

Importing AutoImageProcessor and breaking PretrainedConfig type checking are separate regressions with different failure modes.

modeling_utils sys.modules access and a testing_utils bug are different files, different behavior, and not the same defect.

One is removal of tie_embeddings_and_encoder_decoder; the other is gguf_file breaking tokenizer/model loading. Different underlying problems.

Summary: The set is heterogeneous: the soft-similarity pairs are only topically related and do not look like the same underlying bug or change. I would not merge any of the proposed duplicates.


Both mention loading failures, but one is a tokenizer-mapping None bug and the other is a transformers>=5.1.0 model load failure for a specific repo; different code paths and failure modes.

Both involve Qwen/VL-style model loading, but one is a weight-shape mismatch while the other is missing projections in qwen3next layer 0; not the same bug.

43986 is a video/AutoProcessor torchvision dependency crash; 45341 is a small testing_utils bug. No substantive overlap in bug source or fix.

GLM46V image-processor AttributeError and GlmMoeDsaIndexer torch.split return handling are unrelated components and defects.

These are different warnings in different models: sam3 tracker/type mismatch versus Qwen3.5 tie_word_embeddings warning.

SwitchTransformers sparse-layer creation and PretrainedConfig type checking are unrelated issues with no shared code path.

Both are Qwen3-VL related, but one is a loading shape mismatch and the other is a transformers 5.0 bug with Qwen3-VL-Moe; distinct failures.

Video-model AutoProcessor/torchvision crash and Gemma 4 processor import error come from different dependency paths and model families.

Flash-attention-3 degenerate training and category-cardinality RuntimeError are completely different problems.

Trainer/FSDP2/PEFT optimizer-state corruption and Liger Kernel not applied with model_init are separate training-stack issues, not one concrete bug.

Summary: The soft-edge candidates span different subsystems and root causes, so none look like true duplicates or mergeable PR-equivalents. This cluster is better treated as a set of unrelated issues rather than one underlying bug/change.


Both mention release/version compatibility, but one is a Python support regression and the other is a PretrainedConfig type-checking break; different failure modes and code paths.

Compiled-forward generation inconsistency is unrelated to config type checking; no shared bug mechanism or fix scope.

Qwen3-MoE sliding-window behavior and a testing_utils bug are unrelated subsystems and symptoms.

Both concern model internals, but one is a missing RMS norm epsilon config field and the other is a RoPE implementation issue; not the same concrete bug.

AutoProcessor kwargs forwarding and auto_docstring annotation handling are separate utility-layer problems with different code paths.

Both involve tokenizer/pretrained loading, but one is an AddedToken construction error and the other is a mapping-name None handling bug; not the same defect.

Both are import errors, but for different missing symbols from different modules; no evidence they stem from one shared export regression.

AutoProcessor/video-model crash without torchvision is unrelated to TOKENIZER_MAPPING_NAMES returning None.

local_files_only network leakage and missing embed_tokens.weight on UMT5Encoder.from_pretrained are distinct loading bugs.

Missing qwen3next projections and a dropped config field in Qwen3_5MoeVisionConfig are different model/config issues.

Summary: These issues are mostly unrelated, with only superficial overlap in a few Transformers import/configuration topics. None of the soft pairs looks like the same underlying bug or a mergeable duplicate PR-equivalent change, so all soft edges should be rejected.


issue:43097 is the broadest and most central v5 regression report in the set, but it should be treated as a representative issue only, not a duplicate target for the rest of the cluster.

Both mention v5-related breakage, but one is an ImportError for a missing symbol while the other is about a removed API; different failure modes and code paths.

These concern different Qwen3/VL problems: one is a generic Transformers 5.0 bug report, the other is a specific missing projection layer in qwen3next.

Apple Silicon TypeError in caching allocator warmup is unrelated to a testing_utils bug.

UMT5 weight-loading omission is a model-specific loading bug; max_shard_size default behavior in save_pretrained() is a separate API/design issue.

Wrong tokenizer decoder type and an isolated reproduction of another issue are not the same defect; no shared code-path evidence.

Removed tie_embeddings API and quantization offloading misbehavior are different regressions affecting different subsystems.

Missing Qwen2_5_VL export and AutoProcessor crash without torchvision are distinct import/dependency issues.

Meta-device model loading failures and missing HybridCache import are separate v5 regressions with different symptoms.

A bfloat16 compilation warning is not the same as degenerate training under flash_attention_3; they involve different execution paths.

Qwen3VL-Moe loading breakage is not the same as qwen3next missing attn projections; both are model-family-specific but unrelated.

Summary: The cluster is a loose collection of unrelated Transformers issues, mostly v5 breakages, import errors, and model-specific loading/training bugs. None of the soft pairs look like the same underlying defect, so I would not merge any of them as duplicates.


No issue is a strong global representative because the cluster is heterogeneous and none of the soft pairs are true duplicates.

No single canonical issue stands out: the items span unrelated regressions and feature gaps (offline cache loading, saving dequantized models, bfloat16 warnings, config-field removal, Flash Attention support, pipeline docs, etc.).

Different problems: NemotronHForCausalLM lacking Flash Attention 2.0 support vs GPT2 attention scaling being ignored under SDPA/FlashAttention. Same broad area, but not the same bug or fix.

One is about junk-filled non-persistent buffers in v5; the other asks why save_pretrained() uses 50GB max_shard_size. Both touch saving, but they are unrelated issues.

Pipeline task-support error messaging is unrelated to saving Pipeline objects with save_pretrained(). Different code paths and different user-facing failures.

Removed tie_embeddings_and_encoder_decoder in v5 is a model/config API change; return_all_scores documentation mismatch is a pipeline doc/behavior issue. Not the same underlying bug.

A bfloat16 compilation warning from PyTorch is unrelated to a LoRA fine-tuning warning about tie_word_embeddings=False. Similar warning shape, different cause and fix.

Tokenizer offline cache loading and gradient checkpointing in eval mode are unrelated behaviors in different subsystems.

Invalid GenerationConfig for GLM-5 is not the same as a failing janus image-generation test; these are different models and failure modes.

Saving dequantized Ministrals/Devstrals and saving Pipeline objects are both about serialization, but the concrete failure and code path differ.

Llama4Config missing pad_token_id is a model config attribute bug; TOKENIZER_MAPPING_NAMES returning None is a tokenizer mapping assumption bug. Not duplicates.

A bfloat16 precision warning is not the same as Bamba-9B-v2 failing under torch.compile with SDPA. Same general compute stack, different concrete issue.

Summary: All proposed soft pairs are only loosely similar at a topic level; they describe different bugs, configs, or subsystems and should not be merged as duplicates.


Issue 36683 is the best global issue candidate because it is a specific, reproducible runtime error with strong community engagement.

Issue 36683 is the clearest concrete bug report and has the highest discussion activity, making it the strongest single representative among these unrelated issues.

Different problems: one is a model-specific Flash Attention support error, the other is a Python version compatibility issue.

Different subsystems and symptoms: xLSTM training bugs vs a BeitImageProcessorFast label reduction bug.

One concerns distributed optimizer state handling under FSDP2/PEFT, the other is attention scaling being ignored in GPT2 backends.

CLIP attentions assignment and GPT2 attention scaling are distinct code paths and failure modes.

Both touch chat/completions-related flows, but one is an API request validation problem and the other is a batched processor crash.

Both are CLIP regressions, but one is missing attentions and the other is missing hidden states; they are separate bugs.

Gemma3Config missing vocab_size is unrelated to an Apple Silicon TypeError in caching_allocator_warmup.

One is a warning about float32 precision during bfloat16 compilation; the other is a hard failure compiling flex_attention on newer torch.

Both mention RoPE, but they concern different models and different implementation defects.

An import failure for layer_type_validation is unrelated to unwanted network requests under local_files_only=True.

Summary: The items are mostly unrelated standalone bugs; none of the suggested soft pairs looks like the same underlying issue, and there are no PRs in the set.


issue:45216 is the strongest standalone bug report: it’s a concrete regression with a clear `save_pretrained` symptom, a specific model family, and a reproducible checkpoint corruption concern.

No single canonical issue stands out because the items are not duplicates; they cover unrelated subsystems and failure modes (loading, saving, chat templates, vision/video, fp8, docs).

Different surfaces and bugs: `/v1/chat/completions` request acceptance in v5.3 vs `apply_chat_template(tokenize=True)` crashing on tool-call assistant messages.

Both are loading-related, but one is Qwen3VL-Moe model loading regression and the other is a generic state_dict-sorting load error; no clear same code path.

Unrelated failures: chat/completions request validation versus wrong `vision_position_ids` for Qwen2.5-VL video input.

Same broad model family, but different topics: a Qwen3-VL-Moe bug report versus fp8 inference support request.

Docs mismatch for `return_all_scores` is not the same as failing to save `Pipeline` objects with `save_pretrained`.

Quantized model saving failure and pipeline-object saving failure are different artifacts and likely different code paths.

Both involve model persistence, but one is a load error from sorted state_dict handling and the other is a Qwen3.5 `save_pretrained` regression; not the same bug.

Different model families and missing attributes: `Gemma3Config.vocab_size` versus `Sam3VisionEncoderOutput.fpn_position_embeddings`.

Separate model-specific issues: Flash Attention 2.0 unsupported for NemotronH vs invalid `GenerationConfig` for GLM-5.

Audio feature extraction bug and pipeline save failure are unrelated code paths.

`torch.split()` return handling in `GlmMoeDsaIndexer` is a different issue from `DeepseekV3MoE` diverging from the remote implementation.

Summary: No duplicate cluster here: the items span separate bugs, regressions, docs mismatches, and model-specific loading/saving issues. None of the soft pairs looks like the same underlying defect.


#45278 is the most general and cluster-like item: it describes a broad upgrade regression with multiple import failures, so it is the best representative issue only in a loose sense. It still should not be treated as a true duplicate umbrella for the other issues.

No strong canonical duplicate emerges; the issues span unrelated regressions across model configs, loading, training, attention, and Python compatibility. If one issue must serve as the cluster representative, #45278 is the broadest regression-style report, but it does not subsume the others.

Different failures: tokenizer decoder type in v5 vs Qwen2.5-VL video position IDs. Same library, but not the same bug or fix.

Optimizer/FSDP state corruption is unrelated to a cache-strategy typo. No shared code-path problem.

Both involve from_pretrained loading, but they concern different models and different missing weights/error paths.

PatchTSMixer post_init validation and GPT2 attention scaling under SDPA/FlashAttention are separate issues in different subsystems.

Gemma3Config missing vocab_size is a config-attribute bug; PatchTSMixer optional post_init is a model-construction rule change. Not the same underlying problem.

Both mention Python-version compatibility, but one is a Transformers 5.1.0 support issue and the other is a Python 3.14 load failure; too broad and likely different causes.

Missing vocab_size in Gemma3Config and missing pad_token_id in Llama4Config are analogous but distinct model-config omissions, not one concrete bug.

torch.compile branching divergence in attention kernels is a different failure mode from GPT2 attention scaling being ignored in backend paths.

CLIPOutput attentions assignment and Qwen3.5 save_pretrained checkpoint corruption are unrelated changes/failures.

Gemma3 config attribute access and MoE load-balancing loss gating are unrelated code paths.

A no_grad decoration request for cache updates is unrelated to broad import errors after upgrading from 4.57.0 to 5.5.0.

Summary: This cluster is heterogeneous: the soft pairs mostly share only broad Transformers vocabulary (configs, loading, Python, attention, from_pretrained) but point to different models, code paths, and failure modes. I do not see any pair that should be merged as the same underlying bug/change.


issue:41669 best represents a dedup/triage anchor because it names a clear root cause and measurable impact, making it the strongest candidate to subsume nearby import-performance reports.

issue:41669 is the most concrete and actionable item in the set: it identifies a specific import-time regression cause and proposed fix, whereas related import complaints are much more generic.

Both mention slow imports, but one is a specific import-* cause while the other is a vague intermittent import complaint; not clearly the same bug.

Both involve FlashAttention/backends, but they describe different models and different failure modes.

Gemma3 config missing vocab_size and Nemotron FlashAttention support are unrelated failures.

FlashAttention support error vs. Qwen3-VL weight-shape mismatch are different code paths and symptoms.

Model loading error with sorted state_dict is not the same as a missing config field being dropped by strict serialization.

Config attribute error and FSDP2/PEFT optimizer-state corruption are unrelated.

Python 3.14 import/load failure and PretrainedConfig type-checking regression are distinct versioning/type issues.

Both touch model save/load behavior, but one is about sorted state_dict loading and the other about incorrect save_pretrained key mapping.

DSA ReLU discussion and DeepseekV3MoE divergence are different model/implementation problems.

torch.no_grad decoration for update methods is unrelated to the Python version compatibility issue.

Python 3.14 loading failure and Qwen2.5-VL video position-id bug are unrelated.

Summary: The set is thematically broad but not duplicate-tight; most pairs share only a subsystem or symptom class. I found no pair that clearly looks like the same underlying bug/change, so all soft edges are rejected.


Different model-specific bugs: CLIPOutput attention handling vs PatchTSMixer post_init policy. No shared code-path failure.

One is about corrupt non-persistent buffers in Transformers 5.0.0; the other is a Python 3.14 import/load failure. Too different to be the same bug.

An ImportError for a missing symbol in configuration_utils is unrelated to UMT5Encoder omitting embed_tokens.weight during from_pretrained.

Model loading failure due to sorted state_dict is not the same as a question about max_shard_size in save_pretrained.

Both mention tensor parallelism, but one is a training bug and the other is OOM while loading a specific model. Not the same underlying defect.

A flaky SamHQ integration test missing set_seed is unrelated to a latest-transformers model loading failure for Phi-4 multimodal.

Both are CI/test issues, but they affect different tests and failure modes; no evidence of one shared bug.

CLIPOutput attentions assignment and LwDetrImageLoss AMP/CUDA crashes are different model/runtime problems.

PyTorch-not-found ImportError is unrelated to a tokenizer-loading regression.

CLIP attention-output behavior and Qwen3.5 flash-attention generation issues are distinct model-specific bugs.

Summary: The cluster is heterogeneous: the soft pairs share only broad themes like loading, CI, or tensor parallelism, but not the same concrete bug or change. I would reject all soft edges and treat this as a non-duplicate mix of unrelated issues.


issue:43502 stands out as a precise, actionable bug report with a direct behavioral failure (`local_files_only=True` still causing API calls).

issue:43502 is the most concrete, reproducible runtime bug here and has clear user impact; it is the best single issue representative among otherwise unrelated reports.

Both involve loading/import problems, but one is a network/offline leak and the other is an `AddedToken` constructor error; different code paths and fixes.

`@torch.no_grad` on cache/layer updates is unrelated to SGD optimizer arguments; different subsystems and failure modes.

Both mention testing, but one is about missing `set_seed()` in a specific integration test and the other is a bug in `testing_utils.py`; not the same bug.

Both are loading-related, but one is tokenizer loading in v5 and the other is checkpoint reload compatibility after version upgrade; too broad and not the same concrete issue.

Int4 quantization OOM from reserved memory is a distinct performance/memory bug from checkpoint reload failure after upgrade.

FP8 `save_pretrained` for MoE and missing `_tp_plan` for tensor parallelism are separate model/config issues.

Both are import-name errors, but they concern different symbols (`PreTrainedModel` vs `HybridCache`) and likely different missing re-exports.

One is about `update(...)` needing `no_grad`; the other is a generation kwargs update bug after `sync_gpus`—different code paths.

A `no_grad` decoration request is unrelated to a dummy `nn.Conv2d` in `Sam3PixelDecoder`.

Missing `_tp_plan` for tensor parallelism and missing `deepstack_visual_indexes` in a vision config are different config-schema bugs.

Sentence Transformers loading hang and documentation confusion about `input_ids`/`past_key_values` are unrelated issues.

Summary: No soft-edge pair looks like the same underlying bug/change; all should remain separate. The clearest standalone issue in this set is the `local_files_only=True` network-leak report.


#43502 is the best representative issue because it describes a clear, reproducible runtime regression with direct user impact, while the others are narrower or more incidental.

No strong canonical duplicate exists in this set; if one issue must be chosen, #43502 is the most concrete and broadly user-impacting bug report.

Different failures: compiled Python file errors vs slowdown after upgrading and filtering data. Not the same code-path bug.

local_files_only API requests is unrelated to GLM-5 RoPE implementation.

Model_init/Liger kernel application bug and DSA indexer ReLU discussion are unrelated.

torch.no_grad on cache/layer update methods is unrelated to tie_word_embeddings warnings in LoRA fine-tuning.

Tensor parallel training bug and SGD argument handling are different problems in different code paths.

Flaky integration tests due to missing set_seed and wrong position_ids docstring are unrelated.

Unexpected zero probabilities in SigLIP2 and unwanted API requests under local_files_only are distinct bugs.

The racoon issue has no clear overlap with local_files_only API requests.

Both concern version-related loading, but they affect different models and failure modes; not the same concrete bug.

Compiled Python file errors and save_pretrained pipeline object failures are unrelated.

Running compiled Python files and PretrainedConfig type checking are separate issues with different symptoms and fixes.

Summary: The cluster is highly heterogeneous: model-loading bugs, config/type-checking issues, flaky tests, docs, and unrelated warnings. None of the soft pairs appear to be the same underlying bug or change, so no duplicate merges are warranted.


Different bugs: FP8 accuracy issue vs missing image-processor method causing multimodal token counting failure.

One is a flaky integration test missing set_seed; the other is a generation kwargs bug after sync_gpus. Different code paths and symptoms.

Both mention FP8/MoE, but one is save_pretrained behavior and the other is inference support for specific Qwen models; not the same concrete defect.

Both are loading regressions, but one is tokenizer loading and the other is full model loading for a specific vision instruct model. Too broad to merge.

Tokenizer loading regression and tensor-parallel training bug are unrelated.

Docs mentioning pipeline() after v5 removals is unrelated to an issue titled 'racoon'.

Both are v5-era breakages, but one is the env command and the other is an import error for a specific model class; different fixes.

v5 env command failure and PretrainedConfig type-checking breakage are separate regressions with different surfaces.

Generation cache missing during chunked_prefill is unrelated to a typo in cache strategy text/naming.

ImportError for layer_type_validation is a specific API break, not the same as the broken v5 env command.

MacOS bus error loading a community CLIP model is unrelated to a tokenizer-loading regression.

Summary: This cluster is heterogeneous: it mixes unrelated regressions across model loading, generation, FP8, docs, tests, and CLI/env tooling. The soft-similarity links are too broad to treat as duplicates.


No strong best issue for clustering; none of the items clearly represents the whole set, since they span distinct failure modes.

No single canonical issue stands out because the issues cover unrelated problems and components rather than one underlying bug.

Different import failures for different symbols (`AutoImageProcessor` vs `PreTrainedModel`); not the same underlying bug.

One is a documentation clarity issue, the other is an import error for `layer_type_validation`; unrelated.

`transformers env` CLI breakage is unrelated to the `HybridCache` import failure.

An LR scheduler kwargs bug and an unrelated issue titled `racoon`; no evidence of a shared code-path bug.

CLI/env command breakage in v5 is unrelated to Python 3.14 loading failure.

GLM-5 RoPE implementation discussion is unrelated to the `racoon` issue.

Lazy loading behavior and unsafe `sys.modules[]` access are different bugs in different code paths.

Tensor parallel training bug is unrelated to docs still mentioning `return_all_scores`.

Tensor parallel training bug and bfloat16 compilation warning are distinct runtime concerns.

Tensor parallel training bug is unrelated to BEiT image processor label handling.

`AutoImageProcessor` import failure and compiled Python file errors are separate import/loading problems.

MLA q_a_layernorm precision/config bug is unrelated to the `racoon` issue.

Summary: This cluster is not a duplicate set; it contains many unrelated issues across docs, imports, training/runtime behavior, and different model/component bugs. All soft pairs should be rejected.


Issue 45092 is the clearest standalone bug report here: it names a specific incompatibility (old InternVL2 remote-code checkpoints vs v5 meta initialization) and provides a concrete failure mode, even though the cluster is too mixed to justify a true canonical duplicate set.

Different underlying problems: one is an MLA q_a_layernorm precision/config epsilon issue, the other is a DSA indexer missing ReLU.

Both mention v5 regressions, but one is about the `transformers env` command and the other about loading old checkpoints after upgrade; different code paths and fixes.

`processor.save_pretrained(...) missing files` is a specific serialization bug, while `Bug report` is too generic to establish the same underlying issue.

Import-star model startup slowdown and missing GenerationMixin cache during chunked prefill are unrelated failures.

Qwen3-VL 2D bbox hallucination/error is a model-output bug, while PretrainedConfig type checking is a config validation regression.

Both involve Qwen3/MoE, but one is a generic v5/Qwen3-VL-Moe bug and the other is a missing `_tp_plan` for tensor parallelism; not the same concrete fix.

Both are v5 compatibility complaints, but one is general checkpoint reload failure after upgrading and the other is a remote-code/meta-initialization incompatibility for InternVL2; too different to merge as one bug.

TF32 API settings guidance and a typo in cache strategies are unrelated.

Missing `set_seed()` in integration tests versus `inverse_sqrt` ignoring `lr_scheduler_kwargs` are distinct issues affecting different parts of the codebase.

Summary: This cluster looks heterogeneous: the issues share broad Transformers/v5/modeling vocabulary, but they describe different bugs, subsystems, and likely fixes. All soft pairs are false positives rather than true duplicates.


issue:41669 is the best representative issue in this set, but only as an anchor for the import/performance subtheme—not as a duplicate of the other issues.

issue:41669 is the clearest, most concrete anchor because it describes a specific import-time performance regression with measurable impact; the others are broader symptom reports or different code paths.

Both concern import/lazy-loading behavior, but one is about intermittent import slowness and the other about lazy loading being incorrect; different bugs and likely different fixes.

Both involve kwargs propagation, but they affect different APIs and different code paths (AutoProcessor vs inverse_sqrt scheduler).

A model-type mismatch warning and a Liger Kernel/model_init application bug are unrelated issues in different flows.

The env command regression is unrelated to scheduler kwargs handling; no shared underlying defect.

Python version compatibility and Qwen3-VL bounding-box output errors are unrelated.

Flash Attention support for Nemotron and Qwen3-VL 2D box hallucinations are different model-specific problems.

Scheduler kwargs omission and PretrainedConfig type checking are separate regressions in different components.

Both mention imports, but one is import-time slowdown from import * usage and the other is a missing exported symbol; different root causes.

Both touch model initialization/attention features, but the reported failures are distinct: Liger Kernel not applied vs degenerate training with flash_attention_3.

The tokenizer_class mismatch bug is specific and concrete; the other issue is too vague to establish the same underlying problem.

An import performance regression and a small testing_utils bug do not share a concrete code-path defect.

Import slowdown from wildcard imports is unrelated to a typo in cache strategies.

Summary: These items are mostly unrelated issue reports across different subsystems: import performance, lazy loading, model-type warnings, scheduler kwargs, tokenizer save behavior, and model-specific incompatibilities. None of the soft pairs look like the same underlying bug.


Issue 43723 is the most concrete and specific report, but it only represents a small tokenizer-loading subset rather than the cluster as a whole.

No single canonical issue fits the cluster: the items do not share one concrete bug or code path.

Specific buffer/position_ids bug vs a generic bug report; no shared code path is evident.

A typo in cache strategy docs/code is unrelated to pipeline-parallelism output errors.

Deprecated pipeline docs vs scheduler kwarg handling are different subsystems and bugs.

PatchTSMixer post_init validation is unrelated to tied-weight key handling.

Model.forward docs confusion is not the same as a tokenizer-loading regression.

Import-star performance issue and a VRAM leak in Qwen3ForCausalLM are distinct problems.

Tokenizer loading in v5 is unrelated to Qwen3-VL bounding-box generation errors.

Saving Pipeline objects and tied-weight key crashes concern different save/serialization paths.

Broken 'transformers env' command is not the same as lazy loading behavior.

Invalid GenerationConfig handling and Qwen3-VL bbox output issues are different model-specific bugs.

Summary: This cluster is heterogeneous: it mixes unrelated issues about docs, tokenizer loading, env tooling, lazy loading, VRAM leaks, cache typos, schedulers, and model-specific bugs. The soft pairs look like title-level similarity only, not shared underlying defects or changes.


issue:45310 is the best representative issue for triage because it captures the concrete loading failure and has a direct inbound reference.

issue:45310 is the broadest and most user-facing report in the only plausible duplicate group, while issue:45125 is the narrower technical symptom.

Same underlying Qwen3.5 MoE loading/tensor-parallel regression; one report is the narrower missing _tp_plan symptom, the other is the broader from_pretrained failure.

Lazy loading behavior and inverse_sqrt scheduler kwargs are unrelated subsystems and bugs.

The generic title gives no evidence it is the same loading bug; too little concrete overlap to merge.

Qwen3VL timestamp calculation and GLM-5 RoPE implementation are different model/component issues.

Processor timestamp math and scheduler kwargs handling are unrelated code paths.

Documentation confusion in model.forward is not the same as a model loading breakage.

Liger Kernel application during model_init and Qwen3-VL bbox output errors are different problems.

Forward-doc wording and a flash-attention import error are unrelated.

Lazy loading and PretrainedConfig type-checking regression do not describe the same bug.

VRAM leak in multithreaded dataloader use is unrelated to RoPE implementation discussion.

TF32 API guidance and VRAM leakage are different issues with no shared failure mode.

local_files_only network requests and Qwen3VL timestamp calculation are separate bugs.

Processor timestamp calculation and processor.save_pretrained missing files are different processor issues.

Timestamp calculation in a processor is unrelated to Qwen3ForCausalLM VRAM leakage.

Summary: The set is mostly unrelated issues. The only plausible duplicate pair is the Qwen3.5 MoE regression around from_pretrained/tensor-parallel handling; everything else looks distinct.


If one issue must be used as the standalone representative, issue 44556 is the most concrete and broadly actionable regression report (checkpoint reload failure after v4.57 -> v5.2/v5.3), but it is not a duplicate anchor for the rest of the set.

No clear duplicate center emerges: the items span unrelated areas (tokenizer behavior, config attributes, cache strategy, test flakiness, checkpoint loading, etc.), so there is no single canonical issue for the cluster.

Both mention tokenizer v5, but one reports generic behavior differences while the other is about the wrong decoder type; different failure modes and code paths.

Test flakiness from missing set_seed is unrelated to a VRAM leak in Qwen3ForCausalLM with multiple dataloader threads.

A scheduler kwargs bug and an unrelated placeholder title ('Unemployment') are not the same issue.

_get_tied_weight_keys AttributeError and apply_chat_template crashing on tool-call assistant messages are separate subsystems and bugs.

The placeholder/irrelevant 'Unemployment' issue is unrelated to a testing_utils.py bug.

A cache-strategy typo is unrelated to the unrelated 'Unemployment' issue.

CLIPOutput attentions regression and the unrelated 'Unemployment' issue are not duplicates.

Checkpoint reload breakage after upgrading to v5.x is unrelated to the unrelated 'Unemployment' issue.

Missing pad_token_id in Llama4Config and AttributeError in tied-weight-key collection affect different code paths and model/config classes.

Missing pad_token_idx in StableLmConfig is a config-compatibility issue, not the tied-weight-key crash described in 44861.

Slow from_pretrained checkpoint loading and an ImportError for layer_type_validation are unrelated problems.

fp8 inference support for Qwen3-VL is a feature/support request, while processor.save_pretrained missing files is a separate save-path bug.

Summary: This cluster is mostly unrelated issue reports that only share broad Transformers vocabulary; none of the suggested soft edges look like the same underlying bug or change.


If one issue had to serve as the broadest representative, issue 45310 is the most concrete/reproducible code bug, but it still does not subsume the others; overall this cluster does not have a strong best issue.

No single canonical issue is justified here: the soft-linked issues are thematically related to model loading/inference, but the actual bug reports are different enough that they should remain separate.

Slow from_pretrained checkpoint loading and a tensor-parallel training bug are different failures in different code paths.

One is a performance/load-time complaint, the other is documentation confusion about forward inputs; not the same underlying bug.

Both mention loading, but checkpoint loading slowness and tokenizer-loading regression are distinct issues.

FP8 MoE inference support and a Qwen3.5 MoE from_pretrained error are different feature/bug reports, not one concrete fix.

A slow checkpoint load issue and a Gemma3Config missing vocab_size AttributeError are separate problems.

Continuous batching support for audio models and FP8 support for Qwen3-VL/Qwen3.5 MoE are unrelated feature requests/bugs.

Summary: These items are not duplicates of one another; they span separate problems such as slow checkpoint loading, tokenizer loading regressions, documentation confusion, tensor-parallel training, missing config attributes, continuous batching audio support, and FP8 inference support.


issue:27088 is the most actionable and specific issue; the others are generic template variants with no explicit language named in the visible title.

issue:27088 is the only specific, non-placeholder request ([i18n-TR] Translating docs to Turkish), so it is the clearest representative of the actual translation task in this cluster.

High textual similarity, but the right side is a generic placeholder and not clearly the same language/task as Turkish.

High textual similarity, but this looks like a separate placeholder i18n request rather than the same Turkish translation issue.

The visible titles/body patterns are templated i18n requests; no evidence this is the same underlying Turkish request.

These appear to be separate placeholder translation issues, likely for different languages, not one concrete bug/change.

Similarity is template-level only; there is no concrete evidence they target the same translation task.

Both are generic i18n placeholders, but the data does not show they are the same underlying request.

Summary: This cluster is dominated by near-identical i18n template issues, but the only concrete request is for Turkish. The placeholder-style issues look like separate language requests rather than duplicates of the Turkish one, so I would not merge any pair.


Different models and scopes: LFM2.5 Audio 1.5B vs SAM3-LiteText. Both are model requests, but they target different architectures and features, not the same underlying issue.

Both are Qwen3 requests, but one is TTS and the other is ASR. Different code paths and model capabilities, so not duplicates.

Weight-sparse transformer support request vs EUPE perception encoder request. They are unrelated model additions with different implementation requirements.

ASR support vs a generic audio model request. Similar domain, but distinct model and task, so not the same change.

Qwen3-ASR support and EUPE are different model families and modalities; no shared concrete bug or code path.

NeoBERT and LFM2.5 Audio are unrelated models. Broadly both are add-model requests, but they do not describe the same feature.

Qwen3-TTS support vs DeepSeek-OCR2. Different modality and integration path, so not duplicates.

NeoBERT vs Qwen3-ASR are unrelated model additions. Same general 'support a model' theme only.

Both are TTS-related requests, but for different models (Qwen3-TTS vs Voxtral-4B-TTS-2603) and likely different integration details.

NeoBERT request and weight-sparse transformer request target different model types and functionality.

ASR support for Qwen3 is not the same as adding an OpenAI weight-sparse transformer model.

Qwen3-ASR and DeepSeek-OCR2 are different tasks and model families; no duplicate evidence beyond generic model-support similarity.

TTS support request vs audio model addition. Related domain, but not the same model or implementation target.

Qwen3-TTS and the OpenAI weight-sparse transformer request are different model additions with different code paths.

DEIMv2 and Qwen3-TTS are unrelated model requests; similarity is only at the generic 'add support' level.

EuroBert config support vs DEIMv2 model support. Different models and different integration work.

NeoBERT and ModernVBERT are both BERT-family requests, but they are distinct models with different integration requirements.

EuroBert model config addition and Qwen3-TTS support are unrelated changes across different model families and modalities.

NeoBERT vs Voxtral-4B-TTS-2603 are different model requests, one text encoder-style and one speech/TTS.

BERT-like models with RoPE is a broad conceptual request, but Voxtral-4B-TTS-2603 is a specific TTS model. Not the same concrete issue.

Qwen3-ASR and Voxtral TTS are different speech tasks and model families; they should not be merged.

ModernVBERT models vs Qwen3-ASR support are distinct model additions with different target code paths.

ModernVBERT models may relate to RoPE usage, but the issues are not the same request: one is a specific model family, the other a broader architectural pattern.

ModernVBERT and Qwen3-TTS are unrelated model requests; no shared concrete change.

Summary: This cluster contains many unrelated model-request issues that only share a broad 'add model support' theme. The apparent similarities are mostly by model family or modality (e.g., TTS, ASR, OCR, BERT-like), not the same concrete change, so no soft edges should be merged.


issue:45027 is the strongest issue to keep as the cluster representative because it is open, concrete, and likely to drive the actual implementation discussion for a specific model.

issue:45027 is the more specific and active request: it targets Voxtral-4B-TTS-2603, is open, and has discussion/inbound activity, making it the better representative of the current support request cluster.

Same broad topic of adding model support, but they request different models (ModernVBERT vs Voxtral-4B-TTS-2603) and do not appear to describe the same underlying bug or change.

Summary: These are two separate model-support requests in the same broad area, but they target different models and likely different implementation work. They should not be merged as duplicates.


issue:44031 is the strongest standalone issue here because it describes a concrete, user-facing regression affecting all tokenizers, with clear impact and discussion activity.

Different problems: one questions Llama4TextL2Norm semantics, the other reports an incorrect type hint in ModernBERTConfig.

Both are model-related bugs, but they affect different code paths: Mask2Former ignore_value handling vs loss-function kwargs propagation.

Unrelated subsystems: a Mask2Former model option bug versus a tokenizer regex warning regression.

Different scope and failure mode: missing use of ignore_value vs a typo in a quantization attribute name.

No shared underlying bug: Mask2Former ignore_value behavior is unrelated to a ModernBERTConfig annotation error.

Loss kwargs forwarding and a config type-hint mistake are distinct issues with no common code path.

A ModernBERT config typing issue is unrelated to the tokenizer regex-warning regression.

Different classes of change: type-hint correction versus a literal typo in a conversion attribute name.

Summary: These issues are not duplicates of one another; they span unrelated areas (model behavior, loss plumbing, config typing, a typo, and a tokenizer regression).


#43037 is the best representative issue in this pair because it has a clearer scope and intent; #41084 is too underspecified.

Issue #43037 is the more concrete and actionable issue: it names a specific model support request, whereas #41084 is too vague to serve as a strong canonical reference.

Different problem statements: 'Set Block Decoding' suggests an implementation detail, while 'DeepSeek v3.2 support' is a model-support request. No shared targets, files, or concrete evidence that they refer to the same change.

Summary: These two issues are not duplicates: one is a vague request about block decoding, while the other is a specific feature/support request for DeepSeek v3.2. They don’t describe the same underlying bug or change.


No single canonical issue stands out because the issues target different Trainer behaviors and different underlying fixes.

The titles and likely scopes differ: one concerns column pruning customizability, the other concerns FLOPS counting for custom trainers. They share a broad Trainer theme but not the same underlying bug or change.

Summary: These two issues are related to Trainer internals and customization, but they describe different problems: one asks to revisit `remove_unused_column` behavior, while the other asks FLOPS estimation to account for custom trainers. They should not be merged as duplicates.


Neither issue is a clear canonical for the other because they address different model/config combinations and different auto-model entry points.

Not a duplicate cluster: one asks for Qwen3-Omni registration in AutoModel/AutoModelForConditionalGeneration, while the other asks for AutoModelForSequenceClassification support for Qwen3.5/Qwen3_5Config.

Different model families (Qwen3-Omni vs Qwen3.5) and different tasks/auto classes (conditional generation vs sequence classification); not the same fixable code-path problem.

Summary: These issues are both about missing AutoModel registration/support, but they target different model families and different auto classes, so they do not look like the same underlying bug.


43845 is the best global issue candidate only in a provisional sense: it is the earliest issue with the repeated title, but the evidence is too thin to confirm a true duplicate set.

43845 is the earliest of the similarly titled "huggingface" issues, so it is the best provisional representative if this later proves to be a duplicate cluster.

Different title and no concrete evidence that they report the same underlying problem.

Same title and close timing are not enough without body text, links, or target/code-path evidence.

Summary: Fett looks unrelated. The three "huggingface" issues are only weakly similar by title and timing; without body text or explicit links, they should not be treated as confirmed duplicates.

The grouping is a bit too strong for the evidence in the packet. We only see matching titles, close timestamps, and soft-similarity scores/body lengths; there is no body text or explicit link showing the three "huggingface" issues are the same underlying report. The soft-edge accepts therefore overstate certainty, especially the claims about "same general report text pattern" and "same underlying issue report." The "Fett" issue being unrelated is reasonable, but the duplicate-set verdicts should be more conservative.


issue:44371 is the best placeholder only because it is an early, generic spam-like report; however, none of the issues form a meaningful canonical root cause.

Both are generic spam placeholders, but there is no concrete shared bug or request to unify.

Same as above: similar low-content spam titles, not the same underlying issue.

One is a spam placeholder and the other is a documentation enhancement request; these are unrelated.

A spam placeholder and a named-entity style issue title are not the same bug/change.

Documentation enhancement and spam placeholder do not describe the same underlying task.

Documentation enhancement and spam placeholder are unrelated.

Both are spam placeholders, but there is no evidence of a shared concrete issue beyond generic junk titles.

Spam placeholder and unrelated named-entity title do not match the same problem.

Summary: All items look like unrelated low-signal spam or placeholder issues, not duplicates of a single underlying bug or request. No soft edges should be accepted.


#45145 is the best representative issue for this cluster: earliest timestamp, identical title to #45151, and slightly stronger evidence of being the original discussion.

Issue #45145 is the better canonical issue because it was created first and has an inbound reference, making it the most likely original thread.

Likely duplicate: the issues have identical titles, were opened close together, and have similar body lengths. The packet does not show body-content comparison, so this is a conservative duplicate acceptance based on metadata.

Summary: The pair looks like a likely duplicate issue cluster: both are closed, share an identical title, and were opened within hours of each other. #45145 is the best canonical/representative issue because it was created first and has the only inbound reference.

The overall clustering judgment is plausible, but the soft-edge verdict is a bit too strong for the evidence in the packet. We only have identical titles, similar body lengths, and close creation times; we do not have body-content comparison, so saying the issues are 'evidently the same topic/body' overstates what is shown. Please keep the verdict more conservative (e.g., 'likely duplicate' based on identical title and timing).


Issue #45373 is the best representative: it is open, more detailed, and directly describes the exact API missing from Gemma 4.

Issue #45373 is the clearest canonical issue because it precisely names the missing class (`Gemma4ForSequenceClassification`) and states the gap in the `gemma4` module.

Summary: Both items are the same missing feature request for Gemma 4 sequence classification support; the newer issue is more specific and better documented.


PR 43251 is the strongest canonical PR candidate in this cluster: explicit issue linkage, direct utility-function fix, and the clearest match to the underlying bug. The rest of the cluster is mostly unrelated model additions or subsystem changes.

PR 43251 is the best representative of the duplicate pair because it explicitly targets issue 43240 and contains the more complete `fixed_cross_entropy` kwargs pass-through fix in the shared code path.

Same bug and same code path: both patch `src/transformers/loss/loss_utils.py` to forward supported `cross_entropy` kwargs for issue 43240, so they are functionally the same fix.

Different changes: Mistral4 test/integration fixes versus adding SonicMoe kernels/MoE integration; same broad MoE area but not the same underlying bug.

Unrelated: processor/auto-loading robustness changes versus adding a new MobileLLM model.

Different problems in `auto` loading logic, but one is processor handling and the other is tokenizer conversion/error behavior; not the same fix.

Tokenizer conversion/error handling versus Gemma4 text-only training behavior; no shared underlying bug.

Model-creation skill/docs scaffolding is unrelated to the Whisper tokenizer off-by-one fix.

New MobileLLM model addition versus Gemma4 training-mask logic; different models and different code paths.

Mistral4 test fixes and SonicMoe renaming/kernels are unrelated changes.

Executorch export dynamic-shape test is unrelated to Mistral4 test/runtime fixes.

New model implementation versus Whisper tokenizer special-token indexing fix; unrelated.

Different model additions/refactors: MobileLLM versus Falcon output-collection refactor.

Loss utility kwargs fix versus a new model implementation; no overlap in underlying bug.

Falcon output-capture refactor and tokenizer conversion behavior are different code paths and issues.

Tokenizer auto-loading error handling versus Whisper tokenization bug; different behavior and files.

Falcon model refactor is unrelated to Whisper tokenizer boundary checking.

Executorch export test and Whisper tokenizer fix are unrelated.

Cross-entropy kwargs fix is unrelated to Mistral4/MoE test changes.

Executorch exportability testing is unrelated to adding MobileLLM.

VideoPrism model addition and Executorch dynamic-shape export testing are separate, unrelated efforts.

Falcon refactor and model-creation skill PR are unrelated and not the same code change.

Mistral4 tests and model-creation skill scaffolding are unrelated.

Falcon standardized output collection refactor is unrelated to Mistral4 test fixes.

MobileLLM addition and Mistral4 test fixes are different model areas and different changes.

MobileLLM model addition and model-creation skill PR are not the same underlying bug/change.

Summary: Mostly unrelated pull requests across different models and subsystems; only one soft edge looks like a true duplicate fix pair in `fixed_cross_entropy` for issue 43240.


PR 43823 is the best representative artifact here because it is a focused, self-contained feature addition with model code and tests. PR 45078 is a separate tokenizer fix, and PR 45213 is mostly tooling/documentation scaffolding.

PR 43823 is the most concrete standalone code contribution in the set: a new model implementation with tests. The other PRs are a narrow tokenizer behavior fix and a broad scaffolding/meta workflow change, so they are not better representatives of a shared change.

Tokenizer auto-selection bug fix and model-creation skill/meta PR are different changes in different code paths; they do not fix the same concrete problem.

New MobileLLM model implementation vs tokenizer auto behavior change are unrelated features/fixes with no shared underlying bug.

Summary: The three PRs are unrelated: one adds MobileLLM, one changes tokenizer auto-selection logic, and one is a broad model-creation skill/meta update. None look like duplicates or the same underlying change.


#40546 is the best PR to represent the cluster since it is the main implementation PR; #42781 is a follow-on extension rather than the same change.

#40546 is the better canonical PR because it is the original, broader VibeVoice integration and provides the baseline implementation that the later realtime work builds on.

Reject: same model family and overlapping files, but #40546 implements core VibeVoice support while #42781 adds realtime-specific functionality and extra components, so they are not the same concrete change.

Summary: These are related VibeVoice PRs, but they are not duplicates: #40546 adds the base VibeVoice model integration, while #42781 adds a separate realtime variant with additional tokenizer/feature-extractor and generation changes. They share a model family and several files, but they target different functionality and code paths.


41224 is the more developed and reviewed PR, so it is the better standalone representative, but it is not a duplicate of 40755.

No canonical PR: the PRs target different models and code paths, so there is no duplicate pair to collapse.

Different model families and code paths: TimesFM covariate forecasting vs DINOv3 image-classification support. They share only a broad 'add model support' theme, not the same underlying change.

Summary: The cluster contains two unrelated feature PRs: TimesFM covariate forecasting and DINOv3 image-classification support. They do not duplicate each other.


PR 44339 is the best representative of the cluster because it covers the full Transformers integration for DEIMv2 and subsumes the narrower initial add in 41356.

PR 44339 is the better canonical PR because it is the more complete DEIMv2 integration: it adds the model, loss, auto-registry wiring, converter, docs, and tests, whereas 41356 is an earlier smaller implementation.

These look like the same underlying feature change: adding DEIMv2 to Transformers. They share the same issue target, overlap on core model/doc/test files, and 44339 appears to be the later, expanded version of the same integration rather than a different change.

Summary: Both PRs are for DEIMv2 integration, with substantial overlap in model/docs/tests and the same tracking issue. PR 44339 is the broader, more complete implementation, while 41356 looks like an earlier partial version.

The summary is grounded in the packet: both PRs target issue 41211, share core DEIMv2 files, and 44339 clearly adds a broader set of integration pieces (loss, auto-registry, converter, modular code, docs, tests). The mergeability judgment is conservative enough for a same-feature follow-up rather than an unsupported leap.


45186 is the slightly better representative of the cluster because it is a fuller integration with model, image processing, and extra utility coverage, but it is not a duplicate of 41797.

No canonical PR: they introduce different model families with distinct configs, modeling, processing, and tests.

Different model additions for different architectures (DeepSeekOCR vs Isaac). Shared files like auto registries and repo checks are expected boilerplate for new model PRs, not evidence of the same underlying change.

Summary: These are both new-model integration PRs, but for different models and codepaths (DeepSeekOCR vs Isaac). The overlap is mostly boilerplate for registering a new model, not a shared underlying bug or change.


Different model integrations with different files, configs, and code paths; shared registry edits are incidental and not enough to treat them as the same PR or merge into one change.

Summary: These are two separate model-addition pull requests for different architectures (InternVLFlash vs AXK1). They share some auto-registration scaffolding, but they do not address the same underlying change and should not be deduplicated.


PR 42227 is the strongest standalone candidate: it has a concrete Whisper bug fix, an explicit linked issue, and a focused code change in the ASR pipeline.

Both touch Whisper, but 42227 fixes return_language forwarding in the ASR pipeline while 43291 changes tokenizer decode/test behavior; different underlying bugs.

Unrelated: 42227 is a Whisper pipeline bug fix, while 43665 only adds/edits tests for CLIP and ViT with no shared concrete code-path problem.

Different subsystems and failures: Whisper ASR parameter handling versus FP8/core model loading dequantization logic.

Unrelated changes: Whisper return-language fix versus CLIP checkpoint conversion mapping and loading behavior.

Test-focused edits in different models, but they do not address the same concrete bug or code path.

Whisper tokenizer/test changes are unrelated to FP8 loading/dequantization fixes.

Different targets: Whisper decode/test adjustments versus CLIP conversion/loading fixes.

No shared underlying bug; one is bogus model test edits, the other is a substantive FP8 dequant/loading change.

Different code paths and goals: placeholder test edits versus CLIP checkpoint conversion mapping.

They both mention core_model_loading.py, but 44815 is FP8 dequant logic while 45448 is CLIP prefix/conversion mapping; not the same fix and not mergeable into one PR.

Summary: These PRs are not duplicates overall; they split into unrelated fixes: Whisper return-language plumbing, Whisper tokenizer tests, placeholder/bogus test edits, FP8 dequant loading fixes, and CLIP checkpoint conversion fixes.


PR #42975 is the best representative of the cluster overall: it spans more workflows and a more coherent dependency upgrade objective than #42976, which is narrower and more piecemeal.

PR #42975 is the better canonical representative because it has the broader workflow-action compatibility upgrade scope and a clearer single theme (Node 24 compatibility across multiple GitHub Actions).

Both are workflow dependency bumps, but they change different actions and do not appear to fix the same concrete bug or be safely mergeable into one PR without conflating distinct upgrade tracks.

Summary: Two open PRs both update GitHub Actions versions in workflow files, but they target different action families and different change scopes: one is about Node 24 compatibility for core actions, the other is a broader/latest-version bump centered on Docker-related actions. They are related maintenance, not the same underlying change.


pull_request:43451 is the most substantial and specific PR in the set, but it is still a distinct Molmo2 addition rather than a duplicate of the others.

Different models and code paths: ViT NEPA vs Molmo. Shared docs/auto-registry edits are boilerplate only.

Different model additions with unrelated implementations. Similarities are limited to generic docs/registration files.

Related family names, but Molmo and Molmo2 are separate model integrations with different files and behavior; not the same concrete change.

Summary: These are three separate model-addition PRs: ViT NEPA, Molmo, and Molmo2. Their overlap is limited to shared docs/auto-registration boilerplate, not the same underlying code change, so none should be merged as duplicates.


PR #43532 is the best representative because it has a clear, coherent codepath change centered on CI/test infrastructure and broader impact than the narrow, likely synthetic edits in #43488.

PR #43532 is the more substantive and representative change in this cluster: it makes a concrete CI/testing workflow adjustment across workflow files and testing utilities, whereas #43488 looks like a synthetic repo-bot check with unrelated packaging edits.

Reject: the PRs target different problems. #43488 changes setup/versioning and test dependency plumbing for a repo-bot-style check, while #43532 rewires comment-driven CI/workflow behavior and related utilities. The only shared file is a test file, which is insufficient to treat them as the same underlying change.

Summary: The two PRs are not the same underlying change: #43488 is a repo-bot/check-format style change touching packaging and a VIT test, while #43532 is a broader CI/workflow and testing utility change. They only overlap on one test file and do not appear mergeable into a single fix.


Neither PR is a duplicate of the other; if forced to pick a representative, PR #43613 is slightly broader in model coverage, but it still addresses a different feature than #43612.

No single canonical PR: the two changes implement different pipeline features rather than the same fix/change.

Different pipeline features (concept vs visual segmentation) with different filenames/tests and model integrations; shared docs and pipeline scaffolding are not enough to treat them as the same change.

Summary: These are related but distinct PRs: one adds a Promptable Concept Segmentation pipeline, the other adds a Promptable Visual Segmentation pipeline. They share documentation/scaffolding patterns, but the underlying tasks, model integrations, and test targets differ, so they should not be deduplicated.


PR 43651 is the cleaner representative of the cluster because it introduces a focused trainer override hook for loss scaling; however, it is not a duplicate of 43663.

No canonical PR for a duplicate set: the PRs target different code paths and different extensibility points in `trainer.py`.

Both touch `trainer.py`, but one addresses gradient accumulation loss normalization and the other changes signature-column filtering for PEFT/custom trainers. Different behavior, different fix.

Summary: The two PRs are both small trainer refactors that add override hooks, but they address different behaviors: one changes gradient-accumulation loss scaling, the other changes column filtering based on model signature. They are not the same underlying fix and should not be merged as duplicates.


PR 43842 is the best overall representative because it targets the concrete runtime failure directly and avoids the broader refactor/annotation cleanup noise seen in the other PRs.

PR 43842 is the most direct and minimal fix for the `TypeAdapter` NameError, with an explicit issue link and a narrow change set concentrated on the failing import/annotation path.

The evidence is not strong enough to treat these as the same bugfix. 43656 has a different issue target and the preview shows broader `from __future__ import annotations` / annotation cleanup in `TimedModel`, not a clearly identical `TypeAdapter` NameError fix.

Although both touch `src/transformers/cli/serve.py` and share an issue target, the preview for 43836 suggests a wider Serve refactor rather than a narrowly equivalent fix for the same concrete `TypeAdapter` NameError path.

Summary: PR 43842 is still the best representative: it directly fixes the optional-`pydantic` `TypeAdapter` NameError with a minimal, focused change. The other two PRs are too weakly grounded as duplicates: 43656 looks like a broader annotation/`__future__` cleanup with a different issue target, and 43836 appears to be a larger Serve refactor that merely includes a TypeAdapter-related edit.

The conclusion is a bit too strong for the packet. PR 43842 is well-supported as the most direct fix: it has an explicit issue link and a narrow change around `TypeAdapter` import/annotation handling. But the claim that all three PRs are the same `TypeAdapter` NameError fix is not fully grounded. For 43656, the preview only shows a broader `from __future__ import annotations` / annotation cleanup in `TimedModel`, with a different issue target and no direct evidence it is the same bug. For 43836, the shared issue target helps, but the diff preview suggests a wider Serve refactor rather than just the minimal bugfix. The soft-edge accepts therefore feel a bit non-conservative, especially for 43656 vs 43842.


#45118 is the best PR because it addresses the concrete loading path end-to-end, not just a temporary compatibility fallback.

#45118 is the broader, final implementation for GPT-OSS GGUF loading support; it supersedes the earlier fallback-only workaround in #43757.

Same general issue target, but different changes: #43757 only adds a fallback to gpt-neox for unsupported GPT-OSS GGUF, while #45118 implements full GGUF loading support. They are related, but not the same underlying code change.

Summary: These PRs are related to GPT-OSS GGUF loading, but they are not duplicates: #43757 is a stopgap fallback to avoid hard failure, while #45118 adds full GGUF loading support with docs, integration, and tests. The later PR is the better representative of the underlying fix.


PR 43816 is the strongest overall candidate: it targets the same issue, touches the same code path, and appears to be the more complete implementation of the SwanLab `id`/`resume` support.

PR 43816 is the better canonical representative because it more clearly and completely describes the same SwanLab resume/id feature, including documentation for the new `SWANLAB_RUN_ID` and `SWANLAB_RESUME` parameters alongside the integration change.

Same underlying SwanLabCallback change: both modify `integration_utils.py` to support `id`/`resume`-style run resumption, share the same issue target, and could plausibly be merged into one PR.

Summary: Both PRs target the same SwanLabCallback enhancement in the same file and appear to implement the same underlying run-resume/id support for SwanLab init. PR 43816 looks like the more complete formulation, with explicit parameter docs plus the code-path change.

The packet supports the analyst’s conclusion: both PRs target issue 43698, touch the same file, and are clearly about the same SwanLab `id`/`resume` resume-support bugfix. The soft-edge mergeability verdict is conservative enough here. The only caveat is that PR 43816’s preview is truncated, so the “more complete” claim should be treated as tentative, but it is still grounded by the titles and diff previews.


#43838 is the strongest standalone PR: it has the broadest and most complete model integration surface plus explicit issue linkage, making it the best representative of this cluster even though the other PRs are unrelated.

No single PR here is a clear canonical duplicate target; the closest to a substantial implementation PR is #43838 because it adds a full new model family with docs, auto-registration, modeling, processing, and tests.

Different changes: #43838 adds Qwen3-ASR model support and docs/tests, while #45283 adds GGUF loading mappings for Qwen3.5. They do not fix the same code-path problem and would not plausibly be merged as one PR.

Different model families and different purposes: #43973 adds Lfm2Audio support, while #45283 changes GGUF integration for Qwen3.5. Shared audio/serialization infrastructure is too broad to treat as the same underlying change.

Summary: These are three unrelated model-support pull requests: Qwen3-ASR integration, Lfm2Audio support, and Qwen3.5 GGUF loading. They share only broad audio/LLM-adjacent infrastructure patterns, not the same underlying bug or change.


44066 is the most canonical single PR in this set because it is the clearest, broadest example of the shared refactor pattern and is explicitly tied to the umbrella issue.

PR 44066 is the best representative of the cluster: it has the explicit tracking issue, targets the standardized output-tracing migration directly, and covers the core GPT-J/CodeGen path cleanly.

Different model families and files; both are output-tracing refactors, but not the same concrete change.

CVT/FNet vs DeBERTa V2; same umbrella theme only, not a duplicate patch.

Same GPT-J output-tracing decorator migration in the same core file; 44085 looks like a narrower version of the same change.

ResNet/RT-DETR vs EfficientNet; shared theme only, not the same code path.

EfficientNet vs GPT-J/CodeGen; unrelated implementations despite similar refactor wording.

GPT-J/CodeGen vs EfficientNet; same refactor style, different underlying model code.

MobileNetV2 vs DeBERTa V2; not the same bug or patch.

GPT-J/CodeGen vs MGP-STR; broad output-tracing work only, no shared concrete code path.

GPT-J/CodeGen vs MPT; same infrastructure change, different model implementation.

Both are GPT-Neo output-tracing decorator refactors in the same file/test area, so they look like the same underlying change.

GPT-J/CodeGen vs GPT-Neo; similar refactor pattern, but different model-specific code paths.

GPT-Neo vs GPT-J/CodeGen; same umbrella initiative, but not the same concrete patch.

ResNet vs GPT-J/CodeGen; no shared code path.

MGP-STR vs GPT-J/CodeGen; only the refactor pattern matches, not the implementation.

ResNet vs GPT-J; different architecture and file set.

GPT-Neo vs ResNet; same output-tracing theme, different concrete change.

GPT-Neo vs Flaubert; shared refactor style only.

GPT-Neo vs GPT-J/CodeGen; different model families.

GPT-Neo vs MGP-STR; same umbrella work, different code paths.

GPT-Neo vs GPT-J; different models and files.

GPT-Neo vs MGP-STR; not the same underlying change.

Both target the GPT-J output-tracing decorator refactor on the same core file family; they look mergeable into one PR.

Same GPT-J output-tracing refactor in overlapping code; 44722 is a broader variant of the same change.

Summary: This cluster is mostly a set of model-specific output-tracing refactors, but only the GPT-Neo pair and the GPT-J family variants look like true duplicates of the same concrete code change. The rest are broader umbrella refactors across different architectures and should stay separate.


44161 is the best representative PR in the cluster because it is explicitly issue-linked, narrowly scoped, and directly reflects the standardized output-handling change pattern without mixing in unrelated model changes.

44161 is the cleanest representative of the shared theme: it explicitly targets #43979 and focuses on a single model’s transition to @capture_outputs/@can_return_tuple with a clear, self-contained refactor.

Different models/code paths (MPT vs GPT-J). Same refactor theme, but not the same underlying change.

GPT-2 and MGP-STR are unrelated model implementations; this is only a broad architectural similarity.

GPT-2 vs GPT-J/CodeGen. Shared output-tracing theme is too broad to treat as a duplicate change.

GPT-J and MGP-STR touch different code paths and models.

ViLT vs Flaubert/XLM are different model families; same refactor pattern is not enough.

GPT-Neo and MPT are unrelated model-specific refactors.

SegFormer vs GPT-J/CodeGen are different model changes with no shared concrete code path.

SegFormer and LongT5 are separate implementations; this is only a similar output-handling migration.

Different models (SegFormer vs VisualBert); not the same bug or fix.

GPT-Neo and MPT are separate model refactors, not one duplicate change.

MPT vs MGP-STR are unrelated code paths.

GPT-2 and MPT are different models; shared decorator migration is too broad.

SegFormer vs MPT are not the same underlying fix.

RegNet and VisualBert are unrelated model changes.

GPT-2 and GPT-Neo are distinct model code paths; same refactor family is not a duplicate.

GPT-Neo vs GPT-2 are different implementations and should not be merged as duplicates.

VisualBert vs Flaubert/XLM are different model families and fixes.

MPNet and Flaubert/XLM are unrelated model-specific refactors.

VisualBert and LongT5 are different model code paths; only the refactor style matches.

Different model families and different output-tracing implementations.

SegFormer vs GPT-Neo are unrelated model changes.

RegNet and MPNet are separate model implementations.

MPT and ImageGPT are different models; this is only the same refactoring pattern.

TextNet vs Flaubert/XLM are different model-specific output handling refactors.

Summary: This cluster is a set of similar but model-specific refactors for standardized output tracing/capture_outputs. The items mostly share the same refactoring theme, but they are not duplicate fixes of the same concrete code path, so the soft edges should be rejected.


44066 is the best overall PR to represent this cluster because it is explicit about the target issue, covers the core code-path change, and most clearly matches the duplicate GPT-J/CodeGen follow-up PR.

44066 is the cleanest representative: it has the explicit #43979 linkage, a clear GPT-J/CodeGen output-tracing refactor, and is the strongest anchor for the duplicated GPT-J PR variant (44722).

Both are output-tracing refactors, but for different models (MPNet vs LongT5); same initiative, not the same concrete change.

RegNet and GPT-Neo are separate model implementations with different code paths; issue similarity alone is not enough.

Different model families (RegNet vs LongT5) and different refactor surfaces; not a duplicate change.

TextNet and LongT5 are unrelated implementations; both migrate to the same tracing pattern but are not the same bug/change.

RegNet vs MPT are distinct model code paths; this is only a shared refactor theme.

SqueezeBert and MPT are separate model-specific migrations, not one mergeable fix.

SqueezeBert and VisualBert touch different architectures and tracing code; not the same underlying change.

GPT-Neo and SpeechT5 are different models with different output-tracing plumbing; do not treat as duplicates.

RegNet and TextNet are separate model refactors, even if both reference the same broader initiative.

RegNet and SpeechT5 have different concrete code paths and should not be merged as one PR.

SqueezeBert and GPT-Neo are unrelated model implementations; same theme, not same fix.

MPT and SpeechT5 are different subsystems; too broad to call a duplicate.

CVT/FNet refactors and LongT5 refactors are separate model-specific changes.

CVT/FNet vs SegFormer are different model ports of the same tracing pattern, not duplicates.

SqueezeBert and DeBERTaV2 are distinct code paths; no evidence of the same concrete bug/change.

DeBERTaV2 and TextNet are unrelated model implementations; reject despite shared topic.

Same GPT-J/CodeGen output-tracing refactor on the same files and same issue target; this looks like a direct duplicate or rebased copy.

Both appear to implement the same GPT-J output-tracing change on the same code path, with overlapping files and shared issue target.

GPT-J and SpeechT5 are different models; shared issue target is not enough to merge them.

CVT/FNet and RegNet are separate model-specific tracing refactors, not the same fix.

CVT/FNet vs SpeechT5 are different code paths and architectures; not duplicates.

DeBERTaV2 and SpeechT5 are distinct model implementations; the overlap is only in refactor style.

DeBERTaV2 and VITS are different models and different tracing paths; do not merge as duplicates.

Summary: Most items are related but distinct model-by-model refactors for the shared output-tracing initiative. The only true duplicate pair here is the GPT-J/CodeGen PR line (44066 and 44722); the rest are separate model ports and should not be merged as duplicates.


PR #44129 is the best single representative of the cluster because it is issue-linked and clearly embodies the output-tracing migration pattern without being unusually narrow or incomplete.

PR #44129 is the strongest representative: it has an explicit issue target, a clear standardized output-capture refactor, and enough implementation detail to anchor the cluster theme.

Both are standardized-output refactors, but for different models (FocalNet vs ImageGPT) and different forward paths. Same theme, not the same change.

VisualBert and TextNet are separate model implementations with distinct output-capture plumbing; they are not the same concrete bug or patch.

MPNet and VisualBert both refactor tracing, but they modify different model internals and hook mappings. No evidence they could be merged as one PR.

These are different model-specific refactors with different affected files and output shapes; similarity is only at the framework pattern level.

RegNet and SqueezeBert are unrelated model code paths; both mention standardized output handling, but they are not the same underlying fix.

SqueezeBert and SpeechT5 touch different models and different tracing logic. Shared output-capture vocabulary is not enough to treat them as duplicates.

Summary: These PRs are all model-specific refactors to standardized output tracing/capture, but they touch different architectures and code paths. They are related by theme, not duplicates.


PR 44003 is the strongest single representative of this cluster’s pattern, but only as a thematic exemplar, not as a merge target for the rest.

PR 44003 is the best representative of the shared theme because it is a larger output-tracing refactor spanning two related Mamba variants and introducing the new tracing helpers, but it is still not a duplicate of the other model-specific refactors.

Different models and code paths: timm_backbone vs falcon_mamba/mamba. Same refactor style, not the same change.

UnivNet audio generation and Mamba state/output tracing are unrelated implementations.

UperNet segmentation wrapper vs Mamba model tracing; shared wording only.

Vision-text dual encoder and Mamba are different model families with different forward contracts.

Falcon/Mamba tracing refactor and CodeGen cache/output refactor affect different code paths.

Vision-text encoder-decoder and CodeGen are unrelated model architectures.

MobileNetV1 and UnivNet touch different modalities and output-tracing mechanics.

MobileNetV1 classification/backbone refactor is not the same bug as UperNet segmentation refactor.

MobileNetV1 and Depth Anything are separate vision models with different forward implementations.

MobileNetV1 output tracing is unrelated to VisionEncoderDecoder wrapper changes.

MobileNetV1 and SpeechEncoderDecoder are different domains and code paths.

Timm backbone tracing and UperNet tracing are distinct model-specific refactors.

Timm backbone and vision-text dual encoder do not share the same concrete implementation change.

VisionEncoderDecoder wrapper changes are unrelated to RWKV layer output tracing.

Timm backbone and UnivNet are unrelated models; same helper import is not enough.

RWKV and DPR are different architectures; these are separate refactors, not one fix.

Depth Anything and VisionEncoderDecoder are different code paths and different model wrappers.

Depth Anything and SpeechEncoderDecoder are unrelated model families.

Depth Anything and SuperPoint are separate vision models with different output schemas.

VisionEncoderDecoder and SpeechEncoderDecoder are analogous wrappers but not the same concrete change.

VisionEncoderDecoder wrapper refactor is unrelated to SuperPoint output tracing.

SpeechEncoderDecoder and SuperPoint are entirely different model paths.

UnivNet and UperNet share no concrete implementation path beyond the generic tracing theme.

Vision-text dual encoder and UnivNet are unrelated architectures and should not be merged as duplicates.

Summary: This cluster is a loose theme cluster of model-specific output-tracing refactors, not true duplicates. The PRs touch different model families and forward paths, so they should stay separate.


PR 44025 is the broadest self-contained refactor in the set (it touches two related Depth Anything files), but it is still model-specific and not a duplicate representative for the others.

Both are output-tracing refactors, but one is timm_backbone and the other is upernet; different model implementations, different forward signatures, no shared concrete bug.

Both mention output tracing, but timm_backbone and rwkv are unrelated code paths and fixes; too broad to be one mergeable PR.

upernet vs rwkv are distinct model-specific refactors; same theme, not the same underlying change.

timm_backbone and codegen touch unrelated forward/capture logic in different models; not the same bug or change.

univnet and codegen are separate model refactors with different call signatures and outputs; only the umbrella theme matches.

upernet and codegen are unrelated model paths; this is not a single concrete fix.

Depth Anything and RWKV are different models with different output-tracing implementations; too dissimilar to merge as duplicates.

Depth Anything vs DPR are separate model-specific forward refactors, not one underlying issue.

vision_encoder_decoder and DPR are different architectures and code paths; same pattern, not same change.

speech_encoder_decoder and rwkv are unrelated implementations; no shared concrete defect or patch.

speech_encoder_decoder and DPR are distinct model refactors, so they should not be deduped.

superpoint and rwkv affect different modules and output shapes; same refactor motif only.

superpoint and DPR are unrelated model code paths; not the same bug or change.

univnet and Depth Anything are separate model implementations; this is a shared refactor style, not a duplicate fix.

univnet vs vision_encoder_decoder are different model-specific output-tracing changes and could not plausibly be one PR.

upernet and Depth Anything are related only by the generic refactor theme; different files, different model behavior.

timm_backbone and Depth Anything are separate model-specific changes, not the same underlying issue.

timm_backbone vs vision_encoder_decoder is too broad; these are independent refactors in different subsystems.

Summary: These are thematically similar refactors around output tracing/can_return_tuple, but they target different model code paths and files, so they are not duplicates of the same underlying bug/change. No single canonical issue exists in the set.


PR #45075 is the strongest representative of the set because it is the most complete standalone model addition and includes both implementation and conversion tooling; however, it is still not a duplicate of the others.

No single canonical PR: the three PRs add different models with different configs, processors, and model code paths.

Different underlying changes: PenguinVL is a vision-language model, while Voxtral TTS is a text-to-speech model. Shared auto-registration/docs files are generic scaffolding, not the same bug or fix.

Both add new model integrations, but for unrelated models with different architectures and code paths (PenguinVL vs DeepSeek-OCR-2). Overlap is only in shared framework wiring.

Distinct model families and concrete implementations: OCR vs TTS. They touch some of the same registry/docs files, but they do not fix the same issue or represent one mergeable change.

Summary: These are three distinct model-addition PRs that overlap on Transformers scaffolding, but each implements a different model family (PenguinVL, DeepSeek-OCR-2, Voxtral TTS). They are not duplicates and should not be merged as one change.


#44979 is the best cluster representative because it captures the foundational fusion API, while #45363 is a specific application of that idea rather than the same patch.

#44979 is the broader, earlier core API proposal that defines the fusion abstraction; #45363 is a narrower integration built around KernelConfig and specific fused modules.

Do not merge: one PR adds a generic module-fusion API and tests, the other wires a concrete KernelConfig n-to-1 fusion path plus an example. Same broad subsystem, but not the same code-path fix or mergeable into one PR as a duplicate.

Summary: These PRs are related by the general idea of model/module fusion, but they target different layers: #44979 introduces a generic Module Fusion API, while #45363 adds a specific n-to-1 KernelConfig-based fusion integration and example. They are conceptually adjacent, not the same underlying change.


`45317` best represents the cluster because it contains the concrete fix plus validation, while `45086` is a smaller precursor/subset of the same change.

`45317` is the stronger canonical PR: same code fix as `45086`, clearer title, and it adds a test file, making it the more complete patch.

Same underlying bug and same code-path fix in the same file; `45317` appears to extend `45086` with tests rather than introduce a different change.

Summary: Both PRs address the same Mistral pre-tokenizer AttributeError in `tokenization_utils_tokenizers.py`; `45317` is the fuller follow-up with tests and the same fix path.


PR #45332 is the best representative of the cluster since it subsumes the config-only work in #45333 and extends it into actual heterogeneous model support.

PR #45332 is the better canonical PR because it is the broader end-to-end feature implementation, covering both per-layer config handling and the downstream modeling/cache changes that use it.

Reject: #45333 appears to implement the per-layer configuration layer, while #45332 adds the downstream heterogeneous modeling/cache support that consumes it. They are complementary, not duplicate fixes, and would not be the same single PR.

Summary: These are related but distinct PRs: one adds heterogeneous per-layer configuration plumbing, and the other builds on that to add heterogeneous model/runtime support. They share helper/config files, but they are not the same concrete change or bug fix.


PR #45425 is the best fit for the cluster since it is the more concrete, self-contained typing change; PR #45415 is broader and touches many unrelated files, so it is less suitable as the canonical representative.

PR #45425 is the better representative because it targets a specific typing fix centered on modeling_utils/check_types, rather than a broad multi-file typing sweep.

Both are typing-related, but they do not appear to fix the same concrete code-path problem. #45415 is a broad typing enablement across many files, while #45425 is a focused modeling_utils/type-checking tweak; shared filenames are incidental and they would not naturally merge into one PR.

Summary: Two typing-related PRs, but they cover different scopes: one is a broad repo-wide typing sweep, the other is a focused modeling_utils typing/check-types update. They are not the same underlying change.