即使 RTX 3090 有著 24GB 的 RAM，使用一塊 RTX 3090 依然無法 fp32 精度訓(xùn)練最小號的 LLaMA-6B。
估算模型所需的RAM
首先，需要了解如何根據(jù)參數(shù)量估計模型大致所需的 RAM，這在實踐中有很重要的參考意義。需要通過估算設(shè)置 batch_size，設(shè)置模型精度，選擇微調(diào)方法和參數(shù)分布方法等。
接下來用 LLaMA-6B 模型為例估算其大致需要的內(nèi)存。
精度對所需內(nèi)存的影響：
- fp32 精度，一個參數(shù)需要 32 bits, 4 bytes.
- fp16 精度，一個參數(shù)需要 16 bits, 2 bytes.
- int8 精度，一個參數(shù)需要 8 bits, 1 byte.
模型需要的 RAM 大致分三個部分：
- 模型參數(shù)
- 梯度
- 優(yōu)化器參數(shù)
模型參數(shù)：等于參數(shù)量*每個參數(shù)所需內(nèi)存。
- 對于 fp32，LLaMA-6B 需要 6B*4 bytes = 24GB內(nèi)存
- 對于 int8，LLaMA-6B 需要 6B*1 byte = 6GB
梯度：同上，等于參數(shù)量*每個梯度參數(shù)所需內(nèi)存。
優(yōu)化器參數(shù)：不同的優(yōu)化器所儲存的參數(shù)量不同。
對于常用的 AdamW 來說，需要儲存兩倍的模型參數(shù) (用來儲存一階和二階momentum)。
- fp32 的 LLaMA-6B，AdamW 需要 6B*8 bytes = 48 GB
- int8 的 LLaMA-6B，AdamW 需要 6B*2 bytes = 12 GB
除此之外，CUDA kernel 也會占據(jù)一些 RAM，大概 1.3GB 左右，查看方式如下。
綜上，int8 精度的 LLaMA-6B 模型部分大致需要 6GB+6GB+12GB+1.3GB = 25.3GB 左右。
再根據(jù)LLaMA的架構(gòu)（hidden_size = 4096, intermediate_size =11008, num_hidden_layers = 32, context_length = 2048）計算中間變量內(nèi)存。
每個 instance 需要：
所以一張 A100（80GB RAM）大概可以在 int8 精度；batch_size = 50 的設(shè)定下進(jìn)行全參數(shù)訓(xùn)練。
ps:查看消費級顯卡的內(nèi)存和算力：
2023 GPU Benchmark and Graphics Card Comparison Chart
Fp16-mixed precision
混合精度訓(xùn)練的大致思路是在 forward pass 和 gradient computation 的時候使用 fp16 來加速，但是在更新參數(shù)時使用 fp32。
用 torch 實現(xiàn)：CUDA Automatic Mixed Precision examples
torch fp16 推理：直接使用 model.half() 將模型轉(zhuǎn)換為fp16.
使用 Huggingface Transformers：在 TrainingArguments 里聲明 fp16=True
Int8-bitsandbytes
Int8 是個很極端的數(shù)據(jù)類型，它最多只能表示 - 128～127 的數(shù)字，并且完全沒有精度。
為了在訓(xùn)練和 inference 中使用這個數(shù)據(jù)類型，bitsandbytes 使用了兩個方法最大程度地降低了其帶來的誤差：
- vector-wise quantization
- mixed precision decompasition
Huggingface 在這篇文章中用動圖解釋了 quantization 的實現(xiàn)
論文：LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale
借助 Huggingface PEFT，使用 int8 訓(xùn)練 opt-6.5B 的完整流程
LoRA
Low-Rank Adaptation 是微調(diào) LLMs 最常用的省內(nèi)存方法之一。
LoRA 的論文
借助 Huggingface PEFT 框架，使用 LoRA 微調(diào) mt0
Gradient Checkpointing
在 torch 中使用 - 把 model 用一個 customize 的 function 包裝一下即可，詳見：Explore Gradient-Checkpointing in PyTorch
在 Huggingface Transformers 中使用
Torch FSDP+CPU offload
Fully Sharded Data Paralle（FSDP）和 DeepSpeed 類似，均通過 ZeRO 等分布優(yōu)化算法，減少內(nèi)存的占用量。其將模型參數(shù)，梯度和優(yōu)化器狀態(tài)分布至多個 GPU 上，而非像 DDP 一樣，在每個 GPU 上保留完整副本。
CPU offload 則允許在一個 back propagation 中，將參數(shù)動態(tài)地從 GPU -> CPU, CPU -> GPU 進(jìn)行轉(zhuǎn)移，從而節(jié)省 GPU 內(nèi)存。
Huggingface 這篇博文解釋了 ZeRO 的大致實現(xiàn)方法
借助 torch 實現(xiàn) FSDP，只需要將 model 用 FSDPwarp 一下；同樣，cpu_offload 也只需要一行代碼
在這個可以查看 FSDP 支持的模型
在 Huggingface Transformers 中使用 Torch FSDP
根據(jù)某些 issue，shard_grad_op（只分布保存 optimizer states 和 gradients）模式可能比 fully_shard 更穩(wěn)定文章來源：http://www.zghlxwxcb.cn/news/detail-487577.html
參考
pytorch模型訓(xùn)練之fp16、apm、多GPU模型、梯度檢查點（gradient checkpointing）顯存優(yōu)化等
圖解網(wǎng)絡(luò)Offload
Flexgen LLM推理 CPU Offload計算架構(gòu)到底干了什么事情？文章來源地址http://www.zghlxwxcb.cn/news/detail-487577.html
到了這里，關(guān)于省顯存（內(nèi)存？）的大語言模型（LLMs）訓(xùn)練/微調(diào)/推理方法的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
