change version
Author: ArthurZucker
Pull request: yes

# What does this PR do?
Try to change cached version

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

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 

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

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

@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`? 

@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).




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).

@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](https://github.com/huggingface/transformers/issues/28530) which later triggered [errors in a different PR](https://github.com/huggingface/transformers/pull/28312).

> 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

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)

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.

Thanks both 🤗