SWE-bench: Rangliste 2026 der Open-Source-LLMs zum Programmieren

Ein LLM lokal mit SWE-bench zu evaluieren ermöglicht es, die tatsächliche Fähigkeit eines Modells mit offenen Gewichten zur Behebung echter GitHub-Bugs zu messen — weit über HumanEval-Scores hinaus. SWE-bench für LLMs zeichnet sich dadurch aus, dass das Modell ein vollständiges Repository durchsuchen, ein Issue-Ticket verstehen, mehrere Dateien ändern und die Testsuite bestehen muss. Dieser Artikel erläutert die Funktionsweise des Benchmarks, die Variante SWE-bench Verified, die Hardwareanforderungen, geeignete Modelle aus dem Katalog und das Vorgehen bei der lokalen Ausführung. Anschließend beantwortet er häufige Fragen von Anwendern, die ihre Modelle selbst hosten.

Die Funktionsweise von SWE-bench verstehen

SWE-bench ist ein Benchmark, der 2023 von der Princeton University veröffentlicht wurde und 2.294 echte GitHub-Probleme aus 12 beliebten Python-Projekten (Django, scikit-learn, sympy, matplotlib usw.) zusammenstellt. Jede Aufgabe stellt dem Modell ein Repository auf dem Stand eines bestimmten Commits und die Beschreibung eines Issues zur Verfügung. Das LLM muss einen Patch erzeugen (diff) der nach seiner Anwendung zuvor fehlgeschlagene Tests bestehen lässt, ohne bestehende Tests scheitern zu lassen. Einzelheiten zur Erstellung des Datensatzes finden Sie im Originalpaper zu SWE-bench und das offizielles GitHub-Repository.

Im Gegensatz zu HumanEval, das kurze, isolierte Funktionen bewertet, misst SWE-bench:

• Kontextverständnis : ein Repository mit mehreren zehntausend Zeilen lesen
• Fehlerlokalisierung : ohne ausdrückliche Anleitung die richtigen Dateien ermitteln, die geändert werden müssen
• Bearbeitung mehrerer Dateien : einen konsistenten Patch erstellen, der nichts kaputt macht
• Schlussfolgern in langen Gedankengängen : zwischen Erkundung, Hypothese und Überprüfung wechseln

Ein Rohscore von 20 % bei SWE-bench entspricht häufig einem Score von über 80 % bei HumanEval. Das erklärt, warum viele Modelle bei HumanEval hervorragende Ergebnisse erzielen, bei SWE-bench jedoch einbrechen.

SWE-bench Verified: die gefilterte Version

SWE-bench Verified ist eine Teilmenge von 500 Instanzen, die von OpenAI in Zusammenarbeit mit den Autoren aus Princeton manuell annotiert wurden. Ziel ist es, Aufgaben zu entfernen, deren Aufgabenstellung mehrdeutig ist, deren versteckte Tests zu spezifisch sind oder deren Referenzpatch von einem nicht bereitgestellten Kontext abhängt. Vollständige Details finden Sie im Blog von OpenAI zum Thema Verified.

Für einen lokalen Test, SWE-bench Verified ist die richtige Wahl :

• 500 Instanzen statt 2.294: Ausführung in wenigen Tagen auf einer Workstation möglich
• Zuverlässigere Beurteilung des tatsächlichen Schlussfolgerungsvermögens des Modells
• Direkter Vergleich mit den von den Anbietern veröffentlichten Scores

Der am häufigsten verwendete Referenzagent ist SWE-agent, ein Ausführungsframework, das dem LLM ein interaktives Terminal bereitstellt und ihm ermöglicht, Dateien zu bearbeiten, Befehle auszuführen und Tests durchzuführen. Eine beliebte Alternative ist OpenHands, mit nativer Unterstützung für OpenAI-kompatible Backends (vLLM, llama.cpp server, SGLang).

Für den Benchmark geeignete Modelle aus dem Katalog

Der LLM für einen Programmieragenten muss ein großes Kontextfenster (das Agenten-Framework speist Stacktraces, Quellcode und den Verlauf der Aktionen ein) mit guten Leistungen beim Schlussfolgern verbinden. Hier sind die Kandidaten aus dem Katalog, nach Hardwareprofil sortiert.

Workstations mit sehr hohem VRAM-Budget (≥ 400 GB)

• DeepSeek V3.2 (685B, MIT) — VRAM Q4 ~410 GB, ctx 128k. Laut unabhängigen Bewertungen derzeit die Referenz unter den Open-Weights-Modellen auf SWE-bench Verified.
• DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB, ctx 128k. Reasoning-Modell mit langen Schlussfolgerungsketten, besonders geeignet zur Lokalisierung von Bugs.
• Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB, ctx 256k. Permissive Lizenz, interessant für den kommerziellen Einsatz.
• Kimi K2.6 (1000B, Modified MIT) — VRAM Q4 ~600 GB, ctx 256k. Laut Moonshot für agentbasierte Workflows optimiert.

Cluster mit mehreren GPUs (140–250 GB)

• Qwen 3 235B-A22B (235B, Apache 2.0) — VRAM bei Q4 ~142 GB, Kontext 131k. MoE mit 22B aktiven Parametern, gutes Verhältnis von Kosten zu Qualität.
• Llama 4 Maverick 400B (400B, Llama 4 Community) — VRAM Q4 ~240 GB, ctx 1M. Außergewöhnlich großes Kontextfenster für große Code-Repositories.
• GLM-5.1 (744B, MIT) — VRAM Q4 ~445 GB, ctx 200k.

Einzelne Workstation (≤ 80 GB)

• Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 ~48 GB, ctx 262k. Spezialisiert für Code, ausführbar auf einer A100 80GB oder zwei 3090.
• gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB, ctx 128k. Modell von OpenAI, dessen Gewichte offen veröffentlicht wurden.
• Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB, ctx 256k.

Für einen detaillierten Vergleich im Bereich des Codes siehe Qwen3-Coder vs DeepSeek V3.2 und die Seite bester LLM für Code.

Tokens pro Sekunde und Auswirkungen auf die Laufzeit

Ein vollständiger SWE-bench-Verified-Durchlauf verbraucht je nach Test-Harness und Anzahl der erlaubten Versuche zwischen 500 Millionen und 2 Milliarden Tokens. Der Durchsatz in Tokens pro Sekunde bestimmt daher direkt die Dauer des Benchmarks.

Ungefähre Schätzwerte (mit Ihrer Konfiguration zu bestätigen) :

• DeepSeek V3.2 auf 8×H100 80GB in Q4: ~25 Tokens/s bei der Generierung, geschätzte Dauer des Verified-Durchlaufs zwischen 5 und 8 Tagen
• Qwen 3 235B-A22B auf 4×H100: ~40 Tokens/s in Q4 (die MoE-Architektur mit 22B aktiven Parametern hilft dabei), geschätzte Laufzeit: 3 bis 5 Tage
• Qwen3-Coder-Next 80B-A3B auf 2×A100 80GB: ~60 Tokens/sec in Q4, geschätzte Laufzeit von 2 bis 3 Tagen
• gpt-oss 120B auf 1×H200 141GB in Q4: ~35 Tokens/s, geschätzte Laufzeit 3 bis 4 Tage

Das effektive Kontextfenster ist ebenso wichtig wie die reine Geschwindigkeit: SWE-agent fügt regelmäßig 30.000 bis 60.000 Tokens in den Prompt ein, um den Zustand des Repositorys zu rekonstruieren. Ein Modell mit einem auf 32.000 Tokens begrenzten Kontextfenster ist dafür schlecht geeignet; streben Sie mindestens 128.000 Tokens an. Siehe auch den VRAM-Leitfaden nach Quantisierung um Ihr Speicherbudget anzupassen.

Verfahren zur lokalen Ausführung

Hier ist ein vereinfachtes Vorgehen für eine strikt selbst gehostete Einrichtung.

1. Docker-Umgebung vorbereiten : SWE-bench Verified benötigt Docker-Images für jedes Projekt (Django, sympy usw.), um die Testausführung zu isolieren. Planen Sie 80 GB Festplattenspeicher für die offiziellen, von den Maintainern veröffentlichten Images ein.

2. Einen OpenAI-kompatiblen Inferenzserver starten : mit vLLM oder llama.cpp im Servermodus, stellen Sie Ihr Modell bereit localhost:8000/v1. Für Qwen3-Coder-Next in Q4 auf 2×A100 verwendet ein typischer vLLM-Befehl die Optionen --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.

3. SWE-agent klonen und den Test-Harness so konfigurieren, dass er den lokalen Endpunkt verwendet. Die Konfigurationsdatei akzeptiert api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.

4. Einen Kalibrierungslauf starten auf 10 bis 20 Instanzen, um zu überprüfen, ob die Formatierung der Aktionen eingehalten wird. Viele Modelle mit offenen Gewichten scheitern hier, weil sie XML-Tags erfinden, die die Testumgebung nicht erkennt.

5. Vollständiger Durchlauf : 500 Instanzen, mehrere Tage, systematisch die generierten Patches protokollieren, um eine nachträgliche Analyse durchzuführen.

6. Optionale Einreichung au offizielle Rangliste für einen öffentlichen Vergleich.

Praktischer Tipp: Begrenzen Sie die Anzahl der Aktionen pro Instanz (50–75), um zu verhindern, dass ein Modell in eine Endlosschleife gerät, die Ihr Token-Budget aufbraucht.

Interpretation der Ergebnisse

Ein Rohwert bei SWE-bench Verified ist relativ zu interpretieren, nicht absolut.

• < 10 % : das Modell beherrscht das Aktionsformat des Agenten nicht, oder sein Kontext ist zu kurz
• 10-25 % : ordentliches Leistungsniveau für ein vielseitiges Open-Weights-Modell
• 25-50 % : erwarteter Leistungsstand eines spezialisierten Reasoning-Modells (DeepSeek R1 671B, Kimi K2.6)
• > 50 % : Spitzenniveau, das die besten proprietären Modelle erreichen

Achten Sie über den Score hinaus auf die Verteilung der Fehlschläge : Tests, bei denen das Zeitlimit überschritten wird, Patches, die sich nicht anwenden lassen, Dateien, die außerhalb des vorgesehenen Änderungsumfangs geändert werden. Diese Analyse zeigt häufig, dass das Modell nicht durch seine Schlussfolgerungsfähigkeit, sondern durch den Test-Harness (Fenstergröße, Parsing der Aktionen) begrenzt wird. Für weiterführende Informationen zur Auswahl eines Modells für KI-Agenten lesen Sie den Leitfaden zu LLMs für Agenten.

FAQ

F: SWE-bench oder SWE-bench Verified für einen ersten Test?

Verified, ohne Zweifel. Die 500 Instanzen sind manuell annotiert, Mehrdeutigkeiten wurden entfernt, und die Ausführungszeit bleibt auf einer einzelnen Workstation vertretbar. Der vollständige SWE-bench (2.294 Instanzen) enthält unzureichend spezifizierte Aufgaben, die Modelle ungerecht benachteiligen. Verified ermöglicht außerdem einen direkten Vergleich mit den von Anbietern proprietärer Modelle veröffentlichten Ergebnissen.

F: Welche Quantisierung wählen, um den Code-Score zu erhalten?

Q4_K_M (GGUF) oder AWQ 4-Bit senken den SWE-bench-Score gegenüber FP16 typischerweise um 1 bis 3 Punkte, was weiterhin akzeptabel ist. Vermeiden Sie Q3 und Q2 bei Reasoning-Modellen, bei denen der Verlust erheblich wird. Wenn Ihr VRAM ausreicht, bieten Q5_K_M oder Q8 ein besseres Verhältnis. Siehe den Vergleich der Quantisierung GGUF vs AWQ.

F: Ist ein spezialisiertes „Coder“-Modell oder ein Allzweckmodell erforderlich?

Beide Profile funktionieren. Auf Code spezialisierte Modelle wie Qwen3-Coder-Next 80B-A3B zeichnen sich durch die Generierung von Patches aus, aber universell einsetzbare Reasoning-Modelle wie DeepSeek R1 671B sind bei der Fehlerlokalisierung und der mehrstufigen Planung oft überlegen; diese beiden Aspekte machen den größten Teil der Kosten einer SWE-bench-Aufgabe aus.

F: Kann SWE-bench Verified auf einer einzigen RTX 4090 ausgeführt werden?

Schwierig. 24 GB VRAM begrenzen die Auswahl auf Modelle mit ≤ 30B in Q4, und diese Modelle erreichen auf Verified aufgrund unzureichender Schlussfolgerungsfähigkeiten in der Regel weniger als 10 %. Sie können es verwenden, um Ihre Pipeline mit einem leichtgewichtigen Modell wie Qwen3-Coder-Next mit teilweisem CPU-Offload zu validieren, sollten für ein brauchbares Ergebnis aber eher 2×3090 oder 1×A100 80GB anstreben.

Q: Wie viele Tokens verbraucht ein vollständiger Lauf?

Geschätzt werden zwischen 500 Millionen und 2 Milliarden Tokens, abhängig von der Testumgebung (SWE-agent, OpenHands, custom) und der maximal zulässigen Anzahl von Aktionen pro Instanz. Bei einem Budget von 50 Aktionen pro Instanz und einem durchschnittlichen Kontext von 30.000 Tokens sollten Sie für 500 Instanzen mit etwa 1 Milliarde Tokens rechnen. Je mehr das Modell in einer Gedankenkette „nachdenkt“ (R1-Stil), desto höher fällt die Tokenrechnung aus.

F: Sind die lokalen Ergebnisse mit den Punktzahlen auf dem Leaderboard vergleichbar?

Ja, sofern Sie den offiziellen Test-Harness und dieselbe Version des Datensatzes verwenden und das Einreichungsprotokoll einhalten (nur ein Patch pro Instanz, keine erneuten Versuche mithilfe eines Orakels). Jede Änderung am Test-Harness oder am Systemprompt muss dokumentiert werden. Die SWE-bench-Leaderboard akzeptiert Einreichungen aus selbst gehosteten Umgebungen und prüft die Reproduzierbarkeit.

Fazit

Ein lokaler SWE-bench-Lauf mit einem LLM bleibt der aussagekräftigste Test, um ein Open-Weights-Modell für Code von einem Modell zu unterscheiden, das lediglich bei HumanEval gut abschneidet. Mit SWE-bench Verified, einer Workstation mit 2×A100 oder 4×H100 und einem geeigneten Modell (Qwen3-Coder-Next, DeepSeek V3.2 oder gpt-oss 120B), ein realistischer Lauf dauert einige Tage. Um Ihr Setup vor dem Benchmark zu kalibrieren, verwenden Sie den Konfigurations-Tool von quelllm.fr oder durchsuchen Sie den komplettes Katalog.