Lokale Coding-LLMs für Python vergleichen: Ein Verfahren für dein Homelab

Lokale Coding-LLMs für Python vergleichen: Ein Verfahren für dein Homelab

Ein lokales Coding-LLM kann eine Python-Aufgabe überzeugend erklären und trotzdem Code liefern, der an einem Testfall scheitert. Für dein Homelab zählt deshalb mehr als die Frage, ob ein Modell auf deiner Hardware startet: Es muss deine Aufgaben lösen, in annehmbarer Zeit antworten und mit den verfügbaren Ressourcen auskommen.

Hier vergleichst du Modelle anhand derselben Python-Aufgaben und hältst die Bedingungen nachvollziehbar fest. Es geht weder um eine Rangliste aktueller Modellnamen noch um eine allgemeine Hardware-Kaufberatung. Die Auswahl von GPU, RAM und Software behandelt unser Ratgeber zum KI-Homelab-Setup; hier arbeitest du mit der vorhandenen Hardware.

Warum öffentliche Benchmarks nicht reichen

Ranglisten auf Basis bekannter Code-Benchmarks sagen weniger über deinen Alltag aus, als die Zahlen vermuten lassen. Die Autoren von LiveCodeBench fanden Hinweise darauf, dass viele Modelle, die bei HumanEval gut abschneiden, auf diesen Benchmark überangepasst sein könnten. HumanEval besteht aus kleinen, isolierten Aufgaben. Ein feinjustiertes offenes Modell erreichte dort 59,8 Prozent, bei den leichten Aufgaben von LiveCodeBench nur 26,3 Prozent (LiveCodeBench, arXiv).

Außerdem beobachteten die Forscher bei mehreren Modellen einen deutlichen Leistungseinbruch bei LeetCode-Aufgaben, die erst nach dem Trainingsstand veröffentlicht wurden, was sie als wahrscheinliche Kontamination älterer Aufgaben deuten. Für dich heißt das: Eigene Aufgaben, die das Modell nicht aus dem Training kennen kann, sind der verlässlichere Maßstab.

Lege fest, welche Python-Arbeit das Modell übernehmen soll

„Gut im Programmieren“ ist als Vergleichsziel zu ungenau. Brauchst du kleine Funktionen für Skripte, Hilfe bei Fehlern in bestehendem Code, neue Tests oder Erklärungen fremder Programme? Formuliere vor der Modellauswahl, welche Arbeit dir das Modell abnehmen soll.

Stelle ein Aufgabenpaket aus deinem Arbeitsgebiet zusammen. Gib eine Funktion mit klaren Eingaben und erwarteten Ausgaben vor, lass einen bekannten Fehler korrigieren und fordere Tests für beschriebenes Verhalten an. Ergänze Randfälle wie leere Eingaben oder ungültige Werte. So erkennst du, ob eine Antwort die Anforderungen erfüllt oder nur den offensichtlichen Fall trifft.

Schreibe für jede Aufgabe vorab auf, was als Erfolg gilt. Bei einer Funktion zählen die geforderte Schnittstelle und das Verhalten in den vorbereiteten Tests. Bei einer Fehlerkorrektur muss der bekannte Fehler verschwinden, während bisheriges Verhalten erhalten bleibt. Eine Erklärung bewertest du danach, ob sie die Ursache trifft und dir eine brauchbare nächste Handlung nennt.

Wähle Kandidaten nach Passung, nicht nach Rangliste

Beginne mit Modellen, deren Einsatzbedingungen du prüfen kannst. Bei einem Open-Weights-Modell gehören die offizielle Modellkarte und die konkrete Lizenzdatei auf deine Leseliste. Kläre vor dem geplanten Einsatz, welche Regeln für Nutzung, Weitergabe und gegebenenfalls deinen Standort gelten. Wenn du die Bedingungen für einen beruflichen Einsatz nicht sicher einordnen kannst, hol fachkundigen Rat ein.

Prüfe danach die technische Passung: Beschreibt die Modellkarte Aufgaben mit Code? Kann deine lokale Laufzeit das angebotene Format laden? Welche Angaben macht sie zum Kontextfenster? Damit ist der Platz für Eingaben und bisherige Unterhaltung gemeint, den das Modell zugleich berücksichtigen kann. Dateiauszüge, Fehlermeldungen und frühere Antworten beanspruchen diesen Platz. Eine Untersuchung von Chroma mit 18 Sprachmodellen zeigte, dass die Leistung mit wachsender Eingabelänge deutlich schwankt, selbst bei einfachen Aufgaben (Chroma, 14.7.2025). Halte wichtige Anforderungen deshalb im aktuellen Auftrag sichtbar.

Prüfe auch, welches Kontextfenster deine Laufzeit tatsächlich nutzt. Ollama legt den Standard laut Dokumentation nach dem Grafikspeicher fest: unter 24 GiB VRAM „4k“, bei 24 bis 48 GiB „32k“ und ab 48 GiB „256k“ Token. Ein größerer Kontext braucht mehr Speicher. Mit ollama ps siehst du in der Spalte CONTEXT, wie viel tatsächlich zugeteilt ist, und in der Spalte PROCESSOR, ob das Modell ganz auf der GPU läuft oder teilweise auf die CPU ausweicht. Für einen fairen Vergleich stellst du für alle Kandidaten denselben Kontext ein, etwa über die Umgebungsvariable OLLAMA_CONTEXT_LENGTH oder die Option num_ctx.

Vergleiche zunächst Kandidaten, die auf deiner vorhandenen Hardware nutzbar sind. Wenn du Varianten mit unterschiedlichem Speicherbedarf einbeziehst, etwa verschiedene Quantisierungsstufen, behandle sie als getrennte Kandidaten und notiere jeweils den genauen Modellstand. Ob eine sparsamere Variante deine Aufgaben noch gut löst, zeigt erst das gleiche Aufgabenpaket.

Halte fest, wie viel Arbeitsspeicher und Grafikspeicher für den Versuch verfügbar ist und welche Wartezeit du akzeptierst. Läuft ein Kandidat nur mit stark gekürzter Eingabe oder beeinträchtigt andere Dienste, gehört auch das ins Ergebnis. Eine grundsätzliche Aussage zur Lauffähigkeit ersetzt die Prüfung an deinem Python-Workflow nicht.

Baue eine nachvollziehbare Vergleichsumgebung

Nutze für alle Kandidaten möglichst dieselbe lokale Laufzeit und denselben Eingabeweg. Im Vergleich solltest du neben dem Modell nicht zugleich Oberfläche, Hardwarezuweisung und Ausgabevorgaben wechseln.

Schreibe jeden Prompt vor dem Versuch fest. Beschreibe Aufgabe, erlaubte Bibliotheken, geforderte Schnittstelle und gewünschtes Ausgabeformat. Gib jedem Kandidaten dieselben Informationen. Ein zusätzlicher Hinweis nach einer misslungenen Antwort zählt als neue Runde und darf nicht mit dem Erstversuch eines anderen Modells vermischt werden.

Protokolliere die verfügbaren Generierungseinstellungen zusammen mit Laufzeit, Modellstand und Variante. Achte besonders auf Einstellungen für die Zufälligkeit und die Antwortlänge. In der Ollama-API heißen sie temperature und num_predict; mit seed legst du einen Startwert für reproduzierbare Ausgaben fest (Ollama-API). Lassen sie sich zwischen Kandidaten nicht gleich setzen, halte den Unterschied fest, statt ihn in der Auswertung zu übergehen.

Beginne jede Aufgabe mit frischem Gesprächskontext. Sonst könnte ein Kandidat von Fehlermeldungen oder Hinweisen aus einer früheren Runde profitieren. Notiere außerdem, ob das Modell beim Aufruf erst geladen werden musste: Ein Start aus dem Ruhezustand und eine Antwort aus laufender Sitzung sind für den Alltag unterschiedliche Situationen.

Bewahre Prompts, Testdateien, Rohantworten und Einstellungen gemeinsam auf. Eine klare Ordnerstruktur genügt, solange du jede Antwort ihren Bedingungen zuordnen kannst. Entdeckst du eine missverständliche Aufgabe, korrigiere sie für alle Kandidaten und wiederhole genau diese Aufgabe.

Prüfe Codequalität, bevor du Geschwindigkeit bewertest

Führe generierten Code nicht ungeprüft in deiner produktiven Homelab-Umgebung aus. Lies ihn zuerst auf Dateioperationen, Netzwerkzugriffe, Paketinstallationen und Befehle für die Kommandozeile durch. Nutze entbehrliche Testdaten in einer isolierten Umgebung und halte Zugangsdaten sowie produktive Verzeichnisse fern. Bei Agenten und Erweiterungen ist besondere Vorsicht nötig: Sie können fremden Code ausführen.

Lass für Funktionen und Fehlerkorrekturen dieselben vorbereiteten Tests gegen jede Lösung laufen. Protokolliere mehr als das Gesamtergebnis: Bleibt die geforderte Schnittstelle erhalten? Scheitert bereits das Laden des Codes? Liegt der Fehler bei einem Randfall oder fehlt ein Teil der Lösung? Diese Unterschiede helfen dir später bei der Auswahl.

Halte zusätzliche Prüfungen zurück, die aus den Anforderungen folgen, aber nicht schon als Beispiel im Prompt stehen. Eine eigene Musterlösung kann dir helfen, Aufgabe und Tests zu kontrollieren; das Modell sollte sie nicht sehen. Sind verschiedene Lösungen korrekt, bewerte ihr Verhalten statt ihrer Ähnlichkeit zu deiner Lösung.

Bei erzeugten Tests drehst du die Prüfung um: Laufen sie gegen eine korrekte Umsetzung und schlagen sie bei einer gezielt eingebauten Fehlvariante an? Für Erklärungsaufgaben notierst du vorher die Aussagen, auf die es ankommt. Flüssiger Text soll eine falsche Erklärung nicht verdecken.

Erfasse Nacharbeit getrennt vom ersten Ergebnis. Eine kleine Korrektur am Ausgabeformat wiegt anders als das Umschreiben der Programmlogik. Auch eine erfolgreiche Nachfrage macht den ersten Versuch nicht nachträglich richtig. Sie zeigt dir aber, ob das Modell für interaktive Arbeit nützlich sein könnte.

Messe Tempo und Ressourcen entlang deines Arbeitsablaufs

Die Ollama-API liefert die nötigen Messwerte mit jeder Antwort: load_duration für das Laden des Modells, prompt_eval_duration für die Verarbeitung der Eingabe, eval_count und eval_duration für die erzeugten Token, alle Zeiten in Nanosekunden. Die Erzeugungsgeschwindigkeit in Token pro Sekunde ergibt sich aus eval_count geteilt durch eval_duration, multipliziert mit einer Milliarde. Mit dem Parameter keep_alive steuerst du, wie lange ein Modell geladen bleibt; der Wert 0 entlädt es sofort, was für einen sauberen Kaltstart-Test hilft.

Starte und beende die Zeitmessung für jeden Kandidaten am selben Punkt. Maßgeblich ist, wann die vollständige, verwertbare Antwort vorliegt: Eine frühe Textausgabe hilft wenig, wenn der benötigte Code noch fehlt. Erfasse den Start eines ungeladenen Modells getrennt von Antworten aus einer laufenden Sitzung.

Beobachte während derselben Aufgaben den Speicherbedarf von Laufzeit und System. Halte fest, ob der Prozess stabil bleibt und ob andere Dienste beeinträchtigt werden. Wenn du den Stromverbrauch erfasst, vergleiche nur Messungen mit gleichem Messpunkt und vergleichbarer Hintergrundlast; wie du dabei vorgehst, zeigt unser Ratgeber zu den Stromkosten lokaler KI.

Wiederhole Aufgaben, deren Antworten schwanken. Eine einzelne besonders gute oder schlechte Antwort sollte die Auswahl nicht bestimmen. Prüfe, ob ein Kandidat dieselbe Aufgabe erneut korrekt löst und ob die Wartezeit für dich verlässlich genug bleibt.

Werte Qualität, Tempo und Ressourcen zunächst getrennt aus. Ein schnelles Modell mit häufig falschen Änderungen kann mehr Nacharbeit verursachen, als es Wartezeit spart. Ein ressourcenhungriger Kandidat kann sich für seltene schwierige Aufgaben eignen, auch wenn du ihn nicht ständig laufen lassen willst. Prüfe deine Favoriten anschließend an bisher ungesehenen Python-Aufgaben. Wenn du einen Agenten einsetzt, musst du zusätzlich seine Werkzeugzugriffe begrenzen.

Häufige Fehler beim Vergleich lokaler Coding-LLMs

Praktische Handlungsempfehlungen Oktober 2026

Definiere zuerst deinen Python-Workflow. Wähle Aufgaben aus, die bei dir vorkommen, und lege fest, ob korrekter Erstcode, Hilfe bei Fehlern oder schnelle Rückfragen Vorrang haben.

Prüfe dann Lizenz und technische Passung. Lies bei jedem Open-Weights-Kandidaten Modellkarte und Lizenzdatei. Kontrolliere außerdem Format, Laufzeit und verfügbaren Speicher.

Fixiere Prompts und Umgebung. Nutze dieselben Aufgaben und Ausgabevorgaben sowie möglichst gleiche Laufzeiteinstellungen. Speichere die Rohantworten, bevor du Änderungen vornimmst.

Prüfe den Code sicher und systematisch. Lies mögliche Zugriffe vor der Ausführung, arbeite isoliert und lasse vorbereitete Tests laufen. Erfasse Fehlerarten und Nacharbeit zusätzlich zum Testergebnis.

Messe die Kosten einer brauchbaren Antwort. Halte Wartezeit und Speicherverhalten fest. Trenne den Startvorgang von der laufenden Sitzung; erfasse Stromverbrauch nur bei einem vergleichbaren Messaufbau.

Bestätige den Favoriten an ungesehenen Aufgaben. Nutze ein eigenes Python-Projekt außerhalb des bisherigen Vergleichs. Bewahre die funktionierende Konfiguration auf und prüfe sie erneut, wenn du Modellstand oder Laufzeit änderst.

Fazit

Ein brauchbarer Vergleich lokaler Coding-LLMs beginnt mit deinen Python-Aufgaben und endet bei ausführbarem Verhalten, Nacharbeit und Ressourcenbedarf. Gleiche Prompts, vorbereitete Tests und ein sauberes Protokoll machen Unterschiede zwischen Kandidaten erst einordnungsfähig.

Nimm das Modell, das deine wichtigen Aufgaben wiederholt korrekt löst und in dein Homelab passt. Halte einen aufwendigeren Kandidaten nur für schwierige Aufgaben vor, wenn er dort einen erkennbaren Nutzen bringt. Erfüllt keiner deine Anforderungen zuverlässig oder sind die Nutzungsbedingungen unklar, setze vorerst keinen davon für diesen Workflow ein.

Quellen und weiterführende Informationen

• Jain et al.: LiveCodeBench – Holistic and Contamination Free Evaluation of Large Language Models for Code (arXiv 2403.07974)
• Chroma Research: Context Rot – How Increasing Input Tokens Impacts LLM Performance (14.7.2025)
• Ollama-Dokumentation: Context length (Standardkontext nach VRAM, ollama ps)
• Ollama-API-Spezifikation (Messwerte, Optionen temperature, seed, num_predict, num_ctx, keep_alive)

Haftungsausschluss

Transparenzhinweis: Dieser Artikel ordnet öffentlich zugängliche Informationen ein, vor allem die oben genannten Quellen (Stand: Oktober 2026). Wir testen und messen nicht selbst. Wo es um Produkte geht, stützen sich die Aussagen auf Herstellerangaben und die Tests anderer Redaktionen.

Sicherheitsprüfung: Prüfe generierten Python-Code vor der Ausführung auf Dateioperationen, Netzwerkzugriffe und Befehle. Führe ihn nur mit entbehrlichen Daten in einer isolierten Umgebung aus und halte Zugangsdaten fern. Beachte, dass Agenten und Erweiterungen fremden Code ausführen können. Hole bei Verdacht auf einen Sicherheitsvorfall fachliche Hilfe.

Lizenzen und Stand: Lies bei jedem Open-Weights-Modell die konkrete Lizenzdatei und prüfe Territorialklauseln, Umsatzschwellen und Attributionspflichten für deinen geplanten Einsatz. Hole bei rechtlichen Zweifeln fachkundigen Rat ein. Prüfe Modellstand, Lizenztext und Laufzeitdokumentation vor deiner Entscheidung erneut, da sie sich ändern können.

Affiliate-Hinweis: Enthält dieser Artikel Links zu Produkten oder Händlern, kann es sich um Affiliate-Links handeln: Bei einem Kauf darüber erhält aimageddon.de eine Provision, ohne dass sich dein Preis erhöht. Genannte Markennamen sind Warenzeichen der jeweiligen Inhaber und dienen der sachlichen Information; es handelt sich um keine bezahlte Empfehlung.