Modell / Datensatz
salesforce/CodeGen avatar
salesforce/CodeGen

CodeGen von Salesforce: eine Modellfamilie für Programmsynthese im Transformers-Format

CodeGen is a family of open-source model for program synthesis. Trained on TPU-v4. Competitive with OpenAI Codex.

5.180 Sterne420 ForksPythonApache-2.0
GitHub

Auf einen Blick

Was ist das?
Das Repository liefert Gewichte und Ladebeispiele für CodeGen1, CodeGen2 und CodeGen2.5, nicht aber ein fertiges Werkzeug. Wer die Modelle über Hugging Face einbindet, sollte die Lizenz und den Trainingsstand vor dem Einsatz prüfen.
Für wen ist es gedacht?
Wer eine vortrainierte Code-Grundlage für Experimente mit Multi-Turn-Synthese sucht und bereit ist, Jaxformer oder eigene Datenpipelines selbst zu bauen, findet hier brauchbare Gewichte. Wer ein Werkzeug mit Server, Kontextanreicherung oder Auswertung sucht, ist falsch.
Darf ich es kommerziell nutzen?
Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 105 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich Python, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Was CodeGen liefert und was nicht

Das Repository ist die offizielle Veröffentlichung der CodeGen1- und CodeGen2-Modelle von Salesforce AI Research, laut README in den Größen 350M, 1B, 3B, 7B und 16B. Hinzu kommt CodeGen2.5, das im Juli 2023 veröffentlicht wurde und nach Angaben der Release Notes 16B-Modelle mit nur 7B Parametern übertrifft. Der Anspruch aus dem Repository-Titel ist Programmsynthese, also das Erzeugen von Code aus natürlichsprachlichen oder Code-Anfängen. Wer eine Bibliothek mit Kommandozeilenwerkzeug, Server oder Auswertungslogik erwartet, wird enttäuscht: Das README beschreibt Gewichte, Ladebeispiele und Zitationen, mehr nicht. Die eigentliche Arbeit, nämlich Datenaufbereitung, Training und Feinabstimmung, liegt im separaten jaxformer-Repository, auf das die Trainingssektion verweist. Damit ist CodeGen weniger ein Produkt als eine Modellablage mit Beispielcode.

Drei Generationen mit unterschiedlichen Ladeanforderungen

Die Ladebeispiele im README unterscheiden sich je Generation, und diese Unterschiede sind praktisch relevant. CodeGen1 wird über AutoModelForCausalLM.from_pretrained("Salesforce/codegen-2B-mono") ohne zusätzliche Flags geladen. Bei CodeGen2 taucht erstmals trust_remote_code=True auf, zusammen mit revision="main". CodeGen2.5 setzt ebenfalls trust_remote_code=True, aber nur beim Tokenizer, während das Modell ohne dieses Flag geladen wird. Wer diese Zeilen blind kopiert, übersieht schnell, dass trust_remote_code bedeutet, dass beim Laden Code aus dem Modell-Repository ausgeführt wird. Das ist kein Detail, sondern eine Vertrauensentscheidung. Die README-Beispiele zeigen außerdem, dass die Ausgabe bei CodeGen1 und CodeGen2 mit truncate_before_pattern beschnitten wird, bei CodeGen2.5 dagegen nicht. Diese Inkonsistenz deutet darauf hin, dass die Generation sich zwischen den Versionen unterschiedlich verhält, ohne dass das README erklärt, warum.

Der Mechanismus: kausales Sprachmodell mit Infill-Fähigkeit

Technisch handelt es sich um kausale Sprachmodelle für AutoModelForCausalLM, also um Dekodierer, die Token für Token vorhersagen. Das README nennt für CodeGen2.0 eine starke Infill-Sampling-Fähigkeit. Infill heißt, dass das Modell Lücken in vorhandenem Code füllen kann, nicht nur fortlaufend anhängen. Genau das ist der Unterschied zu einem reinen Completion-Modell. Der Ablauf im Beispiel ist schlicht: tokenizer(...) erzeugt Eingabetensoren, model.generate(**inputs, max_length=128) erzeugt eine Sequenz, tokenizer.decode gibt sie als Text zurück. Die Angabe max_length=128 begrenzt die Gesamtlänge, nicht nur die neu erzeugten Token. Wer längere Ausgaben braucht, muss diesen Wert anpassen, sonst schneidet die Generierung ab, bevor der Code fertig ist. Ein Kontextfenster oder eine Angabe zur maximalen Eingabelänge fehlt im README. Das ist eine Lücke, die sich nur über die Modellkarten auf Hugging Face klären lässt, nicht über dieses Repository.

Installation und der erste Lauf

Das Repository nennt keine Installationsanleitung, keine requirements.txt und keinen Setup-Befehl. Die Beispiele setzen torch und transformers voraus, ohne Versionen zu nennen. Wer den Code ausführt, braucht also beides, und bei CodeGen2 und CodeGen2.5 zusätzlich eine Transformers-Version, die trust_remote_code unterstützt. Die Gewichte selbst liegen auf dem Hugging Face Hub unter Modell-IDs wie Salesforce/codegen-2B-mono, Salesforce/codegen2-7B und Salesforce/codegen25-7b-mono. Das bedeutet: Der erste Lauf lädt mehrere Gigabyte herunter, abhängig von der gewählten Größe. Für 7B und 16B ist eine GPU praktisch unvermeidbar, für 350M und 1B kann ein Lauf auf CPU je nach Geduld funktionieren. Das README gibt dazu keine Angaben. Wer den Einstieg plant, sollte mit einer kleinen Variante beginnen, weil die Ladebeispiele identisch aufgebaut sind und sich nur die Modell-ID ändert.

Lizenz und der Hinweis auf Forschungszwecke

Das Repository trägt die Lizenz Apache-2.0. Gleichzeitig enthält das README einen Abschnitt mit dem Titel Ethics disclaimer for Salesforce AI models, data, code, der die Veröffentlichung als for research purposes only in support of an academic paper bezeichnet. Das ist keine Lizenzänderung, aber eine ausdrückliche Erwartung des Herausgebers. Wer CodeGen in einem Produkt einsetzen will, sollte diesen Widerspruch nicht überlesen: Eine permissive Lizenz und ein Forschungsvorbehalt im README stehen nebeneinander, und ob die Modellkarten auf Hugging Face zusätzliche Bedingungen tragen, sagt dieses Repository nicht. Der Disclaimer verweist außerdem auf die Acceptable-Use-Policies von Salesforce. Eine rechtliche Bewertung kann hier nicht stattfinden, aber die Prüfung der konkreten Modellkarte vor dem Einsatz ist unumgänglich, weil Lizenzangaben pro Modell abweichen können.

Wo CodeGen nicht passt

CodeGen ist ein Basismodell, kein Assistent. Wer Code in einer bestehenden Codebasis ergänzen will, braucht Kontext aus dem Repository, also Abruf relevanter Dateien, Rangfolge und Einbettung in den Prompt. Nichts davon ist hier enthalten. Auch eine Auswertung, ob der erzeugte Code kompiliert oder Tests besteht, fehlt vollständig. Das Modell liefert Text, der wie Code aussieht, und das README macht keine Aussage über Korrektheit. Ein weiterer Grenzfall: Wer ein feinabgestimmtes Modell für eine bestimmte Sprache oder ein bestimmtes Framework braucht, muss selbst trainieren und landet damit im jaxformer-Repository. Dort gelten andere Anforderungen an Hardware und Datenaufbereitung, die in diesem Repository nicht dokumentiert sind. Für Aufgaben mit hohen Anforderungen an Reproduzierbarkeit und Nachvollziehbarkeit ist ein Basismodell ohne Auswertungsschicht die falsche Grundlage.

Was andere anders machen: StarCoder und SantaCoder

Der naheliegende Vergleich sind die Code-Modelle von BigCode, etwa StarCoder und SantaCoder. Der Unterschied liegt weniger in der Architektur als im drumherum: BigCode veröffentlicht Datenaufbereitung, Trainingsdetails und Auswertungen zusammen mit den Gewichten, während CodeGen die Trainingspipeline in ein separates Repository auslagert und im Hauptrepository nur Ladebeispiele zeigt. Ein weiterer Unterschied ist die Zielsetzung. CodeGen1 wurde laut README auf TPU-v4 trainiert und war zum Zeitpunkt der Veröffentlichung auf Augenhöhe mit OpenAI Codex. Das ist eine historische Aussage über 2022, keine über den heutigen Stand. Wer heute ein Modell für CodeCompletion in einer IDE sucht, findet bei neueren Modellen mehr Dokumentation zu Kontextlänge und Feinabstimmung. CodeGen bleibt interessant für alle, die den Trainingsweg über Jaxformer nachvollziehen oder eigene Varianten auf dieser Grundlage bauen wollen.

Wartung, Upgrades und was zu prüfen bleibt

Das Repository wurde zuletzt am 2. Juni 2026 aktualisiert und ist nicht archiviert. Es gibt keine abgerufenen Releases, also keine versionierten Pakete, an denen man sich orientieren könnte. Upgrades bedeuten hier in der Praxis: eine andere Modell-ID auf Hugging Face wählen, etwa von codegen-2B-mono auf codegen2-7B oder codegen25-7b-mono. Ein API-Versionsvertrag existiert nicht, weil das Repository keine API bereitstellt. Die Kosten eines Wechsels liegen im Speicherbedarf und in der Anpassung des Ladecodes, weil sich die Flags zwischen den Generationen unterscheiden. Wer heute auf CodeGen setzt, sollte die Modellkarte der gewählten Variante lesen, die Transformers-Version gegen trust_remote_code prüfen und mit einer kleinen Variante beginnen, bevor GPU-Speicher für 7B oder 16B gebunden wird.

Redaktionelles Fazit

Wer eine vortrainierte Code-Grundlage für Experimente mit Multi-Turn-Synthese sucht und bereit ist, Jaxformer oder eigene Datenpipelines selbst zu bauen, findet hier brauchbare Gewichte. Wer ein Werkzeug mit Server, Kontextanreicherung oder Auswertung sucht, ist falsch. Vor dem Einsatz sind drei Dinge zu klären: ob die Apache-2.0-Datei im Repository tatsächlich alle Gewichte abdeckt, ob die genutzte Transformers-Version den Parameter trust_remote_code für die gewählte Variante akzeptiert, und ob die Modellkarte der konkreten Variante die Nutzung erlaubt, die geplant ist.

Offizielle Quellen

  1. Issues
  2. License: Apache-2.0
  3. README
  4. salesforce/CodeGen on GitHub
Community-Notizen

Community-Notizen