c't KI-Praxis (eBook)

Bild: Moritz Reichartz

Live on the bleeding edge

von Pina Merkert

Es ist toll, dass man inzwischen mit gigantisch großen Sprachmodellen auf dem eigenen Rechner herumspielen kann. Die Modelle sind aber alle noch sehr neu und die Software, um sie auszuführen, ist ständigen Änderungen unterworfen. Das GGML-Format hat dieses Jahr schon drei Versionen durchlaufen und es kann einem leicht passieren, dass das Datenformat eines heruntergeladenen Modells nun doch wieder nicht zur neuesten Version von llama.cpp passt.

Diese Software öffnet sich gerade durch die Umstellung auf die GGML-Variante GGUF für andere Architekturen (vor allem, um gleichzeitig LLaMA-1 und -2 zu unterstützen). Für die nicht auf LLaMA aufbauenden Falcon-Modelle gibt es aber längst einen Fork namens ggllm.cpp, bei dem nicht klar ist, ob er durch GGUF obsolet wird.

Das sind nur Beispiele für die Schnelllebigkeit der gesamten Software-Infrastruktur. Dass Bibliotheken mit neuen CUDA-Versionen funktionieren, ist ein Stück weit Glückssache. Neue Torch-Versionen können Einfluss auf Bibliotheken haben, die Torch gar nicht benutzen. Wrapper und Helper werden oft für eine bestimmte Version geschrieben und dann nicht weiter gepflegt, weil Entwickler auf ein anderes Basismodell gewechselt sind.

Man kann sich momentan weder auf stabile APIs noch auf Langzeit-Support verlassen. Bibliotheken und Frontends funktionieren meist nur dann zusammen, wenn die Entwickler genau mit dieser Kombination gearbeitet haben. Die Information, was zusammenarbeitet, ist aber schwer zu finden und fast nie dokumentiert.

Wir haben bei unserer Recherche Tage damit verschwendet zu versuchen, Torch für CUDA 12.2 zu kompilieren, llama.cpp mit dem Visual-Studio-Compiler zu übersetzen und das Python-Binding zu llama.cpp mit dessen Low-Level-API für einen browserbasierten Chat zu benutzen. Meist hat etwas funktioniert, aber nicht alles und wir mussten die Recherche abbrechen, weil wir niemandem zumuten wollten, mit eigenen Patches Code zu flicken, der noch nicht reif für eine halbwegs stressfreie Nutzung ist.

Probieren Sie die hier erwähnten Modelle gerne aus. Es macht Spaß zu experimentieren und ein Stück weit entwickelt man ein Gefühl dafür, wohin sich die Sprachmodell-KI-Community gerade entwickelt. Wir empfehlen aber nicht zu viel Zeit in einzelne Experimente zu stecken. Für 99 Prozent der Nutzer lohnt es sich zu warten, bis die Software gereift ist und nicht mehr irgendwo zwischen einem Technical Preview und einer Alpha-Version rangiert.

Kein PyTorch, kein Training

Außer Google nutzen ziemlich alle Forschungsgruppen das Framework PyTorch, um ihre Modelle zu strukturieren und zu trainieren. LLaMA und alle nachtrainierten Varianten wie Alpaca und Guanaco sind Torch-Modelle. Nur leider ist die Installation von Torch nicht trivial, weil man je nach Hardware vorab unterschiedliche Bibliotheken installieren muss. Besonders schwer ist es beispielsweise, mit PyTorch volle Hardwarebeschleunigung bei M1- und M2-Chips von Apple hinzubekommen.

Dazu kommt, dass sich neuronale Netze nur dann trainieren lassen, wenn die Parameter in einem Zahlenformat vorliegen, das auch sehr kleine Veränderungen an den Werten darstellen kann. Das ist nötig, weil das Training in winzigen, aber dafür vielen Schritten vorangeht. Wer selbst schon Netze trainiert hat, weiß, dass das Training nämlich schnell instabil wird, wenn man die Lernrate zu hoch einstellt, was im Endeffekt auf zu große Schritte hinausläuft.

Wenn Sie überschlagen, wie viel Speicher 7, 13, 40 oder 75 Milliarden Parameter belegen wenn jede Zahl 16 Bit lang ist (inzwischen wird meist im Format bfloat16 statt mit float32 trainiert), stellen Sie fest, dass der Grafikspeicher und oft sogar der gesamte Hauptspeicher des PC ruck, zuck überlaufen. In der Praxis heißt das: Die meisten Modelle können Sie auf dem PC nicht trainieren und nicht feintunen (Parameter Efficient Fine Tuning – PEFT ist zwar möglich, der Trick lässt die Original-Parameter aber auch unangetastet). Die Summe dieser Schwierigkeiten ist auch der Grund, warum wir das „kleine“ Falcon-Modell mit 7 Milliarden Parametern bisher nur in Google-Colab, also in der Cloud ausgeführt hatten (siehe nachfolgenden Artikel).

Fürs Inferencing, also das Benutzen eines schon trainierten Modells, muss die Software aber keine kleinen Schritte darstellen können. Multipliziert man die Neuronen-Aktivierungen mit Zahlen deutlich größer 1, kann man sogar mit ganzzahligen Gewichten weiterrechnen. Ganzzahlen berechnen sowohl CPUs als auch GPUs mit weniger Taktzyklen und wenn die wenige Bits lang sind, passen mehr davon nebeneinander in die Register der Vektor-Einheiten. Ein Modell so umzubauen, dass es mit kurzen Ganzzahlen rechnet, bezeichnet man als Quantisierung [2]. Für den Preis nicht trainierbar zu sein, lassen sich quantisierte Modelle viel schneller und auf weniger komplexer Hardware berechnen und verbrauchen viel weniger Speicher.

Die Entwickler von llama.cpp bezeichnen das Programm als Spielwiese für die Entwicklung der GGML-Bibliothek. GGML ist gleichzeitig ein Quantisierungsalgorithmus und ein Datenformat, um die Parameter von KI-Modellen zusammen mit Metainformationen zur Architektur in eine Datei zu packen. Beim Quantisieren ergibt sich schnell die Notwendigkeit für so ein Datenformat, weil das gleiche neuronale Netz an verschiedenen Stellen mit unterschiedlich langen Datentypen hantieren kann und bei großen Modellen viele Metainformationen anfallen, die man ohnehin gemeinsam mit den Parametern teilen muss.