Auf dem von D1net veranstalteten Summit für CIOs und Führungskräfte von staatseigenen Unternehmen im Herbst 2026 (19. Auflage) präsentierte Tang Anbo, Director of Silicon-Based Flow Solutions, einen Vortrag mit dem Thema: „Von ‚Rechenleistung‘ zu ‚Token-Produktivität‘: Die Infrastruktur für die Skalierung großer Modelle von staatseigenen Unternehmen und die ROI-Praktiken“. Im Folgenden ist der Kern des Vortrags enthalten.
Im Moment befinden sich AI-Anwendungen in der frühen Phase eines explosionsartigen Wachstums, und die Tokenverbrauchung wächst exponentiell. Hinter dieser Entwicklung entwickelt sich die Modellarchitektur stetig weiter, und die Versionen werden schnell aktualisiert; gleichzeitig entwickelt sich auch die Rechenleistungsarchitektur weiter. Zwischen den Modellen und der Rechenleistung gibt es einen gegenseitig vorantreibenden Iterationsprozess. Für Unternehmen muss es einerseits mit diesen Veränderungen Schritt halten, andererseits aber auch vielfältige Modelldienste für ihre Geschäftsszenarien anbieten und die Kosten innerhalb eines angemessenen Rahmens halten.
Was das Siliziumbasierte Flow tut, ist, die Übertragungsschicht zwischen Rechenleistung und Token zu schließen: Die Rechenleistung wird zusammengefasst; durch einen eigenentwickelten Schluss-Engine wird das Modell schneller und besser laufen. Wir bauen sowohl in der öffentlichen Cloud Token-Fabriken auf, als auch helfen staatlichen Unternehmen dabei, ihre eigenen Token-Fabriken zu errichten.
Kurz gesagt: Durch ein systematisches Rätselverfahren wird eine mehrfache Anpassung von Modellen und Rechenleistung erreicht. Auf dieser Grundlage wird die Silizium-basierte Fluss-Formel für die Token-Produktivität vorgeschlagen: Token-Produktivität = Kapazität × Nutzungsrate × Lieferqualität. Dabei wird die Kapazität durch die Hardwarekapazität der Chips und den Optimierungsgrad der Modelle bestimmt; die Nutzungsrate wird durch Traffic-Verwaltung und intelligente Rechenleistungsteuerung erreicht; die Lieferqualität umfasst die Genauigkeit des Modellverstandnisses, den Erfolg der Aufrufe von Tools sowie die Stabilität der SLA-Dienstleistungen, die für das Produktionsumfeld erforderlich sind.
Von der zentralen Verwaltung zu Modellbetrieb – die Nutzung der Rechenleistung wirklich optimieren
Wir haben eine vierstufige Dekompilation-Architektur aus der Perspektive von Geschäftsprozessen und Traffic entworfen. Dabei werden Modellbetrieb, Modellwartung, Inferenzausführung und Rechenleistungsverkehr miteinander verbunden, um alle Phasen des Lebenszyklus eines Modells abzudecken – von der Implementierung bis zur Service-Disposition. Die dekompilierte Architektur ermöglicht es auch, sich an die bestehenden Plattformen staatlicher Unternehmen anzupassen und wiederholte Investitionen zu vermeiden; wenn das Unternehmen bereits eigene Kapazitäten besitzt, kann die Kommunikation mit bestehenden Systemen erfolgen, ohne alles neu aufzubauen. So kann man direkt die benötigten Fähigkeiten durch eine „Kapazitätskombination“ ergänzen.
Modell-Gateway: Es ist nicht nur ein Eingang, sondern auch eine Plattform für die Modellbetriebsführung.
Diese Schicht ist direkt mit den Nutzern von Modelldiensten verbunden, wie beispielsweise den Unternehmen und deren Tochtergesellschaften. Alle Aufrufe großer Modelle werden durch diese Schicht für die Messung, Berechnung und Zertifizierung der Grundarbeiten durchgeführt. Noch wichtiger ist, dass sie zahlreiche Planungsoptionen und Routing-Methoden anbietet: So kann je nach Anforderungen an die Antwortzeit in verschiedenen Geschäftsszenarien die Anfrage auf die entsprechende Modelldienstleistung weitergeleitet werden, sodass die verschiedenen Geschäfte untereinander nicht beeinträchtigt werden und jeder Teilnehmer einen zufriedenstellenden SLA erhält; gleichzeitig ermöglicht es eine flexible Planung nach verschiedenen Zielen wie Leistungspriorität oder Kostenpriorität.
Modelldienstleistungsplattform: Die besten Praktiken für die Bereitstellung und Wartung bereiten Unternehmen vor.
Diese Schicht verwaltet hauptsächlich aus der Sicht des Operations und Wartens die Fähigkeiten wie das Herunterfahren von Modellen und das Modelllager. Wir integrieren best Practices für die Deployment von Modellen, sodass Unternehmen die Modelle mit einer einzigen Taste aktivieren können, anstatt jedes Mal eine Neukonfiguration durchzuführen. Wir haben bereits fast hundert Modelle konfiguriert, und neue Mainstream-Modelle werden kontinuierlich angepasst – das Ziel ist es, dass die Geschäftsteams die Modelle sofort verwenden können.
Hochleistungs-Inferenzframework: Optimierte Iterationen für spezifische Modelle und Hardware.
Wir führen enge Zusammenarbeit mit verschiedenen Rechenleistungsanbietern. Um spezifische Modelle und Rechenleistung zu unterstützen, entwickeln wir eigene Operatorbibliotheken und Kommunikationsbibliotheken, um das Leistungspotenzial der Modelle auf dem entsprechenden Hardware-System so weit wie möglich freizusetzen. Zum Beispiel hat man mit Huawei Cloud zum ersten Mal in der Branche einen DeepSeek R1/V3 Token-Dienst auf einem inländischen Chip eingeführt. Zusammen haben sie eine Rechenlösung für das CloudMatrix-Hypernode-Kluster entwickelt und optimiert, wodurch die Durchsatzleistung des Decode-Prozesses auf dem DeepSeek-R1 über 1.920 tokens/s erreicht wurde. Ebenfalls erstmalig weltweit wurde eine kommerzielle Dienstdeployment-Lösung für das Kimi-K2-Großmodell auf dem Muxi C550-Kluster eingeführt. Auf dem Moore Thread MTT S5000-Chip wurde DeepSeek-V3 deployed, wodurch der Prefill-Durchsatz auf einem einzelnen Card über 4000 tokens/s und der Decode-Durchsatz über 1000 tokens/s erreicht wurde.
Gleichzeitig entwickelt sich unsere Rechentechnologie kontinuierlich weiter: Da der Kontext der Modelleingriffe zunehmt und die Konkurrenzfähigkeit steigt, ist es notwendig, das Recheneffizienzmodell kontinuierlich zu optimieren – beispielsweise durch Optimierung von Operatoren, Kommunikation und Quantisierung des Modells. Dabei werden Methoden wie PD-Separation und KV-Cache-Abstraktion eingesetzt, um die Gesamtkompetenz und den Durchsatz der Modelleingriffe deutlich zu verbessern.
Rechenleistungsverteilung: Elastische Verwaltung von Rechenleistungsressourcen.
Eine elastische und flexible Rechenleistungsverteilung ist ein Schlüsselfaktor zur Reduzierung der Berechnungskosten und zur Steigerung der Nutzung der Rechenleistung. Doch die Planung der Rechenleistung steht oft vor einem Dilemma: Eine zu konservative Schätzung kann schnell eine volle Belastung oder sogar Überlastung bedeuten; eine vollständige Konfiguration nach dem Tagestiefstwert führt hingegen zu Ressourcenverschwendung in anderen Zeitabschnitten. Daher ist sowohl eine elastische Skalierungsstrategie als auch betriebliche Maßnahmen erforderlich.
Zum Beispiel kann bei der Bereitstellung von Modelldiensten durch staatliche Unternehmen an ihre Tochtergesellschaften eine zeitabhängige Preisgestaltung in den internen Abrechnungen verwendet werden: Tagsüber wird die übliche Preisgestaltung angewendet, nachts gibt es einen Rabatt, um einen Teil der Geschäfte nachts zu betreiben. Die verschiedenen Geschäfte könnten unterschiedliche Modelle verwenden, was erfordert, dass die Plattform auf Basis von Kriterien wie Anfragen und Leistung die Modellinstanzen dynamisch anpassen kann.
Fall eines staatlichen Unternehmens: Von „Machbarkeiten mieten“ zu „Modelldiensten aufrufen“
Wir haben eine staatliche Unternehmensgruppe betreut, die ursprünglich etwa 50 Maschinen hatte und Dienstleistungen an die untergeordneten Tochtergesellschaften anbot. Die frühe Art der Dienstleistung war sehr direkt: Die Tochtergesellschaften beantragten die Maschinen und installierten die von ihnen benötigten Modelle – um es völlig klar zu sagen, es handelte sich dabei um „Machtzuteilung“.
So wurden vierzig oder fünfzig Modelinstanzen erstellt, aber die Gesamtnutzung der Rechenleistung ist sehr niedrig. Einige Einheiten nutzen die Maschine nur für eine einzige Modelleinstellung; andere werden tagsüber genutzt und nachts nicht; wieder andere werden nur wenige Tage pro Woche verwendet. Die Maschinen sind besetzt, aber es entsteht keine kontinuierliche effektive Last.
Wir arbeiten eng mit den Kunden zusammen und überarbeiten die oben genannte Situation: Konsolidierung der Modelle und einheitliche Rechenleistung. Die wiederkehrenden Modelle werden auf etwa zehn reduziert; die Ressourcenverteilung nach Maschinen wird in einen Serverless-Modelldienst umgewandelt, sodass alle den API abrufen können – es ist nicht mehr wichtig, wo das Modell konkret implementiert ist oder welche Maschine es beansprucht.
So können etwa 50 Maschinen gleichzeitig mehr Aufgaben erledigen. Zum Beispiel können nach dem Einsatz einiger Maschinen für bestehende kleine Modelle mehrere Maschinen freigegeben werden, um neue Modelle mit großen Parametern zu implementieren, wie GLM-5.2, DeepSeek-V4-Flash-0731 usw. In der Vergangenheit waren solche Modelle innerhalb des Unternehmens nicht einsetzbar. Doch neue Modelle mit großen Parametern sind für die Geschäftsforschung sehr wichtig, denn die Grenze der Modelleinsatzfähigkeit bestimmt auch die Grenze der Anwendungsinnovationen. Durch die Konvergenz der Modelle und die intensive Verwaltung der Rechenleistung haben wir diese Modelle implementiert und zusammen mit der Leistungsoptimierung mehr Szenarien von „unbrauchbar“ in „nutzbar“ zu machen, von „erforschbar“ zu „skalierbar“.
Ursprünglich war die größte Sorge auf der Geschäftsseite: Es ist kein Problem, eine Erkundung durchzuführen und einen Agent zu erstellen, aber kann er in großem Maßstab in Betrieb gehen? Kann er mehr Aufrufe bewältigen? Alle hatten Zweifel. Nach dem Start des neuen Modells bleibt die Gesamtfrequenz bei Tests von einer einzigen Konkurrenzlast bis zu vielen Konkurrenzlasten im Durchschnitt über 30 tokens/s. Im Programmierenbeispiel ist eine Überschreitung von 30 TPS eine grundlegende Voraussetzung für einen guten Benutzerzugang. In vergleichbaren Tests des gleichen Modells erzielten wir eine Leistungssteigerung von 40 % bis 100 %. Natürlich hängt das von den unterschiedlichen Eingabedaten und Ausgabelängen ab, sodass die jeweiligen Ergebnisse nicht gleich sind.
Insgesamt hat es dazu geführt, dass die Durchsatzfähigkeit des Modells gesteigert wurde und die Nutzung der Rechenleistung verbessert wurde. Durch diese beiden Faktoren fällt der Kosten pro Million Tokens, was ein Indikator ist, mit dem viele Unternehmen die Effizienz von Reasoning-Diensten messen. In diesem Fall lag der ursprüngliche Kostenwert eines Qwen-Modells pro Million Tokens bei über hundert Yuan, während er nach der Anpassung unter zehn Yuan sank. Die Kosten sind deutlich gesunken, aber am wichtigsten ist, dass es mehr Geschäftsszenarien ermöglicht, die vorher schwer umsetzbar waren.
Weitere Verbesserung des ROI – Optimierung von Anwendungen und Infrastruktur gemeinsam
Mit der Skalierung des Agenten haben wir auch ein Problem beobachtet: Es gibt eine gewisse Abweichung zwischen der Anwendungsebene und der Infrastrukturebene. In der Vergangenheit, wenn es um Anwendungen ging, selbst wenn sie hauptsächlich für die Frontend-Seite zuständig waren, hatten Entwickler normalerweise ein gewisses Verständnis für Datenbankindizes und SQL-Optimierung. Heute ist die Trennung zwischen großen Modellanwendungen und der Infrastruktur deutlicher. Die Anwendungsebene versteht möglicherweise nicht vollständig die untere Berechnungs- und Caching-Mechanismen, und das hat direkten Einfluss auf die Effizienz.
Als Beispiel für Coding untersuchen wir gemeinsam mit den Kunden diese Optimierung. Das Softwareengineering von staatlichen Unternehmen ist nicht so, dass man heute ein App entwickelt und morgen eine andere Demonstration erstellt, sondern es geht um kontinuierliche Iterationen über mehrere Jahre hinweg. Der Code-Repository wird ständig aktualisiert, tägliche Code-Uploads und Builds sind Teil eines langfristigen Projekts. Wie diese Code-Strukturen zum Kontext des Modells werden, ist sehr wichtig.
Wenn die Konstruktion des Kontexts nicht gut ist, kann bei jeder Anfrage der Cache nicht erreicht werden. Die Eingabe von zehntausenden Tokenn verbraucht viel Rechenleistung. Doch wenn die Konstruktion gut ist, können etwa neunzig Prozent des Inhalts im Cache geladen werden, und der Effizienzunterschied wird sichtbar. Zum Beispiel kann das System bei nicht erfolgreicher Ladeerfüllung 100 parallele Anfragen unterstützen; nach Erhöhung der Cache-Erfolgsrate kann es 200 parallele Anfragen unterstützen. Diese Steigerung erhöht nicht die Hardware, sondern reduziert den wiederholten Berechnungen. Daher muss die Konstruktion des Kontexts selbst für die Schlussfolgerung optimiert werden.
In einer anderen Richtung ist es möglich, DevOps zu kombinieren, um die Leistung zu optimieren. Die Nutzung von Rechenleistung hat Höhen und Tiefen – tagsüber wird viel Rechenleistung genutzt, und die Eingaben in Coding-Szenarien sind lang. Wenn alle Code erst am Tag, wenn Anfragen kommen, verarbeitet und dann in einen Cache gespeichert werden, würde dies eine große Menge an Rechenleistung während der Hochsaison beanspruchen. Könnte man also während des täglichen Build-Prozesses am Abend durch ingenieurtechnische Maßnahmen den Modell so vorbereiten, dass er den Code-Repository vorab verarbeitet und die entsprechenden Ergebnisse in einen KV-Cache speichert? Auf diese Weise müsste man tagsüber keine wiederholten Berechnungen durchführen. Alle diese Methoden bieten die Möglichkeit, die Nutzung der Rechenleistung weiter zu verbessern. Doch diese Fähigkeiten hängen auch von unserem gemeinsamen Erkunden mit den Szenarien ab.
Das Silizium-basierte Flussprojekt hofft gemeinsam mit staatlichen Unternehmen, weitere Anwendungsmöglichkeiten von KI zu entdecken und echte Rechenleistung sowie Produktionskapazität freizusetzen.
Leifeng Net (Public Account: Leifeng Net) Leifeng Net