1000-TPS-LLMs: Was schnelle Modelle für Phone Agents ändern

Schnelle Tokens sind noch kein vollständiger Phone Agent

Die praktische Frage lautet nicht, ob ein Modell beeindruckend schnell Text erzeugen kann. Die Frage lautet: Was passiert, wenn ein Phone Agent in einer echten Android-Aufgabe zehnmal denken, prüfen, warten, eine App öffnen, den Nutzer fragen und dann den nächsten Schritt vorbereiten muss? In solchen Abläufen kann jede Sekunde Latenz spürbar werden. Genau deshalb sind 1000-TPS-LLMs für Phone AI Agents ein relevantes Signal.

Trotzdem ist Geschwindigkeit nur ein Teil des Systems. Ein Modell, das sehr schnell antwortet, ist noch kein fertiger Telefonagent. Es kann planen, Optionen vergleichen und Zwischenschritte vorschlagen. Es kann aber nicht allein entscheiden, ob eine SMS gesendet werden darf, ob ein Standort geteilt werden soll oder ob eine App eine bestimmte Aktion unterstützt. Für diese Schritte braucht es Berechtigungen, sichtbare Bestätigung, unterstützte Aktionen und einen sauberen Rückfall.

Ein Beispiel macht den Unterschied klar. Wenn ein Nutzer sagt: „Schick Lisa die Adresse, öffne die Route und erinnere mich 20 Minuten vorher“, muss der Agent nicht nur einen schönen Plan schreiben. Er muss Kontext erkennen, die passende Adresse finden, eine Nachricht vorbereiten, eine Karten-App öffnen, eine Erinnerung vorschlagen und an sensiblen Stellen anhalten. Schnelle Inferenz verkürzt das Denken zwischen diesen Schritten. Sie ersetzt aber nicht die Telefonseite der Aufgabe.

Bei FoneClaw behandeln wir Modellgeschwindigkeit deshalb als vorgelagerte Stärke, nicht als das ganze Produkt. Unser Schwerpunkt liegt auf unterstützten Android-Telefonaktionen. Wer den breiteren technischen Hintergrund zur Ausführung auf dem Telefon sucht, findet ihn in unserem Artikel zum Android Phone Agent. Diese Seite bleibt beim engeren Punkt: Warum Geschwindigkeit wichtig wird, aber nicht ausreicht.

Was MiMo UltraSpeed als Marktsignal zeigt

Das konkrete Signal kommt von Xiaomi. Die offizielle MiMo-Seite von Xiaomi beschreibt MiMo-V2.5-Pro-UltraSpeed als UltraSpeed-Erfahrungsmodus von MiMo-V2.5-Pro, einem 1T-Flaggschiffmodell. Laut Xiaomi soll die höchste Inferenzgeschwindigkeit 1000 Tokens pro Sekunde überschreiten. Außerdem nennt Xiaomi Text-Eingabe und -Ausgabe, Tool Calling, Streaming, Cache-Unterstützung und eine ausgegebene Geschwindigkeit im Bereich von etwa 500 bis 1000 TPS gegenüber 50 bis 100 TPS für MiMo-V2.5-Pro.

Diese Angaben sind wichtig, aber sie müssen sauber eingeordnet werden. Es sind offizielle Xiaomi-Angaben, verifiziert als Planungsquelle am 15. Juli 2026, keine unabhängige Benchmark-Bestätigung durch FoneClaw. Wir behaupten nicht, dass FoneClaw MiMo nutzt. Wir behaupten auch nicht, dass jeder Phone Agent diese Geschwindigkeit erreicht oder dass ein einzelner Zahlenwert die Qualität eines Agenten beweist.

Interessant ist, welche Szenarien Xiaomi mit hoher Geschwindigkeit verbindet: quantitative Trading-Abläufe, Echtzeit-Risikokontrolle, wissenschaftliche Forschung und Echtzeit-Coding-Hilfe. Das sind Aufgaben, bei denen Wartezeit, Zwischenschritte und schnelle Rückkopplung zählen. Für Phone Agents ist die Parallele nicht der konkrete Markt, sondern das Prinzip: Wenn ein Agent oft planen, prüfen und neu planen muss, verändert niedrigere Latenz das Nutzungserlebnis.

Wer Modellfamilien und Fähigkeiten breiter einordnen möchte, kann unseren separaten Leitfaden zu MiMo V2.5 Pro UltraSpeed und anderen agentischen Modelltrends lesen. Hier nutzen wir MiMo UltraSpeed nur als Signal für eine engere Frage: Was macht schnelle Inferenz mit mehrstufigen Telefonaufgaben?

Warum Latenz bei langen Telefonaufgaben zählt

In einem einfachen Chat ist Latenz vor allem Komfort. Eine Antwort kommt schneller, der Nutzer wartet weniger. In einem Phone-Agent-Ablauf wird Latenz jedoch zur Strukturfrage. Lange Aufgaben bestehen selten aus einem einzigen Modellaufruf. Sie bestehen aus mehreren Schleifen: Ziel verstehen, Kontext prüfen, Aktion vorbereiten, Ergebnis anzeigen, Nutzerbestätigung einholen, nächsten Schritt wählen und bei Fehlern zurückfallen.

Stellen Sie sich Benachrichtigungsaufarbeitung vor. Der Agent soll wichtige Nachrichten erkennen, unwichtige gruppieren, eine Antwort vorbereiten, Termine aus dem Kontext ableiten und den Nutzer nur bei relevanten Entscheidungen stören. Wenn jede Prüfung langsam ist, fühlt sich der gesamte Ablauf zäh an. Wenn die Denkschritte schnell sind, kann der Agent häufiger kleine Kontrollen ausführen, ohne die Bedienung zu blockieren.

Ähnlich ist es bei Kalender- und Routenplanung. Eine Aufgabe kann aus mehreren kleinen Abhängigkeiten bestehen: Treffpunkt erkennen, Fahrtzeit schätzen, Puffer einbauen, Erinnerung setzen, Nachricht vorbereiten. Ein schnelleres Modell kann diese Zwischenschritte enger miteinander verbinden. Der Nutzer erlebt weniger Leerlauf und kann früher prüfen, ob der vorgeschlagene Plan stimmt.

Aber auch hier gilt: Geschwindigkeit verbessert nicht automatisch Richtigkeit. Ein schneller Fehler bleibt ein Fehler. Wenn der Agent die falsche Adresse erkennt, eine App-Grenze übersieht oder eine Berechtigung nicht hat, hilft hohe TPS nur begrenzt. Daher ist Latenz ein Verstärker. Sie verstärkt gute Planung, gute Rückfragen und gute Kontrollpunkte. Sie verstärkt aber auch schlechte Annahmen, wenn die Ausführungsschicht nicht sauber gestaltet ist.

Schnelles Modell, tieferes Modell: ein nützliches Agentenmuster

Für Phone Agents ist nicht nur die Maximalgeschwindigkeit eines Modells interessant. Ebenso wichtig ist die Architektur des Ablaufs. Ein nützliches Muster ist die Aufteilung zwischen schnellen Prüfungen und tieferer Entscheidung. Ein leichtes, schnelles Modell kann einfache Klassifikationen, Formulierungen oder Kontextchecks übernehmen. Ein stärkeres Modell kann schwierige Entscheidungen, mehrdeutige Ziele oder riskante Zwischenschritte prüfen.

Dieses Muster ist besonders relevant für Echtzeitgespräche. Wenn ein Nutzer während einer Aufgabe nachfragt, korrigiert oder neue Informationen gibt, darf der Agent nicht jedes Mal lange pausieren. Schnelle Teilantworten halten den Fluss lebendig. Bei wichtigen Entscheidungen sollte der Agent trotzdem nicht übereilt handeln. Dann ist ein tieferer Prüfschritt sinnvoll, auch wenn er länger dauert.

Man kann sich das wie eine gute Assistenz vorstellen. Nicht jede Frage braucht dieselbe Tiefe. „Ist das wahrscheinlich eine Adresse?“ kann schnell beantwortet werden. „Soll ich diese Nachricht jetzt senden oder erst eine Rückfrage stellen?“ braucht mehr Kontext und Vorsicht. Eine gute Agentenarchitektur erkennt diesen Unterschied, statt jeden Schritt mit derselben Modellschwere zu behandeln.

Wichtig ist: Diese schnelle/langsame Aufteilung ist hier ein konzeptionelles Muster, keine Aussage über eine geheime FoneClaw-Implementierung. Wir nennen keine internen Architekturdetails und keine nicht belegten Modellzahlen. Der Punkt ist praktischer: Rohe TPS-Zahlen sagen weniger aus als die Frage, wie ein Produkt schnelle Prüfungen, tiefere Entscheidungen und sichtbare Nutzerkontrolle kombiniert.

Warum Telefonaktionen weiterhin eine verlässliche Ausführung brauchen

Der zentrale Unterschied bleibt: Denken ist nicht Ausführen. Ein Modell kann sehr schnell beschreiben, was zu tun wäre. Eine Telefonaktion muss trotzdem auf einem Gerät stattfinden, in einer App, mit einer Berechtigung, unter einer Nutzerentscheidung. Wer diesen Unterschied übersieht, verwechselt Modellinferenz mit einem vollständigen Phone-Agent-Produkt.

Bei Android-Telefonaktionen gibt es mehrere harte Grenzen. Eine App kann eine Übergabe unterstützen oder nicht. Eine Berechtigung kann erteilt oder verweigert sein. Ein Bildschirm kann sich nach einem Update ändern. Ein sensibler Schritt kann eine Bestätigung brauchen. Ein Agent, der diese Grenzen nicht sichtbar macht, wird durch schnelle Inferenz nicht sicherer. Er wird nur schneller unklar.

Darum braucht ein Phone Agent eine zuverlässige Ausführungsebene: unterstützte Aktionen, erkennbare Zwischenergebnisse, Nutzerbestätigung, Fehlerbehandlung und Rückfall. Eine Nachricht darf nicht nur schnell formuliert werden; Empfänger und Inhalt müssen sichtbar sein. Eine Navigation darf nicht nur berechnet werden; Ziel und App-Übergabe müssen stimmen. Eine Erinnerung darf nicht nur vorgeschlagen werden; Zeitpunkt und Kontext müssen überprüfbar bleiben.

Die Rolle des Telefons als Ort für echte Telefonaktionen erklären wir an anderer Stelle breiter. Hier genügt die Folgerung: Schnellere Modelle machen die vorgelagerte Denkarbeit flüssiger. Sie ersetzen nicht die Geräteseite, die App-Grenzen oder die Verantwortung des Nutzers.

Unsere FoneClaw-Lektion aus dem 1000-TPS-Signal

Bei FoneClaw sehen wir 1000-TPS-Signale wie MiMo UltraSpeed als Hinweis auf die Richtung der Branche. Modelle werden schneller, Rückkopplung wird enger, und mehrstufige Aufgaben können sich natürlicher anfühlen. Das ist für Phone Agents wichtig, weil Telefonaufgaben selten nur aus einer Antwort bestehen. Sie bestehen aus kleinen Entscheidungen und sichtbaren Schritten.

Für FoneClaw ist das inzwischen auch praktische Produktarbeit. FoneClaw hat internen Testzugang zu MiMo V2.5 Pro UltraSpeed erhalten und nutzt dieses 1T-Modell, für das Xiaomi eine Spitzengeschwindigkeit von über 1000 TPS angibt, um die FoneClaw-Erfahrung zu verbessern. Bei Phone-Agent-Workflows zählt nicht die abstrakte Zahl, sondern schnelleres Verstehen, schnellere Korrektur und reaktionsschnellere Ausführung unterstützter Telefonaktionen.

Unsere Produktlektion ist trotzdem klar begrenzt. Wir behaupten nicht, MiMo zu nutzen. Wir behaupten nicht, dass FoneClaw 1000 TPS erreicht. Wir behaupten nicht, dass Geschwindigkeit jede App-Grenze oder jedes Berechtigungsproblem löst. Unser Ansatz ist ein anderer: Wir nehmen schnellere Modelle als stärkere Denkschicht ernst, während wir FoneClaw um unterstützte Android-Aktionen herum gestalten.

Das bedeutet für uns: Ein Agent soll ein Ziel schneller verstehen, aber auch besser anhalten können. Er soll einen nächsten Schritt schneller vorbereiten, aber das Ergebnis sichtbar machen. Er soll Rückfragen flüssiger stellen, aber nicht über Nutzerfreigaben springen. Schnelle Inferenz ist wertvoll, wenn sie in einen kontrollierbaren Ablauf eingebettet ist.

Für Android-Nutzer ist die praktische Schlussfolgerung einfach. Wenn ein Modell sehr schnell ist, kann sich ein Phone Agent reaktionsfähiger anfühlen. Aber die entscheidende Frage bleibt: Wird aus der Absicht eine unterstützte, sichtbare und erlaubte Telefonaktion? Bei FoneClaw bauen wir genau an dieser Brücke. Schnellere Modelle helfen upstream; unser Produktwert entsteht dort, wo ein Android-Schritt zuverlässig, prüfbar und mit klaren Grenzen ausgeführt wird.