Optimierung des Speichers für die Inferenz und Feinabstimmung von Large Language Modellen

Große Sprachmodelle (LLMs) wie GPT-4, Bloom und LLaMA haben durch die Skalierung auf Milliarden von Parametern bemerkenswerte Fähigkeiten erlangt. Die Bereitstellung dieser massiven Modelle für Inferenz oder Feinabstimmung ist jedoch aufgrund ihrer enormen Speicheranforderungen herausfordernd. In diesem technischen Blog werden wir Techniken für die Schätzung und Optimierung des Speicherbedarfs während der LLM-Inferenz und -Feinabstimmung auf verschiedenen Hardware-Konfigurationen erkunden.

Verständnis der Speicheranforderungen

Der Speicher, der zum Laden eines LLM benötigt wird, wird hauptsächlich durch die Anzahl der Parameter und die numerische Genauigkeit bestimmt, die zum Speichern der Parameter verwendet wird. Eine einfache Faustregel lautet:

• Das Laden eines Modells mit X Milliarden Parametern erfordert ungefähr 4X GB VRAM in 32-Bit-Float-Genauigkeit
• Das Laden eines Modells mit X Milliarden Parametern erfordert ungefähr 2X GB VRAM in 16-Bit-bfloat16/Float16-Genauigkeit

Beispielsweise würde das Laden des 175-Milliarden-Parameter-GPT-3-Modells ungefähr 350 GB VRAM in bfloat16-Genauigkeit erfordern. Derzeit bieten die größten kommerziell verfügbaren GPUs wie die NVIDIA A100 und H100 nur 80 GB VRAM, was die Notwendigkeit von Techniken wie Tensor-Parallelismus und Modell-Parallelismus erfordert.

Während der Inferenz wird der Speicherbedarf von den Modellparametern und den temporären Aktivierungstensoren dominiert, die erzeugt werden. Eine hochrangige Schätzung für den Spitzen-Speicherbedarf während der Inferenz ist die Summe des Speichers, der zum Laden der Modellparameter und des Speichers für Aktivierungen erforderlich ist.

Quantifizierung des Inferenzspeichers

Lassen Sie uns den Speicherbedarf für die Inferenz mit dem OctoCode-Modell quantifizieren, das etwa 15 Milliarden Parameter in bfloat16-Format (~ 31 GB) hat. Wir verwenden die Transformers-Bibliothek, um das Modell zu laden und Text zu generieren:

from transformers import AutoModelForCausalLM, AutoTokenizer, pipeline
import torch

model = AutoModelForCausalLM.from_pretrained("bigcode/octocoder",
torch_dtype=torch.bfloat16,
device_map="auto",
pad_token_id=0)
tokenizer = AutoTokenizer.from_pretrained("bigcode/octocoder")
pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)

prompt = "Frage: Bitte schreiben Sie eine Python-Funktion, um Bytes in Gigabyte umzuwandeln.\n\nAntwort:"
result = pipe(prompt, max_new_tokens=60)[0]["generated_text"][len(prompt):]

def bytes_to_gigabytes(bytes):
return bytes / 1024 / 1024 / 1024

bytes_to_gigabytes(torch.cuda.max_memory_allocated())

Ausgabe:

Der Spitzen-GPU-Speicherbedarf beträgt etwa 29 GB, was unserer Schätzung von 31 GB für das Laden der Modellparameter im bfloat16-Format entspricht.

Optimierung des Inferenzspeichers mit Quantisierung

Während bfloat16 die übliche Genauigkeit für das Training von LLMs ist, haben Forscher festgestellt, dass die Quantisierung der Modellgewichte auf niedrigere Genauigkeitsdatentypen wie 8-Bit-Ganzzahlen (int8) oder 4-Bit-Ganzzahlen den Speicherbedarf erheblich reduzieren kann, während der Genauigkeitsverlust für Inferenzaufgaben wie Textgenerierung minimal bleibt.

Lassen Sie uns die Speichereinsparungen durch 8-Bit- und 4-Bit-Quantisierung des OctoCode-Modells sehen:

</div>
# 8-Bit-Quantisierung
model = AutoModelForCausalLM.from_pretrained("bigcode/octocoder", load_in_8bit=True,
pad_token_id=0)
pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)
result = pipe(prompt, max_new_tokens=60)[0]["generated_text"][len(prompt):]
bytes_to_gigabytes(torch.cuda.max_memory_allocated())</pre>

Ausgabe:

# 4-Bit-Quantisierung
model = AutoModelForCausalLM.from_pretrained("bigcode/octocoder", load_in_4bit=True,
low_cpu_mem_usage=True, pad_token_id=0)
pipe = pipeline("text-generation", model=model, tokenizer=tokenizer)
result = pipe(prompt, max_new_tokens=60)[0]["generated_text"][len(prompt):]
bytes_to_gigabytes(torch.cuda.max_memory_allocated())

Ausgabe:

Mit 8-Bit-Quantisierung reduziert sich der Speicherbedarf von 31 GB auf 15 GB, während 4-Bit-Quantisierung ihn weiter auf 9,5 GB reduziert! Dies ermöglicht das Ausführen des 15-Milliarden-Parameter-OctoCode-Modells auf Consumer-GPUs wie der RTX 3090 (24 GB VRAM).

Es ist jedoch zu beachten, dass eine aggressivere Quantisierung wie 4-Bit manchmal zu einem Genauigkeitsverlust im Vergleich zu 8-Bit- oder bfloat16-Genauigkeit führen kann. Es gibt einen Kompromiss zwischen Speichereinsparungen und Genauigkeit, den Benutzer für ihren Anwendungsfall bewerten sollten.

Quantisierung ist eine leistungsstarke Technik, die die Bereitstellung von LLMs in ressourcenbeschränkten Umgebungen wie Cloud-Instanzen, Edge-Geräten oder sogar Mobiltelefonen ermöglichen kann, indem der Speicherbedarf erheblich reduziert wird.

Schätzung des Speichers für Feinabstimmung

Während Quantisierung hauptsächlich für effiziente Inferenz verwendet wird, sind Techniken wie Tensor-Parallelismus und Modell-Parallelismus für die Verwaltung des Speicherbedarfs während des Trainings oder der Feinabstimmung von großen Sprachmodellen von entscheidender Bedeutung.

Der Spitzen-Speicherbedarf während der Feinabstimmung ist typischerweise 3-4 Mal höher als bei der Inferenz aufgrund zusätzlicher Speicheranforderungen für:

• Gradienten
• Optimizer-Zustände
• Aktivierungen aus dem Vorwärtsdurchlauf, die für die Rückwärtsverbreitung gespeichert werden

Eine konservative Schätzung ist, dass die Feinabstimmung eines LLM mit X Milliarden Parametern etwa 4 * (2X) = 8X GB VRAM in bfloat16-Genauigkeit erfordert.

Beispielsweise würde die Feinabstimmung des 7-Milliarden-Parameter-LLaMA-Modells etwa 7 * 8 = 56 GB VRAM pro GPU in bfloat16-Genauigkeit erfordern. Dies übersteigt die Speicherkapazität aktueller GPUs, was die Notwendigkeit verteilter Feinabstimmungstechniken erfordert.

Verteilte Feinabstimmungstechniken

Es wurden mehrere verteilte Feinabstimmungsmethoden vorgeschlagen, um die GPU-Speicherbeschränkungen für große Modelle zu überwinden:

1. Daten-Parallelismus: Der klassische Daten-Parallelismus-Ansatz repliziert das gesamte Modell auf mehrere GPUs, während die Trainingsdatenbatchs aufgeteilt und verteilt werden. Dies reduziert die Trainingszeit linear mit der Anzahl der GPUs, reduziert jedoch nicht den Spitzen-Speicherbedarf auf jeder GPU.
2. ZeRO Stage 3: Eine fortschrittliche Form des Daten-Parallelismus, die die Modellparameter, Gradienten und Optimizer-Zustände auf GPUs aufteilt. Dies reduziert den Speicher im Vergleich zum klassischen Daten-Parallelismus, indem nur die erforderlichen partitionierten Daten auf jeder GPU während verschiedenen Phasen des Trainings gespeichert werden.
3. Tensor-Parallelismus: Anstelle der Replikation des Modells teilt der Tensor-Parallelismus die Modellparameter in Zeilen oder Spalten auf und verteilt sie auf GPUs. Jede GPU arbeitet mit einem partitionierten Satz von Parametern, Gradienten und Optimizer-Zuständen, was zu erheblichen Speichereinsparungen führt.
4. Pipeline-Parallelismus: Diese Technik teilt die Modellschichten auf verschiedene GPUs/Arbeiter auf, wobei jeder Worker einen Teil der Schichten ausführt. Aktivierungen werden zwischen den Arbeitern übergeben, was den Spitzen-Speicherbedarf reduziert, aber die Kommunikationsüberheadzeit erhöht.

Die Schätzung des Speicherbedarfs für diese verteilten Methoden ist nicht trivial, da die Verteilung von Parametern, Gradienten, Aktivierungen und Optimizer-Zuständen je nach Technik variiert. Darüber hinaus können verschiedene Komponenten wie der Transformer-Körper und der Sprachmodell-Kopf unterschiedliche Speicherzuweisungsverhaltensweisen aufweisen.

Die LLMem-Lösung

Forscher haben kürzlich LLMem vorgeschlagen, eine Lösung, die den GPU-Speicherbedarf bei der Anwendung verteilter Feinabstimmungsmethoden auf LLMs auf mehreren GPUs genau schätzt.

Schätzung des GPU-Speicherbedarfs für die Feinabstimmung von vorgefertigten LLMs

LLMem berücksichtigt Faktoren wie die Rekombination von Parametern vor der Berechnung (ZeRO Stage 3), die Ausgabesammlung im Rückwärtsdurchlauf (Tensor-Parallelismus) und die unterschiedlichen Speicherzuweisungsstrategien für den Transformer-Körper und den Sprachmodell-Kopf.

Experimentelle Ergebnisse zeigen, dass LLMem den Spitzen-GPU-Speicherbedarf für die Feinabstimmung von LLMs auf einer einzelnen GPU mit einem Fehler von bis zu 1,6 % schätzen kann, was die durchschnittliche Fehlerrate von 42,6 % des aktuellen Standes der Technik DNNMem übertrifft. Wenn verteilte Feinabstimmungsmethoden auf LLMs mit über einer Milliarde Parametern auf mehreren GPUs angewendet werden, erreicht LLMem eine beeindruckende durchschnittliche Fehlerrate von 3,0 %.