MiMo-V2.5-Pro-UltraSpeed: Ein 1T-Modell, das 1000 Token pro Sekunde erzeugt

• Das erste Modell, das bei einem Modell mit 1 Billion (1T) Parametern die Decoding-Geschwindigkeit von 1000 tokens/s überschreitet
• Erreicht diese Geschwindigkeit nicht mit Spezialhardware, sondern nur mit Commodity-GPUs, und liefert auf einem einzelnen standardisierten 8-GPU-Knoten 1000+ tps
• Die Schlüsseltechnologie ist ein Modell-System-Codesign, das FP4-Quantisierung und DFlash speculative decoding kombiniert
• Die API wird antragsbasiert und für einen begrenzten Zeitraum angeboten und wirbt mit etwa 10-facher Generierungsgeschwindigkeit bei 3-fachem Preis
• Das Überschreiten von 1000 tps ist nicht nur eine reine Geschwindigkeitssteigerung, sondern ein Wendepunkt, der das Paradigma von KI-Anwendungen selbst verändert, etwa bei Coding Agents und Echtzeit-Entscheidungen

---

Xiaomi MiMo-V2.5-Pro-UltraSpeed veröffentlicht

• In Zusammenarbeit mit TileRT wurde bei einem Modell mit 1 Billion Parametern erstmals eine Decoding-Geschwindigkeit von 1000 tokens/s überschritten, was ein Geschwindigkeitsniveau ermöglicht, das Echtzeitantworten und unmittelbare Iteration erlaubt
• Im Vergleich der Echtzeit-Generierungsgeschwindigkeit wurden bis zu etwa 1200 tokens/s erreicht
• Es wird die Perspektive vorgestellt, dass ein Modell, wenn es schnell genug wird, nicht mehr nur ein Werkzeug zum Warten ist, sondern als Verlängerung des Denkens (extension of thinking) fungiert

Zeitlich begrenzte, antragsbasierte Bereitstellung

• Die API startet zu einem begrenzten Aktionspreis und bietet bei dreifachen Kosten gegenüber MiMo-V2.5-Pro etwa 10-fache Generierungsgeschwindigkeit (nur für die API, ohne Unterstützung für den Token Plan)
• Aufgrund begrenzter Ressourcen für High-Speed-Inferenz erfolgt der Betrieb antragsbasiert und zeitlich begrenzt; nur genehmigte Nutzer können die API vom 9. Juni 2026 bis 23. Juni 2026, 23:59 (UTC+8) verwenden

• So beantragen Sie den Zugang

  • Die API-Plattform ist unter platform.xiaomimimo.com/ultraspeed verfügbar; auch bei Antragstellung ist eine Genehmigung nicht garantiert, und Unternehmen sowie professionelle Entwickler mit tatsächlichem Geschäftsbedarf werden bevorzugt
  • Standardzugang zum Modell wird über die MiMo-V2.5-Serie bereitgestellt

• Chat-Erlebnis (während der Testphase kostenlos)

  • Genehmigte Nutzer erhalten für zwei Wochen kostenlosen Chat-Zugang; Einstiegspunkt ist ultraspeed.xiaomimimo.com
  • Pro Konto sind maximal 10 Warteschlangeneintritte pro Tag erlaubt, maximal 30 Minuten pro Sitzung, bei mehr als 5 Minuten Inaktivität erfolgt eine automatische Trennung

1000 tokens/s — ein Paradigmenwechsel über Geschwindigkeit hinaus

• Das Überschreiten von 1000 tps im 1T-Maßstab ist nicht einfach nur eine schnellere Schreibmaschine, sondern eine Veränderung, die das Paradigma von KI-Anwendungen selbst grundlegend erschüttert

• Geschwindigkeit wird direkt zu Intelligenz

  • Innerhalb derselben realen Zeit (wall-clock) können Dutzende Inferenzpfade parallel ausgeführt werden (Best-of-N / Tree Search); automatische Verifikation und Selbstkorrektur im Hintergrund verbessern die Qualität der Schlussfolgerung unmittelbar

• Aufhebung der Produktivitätsgrenze von Coding Agents

  • Bisher war die Inferenzlatenz der Engpass, sodass Entwickler vor dem Bildschirm warten mussten; bei 1000 tps werden Codegenerierung und Produktivität auf paradigmatischer Ebene beschleunigt

• Eintritt in Echtzeit-Entscheidungsschleifen

  • Mit "think-respond"-Zyklen im Millisekundenbereich kann ein 1T-Flaggschiffmodell mit zeitkritischen Szenarien wie Signalgenerierung für Hochfrequenz-Quant-Trading, sofortige Blockierung anomaler Transaktionen, intelligentes Bidding, Echtzeit-Konversationen kombiniert werden
  • Für Anwendungen in lebensentscheidenden Situationen wie Operationsassistenz oder medizinischer Bildanalyse wird die Perspektive vorgestellt, dass jede Sekunde, die bei Läsionsanalyse und Risikoprognose eingespart wird, Chirurgen zusätzlichen Handlungsspielraum verschafft

Extremes Modell-System-Codesign

• 1000+ tps bei einem 1T-Modell sind nicht das Ergebnis einer einzelnen Technik, sondern das Resultat eines extremen Codesigns des MiMo-Modellteams und des TileRT-Systemteams

• Anders als in der Branche, die für ähnliche Geschwindigkeiten häufig auf Spezialhardware setzt (Cerebras' Wafer-Scale, Groqs kundenspezifische On-Chip-SRAM-Architektur), wurde dies allein durch Modell-System-Codesign auf Commodity-GPUs erreicht

• Auf Modellseite reduziert die auf Bandbreitenengpässe ausgerichtete FP4-Quantisierung Modellgröße und Speicherzugriffslast; gleichzeitig erhöht die Einführung von DFlash auf Basis maskierter Block-Parallelvorhersage die akzeptierte Token-Länge pro Verifikationsschritt

• Auf Systemseite liefert TileRT eine auf diese Algorithmuseigenschaften abgestimmte Compile-Engine und Rechenkerne und realisiert 1000+ tps auf einem einzelnen standardisierten 8-GPU-Commodity-Knoten

• 3.1 FP4 Quantization

  • Bei 1T-Größe verursachen herkömmliche 8-Bit- (FP8/INT8) und 16-Bit-Inferenz zu hohe Speicherbelegung und Bandbreitenbelastung; die Reduktion der Bitbreite trägt direkt zur Decoding-Geschwindigkeit bei
  • Es wurde das validierte, praktisch verlustfreie FP4(MXFP4)-Format übernommen; bei einfacher Anwendung auf das gesamte Modell kommt es jedoch bei komplexer Inferenz, Logik und Codegenerierung zu Leistungseinbußen
  • In der MoE(Mixture of Experts)-Architektur wurden selektiv nur die Experts, die den Großteil der Parameter ausmachen und am widerstandsfähigsten gegenüber Quantisierung sind, auf FP4 quantisiert; andere Module behalten ihre ursprüngliche Präzision
  • Mit FP4 QAT(Quantization-Aware Training) wurden Modellgröße reduziert und die Hardware-Bandbreitennutzung maximiert, während die Gesamtleistung praktisch auf dem Niveau des Originals bleibt

• 3.2 DFlash Speculative Decoding

  • Traditionelles speculative decoding funktioniert so, dass ein kleines Draft-Modell folgende Token vorhersagt und ein großes Modell sie verifiziert; die Qualität des Drafts bestimmt die Akzeptanzrate, doch je stärker der Draft, desto höher die Rechenkosten — ein grundlegendes Spannungsverhältnis
  • DFlash lässt das Draft-Modell in einem einzigen Forward-Pass einen ganzen maskierten Block ausfüllen und entfernt damit die serielle Beschränkung des "autoregressive drafting"
  • Mit dem Muon-Optimierer zweiter Ordnung und Model Self-Distillation wird der Overhead der Draft-Phase bis nahe an das theoretische Minimum komprimiert
    • Das Draft-Modell verwendet nur Sliding Window Attention(SWA), was sich natürlich an das SWA-Design der MiMo-V2-Serie anlehnt und durch die vollständige Entfernung der Prefix-Abhängigkeit den Rechenaufwand pro Vorhersage von proportional zur Kontextlänge auf konstant reduziert
    • Während des Trainings wird das Sampling des Mask-Signals auf GPU-lokale Shards verlagert, sodass eine einzelne Sequenz in einem Schritt Zehntausende unabhängige Trainingssignale erzeugt und gleichzeitig Kommunikations-Overhead zwischen Geräten vermeidet
  • Die Blockgröße wird auf 8 begrenzt, um den Verifikations-Overhead zu senken und die Parallelität zu erhöhen; eine hohe Acceptance Length wird damit unmittelbar in hohen Inferenzdurchsatz umgewandelt
  • Durchschnittliche Acceptance Length je Szenario
    • Coding 6.30 (bei einigen Samples maximal 7.14, also Akzeptanz von 6 bis 7 von 8 Draft-Token)
    • Math / Reasoning 5.56
    • Agent 4.29
  • In allgemeinen Dialogszenarien mit semantisch stärkerer Streuung und höherer Unsicherheit ist die aktuelle Akzeptanzrate noch niedrig, eine fortlaufende Optimierung ist im Gange

• 3.3 TileRT Ultra-Low-Latency-Inferenzkernel / System

  • Bei einer Betriebsfrequenz von 1000 tokens/s wird die Lebensdauer jedes Operators auf den Mikrosekundenbereich komprimiert; die "operator boundaries" traditioneller Inferenzsysteme treten als zentraler Engpass hervor
  • Jedes Starten einer Operatorausführung, jede Hardwaresynchronisation und jeder Hin-und-her-Transfer zum globalen Speicher unterbricht den Ausführungsfluss und erzeugt sichtbare "Execution Gaps"

  • TileRTs paradigmatische Innovation des Ausführungsmodells

    • Persistent Engine Kernel: Der operatorweise Start der Ausführung wird aufgegeben; stattdessen bleibt die gesamte Rechenpipeline dauerhaft auf der GPU resident und im Fluss, um extreme Überlappung (overlap) von Datenbewegung und Berechnung zu erreichen
    • Warp Specialization (Zusammenarbeit heterogener Pipelines): Kommunikation, Datenbewegung und Tensorberechnung werden auf Tile-Ebene physisch feiner zerlegt; das homogene Lock-Step-Modell wird aufgebrochen und die GPU in ein präzise orchestriertes heterogenes Ausführungssystem verwandelt

  • Tiefe Hardware-Software-Integration im Mikrosekundenbereich (Codesign)

    • Die Modellebene übernimmt gemischte FP4-Quantisierung für MoE-Experts und an SWA ausgerichtetes DFlash speculative decoding für eine Architektur mit 1 Billion Parametern; TileRT ist eng mit diesen Algorithmuseigenschaften und der Quantisierungsmethode gekoppelt und stellt eine maßgeschneiderte Compile-Engine sowie Rechenkerne bereit
    • Die beiden Teams lassen den Ausführungsdruck durch gemeinsame Engineering-Trade-offs auf Grundlage der Hardware-Physik sanft innerhalb der Hardwaregrenzen konvergieren
    • TileRT ist ein Systemarchitekturteam mit Fokus auf KI-Infrastruktur der nächsten Generation und Ultra-Low-Latency-Inferenz und erreicht durch Full-Stack-Durchbrüche bei Persistent Kernel, Tile-Pipeline und heterogener Zusammenarbeit extreme Rechenauslastung in komplexen heterogenen Umgebungen

Zusätzliche Demo-Videos

• Demo, die in 10 Sekunden ein Snake-Spiel erstellt
• Demo, die in 1 Minute eine MacOS-Oberfläche nachbildet

Open Source und Ausblick

• Auf HuggingFace wurde der Checkpoint MiMo-V2.5-Pro-FP4-DFlash als Open Source veröffentlicht; enthalten sind FP4-quantisierte Gewichte und DFlash-Modellparameter
• UltraSpeed-Unterstützung für MiMo-V2.5 wird vorbereitet

[GN⁺]

Hacker-News-Kommentare

• Schnelle KI ist wirklich spannend, aber auch ziemlich beunruhigend. Schon jetzt ist Claude bei manchen Aufgaben schneller als ich, aber wir liegen immer noch ungefähr auf demselben Niveau.
  Ich lasse seit einer Stunde einen Prompt zum Aufräumen von PRs laufen, und es sieht so aus, als würde es noch ein paar Stunden dauern. Wenn das fast sofort fertig wäre, kann ich mir kaum vorstellen, wie sich der Workflow ändern würde. Manchmal fange ich wegen lang laufender Prompts an, Multitasking zu machen, und bereue es später. Umgekehrt wäre eine KI, die Dinge, die früher Stunden oder Tage dauerten, in Sekunden oder Minuten erledigt, eine echte Zeitenwende, und ich weiß nicht, wo wir dann landen werden.

  • Ich nutze Deepseek-v4-pro als Hauptmodell, und manchmal ist das ziemlich nervig. Ich gebe ihm eine einfache Fleißaufgabe und denke: „Das lasse ich den Agenten machen und halte erst mal ein Nickerchen“, aber noch bevor ich überhaupt vom Rechner aufstehe, hat es den Code schon komplett geschrieben.
  • Ich habe groq und GPT OSS ausprobiert, und 20B lief mit 1000 TPS, 120B mit 800 TPS, sodass sich die Geschwindigkeit ziemlich magisch anfühlt.
    Die 3000 TPS von Cerebras habe ich noch nicht ausprobiert, aber ich habe eine Demo eines Modells mit 15.000 TPS gesehen, dessen Name mir nicht mehr einfällt. Ob das für die eigentliche Arbeit einen sinnvollen Unterschied macht, weiß ich nicht, aber es ist wirklich erstaunlich zu sehen, wie sich der Bildschirm in einem Augenblick mit Text füllt. Für kleine Prüfungen, etwa einen Diff zu zeigen und zu bestätigen, ob die Änderung der Absicht entspricht, ist das sehr nützlich, und wenn man solche Checks schnell mehrfach machen kann, hilft das dabei, viele konzentrierte Prüfungen ohne Unterbrechung durchzuführen.
  • Wenn die Latenz niedrig genug wird, gibt es keinen Grund mehr für Multitasking. Man kann einfach eine Sache nach der anderen anstoßen und das Ergebnis direkt ansehen, und das ist eigentlich eine ziemlich gute Art zu arbeiten.
    Bei nicht rechenintensiven Aufgaben funktionieren interaktive UIs ohnehin so. Programme warten meistens untätig darauf, dass der Nutzer einen Button drückt. Es gibt keinen Grund, warum wir auf Programme warten oder uns mit mehreren Tellern gleichzeitig abmühen sollten. Allerdings reichen schnellere LLMs allein nicht aus, man braucht auch schnelles Kompilieren und Testen.
  • Der nächste Flaschenhals ist der Compiler, aber den kann man ja auch einfach mit einem LLM modellieren. Er liegt nur in etwa 15 % der Fälle daneben :)
    Ernsthaft: Cerebras mit etwa 2k Tokens/s und extrem niedriger Latenz zu nutzen, fühlt sich an wie ein Blick in die Zukunft. Man baut den Workflow dann neu auf, rund um Aufgaben, die ohne belastende manuelle Prüfung ablaufen können, etwa indem man die Erfolgskriterien explizit festlegt. Auf viele meiner Probleme passt das noch nicht gut, aber ich denke, dass es in diese Richtung gehen wird. Natürlich sind schnelle Modelle meist nicht die Modelle mit der besten Leistung, aber wenn hohe Qualität und nahezu sofortiges Denken zusammenkommen, wäre das ein Gamechanger, auf den wir wirklich nicht vorbereitet sind.
  • Es hat zwei Seiten. Wenn ich Gemini 3.5 Flash etwas machen lasse, liefert es fast sofort ein Ergebnis und funktioniert gut, und diese Geschwindigkeit ist manchmal ein wenig unheimlich.
    Bei anderen Aufgaben schlägt es dann aber auch mal völlig die falsche Richtung ein. Früher konnte man noch dazwischengehen und sagen: „Moment, das ist es nicht.“ Doch bis man den Text auf dem Bildschirm sieht und reagieren kann, hat es schon große Änderungen vorgenommen. Wenn man es nicht nach jeder Bearbeitung committen lässt, ist es schwer zu verhindern, dass es genauso schnell falsch abbiegt, wie es richtig liegt, und bei weitreichenden Berechtigungen kann es auch über Remote-APIs Fehler machen.

• Ich verstehe das Gerede über Produktivität nicht so recht. Aus Sicht normaler Angestellter ist es nicht besonders wichtig, dass etwas, das früher zwei Tage dauerte, jetzt in zwei Stunden erledigt ist. Denn man kann die verbleibende Zeit nicht frei nutzen, sondern muss trotzdem acht Stunden am Tag arbeiten.
  Früher hatte man das Vergnügen, sich zwei Tage lang tief in ein Problem einzuarbeiten und etwas zu bauen. Jetzt verwandelt es sich in ein Spielautomaten-Muster, bei dem man nur noch hofft, dass mit dem richtigen Prompt die richtige Antwort herauskommt. Für uns ist das eher schlechter geworden. Für Unternehmen und Führungskräfte gilt natürlich das genaue Gegenteil, und die werden die ganze KI-Situation großartig finden.

  • Wenn man Aufgaben für die KI in kleine Einheiten zerlegt, kann man die architektonische Kontrolle behalten, und dann ist es kein Spielautomat mehr. Man liest den Code weiterhin und schreibt gelegentlich auch selbst welchen.
    Das mache ich zwar nicht oft, aber es ist der Preis, den man für mehr Geschwindigkeit zahlt. Wenn man der KI eine große Aufgabe hinwirft und eine Stunde später zurückkommt, kann es gut sein, dass man nur eine Stunde verloren hat und am Ende nichts Brauchbares dabei herauskommt.
  • Für mich machen langsame Modelle es schwer, Kontext und parallele Aufgaben zu verwalten. Es ist viel besser, einfach nur eine Aufgabe zu erledigen, fertig zu werden, eine Pause zu machen und dann zur nächsten überzugehen.
    Im Moment lasse ich drei Aufgaben parallel in drei Tabs laufen, und der ständige Kontextwechsel ist viel schmerzhafter. Mit schnelleren Modellen muss man während des Wartens keine neue Aufgabe mehr anfangen.
  • Bei jeder Technologie gibt es eine dumme Art, sie zu nutzen, und eine kluge. Sie wie einen „Spielautomaten für die richtige Antwort“ zu behandeln, ist die dumme Variante. Das kann kurzfristig funktionieren, hält aber nicht lange vor, weil es jeder genauso machen kann.
    Niemand hindert einen daran, diese Technologie zu nutzen, um tiefer als früher in Probleme einzutauchen. Das ist die kluge Nutzungsweise.
  • Ich weiß nicht, aus welcher Welt die Vorstellung stammt, dass Angestellte acht Stunden am Tag arbeiten. Vielleicht stempeln sie acht Stunden, aber sie arbeiten nicht die ganze Zeit wirklich.
  • Unsere Fähigkeit, die Qualität von Ergebnissen zu bewerten, bleibt inzwischen weiter zurück als unsere Fähigkeit, Ergebnisse überhaupt zu erzeugen. Die „richtige Antwort“ ist nicht unbedingt das plausibelste Ergebnis.

• Wenn die Preis- und Geschwindigkeitsoptimierung chinesischer Anbieter mit den Preiserhöhungen der US-Anbieter zusammenkommt, wird sich das Spielfeld wohl schon bald ändern. Viele Unternehmen haben bereits Probleme mit ihren AI-Rechnungen.

  • Chinesische Modelle sind gut genug und günstig.
    Ich nutze ein GitHub-Copilot-Jahresabo, und Microsoft hat die Abrechnung kürzlich auf Token-Basis umgestellt. Noch wird pro Premium-Request abgerechnet, aber GPT 5.4 ist von früher 1x jetzt auf 6x gestiegen.
  • Da ich finanziell nicht besonders gut aufgestellt bin, nutze ich in letzter Zeit statt Claude oder GPT so oft wie möglich DeepSeek v4 Flash, GLM 5.1 usw.
  • Ein weiteres Problem ist, dass die US-Modelle alle Closed Source sind. Wenn man ein großes Unternehmen ist, möchte man vielleicht nicht, dass die eigene Organisation von OpenAI oder Anthropic in Geiselhaft genommen wird.
    Ich verstehe wirklich nicht, welchen Burggraben die US-Modelllabore haben sollen. Wenn rekursive Selbstverbesserung unmittelbar bevorsteht und die chinesischen Labore den führenden US-Modellen nur ein kleines Stück hinterherhinken, worin besteht dann der Burggraben der US-Labore? Darin, dass US-Modelle rekursive Selbstverbesserung besser können als chinesische Open-Source-Modelle? Ich kann völlig falschliegen, aber wenn ich Geld in OpenAI oder Anthropic gesteckt hätte, würde ich es jetzt komplett abziehen wollen. Ich halte es für gut möglich, dass das in den nächsten Jahren fast auf 0 fällt.
  • Das größere Problem ist die Modellkonsistenz. Man weiß nicht, ob Anthropic Opus-Preise verlangt und Requests dann an ein günstigeres Modell weiterleitet.
    Deshalb lassen sich die Kosten der Arbeit nicht vorhersagen. Man muss womöglich mehrfach neu anfangen und jedes Mal zahlen. Außerdem muss man zusätzliche Prompts schicken, um abzuschätzen, ob das Modell echt oder nur ein Ersatz ist, was den Token-Verbrauch weiter erhöht.
  • Ich frage mich, welche ökonomische Struktur solche Preisentscheidungen antreibt. Ich weiß nicht, ob chinesische Firmen ihre Modelle stärker subventionieren als die USA oder ob das an Unterschieden in der Energiepolitik zwischen den Ländern liegt.

• Wenn MiMo so günstig ist wie Deepseek, dann ist es nach der früheren Diskussion https://news.ycombinator.com/item?id=48282814 selbst mit dem 3x-Aufschlag für die extreme Geschwindigkeit immer noch schockierend billig.

  • Nicht MiMo und DeepSeek sind billig, sondern Anthropic und OpenAI sind gemessen am gebotenen Wert teuer.

• Die normale Geschwindigkeitsversion von MiMo V2.5 Pro ist unter den Open-Weights-Agentic-Coding-Modellen, die wir getestet haben, immer noch die stärkste. Interessant, dass sie deutlich weniger Aufmerksamkeit bekommt als Releases mit schwächerer Leistung.
  Auch der Preis für den „fast mode“ ist hier sehr wettbewerbsfähig. Die Daten stehen unter https://gertlabs.com/rankings.

  • Warum liegt deepseek v4 pro so viel niedriger als flash? Wo ist mimo 2.5?

• Das mag nach Werbung klingen, aber es gibt exponentielles Wachstum. Wir werden an einen Punkt kommen, an dem wir fast sofort mehrere Softwareprogramme aus einem Prompt erzeugen und dann das beste davon auswählen.
  Diskussionen darüber, welche Bibliothek den besten Methodennamen mit syntaktischem Zucker hat, werden dann ungefähr so seltsam wirken wie der Vorschlag, Eingaben in Assembler zu schreiben.

  • Klingt nach exponentiellem Wachstum von schlechter Software. Es gab zwar schon früher massenhaft produzierten Müll im Software Engineering, aber jetzt wird er geradezu explodieren.
  • Früher gab es Zeiten, in denen alle drei Monate ein neues Frontend-Framework erschien. Das hat inzwischen fast aufgehört, und niemanden interessiert es mehr.
  • Ich bin mir nicht sicher. Ingenieure können Software immer noch auf die alte Weise bauen. Zum Beispiel etwas wie Obsidian oder Ghostty über Monate hinweg entwickeln und dabei jede einzelne Codezeile, Abhängigkeiten und eine gute Architektur im Blick behalten.
    Das ist die wirklich alte Art, und wenn das Produkt gut ist, wird es erfolgreich sein.
  • Ich sehe das hoffnungsvoller. Wenn AI besser und schneller wird, kann man Code, den man früher wegen des Aufwands gemieden hätte, schneller und iterativer verbessern.
    Tatsächlich habe ich dank AI mehrfach Refactoring in einem Ausmaß gemacht, das sonst absurd gewesen wäre. Nicht nur wegen des Arbeitsaufwands, sondern auch, weil man manchmal nicht einmal weiß, ob es überhaupt funktionieren wird, was zu doppelter Reibung führt. Mit AI kann man ein Refactoring anstoßen, sich einen Kaffee holen und dann sehen, wo es hängen bleibt. Insgesamt wird AI die Menschheit dazu bringen, sich selbst extremer auszuleben – im Guten wie im Schlechten. Ich glaube nur, dass es mehr vom Schlechten geben wird.
  • Der exponentielle Trend wird innerhalb weniger Jahre zu vollständiger In-Memory-Berechnung führen, und das wird 100x effizienter sein. Das heißt, mindestens 10x größere Modelle werden möglich, deutlich intelligenter und zugleich sehr schnell.
    In kleinen Unternehmen wird man Code möglicherweise ganz überspringen und die UI direkt in Konversationsgeschwindigkeit aus Kontextdaten und Prompts rendern. So ähnlich, wie Google Genie es bei Spielen macht, nur viel präziser.

• Das wird bei Sprache wirklich mächtig sein. Durch die Inferenzfähigkeiten werden LLMs viel klüger, aber bei Sprache ist das Latenzbudget so knapp, dass man diese Zeit normalerweise nicht nutzen kann.

• Cerebras testet Kimi K2.6 mit 3000t/s, nur auf Einladung. Ich freue mich auf den Zeitpunkt, an dem schnelle Hardware bei Frontier-Modellen verbreiteter wird.
  Von Nvidia auf Geschwindigkeit ausgelegte Modelle könnten eine gute Ergänzung sein, um diese Lücke zu schließen.

  • Im Original heißt es, dass man bisher spezielle und sehr teure Hardware wie von Cerebras brauchte, um solche Geschwindigkeiten zu erreichen.
    Das Neue an diesem Ergebnis ist, dass mit Standard-Hardware, also nur einem Server mit 8 GPUs, bei einem Modell mit mehr als 1 Billion Parametern die Marke von 1000 token/s überschritten wurde.
  • Mich würde die Quelle interessieren. Auf der Cerebras-Website steht 1000t/s https://www.cerebras.ai/blog/which-is-faster-gemini-3-5-flas...
  • Cerebras hatte Glück, letzten Monat an die Börse gegangen zu sein. Jetzt wäre das anders.
  • Cerebras bietet derzeit keinen Rabatt für Prefix Caching, daher sind die Nutzungskosten bei agentischen Workloads um sqr(n_turns) höher.

• Interessant. Frontier-Modelle sind inzwischen ziemlich beeindruckend geworden, aber für interaktives Human-in-the-Loop-Coding sind sie alle noch etwas zu langsam. Deshalb lenkt das in Richtung Vibe Coding und darauf, mehrere Agenten parallel laufen zu lassen. Ein schneller Agent fühlt sich eher wie ein Partner an.
  Ich habe eine Zeit lang Cerebras GLM 4.7 für verschiedene Aufgaben genutzt. Es ist kein besonders schlaues Modell, aber die Erfahrung, einen Live-Prototypen einer Website offen zu haben und „Mach die Schrift etwas größer. Nein, nicht so viel“ einzugeben und die Änderungen in Echtzeit zu sehen, ist großartig. Und MiMo 2.5 ist deutlich leistungsfähiger als GLM 4.7.

  • Ich habe GLM 4.7 als Code-Schreib-Agent ausprobiert, und selbst bei einfachen Skripten mit 200 bis 1000 Zeilen war es extrem schlecht. Ich musste die von Cerebras angebotenen Modelle aufgeben, und die schlauen Modelle gibt es nur im Enterprise-Plan.
  • MiMo 2.5 ist nicht dasselbe Modell wie MiMo 2.5 Pro.
    GLM 5.1 ist die neueste Iteration von z.ai und eines der beliebten Open-Weights-Coding-Modelle. Falls du es ausprobiert hast, würde mich interessieren, wie sich GLM 5.1 im Vergleich zu MiMo 2.5 Pro schlägt, zumal es nach der jüngsten Preissenkung um 70 % immer noch teurer ist.

• 1k TPS ist ebenfalls großartig, aber noch interessanter ist, wie viele der Kommentare in diesem Thread von KI generiert wurden.