Wie viele Qwen3.8-27B-Agenten wurden verwendet?

Fünf Qwen3.8-27B-Agenten wurden verwendet, um die Ergebnisse zu erzielen.

Welche Bewertung erreichte Fable 5 bei den ersten zehn Aufgaben?

Fable 5 erreichte eine Bewertung von 8,0 bei den ersten zehn Aufgaben.

Welche Rolle spielt der YAML-Workflow in diesem Prozess?

Der YAML-Workflow ermöglicht die Umwandlung einer getesteten Mehr-Modelle-Lösung, die Temperaturen und Genehmigungsprozesse ändern kann, und integriert sie in das CI-System.

Fünf 27B-Agenten gegen Fable 5: Hält der Benchmark stand?

Eröffnungsgespräch

Shiwen: Heute Morgen wurde auf dem Externe Forum eine GitHub-Projekt gemeldet, das berichtet, dass fünf Qwen3.8-27B-Modelle in einer Gruppe die Fable 5 bei den ersten zehn Aufgaben von LiveCodeBench Hard besiegt haben. Die Quelle ist ein Beispiel für einen Arbeitsablauf von Memdoor, und der Autor hat eine vollständige Aufzeichnung der 50 Durchläufe veröffentlicht. Lassen Sie uns zuerst entscheiden, ob der Titel übertrieben ist oder nicht – aber allein aufgrund dieser Informationen lohnt es sich, darüber zu sprechen?

Yongliang: Es lohnt sich, darüber zu sprechen, aber nicht über die glückliche Geschichte von „kleine Modelle besiegen große Modelle“. Was wirklich interessant ist: Es wurde eine bereits getestete Mehr-Modelle-Lösung in einen YAML-Arbeitsablauf umgewandelt, sodass jeder Modelle, Temperaturen und Genehmigungsprozesse ändern kann. Das bedeutet, dass die akademische Implementierung von GVS5H in Teile zerlegt wurde, die ein Ingenieurteam direkt in das CI-System integrieren kann. Ob Fable 5 tatsächlich besiegt wurde, muss man eher mit Vorsicht betrachten.

Q1: Wie ist diese „Sieg“ möglich geworden?

Shiwen: Die README-Datei von Memdoor ist ziemlich klar: In den ersten fünf Passagen liegt der Durchschnitt bei 9.8/10, beim Originalautor und demselben Modell mit denselben Anweisungen bei 9.6, während Fable 5 bei einer einzelnen Aufgabe 8.0 erreicht hat. Wie soll man diese Daten interpretieren?

Yongliang: Wir müssen zunächst die Kontexte verstehen. Es wurde ein Mehr-Modelle-Rundlauf mit Qwen3.8-27B durchgeführt: Der Planner gibt Lösungen vor, zwei Ideator-Modelle schlagen Vorschläge vor, der Solver schreibt Code, der Manager überprüft die Arbeiten, und ein Reparaturarbeiter behebt Fehler. Jede Rolle hat einen neuen Kontext und kommuniziert über Dateien auf dem Datenträger. Nach fünf Passagen liegt der Durchschnitt bei 9.8, was etwas höher ist als die 9.6 des Originalautors von GVS5H, aber deutlich höher als die 8.0 von Fable 5 bei diesen zehn Aufgaben.

Shiwen: Das bedeutet also, dass nicht das Modell selbst stärker wurde, sondern die Art und Weise, wie es verwendet wird?

Yongliang: Richtig. Die 8.0 von Fable 5 stammt aus den einzelnen Aufgaben-Daten des Autors von GVS5H, nicht aus einer erneuten Ausführung durch Memdoor im selben Harness. Genau genommen bedeutet das: „Eine Gruppe von Modellen, unter denselben Bedingungen, zeigt eine bessere Leistung als eine einzelne Aufgabe von Fable 5“, und nicht „Das 27B-Modell übertreft Fable 5 vollständig“. Aber selbst dann reicht dieser Unterschied aus, um zu zeigen: Wenn mehrere kleine Modelle gut organisiert werden, kann man in bestimmten Aufgaben sogar die Grenzen der frontier-Modelle überschreiten. Was noch wichtiger ist, Memdoor hat diese Methode in einen YAML-Arbeitsablauf umgewandelt, was bedeutet, dass man den Planner, den Ideator und den Manager durch eigene Modelle und Temperaturen ersetzen kann, und die Genehmigungsprozesse in jede Phase einbinden kann. Das ist für das Ingenieurteam viel nützlicher als die Punktzahl selbst.

Q2: Ist die Größe der Modelle nicht mehr ein festes Kriterium?

Shiwen: In den letzten Jahren gilt in der Branche die Annahme, dass „je größer das Modell, desto besser“. Dieses Projekt scheint zu sagen, dass die Organisation der Modelle der neue Hebel ist. Sind Sie damit einverstanden?

Yongliang: Ich stimme zur Hälfte zu. Die Größe des Modells bestimmt immer noch die Obergrenze, aber die Anordnung der Aufgaben entscheidet darüber, wie weit diese Obergrenze ausgeschöpft werden kann. Im Beispiel von Memdoor liegt der wirkliche Hebel in vier Punkten: Erstens die Arbeitsteilung, bei der jeder Agent nur für einen kleinen Teil der Aufgabe zuständig ist, was einen klareren Kontext schafft; zweitens der persistente Zustand, bei dem Pläne, Notizen und aktuelle Lösungen in Dateien gespeichert werden, sodass die Rollen nicht den gesamten Vorherigen Kontext in den Prompt einbauen müssen; drittens die mehrstufige Überprüfung, bei der der Manager nicht nur auf den Code schaut, sondern auch auf die Testergebnisse; viertens die Wiederherstellbarkeit, bei der YAML-Prozesse mit Genehmigungsmechanismen und Pausieren nach dem Aussetzen ermöglichen, dass Fehler von den gescheiterten Schritten weitergeführt werden können.

Shiwen: Memdoor erwähnte auch einen „Entscheidungsmodell“ als Voraussetzung zur Kostenersparung durch Token. Wie lässt sich das verstehen?

Yongliang: Das ist ein sehr praktischer Engineering-Punkt. Ein gewöhnlicher Chat-Modell muss jede Gesprächsgeschichte, die Dateiinhalte und die Ergebnisse der Tools vollständig verarbeiten, wodurch die Token-Kosten linear steigen. Der Entscheidungsmodell überprüft zunächst die Eingaben und entscheidet, welche Tools, Dateien und Kontexte für diesen Schritt benötigt werden, und gibt nur die notwendigen Informationen an das große Modell weiter. Memdoor sagt in seinen Tests, dass bei einigen Aufgaben 74% der Eingabetoken eingespart werden können. Dies ist besonders wichtig für mehrrädrige Zyklen, da die Rollen wiederholt Dateien lesen und schreiben. Wenn keine Filter angewandt werden, würde der Kontext schnell anwachsen.

Shiwen: Heißt das, dass die Kosten für die Kauf von Frontier-APIs in Zukunft sinken werden?

Yongliang: Es hängt vom Szenario ab. Wenn die Aufgabe kurz ist, der Kontext nicht tief ist und die Verzögerung wichtig ist, ist eine einzelne Frontier-Aufruf immer noch am praktischsten. Wenn die Aufgabe in mehrere Unteraufgaben aufgeteilt werden kann, mehrere Iterationen erforderlich sind, auditiert oder lokal ausgeführt wird, dann ist „Entscheidungsmodell + mehrere Arbeiter + persistenter Prozess“ vorteilhafter. In Zukunft werden Engineering-Teams eher wie in einer Konstruktionslinie arbeiten, anstatt sich ständig mit dem Prompt für Modelle zu beschäftigen.

Q3: Wie wird der Kostennachweis berechnet? Kann ein lokales Modell wirklich Geld sparen?

Shiwen: Memdoor betont BYOK und lokale Modelle, die von Ollama, llama.cpp und vLLM unterstützt werden. Der ursprüngliche Artikel von GVS5H besagt auch, dass die Kosten auf einem Neunzigstel der Frontier-Kosten sinken. Ist dieser Nachweis glaubwürdig?

Yongliang: Memdoor wurde dieses Mal tatsächlich auf OpenRouter ausgeführt, nicht auf einer lokalen Maschine. 50 effektive Ausführungen kosteten 35,79 US-Dollar, plus 16 abgebrochene oder reparierte Versuche, insgesamt 38,77 US-Dollar. Der mittlere Betrag pro Ausführung betrug 0,39 US-Dollar, die durchschnittliche Laufzeit 40 Minuten, der längste einmal 4 Stunden. Wenn man mit einem lokalen vLLM FP8 ausgeführt wird, sagen die Autoren, dass dies auf einer einzigen GPU funktioniert. Also kann man tatsächlich die API-Kosten sparen, aber man muss Hardware, Stromkosten und Wartung bezahlen.

Shiwen: Heißt das, dass auch Einzelpersonen als Händler zu Hause ausführen können?

Yongliang: Theoretically yes. Memdoor unterstützt Ollama, llama.cpp, vLLM, LM Studio sowie sein eigenes janis Gateway. Auf dem Forum wurde erwähnt, dass nach der Quantisierung von Bonsai 2 Qwen3.8-27B auf einem gewöhnlichen Spielkonsolen mit einer Rate von 50 Token/s laufen kann. In den Kommentaren zu HN steht: „Die Kodierleistung auf dem Niveau von Fable 5 kann lokal erreicht werden, sofern das Design des Harnesss gut ist.“ Aber es gibt zwei Probleme: Erstens könnte die Quantisierung die Qualität der Reasoning beeinträchtigen, zweitens ist die Wartezeit beim multi-agenten-basierten Zyklus. Ein Agent lässt sich möglicherweise schnell lokal ausführen, aber wenn fünf Agenten zusammenlaufen und zusätzlich zum Datei-lesen und -schreiben sowie Testen gearbeitet wird, wird die Gesamtzeit verlängert.

Shiwen: Wie verhält es sich im Vergleich zur frontier API?

Yongliang: Die frontier API wird nach Token gebucht. Der Vorteil ist Flexibilität, Geschwindigkeit und keine Bedarf an speziellen Rechenmaschinen. Lokal modeln erfordert nur einen einmaligen Hardwareaufwand mit niedrigen Kosten. Zum Beispiel kann Qwen3.8-27B nach der Quantisierung von Bonsai 2 auf einer gewöhnlichen Spielkonsolen mit 50 Token/s laufen, was für Einzelentwickler und kleine Teams attraktiv ist. Aber man muss beachten, dass bei dieser Wiederholung von Memdoor der längste multi-agenten-basierten Zyklus 4 Stunden dauerte. Wenn die lokale GPU langsam ist, wird das Erlebnis stark beeinträchtigt. Die Kosten werden nicht nur anhand der Rechnung beurteilt, sondern auch anhand von Zeit, Komplexität und Ausfallrate.

Q4: Wie hoch sollte der Rabatt auf „beats“ im Titel sein?

Shiwen: Sie haben gerade darauf hingewiesen, dass ein Rabatt erforderlich ist. Welche Einschränkungen gibt es konkret?

Yongliang: Erstens: Die Proben umfassen nur die ersten zehn Aufgaben. In dem GVS5H-Artikel werden 100 Aufgaben angegeben, Memdoor hat diesmal nur die ersten zehn gemacht, was eine begrenzte Repräsentativität bedeutet. Zweitens: Die Kontamination ist nicht klar definiert. Diese zehn Aufgaben stammen aus Wettbewerbsaufgaben vom Ende März bis Anfang April 2025. Das Trainingsdatum von Qwen3.8-27B hat diese vielleicht bereits gesehen, und die Autoren haben deutlich gemacht, dass Kontamination nicht ausgeschlossen werden kann. Drittens: Fable 5 wird nicht im selben Umfeld wie Qwen3.8 wieder geladen, die Daten stammen aus den Dateien der Autoren von GVS5H, daher können Unterschiede im Harness nicht ausgeschlossen werden. Viertens: Die Zeitkosten für multi-agenten-basierte Systeme sind hoch, mit einer mittleren Dauer von 40 Minuten und einer maximalen Dauer von 4 Stunden. Das ist völlig anders als eine einzelne Anfrage. Fünftens: Die Genauigkeit auf verschiedenen Hosts in OpenRouter ist nicht transparent, die Autoren verwenden lokall FP8-vLLM, das im Cloudbereich möglicherweise anders ist.

Shiwen: Was halten Sie von den Kommentaren auf dem Forum?

Yongliang: Auf Hacker News wurde auch darauf hingewiesen, dass die ersten zehn Aufgaben möglicherweise bereits ausgeschöpft sind. LiveCodeBench Hard ist auch nicht neu. Andere hoffen, Tests von Qwen3.8-flash-next zu sehen, da flash-next in vielen Kodieraufgaben schneller und stärker ist als 27B. Die Autoren selbst geben zu, dass durch Anpassung von Prompten und Temperaturen möglicherweise eine volle Punktzahl erreicht werden könnte. Das zeigt, dass die Ergebnisse auf Parametern abhängig sind und nicht mit einer festen Rezeptur in alle Situationen übertragen werden können. Ein weiterer Kommentar stellte eine gute Frage: „Können fünf 27B-Aufgaben fünf Fable 5-Aufgaben überholen?“ Diese Frage trifft direkt ins Schwarze, denn ein wirklicher faire Vergleich sollte multi-agenten-basiert sein, nicht multi-agenten-kleine Modelle gegen große Modelle mit einer einzigen Anfrage.

Shiwen: Ist das also ein Titel wie „Fünf 27B-Versionen besiegen Fable 5“ nur Titelbetrug?

Yongliang: Unter bestimmten Umständen ist das wahr, aber es ist noch weit von einer allgemeinen Schlussfolgerung entfernt. Es ähnelt eher einem technischen Nachweis und der Überprüfung von Methoden, als einer Schlussfolgerung, die in eine Kauflehre aufgenommen werden kann. Als Leser würde ich das „beats“ im Titel als „Bezugnahme auf Vergleichbarkeit unter beschränkten Bedingungen“ verstehen, nicht als „Vollständige Überlegenheit“.

Q5: Was ist die größte Lehre für Fachentwickler aus dieser Erfahrung?

Shiwen: Letzte Frage: Wenn das wahr ist und übertragbar, was bedeutet das für den Arbeitstag eines gewöhnlichen Entwicklers?

Yongliang: Es bedeutet, dass unsere Arbeitsschwerpunkte von „Code schreiben“ zu „Entwurf von Arbeitsabläufen und Überprüfung von Anforderungen“ wechseln werden. In den letzten zwei Jahren hat man sich auf Prompt-Engineering konzentriert; nun geht es darum, Aufgaben in verifizierbare Schritte zu unterteilen, Kooperationsabkommen zwischen Agenten zu entwerfen und Genehmigungsschwellen sowie Rückstellpunkte festzulegen. Im Arbeitsablauf von Memdoor gibt es einige Punkte, die man lernen kann: Schritte mit YAML definieren, unabhängige Schritte parallel ausführen, fehlgeschlagene Schritte wiederholen können, wichtige Schritte mit menschlicher Überprüfung versehen und Ergebnisse auf die Festplatte schreiben, anstatt sie vollständig in den Kontext zu packen.

Shiwen: Welche Auswirkungen hat dieser Wandel auf die Teamstruktur?

Yongliang: Der direkteste Effekt ist, dass „Code mit AI schreiben“ keine knappe Fähigkeit mehr ist, sondern „Arbeitsabläufe für Agenten entwerfen“ eine wichtige Fähigkeit wird. Früher lag der Wert eines Hochqualifizierten darin, komplexe Algorithmen zu schreiben, heute liegt er darin, zu entscheiden, welche Probleme für einzelne Agenten geeignet sind, welche mehrere Agenten benötigen und welche Schritte menschliche Überprüfung erfordern. In den Teams werden neue Rollen wie Workflow-Designer und Agent-Überprüfer entstehen. Für Manager müssen die Bewertungskriterien sich ändern: Man sollte nicht nur die Anzahl der Codezeilen betrachten, sondern auch die Stabilität des Prozesses, seine Reproduzierbarkeit und die Fähigkeit, Fehler rückgängig zu machen.

Shiwen: Wird es dann nicht mehr notwendig sein, dass Entwickler keinen Code mehr schreiben?

Yongliang: Nein. Aber „Code schreiben“ wird zu einem kleineren Teil, während der größere Wert darin liegt, Probleme zu definieren, Arbeitsabläufe zu zerlegen und Überprüfungsstandards zu entwerfen. So wie früher DevOps die Betriebs- und Entwicklungstechnik miteinander verband, verbinden jetzt Agent-Arbeitsabläufe Analyse, Codegenerierung, Testverifizierung und menschliche Überprüfung zu einer Wertschöpfungskette. Die Kernfähigkeit eines Entwicklers in der Zukunft könnte sein, Geschäftsfragen in Diagramme zu übersetzen, die Agenten ausführen können, anstatt nur darum zu wetteifern, die schönsten Funktionen zu schreiben.

Shiwen: Was sind deine Ratschläge für Teams, die es ausprobieren wollen?

Yongliang: Beginnen Sie mit Ihren eigenen realen Codeaufgaben. Verwenden Sie keine Benchmark-Werte, um die Auswahl zu leiten. Nehmen Sie eine konkrete Bug-Behebung oder ein Neuanfangstask, führen Sie es mit den Methoden von Memdoor oder GVS5H durch und notieren Sie Zeit, Token-Kosten und Trefferquote. Stellen Sie gleichzeitig klare Überprüfungsschwellen fest, wie zum Beispiel die Durchführung von Unit-Tests oder menschliche Überprüfung, sonst können mehr Agenten leicht in eine Falle geraten. Schließlich sollten Sie lokale Modelle nicht als kostenlosen Snack betrachten – Hardware, Quantisierungsgenauigkeit und Inference-Latenz müssen berücksichtigt werden. Wenn das Team keine Erfahrung mit der Betreuung lokaler GPUs hat, ist es praktischer, mit BYOK-Lösungen wie OpenRouter zu beginnen.

Unterschrift: Yongliang