Die KI-Infrastruktur geht über die Ära hinaus, in der ein einzelnes Modell auf eine Anfrage bedient wird. Ein produktionsreifer Agent nimmt ...
Die KI-Infrastruktur geht über die Ära hinaus, in der nur ein einzelnes Modell pro Anfrage verarbeitet wird.
Ein produktionsreifer Agent ist mehr als nur ein System, das einen Prompt entgegennimmt und eine Antwort liefert. Er kann Aufgaben in mehrere Phasen unterteilen, externe Tools aufrufen, Kontext verwalten, mit Sub-Agenten koordinieren, Zwischenergebnisse prüfen und über längere Zeit aktiv bleiben. Wenn Unternehmen Tausende solcher Agenten gleichzeitig einsetzen, unterscheiden sich die Anforderungen an die Infrastruktur grundlegend von denen gewöhnlicher Chatbot-Inferenzen.
Auf dem Open Compute Technology Summit 2026 in Peking präsentierte Inspur zwei infrastrukturelle Richtungen für diese neue Arbeitslast:
Die erste Richtung konzentriert sich auf den Maßstab: eine große Anzahl langlebiger Agenten online zu halten. Die zweite Richtung konzentriert sich auf die Qualität: mehreren Modellen mit unterschiedlichen Stärken zu ermöglichen, zusammenzuarbeiten, anstatt ein einzelnes Modell zu zwingen, jeden Teil einer schwierigen Aufgabe zu bewältigen.
Die herkömmliche Inferenz großer Sprachmodelle folgt in der Regel einem einfachen Muster:
Der Ausführungspfad einer Agentenanwendung ist jedoch wesentlich länger.
Eine einzelne geschäftliche Aufgabe kann Folgendes umfassen:
Daher muss die Infrastruktur nicht nur die Modellinferenz unterstützen, sondern auch eine große Anzahl dauerhaft laufender Softwareprozesse.
In Unternehmensumgebungen kann die Anzahl der aktiven Agenten von einigen Dutzend auf Tausende oder sogar Zehntausende ansteigen. Einige Agenten laufen möglicherweise kontinuierlich, während andere dynamisch für kurze Aufgaben erstellt und nach Abschluss wieder vernichtet werden.
Dies verändert das Gleichgewicht zwischen CPU- und GPU-Ressourcen.
GPUs sind in den folgenden Bereichen unverzichtbar:
Die CPU erledigt einen Großteil der peripheren Arbeit:
Das Modell mag für die Generierung von Schlussfolgerungen oder Text verantwortlich sein, aber die CPU betreibt in der Regel die Betriebsumgebung, in der der Agent ausgeführt wird.
Daher verlagert sich die Agenten-Infrastruktur von einem GPU-zentrierten Design hin zu einem System, bei dem CPU, GPU, Netzwerk, Speicher, Kühlung und Orchestrierungssoftware zusammenwirken.
In gewöhnlichen Unternehmensservern war die CPU-Dichte historisch durch Faktoren wie Stromverbrauch, Kühlung, Platz, Kabel, Lüfter und Wartungsanforderungen begrenzt.
Agenten-Einsätze verändern das wirtschaftliche Modell.
Wenn Tausende von Agenten CPU-Ressourcen für Orchestrierung, Werkzeugaufrufe und isolierte Laufzeitumgebungen benötigen, beanspruchen Racks mit geringer CPU-Dichte mehr Rechenzentrumsfläche, Netzwerkverbindungen und zugehörige Infrastruktur.
Gleichzeitig entwickeln sich KI-Rechenzentren hin zu einer höheren Rack-Leistung.
Laut Quellenberichten erwartet Inspur, dass die Leistung von KI-Racks in China fast 300 kW erreichen wird, während einige globale Designs bereits auf Megawatt-Rack-Systeme zusteuern. Herkömmliche Luftkühlung, die normalerweise auf einige zehn Kilowatt pro Rack begrenzt ist, wird bei dieser Dichte zunehmend schwieriger.
Daher ist Flüssigkeitskühlung nicht mehr nur ein Problem für GPUs.
Auch CPU-Racks, die Agenten-Workloads unterstützen, müssen an die Strom- und Kühlarchitektur der nächsten Generation von KI-Rechenzentren angepasst sein.
Inspur hat den nach eigenen Angaben branchenweit ersten CPU-nativen, flüssigkeitsgekühlten Komplettrack-Server vorgestellt.
Das System basiert auf der flüssigkeitsgekühlten OCM 2.0-Architektur und unterstützt x86- und Arm-Prozessoren.
Die wichtigsten Parameter sind:
| Merkmal | Vom Hersteller angegebene Parameter |
|---|---|
| Maximale Anzahl CPUs pro Rack | 384 |
| Unterstützte Anzahl gleichzeitiger Agenten | über 40.000 |
| Prozessorarchitektur | x86 und Arm |
| Kühlbereich | CPU, Arbeitsspeicher, SSDs, Netzwerkkarten, optische Module und andere wärmeerzeugende Komponenten |
| Rechendichte | 4 CPUs integriert in 0,5U Platz |
| Wartungsart | Flüssigkeitskühlung über den gesamten Lebenszyklus |
| Ziel-Szenarien | Hochdichte und Gigawatt-KI-Rechenzentren |
Das System betrachtet Flüssigkeitskühlung nicht als nachträgliches Add-on zum Serverdesign.
Vielmehr wurden das Rechnerlayout und die Kühlarchitektur gemeinsam entwickelt.
Herkömmliche Server mit Kühlplatten
können die Prozessoren zwar direkt kühlen, aber Arbeitsspeicher, Netzwerk, Speicher, Stromversorgungskomponenten und andere Geräte sind weiterhin auf Lüfter zur Kühlung angewiesen.
Mit zunehmender Dichte wird diese Methode weniger effektiv.
Die native Flüssigkeitskühlungsarchitektur von Inspur bezieht die wichtigsten wärmeerzeugenden Komponenten in ein einheitliches Kühlsystem ein:
Dies reduziert die Abhängigkeit von der internen Luftzirkulation und ermöglicht eine kompaktere Anordnung der Komponenten.
Unten befinden sich drei blaue Symbole: „Flüssigkeitskühlungsarchitektur“, „Flüssigkeitskühlungsverbindung“ und „Flüssigkeitskühlungsbetrieb“. Das Bild steht in engem Zusammenhang mit dem Kontext und zeigt anschaulich die Präsentation des Inspur-Flüssigkeitskühlungsservers, was mit der im Dokument beschriebenen Flüssigkeitskühlungsarchitektur übereinstimmt.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
Der Bericht beschreibt eine kompakte Recheneinheit, die mehrere Gruppen von Prozessoren und Peripheriekomponenten in einem schlanken Gehäuse integriert.
Das Designziel besteht darin, den Platz zurückzugewinnen, der zuvor von folgenden Komponenten belegt wurde:
Durch die flache Komponentenanordnung kann eine einzige große Kühlplatte mehr Systembereiche abdecken.
Der Rack verwendet ein kabelreduziertes oder kabelloses internes Design und ermöglicht einen unterbrechungsfreien Betrieb während der Wartung. Inspur gibt an, dass dies die Effizienz der Rack-Bereitstellung und -Wartung verbessert.
OCM steht für Open Compute Module.
Die modulare Architektur zielt darauf ab, das Prozessormodul vom Gesamtdesign des Systems zu entkoppeln. Dieses Design ermöglicht es, Prozessoren verschiedener Generationen oder Architekturen einfacher zu unterstützen, ohne für jeden Prozessor das gesamte Rack neu zu entwerfen.
Für Unternehmen und Rechenzentrumsbetreiber bietet dieser Ansatz folgende Vorteile:
Die tatsächliche Wirksamkeit hängt von der Ökosystem-Kompatibilität, Interoperabilität und Verfügbarkeit der zugehörigen Komponenten ab.
Der Betrieb von Zehntausenden von Agenten löst Kapazitätsprobleme, verbessert aber nicht automatisch die Antwortqualität.
Große Sprachmodelle haben ihre spezifischen Stärken.
Bestimmte Modelle sind möglicherweise besser geeignet für:
Selbst extrem große Modelle haben Schwächen.
Bei komplexen Aufgaben übersieht ein einzelnes Modell möglicherweise kritische Punkte, die andere Modelle erkennen. Ein einzelnes Modell kann auch selbstbewusst Antworten geben, ohne Unsicherheiten offenzulegen oder alternative Erklärungen in Betracht zu ziehen.
Daher konzentriert sich Inspurs zweiter Infrastruktur-Schwerpunkt auf die Multi-Modell-Kollaboration.
Die EPAI Multi-Modell-Fusion-API verteilt komplexe Aufgaben parallel an mehrere Kandidatenmodelle.
Jedes Modell generiert unabhängig eine Antwort. Ein weiteres Prüf- und Fusionsmodell vergleicht die Kandidatenantworten und identifiziert:
Nicht unterstützte Aussagen:
Anschließend generiert die Plattform eine integrierte Antwort.
Dies ist keine einfache Mehrheitsabstimmung und auch keine direkte Aneinanderreihung aller Antworten. Der erwartete Arbeitsablauf ist wie folgt:
Inspur berichtet, dass das System im DRACO-Benchmark 53,9 % erreicht hat und damit jedes einzelne Modell im verwendeten Kandidatenpool übertrifft.
Dieses Ergebnis sollte als Basislinie für den Plattformbericht betrachtet werden, nicht als Behauptung, dass die Modellfusion immer das beste Einzelmodell übertrifft. Die Leistung hängt von den Kandidatenmodellen, Bewertungsmodellen, Routing-Logik, Aufgabentyp, Prompt und Bewertungsmethode ab.
Wenn für jede Anfrage mehrere Modelle ausgeführt würden, würden Kosten und Latenz unnötig steigen.
Daher unterscheidet EPAI zwischen kurzen, vorhersagbaren Aufgaben und komplexen Aufgaben.
Leichte Modelle sind möglicherweise ausreichend für:
Mehrere Modelle könnten nützlich sein für:
Dieses Routing-Prinzip ist für Produktionssysteme von entscheidender Bedeutung.
Die Multi-Modell-Kollaboration ist dann am wertvollsten, wenn die potenzielle Qualitätsverbesserung die zusätzlichen Token-Kosten, GPU-Zeit und Antwortlatenz ausgleicht.
Die EPAI-API zielt darauf ab, die Multi-Modell-Orchestrierung hinter einer einheitlichen Schnittstelle zu verbergen.
Entwickler senden eine Anfrage an die Plattform. EPAI verwaltet:
Dieselbe Schnittstelle kann in Agent-Anwendungen und Entwicklungsframeworks integriert werden, ohne dass jedes Team ein eigenes Modell-Routing und Bewertungssystem erstellen muss.
Die Architektur eignet sich für Unternehmen, die eine Mischung von Modellen verwenden:
Die größte betriebliche Herausforderung besteht darin, dass mehrere große Modelle gleichzeitig verfügbar sein müssen. Dies stellt höhere Anforderungen an den Beschleunigerspeicher, die Interconnect-Bandbreite, das Scheduling und die Kommunikation mit geringer Latenz.
Beschreibe deine Idee einmal, und We0 AI erstellt eine Showcase-Website, Seiten und ein CMS und hilft nach dem Launch bei Kunden und Traffic.
Eine komplette Projektgeneration zur kostenlosen Registrierung
Am besten geeignet, um einen vollständigen Generierungsablauf auszuprobieren und schnell einen ersten Projektentwurf zu sehen.
Der MetaBrain SD200 Supernode ist die Hardware-Plattform, die den Multi-Modell-Fusion-Workflow unterstützt.
Das System verwendet eine Multiprozessor-Architektur mit Memory-Semantic-Kommunikation und geringer Latenz. Laut Inspur kann es innerhalb eines einzigen Systems 64 inländische GPU-Beschleuniger miteinander verbinden.
Das Design umfasst:
Fähigkeiten
Angeblich kann dieser Supernode ein einzelnes Modell mit einer Größe von bis zu vier Billionen Parametern oder mehrere Modelle mit Billionen Parametern unterstützen, die gleichzeitig von Agent-Anwendungen verwendet werden.
Inspur berichtet, dass der SD200 die Single-Token-Generierungszeit des Kimi K2.6-Modells mit Billionen Parametern auf 4,77 Millisekunden verkürzt hat.
Das Unternehmen berichtet außerdem, dass die First-Token-Generierungszeit im Vergleich zur vorherigen Implementierung um 35 % reduziert wurde.
Diese Daten beziehen sich auf Ergebnisse in spezifischen Optimierungs- und Testumgebungen und sollten nicht als garantierte Latenz für jedes Modell, jede Bereitstellung, Prompt-Länge, Parallelität oder Produktionsworkload interpretiert werden.
Diese Verbesserungen sind auf mehrere Technologien zurückzuführen.
Autoregressive Modelle generieren normalerweise zuerst einen Token, überprüfen den neuen Zustand und generieren dann den nächsten.
Multi-Token-Vorhersage versucht, in einem Schritt mehrere Kandidaten-Token zu generieren und gemeinsam zu überprüfen.
Wenn die Vorhersagegenauigkeit hoch ist, kann die Anzahl der sequentiellen Dekodierungsschritte reduziert werden.
Die Optimierung verwendet INT4-Gewichte und INT8-Aktivierungsberechnungen in einem Teil der Arbeitslast des Mixture-of-Experts-Modells.
Im Vergleich zu BF16-Berechnungen reduziert dies:
Quantisierung kann die Modellqualität beeinflussen, daher müssen Produktionsteams die Genauigkeit auf Basis ihrer eigenen Arbeitslast bewerten, anstatt sich nur auf die Geschwindigkeitsergebnisse zu verlassen.
JIT-Kompilierung generiert zur Laufzeit spezialisierte Beschleuniger-Kernel basierend auf Tensor-Formen, Layouts und Datentypen.
Im Vergleich zu generischen, statischen Implementierungen reduzieren spezialisierte Kernel unnötige Verzweigungen und verbessern den Speicherzugriff.
Prompt-Prefill und Token-Dekodierung haben unterschiedliche Leistungsmerkmale.
Durch die Trennung der beiden Phasen können Ressourcen differenziert zugewiesen und KV-Caches asynchron übertragen werden, wodurch Konflikte zwischen Berechnung und Kommunikation reduziert werden.
Inspur gibt an, dass der SD200 die Leistungsoptimierung für mehrere gängige Open-Source-Modelle abgeschlossen hat, darunter:
Kompatibilität bedeutet nicht unbedingt, dass jedes Modell die gleiche Latenz oder den gleichen Durchsatz erreicht.
Modellarchitektur, Anzahl der Parameter, MoE-Design, Kontextlänge, Quantisierung, Batchverarbeitung und Serversoftware beeinflussen alle die Leistung.
Das 64-Beschleuniger-Supernode eignet sich für große KI-Infrastrukturprojekte, ist aber für viele Unternehmen zu groß und zu teuer.
Inspur hat außerdem die MetaBrain SD200 Enterprise Edition vorgestellt.
Die Enterprise Edition reduziert das vertikal skalierte Rechendomäne von 64 auf 16 Beschleuniger und zielt auf die lokale Bereitstellung von Billionen-Parameter-Modellen ab.
Die beworbenen Eigenschaften umfassen:
Diese Enterprise Edition ist für die folgenden Workloads konzipiert:
Es bietet einen kleineren Einstiegspunkt für Organisationen, die eine lokale Modellkontrolle benötigen, aber den 64-Beschleuniger-Supernode nicht rechtfertigen können.
Die auf der OCTS 2026 vorgestellten Produkte zeigen eine Drei-Schichten-Architektur.
| Schicht | Hauptverantwortung |
|---|---|
| Softwareplattform | Modellzugriff, Aufgabenrouting, Orchestrierung, Berechtigungen, Evaluierung und Ergebnis-Fusion |
| CPU-Infrastruktur | Agentenprozesse, Werkzeugaufrufe, Sandbox-Ausführung, Kontextverwaltung und Interaktion mit Geschäftssystemen |
| GPU-Supernode | Large-Model-Inferenz, Token-Generierung mit hohem Durchsatz und Multi-Modell-Ausführung |
Das System funktioniert nur dann richtig, wenn alle drei Schichten zusammenarbeiten.
Ein schneller GPU-Cluster kann eine schwache Agentenplanung nicht ausgleichen. Ein dichter CPU-Rack verbessert die Inferenzqualität nicht, wenn er keinen Zugriff auf leistungsstarke Modelle hat. Eine komplexe Fusions-API kann keine nützliche Latenz bieten, wenn die zugrunde liegenden Modelle nicht effizient geladen oder verbunden werden können.
Dies ist eine der wichtigsten Veränderungen im Wettbewerb um die Agenteninfrastruktur.
Der frühe Markt konzentrierte sich hauptsächlich darauf, wie gut ein einzelner Server ein einzelnes großes Modell unterstützen kann. Das Zeitalter der Agenten lenkt die Aufmerksamkeit auf die systemweite Leistung:
Glänzende Zahlen der Anbieter sind nützlich, aber nicht ausreichend, um eine Plattform für die Agenteninfrastruktur auszuwählen.
Eine Bewertung unter Produktionsbedingungen sollte den vollständigen Workload messen.
Zählen Sie nicht nur die aktiven Benutzer, sondern auch:
Ein leichtgewichtiger
Recherche-Agent hat ein völlig anderes Ressourcenprofil als ein Codier-Agent mit einer eigenen Entwicklungsumgebung.
Die Metrik "Agenten pro Rack" muss auf den tatsächlichen Speicher-, CPU-, Speicher- und Netzwerkbedarf der Zielanwendung abgebildet werden.
Es ist zu messen:
Niedrige Token-Generierungszeiten in Benchmarks garantieren keine niedrige Latenz für End-to-End-Workflows.
Die Fusion mehrerer Modelle kann die Qualität verbessern, aber zu einem exponentiellen Anstieg der Inferenzkosten führen.
Teams sollten vergleichen:
Native Flüssigkeitskühlungs-Racks benötigen eine passende Anlageninfrastruktur.
Es ist zu prüfen:
Offene Modulstandards können die Flexibilität erhöhen, aber die tatsächliche Portabilität hängt von der Softwarekompatibilität ab.
Es ist zu validieren:
Langlaufende Agenten benötigen eine starke Kontrolle über:
Die Dichte der Infrastruktur sollte nicht auf Kosten der Betriebsisolation gehen.
Es handelt sich um ein komplettes Rack-CPU-Serverdesign, das um ein Kühlsystem herum entwickelt wurde, und nicht um eine nachträgliche Flüssigkeitskühlung eines luftgekühlten Designs. Inspur gibt an, dass es bis zu 384 CPUs aufnehmen und über 40.000 gleichzeitige Agenten unterstützen kann.
Diese Zahl ist das Maximum, das im Bericht des Lieferanten der Referenzarchitektur von Inspur angegeben wird. Die tatsächliche Kapazität hängt von den CPU-, Speicher-, Netzwerk- und Sandbox-Isolationsanforderungen jedes Agenten ab.
Sprachmodelle laufen möglicherweise auf GPUs, aber Agenten benötigen auch CPUs für Planung, Werkzeugausführung, Statusverwaltung, Geschäftssystemzugriff, Sicherheitsprüfungen und isolierte Laufzeitumgebungen. Langlaufende und Multi-Agenten-Workflows erhöhen diesen CPU-Bedarf weiter.
OCM ist eine offene Rechenmodul-Architektur, die das Rechenmodul vom breiteren Rack-Design entkoppelt. Das flüssigkeitsgekühlte OCM 2.0-System von Inspur unterstützt mehrere CPU-Architekturen und vollständige Bauteil-Flüssigkeitskühlung.
MetaBrain SD200 ist ein KI-Supernode von Inspur, der für Large-Model-Inferenz und Multi-Modell-Workloads entwickelt wurde. Es verwendet eine 64-Beschleuniger-Skalierungsarchitektur und unterstützt einheitliche Adressierung und Hochgeschwindigkeitsverbindungen.
Dies ist eine API, die eine Aufgabe an mehrere Kandidatenmodelle sendet, deren unabhängige Antworten sammelt und
ein Überprüfungs- und Fusionsmodell verwendet, um Konsens, Abweichungen, Auslassungen und einzigartige Erkenntnisse zu identifizieren, bevor die endgültige Antwort generiert wird.
Nein. Mehrere Modelle können die Leistung bei komplexen Aufgaben verbessern, erhöhen aber den Token-Verbrauch, die Rechenkosten und die Latenz. Einfache Aufgaben eignen sich besser für das Routing zu einem einzelnen, leichten Modell.
Das vollständige SD200 verwendet ein 64-Beschleuniger-Skalierungsdomäne für extrem große Workloads, während die SD200 Enterprise Edition das Domäne auf 16 Beschleuniger reduziert und sich an Unternehmen richtet, die lokale Billionen-Parameter-Modelle mit einer geringeren Infrastrukturschwelle bereitstellen möchten.
DeepSeek: KI-Modellanbieter, dessen Open-Source-Modell in die SD200-Kompatibilitätsliste aufgenommen wurde.
Die Ankündigung von Inspur auf der OCTS 2026 befasst sich mit zwei zentralen Problemen, die durch Unternehmens-Agenten verursacht werden.
CPU-native Flüssigkeitskühlungs-Racks konzentrieren sich auf Skalierbarkeit und bieten eine intensive Umgebung für Agentenplanung, Tools, Sandboxen, Kontextmanagement und langlaufende Prozesse. SD200 und EPA Multi-Modell-Fusions-Workflows fokussieren auf Intelligenz und ermöglichen die Zusammenarbeit mehrerer großer Modelle bei komplexen Aufgaben, wobei das Prüfmodell die Ergebnisse integriert.
Die weiterreichende Erkenntnis lautet: KI-Agenten-Infrastruktur kann nicht auf einen einzelnen schnelleren Beschleuniger reduziert werden. Produktionssysteme müssen die Koordination von CPU, GPU, Speicher, Interconnects, Kühlung, Orchestrierung, Berechtigungen und Bewertung sicherstellen.
Der zentrale Maßstab für KI-Agenten-Infrastruktur verschiebt sich von der Leistung eines einzelnen Modells hin zur Frage, ob das gesamte System Tausende von Agenten effizient orchestrieren und kontinuierlich zuverlässige Ergebnisse liefern kann.
Starte mit einem Satz und erhalte in wenigen Minuten eine vollständige Website.
