Fallstudie zum Fine-Tuning von Llama-2 für die Anpassung kundenspezifischer Modelle

• Bei spezialisierten Aufgaben, für die ein allgemeines LLM überdimensioniert ist, kann direktes Fine-Tuning von Llama-2 mit einem kleineren und günstigeren Modell Qualität, Kosten und Latenz zugleich verbessern
• Bei Llama-2 13B stieg nach dem Fine-Tuning die Genauigkeit für ViGGO-Funktionsdarstellungen von 58 % auf 98 %, für SQL-Generierung von 42 % auf 89 % und für GSM8k von 28 % auf 47 %
• Bei Aufgaben wie ViGGO und SQL-Generierung, bei denen das Ausgabeformat entscheidend ist, erzielten kleine Llama-2-Modelle bessere Ergebnisse als GPT-4; beim mathematischen Schlussfolgern erreichten sie jedoch nicht das Niveau von GPT-4
• Die Experimente wurden mit Skripten auf Basis von Ray Train, Ray Data, DeepSpeed und Accelerate durchgeführt; 7B und 13B wurden auf 16xA10G, 70B auf 32xA10G trainiert
• Der Schlüssel zu Leistungssteigerungen liegt eher in Datenqualität und Evaluierungspipeline als in der Modellgröße; der Kosten-/Qualitäts-Trade-off zwischen Prompt Engineering und Fine-Tuning sollte je nach Aufgabe verglichen werden

---

Fine-Tuning-Effekte in drei Aufgaben

• Große allgemeine Modelle wie GPT-4 oder Claude-2 sind nützlich für schnelles Prototyping, können aber bei eng umrissenen Anforderungen wie der Zusammenfassung oder Klassifizierung von Support-Tickets in Bezug auf Kosten und Leistung überdimensioniert sein
• Das Experiment vergleicht den Verbesserungsumfang, wenn Llama-2-Modelle per Full-Parameter-Fine-Tuning auf drei praxisnahe Aufgaben angepasst werden
  • ViGGO: Extraktion funktionaler Darstellungen aus unstrukturiertem Text
  • SQL-create-context: SQL-Generierung aus natürlicher Sprache und CREATE TABLE-Kontext
  • GSM8k: Lösen von Mathematikaufgaben auf Grundschulniveau
• Für Llama-2 13B veränderte sich die Genauigkeit wie folgt
  • ViGGO-Funktionsdarstellungen: 58 % → 98 %
  • SQL-Generierung: 42 % → 89 %
  • GSM8k: 28 % → 47 %
• Bei ViGGO und SQL-Generierung schnitten kleine Llama-2-Modelle besser ab als GPT-4; bei mathematischen Schlussfolgerungsaufgaben wie GSM8k reichte die Leistung selbst nach dem Fine-Tuning nicht an GPT-4 heran

Fine-Tuning-Verfahren und Trainingsinfrastruktur

• Für alle drei Aufgaben wurde standardmäßiges Full-Parameter-Fine-Tuning verwendet
  • Trainiert wurde mit Next-Token-Prediction
  • Alle Modellparameter wurden per Gradienten aktualisiert
  • LoRA oder das Einfrieren einzelner Transformer-Blöcke lagen außerhalb des Experimentumfangs
• Die Experiment-Skripte wurden auf Ray Train, Ray Data, DeepSpeed und Accelerate aufgebaut
  • Unterstützt werden Ausführungen mit Llama-2 7B, 13B und 70B
  • Der TorchTrainer von Ray Train verteilt die Trainingsschleife auf mehrere Worker-Prozesse und GPU-Ressourcen
  • Das Daten-Sharding übernimmt Ray Train; jeder Worker greift mit session.get_dataset_shard("train") und session.get_dataset_shard("valid") auf seine zugewiesenen Datensplits zu
• Das Modell-Sharding wird mit DeepSpeed ZeRO stage 3 und Optimizer-State-Offloading umgesetzt
  • Da Modellteile auf mehrere Worker verteilt sind, muss für Zugriffe auf das Gesamtmodell, etwa beim Speichern von Checkpoints, das Modell mit accelerator.unwrap_model(model) entpackt werden
• Die Rechenressourcen waren wie folgt
  • 7B·13B: 16xA10G
  • 70B: 32xA10G, 4 Instanzen vom Typ g5.48xlarge
  • Mit Ray ist für Full-Parameter-Fine-Tuning nicht zwingend eine A100 erforderlich
• Trainiert wurde bis zu 10 Epochen, ausgewählt wurde der Checkpoint mit der niedrigsten Perplexity auf dem Validierungsset

Eingabe-/Ausgabestruktur mit speziellen Tokens fixieren

• Die Fine-Tuning-Daten bilden die Aufgabenstruktur nicht über Instruktions-Prompts, sondern über spezielle Tokens ab
  • Beispiel: <START_Q>{question}<END_Q><START_A>{answer}<END_A>
• Diese speziellen Tokens helfen dem Modell, Eingabe- und Ausgabebereiche zu unterscheiden und klar zu lernen, wann die Ausgabe beendet werden soll
  • Im Beispiel wird <END_A> als Stopping-Token definiert, damit die Ausgabe nach Abschluss der Aufgabe stoppt
• Der Llama-Tokenizer gibt standardmäßig 32.000 Token-IDs aus
  • Nach dem Hinzufügen von vier speziellen Tokens gibt er 32.004 IDs aus
  • <START_Q> erhält etwa die ID 32000, <END_Q> die 32001
• Das Skript fügt die speziellen Tokens mit tokenizer.add_tokens(special_tokens, special_tokens=True) hinzu und erstellt mit model.resize_token_embeddings(len(tokenizer)) neue trainierbare Parameter

ViGGO: Unstrukturierten Text in funktionale Darstellungen umwandeln

• ViGGO ist ursprünglich ein englischer Datensatz, der attributwertbasierte funktionale Darstellungen in natürliche Sprache umwandelt; im Experiment wurde die Richtung umgekehrt, um unstrukturierten Text in strukturierte funktionale Darstellungen zu überführen
  • Die Domäne sind Meinungen zu Videospielen
  • Die resultierenden Darstellungen können für Indizierung und nachgelagerte Anwendungen genutzt werden
• Das Modell muss zur Eingabe passende Funktionen und Attributwerte erzeugen
  • Zu den möglichen Funktionen gehören inform, request, give_opinion, confirm, verify_attribute, suggest, request_explanation, recommend, request_attribute
  • Zu den möglichen Attributen gehören name, release_year, esrb, genres, platforms, available_on_steam, has_linux_release, has_mac_release, specifier, rating, player_perspective, has_multiplayer, developer, exp_release_date usw.
• Für die Beispiel-Eingabe What's a really fast-paced game with multiplayer that you like to play? lautet die erwartete Ausgabe request(has_multiplayer[yes], specifier[fast-paced])
• Allgemeine Modelle hielten das gewünschte Ausgabeformat oft nicht zuverlässig ein, und durch den langen Eingabekontext war die Verarbeitungszeit der Eingabe größer als die Zeit zur Ausgabeerzeugung
• Diese Aufgabe beruht eher auf Mustererkennung und grundlegendem Sprachverständnis als auf komplexem logischem Schlussfolgern
  • Es handelt sich um eine grounded task, bei der alle benötigten Fakten in der Eingabe enthalten sind
  • Dass Few-Shot-Prompts helfen, wurde als Signal gewertet, dass sich auch kleinere Llama-2-Modelle per Fine-Tuning verbessern lassen

ViGGO-Evaluierung und Ergebnisse

• Die Evaluierung basiert nicht nur auf exakter Zeichenübereinstimmung
  • Es wird geprüft, ob die Ausgabefunktion korrekt ist
  • Es wird geprüft, ob die Attributtypen korrekt sind
  • Es wird geprüft, ob die Attribute innerhalb der Funktion einer festgelegten Prioritätsreihenfolge folgen
• Bei instruktionsfolgenden Modellen wie GPT und Llama-2-chat war die Attributreihenfolge in den Prompts explizit vorgegeben; entsprechend mussten sie in der Bewertung auch diese Regel einhalten
• Zur Beschleunigung der Evaluierung wurden die batch inference API von Ray und Aviary von Anyscale zusammen verwendet
  • LLM-Generierung und Nachbearbeitung wurden verkettet und über mehrere Maschinen verteilt
• Die 7B- und 13B-Modelle verbesserten ihre Genauigkeit nach dem Fine-Tuning deutlich
  • Bei GPT-4 sank die Genauigkeit stark, wenn die Attributpriorität in die Bewertung einbezogen wurde
  • Die feinabgestimmten Modelle hielten die Priorität stets ein; selbst mit dieser zusätzlichen Einschränkung änderte sich ihre Genauigkeit nicht
• Die ViGGO-Ergebnisse zeigen, dass Fine-Tuning bei Aufgaben mit strukturierten Formaten ein stabiles und effizientes Mittel sein kann
  • Es geht nicht nur um einfaches Regex- oder JSON-Formatting, sondern darum, zu entscheiden, welche Argumente enthalten sein müssen, und auch deren Reihenfolge einzuhalten
  • Da die Ergebnisse mit 7B- und 13B-Modellen erzielt wurden, können die Serving-Kosten niedriger sein als bei Aufrufen des GPT-4-Endpunkts

SQL-Generierung: Abfragen aus natürlicher Sprache und Tabellenkontext erzeugen

• Bei der SQL-Generierung soll aus einer Anfrage in natürlicher Sprache und einer SQL-CREATE TABLE-Anweisung eine ausführbare SQL-Abfrage erzeugt werden
• Der verwendete Datensatz b-mc2/sql-create-context ist ein Hugging-Face-Datensatz, der WikiSQL und Spider kombiniert
  • Jeder Datenpunkt besteht aus einer Anfrage in natürlicher Sprache, einer SQL-CREATE TABLE-Anweisung und der zugehörigen SQL-Abfrage
  • Insgesamt umfasst der Datensatz 78.577 Datenpunkte
• Im Datensatz gab es Probleme mit den Ziel-SQLs
  • In CREATE TABLE wurden Integer-Spalten als VARCHAR gekennzeichnet, in den SQL-Abfragen aber oft wie Integer behandelt
  • Deshalb wurden alle SQL-Abfragen entfernt, die Integer-Spalten voraussetzten, wodurch der Datensatz von rund 70k auf 45k reduziert wurde
• Auch diese Aufgabe eignet sich gut für Fine-Tuning, da hier natürliche Sprache in eine strukturierte Darstellung in Form von SQL überführt wird
  • Im Unterschied zu ViGGO kann es jedoch mehrere SQL-Abfragen geben, die das korrekte Ausführungsergebnis liefern, was die Aufgabe mehrdeutiger macht

SQL-Evaluierung und Ergebnisse

• Für die Bewertung der SQL-Generierung ist ein bloßer Stringvergleich ungeeignet
  • Zeichenbasierte Vergleiche können viele False Negatives erzeugen
  • Auch AST-Vergleiche können empfindlich auf Dinge wie die Reihenfolge von Variablennamen reagieren
  • Am verlässlichsten ist es, den Code auf einem synthetischen Datensatz auszuführen und zu vergleichen, ob die Ausgabe identisch ist
• Im Experiment wurde der OpenAI-GPT-3.5-Endpunkt verwendet, um für Hunderte Beispiele synthetische Tabellen für Unit-Tests zu erzeugen
  • GPT-3.5 erhielt Frage, Tabellenschema und Ground Truth und erzeugte daraus Fake-Tabellen mit 10 Datenpunkten
  • Mit sqlglot.executor.execute wurden Ground-Truth-SQL und Modell-SQL ausgeführt und die Ergebnisse verglichen
• Um die Qualität der von GPT-3.5 erzeugten Tabellen zu prüfen, wurde zunächst die Ground-Truth-SQL ausgeführt
  • Wenn die Ergebnistabelle leer war oder dieselbe Länge wie die Ursprungstabelle hatte, wurde das Beispiel verworfen
  • Dabei wurden etwa 50 % der von GPT erzeugten Datentabellen herausgefiltert
• Die feinabgestimmten Llama-2-Modelle 7B und 13B erzielten bessere Leistung als 70B-chat und GPT-4
  • Ein häufiger Fehler der Llama-Chat-Modelle war, SQL entgegen der Prompt-Anweisung nicht konsistent in <SQL>-Tags einzuschließen
  • Dieses Problem trat bei den 7B- und 13B-Chat-Modellen häufiger auf als bei 70B
• Einige Anfragen in natürlicher Sprache im SQL-Datensatz waren kein vollkommen korrektes Englisch; dieses Rauschen könnte die GPT-4-Ergebnisse beeinflusst haben
  • Die feinabgestimmten Modelle passten sich schnell an die Eigenheiten des Datensatzes an

GSM8k: Mathematisches Schlussfolgern ist schwieriger als Strukturlernen

• GSM8k ist ein standardisierter akademischer Benchmark zur Bewertung mathematischen Schlussfolgerns und Verständnisses
• Während die beiden vorherigen Aufgaben vor allem Strukturlernen betrafen, untersucht GSM8k, inwieweit das Modell seinen Schlussfolgerungsprozess beim Lösen von Mathematikaufgaben verbessern kann
• Eine Beispielaufgabe fragt nach der Gesamtzahl verkaufter Einheiten, wenn im April 48 Stück und im Mai die Hälfte davon verkauft wurden; die richtige Antwort endet zusammen mit Zwischenschritten im Format #### 72
• Aktuelle LLMs berechnen die Endantwort in der Regel nicht nur intern und geben sie direkt aus, sondern müssen einen Teil ihres Denkprozesses in der Ausgabe erzeugen, damit die nachfolgende Token-Generierung auf einem logischen Ablauf aufbauen kann
• Diese Aufgabe erfordert nicht nur einfache Berechnung, sondern eine logische Chain of Thought von den Prämissen über Zwischenfolgerungen bis zur Endantwort

GSM8k-Evaluierung und Baselines

• Für die Evaluierung wird eine Methode benötigt, um die endgültige Antwort robust aus der Modellausgabe zu extrahieren
• Allgemeine Sprachmodelle halten das gewünschte Ausgabeformat nicht immer konsistent ein, was automatische Bewertung erschwert
  • Dafür wurde die OpenAI function calling API genutzt
  • gpt-3.5-turbo-0613 rief die Funktion report_answer auf, um aus den Generationsergebnissen anderer Modelle die finale Ganzzahl-Antwort zu extrahieren
  • So konnte selbst eine Antwort wie „The answer is four“ als 4 geparst werden
• Dieses Verfahren wurde an den Ground-Truth-Antworten des Datensatzes validiert, hat aber den Nachteil zusätzlicher OpenAI-Tokenkosten bei der Evaluierung
• Feinabgestimmte Modelle lernten das Ziel-Antwortmuster schnell, sodass selbst bei falschen Antworten die Ausgabestruktur vorhersagbar blieb
  • Die Auswertung der feinabgestimmten Modelle erfolgte per #### {answer}-Regex und vermied dadurch die Nachbearbeitung über OpenAI-Endpunkte
• Als Baselines dienten
  • die in der Literatur veröffentlichten 8-shot prompting-Ergebnisse der vortrainierten Basismodelle
  • mehrere prompt-engineerte Templates für die von Meta per RLHF zu allgemeinen Assistenten trainierten chat-optimierten Llama-2-Varianten

GSM8k-Ergebnisse und zweistufiges Fine-Tuning

• Fine-Tuning der Basismodelle verbesserte die GSM8k-Leistung konsistent, führte aber nicht immer zu deutlich besseren Ergebnissen als bei chat-optimierten Modellen
  • Die Chat-Modelle waren dem Basismodell bei der Genauigkeit überlegen, möglicherweise weil sie während des Chat-Tunings mit Mathematikbeispielen trainiert wurden
• Das Einfügen von Prompts in feinabgestimmte Modelle führte nicht immer zu besseren Ergebnissen als beim Basismodell
  • Beispielsweise kann Llama-2-70B-chat schlechter abschneiden als ein Basismodell mit 8-shot-Beispielprompt
  • Feinabgestimmte Modelle waren jedoch konsistent besser als 8-shot-gepromptete Basismodelle
• Aus Sicht der Serving-Kosten können feinabgestimmte Modelle vorteilhaft sein
  • Bei promptbasierten Verfahren fallen pro Anfrage zusätzliche Prompt-Token-Kosten an
  • Bei feinabgestimmten Modellen schlagen praktisch nur die Tokens der eigentlichen Frage zu Buche
• Der GSM8k-Trainingsdatensatz ist mit etwa 8k Beispielen relativ klein, weshalb angenommen wurde, dass sich das Potenzial von Llama-13B damit nicht vollständig ausschöpfen lässt
• Ein zweistufiger Ansatz mit zunächst Fine-Tuning des Llama-13B-Basismodells auf MathQA und anschließend erneutem Fine-Tuning auf GSM8k brachte zusätzliche Verbesserungen
  • Fine-Tuning nur auf GSM8k verbesserte sich gegenüber dem Basismodell um 10 Prozentpunkte
  • Zweistufiges Fine-Tuning mit MathQA und anschließend GSM8k brachte weitere 10 Prozentpunkte gegenüber dem ersten Fine-Tuning, also insgesamt 20 Prozentpunkte gegenüber dem Basismodell
• MathQA besteht aus 30.000 Frage-/Antwort-Paaren, enthält aber mehr Rauschen und hat eine andere Struktur als GSM8k
  • Die Antwortqualität ist niedriger, und die Endantwort liegt im Multiple-Choice-Format vor
  • Trotzdem erwies sich das zweistufige Fine-Tuning mit MathQA als wirksam, um die Endergebnisse auf GSM8k zu verbessern

Wichtige Kriterien für den Praxiseinsatz

• Geschlossene Modelle wie GPT-4 oder Claude-2 sind stark für Prototyping und die frühe Validierung von Mehrwert, reichen aber für den Betrieb produktiver LLM-Anwendungen nicht immer aus
• LLM-Fine-Tuning für Nischenaufgaben kann nicht nur in Bezug auf Datenschutz, sondern auch bei Latenz, Kosten und Qualität wertvoll sein
  • In den Beispielen zu ViGGO und SQL war die Qualität sogar besser als bei GPT-4
• Beim Fine-Tuning sollte der Fokus weniger auf Infrastrukturdetails als auf Datenerhebung und dem Aufbau einer Evaluierungspipeline liegen
  • Die Evaluierungspipeline bildet die Grundlage, um Trade-offs verschiedener Lösungsansätze entlang geschäftlicher Anforderungen zu vergleichen
• Die Experimente wurden mit der Fine-Tuning- und Serving-Plattform von Anyscale sowie Anyscale Endpoints durchgeführt
• Derselbe Prozess wurde so auf Anyscales Fine-Tuning- und Serving-Lösung auf Ray aufgebaut, dass er sich mit eigenen Daten und in der eigenen Cloud wiederholen lässt

[GN⁺]

Meinungen auf Hacker News

• Vor ein paar Wochen habe ich in einem Coding-Livestream ausführlich behandelt, wie man Llama 2 mit einem eigenen Datensatz feinabstimmt, und das auf einer einzelnen GPU in Colab gemacht.
  In meinem Fall bestand der Datensatz aus meinem eigenen Code.
  Fine-tuning Llama stream: https://www.youtube.com/watch?v=TYgtG2Th6fI&t=2282s
  Es gibt auch noch ein paar weitere QLoRA-Finetuning-Sessions, in denen ich die Konzepte aus der Perspektive eines Software Engineers mit acht Jahren Erfahrung erkläre, der vor Kurzem in Machine Learning gewechselt ist und es sich selbst beigebracht hat.
  QloRa fine-tuning stream: https://www.youtube.com/watch?v=LitybCiLhSc&t=4584s
  Ich versuche, möglichst verständlich zu erklären, wie ich bei persönlichen Projekten und bei meinem aktuellen KI-basierten Startup herangehe. Auch die Serie zum Feinabstimmen des kleinsten LLM für Webentwicklung scheint gut anzukommen; ich streame seit etwa einem Monat und werde künftig noch mehr hochladen.

  • Mich würde eine allgemeine Faustregel interessieren, wann man jeweils RAG und Finetuning einsetzen sollte.
    Auch das Aufteilen feinabgestimmter Modelle verstehe ich noch nicht gut. Braucht man ein eigenes Terraform-LLM, SQL-LLM und Python-LLM, oder reicht einfach ein „Code“-LLM?
  • Es braucht wirklich eine einfache App/ein Modul/eine Bibliothek auf dem Niveau: „Quelldaten in dieses Verzeichnis legen, Button drücken und dann mit diesen Inhalten chatten“.
    Im Moment braucht man zu viele Implementierungsdetails, sodass es ohne einen wirklich sinnvollen Anwendungsfall schwer zugänglich ist. privateGPT scheint sich langsam in diese Richtung zu bewegen.
  • Das war gut; eine Serie zur Vorbereitung eigener Datensätze fürs Finetuning wäre ebenfalls wünschenswert.
    Das ist der Teil, den viele andere Tutorials weitgehend überspringen. Besonders würde mich interessieren, wie man je nach unterschiedlichen Zielen wie Sicherheit oder Genauigkeit vorgeht.
  • Geht das mit einer einzelnen GPU? Mich würde interessieren, ob es selbst mit einer 3060 realistisch ist.

• Ich habe bei Llama 2 dasselbe Problem. Es ist fast unmöglich, es dazu zu bringen, nur den gewünschten Text auszugeben; es hängt der Antwort immer vorn oder hinten irgendetwas an.
  Mich würde interessieren, ob es Prompt-Techniken gibt, um das zu beheben.

  • Besser ein besseres Modell verwenden.
    airoboros unterstützt ein PLAINFORMAT-Token, das Backticks, Erklärungen usw. vermeidet und nur Code ausgeben lässt.
    https://huggingface.co/TheBloke/airoboros-l2-70B-GPT4-2.0-GG...
  • Die Llama-2-chat-Modelle sind in dieser Hinsicht übermäßig feinabgestimmt. Man kann Few-Shot-Prompting versuchen, aber das garantiert nicht die gewünschte Ausgabe.
    Wenn man eine Garantie braucht, ist es am besten, mit einem kleinen Datensatz von ungefähr 1.000 Beispielen feinzujustieren und von dort aus weiter zu verbessern.
  • Es hängt vom Ziel ab, aber ich hatte Erfolg damit, statt eines RLHF-Modells das Basis-LLaMA2-Modell feinzujustieren, um ein bestimmtes Ausgabeformat zu reproduzieren.
    Mein Anwendungsfall war eine einfache Aufgabe zur Informationsextraktion/-synthese aus Text, nicht kreatives Schreiben. Das Basismodell passt möglicherweise nicht für alle Aufgaben gut.
  • Man kann das Modell per Prompt anweisen, Antworten oder Code immer in einem content-String oder in JSON auszugeben.
    Bei JSON lassen sich Anfang und Ende erkennen, sodass man alles außerhalb des JSON entfernen kann.

• Schön, dass es so einen Artikel gibt. Online gab es sehr viele Diskussionen über Modell-Customization, und dieser Artikel räumt das Rauschen ziemlich gut weg.
  Auch die Evaluationsmethodik gefällt mir, und der Artikel scheint gut geschrieben zu sein.

• Es ist seltsam, dass LoRA und quantisiertes Training nicht ernsthafter behandelt werden. Das ist deutlich günstiger und weniger zeitaufwendig, und es gibt viele Hinweise darauf, dass es ziemlich gut funktioniert.
  Meiner Meinung nach sollte man es nicht als spätere Zusatzoption beiseiteschieben.

  • https://twitter.com/Tim_Dettmers/status/1689375417189412864

• Schön zu sehen, dass eine NER-ähnliche Aufgabe die beste Performance erzielt hat. Ich war gerade dabei, einen ähnlichen Test zum Vergleich mit einem feinabgestimmten BERT-Modell durchzuführen.
  Mich würde interessieren, wie hoch die Trainingskosten für diese Aufgabe waren.

  • Ich bin Mitautor des Artikels. Die ViGGO-Trainingsdaten umfassen etwa 5.100 Zeilen, und wir haben mit Blockgröße 512 trainiert.
    Man könnte die Blockgröße reduzieren, aber es war einfacher, den Code unverändert zu lassen. 7B brauchte auf 16xA10G etwa 15 Minuten pro Epoche, 13B etwa 25 Minuten. Die On-Demand-Kosten liegen damit pro Epoche bei etwa $7.2 für 7B und etwa $12 für 13B. Diese Werte beziehen sich nur auf die Trainingszeit und schließen die Zeit zum Starten/Beenden des Clusters nicht ein.
  • Gute Frage. Schade, dass nicht angegeben wurde, wie lange 10 Epochen gedauert haben; dann hätte man die Kosten berechnen können. Noch besser wäre es gewesen, Zeit und Kosten gemeinsam anzugeben.
    Es heißt, dass für 7B und 13B 16xA10G und für 70B 32xA10G verteilt auf vier g5.48xlarge-Instanzen verwendet wurden. Mit Ray muss man für ein Full-Parameter-Finetuning solcher Modelle keine A100s beschaffen, und derselbe Ablauf wird für jede Aufgabe wiederholt. Für den GSM8k-Datensatz wird ein Beispiellauf mit Kontextlänge 512 und 3,7 Millionen effektiven Tokens pro Epoche gezeigt.
    Es wurde bis zu 10 Epochen trainiert, und ausgewählt wurde der Checkpoint mit der niedrigsten Perplexity auf dem Validierungsset.

• Eine Schwierigkeit ist, dass man entweder eine kleine Armee von Leuten oder ein sehr starkes bestehendes Modell braucht, um einen ausreichend großen eigenen Datensatz zu erstellen.
  Am Ende muss man wahrscheinlich OpenAI verwenden, aber mit OpenAI Trainingsmaterial für andere Modelle zu erzeugen, verstößt gegen die Nutzungsbedingungen. Mich würde interessieren, ob es dazu schon einmal zu einem Rechtsstreit gekommen ist. Sieht man das einfach als unfair an und ignoriert es?

  • Das gilt nicht für alle Aufgaben. Bei vielen Natural-Language-Processing-Aufgaben muss man vorhandene Daten nur in ein LLM-Format umformatieren.
  • Gibt es einen Grund, die Nutzungsbedingungen nicht zu ignorieren? Im schlimmsten Fall verliert man den Zugriff.

• In letzter Zeit sehe ich häufiger NER-Beispiele; ich frage mich, warum man für solche Aufgaben nicht spaCy verwendet.

  • spaCy funktioniert bei mehrsprachigen Trainingsdaten nicht gut, und ich habe gesehen, dass es häufiger und auf seltsamere Weise scheitert als Transformer-basierte Ansätze.
  • Ich denke in die Richtung, Daten mit einem teuren Modell zu labeln und anschließend per Lehrer/Schüler-Ansatz ein kleineres Modell wie SpaCy oder BERT zu trainieren, um Kosten und Geschwindigkeit in den Griff zu bekommen.
  • Für NER verwenden wir ein feinabgestimmtes BERT-basiertes Modell, aber ich würde gern einen Performance-Vergleich machen.

• Ich arbeite bei Anyscale.
  Da dieser Blog offenbar gut angekommen ist, planen wir, ihn in den Ray Summit aufzunehmen: https://raysummit.anyscale.com/agenda
  Wenn ihr Ideen habt, welche Art von Inhalten ihr auf dem Ray Summit gern häufiger sehen würdet, sagt gern Bescheid.

• Es heißt, dass 7B bei 3,5 Millionen Tokens etwa 14 Minuten pro Epoche braucht und 13B etwa 26 Minuten pro Epoche.
  Für 7B und 13B brauche man mindestens 1xg5.16xlarge als Head Node und 15xg5.4xlarge als Worker Nodes; mich würde interessieren, wie hoch die Kosten bei AWS ungefähr sind.

  • g5.16xlarge kostet $4.0960 pro Stunde, g5.4xlarge $1.6240 pro Stunde.
    Wenn man es in us-east-1 laufen lässt, kann man von etwa $30 pro Stunde ausgehen.
    https://instances.vantage.sh/?selected=g5.16xlarge,g5.4xlarg...

• Mich würde interessieren, ob man Llama-2 auf einem M1 Ultra 64GB lokal feinabstimmen kann. Die meisten Materialien beziehen sich auf Cloud oder Nvidia CUDA unter Linux; Hinweise auf brauchbare Ressourcen wären hilfreich.

  • Ich glaube eher nicht. Ich nutze einen M1 Max mit 64 GB, und einige Inferenz läuft ganz ordentlich.
    Fürs Training werde ich wohl ein paar RunPod-Credits kaufen; ein paar Dutzend Dollar sollten reichen.