Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Unused params lead to "still have inflight params" error #4094

Open
tiwargau opened this issue Aug 4, 2023 · 11 comments
Open

[BUG] Unused params lead to "still have inflight params" error #4094

tiwargau opened this issue Aug 4, 2023 · 11 comments
Assignees
Labels
bug Something isn't working inference

Comments

@tiwargau
Copy link

tiwargau commented Aug 4, 2023

Bug description
Context: Running inference on a multi-modal LLM , at each decoding step parts of the network are used and depends on the input modality at each step. In my second step, deepspeed goes ahead and fetches part of the network that ends up not being used. The code does assume that this can happen and correctly invalidates the trace. However, for the params that were prefetched but never used, at the end of the step, these are detected as in-flight and result in the RuntimeError(f"still have inflight params").

To Reproduce
My setup is a bit involved. I am thinking it is clear from the description what the issue is. However, if the team feels like they can benefit from a simple reproduction, I can work on creating one. Please let me know.

Expected behavior
I would have expected that when we notice the order of params isn't the same as before, it would be reasonable to also not demand that all the parameters be used. Right now, we tolerate different ordering but require that all the params previously used (hence prefetched) need to be used at some point.

ds_report output

Setting ds_accelerator to cuda (auto detect)--------------------------------------------------DeepSpeed C++/CUDA extension op report
--------------------------------------------------
NOTE: Ops not installed will be just-in-time (JIT) compiled at      runtime if needed. Op compatibility means that your system
      meet the required dependencies to JIT install the op.
--------------------------------------------------
JIT compiled ops requires ninja
ninja .................. [OKAY]
--------------------------------------------------
op name ................ installed .. compatible
--------------------------------------------------
 [WARNING]  async_io requires the dev libaio .so object and headers but these were not found.
 [WARNING]  async_io: please install the libaio-devel package with yum
 [WARNING]  If libaio is already installed (perhaps from source), try setting the CFLAGS and LDFLAGS environment variables to where it can be found.
async_io ............... [NO] ....... [NO]
cpu_adagrad ............ [NO] ....... [OKAY]
cpu_adam ............... [NO] ....... [OKAY]
fused_adam ............. [NO] ....... [OKAY]fused_lamb ............. [NO] ....... [OKAY]
quantizer .............. [NO] ....... [OKAY]
random_ltd ............. [NO] ....... [OKAY]
 [WARNING]  please install triton==1.0.0 if you want to use sparse attention
sparse_attn ............ [NO] ....... [NO]
spatial_inference ...... [NO] ....... [OKAY]
transformer ............ [NO] ....... [OKAY]
stochastic_transformer . [NO] ....... [OKAY]
transformer_inference .. [NO] ....... [OKAY]
--------------------------------------------------
No CUDA runtime is found, using CUDA_HOME='/usr/local/cuda-11.6'
DeepSpeed general environment info:
torch install path ............... ['/home/ec2-user/anaconda3/envs/pytorch_p39/lib/python3.9/site-packages/torch']
torch version .................... 1.13.0
deepspeed install path ........... ['/home/ec2-user/anaconda3/envs/pytorch_p39/lib/python3.9/site-packages/deepspeed']
deepspeed info ................... 0.10.0, unknown, unknown
torch cuda version ............... 11.7
torch hip version ................ None
nvcc version ..................... 11.6
deepspeed wheel compiled w. ...... torch 1.13, cuda 11.7

System info (please complete the following information):

  • OS: AL2 (Amazon Linux) 5.10.149-133.644.amzn2.x86_64 #1 SMP Tue Oct 18 16:52:42 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
  • GPU count and types: p3.16xlarge instance from aws, 8 V100 with 16 GB per device
  • Deepspeed version: 0.10.0
  • (if applicable) Hugging Face Transformers/Accelerate/etc. versions: transformers: 4.29.1 accelerate 0.21.0
  • Python version: 3.9.15
@tiwargau tiwargau added bug Something isn't working inference labels Aug 4, 2023
@tiwargau tiwargau changed the title [BUG] Unused params lead to "till have inflight params" error [BUG] Unused params lead to "still have inflight params" error Aug 4, 2023
@alexwangmac
Copy link

Have you solved the problem? My situation is exactly the same as yours.

@tiwargau
Copy link
Author

Hi @alexwangmac I haven't really solved this problem, just worked around it with setting "stage3_prefetch_bucket_size": 0. This is not an ideal solution as you lose the efficiency.

Hoping deepspeed team can help with this soon.

@HeyangQin HeyangQin self-assigned this Aug 10, 2023
@hatrexltd
Copy link

Same

@haixpham
Copy link

haixpham commented Dec 1, 2023

Hi @alexwangmac I haven't really solved this problem, just worked around it with setting "stage3_prefetch_bucket_size": 0. This is not an ideal solution as you lose the efficiency.

Hoping deepspeed team can help with this soon.

I ran into the same problem and your fix worked!
Indeed the problem arises if not all model params are used during inference.

@siddk
Copy link

siddk commented Dec 18, 2023

Any update on this? Running into the same issue when I have unused parameters for a given forward pass!

@haixpham
Copy link

Any update on this? Running into the same issue when I have unused parameters for a given forward pass!

In the config json, set "stage3_prefetch_bucket_size": 0, that should work

@andre-bauer
Copy link

andre-bauer commented Jan 3, 2024

In the config json, set "stage3_prefetch_bucket_size": 0, that should work

While this might "work" this still not solves the problem for example with mixtral, since this kind of MoE does not properly work with deepspeed. Also I tried to use mixtral on a multi GPU setup and instead of getting this error message the process just hangs infinitely, most likely because parameters are fetched but not used and thus not released. Even with prefetch_bucket_size=0

@BBerabi
Copy link

BBerabi commented Jan 11, 2024

In the config json, set "stage3_prefetch_bucket_size": 0, that should work

While this might "work" this still not solves the problem for example with mixtral, since this kind of MoE does not properly work with deepspeed. Also I tried to use mixtral on a multi GPU setup and instead of getting this error message the process just hangs infinitely, most likely because parameters are fetched but not used and thus not released. Even with prefetch_bucket_size=0

I have exactly the same issue, when will Mixtral support be added to deepspeed?

@tohtana
Copy link
Contributor

tohtana commented Jan 16, 2024

(I posted a similar comment on #4808)
I will investigate this issue, but you can use DeepSpeed-FastGen (DeepSpeed-MII) for text generation. The example is available here. I verified that Mixtral works just by modifying the model name.
It is easier to use "non-persistent" mode for testing purpose, but "persistent" mode will give you the best performance. Please refer to DeepSpeed-MII for more details.

github-merge-queue bot pushed a commit that referenced this issue Jan 19, 2024
…oks (#4966)

ZeRO3 does not work with MoE models because the order of executing
modules can change at every forward/backward pass (#4094, #4808).

This PR adds an API to stop breaking down a module for parameter
fetching. The following shows an example of the usage:
```python
import torch
import deepspeed
import deepspeed.comm as dist
from transformers.deepspeed import HfDeepSpeedConfig
from transformers import AutoTokenizer, AutoModelForCausalLM
from transformers.models.mixtral.modeling_mixtral import MixtralSparseMoeBlock

model_id = "mistralai/Mixtral-8x7B-v0.1"
ds_config = {
      "bf16": {
          "enabled": True,
      },
      "zero_optimization": {
          "stage": 3,
      },
      "train_micro_batch_size_per_gpu": 1,
  }

hfdsc = HfDeepSpeedConfig(ds_config)

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16)

deepspeed.utils.set_z3_leaf_modules(model, [MixtralSparseMoeBlock])
model.eval()

ds_engine = deepspeed.initialize(model=model, config_params=ds_config)[0]
ds_engine.module.eval()
model = ds_engine.module

inputs = tokenizer.encode("DeepSpeed is", return_tensors="pt").to("cuda")
outputs = model.generate(inputs, max_new_tokens=200)
output_str = tokenizer.decode(outputs[0])
if dist.get_rank() == 0:
  print(f"output: {output_str}")
```

By passing names of modules to `set_z3_leaf_modules`, DeepSpeed engine
stops breaking down the module.

In this example, `MixtralSparseMoeBlock` has multiple experts as its
submodule. Using `set_z3_leaf_modules`, the DeepSpeed engine fetches
parameters of all the submodules when pre-fetching the parameters of
`MixtralSparseMoeBlock`.
@tohtana
Copy link
Contributor

tohtana commented Jan 19, 2024

Hi everyone,
#4966 should have fixed this issue. You can find working example there.
The PR was already merged into master. Please feel free to try, but I still recommend using DeepSpeed-FastGen for text generation.

mauryaavinash95 pushed a commit to mauryaavinash95/DeepSpeed that referenced this issue Feb 17, 2024
…oks (deepspeedai#4966)

ZeRO3 does not work with MoE models because the order of executing
modules can change at every forward/backward pass (deepspeedai#4094, deepspeedai#4808).

This PR adds an API to stop breaking down a module for parameter
fetching. The following shows an example of the usage:
```python
import torch
import deepspeed
import deepspeed.comm as dist
from transformers.deepspeed import HfDeepSpeedConfig
from transformers import AutoTokenizer, AutoModelForCausalLM
from transformers.models.mixtral.modeling_mixtral import MixtralSparseMoeBlock

model_id = "mistralai/Mixtral-8x7B-v0.1"
ds_config = {
      "bf16": {
          "enabled": True,
      },
      "zero_optimization": {
          "stage": 3,
      },
      "train_micro_batch_size_per_gpu": 1,
  }

hfdsc = HfDeepSpeedConfig(ds_config)

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16)

deepspeed.utils.set_z3_leaf_modules(model, [MixtralSparseMoeBlock])
model.eval()

ds_engine = deepspeed.initialize(model=model, config_params=ds_config)[0]
ds_engine.module.eval()
model = ds_engine.module

inputs = tokenizer.encode("DeepSpeed is", return_tensors="pt").to("cuda")
outputs = model.generate(inputs, max_new_tokens=200)
output_str = tokenizer.decode(outputs[0])
if dist.get_rank() == 0:
  print(f"output: {output_str}")
```

By passing names of modules to `set_z3_leaf_modules`, DeepSpeed engine
stops breaking down the module.

In this example, `MixtralSparseMoeBlock` has multiple experts as its
submodule. Using `set_z3_leaf_modules`, the DeepSpeed engine fetches
parameters of all the submodules when pre-fetching the parameters of
`MixtralSparseMoeBlock`.
@matthewdm0816
Copy link

Hi, I also found this problem also in my experiments. It seems in generation some parameters are not used.
Except the PR, a simple workaround can be passing a dummy input to invoke that unused parameter in inference.
While warnings like "Invalidate trace cache @ step 1: expected module 1704, but got module 1703" still appears, but the training and generation seems to be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working inference
Projects
None yet
Development

No branches or pull requests

10 participants