Mercury 2

Was ist Mercury 2?

Mercury 2 ist ein auf Reasoning spezialisiertes Large Language Model (LLM) von Inception. Sein Kernzweck ist schnelle Reasoning-Leistung für Produktions-AI-Workloads – insbesondere dort, wo Latenz in iterativen „Schleifen“ wie Agent-Schritten, Retrieval-Pipelines und Extraktionsjobs kumuliert.

Im Gegensatz zu autoregressiven Modellen, die tokenweise von links nach rechts generieren, verwendet Mercury 2 einen diffusion-basierten Ansatz für Echtzeit-Reasoning. Das Modell erzeugt Ausgaben durch parallele Verfeinerung, produziert mehrere Tokens gleichzeitig und konvergiert in wenigen Schritten.

Wichtige Features

• Diffusion-basiertes, paralleles Verfeinerungs-Generieren: Erzeugt mehrere Tokens gleichzeitig statt sequentieller Dekodierung, für geringere End-to-End-Latenz in interaktiven Systemen.
• Für Produktion optimierte Geschwindigkeit: Gemeldet als 1.009 Tokens/Sek. auf NVIDIA Blackwell GPUs, entwickelt zur Reduzierung wahrgenommener Wartezeiten unter Last.
• Abstimmbares Reasoning: Ermöglicht Konfiguration des Reasoning-Verhaltens bei Erhaltung des Speed–Quality-Gleichgewichts.
• 128K Kontext: Unterstützt lange Eingaben über ein 128K-Kontextfenster.
• Native Tool-Nutzung: Beinhaltet integrierte Fähigkeit zum Aufruf von Tools in Reasoning-Workflows.
• Schema-ausgerichtete JSON-Ausgabe: Kann strukturierte Ausgaben liefern, die einem Schema entsprechen, nützlich für nachgelagerte Automatisierung.

So nutzen Sie Mercury 2

1. Integrieren Sie Mercury 2 in Ihren LLM-Pipeline, wo Latenz zählt (z. B. Agent-Schleifen, retrieval-angereicherte Workflows oder Extraktionsaufgaben).
2. Wählen Sie eine Reasoning-Einstellung, die zu Ihren Qualitäts- und Reaktionszeit-Anforderungen passt (das Modell unterstützt abstimmbares Reasoning).
3. Geben Sie Eingaben innerhalb des 128K-Kontextfensters an und fordern Sie bei Bedarf schema-ausgerichtete JSON-Ausgabe für zuverlässiges Parsen an.
4. Nutzen Sie Tool-Aufrufe für Workflows, die externe Aktionen erfordern (z. B. Suche, Datenbankabfragen oder andere tool-gestützte Schritte), besonders in mehrstufigen Agent-Szenarien.

Anwendungsfälle

• Coding- und Editier-Workflows: Autovervollständigung, Vorschläge für nächste Edits, Refactorings und interaktive Code-Agents, bei denen Pausen den Entwicklungsfluss stören können.
• Agentic-Loop-Aufgaben: Systeme, die viele Inferenz-Aufrufe pro Job verketten (z. B. mehrstufige Entscheidungsfindung), wo reduzierte Latenz pro Aufruf mehr erschwingliche Schritte ermöglicht.
• Echtzeit-Sprache und Interaktion: Sprachschnittstellen und interaktive HCI-Szenarien mit engen Latenzbudgets, wo schnelleres Reasoning sprachähnliche Interaktion responsiv hält.
• Such- und RAG-Pipelines: Multi-Hop-Retrieval- und Zusammenfassungs-Workflows, bei denen Reasoning in die Suchschleife integriert wird, ohne Latenzgrenzen zu überschreiten.
• Transkript-Reinigung und andere iterative Transformationsaufgaben: Anwendungen, die schnelle, konsistente Transformationen und Verfeinerungen über benutzergerichtete Schnittstellen benötigen.

FAQ

Worin unterscheidet sich Mercury 2 von typischem LLM-Decoding? Mercury 2 wird als diffusion-basiert beschrieben und generiert Antworten durch parallele Verfeinerung statt sequentieller, tokenweise autoregressiver Dekodierung.

Welche Leistungsmerkmale werden für Mercury 2 angegeben? Die Seite berichtet von >5x schnellerer Generierung und 1.009 Tokens/Sek. auf NVIDIA Blackwell GPUs, sowie Hinweisen zur Optimierung der benutzerspezifischen Responsivität (einschließlich p95-Latenz bei hoher Parallelität).

Welche Kontextlänge unterstützt Mercury 2? Es werden 128K Kontext aufgeführt.

Kann Mercury 2 strukturierte Ausgaben erzeugen? Ja. Es wird als Unterstützung von schema-ausgerichteter JSON-Ausgabe für strukturierte Antworten beschrieben.

Unterstützt Mercury 2 Tool-Nutzung? Die Seite gibt native Tool-Nutzung an, gedacht zur Integration von Tools in Reasoning-Workflows.

Alternativen

• Autoregressive Reasoning-LLMs: Traditionelle tokenweise LLMs sind einfacher zu integrieren, generieren aber typischerweise sequentiell, was Latenz in mehrstufigen Schleifen erhöhen kann.
• Andere diffusion- oder nicht-autoregressive Generierungsansätze: Alternative Modellarchitekturen für parallele Generierung zielen auf ähnliche Latenzziele ab, wobei Implementierungsdetails und Ausgabeverhalten variieren können.
• Kleinere, auf Geschwindigkeit optimierte LLMs für interaktive Nutzung: Modelle mit Fokus auf niedrige Latenz opfern möglicherweise Reasoning-Tiefe oder Steuerbarkeit im Vergleich zu einem reasoning-optimierten Setup wie Mercury 2.
• Agent/RAG-Orchestrierungsstrategien zur Minimierung von Aufrufen: Statt der Modellarchitektur zu ändern, können Teams Latenz durch Workflow-Umschichtung reduzieren (z. B. weniger Retrieval-Schritte, Caching oder Batching), was jedoch die Reasoning-Menge pro Aufgabe einschränken kann.