Enhance get_balanced_memory to ensure adequate GPU allocation for small models with large layers - #47426
Enhance get_balanced_memory to ensure adequate GPU allocation for small models with large layers#47426xin3he wants to merge 2 commits into
get_balanced_memory to ensure adequate GPU allocation for small models with large layers#47426Conversation
…mall models with large layers; add regression test for allocation correctness.
CI recapDashboard: View test results in Grafana
|
|
cc @SunMarc for accelerate |
SunMarc
left a comment
There was a problem hiding this comment.
Thanks for tacking this ! Left a comment.
| if modules_list: | ||
| max_layer_size, _ = get_max_layer_size(modules_list, module_sizes, no_split_module_classes) |
There was a problem hiding this comment.
We should get the max_layer_size only from the leaves as the leaves should include the embeddings. I feel that we are taking into account modules that shouldn't be counted. For the no_split_module, it will still be accounted in the buffer above so that's fine to not deal with this case. Also we should only modify the GPU0 memory for this case if possible. In the last GPU, we leave enough space for the rest.
… by ensuring minimum memory for the first GPU when not using low zero memory. Signed-off-by: Xin He <xin3.he@intel.com>
What does this PR do?
Fixes intel/auto-round#1889
For W2A16 facebook/opt-125m, we have below param size:
When there are two GPUs, the current logic will split the param size by
//2and the embedding is dispatched on CUDA:1max_memory = {0: 97288832, 1: 84647280640}lm_eval requires embedding on cuda:0 to match the input device.
Code Agent Policy
The Transformers repo is currently being overwhelmed by a large number of PRs and issue comments written by
code agents. These often are low-quality, or fix extremely minor issues that occur rarely or never in practice.
As a result, we're instituting a rule that first-time contributors should not use code agents to submit PRs or issues.
We'd also ask autonomous "OpenClaw"-like agents not to open any PRs or issues.
Issues/PRs from first-time contributors that violate this rule will probably just be closed without review, and we
might block you, especially if you open more than one or appear to be deliberately ignoring this. We especially do not
want new contributors to jump in on random issues to contribute an agent-written fix. This creates lots of noise
for reviewers and other users and will almost certainly get you blocked.
For more information, please read
CONTRIBUTING.md.Before submitting
Pull Request checks?
to it if that's the case.
Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.