Mercury – ultraschnelles Sprachmodell auf Diffusionsbasis

 (arxiv.org)
10 Punkte von GN⁺ 2025-07-08 | 1 Kommentare | Auf WhatsApp teilen
  • Mercury ist ein neues kommerzielles Large Language Model (LLM), das einen Diffusionsansatz nutzt
  • Das Modell basiert auf einer Transformer-Architektur und zeichnet sich dadurch aus, mehrere Tokens parallel vorherzusagen
  • Mercury Coder ist die erste Diffusions-LLM-Serie, wurde für die Code-Erstellung entwickelt und ist in den zwei Größen Mini und Small verfügbar
  • Auf NVIDIA-H100-GPUs erreicht es einen Durchsatz von 1109 (Mini) bzw. 737 (Small) Tokens pro Sekunde und ist bei gleicher Qualität bis zu 10-mal schneller als bestehende, auf Geschwindigkeit optimierte Modelle
  • Auch in praxisnahen Benchmarks und in Entwicklerbewertungen wie Copilot Arena erreicht es Platz 2 bei der Qualität und den Spitzenplatz bei der Geschwindigkeit; zudem stehen eine öffentliche API und ein Playground zur Verfügung

Überblick

  • Mercury ist eine neue Familie großer Sprachmodelle auf Diffusionsbasis, die in kommerziellem Maßstab arbeitet und eine neue Generation von LLMs darstellt
  • Alle Modelle sind mit einer Transformer-Architektur parametrisiert und darauf trainiert, mehrere Tokens parallel vorherzusagen
  • Dieser Bericht stellt vor allem die erste Reihe von Mercury Coder vor, die primär für Code-Generation-Anwendungen entwickelt wurde
  • Mercury Coder ist derzeit in zwei Modellgrößen verfügbar: Mini und Small

Zentrale Beiträge

  • Mercury Coder erreicht ein neues State-of-the-Art beim Gleichgewicht zwischen Geschwindigkeit und Qualität
  • Laut der externen Bewertungsstelle Artificial Analysis:
    • Mercury Coder Mini: 1109 Tokens pro Sekunde
    • Mercury Coder Small: 737 Tokens pro Sekunde auf NVIDIA-H100-GPUs
    • Im Durchschnitt bis zu 10-mal schneller als die schnellsten Frontier-Modelle bei vergleichbarer Qualität
  • Zusätzlich werden weitere Evaluationsergebnisse für Code-Benchmarks über verschiedene Programmiersprachen und Anwendungsfälle hinweg bereitgestellt
  • Auch in realen Entwicklerumgebungen (Copilot Arena) wurde erreicht:
    • Platz 2 bei der Qualität
    • Platz 1 insgesamt bei der Geschwindigkeit
  • Unterstützt werden eine frei nutzbare öffentliche API ( platform.inceptionlabs.ai ) sowie ein kostenloser Chat-Playground ( chat.inceptionlabs.ai )

Erklärung der Inhaltsstruktur

  • Introduction(Einführung)
    • Contributions(Zentrale Beiträge)
  • Inception Mercury Model Family(Beschreibung der Modellfamilie)
    • Training(Training)
    • Inference(Inferenz)
  • Capabilities(Modellfähigkeiten)
    • Baselines(Basislinien)
    • Coding Capabilities(Code-Fähigkeiten)
      • Evaluation Benchmarks(Evaluations-Benchmarks)

Zusammenfassung

  • Mercury kombiniert ein innovatives LLM-Design auf Diffusionsbasis mit einer Architektur zur parallelen Vorhersage und erreicht damit überragende Geschwindigkeit und hohe Qualität bei der Code-Generierung
  • Mit Modellen in verschiedenen Größen, starken praxisnahen Benchmarks und einfacher Zugänglichkeit bietet es sowohl im kommerziellen Einsatz als auch in Entwicklungsumgebungen eine wettbewerbsfähige Option

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-08
Hacker-News-Kommentare

  • Es wird betont, dass mit der Einführung von LLM-Agenten die Testleistung zu einem noch gravierenderen CPU-Flaschenhals werden dürfte und bereits jetzt alle Teams wegen der CI-Geschwindigkeit unter Engpässen leiden.
    Selbst wenn Agenten 100-mal schneller als Menschen Code schreiben, bringt das wenig, wenn die Tests eine Stunde dauern.
    In vielen Projekten, an denen ich gearbeitet habe, wurde viel Entwicklerzeit verschwendet, während man darauf wartete, dass Änderungen übernommen werden, und viele Ausführungen waren durch I/O oder zu wenige Worker ausgebremst.
    Wenn Coding-Agenten einfache Tickets schnell in PRs umwandeln und auf Testfehler in Echtzeit reagieren und direkt nachbessern, wird sich der CI-Flaschenhals weiter verschärfen.
    Bei den Testumgebungen der meisten Projekte gäbe es viel Raum für Verbesserungen, tatsächlich hat man sich aber über Jahre hinweg an langsame CI und hohe Kosten gewöhnt, ohne nennenswerte Fortschritte zu machen.
    CI wurde sogar noch langsamer, wenn man Caching deaktivierte, um Builds vollständig zu isolieren, oder von On-Prem auf langsame Cloud-VMs wechselte.
    Mercury ist wahnsinnig schnell, und nach ein paar Tests waren auch Codequalität und Genauigkeit hervorragend, aber nun bleibt die Herausforderung, die Testausführung auf dieses Tempo zu bringen.

    • Ich finde es schwer nachvollziehbar, dass in den meisten Projekten, an denen ich gearbeitet habe, Entwicklerzeit durch das Warten auf PR-Freigaben verschwendet wird.
      Aus Unternehmenssicht ist Entwicklungszeit viel teurer als Maschinenzeit, daher kann man die Zahl der CI-Worker einfach verdoppeln, sobald sich Entwickler beschweren.
      Bei Google wurde beim Debugging von Test-Flakiness teils auf 10.000 Maschinen 10.000-mal getestet, um seltene Fehler zu finden.
      Mein aktueller Arbeitgeber bietet etwas Ähnliches an: Mit einem einzigen Kommando lassen sich alle Tests parallel auf 1.000 Workern ausführen, damit man selbst bei einem Projekt mit 1M LOC innerhalb von 5 Minuten Feedback bekommt.
      Vollständig isolierte Builds und der Verzicht auf Caching sind zwei verschiedene Dinge; man sollte Builds vollständig isolieren und trotzdem alle Caches maximal nutzen.

    • Wenn die Implementierung schneller wird, dürfte der Flaschenhals in Richtung PM wandern, und dadurch könnten Konflikte deutlich seltener werden, weil Änderungen stärker serialisiert verarbeitet werden.
      Es könnte auch zu einer Wiederbelebung von Spezifikationssprachen wie TLA+ kommen, weil Agenten diese schnell schreiben und verifizieren könnten, was die Zahl umfassender Integrationstests senken würde.
      Wenn Hintergrundagenten doppelten Code aufräumen, könnten sie dabei auch doppelte Tests bereinigen.
      AI dürfte im Unterschied zu menschlichen Engineering-Teams mit monolithischen Strukturen effizienter arbeiten; dadurch könnte mehr Testabdeckung lokal laufen, was weniger flaky Tests und geringere CI-Last bedeuten würde.
      Auch wenn AI die Effizienz erhöht, wird sie zugleich mehr Code sowie schnellere Code-Erstellung und -Ausführung erzeugen, wodurch ständig neue Probleme entstehen, die menschliche Engineers lösen müssen.

    • Für schnelle Korrekturen unter 100 Zeilen oder als Rubber-Duck ist ein LLM okay, aber wenn man es direkt in die CI-Pipeline eines großen Projekts einbaut, drohen Produktivitätseinbußen im Umfang von Hunderten Stunden.
      Wenn man am Ende nur Prompt-Tuning und Kontextanpassung betreibt, statt die eigene Fähigkeit zum Coden zu verbessern, hat das keinen Sinn.
      Ich habe das Gefühl, dass das Vertrauen in LLM-Tooling viel zu groß ist, und ich glaube nicht, dass es sich gut auf komplexe Systeme anwenden lässt.
      Ein LLM unbeaufsichtigt auf ein wichtiges Repository loszulassen, käme für mich nur infrage, wenn man mir "eine Waffe an den Kopf hält".
      Am Ende überarbeitet man das Ergebnis des LLMs ohnehin halb von Hand, und dann kann man es auch gleich selbst machen.

    • Vor dem Auto gab man fast kein Geld für Benzin, Öl oder Wartung aus, doch mit fortschreitenden Systemen kommen passende Begleitinfrastruktur und Kosten automatisch dazu.
      Man kann mit AI Engpässe beseitigen oder mehr Features bauen und den Umsatz maximieren und mit diesen zusätzlichen Einnahmen dann mehr CI-Ressourcen beschaffen.
      AI ist im Grunde nicht anders, als zehn zusätzliche Entwickler einzustellen, und entsprechend steigen auch die Supportkosten.
      Man sollte sich fragen, ob man den Bedarf an mehr CI-Ressourcen logisch mit Effizienzgewinnen begründen oder eine Richtung zur Optimierung aufzeigen kann.
      Ich frage mich, wie hoch die Kosten pro CI-Ressource bzw. pro Maschine sind.

    • Bei einer Python-App habe ich mit der astral.sh-Toolchain sowie uv-Paketinstallation plus Caching die CI deutlich beschleunigt.
      Demnächst will ich statt mypy auf den Typechecker von astral wechseln, dann dürfte es noch schneller werden.
      Bei Apps mit Frontend sind Playwright-Tests vermutlich der langsamste Teil, aber bei anderen Apps trifft selbst das nicht zu.
      (P.S.: Falls Mike recht hat, erinnere ich mich an ihn als SRE, mit dem ich Anfang der 2000er bei Google Maps gearbeitet habe; das macht seine Einschätzung für mich glaubwürdig.)

  • Als ich im Mercury-Playground nach einem Regex-Muster fragte, begann das Modell von selbst zu planen, das Muster zu schreiben und anschließend Tests zu erzeugen.
    Dann fügte es aber endlos weitere Tests hinzu, bis es an die Kontextgrenze stieß und die Antwort abbrach.
    Nach etwa 30 Stück fing es an, Testresultat-Kommentare falsch zuzuordnen, und nach über 120 wurden sogar die Testeingaben selbst seltsam und voller Zufallszeichen.
    Das Muster selbst war auch nicht korrekt, aber dieses Phänomen einer „Endlosschleife“ war noch interessanter.

    • Zur Einordnung: Bis vor nicht allzu langer Zeit erzeugten auch normale LLMs gelegentlich solche sich wiederholenden Ausgaben, die wie „fast unendliche Schleifen“ wirkten.
      Sie blieben in einem Muster hängen, bei dem sich die Ausgabe nur minimal veränderte.

    • Ich halte diesen Fall für ein typisches Beispiel dafür, dass man mit bloßer Token-Vorhersage keinen korrekten Code erzeugen kann.
      LLMs wurden von Grund auf nicht dafür entworfen, gut über Code nachzudenken.

  • Nach der Lektüre des technischen Berichts habe ich bestätigt, dass Mercury auf dem Paper Lou et al. 2023, SEDD basiert.
    Ich habe SEDD als wohl Erster vollständig from scratch reimplementiert und den Code veröffentlicht.
    Ich habe auch die komplexe Denoising-Methode selbst implementiert.
    Das Ganze habe ich sauberer und lesbarer als das ursprüngliche SEDD gestaltet, und auf einem einzelnen GPU lässt es sich mit einem Spielzeug-Datensatz innerhalb weniger Stunden ausführen.

  • Zur Info: Auch DeepMind hat ein diffusion-basiertes Gemini-Modell (Link).
    Nach eigenen Tests war es wie Mercury wahnsinnig schnell, aber die Antwortqualität lag deutlich unter der anderer Gemini-Modelle.

    • Nach kurzem Ausprobieren stimme ich zu: Die Geschwindigkeit ist beeindruckend, aber die Trefferquote fällt deutlich ab.

    • Ich frage mich, ob die Gemini-Diffusion-Demo kostenlos ist.
      Ich stehe seit Tagen auf der Warteliste und finde es schade, dass ich es noch nicht selbst ausprobieren konnte.

  • Ich persönlich freue mich sehr über solche Fortschritte.
    Bei einem Game Jam habe ich kürzlich mit AI ein kleines Spiel programmiert, und mehr als die Hälfte der Zeit ging fürs Warten auf Ergebnisse drauf.
    Wenn man statt 1–2 Minuten pro Prompt nur 10 Sekunden warten muss, kann man in der Zeit eines einzigen bisherigen Tests fünf bis zehn Experimente durchführen.
    Mercury ist zwar noch nicht reif genug für den praktischen Einsatz, aber Claude 3.0 war vor einem Jahr ebenfalls noch unausgereift, also dürfte es von hier an besser werden.
    Ich bin wirklich gespannt, was als Nächstes kommt.

  • Ich habe den Mercury-Playground ausprobiert, und die Geschwindigkeit ist wirklich enorm.
    Die Visualisierung des Diffusion-Modus ist zwar originell, praktisch zeigt sie aber wohl nur, wie aus visualisiertem Linienrauschen nach und nach ein präziserer Zustand wird.
    Tatsächlich ist es wohl eher als ein Prozess zu verstehen, bei dem in einem beliebigen Vektorraum schrittweise auf eindeutigere Tokens konvergiert wird.

    • Einige Text-Diffusion-Modelle verwenden einen kontinuierlichen latenten Raum, aber die Leistung ist nicht besonders gut.
      In letzter Zeit konzentriert man sich meist auf die Vorhersage echter Ausgabe-Tokens und korrigiert in jedem Schritt den vorherigen Wert, bis man zum Endergebnis konvergiert.
      Ich empfehle dazu meinen Text Wie Text-Diffusion funktioniert.

    • Link: https://chat.inceptionlabs.ai/

    • Es fühlt sich wirklich absurd schnell an.

  • In den meisten GPU-nahen Codepfaden gibt es enorm viel Spielraum für Performance-Optimierung.
    Allerdings frage ich mich, ob das arXiv-Paper eher Marketing als echte Forschung ist.
    Andere Meinungen sind willkommen.

    • Ganz falsch ist der Punkt nicht, aber solche Fälle sind auf arXiv nun wirklich nichts Neues.

  • Preisgestaltung des Mercury-Modells
    1 US-Dollar pro 1 Million Output-Tokens, 0,25 US-Dollar pro 1 Million Input-Tokens
    Weitere Preisdetails gibt es hier.

    • Der Preis ist etwas hoch.
      Wenn Performance entscheidend ist, war bei Vergleichen zwischen Mercury und Groq (Llama 3.1 8b, Llama 4 Scout) die Leistung ähnlich, aber preislich war Groq deutlich attraktiver.
      Ich beobachte das mit Interesse und hoffe, dass Open-Source-Diffusionsmodelle auftauchen.

  • Im Playground-Code und in den API-Antworten sind gpt-3.5-turbo und "openai": true zu sehen, deshalb frage ich mich, ob in Wahrheit nicht das eigene dLLM, sondern OpenAI aufgerufen wird.
    Die Diffusion-Effect-Funktion oben rechts wirkt wie ein bloßer Animationseffekt.

    • Für ein echtes OpenAI-Backend wäre es viel zu schnell, es fühlt sich eher wie Echtzeit an.

  • Alles klingt zwar großartig,
    aber laut den Nutzungsbedingungen erteilt man Inception beim Einreichen von Nutzerbeiträgen an den Dienst eine weltweit gültige, nicht exklusive, unbefristete, lizenzgebührenfreie und vollständig übertragbare Lizenz.
    Das heißt, Nutzerinhalte können zum Training von AI-Modellen verwendet werden.
    (Allerdings gibt es eine Ausnahmeklausel: Zugriffe über OpenRouter werden nicht für das Training verwendet.)