First-Token-Latenz um 32.4% gesenkt! Shishi Technology setzt mit Cluster-Scheduling einen großen Hebel an, domestizierte Inferenz wird…

Yunzhong von Ou Feisi, QbitAI | Öffentlicher WeChat-Account QbitAI

In GPU-Clustern können Request-Warteschlangen und ungenutzte Ressourcen gleichzeitig auftreten.

Anlässlich der CCF National High Performance Computing Konferenz 2026 hat Shishi Technology ein neues Produkt vorgestellt:das TokenFleet-Verteilte-Scheduling-Framework. Der Optimierungsfokus liegt auf Request-Routing, kapazitätsübergreifender Koordination zwischen Rechenzentren und der Steuerung gemischter Workloads, um die effektive Auslastung der vorhandenen Rechenleistung zu steigern.

Betrachtet man den Inferenzdienst als eine „domestizierte Token-Optimierungsfabrik“, so sind die GPUs die Produktionsanlagen, die Inferenzinstanzen die Arbeitsplätze und die Business-Requests die einzelnen Aufträge. TokenFleet hat die Aufgabe, Aufträge und Kapazität zusammenzubringen.

Dieselbe Ausstattung liefert je nach Art der Aufgaben und Art der Zuteilung unterschiedliche Wartezeiten und unterschiedliche mengenmäßige konforme Ergebnisse. Skalierbare Dienste erfordern, dass diese Produktionsplanungen gemeinsam betrachtet werden.

TokenFleet konzentriert sich auf den effektiven Output des Clusters

Nachdem die Modelle bereitgestellt sind, muss der Cluster gleichzeitig多种 Geschäfte bewältigen.

Mehrere Modelle teilen sich Rechenleistung, verschiedene Mandanten haben eigene Service-Level-Anforderungen. Kurze Dialoge brauchen sofortige Antworten, die Verarbeitung langer Dokumente erfordert mehr Rechenleistung und Grafikspeicher, und Offline-Batch-Jobs haben Fristen. Wenn Dienste über mehrere Rechenzentren verteilt sind, muss zudem berücksichtigt werden, ob die Kapazitäten an den Standorten koordiniert werden können.

Eine einfache Aufteilung kann dazu führen, dass an einigen Instanzen lange Warteschlangen entstehen, während Kapazitäten an anderen Stellen nicht rechtzeitig genutzt werden. Lange Requests und Batch-Jobs drängen sich gegenseitig und verlangsamen die Echtzeit-Interaktion; Timeouts, Abbrüche und doppelte Berechnungen verbrauchen Ressourcen, ohne eine ordnungsgemäße Lieferung zu erzeugen.

TokenFleet sorgt – bei gleichbleibender Modellqualität, Serviceanforderungen und Rechenleistungsbudget – durchSteigerung des effektiven Token-Outputs und Senkung der Kosten pro Einheit effektiven Outputs。

TokenPilot wählt Instanzen innerhalb desselben Modellpools aus, FleetMind kümmert sich um die kapazitätsübergreifende Koordination zwischen Rechenzentren, und SLOMax ist zuständig für Zulassung, Warteschlangensteuerung und Kapazitätsverteilung bei gemischten Workloads – drei Kerntechnologien mit klar getrennten Aufgaben.

Wem ein Request zugewiesen wird, wann eine Aufgabe in die Warteschlange kommt und wie Rechenzentrumskapazitäten koordiniert werden – all das läuft letztlich auf dieselbe Kennzahl hinaus: der effektive Token-Output, der erfolgreich fertiggestellt wird und die Serviceanforderungen erfüllt.

TokenPilot rechnet Caching-Gewinne und Wartekosten gemeinsam ein

Zunächst zur Auswahl des Ziels für einen Request. An welche Instanz sollte ein Request gesendet werden?

Eine kurze Frage-Antwort-Einheit und ein langes Dokument können – obwohl beide als ein Request zählen – sehr unterschiedliche Mengen an Rechenleistung und Grafikspeicher verbrauchen. Eine Verteilung allein nach Request-Anzahl gleicht die tatsächliche Arbeitslast der Instanzen kaum aus.

Caching fügt dieser Abwägung eine weitere Ebene hinzu. Werden Requests mit demselben langen Präfix an eine Instanz gesendet, die die relevanten KV-Caches vorhält, können frühere Berechnungsergebnisse wiederverwendet und der Prefill – also die wiederholte Berechnung bei der Verarbeitung der Eingabe – reduziert werden.

Allerdings kann es bei Instanzen mit hoher Cache-Trefferquote auch lange Wartezeiten geben. Strömen alle Requests an dieselbe Stelle, kann die eingesparte Rechenzeit im Warten aufgezehrt werden.

TokenPilot schätzt bei der Auswahl des Zielszugleich den Nutzen der Cache-Wiederverwendung und die Wartekosten. Es schätzt die Arbeitslast anhand der Eingabegröße, des Output-Budgets und der wiederverwendbaren Präfixe und bewertet Kandidateninstanzen unter Berücksichtigung von Warteschlange, Tokens in Bearbeitung, KV-Cache-Druck und vorhergesagter Latenz. Das Output-Budget ist eine Beschränkung und entspricht nicht der tatsächlichen Ausgabelänge.

Der Scheduler vergleicht damit die voraussichtlichen Verarbeitungskosten verschiedener Instanzen und beurteilt, ob die durch die Cache-Wiederverwendung gesparte Rechenzeit die zusätzliche Wartezeit aufwiegt.

Laut den von Shishi Technology bereitgestellten Tuning-Daten für GLM5.3 sank – unter den getesteten Grafikkarten-Clustern und Lastbedingungen – nach Einführung des Latenzvorhersage-Routings dieP95-First-Token-Latenz um 32.4%, die P50-First-Token-Latenz um 71.3%。

△ Tabelle 1: Tuning-Ergebnisse der First-Token-Latenz von TokenPilot. Datenquelle: Konferenzvortragsmaterial von Shishi Technology. Die Verbesserungsrate wird berechnet als (Baseline-Wert − optimierter Wert) ÷ Baseline-Wert; eine gesenkte Latenz bedeutet nicht direkt gesenkte Kosten.

P50 spiegelt das mittlere Niveau wider, P95 die Wartezeit der Tail-Anfragen. Diese Daten zeigen die Antwortverbesserung unter den gemessenen Bedingungen; die Kosten-Nutzen-Bewertung muss weiterhin unter Einbeziehung von Durchsatz und Ressourcenverbrauch erfolgen.

FleetMind muss auch rechenzentrenübergreifend die Servicekapazität genau berechnen

Wenn sich die Perspektive von einem Modell-Pool auf mehrere Rechenzentren ausweitet, kommt bei der Planung eine zusätzliche Kapazitätsbewertung hinzu.

Freie GPUs bedeuten nicht, dass sofort Aufträge angenommen werden können. Ob das Zielmodell bereitgestellt ist, ob die Versionen übereinstimmen, ob der Service-Endpunkt bereit ist und wie viel Zeit die Netzwerkübertragung benötigt – all dies beeinflusst die Wirkung der Lastverteilung.

FleetMind achtet aufdie tatsächlich verfügbare Modell-Servicekapazität. Im Design von TokenFleet aggregiert es die Modellverfügbarkeit, die Echtzeitkapazität und den Netzwerkzustand der einzelnen Rechenzentren, wählt zunächst das Ausführungsrechenzentrum aus, und die lokale Entscheidungs-Engine dieses Rechenzentrums wählt dann die konkrete Inferenzinstanz aus.

Wenn in einem ausgelasteten Rechenzentrum Warteschlangen entstehen, bewertet das System, ob andere Rechenzentren einsatzbereite Endpunkte desselben Modellversionsstandes und noch verbleibende Servicekapazität haben, und prüft dann, ob neue Anfragen, die eine regionsübergreifende Ausführung erlauben, übernommen werden können.

Ob eine Ablenkung des Datenverkehrs möglich ist, hängt zunächst davon ab, dass Berechtigungs- und Datenspeicherort-Vorgaben erfüllt werden. Ob sich die Ablenkung lohnt, erfordert zudem einen Gesamtabgleich von Latenz beim Rückgriff auf die Quelle, Warteschlangen-, Rechen-, Cache- und Übertragungskosten.

Die Kapazitätskoordination erfolgt ebenfalls auf unterschiedlichen Zeitskalen: Kurzfristig wird das Ziel neuer Anfragen angepasst, langfristig werden Modellreplikate und Warmladeorte verändert, kombiniert mit Kapazitätsreservierung, Lastgrenzen-Wahrnehmung und automatischem Rückfall, um Kapazitätsfehlpassungen zu reduzieren.

△Abbildung 3: FleetMind-Ausführungsframework über Rechenzentren hinweg. Erläuterung: Standort A ist der Geschäftseingang und zählt nicht zum GPU-Kapazitätspool; Standort B ist der bestehende Cluster, die Standorte C und D sind erweiterte Rechenzentren.

TokenPilot und SLOMax richten sich an bestehende Cluster, FleetMind an die spätere Erweiterung um neu hinzukommende Rechenzentren. Das Ziel der rechenzentrumsübergreifenden Koordination besteht darin, dass verteilte Kapazitäten, die den Geschäftsanforderungen entsprechen, Hotspot-Nachfragen übernehmen und Kapazitätsfehlpassungen sowie doppelte Reservierungen verringert werden.

SLOMax plant die Produktion nach Serviceanforderungen

Anfragen gelangen in denselben Cluster, doch die Lieferanforderungen unterscheiden sich erheblich.

Echtzeitdialoge interessieren sich für die Antwortzeit des ersten Tokens und die kontinuierliche Generierungsgeschwindigkeit, Aufgaben mit langem Kontext sind stärker auf die Eingabeverarbeitungskapazität und KV-Kapazität angewiesen, und Offline-Batchaufgaben achten auf Fristen und Durchsatz. Legt man sie in dieselbe Warteschlange, entstehen leicht Ressourcenkonflikte.

Langes Prefill, KV-Kapazitätsdruck und Batch-Lasten können interaktive Anfragen verdrängen. Zeitüberschreitungen, Abbrüche und wiederholte Ausführungen führen zudem dazu, dass ein Teil der Berechnung nicht in eine wirksame Auslieferung umgesetzt wird.

SLOMax identifiziert Arbeitslasten anhand der Eingabelänge, des Ausgabebudgets, des Aufgabentyps und der Serviceziele der Mandanten, steuert dann die Zulassung nach Rangstufen, bildet Warteschlangenpools und koordiniert die Kapazität. Es muss interaktive Kapazität sichern und die Parallelität von langen und kurzen Anfragen sowie deren gegenseitige Störung kontrollieren.

△Abbildung 4: SLOMax-Framework mit klassifizierten Warteschlangen und Kapazitätsrückmeldung. Erläuterung: Die Wirkungsrückmeldung dient der Anpassung von Kapazität und Zulassung; das Framework geht nicht von einer Präemptionsfähigkeit für laufende Aufgaben aus.

Zur Messung der Wirksamkeit dieser Steuerung setzt TokenFleet die regelkonforme Produktion als Optimierungsziel ein.

Goodput, also der regelkonforme Ausgabedurchsatzwird berechnet als: die Gesamtzahl der Ausgabe-Tokens, die von Anfragen im vollständigen Testzeitraum erzeugt wurden, die erfolgreich abgeschlossen wurden und die vereinbarten Serviceanforderungen erfüllen, geteilt durch die Testdauer. Für unterschiedliche Aufgabenkategorien müssen die Schwellenwerte für die Konformität separat definiert und die Ergebnisse separat berichtet werden.

Das System gibt den regelkonformen Durchsatz, Fehler, Abbrüche und wiederholte Ausführungen an die Steuerungsstrategie zurück und passt kontinuierlich Zulassung und Kapazitätsanteile an. Wie ausgelastet die GPUs sind und wie hoch der Gesamtdurchsatz liegt, muss stets gemeinsam mit der endgültigen qualifizierten Auslieferung betrachtet werden.

Im Beispiel einer Nutzenkalkulation für GLM5.3 von Metastone (是石科技) stieg nach Einführung der flow-control-koordinierten Steuerung der Gesamtausgabedurchsatz um etwa 1,5%,der regelkonforme Ausgabedurchsatz stieg um etwa 29,4%und der regelkonforme Anteil erhöhte sich von etwa 67% auf etwa 86%.

△Tabelle 2: Beispielhafte Nutzenkalkulation des effektiven Token-Durchsatzes von SLOMax. Datenquelle: Präsentationsmaterial des Metastone-Kongresses. Diese Tabelle ist ein Beispiel einer Nutzenkalkulation; der regelkonforme Anteil folgt den gerundeten Werten des Originaltexts, die Veränderung beträgt etwa 19 Prozentpunkte.

Diese Zahlen sind Teil einer Nutzenkalkulation und zeigen die Output-Struktur, die die Steuerung verbessern möchte. Der tatsächliche Nutzen muss noch anhand konkreter Lasten und Service-Schwellenwerte verifiziert werden.

Bei gleichem Gesamtergebnis besteht die Chance, mehr regelkonforme Tokens auszuliefern, wenn Zeitüberschreitungen, Abbrüche und doppelte Berechnungen reduziert werden. SLOMax nimmt diese Ergebnisse in die Rückmeldung auf, um die künftige Ressourcenverteilung anzupassen.

Die Effizienz einer inländischen Token-Optimierungsfabrik hängt auch von der Steuerung ab

TokenFleet führt die Optimierung von Inferenzdiensten auf Cluster-Ebene weiter. Wie die Instanzleistung auf verschiedene Anfragen verteilt wird und wie die Kapazitäten mehrerer Rechenzentren in den Dienst einbezogen werden – all das erfordert, dass die Steuerung Ressourcen mit Geschäftsanforderungen verknüpft.

Metastone (是石科技) ist einunabhängiger, neutraler Full-Stack-Rechenleistungsbetreiber, der an keinen bestimmten Hersteller großer Modelle gebunden ist und seinen Kunden eine(n)一站式Full-Stack-Rechenleistungslieferung aus Hardware, Vernetzung, Steuerung, Optimierung und Betrieb。

bietet. Gestützt auf die umfangreiche Erfahrung aus nationalen Rechenzentren erreicht der Betrieb seiner Rechencluster ein SLA von über 99,95%. Derzeit verwaltet Metastone bereits mehr als 20000P+ an Rechenleistungskapazität und betreibt über 10 Superintelligenz-Zentren, darunter 2 nationale Supercomputing-Zentren; Teammitglieder wurden mit 3 Gordon-Bell-Preisen ausgezeichnet und verfügen über Full-Stack-Technologiediensterfahrung mit hyperskalierbaren Clustern.

Rund um die inländische Token-Optimierungsfabrik verfeinert Metastone seine Softwarefähigkeiten durch Eigenentwicklung und Eigennutzung in der Hoffnung, allgemeine und häufig genutzte Inferenzdienste wirtschaftlicher zu machen und die inländische Rechenleistung stärker auszuschöpfen.

Die zuvor veröffentlichte hocheffiziente Inferenz-Engine Meta-Infer zielte darauf ab, die Ausführungseffizienz einer einzelnen Inferenzinstanz zu steigern. TokenFleet setzt den Schwerpunkt dagegen aufCluster-Steuerung: durch Anfrageverteilung, Kapazitätskoordination und Governance gemischter Arbeitslasten organisiert es Dienste im großen Maßstab.

Damit mehr Unternehmen Tokens sich leisten können und sie gut nutzen können, braucht es sowohl Hardware, die Rechenleistung bereitstellt, als auch Software, die die Produktionskapazität organisiert.

TokenFleet verlagert die Richtung der weiteren Optimierung darauf, wie jede einzelne Anfrage zugewiesen und wie jede einzelne Kapazität genutzt wird.

*Dieser Artikel wurde von Quantum Bit mit Genehmigung veröffentlicht; die Ansichten gehören ausschließlich dem ursprünglichen Autor.