Wir haben Qwen3.7-Plus 10 echte Bugs und 15 AIME-Probleme gegeben. Es hat das Flaggschiff-Modell in beiden Bereichen übertroffen.

Zusammenfassung

Mitte Mai 2026 tauchten Qwen3.7-Max und Qwen3.7-Plus überraschend auf der LM Arena auf. @Alibaba_Qwen setzte die Erwartungen der Community mit der Aussage „Alibaba #6 bei Text, #5 bei Vision“. Am 2. Juni veröffentlichte das Alibaba Cloud Tongyi Qianwen Team dieses multimodale Agentenmodell offiziell. Es ist bereits auf Alibaba Cloud Model Studio und Qwen Chat verfügbar; der API-Zugriff erfolgt unter alibaba/qwen3.7-plus zu einem Listenpreis von etwa USD 0,40 / USD 1,60 pro Million Input/Output-Token.

Die offizielle Positionierung ist klar: Plus ist das kosteneffiziente multimodale Modell; Max ist das Text-Flaggschiff.

Wir haben einen Nachmittag lang eine umfangreiche Testreihe mit Qwen3.6-plus, Qwen3.7-plus und Qwen3.7-

1Max

Die Ergebnisse sollten als 5 Beobachtungen auf Aufgabenebene gelesen werden, nicht als allgemeines Modell-Ranking:

1. BugFind-10 Einzeldurchlauf: Plus hat alle externen pytest-Prüfungen bestanden. In dieser 10-Aufgaben-Suite, unter Verwendung des offiziellen Stirrup-Frameworks und im Einzeldurchlauf, erzielte Plus 10/10, während Max und 3.6-Plus 9/10 erreichten. Dies deutet auf eine gute Eignung für diese Aufgabenstellung hin; es sollte jedoch nicht auf ein allgemeines Coding-Ranking extrapoliert werden.
2. Mathe: Plus mit aktiviertem "Thinking"-Modus erreichte denselben Score wie Max im Einzeldurchlauf. Bei 15 Wettbewerbsaufgaben beantworteten Plus und Max beide 14 korrekt; in diesem Durchlauf benötigte Qwen3.7-plus deutlich weniger Zeit als Qwen3.7-Max (113s vs. 303s pro Aufgabe).
3. Ein generationeller Geschwindigkeitssprung: Bei Agentenaufgaben erreichte der End-to-End-Durchsatz für Qwen3.7-plus 147,5 t/s, während Qwen3.6-plus nur 41,5 t/s erreichte – eine 3,55-fache Verbesserung. Matheaufgaben, die die Vorgängergeneration nicht abschließen konnte, wurden leicht lösbar.
4. Multimodalität weist noch Fehler auf: In unseren kontrollierten multimodalen Tests beantwortete Qwen3.7-plus einfache Bildfragen korrekt, aber das offizielle Beispielbild dog_and_girl.jpeg wurde als „ein Zug und eine Menschenmenge“ beschrieben.
5. Einige Fähigkeiten waren nahe an Max, bei gleichzeitigem Latenzvorteil: In mehreren Tests dieses Durchlaufs erzielte Qwen3.7-plus Ergebnisse nahe an Qwen3.7-Max bei geringerer Latenz. Dies ist keine allgemeine Ranking-Behauptung.

Nachfolgend finden Sie die vollständigen Testdaten, die Methodik und Empfehlungen zur Modellauswahl für Engineering-Leads. Alle Vergleiche beziehen sich ausschließlich auf diese kleine Stichprobe, den Einzeldurchlauf und das festgelegte Framework.

0. Modellfähigkeiten und Kontext der Bestenliste

Die Produktlinie von Alibaba Qwen hatte sich bereits in der 3.6-Generation eingependelt: Max = Text-Flaggschiff, Plus = multimodales Modell für langen Kontext. Version 3.7 setzt diese Logik fort:

1. Wie positioniert die offizielle Story das Modell "Plus"?

Der Launch-Post von Alibaba Qwen reduziert die Botschaft auf einen Satz:

"Ein Modell. Sieht, denkt, schreibt Code, handelt."

Die Kernpunkte sind: ein multimodaler interaktiver Hybrid-Agent mit einheitlicher GUI- & CLI-Bedienung, ein vielseitiger Coding-Agent und Generalisierung über Agenten-Frameworks hinweg. Qwen-Core-Entwickler shuai bai_ erläuterte dies weiter:

Unser Ziel ist es, multimodale KI von einer passiven Bildbeschreibung zu einem aktiven Problemlöser zu machen: einem Modell, das sehen, schlussfolgern, Code schreiben, Interfaces bedienen und Ergebnisse verifizieren kann. Es ist ein Schritt hin zu wahrhaft agentischer multimodaler Intelligenz.

Die Performance-Posts aus dem offiziellen Thread verdeutlichen die Positionierung:

• Text-Performance ist "nahe am Max-Niveau" (Anbieter-Aussage)
• Multimodale Verbesserungen konzentrieren sich auf Kern-Agentenfähigkeiten: komplexes visuelles Verständnis, visuelles Schlussfolgern, Tool-Nutzung sowie Code-/GUI-Ausführung.

2. Unsere Evaluierungsmethode: Vier Aufgabentypen und eine harte Regel

Um den Test fair zu halten, nutzen wir eine kleine Suite namens BugFind-10: 10 reale Bugs in den Bereichen Preisberechnung, Array-Grenzen, Pfadbehandlung, Nebenläufigkeit, JSON, SQL, Cache-Verhalten, Unicode, Konfiguration und mehr. Jeder Bug enthält pytest-Tests. Das Modell muss innerhalb des offiziellen Stirrup-Agent-Frameworks mit lokalen Code-Ausführungs-Tools arbeiten und den gesamten Loop eigenständig vollziehen: "Reproduzieren → Lokalisieren → Produktionscode editieren → Tests ausführen."

Warum eine eigene Test-Suite?

Öffentliche Bestenlisten haben drei häufige Schwachstellen:

1. Auswendiglernen und Leaks: Flaggschiff-Modelle sind bei älteren Problemen bereits gesättigt. Wir wählten AIME 2025, einen Wettbewerb, der erst nach den wahrscheinlichen Trainings-Cutoffs der Modelle veröffentlicht wurde.
2. Selbstberichte der Anbieter können von unabhängigen Nachtests abweichen: dieselbe Metrik kann je nach Datensatzversion, aktiviertem Thinking-Modus und erlaubten Tools stark variieren.
3. Agenten-Benchmarks hängen vom Framework ab: Verschiedene Agenten-Frameworks können Scores um 2–3 Prozentpunkte verschieben. Wir haben das Framework auf das offizielle Stirrup festgelegt und eine externe Verifizierung hinzugefügt.

Die vier Testaufgaben

Unsere harte Regel: Code-Scores zählen nur unter externem pytest

Dies ist das Fundament der gesamten Überprüfung. Es adressiert direkt die Sorge, dass ein Agent, der behauptet "Tests bestanden", nicht ausreicht.

Prozess:

1. Der Agent editiert Code im Workspace, führt selbst pytest aus und schreibt ein CHANGELOG.
2. Wir kopieren den modifizierten Produktionscode in eine isolierte Umgebung und führen pytest unabhängig aus.
3. Wir veröffentlichen nur den Exit-Code und den Fehler-Stack aus Schritt 2.

Eine Analogie: Der Agent ist der Prüfling. Wir lesen nicht nur die Antwort, die er abgibt; wir nehmen die Antwort in einen anderen Raum und korrigieren sie erneut, um uns nicht auf seine eigene Einschätzung zu verlassen.

3. Code- und Agentenfähigkeiten

Übersicht der drei Modelle

Dass Plus im BugFind-Einzeldurchlauf besser abschnitt, war unerwartet:

1. Plus war der einzige 10/10-Durchlauf in diesem Test.
2. Max nutzte die wenigsten Aufrufe, erreichte aber nicht die volle Punktzahl. 3.7-Max stoppte nach nur 20 Modellaufrufen. Es neigte dazu, „lange nachzudenken und eine große Änderung vorzunehmen“, mit weniger Iterationen. Im Gegensatz dazu nutzte 3.7-Plus 52 Aufrufe und war bereit, zu editieren, auszuführen, Feedback zu prüfen und erneut zu editieren.
3. Plus hatte die kürzeste Laufzeit und den höchsten Durchsatz. Für die IDE-Agenten-Erfahrung ist das weitaus wichtiger als ein paar Elo-Punkte auf einer Bestenliste.

Eine Aufgabe, drei Reparatur-Philosophien: Deep Dive in task05

Diese Aufgabe testet die Regel, dass ungültiges JSON nicht stillschweigend geschluckt werden darf. Beim Parsen fehlerhafter Daten darf kein Erfolg vorgetäuscht und kein leeres Objekt zurückgegeben werden; der Fehler muss klar gemeldet werden. Der ursprüngliche Bug:

plaintextCopy
1def safe_parse(data: str):
2    try:
3        return json.loads(data)
4    except Exception:
5        return {}   # Bug: schluckt die Exception

Die Tests fordern:

• Bei Input wie "dies ist kein json {" darf die Funktion kein leeres dict {} zurückgeben.
• Bei ungültigem Input ohne geschweifte Klammern, wie "schlecht", muss eine Exception ausgelöst werden.

Der Ansatz von Max (externer Test ✗): eine benutzerdefinierte JSONParseError auslösen.

Das sieht nach einer sauberen Lösung aus, aber bei "dies ist kein json {" trat der Fehler sofort auf, sodass der Test fehlschlug, noch bevor die erste Assertion überhaupt laufen konnte. Dennoch sagte das CHANGELOG von Max selbstbewusst "27 bestanden". Genau deshalb ist eine externe Verifizierung obligatorisch: Selbsteinschätzung eines Agenten und externes Audit gehen oft auseinander.

3.6-Plus (extern ✗): scheiterte an derselben ersten Hürde.

3.7-Plus (extern ✓):

plaintextCopy
1if re.search(r'[\{\[\]\}]', data):
2    return {"error": str(e), "raw": data}
3raise ValueError(f"Ungültiges JSON: {e}") from e

Bei fehlerhaftem Input, der Klammern enthält, gibt es ein Fehlerobjekt zurück, das von

1{}

Warum verpasste Max bei dieser Aufgabe die volle Punktzahl? Betrachten wir die Aufrufanzahlen:

3.7-Max stoppte nach nur 20 Modellaufrufen. Es neigte dazu, „lange nachzudenken und eine große Änderung vorzunehmen“, mit weniger Iteration. 3.7-Plus nutzte 52 Aufrufe und war bereit, Feedback zu verarbeiten. Bei Agenten-Coding-Aufgaben, die wiederholte Interaktion mit der Umgebung erfordern, kann mehr Iteration helfen, Grenzfälle abzudecken, die Max in diesem Durchlauf verpasste. Dies deutet auf eine oft übersehene Tatsache hin: "Tieferes Denken" bedeutet bei Agentenaufgaben nicht unbedingt stabilere Ergebnisse. Die Nutzung von Tool-Feedback ist ebenso wichtig.

Engineering-Takeaways:

• Bei Agentenaufgaben ist die Bereitschaft, mit der Umgebung zu ringen, wichtiger als minimale Iteration.
• Max stoppte nach 20 Runden und glaubte verfrüht, task05 gelöst zu haben.

4. Reasoning und Mathe: Thinking-Modus ist eine Kostenentscheidung

Die Qwen3.7-Serie betont "hybrides Denken", gesteuert über den

1enable_thinking

Grenznutzen des Thinking-Schalters

Mit aktiviertem Reasoning erreichte Plus im Einzeldurchlauf denselben AIME-Score wie Max. 3.7-Plus mit Thinking an und 3.7-Max erzielten beide 14/15, aber Plus benötigte 113 Sekunden pro Aufgabe, während Max 303 Sekunden benötigte.

Bei 8 Grundschul-Textaufgaben waren beide Modi zu 100 % korrekt. Das Thinking-Modus verbrauchte nur 24 % mehr Token. Fazit:

Schalten Sie Thinking für einfache Aufgaben aus, um Geld zu sparen; schalten Sie es für schwere Aufgaben ein, um Genauigkeit zu erkaufen. Den Reasoning-Modus global aktiviert zu lassen bedeutet, bei einfachen Anfragen kontinuierlich mehr als das Vierfache zu zahlen, ohne Genauigkeitsgewinn.

5. Geschwindigkeit und die generationelle Lücke

Durchsatzvergleich (End-to-End)

Echte End-to-End-Geschwindigkeit aus den BugFind-Runner-Logs:

• 3.7-Plus: 147,5 t/s
• 3.7-Max: 51,8 t/s
• 3.6-Plus: 41,5 t/s

Die generationelle Verbesserung (3.6 → 3.7 Plus) lag bei etwa 3,55x.

Rat für Engineering-Teams: Bei Thinking-Modellen können traditionelle Timeout- und max_tokens-Strategien versagen. Sie benötigen ein Gesamt-Token-Budget, ein striktes Wall-Time-Limit oder ein Reasoning-Token-Limit.

6. Multimodalität: Kontrolliertes Bild bestanden, offizielle Probe fehlgeschlagen

Arena Vision stuft Plus um #16 (Preview) ein. Unser Test zeigt: Ein hoher Bestenlisten-Score und ein einzelner Bildfehler können koexistieren.

Rat an Modell-Anwender: Führen Sie 20–50 Bilder aus Ihrem eigenen Geschäftsbereich (OCR, Charts, UI-Screenshots) aus – das ist deutlich verlässlicher als das Lesen einer Bestenliste.

7. Kosten: Was diese Testrunde kostete

Die realen API-Kosten beliefen sich auf etwa 2 Millionen Token, mit Kosten von ca. USD 2-3.

• Erkenntnis 1: Eine ernsthafte Evaluierung kostet so viel wie eine Mahlzeit. Teams sollten das Geld in das Wiederholen eigener Aufgaben investieren, nicht in Marketing-Texte.
• Erkenntnis 2: Agenten-Kosten entstehen primär durch Anzahl der Runden × Historienlänge.

8. Fazit

Im offiziellen Narrativ von Juni 2026 ist Qwen3.7-Plus das chinesische Flaggschiff-Modell der Vision-Bestenliste, die kosteneffiziente Gateway-Wahl und ein Modell mit beängstigender Iterationsgeschwindigkeit.

In unserem reproduzierbaren Universum ist es:

• Das Modell, das als einziges im BugFind-Run 10/10 erzielte.
• Das Modell, das bei Mathe-Aufgaben mit aktiviertem Thinking den gleichen Score wie Max bei niedrigerer Latenz erreichte.
• Das Modell, das eine 3,55-fache Durchsatzverbesserung gegenüber der Vorgängergeneration lieferte.
• Das Modell, das beim offiziellen Beispielbild halluzinierte, aber unsere kontrollierten Tests bestand.

Für Ingenieure gilt: Das offizielle Narrativ ist für die Vision zuständig; das outputs/-Verzeichnis ist für die Beweise zuständig. Wenn Sie ein Modell für die Produktion wählen, vertrauen Sie zuerst den Zahlen.