Fix Gemma2IntegrationTest#38492
Conversation
|
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. |
| return unittest.skipUnless(torch_device == "cuda", "test requires CUDA")(test_case) | ||
|
|
||
|
|
||
| def require_large_cpu_ram(test_case, memory: float = 80): |
There was a problem hiding this comment.
Our single-gpu runner has 60G CPU RAM.
Currently, test_export_hybrid_cache is killing pytest process.
There was a problem hiding this comment.
No particular reason: I set a value so it won't run on our single gpu runner (T4/A10). I don't try to figure out how much RAM this test really requires. And I don't want to set 60 neither as the RAM on our single gpu runner it is not exactly 60 G
| if attn_implementation == "flash_attention_2" and not is_flash_attn_2_available(): | ||
| self.skipTest("FlashAttention2 is required for this test.") |
There was a problem hiding this comment.
Not gemma2, but just update here anyway.
This test is @parameterized.expand so skip inside the body if flash attn is not installed.
| self.assertEqual(output_text, EXPECTED_TEXTS) | ||
|
|
||
| @tooslow | ||
| @require_torch_large_accelerator |
There was a problem hiding this comment.
T4 can't run 9b, but A10 can
There was a problem hiding this comment.
Hmm, do you know what the previous integration tests used then? I guess the A100s?
Makes sense that the expected generation changes then.
There was a problem hiding this comment.
It's always the same test. While with @tooslow, it's never run at all. Now it will run on A10 but not T4.
There was a problem hiding this comment.
Oh you mean the previous expected values? I have no idea, it depends on the contributor or the team members who wrote the tests. It's very likely not A10 however.
|
|
||
| @slow | ||
| @require_read_token | ||
| @require_large_cpu_ram |
There was a problem hiding this comment.
@guangy10 if you can check why this test take so much CPU RAM ?
There was a problem hiding this comment.
@ydshieh Hmm interesting if it requires large CPU RAM as it essentially same as the Static one since only the global cache is exposed to export. BTW how do you notice the RAM usage surge? I'd like to understand if there is any utils/tools/ci that would help debug this kind of issue?
There was a problem hiding this comment.
BTW how do you notice the RAM usage surge?
I just check the CI job run page and find killed and the process exit 😅
There was a problem hiding this comment.
There was a problem hiding this comment.
as it essentially same as the Static one since only the global cache is exposed to export
BTW, maybe the other test is just taking a blit less RAM under 60GB and we get lucky ...
|
@vasqu If you want to take a look too as Cyrilvallez if off. No worry if not. |
vasqu
left a comment
There was a problem hiding this comment.
LGTM, just some nits / questions.
Just curious to know why flex attention fails but it might've also relied on some old version which didnt use the block mask. In general, generation with flex attn needs a rework :D
| return unittest.skipUnless(torch_device == "cuda", "test requires CUDA")(test_case) | ||
|
|
||
|
|
||
| def require_large_cpu_ram(test_case, memory: float = 80): |
| if attn_implementation == "flash_attention_2" and not is_flash_attn_2_available(): | ||
| self.skipTest("FlashAttention2 is required for this test.") |
| self.assertEqual(output_text, EXPECTED_TEXTS) | ||
|
|
||
| @tooslow | ||
| @require_torch_large_accelerator |
There was a problem hiding this comment.
Hmm, do you know what the previous integration tests used then? I guess the A100s?
Makes sense that the expected generation changes then.
I have to say I don't know much about this (and in general flex failing tests ). Sometimes, some flex tests fail on torch 2.6 but works on torch 2.7 (on T4), but works on A10 even with torch 2.6, see for example https://huggingface.slack.com/archives/C06LR9PQA00/p1748515989352219 And maybe let me ping you for |
| EXPECTED_BATCH_TEXTS = Expectations( | ||
| { | ||
| ("cuda", 8): [ | ||
| "Hello I am doing a project on the 1960s and I am trying to find out what the average", | ||
| "Hi today I'm going to be talking about the 10 most powerful characters in the Naruto series.", | ||
| ] | ||
| } | ||
| ) | ||
| EXPECTED_BATCH_TEXT = EXPECTED_BATCH_TEXTS.get_expectation() |
There was a problem hiding this comment.
@yao-matrix I am trying to use Expectations class when I update some updates. If you find something is broken on XPU because I miss some details, let me know.
|
Hey! Just seeing this now that I'm back from vacation! The export test has absolutely no reason to use that much cpu memory... I mean, I don't know the inner workings of |
|
This is the kind of stuff that's not super good to skip without knowing what's happening - maybe a matter of retaining a lot of different torch graphs on cpu as well? Not sure if the compile/export graphs are being cleaned up properly between tests etc |
|
@Cyrilvallez On daily CI, there is only one pytest process, i.e. we are not using
I agree, but IMO, it would be good for @guangy10 to investigate this to see something like
etc. If we keep this test, other tests are not reported as the job is killed, which is not good neither for maintenance. (if it fails but not affecting other tests, I might be happy to keep running though) |
|
BTW, it still run on our mulit-gpu CI runners (which have more CPU RAM) |
What does this PR do?
Currently on singe-gpu T4 runner,
test_export_hybrid_cacheuse more than 60G CPU RAM memory and the process is killed, so we don't receive any report.This PR skips this tests by introducing a new
require_large_cpu_ram. I also update some tests to make them pass and to avoid some OOM.On T4: only 2 flex attn. related tests are failing.
On A10: only 1 flex attn. related test is failing.