{"id":17684,"date":"2025-06-30T14:37:27","date_gmt":"2025-06-30T12:37:27","guid":{"rendered":"https:\/\/www.centigrade.de\/?post_type=blog&p=17684"},"modified":"2025-08-13T11:26:29","modified_gmt":"2025-08-13T09:26:29","slug":"open-source-llms-im-test-wie-gut-eignen-sie-sich-fuer-als-entwicklungsunterstuetzung","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/open-source-llms-im-test-wie-gut-eignen-sie-sich-fuer-als-entwicklungsunterstuetzung\/","title":{"rendered":"Open-Source-LLMs im Test: Wie gut eignen sie sich als Entwicklungsunterst\u00fctzung?"},"content":{"rendered":"

\"Zwei<\/h2>\n

1. Einf\u00fchrung<\/strong><\/h2>\n

In diesem Blogartikel widmen wir uns der Frage, inwiefern lokal im Unternehemen bereitgestellte Open-Source-Modelle ausgereift genug sind, um mit den „gro\u00dfen“, kommerziellen Modellen wie Claude oder Chat-GPT mithalten zu k\u00f6nnen. Der Rummel um KI \u2013 egal in welcher Branche \u2013 k\u00f6nnte kaum gr\u00f6\u00dfer sein. \u00dcberall werden Automatisierung und Effizienzsteigerungen versprochen, denn Maschinen sollen in gleicher Zeit mehr leisten, als es dutzende Menschen je k\u00f6nnten. Wir untersuchen, in wie weit das auch f\u00fcr die kostenfreien Open-Source-Modelle gilt. Daf\u00fcr haben wir uns ein realistisches Angular-Beispielprojekt<\/a> genommen und den LLMs Code Llama 3.1, Deep Seek Coder 2, Phind Code Llama<\/strong> und Wizard Coder<\/strong> ein paar Aufgaben gestellt…<\/p>\n

Die Resultate werden dann mit den Antworten von Claude Sonnet 4 verglichen, um einen soliden Referenzwert zu haben. Wer gewinnt? Und wie knapp? Das lest ihr hier.<\/p>\n

Die Ergebnisse dieses Tests beinhalten nicht vermeidbare, subjektive Bewertungen und spiegeln daher unweigerlich unsere Perspektive wider. Der ein oder andere Leser wird sicherlich andere Erfahrungen gemacht haben und daher unsere Meinung zum Testergebnis nicht teilen. Und das ist auch in Ordnung so!<\/p>\n

1.1 Motivation<\/strong><\/h3>\n

Large Language Models (LLMs) sind l\u00e4ngst nicht mehr nur ein Hype \u2013 sie haben sich als praktische Helfer in der Softwareentwicklung etabliert. Besonders im Webdevelopment, wo sich Frameworks, Bibliotheken und Best Practices st\u00e4ndig weiterentwickeln, k\u00f6nnen sie wertvolle Unterst\u00fctzung bieten. Doch wie gut sind lokal Open-Source-Modelle mit bis zu 60B wirklich? Und lohnt sich ihr Einsatz im professionellen Umfeld?<\/p>\n

Genau das wollen wir in unserem Test herausfinden. Denn wenn Open-Source-LLMs halten, was sie versprechen, k\u00f6nnten sie nicht nur unsere Workflows optimieren, sondern auch eine unabh\u00e4ngigere, und vor allem datenschutzfreundlichere Alternative zu propriet\u00e4ren Modellen darstellen.<\/p>\n

1.2 Getestete LLMs<\/strong><\/h3>\n

In unserem Test haben wir uns die bekanntesten und erfolgreichsten Open-Source-Modelle herausgesucht. Darunter Modelle, die von gro\u00dfen Konzernen wie Meta oder DeepSeek AI entwickelt und trainiert wurden, sowie solche, die auf dem Big Code Models Leaderboard<\/a> hoch gerankt sind.<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t
Name <\/th>Parameteranzahl <\/th>Open-Source<\/th>Beschreibung<\/th>\n<\/tr>\n<\/thead>\n
Code Llama 3.1<\/td>8B<\/td>?<\/td>Meta\u2019s leistungsstarkes Modell f\u00fcr Code-Generierung und -Verst\u00e4ndnis.<\/td>\n<\/tr>\n
Deep Seek Coder 2<\/td>15.7B<\/td>?<\/td>Spezialisiert auf Code-Analyse und -Generierung mit erweitertem Kontext.<\/td>\n<\/tr>\n
Phind Code Llama<\/td>3.8B<\/td>?<\/td>Optimiert f\u00fcr pr\u00e4zise Antworten und schnelle Code-Hilfe.<\/td>\n<\/tr>\n
Wizard Coder<\/td>33B<\/td>?<\/td>Feinabgestimmt f\u00fcr komplexe Programmieraufgaben und Refaktorierungen.<\/td>\n<\/tr>\n
Claude Sonnet 4<\/td>nicht ver\u00f6ffentlicht<\/td>?<\/td>Anthropics propriet\u00e4res Modell mit starken F\u00e4higkeiten in Code-Verst\u00e4ndnis.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

2. Testaufbau<\/strong><\/h2>\n

Der Test findet in einem realit\u00e4tsnahen Angular 18<\/strong>-Projekt statt, das als realistische Basis f\u00fcr unsere Bewertung dient. Als IDE nutzen wir VS Code<\/a><\/strong> mit der Continue Extension<\/a><\/strong>, die es erm\u00f6glicht, lokal gehostete Modelle einzubinden. Die Open-Source-LLMs werden auf unserer Infrastruktur mittels Ollama bereitgestellt und in Continue integriert, um einen komfortablen Zugriff auf die Modelle aus der IDE heraus zu schaffen.<\/p>\n

Hardware Limitierungen<\/h3>\n

Durch das Hosten auf der eigenen Infrastruktur, unterliegen wir nat\u00fcrlich Hardware-Limitierungen, die bspw. maximale Parameteranzahl der Modelle beschr\u00e4nken. Die gr\u00f6\u00dften, bei uns noch reibungslos lauff\u00e4higen Modelle haben 60 Milliarden Parameter. Mit gr\u00f6\u00dferen Modellen w\u00fcrde der Test hier und da sicherlich anders ausfallen.<\/p>\n

2.1 Vorgehen<\/strong><\/h3>\n

Alle Modelle erhalten dieselben acht Aufgaben mit identischen Prompts und Kontextdaten. Die Tests decken verschiedene Aspekte der Webentwicklung ab:<\/p>\n

    \n
  • App- und Routing-Struktur erkl\u00e4ren<\/strong> (Code-Verst\u00e4ndnis): Das LLM soll die Routing-Struktur erkl\u00e4ren und den Aufbau der App beleuchten.<\/li>\n
  • API eines Services analysieren<\/strong> (Code-Analyse): Hier sollte erkl\u00e4rt werden, welche Verantwortung ein Service \u00fcbernimmt und wie er in der App eingesetzt wird.<\/li>\n
  • Simples Feature hinzuf\u00fcgen<\/strong> (Code-Modifikation): Die LLMs sollen eine Artikel-Vorschau um die Informationen „Wortzahl“ und „Lesezeit“ erweitern.<\/li>\n
  • Bug beheben<\/strong> (Critical Thinking): Hier wurde ein Bug eingebaut, der sehr subtile Auswirkungen hat. Die LLMs sollen ihn finden und l\u00f6sen.<\/li>\n
  • Refaktorierung von Initialisierungs-Observables<\/strong> (Refactoring): Hier wurden den Modellen mehrere Komponenten-Initialisierungslogiken pr\u00e4sentiert, die auf RxJS beruhen und ein gemeinsames Pattern aufweisen. Dieses Pattern soll gefunden und sauber extrahiert werden.<\/li>\n
  • Accessibility-Pr\u00fcfung<\/strong> (A11y-Kenntnisse): Diese Aufgabe pr\u00fcft das Erkennen von Accessibility-Problemen in Komponenten.<\/li>\n
  • Unit-Tests schreiben<\/strong> (Test-Automatisierung): Den LLMs wird eine Komponente pr\u00e4sentiert, f\u00fcr die sie Unit-Tests schreiben sollen.<\/li>\n
  • Anti-Pattern-Erkennung<\/strong> (Framework-spezifisches Wissen): Dieser Task pr\u00fcft das Wissen rund um Best-Practices, sei es Angular-spezifisch oder allgemein zur Softwareentwicklung.<\/li>\n<\/ul>\n

    2.2 Bewertung<\/strong><\/h3>\n

    Die Antworten werden nach folgenden Kriterien bewertet:<\/p>\n

      \n
    • Richtigkeit<\/strong>: Sind die Aussagen korrekt oder irref\u00fchrend?<\/li>\n
    • Vollst\u00e4ndigkeit<\/strong>: Fehlen essentielle Aspekte?<\/li>\n
    • Verst\u00e4ndlichkeit<\/strong>: Ist die Antwort klar und strukturiert?<\/li>\n
    • Relevanz<\/strong>: Trifft die L\u00f6sung den Kern der Frage?<\/li>\n<\/ul>\n

      Jeder Aspekt erh\u00e4lt eine Punktzahl von 1\u201310, aus denen der Durchschnitt als Gesamtbewertung berechnet wird.<\/p>\n

      Ergebnisse …<\/h2>\n

      Der K\u00fcrze halber haben wir die genauen Aufgabenstellungen und deren Antworten der LLMs hier nicht mit aufgef\u00fchrt; der Artikel zeigt lediglich die Benotung und Auswertung der Ergebnisse.<\/p>\n

      Einordnung der Bewertung<\/h3>\n

      Obwohl wir uns gro\u00dfe M\u00fche gegeben haben, die Bewertungen so objektiv wie m\u00f6glich zu halten, ist ein gewisser Bias nicht auszuschlie\u00dfen. Nicht jeder wird mit allen vergebenen Punktzahlen einverstanden sein, und das ist auch legitim so. Arbeitsumgebungen und -anforderungen variieren oft stark, daher ist eine „one-size-fits-all“ Bewertung auch gar nicht m\u00f6glich.<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t
      Task<\/th>Claude Sonnet 4 <\/th>Code Llama <\/th>DeepSeek Coder 2 <\/th>Phind Code Llama<\/th>Wizard Coder <\/th><\/td><\/td>\n<\/tr>\n<\/thead>\n
      1 \u2013 Code Verst\u00e4ndnis<\/td>9,75<\/td>7,75<\/td>8,75<\/td>8,25<\/td>7,25<\/td><\/td><\/td>\n<\/tr>\n
      2 \u2013 Code Analyse<\/td>10,0<\/td>8,25<\/td>9,25<\/td>7,0<\/td>9,0<\/td><\/td><\/td>\n<\/tr>\n
      3 \u2013 Feature-Erweiterung<\/td>10,0<\/td>6,25<\/td>7,75<\/td>4,0<\/td>8,75<\/td><\/td><\/td>\n<\/tr>\n
      4 \u2013 Bug-Fixing<\/td>10,0<\/td>5,25<\/td>5,75<\/td>5,0<\/td>3,5<\/td><\/td><\/td>\n<\/tr>\n
      5 \u2013 Refactoring eines Observables<\/td>5,5<\/td>4,25<\/td>1,0<\/td>4,75<\/td>2,5<\/td><\/td><\/td>\n<\/tr>\n
      6 \u2013 Accessibility-Check<\/td>9,75<\/td>5,0<\/td>5,25<\/td>6,25<\/td>5,25<\/td><\/td><\/td>\n<\/tr>\n
      7 \u2013 Unit-Tests schreiben<\/td>8,75<\/td>7,0<\/td>4,25<\/td>8,75<\/td>3,0<\/td><\/td><\/td>\n<\/tr>\n
      8 \u2013 Angular Best Practices<\/td>10,0<\/td>1,25<\/td>8,25<\/td>2,0<\/td>2,75<\/td><\/td><\/td>\n<\/tr>\n
      <\/td><\/td><\/td><\/td><\/td><\/td><\/td><\/td>\n<\/tr>\n
      \u00d8 \/ 10<\/td>9,22 \/ 10<\/td>5,63 \/ 10<\/td>6,28 \/ 10<\/td>5,75 \/ 10<\/td>5,25 \/ 10<\/td><\/td><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

      Erkl\u00e4rungen zu den Extrema<\/h3>\n

      Um die h\u00f6chst- und niedrigst-Punktzahlen besser einordnen zu k\u00f6nnen, haben wir die Extrema hier kurz beschrieben:<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t
      Model<\/th>Bester Task<\/th>Schlechtester Task
      \n<\/th>\n<\/tr>\n<\/thead>\n
      Code Llama\t<\/td>8,25 Punkte bei Code Analyse<\/td>1,25 Punkte bei Angular Best Practices<\/td>\n<\/tr>\n
      <\/td>- Erkannte Methoden und HTTP-Endpunkte korrekt
      \n- Klare funktionale Beschreibung des Services
      \n- Allerdings: Filter-Parameter unklar, Fehlerbehandlung fehlt<\/td>      		- Fast alle Vorschl\u00e4ge falsch oder irrelevant
      \n- Verstand takeUntilDestroyed nicht
      \n- Erkannte nur Single-Responsibility-Versto\u00df (SRP)
      \n- Allerdings: Da Angular im Gegensatz zu anderen Frontend-Frameworks wie bspw. React eher seltener gebraucht wird, halten wir dieses Ergebnis f\u00fcr nachvollziehbar, da die LLM-Trainingsdaten entsprechend wenig Angular-Wissen enthalten werden.<\/td>\n<\/tr>\n
      Deep Seek Coder 2\t<\/td>9,25 Punkte bei Code Analyse<\/td>1,0 Punkte bei Refactoring eines Observables<\/td>\n<\/tr>\n
      <\/td>- Erkannte Methoden und HTTP-Endpunkte korrekt
      \n- Klare funktionale Beschreibung des Services
      \n- Allerdings: Fehlende Parameter\/R\u00fcckgabetypen, veraltete DI-Empfehlung<\/td>      		- Die Aufgabe konnte nicht zu Ende gebracht werden
      \n- Nach wiederholten Malen bricht die Ausgabe an immer derselben Stelle ab<\/td>\n<\/tr>\n
      Phind Llama<\/td>8,75 Punkte bei Unit-Tests schreiben<\/td>2,0 Punkte bei Angular Best Practices<\/td>\n<\/tr>\n
      <\/td>- Tests kompilierten direkt
      \n- Best Practices wie Abh\u00e4ngigkeiten-Doubles, das Beibehalten vom Smoke-Test wurden eingehalten
      \n- Template wird mitbetestet
      \n-Allerdings: Hat f\u00e4lschlicher eine Standalone-Komponente in das declarations-Array gepackt.<\/td>      		- Veraltete Unsubscribe-Patterns empfohlen
      \n- Unn\u00f6tige Komponenten-Extraktionen vorgeschlagen
      \n- Keine hilfreichen Architektur-Empfehlungen
      \n- Allerdings: Da Angular im Gegensatz zu anderen Frontend-Frameworks wie bspw. React eher seltener gebraucht wird, halten wir dieses Ergebnis f\u00fcr nachvollziehbar, da die LLM-Trainingsdaten entsprechend wenig Angular-Wissen enthalten werden.<\/td>\n<\/tr>\n
      Wizard Coder<\/td>9,0 Punkte bei Code Analyse<\/td>2,5 Punkte bei Refactoring eines Observables<\/td>\n<\/tr>\n
      <\/td>- Gute, kurze und pr\u00e4zise Auflistung der Klassen-API
      \n- Benutzt technische Ausdr\u00fccke und Konzepte
      \n- Zeigt auf, dass es sich um eine REST-API handelt
      \n- Behandelt das Thema Error-Handling<\/td>      		- Code, der nicht kompiliert, wird vorgeschlagen (ignoriert Kapselung)
      \n- generierter Code gleicht inhaltlich nicht dem Original
      \n- F\u00fchrt einen Bug ein, da ein falscher Service aufgerufen wird
      \n- Schlechte Benennung von Funktionen<\/td>\n<\/tr>\n
      Claude\t<\/td>10,0 Punkte bei Code Analyse, Feature-Erweiterung und Bug-Fixing<\/td>5,5 Punkte bei Refactoring eines Observables<\/td>\n<\/tr>\n
      <\/td>\t- Gute und pr\u00e4gnante Beschreibung von APIs und deren Nutzen
      \n- Vorgeschlagener Code ist einfach, gut benannt und kompiliert
      \n- Fehlerursache und -szenario wird schl\u00fcssig erkl\u00e4rt und Bug wird gefunden<\/td>      		- Code kompiliert zwar, aber geschaffene Abstraktion bietet keinen Mehrwert
      \n- Ein Codeausschnitt wurde semantisch 1:1 wiedergegeben<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

      … Und Auswertung<\/h2>\n

      Das propriet\u00e4re Modell Claude dominiert mit \u00d8 9,2\/10<\/strong> klar und \u00fcbertrifft Open-Source-Modelle (\u00d8 5,6\u20136,3) in fast allen Aufgaben, besonders bei komplexem Debugging, Refactoring und Framework-Wissen<\/strong>. Hier eine Zusammenfassung der Ergebnistabelle:<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t
      Modell<\/th>St\u00e4rken<\/th>Schw\u00e4chen<\/th>\n<\/tr>\n<\/thead>\n
      Code Llama<\/td>Hohe Scores bei Routineaufgaben (Task 1, Task 2)<\/td>Schw\u00e4chen bei komplexer Umsetzung mit semantischen Details und nicht aktueller Wissensstand (Task 5, Task 8)<\/td>\n<\/tr>\n
      Deep Seek Coder<\/td>Robust bei beschreibenden Aufgaben (Task 1, Task 2)<\/td>Versagt bei Architektur-\/Pattern-Aufgaben (Task 5, Task 8).
      \nRefactoringaufgabe konnte nicht beendet werden.
      \nAccessibility eher oberfl\u00e4chlich<\/td>\n<\/tr>\n
      Phind<\/td>Sehr gut bei strukturierter Sprache und Tests (Task 1, Task 7)<\/td>Schwach bei Angular-Details, Refactoring, Anti-Pattern-Erkennung<\/td>\n<\/tr>\n
      Wizard Coder<\/td>Sehr stark bei expliziten Aufgaben mit klarer Struktur (Task 2, Task 3)<\/td>Komplettausf\u00e4lle bei Anti-Pattern-Erkennung (Task 5, Task 8).
      \nSchw\u00e4chen bei exakter Fehlerursache und testbarem Code.
      \nNeigt zu unrichtigen Aussagen.<\/td>\n<\/tr>\n
      Claude<\/td>\u00dcberzeugt in fast allen Disziplinen, hat gute und aktuelle Kenntnisse zu Angular und Best Practices<\/td>Schwach, wenn es um semantische Details geht, die sinnbringend refaktoriert werden sollen<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

      St\u00e4rken aller LLMs:<\/strong><\/p>\n

        \n
      • Code-Verst\u00e4ndnis:<\/li>\n
      • Zusammenfassen von offensichtlichen App-Architekturen<\/li>\n
      • Zusammenfassen von Klassen-APIs<\/li>\n
      • Benutzung von Klassen und Komponenten<\/li>\n<\/ul>\n

        Durchwachsene Performance<\/strong><\/p>\n

          \n
        • Unit-Test-Generierung<\/li>\n
        • Von „zu aufw\u00e4ndig zum Laufen zu bringen“ bis „kompiliert out-of-the-box“<\/li>\n
        • Von „relevante Sachen ausgelassen“ bis „zu viele Details getestet“<\/li>\n
        • Feature-Erweiterung<\/li>\n
        • Von „enth\u00e4lt absolute Beginner-Level-Fehler“ bis „einwandfrei implementiert“<\/li>\n<\/ul>\n

          Schw\u00e4chen der open-source<\/em> LLMs:<\/strong><\/p>\n

            \n
          • Subtile Bugs finden<\/li>\n
          • der Bug wird nicht auf eine oder wenige konkrete Stellen festgelegt, sondern es werden viele M\u00f6glichkeiten „geraten“<\/li>\n
          • eine Art Checkliste wird gegeben, die nicht unbedingt was mit dem Fehler zu tun hat<\/li>\n
          • die Erkl\u00e4rungen zum Bug ergeben zuweilen keinen wirklichen Sinn im tats\u00e4chlichen Fehlerkontext<\/li>\n
          • Schlecht im Critical Thinking<\/strong> (Bugfixing, Best Practices)<\/li>\n
          • Oberfl\u00e4chliches Accessibility- und Angular-Wissen<\/strong><\/li>\n<\/ul>\n

            Schw\u00e4chen aller<\/em> LLMs:<\/strong><\/p>\n

              \n
            • RxJS \/ Observables refaktorieren<\/li>\n
            • sehr h\u00e4ufig werden sinnfreie Abstraktionen geschaffen<\/li>\n
            • dadurch ist auch die Benennung schlecht und wenig verst\u00e4ndlich<\/li>\n
            • meistens kompiliert der Code nach dem Refactoring nicht mehr<\/li>\n
            • Code wird komplizierter, nicht einfacher<\/li>\n<\/ul>\n

              Fazit<\/h2>\n

              Open-Source-LLMs reichen f\u00fcr einfache Code-Generierung aus, doch f\u00fcr professionelle Entwicklung sind (noch) propriet\u00e4re Modelle \u00fcberlegen. W\u00e4hrend erfahrene Entwickler von den Modellen wertvolle Denkanst\u00f6\u00dfe erhalten k\u00f6nnen, besteht bei Einsteigern die Gefahr, dass sie durch falsche oder veraltete Vorschl\u00e4ge der LLMs fehlerhafte Konzepte \u00fcbernehmen und sich dadurch ung\u00fcnstige Gewohnheiten aneignen. Die Modelle haben ganz unterschiedliche St\u00e4rke- und Schw\u00e4cheprofile, was zu einem breiten Spektrum von Anwendungsfeldern aber auch -grenzen f\u00fchrt.<\/p>\n

              Am Ende des Tages z\u00e4hlen die Resultate. Wer KI-Modelle effektiv einsetzt, kann sie zu einem wertvollen Werkzeug machen, um verschiedenste Aufgaben, schnell und komfortabel zu erledigen. Wir f\u00fcr unseren Teil bleiben gespannt, was k\u00fcnftige Modelle uns noch bescheren werden und experimentieren gerne mit ihnen weiter.<\/p>\n","protected":false},"author":82,"featured_media":0,"template":"","tags":[984,395,839,515],"class_list":["post-17684","blog","type-blog","status-publish","hentry","tag-ai-de","tag-development","tag-ki","tag-web-engineering"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/17684","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/82"}],"version-history":[{"count":11,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/17684\/revisions"}],"predecessor-version":[{"id":17735,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/17684\/revisions\/17735"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=17684"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=17684"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}