deepspeedai / deepspeedai/DeepSpeed
[REQUEST] detect opbuilder list at launch time
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 43.1k
- Forks
- 5k
- Avg merge
- 4d 15h
- Merged PRs (30d)
- 112
Description
Is your feature request related to a problem? Please describe.
Currently, DeepSpeed detects opbuilder list at installation time and put all installed ops inside git_version_info_installed.py. This often works except in situation that there is HW change between installation and launch which require change of DeepSpeed Accelerator. A typical situation is when cluster user install DeepSpeed on login node without GPU, then launch DeepSpeed on compute node with GPU.
Currently, this situation is mitigated by using Torch extension as an indicator of which Accelerator to be used. When CPU version of Intel Extension for PyTorch is installed in the environment, DeepSpeed would deem its for CPU no matter whether a GPU device is installed on the system. Otherwise DeepSpeed would decide which Accelerator to use depending on extension installation. If no extension is installed (stock PyTorch), DeepSpeed would assume install and launch for CUDA_Accelerator.
Yet this is not ideal solution, this complicates DeepSpeed deploy and execution (i.e. must install PyTorch extension before install DeepSpeed).
Describe the solution you'd like
Ideally, DeepSpeed should adapt to HW change and act properly. Accelerator should be tracked in git_version_info_installed.py and updated up on HW change. A simple (and probably sufficient) solution would be discard existing info upon HW (Accelerator) change and regenerate them according to current Accelerator being used.
This change could be combine with Accelerator selection logic in real_accelerator.py that when using stock PyTorch (no extension), decide whether to use CPU Accelerator depending on whether CUDA device is used. This could possibly be an alternative to PR#5084 which allows a single CPU Accelerator serve both stock PyTorch and Intel Extension for PyTorch.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading git_version_info_installed.py and real_accelerator.py to understand how the installed opbuilder list and accelerator selection are determined. Compare the proposed behavior with PR#5084 and trace the installation and launch paths. Done means accelerator changes between installation and launch are detected and the opbuilder information is regenerated for the current hardware.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, pytorch
- Domain
- devops, machine-learning
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100