change version

[ArthurZucker]

What does this PR do?

Try to change cached version

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[ydshieh]

We still have failing for test_save_load_low_cpu_mem_usage which are already on main.

On this PR, the accelerate is 0.27.2 and on main, the CI uses accelerate main. So I don't think the change of this PR (on the accelerate part address the issue)

@amyeroberts mentions she has already some work on solving test_save_load_low_cpu_mem_usage .

@ArthurZucker mentions he don't want to use accelerate main on our CI.

So let's keep this PR as it is despite there is test_save_load_low_cpu_mem_usage failing, if @amyeroberts agrees.

cc @muellerzr

[ydshieh]

p.s. test_beam_search_low_memory also happens for which I don't see on main CI.

[amyeroberts]

@ydshieh Do we know the original reasons for using accelerate main rather than the stable release in the CI?

[amyeroberts]

@ydshieh Just to confirm - changing the accelerate version here would mean that test_save_load_low_cpu_mem_usage starts to fail despite the fixes on main. Or that there's still failures on main?

[ydshieh]

@amyeroberts I didn't know the fix of test_save_load_low_cpu_mem_usage is already on main.

However, that fix is merged 4 days ago, right? But last night's run

https://app.circleci.com/pipelines/github/huggingface/transformers/84737/workflows/c2fc5312-c0bf-4620-b523-74c1a99b0d1b/jobs/1096153/tests

having those failures.

So it's not this PR introducing this again. (i.e. those failures are still on main after the fix).

[ydshieh]

I propose to revert the changes regarding accelerate in this PR (as it didn't fix the issue).

If eventually everyone agrees with @ArthurZucker, we can open another PR to use released accelerate for CI - but this is not the scope of this PR (and I don't want to mix the 2 different stuff in a single PR).

[amyeroberts]

@ydshieh OK, what I suggest for the moment is skipping all the models where this fails at the moment.

Separate from this PR, I think there's a issue with our test fetcher. There's been quite a few PRs recently where the whole CI has been green and then after merging into main, another PR which touches related (but different) code suddenly starts to have CI failures. These tests are one example. Two other cases would be:

• Failures coming from the static cache PR
• Failures in coming from processing fix for detr which later triggered errors in a different PR.

[amyeroberts]

If eventually everyone agrees with @ArthurZucker, we can open another PR to use released accelerate for CI - but this is not the scope of this PR (and I don't want to mix the 2 different stuff in a single PR).

I'm pro splitting and pro having stable accelerate for PR's CI and main accelerate on a nightly run

[ydshieh]

Will take a look over the test fetcher. But remember that test fetcher have some design decision (by great @sgugger ) to balance the coverage as well as the speed of CI, so the situation described is not surprising (at least to me since I faced it a few times already and some fix were already done).

(One related PR but not exact is #28816)

[ydshieh]

Regarding skipping all the models where this fails at the moment, I will leave it to anyone that is so motivated to beat me, otherwise I can do it in about 9 hours.

For now, I will just wait the CI of this PR and merge it.

[ydshieh]

LGTM thanks

[ArthurZucker]

Thanks both 🤗