Fine-Tuning Llama-3-70B with QLora: Is 8 H100 80GB SXM5 Overkill?

[monk1337]

I'm attempting to fine-tune Llama-3-70B on my personal data with qlora r: 512 and qlora_alpha: 256. It's currently using 8 H100 80GB SXM5, and I'm wondering if this is normal to consume this much compute for qlora or if I've made a mistake somewhere. Is it possible to optimize the pipeline with the same sequence length and lora r & alpha?

Here is my full config

base_model: meta-llama/Meta-Llama-3-70B
model_type: AutoModelForCausalLM
tokenizer_type: AutoTokenizer

load_in_8bit: false
load_in_4bit: true
strict: false

datasets:
  - path: datahub/data
    type: alpaca
val_set_size: 0
output_dir: ./out

sequence_len: 2000
sample_packing: true
pad_to_sequence_len: true

adapter: qlora
lora_r: 512
lora_alpha: 256
lora_dropout: 0.05
lora_target_linear: true
lora_target_modules:
  - q_proj
  - v_proj
  - v_proj
  - o_proj
  - gate_proj
  - down_proj
  - up_proj

wandb_project: llama70b
wandb_entity:
wandb_watch:
wandb_name:
wandb_log_model:

gradient_accumulation_steps: 1
micro_batch_size: 2
num_epochs: 2
optimizer: adamw_bnb_8bit
lr_scheduler: cosine
learning_rate: 0.00001

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

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

warmup_steps: 100
evals_per_epoch: 4
eval_table_size:
saves_per_epoch: 1
debug:
deepspeed:
weight_decay: 0.0
fsdp:
fsdp_config:
special_tokens:
  pad_token: "<|end_of_text|>"
save_total_limit: 4

[haoyitedaniu]

For this section :

lora_target_modules:

• q_proj
• v_proj
• v_proj
• o_proj
• gate_proj
• down_proj
• up_proj

I see you have two v_projs above, is that just a typo? One should be k_proj?

Tom

[monk1337]

it's a typo, Thank you for the correction.