MIC fleet candidates

Transformers CI failures on main, 4 weeks to 2026-10-27 · models not yet covered by the MIC fleet

Twelve uncovered models are solid candidates. bridgetower, grounding_dino and perceiver give the clearest value; pvt and lw_detr are the cheapest.

A good candidate has many failing tests on main and failures a MIC catches: load, config and processor errors, forward crashes, dtype or device bugs, numeric mismatches in logits or loss, and training or gradient bugs.

Most failures are long-standing: every top candidate except perceiver was already failing 30 to 90 days ago. A MIC recorded today would not have caught them as they appeared; it blocks at creation until the bug is fixed, or guards against the next regression once someone reviews which outputs are correct. Perceiver is the exception: a real regression that started 30 to 60 days ago and cleared on 10-20.

Strong candidates

"Failing tests" have at least one failure in the last 28 days; "Failures" sums failing runs per test over those days (the GPU model job runs daily, so 28 means every day).

#Model typeFailing testsFailures (28 d)What breaksMIC catches it?Suggested checkpoint
1bridgetower5119Processor won't load: "Unrecognized image processor" (4 integration tests)Yes — loading is the first MIC step, so the MIC can't be built until it's fixedBridgeTower/bridgetower-base
2grounding_dino4104Detection logits and loss mismatch (expected loss 1.1147, got 1.0834)Yes — forward logits and loss; mm_grounding_dino (3 tests, 78 failures) could be a siblingIDEA-Research/grounding-dino-tiny
3perceiver8168"Expected all tensors to be on the same device" in cat; real regression, now clearedYes — on the GPU checkpoint run (not the CPU fixture)deepmind/language-perceiver
4timesfm9252fp16 overflow in 8 eager-vs-SDPA tests, one root causePartly — only if the contract runs an fp16 forwardgoogle/timesfm-2.0-500m-pytorch
5minicpm37124KeyError: 'factor' in the rope config (2 tests); the rest are FA2 or compileYes for the config bug — pin the native class, not the repo's remote codeopenbmb/MiniCPM3-4B
6janus256Processor and model disagree: 0 image tokens vs 1,179,648 image featuresYesdeepseek-community/Janus-Pro-1B
7blt256BltConfig has no num_hidden_layersYes — checkpoint is in a personal namespaceitazap/blt-1b-hf
8luke364Base and large logits mismatch; tokenizer idsYesstudio-ousia/luke-base
9pvt256Classification logits off by 0.074Yes — cheap (13M parameters)Zetatech/pvt-tiny-224
10lw_detr240Detection head mismatch (tiny and xlarge)Yes — cheap (13M); personal namespacestevenbucaille/lwdetr_tiny_30e_objects365
11oneformer244Segmentation logits mismatchYesshi-labs/oneformer_ade20k_swin_tiny
12qwen3_vl_moe10256Weight conversion fails at load (8 tests, one root cause)Partly — real checkpoint is 31B: fixture only, saved in the Hub layout to reach the bugQwen/Qwen3-VL-30B-A3B-Instruct

Weaker candidates

MIC-catchable failures, but each has a catch: a family the fleet already covers, mostly generation-text drift, or a real checkpoint too big for a 24 GB GPU.

Model typeFailing testsFailures (28 d)What breaksCatch
smollm32563B logits mismatch; export static-cache textLlama-family models are already well covered
kosmos2384interpolate_pos_encoding and captioning logitsPartly generation text
mimi256Audio codec outputs differOnly if the probe covers audio codes
diffusion_gemma6166Minified-model forward mismatch (118 of 120 values)Real checkpoint is 26B: fixture-only MIC
recurrent_gemma——2B generate/sample text; a non-contiguous bias crashGated checkpoint; mostly generation text
seamless_m4t3—Processor and generation errorsMostly generation
mixtral——Only the tiny test model's logits failReal model is 47B
qwen2_moe——Logits mismatchReal model is 14.3B, about 29 GB in bf16
univnet2—Two scalar mismatchesCheckpoint is in a personal namespace
blip_2, rag, bloom, plbart, encoder_decoder——Mostly greedy or beam-search output diffsGeneration text, which a MIC doesn't probe

Excluded

Method

Caveats