1. AugustDer 9. Meet AI Compiler Technical Salon, veranstaltet von HyperAI, wurde erfolgreich in Zhongguancun, Peking, abgeschlossen.Der Salon erfreute sich nach wie vor großer Beliebtheit und bot Branchenexperten spannende Vorträge. Technische Führungskräfte führender Unternehmen und Forschungseinrichtungen wie der Beijing Academy of Artificial Intelligence, dem TileRT-Team, Tencent, Huawei Ascend und Zhiyuan Innovation kamen zusammen, um tiefgreifende Einblicke in Spitzentechnologien, zugrundeliegende Optimierungen, Open-Source-Ökosysteme und Anwendungsszenarien im Bereich der KI-Kompilation zu geben. Entwickler und Fachleute erlebten ein reichhaltiges und informatives technisches Programm.

vor OrtMa Lingxiao, ein Kernmitglied des TileRT-Teams, hielt einen ausführlichen Vortrag über die neuesten Entwicklungen von TileRT mit dem Titel „Geschwindigkeit ist Intelligenz: Computergestützte Exploration und kollaboratives Design für die Inferenz großer Modelle mit extrem niedriger Latenz“.Von der Entwicklung von KI-Compilern und Laufzeitarchitekturen bis hin zum gemeinsamen Entwurf von Modellen und Systemen sowie den Integrationsergebnissen und praktischen Anwendungsfällen mit vielen führenden Unternehmen und Technologie-Communities wie Z.AI, Xiaomi MIMO und vLLM beschreibt die Präsentation detailliert den Software-Stack für das Rechnen großer Modelle mit extrem niedriger Latenz.

HyperAI hat die Rede zusammengestellt und zusammengefasst, ohne ihren ursprünglichen Sinn zu verändern. Im Folgenden finden Sie das Transkript der Rede.

Die Geschwindigkeit der Inferenz hat sich in anspruchsvollen KI-Szenarien zu einem zentralen Wettbewerbsvorteil entwickelt.

ChatGPT entstand Ende 2022 und Anfang 2023 und demonstrierte erstaunliche Fähigkeiten. Rückblickend zeigten die frühen Modelle jedoch vor allem Anwendungen in Bereichen wie Chatten und virtueller Kommunikation, wobei ihr tatsächlicher Nutzen weit unter ihrem Rechenaufwand lag. Die Ausgabe großer Modelle musste lediglich mit der menschlichen Lesegeschwindigkeit mithalten. Damals lag der Fokus auf dem Gesamtdurchsatz des Systems, nicht auf der Ausgabegeschwindigkeit des Modells.

Seit Ende 2025 hat die Entwicklung von Codierungsagenten wie Claude Code in weniger als einem Jahr weitere Potenziale groß angelegter Modelle aufgezeigt, beispielsweise die Möglichkeit, die Produktivität von Nutzern deutlich zu steigern. Im Vergleich zu den Kosten der Rechenleistung hat sich in diesem Fall ein höherer praktischer Nutzen ergeben. DaherIn letzter Zeit haben wir einen sprunghaften Anstieg der Nachfrage nach Rechenleistung erlebt, was ein direktes Spiegelbild des Bedarfs an hohem Durchsatz ist.

Mit Blick auf diese Entwicklung und die damit einhergehende Steigerung der Modellleistung werden Modelle zwangsläufig in immer mehr automatisierte Aufgaben eingebunden, beispielsweise in KI-Fabriken, bei quantitativen Entscheidungsprozessen und in Echtzeit-Risikomanagementprojekten. In diesem Szenario wird das Modell selbst zum Ergebnis des Modells und schafft so einen KI-automatisierten Workflow.Je schneller das Modell läuft, desto höher ist seine Effizienz. Die maximale Modellgeschwindigkeit wird zu einem entscheidenden Faktor für Produktivität und Benutzererfahrung.

Die neuesten Branchennachrichten bestätigen die obigen Spekulationen eine nach der anderen:

* Ende 2025 erwarb Nvidia Grop für eine enorme Summe, um seine Hochgeschwindigkeits-Inferenzfähigkeiten auszubauen;

* Im Februar 2026 brachte Anthropic Claude Fast auf den Markt, eine Hochgeschwindigkeitsversion der Technologie.

* Im selben Monat brachte OpenAI in Zusammenarbeit mit Cerebras GPT-Codex-Spark auf den Markt;

* Im Mai gab Cerebras bekannt, dass es durch Wafer-Level-Chip-Technologie eine Inferenzgeschwindigkeit von fast 1.000 TPS für ein 1T-Level-Modell erreicht hat.

* Darüber hinaus ging OpenAI erst vor zwei oder drei Wochen eine Partnerschaft mit Cerebras ein, um seinem fortschrittlichsten Flaggschiffmodell GPT-5.6-Sol die Möglichkeit zu geben, einen Hochgeschwindigkeits-Inferenzdienst mit 750 TPS anzubieten.

Die Skalierung der Testzeit (TTS) ist tatsächlich der wichtigste Weg zur Verbesserung der Modellleistung.Bei einem gegebenen Zeitfenster von beispielsweise 10 Sekunden kann ein langsamerer Modellinferenzdienst mit 50 Tokens/s lediglich 500 Gedankenpunkte generieren. Wird die Inferenzgeschwindigkeit jedoch von 50 auf 1000 Tokens erhöht, generiert er 10.000 Gedankenpunkte. Innerhalb desselben Zeitfensters führt eine schnellere Inferenz zweifellos zu einer höheren Modellintelligenz.

Sie fragen sich vielleicht: Es gibt viele Möglichkeiten, TTS zu implementieren, beispielsweise Best-of-N, das mit reiner Stapelverarbeitung eine höhere Intelligenz erzielen kann – warum also Geschwindigkeit priorisieren? Dies erfordert eine Aufteilung von TTS.Betrachtet man es sowohl hinsichtlich der Tiefe als auch der Breite,Während TTS-Aufgaben (Text-to-Speech) ihre Ziele durch Stapelverarbeitung erreichen können, arbeitet dieses Modell aus der Perspektive einer langen Gedankenkette oder einer Reihe von Agentenausführungsschritten seriell. Dies ist mit Stapelverarbeitung nicht möglich, und die Tiefe der seriellen Verarbeitung lässt sich nur durch extrem hohe Inferenzgeschwindigkeit erzielen.

Betrachten wir ein Beispiel aus einer SWE-Bench-Trajektorie, genauer gesagt aus den Statistiken der SWE-Smith-Trajektorie. Die tatsächliche Ausführungstrajektorie zeigt, dass im Durchschnitt etwa 30 Modellausführungsschritte durchgeführt werden, wodurch 10.000 Token generiert werden. Bei einer Geschwindigkeit von 50 Token/s würde dies etwa 200 Sekunden oder über 3 Minuten dauern. Wird die Modellgeschwindigkeit jedoch auf 1000 Token/s erhöht, kann die Aufgabe in nur 10 Sekunden abgeschlossen werden. Dies bietet ein völlig anderes Nutzungserlebnis.Bei normaler Geschwindigkeit könnten die Wartezeiten die Nutzer stören, aber wenn der Vorgang nur wenige Sekunden dauert, erleben sie einen vollständig interaktiven Echtzeitprozess.

Betrachten wir darüber hinaus weitere Szenarien. Beispielsweise erfordert der quantitative Hochfrequenzhandel üblicherweise Feedback im Bereich von etwa 10 Millisekunden, Echtzeit-Sprachanrufe können Feedback im Bereich von Hunderten von Millisekunden erfordern, und auch das Finanzrisikomanagement kann Feedback im Sekundenbereich benötigen. Daher liegt die Feedbackzeit in diesen Echtzeit-Interaktionsszenarien im Wesentlichen zwischen wenigen Sekunden und 10 Sekunden. Können diese Zeitvorgaben nicht eingehalten werden, ist das Modell in diesen Szenarien nicht praktikabel.

Deshalb werden wir die Denkgeschwindigkeit bis an ihre Grenzen ausreizen.Einerseits hoffen wir, mehr Anwendungsszenarien zu ermöglichen; andererseits hoffen wir auch, die Generierung leistungsfähigerer Modellintelligenz zu fördern.

Maximale Geschwindigkeit wird durch den kollaborativen Ansatz von Algorithmen, Systemen und Hardware erreicht.

Wie lässt sich also die Dekodierungsgeschwindigkeit eines Modells maximieren? Dies wird tatsächlich von drei Faktoren bestimmt.Das erste ist die Leistungsfähigkeit der Hardware selbst.Unter Einbeziehung von Rechenleistung, Bandbreite und Vernetzung bestimmt sie die Obergrenze der Dekodierungsgeschwindigkeit;Der zweite Faktor ist die Effizienz des Softwaresystems.Mit anderen Worten: Wie lässt sich die Leistung der Hardware maximieren?Drittens der Algorithmus.Beispielsweise können durch Reduzierung des Rechenaufwands und des Speicherzugriffs mittels Quantisierung oder durch Verwendung von Methoden wie spekulativer Dekodierung mehr Token aus einer einzigen Vorwärtsberechnung generiert werden.

Betrachten wir zunächst die Systemeffizienz.Ausgehend von grundlegenden Prinzipien besteht weiterhin eine erhebliche Diskrepanz zwischen der tatsächlichen Geschwindigkeit der Modellinferenz und der theoretischen Obergrenze der Hardware. Dies liegt daran, dass neben der eigentlichen Berechnung während der Ausführung fixe Overheads anfallen, wie beispielsweise Kernel-Start, Scheduling, Synchronisierung und Kommunikation. Mit der stetigen Verbesserung der Hardwareleistung gewinnen diese Overheads zunehmend an Bedeutung und entwickeln sich allmählich zu zentralen Engpässen für latenzarme Inferenz.

Es existieren bereits zahlreiche Technologien zur Reduzierung dieser fixen Overheads, wie beispielsweise CUDA Graph und PDL. CUDA Graph reduziert hauptsächlich den Overhead beim Kernelstart, während PDL es zwei Kerneln ermöglicht, Abhängigkeiten und Pipelines im Voraus festzulegen, jedoch im Wesentlichen nur eine minimale Überlappung um einen Hop ermöglicht. Für optimale Leistung ist dies bei Weitem nicht ausreichend. Um die durch den Kernel selbst definierten Ausführungsgrenzen aufzubrechen und die Granularität der Scheduling-Prozesse weiter zu dezentralisieren, müssen wir die Ausführungsgrenzen aufbrechen.Dadurch können Berechnungen, Speicherzugriffe und Kommunikation, die ursprünglich durch verschiedene Kernel getrennt waren, stärker miteinander verzahnt werden.

Kernelfusion ist tatsächlich kein neues Konzept; seit der Ära der tiefen neuronalen Netze (DNN) wurde viel Forschung auf diesem Gebiet betrieben. Wir haben bereits eine Reihe von Untersuchungen zu Themen wie Cross-Operator-Scheduling, Kernelgenerierung, Speicherzugriff, dynamischem Kontrollfluss, Berechnungen mit geringer Präzision und Software-Pipelining durchgeführt, darunter Rammer, Roller, Welder, Cocktailer, Ladder und PipeThreader.Nach und nach wurde eine Kompilierungsfähigkeit entwickelt, die von der Optimierung auf Graphebene bis zur feingranularen Ausführung auf Kachelebene reicht.Es wurde in verschiedenen Hardware- und realen Anwendungsszenarien validiert.

Diese Fähigkeiten lassen sich jedoch nicht direkt auf die Inferenz großer Modelle übertragen.Im Vergleich zu traditionellen DNNs bringt die LLM-Ära drei neue Herausforderungen mit sich:Verbesserte Hardwareleistung lässt fixe Overhead-Kosten wie Scheduling und Kommunikation stärker in den Vordergrund rücken; MoE-Routing, spärliche Berechnungen und spekulative Dekodierungsmechanismen erhöhen die Laufzeitdynamik; und die Vergrößerung der Modellgröße macht die karten- und maschinenübergreifende Zusammenarbeit häufiger. Daher müssen LLM-orientierte Kompilierungssysteme feingranulare Ausführung, dynamisches Scheduling und verteilte Zusammenarbeit gleichzeitig bewältigen.

Angesichts dieser HerausforderungenDie Kernidee von TileRT besteht darin, den Kernel nicht länger als die grundlegende Grenze der Softwareplanung zu betrachten, sondern diese Grenze weiter aufzubrechen, die Ausführung feiner zu zerlegen und Berechnung, Speicherzugriff und Kommunikation aus einer globalen Perspektive neu zu orchestrieren.

Betrachten wir zunächst den Ablaufplanungsprozess des bestehenden Frameworks. Bei großen Modellen wird dieser üblicherweise als Berechnungsdiagramm dargestellt und anschließend operations- und kernelweise auf der Hardware ausgeführt. Jeder Kernel verfügt über eigene Start-, Berechnungs- und Synchronisierungsprozesse, und die Kernelgrenzen begrenzen zudem den Spielraum für weitere Überlappungen zwischen verschiedenen Phasen.

TileRT zielt genau darauf ab, diese Grenze aufzulösen. Durch die weitere Aufteilung von Berechnungen innerhalb des Kernels in feinere, kachelartige Aufgaben kann die Software die Ausführungsreihenfolge über bestehende Kernelgrenzen hinweg neu anordnen. Dadurch können nachfolgende Berechnungen, Speicherzugriffe und Kommunikationsvorgänge, die bereits Abhängigkeiten erfüllen, früher beginnen, wodurch eine effizientere Pipeline entsteht. Im Wesentlichen werden nicht einfach mehrere Kernel zu einem größeren Kernel zusammengeführt, sondern die Beschränkungen des Kernels hinsichtlich des Planungsraums aufgehoben, wodurch eine bisher unmögliche Überlappung erreicht wird.

TileRT nutzt Fallstudien aus der Praxis, um die Machbarkeit seiner Technologie zu validieren.

TileRT stellt das Modell zunächst als Datenflussgraph dar und generiert anschließend einen Mikrokernel auf Kachelebene. Daraufhin erfolgt eine detaillierte Kompilierung und Planung, um die Ausführungs-Engine zu erzeugen. Diese Engine orchestriert Berechnungen, Speicherzugriffe und Kommunikation und ordnet Aufgaben verschiedenen Hardwareeinheiten zu, um die Geräteleistung optimal zu nutzen.

Mithilfe dieser Methodik wurde TileRT bereits in realen Produktionsumgebungen validiert. Im Mai dieses Jahres haben wir gemeinsam mit dem Zhipu GLM-Team den Hochgeschwindigkeits-Inferenzdienst GLM-5.1-HighSpeed eingeführt.Es erreichte eine produktionsreife Ausgabegeschwindigkeit von 400 Token/s.Eine beispielhafte Optimierung ist die Sparse Attention für GLM-5.1. Traditionelle Tensor-Parallelen lassen typischerweise verschiedene GPUs dieselbe Berechnungslogik ausführen, während TileRT diese auf verschiedene heterogene Worker aufteilt: Eine GPU übernimmt den Sparse Indexer, die Top-K-Auswahl und das Routing, während die anderen sieben GPUs rechenintensive Aufgaben wie MLA und Attention bearbeiten. Kommunikation, Reduktion und Synchronisierung sind zudem in die Tile-Level-Pipeline integriert. Dadurch können verschiedene Stufen Skalierungsmethoden anwenden, die besser zu ihren spezifischen Eigenschaften passen, wodurch redundante Berechnungen und Synchronisierungswartezeiten reduziert werden. Ohne MTP beträgt die Generierungsgeschwindigkeit für kurze Sequenzen etwa 300 Token/s und für lange Sequenzen etwa 200 Token/s. Mit aktiviertem MTP-3 und einer durchschnittlichen Empfangslänge von 3,2 können kurze Sequenzen 600 Token/s und lange Sequenzen etwa 400 Token/s erreichen.

Wenn wir noch höhere Geschwindigkeiten erreichen wollen, müssen wir auch die Ausgabeeffizienz jedes einzelnen Token-Bytes optimieren.Um die Token-Ausgabe pro Byte zu optimieren, sind zwei Aspekte zu berücksichtigen:Einerseits möchten wir mehr Token pro Schritt generieren, daher können wir MTP oder aggressivere spekulative Dekodierungsverfahren wie DFlash oder DSpark verwenden; andererseits können wir die pro Token benötigte Datenmenge reduzieren, indem wir Quantisierungsmethoden einsetzen, um die Datenmenge zu verringern.

Im Juni haben wir in Zusammenarbeit mit dem Xiaomi MiMo-Team das Modell und das System auf Basis dieser Idee entwickelt.Hinsichtlich der Quantisierung stellt das MoE-Expertenmodul von MiMo-V2.5-Pro den Großteil der Modellparameter dar. Daher wird nur das Expertenmodul mit FP4 QAT quantisiert, während die anderen Module ihre ursprüngliche Genauigkeit beibehalten. Benchmarks zeigen, dass die Gesamtleistung des quantisierten Modells nahezu der des ursprünglichen FP8-Modells entspricht, gleichzeitig aber die Modellgröße und der Speicherzugriffsdruck deutlich reduziert werden. Für die spekulative Dekodierung verwendet DFlash parallele Prädiktion auf Blockebene. Dabei wird in jedem Vorwärtsdurchlauf eine Menge von Kandidaten-Token generiert, die anschließend vom Hauptmodell einheitlich verifiziert werden. Dies reduziert den seriellen Overhead herkömmlicher autoregressiver Entwurfsverfahren.

Diese Modelle werden zur kollaborativen Optimierung mit dem System verwendet.MiMo-V2.5-Pro-UltraSpeed erreichte schließlich eine Generierungsgeschwindigkeit von über 1000 Token/s für 1T-Modelle auf einem einzigen Allzweck-8-GPU-Knoten.Noch wichtiger ist, dass dieses Ergebnis nicht auf Wafer-Level- oder anderen dedizierten Inferenzchips beruhte. Es zeigt, dass Allzweck-GPUs durch eine ausreichende Zusammenarbeit von Modell und System sogar den extremen Inferenzgeschwindigkeitsbereich übertreffen können, der bisher nur mit dedizierter Hardware erreichbar war. Dieses Ergebnis verdeutlicht, dass weitere Geschwindigkeitsverbesserungen nicht mehr allein von der Inferenz-Engine selbst abhängen, wenn sich die Systemleistung den Hardwaregrenzen annähert. Sie erfordern die gemeinsame Weiterentwicklung von Modellstruktur, Kompilierungssystem und Hardware-Ausführungsmethoden.

Natürlich reicht es nicht aus, lediglich auf extrem hohe Dekodierungsgeschwindigkeiten zu setzen. Ein wirklich nutzbarer Dienst für groß angelegte Modelle benötigt außerdem OpenAI-kompatible APIs, Anforderungsplanung, Präfix-Caching, Tool-Aufrufe und ausgereifte Betriebsfunktionen. Müsste das gesamte Dienstsystem nur zur Integration einer Hochgeschwindigkeits-Dekodierungs-Engine neu entwickelt werden, wären die Entwicklungskosten unerschwinglich. DaherWir haben mit der vLLM-Community zusammengearbeitet, um TileRT zu ermöglichen, sich auf die Dekodierung mit niedriger Latenz zu konzentrieren und gleichzeitig das ausgereifte vLLM-Ökosystem wiederzuverwenden.

Die Trennung von Prefill und Decode bildet eine solide Grundlage für diese Kombination. Durch die Entkopplung von Prefill und Decode kann die Decode-Seite als austauschbare Ausführungs-Engine fungieren. In der gemeinsamen TileRT- und vLLM-Lösung werden Prefill, Anforderungsplanung, Chunked Prefill, Präfix-Cache und Service-APIs weiterhin von nativem vLLM bereitgestellt. Nur Anfragen mit hohen Anforderungen an die Generierungsgeschwindigkeit für Einzelbenutzer gelangen in den TileRT-Decodierungspool. Dies erhält die vollen Ökosystemfunktionen von vLLM und nutzt gleichzeitig die extrem niedrige Latenz der TileRT-Decodierungsleistung.

In seiner Implementierung verbindet sich TileRT vollständig über die bereitgestellte Connector-Schnittstelle von vLLM, ohne dass Änderungen oder ein Fork von vLLM oder Eingriffe in dessen interne Worker erforderlich sind. Die Routing-Schicht kennzeichnet latenzkritische Anfragen, und der TileRT Connector akzeptiert ausschließlich diese; alle anderen Anfragen folgen weiterhin dem nativen vLLM-Verarbeitungspfad. Die beiden Dekodierungspools können denselben vLLM-Prefill-Dienst nutzen. Der von Prefill generierte Zustand wird über Transport-Engines wie NIXL oder Mooncake an den entsprechenden Dekodierungsknoten übergeben und parallel zu nachfolgenden Prefill-Prozessen ausgeführt.

Daher können innerhalb derselben Bereitstellung latenzkritische Anfragen wie Echtzeitagenten und interaktive Codierung an TileRT weitergeleitet werden; reguläre Anfragen, die auf hohe Parallelität und hohen Gesamtdurchsatz abzielen, werden weiterhin von der nativen Dekodierungs-Engine von vLLM verarbeitet. Beide Wege bieten dieselbe OpenAI-kompatible API, und der Wechsel zwischen den Diensten erfordert lediglich eine Anpassung der Routing-Strategie.Dies ermöglicht es TileRT und vLLM, eine wirklich koexistierende heterogene Inferenzdienstarchitektur zu bilden, in der jedes System seine Stärken nutzt.

Das TileRT-Ökosystem wächst stetig.

Aktuell unterstützt TileRT mehrere Modelle und verschiedene Ökosystem-Implementierungen:

Ende letzten Jahres haben wir den Prototyp-Adapter für DeepSeek v3.2 veröffentlicht, der eine Inferenzgeschwindigkeit von 500 TPS erreichen kann.

Im Mai dieses Jahres haben wir gemeinsam mit Zhipu eine Hochgeschwindigkeitsversion von GLM-5.1 auf den Markt gebracht, die Inferenzdienste von 400 bis 600 TPS erreicht;

Im Juni dieses Jahres haben wir in Zusammenarbeit mit Xiaomi MIMO erstmals einen Durchbruch von 1000 TPS für ein 1T-Modell erzielt und damit den globalen Rekord für die Inferenzgeschwindigkeit gebrochen;

Anschließend haben wir eine Partnerschaft mit MIND LAB geschlossen, um die erste Plattform zu veröffentlichen, die Hochgeschwindigkeits-Multi-LoRa-Inferenz unterstützt und die Echtzeit-UI-Produktion innerhalb von 5 Sekunden ermöglicht;

Schließlich haben wir in Zusammenarbeit mit der vLLM-Community eine Lösung für die Koexistenz heterogener PD-Separate-Deployments veröffentlicht, die keinerlei Modifikationen erfordert und die Kompatibilität mit dem Ökosystem unterstützt.

Abschließend noch die neuesten Entwicklungen in der Tile-AI-Community. Die Tile-AI-Community ist ein von uns auf Tile basierendes Software-Ökosystem, das speziell für große Modelle und neue Hardwarearchitekturen, einschließlich des bekannten TileLang, neu gestaltet wurde. TileScale ist ein Programmier- und Kompilierungsframework, das für verteilte Architekturen, einschließlich In-Band-Architekturen mit verteiltem Kern, entwickelt wurde.Dies umfasst auch Verbindungen zwischen einzelnen Chips, zwischen Chips und zwischen mehreren Maschinen. Wir haben diese mehrschichtige, verteilte Struktur in der Beschreibung von Tile vereinheitlicht und abstrahiert und ein entsprechendes Framework entwickelt. TileRT ist die Inferenz-Engine für die oben beschriebenen extremen Geschwindigkeiten.

Darüber hinaus haben wir kürzlich TileFoundry und TileOPs veröffentlicht. TileFoundry ist ein KI-gestütztes Framework zur automatischen Generierung von Operatoren. Dessen Ergebnis ist TileOPs – eine TileLang-Operatorbibliothek für große Modelle. Gleichzeitig stehen wir kurz vor der Veröffentlichung des Leistungsanalysemodells TileSight, das primär für die Leistungsmodellierung auf Kachelebene entwickelt wurde und Hilfestellung für die Leistungsoptimierung von Programmen auf Kachelebene sowie für die Architekturanalyse bietet.