Qwen3-Max-Thinking-Modell vorgestellt

 (qwen.ai)
7 Punkte von GN⁺ 2026-01-27 | 1 Kommentare | Auf WhatsApp teilen
  • Das neueste reasoning-zentrierte Modell steigert seine Leistung in mehreren Bereichen wie Faktenwissen, komplexes Schlussfolgern und Alignment mit menschlichen Präferenzen durch groß angelegtes Reinforcement Learning und Parameterskalierung
  • In 19 Benchmarks erzielte es Ergebnisse auf einem ähnlichen Niveau wie GPT-5.2-Thinking, Claude-Opus-4.5 und Gemini 3 Pro oder übertraf diese in einigen Bereichen
  • Durch die Funktion adaptiver Tool-Nutzung ruft es während Gesprächen automatisch Suche, Memory und Code Interpreter auf und unterstützt so weniger Halluzinationen und Zugriff auf Echtzeitinformationen
  • Mit einer Strategie zur Testzeit-Skalierung (test-time scaling) reduziert es wiederholte Berechnungen während des Schlussfolgerns und steigert die Effizienz durch einen selbstreflexionsbasierten Mechanismus zur Erfahrungssammlung
  • Sofort über Qwen Chat und API nutzbar; zudem kompatibel mit OpenAI- und Anthropic-APIs, sodass Entwickler es leicht in bestehende Workflows integrieren können

Überblick über Qwen3-Max-Thinking

  • Qwen3-Max-Thinking ist das neueste Flaggschiff-Reasoning-Modell der Qwen-Serie und skaliert seine Leistung mithilfe von Reinforcement Learning und umfangreichen Rechenressourcen
    • Verbesserungen in mehreren Dimensionen wie Faktenwissen, komplexes Schlussfolgern, Befolgung von Anweisungen, Alignment mit menschlichen Präferenzen und Agentenfunktionen
    • Erreichte in 19 Standard-Benchmarks ein Leistungsniveau ähnlich zu GPT-5.2-Thinking, Claude-Opus-4.5 und Gemini 3 Pro
  • Wurde durch zwei zentrale Innovationen gestärkt
    • Adaptive Tool-Nutzung (adaptive tool-use): ruft bei Bedarf automatisch Suche und Code Interpreter auf
    • Fortgeschrittene Testzeit-Skalierung (test-time scaling): nutzt zusätzliche Rechenleistung während des Schlussfolgerns effizient und erreicht damit eine Leistung, die Gemini 3 Pro übertrifft

Zusammenfassung der Benchmark-Leistung

  • Im Bereich Wissen (knowledge) erreicht es mit MMLU-Pro 85.7 und C-Eval 93.7 Werte nahe an führenden Modellen
  • In STEM liegt es mit GPQA 87.4 und HLE 30.2 unter einigen Modellen, hält aber eine ausgewogene Gesamtleistung
  • In Reasoning-Benchmarks wurden hohe Werte wie HMMT Nov 25 94.7 und LiveCodeBench v6 85.9 erzielt
  • Bei Befolgung von Anweisungen und Alignment (instruction following & alignment) erreicht es mit Arena-Hard v2 90.2 Spitzenniveau
  • Auch bei Tool-Nutzung (tool use) und agentischer Suche (agentic search) wurden teils bessere Ergebnisse als bei Konkurrenzmodellen bestätigt

Funktion zur adaptiven Tool-Nutzung

  • Auch ohne dass der Nutzer selbst Tools auswählt, nutzt das Modell automatisch Search, Memory und Code Interpreter
    • Search und Memory reduzieren Halluzinationen und ermöglichen Zugriff auf Echtzeitinformationen sowie personalisierte Antworten
    • Code Interpreter unterstützt die Lösung komplexer Probleme durch Codeausführung und berechnungsbasiertes Schlussfolgern
  • Diese Funktionen wurden durch einen zusätzlichen Trainingsprozess gestärkt, der regelbasiertes und modellbasiertes Feedback kombiniert
  • Das Ergebnis ist eine natürliche und leistungsstarke konversationelle Erfahrung

Strategie zur Testzeit-Skalierung

  • Eine Methode zur Leistungssteigerung durch die Verteilung zusätzlicher Rechenleistung während des Schlussfolgerns, effizienter als einfaches paralleles Sampling
  • Der vorgeschlagene Ansatz nutzt einen mehrstufigen, erfahrungssammelnden selbstreflexiven Ansatz (self-reflective multi-round)
    • Über den „take-experience“-Mechanismus werden zentrale Erkenntnisse aus früheren Runden extrahiert
    • Statt bereits gezogene Schlussfolgerungen zu wiederholen, konzentriert er sich auf ungelöste Unsicherheiten
  • Erzielt bei gleichem Token-Verbrauch eine höhere Kontexteffizienz
    • Verbesserungen von GPQA 90.3→92.8, HLE 34.1→36.5, LiveCodeBench v6 88.0→91.4, IMO-AnswerBench 89.5→91.5 und HLE(w/ tools) 55.8→58.3

Entwicklung und API-Integration

  • Sofort in Qwen Chat verfügbar; der Modellname lautet qwen3-max-2026-01-23
  • Nutzbar nach Erstellung eines API-Schlüssels über Alibaba Cloud Model Studio
  • Vollständig kompatibel mit der OpenAI API, inklusive Python-Beispielcode
    • Über die Option enable_thinking kann der Reasoning-Modus aktiviert werden
  • Auch kompatibel mit dem Anthropic-API-Protokoll, sodass es in der Claude Code-Umgebung identisch funktioniert
    • Nach dem Setzen von Umgebungsvariablen über den Befehl claude ausführbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-27
Hacker-News-Kommentare

  • Es gab eine Frage zu einem berühmten Foto, aber das System erkannte es als „unangemessenen Inhalt“ und gab einen Fehler zurück. Der Nutzer fragte sich, warum ein solches Bild international so bedeutsam ist

    • Das scheint an einem separaten Sicherheitsmechanismus zu liegen. Tatsächlich behandelten frühere Qwen-Modelle solche Themen frei, wenn sie außerhalb Chinas betrieben wurden. Zum Beispiel erklärte Qwen3 235B A22B Instruct 2507 den historischen Kontext des „Tank Man“-Fotos und sogar die Zensursituation in China ausführlich. Es gab auch die Analyse, dass diese Zensur selbst die Symbolkraft noch verstärkt habe
    • Bei einem chinesischen Unternehmen ist das nicht überraschend, da es rechtlich zur Zensur verpflichtet ist. Interessant ist eher, wie sich solche Einschränkungen auf unpolitische Bereiche wie Coding-Aufgaben auswirken. Tatsächlich hat auch das US-Unternehmen Anthropic Beschränkungen in Form von „Alignment“, um illegale Handlungen zu verhindern
    • Auch US-amerikanische LLMs haben ähnliche Zensurprobleme. Nur die Ziele der Zensur sind andere
    • Es wurde gefragt, ob es unter Forschern jemanden gibt, der die Möglichkeit von eingebauten bösartigen Verhaltensweisen (Backdoors) in LLMs untersucht. In einigen Papers heißt es, schon mit wenigen bösartigen Beispielen könne ein Modell darauf trainiert werden, auf bestimmte Trigger-Phrasen zu reagieren. Sogar durch Manipulation der Tokenizer-Datei könnten Nebenwirkungen wie steigende API-Kosten oder geschwächte Sicherheitsfilter ausgelöst werden. Es sei wohl an der Zeit, solche Diskussionen ernster zu führen
    • Da dieses Thema Diskussionen oft entgleisen lässt, gab es auch die Meinung, man solle das Gespräch nun wieder auf die technischen Aspekte chinesischer KI-Modelle lenken

  • Es kam die Frage auf, wie hoch bei aktuellen Modellen der Token-Verbrauch ist. „Besseres Reasoning“ oder „mehr Tool-Nutzung“ scheint weniger eine Verbesserung des Modells selbst zu sein als vielmehr eine Methode, das Modell mit mehr Tokens besser zu steuern. Also nicht „mit weniger mehr erreichen“, sondern „mit mehr mehr erreichen“

    • Manche sehen darin die realistische Grenze von AGI (Artificial General Intelligence). Wenn zu viele Rechenressourcen nötig sind, könnte selbst ein technischer Durchbruch die reale Welt auf absehbare Zeit nur begrenzt verändern. Letztlich könnten Rechenressourcen für Inferenz zum Engpass werden
    • Jemand fragte Gemini nach dem Stromverbrauch im Vergleich zur Suche und bekam überraschend die Antwort, dass KI-Suche effizienter als klassische Suche sei. Außerdem machte unter den von Perplexity empfohlenen arXiv-Papers Sara Hookers On the Slow Death of Scaling Eindruck. Das Paper zeigt Fälle, in denen kleine Modelle große Modelle übertreffen, und argumentiert, dass künftiger Fortschritt eher von algorithmischer Innovation als von mehr Rechenleistung abhängt
    • Es brauche neue Metriken, um Modellfortschritte zu bewerten. Statt nur Benchmark-Scores zu betrachten, sollte man auch GPU-Nutzung, Geschwindigkeit und Kosten einbeziehen
    • Als passendes Konzept für dieses Spannungsfeld zwischen Effizienz und Leistung wurde die Pareto frontier genannt
    • Bei manchen Modellen wurde kritisiert, dass sie im Reasoning-Prozess viele Tokens verschwenden und in der Praxis daher ineffizient sind

  • Es wurde gefragt, warum das Modell bei deaktivierter Suche schlechter als Opus 4.5 sei, mit aktivierter Suche aber besser. Vielleicht, so die Vermutung, sei die Qualität der Inhalte im chinesischen Internet höher

    • Das sei wohl eine Überinterpretation. Wahrscheinlicher sei schlicht, dass Suchqualität und Integration besser sind. Das Modell unterstützt mehrere Sprachen und verarbeitet Websites aus aller Welt gut
    • Ich nutze Kagi Assistant und bin zufrieden, weil ich die Suche auf nur wissenschaftliche Quellen filtern kann. Allerdings gibt es die Sorge, dass irgendwann selbst wissenschaftliche Papers mit KI-generierten Inhalten kontaminiert sein könnten. Trotzdem glaube man, dass sich dafür am Ende eine Lösung finden lässt
    • Es gab auch den Scherz: „Vielleicht liegt es daran, dass dort Reddit fehlt?“

  • Es wurde nach der Preisgestaltung der Qwen-Modelle gefragt. Ob Qwen Max zum gleichen Tarif wie andere Modelle berechnet werde und warum die Preise innerhalb Chinas deutlich niedriger seien
    Alibaba-Cloud-Modellseite

    • In China herrscht ein intensiver KI-Preiskrieg, und die Regierung senkt Infrastrukturkosten durch Computing-Gutscheine und Subventionen
      Verwandter Artikel
    • Vermutlich handelt es sich vor allem um Subventionen zur Unterstützung inländischer Entwickler
    • Günstigere Energiekosten könnten ebenfalls ein Faktor sein
    • Es wurde auch das Konzept des surveillance pricing vorgestellt, also einer Preisgestaltung je nach Region und Suchbedingungen, zusammen mit einem Videolink

  • Auf HN galt Opus 4.5 praktisch als Standardmodell, und chinesische Modelle wurden als über acht Monate zurückliegend betrachtet. Es wurde gefragt, ob dieses Modell die Lücke schließen könne

    • Nach den veröffentlichten Benchmarks scheint es weiterhin etwa sechs Monate zurückzuliegen
    • Persönlich wirke GPT-5.2 besser und günstiger. Der Claude-Code-Bias auf HN könnte auch eine Form der Selbstrechtfertigung unter Abonnenten sein. Trotzdem ist Opus 4.5 schnell und qualitativ stark, also in der Praxis sehr gut nutzbar.
      Gemini 3 Pro/Flash liegt dagegen weiterhin eine Stufe darunter, ist verglichen mit dem Vorjahr aber sehr schnell und günstig geworden. Letztlich sind Benchmarks nur ein Anhaltspunkt, während die wahrgenommene Qualität subjektiv bleibt

  • Im vergangenen Herbst wurde Qwen3-coder über den CLI-Agenten trae in einem Rust-Projekt eingesetzt, und seine Fähigkeiten bei Codegenerierung und Refactoring seien besser gewesen als bei Gemini 2.5 Pro oder Claude Opus 3.5.
    Selbst das Hinzufügen von Linux-Shared-Memory-IPC-Aufrufen oder x86_64-SIMD-Optimierungen habe gut funktioniert. Durch Token-Cache und große Kontextfenster seien allerdings monatlich Kosten von mehreren hundert Dollar entstanden

  • Da kein Hugging-Face-Link zu sehen war, kam die Frage auf, ob Qwen keine offenen Modelle mehr veröffentliche

    • Die Max-Version war ursprünglich ein geschlossenes Modell
    • Nicht alle Modelle werden mit offenen Gewichten veröffentlicht, und auch dieses Modell scheint bislang kein Open-Weight-Modell zu sein

  • Es fragte auch jemand, ob das Modell bei Open Router verfügbar sei, verbunden mit der Erwartung eines Vergleichs mit Gemini 3 Flash
    Mafia Arena

  • LLM-Benchmarks seien ein bisschen wie Bewerbungsgespräche für Entwickler. Komplexe Probleme zu verteilten Algorithmen lösen sie gut, aber in realer Arbeit vergessen sie beim Hinzufügen eines einzigen Buttons dann die Wiederverwendung von Tailwind-Klassen

  • Es gab eine Frage nach der Modellgröße

    • Qwen2.5 wurde mit 18 Billionen Tokens trainiert, Qwen3 dagegen mit 36 Billionen Tokens, also fast doppelt so viel. Es umfasst 119 Sprachen und Dialekte
      Offizieller Blog