llama-cookbook: Metas Rezeptsammlung für Llama, zwischen Notebook und Bibliothek

Ein Rezeptbuch, kein Framework

Das Repository trägt den Titel Cookbook und beschreibt sich selbst als offiziellen Leitfaden für den Einstieg in Inference, Fine-Tuning und End-to-End-Anwendungen mit der Llama-Modellfamilie. Wer hier eine Bibliothek mit installierbarer API erwartet, wird enttäuscht. Die README verweist auf drei getrennte Bereiche: getting-started für Referenzbeispiele, end-to-end-use-cases für vollständige Anwendungen und 3p-integrations für Rezepte verschiedener Anbieter. Der vierte Bereich, src, enthält laut README den Quellcode der ursprünglichen llama-recipes-Bibliothek samt FAQ zum Fine-Tuning. Genau dieser Satz markiert die Bruchlinie des Projekts: Ein Teil ist ausführbarer Bibliothekscode, der Rest ist Demonstrationsmaterial. Wer das übersieht, sucht in Notebooks nach Funktionen, die dort nie als Paket exportiert wurden. Die Zielgruppe sind Entwickler, die ein konkretes Problem lösen wollen (ein Modell auf eigenen Daten finetunen, eine RAG-Pipeline aufsetzen) und dafür einen Startpunkt brauchen, keinen Baukasten.

Wie die Beispiele aufgebaut sind und warum die Struktur zählt

Die primäre Sprache des Repositories ist Jupyter Notebook. Das ist keine Formalie, sondern bestimmt, wie man damit arbeitet. Notebooks lassen sich Zelle für Zelle ausführen, zeigen Zwischenergebnisse direkt an und eignen sich deshalb gut zum Erkunden. Für den Produktivbetrieb sind sie ein Umweg: Man muss den Code extrahieren, in Module überführen und die Abhängigkeiten selbst festnageln. Die Aufteilung in getting-started, end-to-end-use-cases und 3p-integrations spiegelt unterschiedliche Verbindlichkeitsstufen. Ein Rezept unter getting-started zeigt einen Mechanismus, etwa Inference mit einem bestimmten Provider oder einen Fine-Tuning-Lauf. Eine Anwendung unter end-to-end-use-cases kombiniert mehrere Schritte zu einem Ablauf, die README nennt als Beispiele einen WhatsApp-Bot, einen Analysator für Forschungsarbeiten und eine Figuren-Mindmap aus einem Buch. Die 3p-integrations decken Anbieterdienste ab. Wer den Code übernehmen will, sollte zuerst prüfen, in welchem dieser Zweige das betreffende Rezept liegt, weil sich der Reifegrad unterscheidet. Eine Aussage über die Qualität einzelner Rezepte lässt sich aus der Repository-Struktur allein nicht ableiten.

Llama 4, langer Kontext und die Modellversionen

Die README stellt Llama 4 an den Anfang und nennt fünf Rezepte: den Einstieg über die Llama API, eine WhatsApp-Integration, einen langen Kontext von 5M Token mit Llama 4 Scout, die Analyse von Forschungsarbeiten mit Llama 4 Maverick und eine Figuren-Mindmap, ebenfalls mit Maverick. Die Zahl 5M bezieht sich auf das Kontextfenster, das das Rezept demonstriert, nicht auf einen gemessenen Durchsatz. Wer diese Beispiele nachvollziehen will, braucht Zugang zu den entsprechenden Modellen oder zum Llama-API-Dienst, für den die README auf eine Warteliste verlinkt. Das ist eine praktische Hürde, die in der Beschreibung leicht untergeht: Ein Rezept im Repository garantiert nicht, dass der dahinterliegende Dienst ohne Anmeldung verfügbar ist. Die Modellkarten selbst liegen in einem separaten Repository, meta-llama/llama-models, auf das die README verlinkt. Wer wissen will, welche Modellversion welche Fähigkeiten hat, findet die Antwort dort und nicht im Cookbook. Das Cookbook zeigt den Umgang, nicht die Spezifikation.

Installation und die Frage nach den Abhängigkeiten

Die README nennt keine Installationsbefehle, keine Umgebungsvariablen und keine Versionsnummern für Abhängigkeiten. Wer das Repository nutzt, klont es und öffnet die Notebooks in einer eigenen Umgebung. Die Topics des Repositories nennen vllm, langchain, pytorch und python, was die erwarteten Bibliotheken umreißt, aber keine konkreten Pins liefert. Das ist ein bewusster Verzicht: Rezepte sollen sich schnell an neue Modellversionen anpassen lassen, was bedeutet, dass sie altern. Ein Notebook, das vor einem Jahr gegen eine bestimmte vllm-Version geschrieben wurde, kann mit einer neueren Version brechen. Wer ein Rezept produktiv übernehmen will, sollte die Abhängigkeiten selbst einfrieren und die Versionen im eigenen Projekt dokumentieren. Die FAQ der README behandelt genau diese Art von Reibung: Auf die Frage nach gebrochenen Links oder fehlenden Ordnern antwortet sie mit dem Hinweis auf den Refactor und den Snapshot-Branch archive-main. Wer einem älteren Blogbeitrag folgt und einen Pfad nicht findet, sucht dort.

Der Refactor und was er für Bestandsnutzer bedeutet

Das Repository hieß früher llama-recipes und wurde in llama-cookbook umbenannt. Die README beantwortet die naheliegende Frage direkt und verweist für den Zustand vor der Umstrukturierung auf den Branch archive-main. Für Teams, die Code aus der alten Bibliothek übernommen haben, ist das relevant: Der Bereich src enthält laut README den Quellcode der ursprünglichen llama-recipes-Bibliothek, aber die Struktur drumherum hat sich geändert. Wer ein Upgrade plant, muss also zwei Dinge trennen. Erstens, ob das eigene Projekt Code aus src nutzt, der weiterhin dort liegt. Zweitens, ob es Pfade aus der Zeit vor dem Refactor referenziert, die jetzt nur noch im Snapshot-Branch existieren. Die Versionshistorie stützt diese Einschätzung: Auf v0.0.4 und v0.0.4.post1 im September 2024 folgte v0.0.5 im Januar 2025. Die letzte Veröffentlichung liegt damit mehr als ein Jahr vor dem letzten Push auf main zurück. Das bedeutet nicht, dass das Repository verlassen ist, aber es bedeutet, dass die getaggten Releases nicht den aktuellen Stand der Rezepte abbilden. Wer reproduzierbare Builds braucht, sollte einen Commit-Hash pinnen statt einem Tag zu vertrauen.

Lizenzen: MIT für den Code, etwas anderes für die Modelle

Das Repository selbst steht unter MIT. Diese Angabe bezieht sich auf den Code und die Notebooks. Die README macht an mehreren Stellen deutlich, dass für die Modelle separate Lizenzdateien und Acceptable-Use-Policies gelten, verlinkt auf llama-models für Llama 2, 3, 3.1, 3.2, 3.3 und 4. Das ist der wichtigste Punkt für alle, die das Cookbook kommerziell nutzen wollen. Die MIT-Lizenz des Repositories erlaubt die freie Verwendung des Beispielcodes. Sie sagt nichts darüber aus, ob und unter welchen Bedingungen die Modellgewichte eingesetzt werden dürfen. Wer ein Fine-Tuning-Rezept übernimmt und das resultierende Modell ausliefert, muss die Lizenz der jeweiligen Modellversion lesen, nicht die des Cookbooks. Diese Trennung ist keine Formalie, sondern der häufigste Fehler bei der Übernahme solcher Beispiele. Eine rechtliche Bewertung kann und soll dieser Text nicht liefern, aber die Richtung ist klar: Die Lizenzdatei des Modells ist die maßgebliche, nicht die des Repositories.

Wann ein Framework die bessere Wahl ist

Der Unterschied zwischen einem Cookbook und einem Framework liegt im Vertrag. Axolotl ist ein Beispiel für ein Fine-Tuning-Framework mit Konfigurationsdateien, einer stabilen Kommandozeilenschnittstelle und einer Versionshistorie, die auf Wiederholbarkeit ausgelegt ist. Man beschreibt einen Trainingslauf in YAML, ruft ein Kommando auf und bekommt ein Modell. Das Cookbook geht den umgekehrten Weg: Es zeigt den Code, der den Lauf ausführt, und überlässt es dem Leser, daraus einen wiederholbaren Ablauf zu bauen. Für Experimente ist das ein Vorteil, weil man jeden Schritt sehen und ändern kann. Für einen nächtlichen Trainingsjob über mehrere Knoten ist es ein Nachteil, weil man die Orchestrierung selbst schreiben muss. Wer eine Pipeline betreibt, die regelmäßig läuft und bei der ein stiller Fehler teuer wird, ist mit einem Framework besser bedient. Wer verstehen will, was beim Fine-Tuning tatsächlich passiert, lernt aus dem Cookbook mehr, weil die Zwischenschritte sichtbar bleiben.

Wartung, Beiträge und der Stand der Dinge

Das Repository ist nicht archiviert, der letzte Push auf main datiert vom 19. Mai 2026, die letzte Veröffentlichung v0.0.5 vom 22. Januar 2025. Diese beiden Daten auseinanderzuhalten ist wichtig: Am Hauptzweig wird gearbeitet, die getaggten Releases hinken hinterher. Beiträge laufen laut README über CONTRIBUTING.md mit einem Verhaltenskodex und einem Pull-Request-Prozess. Wer ein Rezept reparieren will, weil sich eine Bibliotheks-API geändert hat, findet dort den Weg. Die Kosten für die Nutzung liegen weniger im Repository als in der Umgebung: Notebook-Abhängigkeiten müssen selbst gepinnt werden, Modellzugänge müssen separat beantragt oder beschafft werden, und die Lizenzprüfung pro Modellversion fällt dem Nutzer zu. Wer das einkalkuliert, bekommt eine breite Sammlung von Beispielen aus erster Hand. Wer erwartet, dass das Repository diese Arbeit abnimmt, wird sie unterschätzen.

Redaktionelles Fazit

Wer schnell einen lauffähigen Einstieg in Inference, Fine-Tuning oder RAG mit Llama sucht und bereit ist, Beispielcode an die eigene Umgebung anzupassen, findet hier eine breite Sammlung. Wer eine gepflegte Bibliothek mit stabiler API und Tests erwartet, sollte zu einem Framework wie Axolotl greifen. Vor dem ersten Commit in ein eigenes Projekt: prüfen, ob das Rezept unter src/ oder unter getting-started/ liegt, denn nur der src-Teil stammt aus der früheren llama-recipes-Bibliothek, und die Lizenzdatei des jeweiligen Modells separat lesen, weil die MIT-Angabe des Repositories nicht für die Gewichte gilt.

Offizielle Quellen

1. License: MIT
2. metainternal/llama-cookbook on GitHub
3. Project website
4. README
5. Releases