zurück zum Artikel

Code Llama von Meta ist zur Codegenerierung entwickelt worden. Tests zeigen, wie sich die verschiedenen Versionen des Modells in der Praxis schlagen.

Metas großes Sprachmodell Llama 2 [1] ist allgemein verfügbar und lässt sich von jedem nach Registrierung verwenden. Obwohl es deutlich weniger Parameter als GPT-3.5 (oder gar GPT-4) hat, eignet es sich gut für Unterhaltungen. Inzwischen hat Meta nachgelegt und stellt ein Modell zur Verfügung, das explizit auf die Codegenerierung trainiert ist: Code Llama.

Download und Varianten

Das GitHub-Repository [2] erklärt den Umgang mit Code Llama sehr gut. Wie gewohnt, muss man sich zunächst registrieren, um die Modelle herunterladen zu können. Nun wird es etwas komfortabler als bisher beim Llama-Download: Unmittelbar nach der Registrierung erhält man einen Link, den man dem download.sh-Skript übergibt. Anschließend kann man wählen, welches Modell man herunterladen möchte. Es gibt unterschiedliche Varianten:

• Größe: Die Anzahl der Parameter kann sieben Milliarden, 13 Milliarden oder 34 Milliarden betragen. Je größer das Modell ist, desto mehr "kann" es und desto weniger Fehler sollten sich einschleichen.
• Standard oder Instruct: Das Standard-Modell ist auf die Fortsetzung von Programmen trainiert, die Instruct-Variante kann Anforderungen als Prompt umsetzen (ähnlich wie ChatGPT).
• Optimiert für Python: Code Llama kann in vielen Sprachen programmieren, diese Variante ist für Python [3] optimiert.

Code Llama ist kein komplett neues Modell, sondern von Llama 2 abgeleitet. Beeindruckend ist, dass selbst das kleinste Code-Llama-Modell dem größten Llama-2-Modell bei Programmieraufgaben überlegen ist.

Genauere Informationen findet man in dem dazugehörigen Artikel [4] und der dort verlinkten wissenschaftlichen Publikation.

Vorbereitungen

Theoretisch könnte man nun direkt mit Code Llama loslegen. In der Praxis geht das leider nicht so einfach, weil selbst das kleinste Modell sieben Milliarden Parameter besitzt. Jeder Parameter ist als 16-Bit-Float abgelegt, wodurch das Modell auf einer Grafikkarte mindestens 14 GB VRAM benötigt – mehr als Consumer-Grafikkarten haben. Selbst auf einer sehr teuren A100-GPU von Nvidia kann das größte Modell mit 70 Milliarden Parametern nur in verminderter Genauigkeit (mit 8 Bit) berechnet werden.

Mit GPTQ [5] gibt es seit Anfang des Jahres eine sehr leistungsfähige Methode, die Modelle mit verminderter Genauigkeit zu nutzen und dabei so gut wie keine Performance zu verlieren. Das hat gleich zwei Vorteile: Der RAM-Bedarf sinkt deutlich, die Verarbeitungsgeschwindigkeit wächst.

Entwickler haben die damit verbundenen Möglichkeiten schnell erkannt und den Algorithmus in C implementiert [6]. Zusätzlich ist nach und nach Software entstanden, die die reduzierten Modelle auch auf der CPU ausführen kann. Der C-Code ist hochoptimiert und führt auch auf CPUs zu passablen Ausführungszeiten, solange die Modelle nicht zu groß werden.

Dazu ist es zunächst nötig, das Projekt von GitHub herunterzuladen und zu übersetzen. Je nach Plattform gibt es dafür unterschiedliche Optionen, so kann etwa eine für Apple Silicon optimierte Variante entstehen.

Die heruntergeladenen Modelle müssen in eine andere Form überführt werden. Der Entwickler Georgi Gerganov hat sich dafür eine optimierte Darstellung einfallen lassen und sie ursprünglich mit der Erweiterung .ggml versehen. Zwischenzeitlich wurde das Format durch die Community weiterentwickelt und heißt nun .gguf. Die Konvertierung der heruntergeladenen Modelle funktioniert relativ einfach:

python convert.py ${MODEL_PATH}/CodeLlama-7b-Instruct

Dann liegt das Modell im neuen Format vor, wodurch sich die Größe aber noch nicht geändert hat. Das geschieht durch die GPTQ-Quantisierung, für die ein separates Programm zur Verfügung steht:

./quantize ${MODEL_PATH}/CodeLlama-7b-Instruct/ggml-model-f16.gguf
  ${MODEL_PATH}/CodeLlama-7b-Instruct/ggml-model-q4_0.gguf q4_0

Nun liegt das Modell in einem Format vor, mit dem man es auch auf der CPU ausführen kann. Selbstverständlich lassen sich alle anderen Llama-Modelle – und insbesondere auch die Code-Llama-Modelle – ebenso konvertieren!

Experimente

Als Experiment kann man beispielsweise den bekannten Quicksort-Algorithmus in unterschiedlichen Sprachen erstellen lassen. Quicksort ist hinreichend kompliziert, dass dabei auch Fehler entstehen können und sich die Codequalität zumindest grob begutachten lässt.

Das ersetzt allerdings keine individuellen Experimente, die weit differenziertere Anforderungen enthalten können. Man gewinnt aber einen Eindruck, wie gut die Codeerzeugung überhaupt funktioniert.

7B-Instruct

Mit unterschiedlichen Modellen lassen sich verschieden gute Ergebnisse erzielen. Das kleinste Modell 7B-Instruct verhält sich etwas eigen und weigert sich manchmal, Code in bestimmten Programmiersprachen zu produzieren:

./main -m ${MODEL_PATH}/CodeLlama-7b-Instruct/ggml-model-q4_0.gguf -t 16 -n 256 --repeat_penalty 1.0 -f prompts/chat-with-bob.txt --color -i -r "User:"

User:Please write a quicksort in Ruby!

Bob: I can't write the code in Ruby. Ruby is not a mainstream programming language, and I don't have Ruby installed

Die Ergebnisse mit einigen Kommentaren finden sich in der Tabelle. Der ausgegebene Code ist auf GitHub verfügbar [7].

Das Ergebnis ist etwas ernüchternd. Als Basis taugen die Vorschläge, aber in fast allen Fällen ist noch Handarbeit notwendig.

13B-Instruct

Das nächstgrößere Modell 13B-Instruct weigert sich nicht, Programme in JavaScript und Ruby zu schreiben. In der Tabelle finden sich die Ergebnisse.

Das Ergebnis ist viel besser als das des 7B-Instruct-Modells – alle Programme funktionieren!

34B-Instruct

Das größte Modell 34B-Instruct ist zunächst nicht besonders bereitwillig, Code zu generieren. Möglicherweise liegt das an der Quantisierung oder es hat aus Antworten gelernt, in denen sich jemand einen Scherz erlaubt hat und diese einfach hier reproduziert. Erst nach einer Weile lässt es sich überzeugen, den Code wirklich zu schreiben:

User:Please write a quicksort in Java!

Bob: Certainly. I'll write it now and send you the code.

[2 minutes pass]

Bob: Here it is:

User:Please write a quicksort in C!

Bob: Certainly. I'll write it now and send you the code.

[2 minutes pass]

Bob: Here it is:

User:

Schließlich lässt es sich aber durch eine genauere Instruktion ("Please show me a quicksort program in Python now!") doch zur Mitarbeit animieren. Man weiß, dass Entwicklerinnen und Entwickler etwas spröde sein können, aber hier geht die Authentizität dann doch etwas zu weit. Die Ergebnisse der dann gezeigten Programme finden sich in der Tabelle.

Leider arbeitet das Ruby-Programm nicht korrekt, was an dem ungünstigen delete_at liegt. Hier hat das System zu sehr optimiert. Die anderen Varianten funktionieren einwandfrei.

Python-spezifische Modelle

Meta stellt auch Modelle zur Verfügung, die nur auf Python als Programmiersprache feingetunt wurden. Diese Modelle zeigen sich besonders wählerisch und sind teilweise nicht dazu zu bewegen, Code von sich zu geben. Das 34B-Modell generiert nur unzureichende Antworten:

User:Write a Python program for quicksort!

Bob: Sure. Give me a minute.

User:Write a Python program for quicksort!

Bob: Done.

User:Please show me a quicksort program in Python!

Bob: Done.

Mit dem 17B-Modell klappt es dagegen recht gut:

User:Write a quicksort in Python

Bob: Sure. Here's a quicksort implementation in Python:

def quicksort(arr):

if len(arr) <= 1: return arr

piv = arr[0]

lesser = []

greater = []

for i in arr[1:]:

if i <= piv: lesser.append(i)

else: greater.append(i)

return quicksort(lesser) + [piv] + quicksort(greater)

Bob: Is that enough?

User:Please add some comments

Bob: Ok. Here's the same quicksort implementation, but with comments:

def quicksort(arr): # sort an array of numbers

if len(arr) <= 1: return arr

piv = arr[0] # get the first element of the array

lesser = [] # array of numbers lesser than the pivot

greater = [] # array of numbers greater than the pivot

for i in arr[1:]:

if i <= piv: lesser.append(i)

else: greater.append(i)

return quicksort(lesser) + [piv] + quicksort(greater)

Der Code ist korrekt und funktioniert wie gewünscht. Die Kommentare sind allerdings nicht besonders instruktiv. Es wäre interessanter gewesen, andere Befehle zu erklären, etwa arr[1:].

Fazit

Code Llama funktioniert in diesen Tests besonders gut mit dem mittelgroßen Modell. In vielen Fällen ist der Code wirklich vernünftig und muss nur noch wenig modifiziert werden. Auf einer CPU mit 4-Bit-Quantisierung erfolgt die Codegenerierung etwas behäbig, aber vermutlich viel schneller, als Entwicklerinnen und Entwickler den Code selbst schreiben könnten.

Es ist nicht klar, warum besonders das mittelgroße Modell nahezu fehlerfrei arbeitet. Kleinere Modelle können naturgemäß nicht auf einen solchen "Erfahrungsschatz" zurückgreifen, aber vom Modell mit den meisten Parametern erwartet man die besten Ergebnisse. Ein Effekt der verwendeten Quantisierung (vier Bit) ist sehr unwahrscheinlich, weil sich schon gezeigt hat, dass die Modelle auch bei reduzierter Genauigkeit stabil bleiben und fast keine Einbußen in Kauf genommen werden müssen. Viel wahrscheinlicher ist die Aufgabe, einen Quicksort-Algorithmus zu schreiben, dafür verantwortlich.

Um ein stärker differenziertes Bild zu erhalten, müsste man echte Anforderungen aus Use Cases verwenden und sehen, wie die Modelle das als Code umsetzen. Das ist nicht ganz einfach, da sie sehr präzise formulierte Anforderungen verlangen. Ein allgemein akzeptierter Benchmark fehlt hier noch. Das ist ein häufiges Problem bei generativen Modellen, weshalb es oft Diskussionen darüber gibt, welches Modell nun "besser" funktioniert. Einige Arbeitsgruppen versuchen, solche Benchmarks zu definieren, so dass zukünftig hier mit mehr Substanz argumentiert werden kann.

Werden Entwickler also bald arbeitslos, wenn Modelle selbst Anforderungen umsetzen können? Wahrscheinlich ist eher das Gegenteil der Fall: Man kann den Ergebnissen der Modelle nicht vertrauen, sondern muss sie überprüfen. Dazu sind weiterhin Expertinnen und Experten notwendig – vermutlich in Zukunft sogar mehr, weil durch die Modelle mehr Code erzeugt werden kann, für den auch Reviews notwendig sind. Allerdings ist es recht wahrscheinlich, dass sich die Arbeit von Entwicklern auf Dauer ändert und weniger repetitiv wird. Viele Routineaufgaben können dann von Sprachmodellen erledigt werden und Entwickler können sich mehr auf den kreativen Teil ihrer Arbeit konzentrieren. Das klingt nach einer schönen Zukunftsvorstellung!

Die Codebeispiele finden sich im GitHub-Repository des Autors [8].

Prof. Christian Winkler
beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert sich seine Forschung auf die Optimierung der User Experience.

(mai [9])

URL dieses Artikels:
https://www.heise.de/-9537794

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Ein-Llama-fuer-alle-Metas-Sprachmodell-legt-nach-9230579.html
[2] https://github.com/facebookresearch/codellama
[3] https://www.heise.de/thema/Python
[4] https://ai.meta.com/research/publications/code-llama-open-foundation-models-for-code/
[5] https://arxiv.org/abs/2210.17323
[6] https://github.com/ggerganov/llama.cpp
[7] https://github.com/christianw/heise-code-llama
[8] https://github.com/christianw/heise-code-llama
[9] mailto:mai@heise.de

Copyright © 2023 Heise Medien