Transformers Uplift Fix
You are fixing transformers compatibility issues that surfaced after uplifting
transformers to TARGET_VERSION in tt-xla.
Instructions
- Read the
FAILURES file, then read the scope-specific instructions
for the SCOPE env var in the Scope section below.
- Check the transformers changelog between the
CURRENT_VERSION and
TARGET_VERSION env vars to help diagnose root causes:
https://github.com/huggingface/transformers/releases.
- Apply fixes at the SOURCE level.
- When you identify a root cause, fix it everywhere it occurs in the
repo — not just where the failure surfaced. Grep the repo for other
files that need the same change and update them in the same pass.
- If a failure cannot be fixed without violating a Rule, leave it alone
and call it out clearly in your final message. The orchestrator
surfaces unfixed failures in the eventual PR — silent half-fixes
are worse than a clear "couldn't fix this".
- Before exiting, write a summary of what you did to
.github/transformers-uplift/fix-summary.md using the template in
Output format below. The orchestrator uses this file as the
commit message body for your edits.
Rules
- Under
third_party/ (these are external submodules), ONLY apply fixes
to third_party/tt_forge_models.
- Do NOT touch
venv/requirements-dev.txt. The transformers pin is
already at the target version and the orchestrator owns that file.
- Do NOT
git add, commit, push, branch, or open PRs. Leave the working
tree dirty with your edits; the orchestrator owns every git step.
- No monkey-patching of
transformers. No if version < X shims for
older versions. The whole repo is moving to TARGET_VERSION and
staying there — backward compatibility is not a goal.
- No drive-by refactors. No "clean up" of unrelated code. Ignore
warnings — focus only on the entries in
FAILURES.
Scope: api-check
The caller ran pytest --collect-only on the model test suite. Failures
are IMPORT-TIME errors raised when pytest tried to import a test module
(which in turn imports its loader, which in turn imports transformers).
Additional Instructions:
- Find the failing import (pytest's collection error includes the file
and line — read it).
- Check
venv/lib/python*/site-packages/transformers/ to find if
the symbol has been moved, removed or replaced. grep -r 'class Renamed' venv/.../transformers/
is fast.
- Update the import in the loader. Often it's a one-line change.
Scope: model-test-uplifts
The caller ran model tests on real TT hardware via call-test-uplift.yml.
Additional Instructions:
- Fixes can land in tt_forge_models loaders OR in tt-xla test
infrastructure (
tests/torch/models/, tests/infra/,
examples/pytorch/llama.py). Don't assume one location — read the
failing file path and edit there.
- Check for removed kwargs and delete them. Add new required ones using the documented
defaults from the transformers changelog.
- If a test fails purely on
pcc < required_pcc (no exception, no
shape mismatch), don't fight it — that's genuine numerical drift.
Lower required_pcc in the test_config YAML or set
assert_pcc: false, and call it out for human review.
- For changed return shapes or renamed attributes (
Cache.key_cache
→ keys, outputs.vision_model_output access patterns, etc.),
update the call site to the new shape. Don't paper over it with
if isinstance(...) — the new shape is the only one that matters now.
- Cache and attention utilities churn every uplift. Expect
breakage in
transformers.cache_utils and in the attention API —
check those first when failures look unfamiliar.
- Baseline comparison. The orchestrator writes
baseline_failures.txt
alongside the failure context — it lists the failures the last main
nightly observed on the same matrix. For each TEST: entry in the
current failure context, check whether the same node id appears in
baseline_failures.txt. If it does AND the failure message/traceback
describes the same root cause, the test was already broken on main —
list it under ## Skipped in fix-summary.md with a one-line
"pre-existing on baseline" note and DO NOT attempt to fix it. If the
node id appears in both files but the root cause differs, treat it as
uplift-induced and fix normally. Tests absent from the baseline are
uplift-induced by definition.
Scope: model-perf-uplift
The caller ran the perf benchmark sweep via call-perf-uplift.yml. There are three
types of issues we want to focus on:
- Broken benchmark test infrastructure.
- Performance (samples/sec) regression beyond the configured threshold.
- Missing expected fused TTNN ops.
Additional Instructions:
- Focus on issues related to the transformers uplift.
- Benchmark infrastructure broken by transformers API changes.
The benchmark code itself raised an exception (TypeError, AttributeError,
ImportError, etc.) because of changes in transformers that benchmark infra relies
on. The failing file lives under
tests/benchmark/ (e.g.
tests/benchmark/benchmarks/llm_benchmark.py,
tests/benchmark/llm_utils/decode_utils.py, etc.).
- Performance Regression DO NOT attempt blind fixes. Only act if
you can attribute the regression to a specific transformers diff. Otherwise list it
under Skipped for human review and add a one-line hypothesis to the entry's bullet
under ## Skipped in fix-summary.md
- Missing Fusion read the IR dump path from the failure, grep for the
expected op, then check transformers diffs for the op pattern that
produced it. Fix by adapting the model wrapper in tt-xla/tt-forge-models
to restore the pattern. Skip if the fusion regression has no clear
source-side cause.
- Apply the same approach as
model-test-uplifts — similar churn patterns
(Cache API, attention API, return-shape renames, etc.).
Output format
Before exiting, write .github/transformers-uplift/fix-summary.md with
this exact structure. Keep the subject line under 70 chars; keep each
bullet to one line. The orchestrator commits your edits using this file
as the commit body.
transformers uplift: <scope> fixes — <one-line subject>
## Fixed
- <file/path>: <what changed and why>
- <file/path>: <what changed and why>
## Skipped (left for human review)
- <test or file>: <reason — Rule violation, ambiguity, PCC drift, etc.>
## Stats
- Failures input: <N>
- Fixed: <M>
- Skipped: <K>
Notes:
- The first line is the commit subject — keep it short and specific
(
"transformers uplift: model-test-uplifts fixes — Cache.key_cache → keys",
not "applied fixes").
- If there's nothing under Skipped, omit the section entirely.
- If you exit early (timeout, blocked by a Rule on every failure),
still write the file with whatever you did. The orchestrator falls
back to a generic commit message only when the file is missing.
1---2name: transformers-uplift-fix3description: Fix transformers compatibility regressions in tt-xla and tt-forge-models after the pinned version was bumped. Called by the transformers-uplift CI orchestrator with a scope (api-check, model-test-uplifts, model-perf-uplift) and a captured failure context. Edits source-level only — no monkey-patching, no shims, no git operations.4---56# Transformers Uplift Fix78You are fixing transformers compatibility issues that surfaced after uplifting9`transformers` to `TARGET_VERSION` in tt-xla.1011## Instructions12131. Read the `FAILURES` file, then read the scope-specific instructions14 for the `SCOPE` env var in the **Scope** section below.152. Check the transformers changelog between the `CURRENT_VERSION` and16 `TARGET_VERSION` env vars to help diagnose root causes:17 `https://github.com/huggingface/transformers/releases`.183. Apply fixes at the SOURCE level.194. When you identify a root cause, fix it everywhere it occurs in the20 repo — not just where the failure surfaced. Grep the repo for other21 files that need the same change and update them in the same pass.225. If a failure cannot be fixed without violating a Rule, leave it alone23 and call it out clearly in your final message. The orchestrator24 surfaces unfixed failures in the eventual PR — silent half-fixes25 are worse than a clear "couldn't fix this".266. Before exiting, write a summary of what you did to27 `.github/transformers-uplift/fix-summary.md` using the template in28 **Output format** below. The orchestrator uses this file as the29 commit message body for your edits.3031## Rules3233- Under `third_party/` (these are external submodules), ONLY apply fixes34 to `third_party/tt_forge_models`.35- Do NOT touch `venv/requirements-dev.txt`. The transformers pin is36 already at the target version and the orchestrator owns that file.37- Do NOT `git add`, commit, push, branch, or open PRs. Leave the working38 tree dirty with your edits; the orchestrator owns every git step.39- No monkey-patching of `transformers`. No `if version < X` shims for40 older versions. The whole repo is moving to `TARGET_VERSION` and41 staying there — backward compatibility is not a goal.42- No drive-by refactors. No "clean up" of unrelated code. Ignore43 warnings — focus only on the entries in `FAILURES`.4445## Scope: api-check4647The caller ran `pytest --collect-only` on the model test suite. Failures48are IMPORT-TIME errors raised when pytest tried to import a test module49(which in turn imports its loader, which in turn imports `transformers`).5051Additional Instructions:52531. Find the failing import (pytest's collection error includes the file54 and line — read it).552. Check `venv/lib/python*/site-packages/transformers/` to find if56 the symbol has been moved, removed or replaced. `grep -r 'class Renamed' venv/.../transformers/`57 is fast.583. Update the import in the loader. Often it's a one-line change.5960## Scope: model-test-uplifts6162The caller ran model tests on real TT hardware via `call-test-uplift.yml`.6364Additional Instructions:65661. Fixes can land in tt_forge_models loaders OR in tt-xla test67 infrastructure (`tests/torch/models/`, `tests/infra/`,68 `examples/pytorch/llama.py`). Don't assume one location — read the69 failing file path and edit there.702. Check for removed kwargs and delete them. Add new required ones using the documented71 defaults from the transformers changelog.723. If a test fails purely on `pcc < required_pcc` (no exception, no73 shape mismatch), don't fight it — that's genuine numerical drift.74 Lower `required_pcc` in the test_config YAML or set75 `assert_pcc: false`, and call it out for human review.764. For changed return shapes or renamed attributes (`Cache.key_cache`77 → `keys`, `outputs.vision_model_output` access patterns, etc.),78 update the call site to the new shape. Don't paper over it with79 `if isinstance(...)` — the new shape is the only one that matters now.805. **Cache and attention utilities churn every uplift.** Expect81 breakage in `transformers.cache_utils` and in the attention API —82 check those first when failures look unfamiliar.836. **Baseline comparison.** The orchestrator writes `baseline_failures.txt`84 alongside the failure context — it lists the failures the last main85 nightly observed on the same matrix. For each `TEST:` entry in the86 current failure context, check whether the same node id appears in87 `baseline_failures.txt`. If it does AND the failure message/traceback88 describes the same root cause, the test was already broken on main —89 list it under `## Skipped` in `fix-summary.md` with a one-line90 "pre-existing on baseline" note and DO NOT attempt to fix it. If the91 node id appears in both files but the root cause differs, treat it as92 uplift-induced and fix normally. Tests absent from the baseline are93 uplift-induced by definition.9495## Scope: model-perf-uplift9697The caller ran the perf benchmark sweep via `call-perf-uplift.yml`. There are three98types of issues we want to focus on:991. Broken benchmark test infrastructure.1002. Performance (samples/sec) regression beyond the configured threshold.1013. Missing expected fused TTNN ops.102103Additional Instructions:104105- Focus on issues related to the transformers uplift.106- **Benchmark infrastructure broken by transformers API changes.**107 The benchmark code itself raised an exception (TypeError, AttributeError,108 ImportError, etc.) because of changes in transformers that benchmark infra relies109 on. The failing file lives under `tests/benchmark/` (e.g.110 `tests/benchmark/benchmarks/llm_benchmark.py`,111 `tests/benchmark/llm_utils/decode_utils.py`, etc.).112- **Performance Regression** DO NOT attempt blind fixes. Only act if113 you can attribute the regression to a specific transformers diff. Otherwise list it114 under Skipped for human review and add a one-line hypothesis to the entry's bullet115 under ## Skipped in fix-summary.md116- **Missing Fusion** read the IR dump path from the failure, grep for the117 expected op, then check transformers diffs for the op pattern that118 produced it. Fix by adapting the model wrapper in tt-xla/tt-forge-models119 to restore the pattern. Skip if the fusion regression has no clear120 source-side cause.121- Apply the same approach as `model-test-uplifts` — similar churn patterns122 (Cache API, attention API, return-shape renames, etc.).123124## Output format125126Before exiting, write `.github/transformers-uplift/fix-summary.md` with127this exact structure. Keep the subject line under 70 chars; keep each128bullet to one line. The orchestrator commits your edits using this file129as the commit body.130131```markdown132transformers uplift: <scope> fixes — <one-line subject>133134## Fixed135- <file/path>: <what changed and why>136- <file/path>: <what changed and why>137138## Skipped (left for human review)139- <test or file>: <reason — Rule violation, ambiguity, PCC drift, etc.>140141## Stats142- Failures input: <N>143- Fixed: <M>144- Skipped: <K>145```146147Notes:148- The first line is the commit subject — keep it short and specific149 (`"transformers uplift: model-test-uplifts fixes — Cache.key_cache → keys"`,150 not `"applied fixes"`).151- If there's nothing under **Skipped**, omit the section entirely.152- If you exit early (timeout, blocked by a Rule on every failure),153 still write the file with whatever you did. The orchestrator falls154 back to a generic commit message only when the file is missing.