Wenn KI in Echtzeit denkt

Letzte Woche habe ich Inception Mercury zum ersten Mal getestet. Der Prompt: eine JavaScript-Animation eines Planetensystems mit realistischen Umlaufbahnen. Die Antwort kam in unter einer Sekunde. Nicht die erste Token-Generation, sondern die vollständige, funktionierende Lösung.

Wow.

Diffusion statt Autoregression

Klassische Large Language Models, wie GPT-5, Claude, Llama, arbeiten autogressiv. Sie generieren Token für Token, sequenziell. Das nächste Wort kann erst berechnet werden, wenn das vorherige feststeht. Schneller wird das nur durch mehr Hardware.

Inception Labs geht einen anderen Weg. Ihr Mercury-Modell basiert auf Diffusion. Dieselbe Technologie, welche bei Bildgeneratoren wie Stable Diffusion zum Einsatz kommt. Der Unterschied: Diffusion kann parallel generieren. Nicht Wort für Wort, sondern ganze Sequenzen gleichzeitig.

Metrik Mercury Typische Autoregressive LLMs

Throughput 1.109 tokens/sec ~200 tokens/sec

Latenz 25ms 100-500ms

Preis ~1/4 von Claude Haiku

Das ist kein inkrementeller Fortschritt. Das ist eine andere Größenordnung.

Der Reasoning-Test

Beeindruckende Geschwindigkeit ist wertlos, wenn die Qualität nicht stimmt. Also schnell ein kleiner Test, mit ChatGPT und Claude als Referenz.

Test 1: Logisches Constraint-Solving

Ein Planungsproblem mit fünf Features, Abhängigkeiten und Sprint-Kapazitäten. Multi-Step-Reasoning, nicht googlebar, eindeutig verifizierbar.

ChatGPT: Korrekte Lösung beim ersten Versuch

Mercury: Korrekte Lösung beim zweiten Versuch

Claude: Korrekte Lösung beim zweiten Versuch

Test 2: Quantitatives Reasoning

SaaS Unit Economics: CAC, LTV, Churn-Berechnungen plus strategische Bewertung.

ChatGPT: Korrekt

Mercury: Korrekt

Claud: Korrekt

Der Eindruck deckt sich mit den offiziellen Benchmarks: Mercury erreicht bei Reasoning etwa 58% (deutlich unter den >80% der Frontier-Modelle). Bei Coding und faktischem Wissen liegt es gleichauf.

Trotzdem

Die naive Interpretation: Mercury ist bei komplexem Reasoning schlechter, also für anspruchsvolle Aufgaben ungeeignet.

Die architektonische Interpretation ist eine andere.

Bei 25ms Latenz und einem Viertel der Kosten verändert sich die Rechnung fundamental:

Szenario A: Ein GPT-5 Call

Latenz: ~500ms

Kosten: X

Ergebnis: Meist korrekt beim ersten Versuch

Szenario B: Mercury mit Retry-Logik

Latenz: 25ms + ggf. 25ms = 50ms

Kosten: ~X/4 + ggf. X/4 = ~X/2

Ergebnis: Korrekt nach maximal zwei Versuchen

Selbst mit Retry ist Mercury zehnmal schneller und halb so teuer. Und das ist der worst case. Bei den 80% der Anfragen, die kein komplexes Multi-Step-Reasoning erfordern, gibt es keinen Retry.

Die eigentliche Architektur-Implikation: Mercury ist kein Ersatz für Frontier-Modelle. Es macht Patterns moeglich, die bisher ökonomisch nicht sinnvoll waren.

And now?

Wenn Inference-Kosten gegen Null gehen und Latenz in Millisekunden gemessen wird, öffnen sich neue Designräume:

Continuous Validation Statt punktueller Prüfung: permanente Analyse im Hintergrund. Code-Review während des Tippens, nicht nach dem Commit.

Multi-Agent-Systeme mit hohem Call-Volumen Agentic Workflows mit 50, 100, 200 LLM-Calls pro Task. Bei GPT-4-Preisen prohibitiv, bei Mercury-Preisen Standard.

Kaskadierende Architekturen Mercury als schneller Gatekeeper: Einfache Anfragen direkt beantworten, komplexe an Frontier-Modelle eskalieren. Das Beste aus beiden Welten.

Edge Deployment Die Effizienz ermöglicht lokale Deployments, wo Cloud-Latenz inakzeptabel ist.

Inception hat Mercury bereits in mehrere Entwicklungstools integriert: ProxyAI, Buildglare, Kilo Code. Die Anwendungsfälle sind keine Spekulation mehr.

Die Verbindung

In meinem letzten Artikel habe ich argumentiert: Das Modell bestimmt die Obergrenze, das Interface bestimmt, wie nah wir drankommen. Die Absorptionsfähigkeit der Organisation - nicht die Modell-Capability - ist der limitierende Faktor.

Mercury fügt dieser These eine neue Dimension hinzu. Wenn Modelle commoditisieren, wenn Speed und Kosten keine Differenzierungsmerkmale mehr sind, dann verschiebt sich der Wert noch weiter: zur Orchestrierung.

Welche Anfrage geht an welches Modell? Wann lohnt sich ein Retry? Wie validiere ich Confidence, bevor ich eskaliere? Das sind keine Implementierungsdetails. Das sind die architektonischen Entscheidungen, die über Produktivitätsgewinne entscheiden.

Das Interface bestimmt, wie gut wir ein Modell nutzen. Die Orchestrierung bestimmt, welches Modell wir wann nutzen. Beides zusammen wird zum eigentlichen Moat, statt der Modelle selbst.

Quellen

Inception Labs: Introducing Mercury

Inception Labs: Scaling up Mercury

TechCrunch: Inception raises $50M (November 2025)

Benchable.ai: Mercury Model Benchmarks

arXiv: Mercury - Ultra-Fast Language Models Based on Diffusion