axolotl icon indicating copy to clipboard operation
axolotl copied to clipboard

Merge lora adaptor leads to saving the model in FP32 though base model is of FP16/BF16

Open amitagh opened this issue 1 year ago • 2 comments

Please check that this issue hasn't been reported before.

  • [X] I searched previous Bug Reports didn't find any similar reports.

Expected Behavior

After merge the final merged model should have been of same precision as the base model but it is FP32 this leads to size of the merged model almost doubling as compared to size of the base model.

Current behaviour

After merge the final merged model should have been of same precision as the base model but it is FP32 this leads to size of the merged model almost doubling as compared to size of the base model.

Steps to reproduce

Generate a lora adaptor.

Below is the config i used for Gemma 2B Pretraining with Lora. after pt i try to merge the adaptor generated with base model. In merged models config.json i see torch.dtype as FP32. Thus the size of merged model is 10 GB when base model is of 5GB

Config yaml

base_model: google/gemma-2b
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer

load_in_8bit: false
load_in_4bit: true
strict: false

datasets:
  - path: /content/test_txt_data-10exmpl.json
    type: completion
    field: text
dataset_prepared_path:
val_set_size: 0
output_dir: ./qlora-out

adapter: qlora
lora_model_dir:

sequence_len: 600
sample_packing: true
pad_to_sequence_len: true

lora_r: 64
lora_alpha: 128
lora_dropout: 0.05
lora_target_modules: 
  - q_proj
  - v_proj
  - k_proj
  - o_proj
  - gate_proj
  - down_proj
  - up_proj
#lora_modules_to_save:
#  - embed_tokens
#  - lm_head
lora_target_linear: true
lora_fan_in_fan_out:


gradient_accumulation_steps: 1
micro_batch_size: 1
num_epochs: 1
optimizer: adamw_bnb_8bit
lr_scheduler: cosine
learning_rate: 0.0002

train_on_inputs: false
group_by_length: false
bf16: false
fp16: false
tf32: false

gradient_checkpointing: true
early_stopping_patience:
resume_from_checkpoint:
local_rank:
logging_steps: 1
xformers_attention:
flash_attention: False

warmup_ratio: 0.1
evals_per_epoch: 1
eval_table_size:
eval_max_new_tokens: 128
eval_sample_packing: False
saves_per_epoch: 1
debug:
deepspeed:
weight_decay: 0.0
fsdp:
fsdp_config:
special_tokens:

save_safetensors: True

Possible solution

No response

Which Operating Systems are you using?

  • [X] Linux
  • [ ] macOS
  • [ ] Windows

Python Version

3.10

axolotl branch-commit

latest

Acknowledgements

  • [X] My issue title is concise, descriptive, and in title casing.
  • [X] I have searched the existing issues to make sure this bug has not been reported yet.
  • [X] I am using the latest version of axolotl.
  • [X] I have provided enough information for the maintainers to reproduce and diagnose the issue.

amitagh avatar Apr 10 '24 10:04 amitagh

code mistake. not an issue.

amitagh avatar Apr 10 '24 13:04 amitagh

This is an issue still there. earlier i thought this is an issue with my script but it is not. axolotl is saving in FP32 at the end of pretraining with lora. Both merged model and adaptor is stored in FP32 precision though base model is in FP16.

amitagh avatar Apr 11 '24 05:04 amitagh

I'm closing this as stale. I recall this to be correctly working now. We have an extra model.to(dtype=cfg.torch_dtype) after merging so it would save in the proper dtype at the end.

NanoCode012 avatar Mar 06 '25 14:03 NanoCode012