Inspur baut Agenten-Infrastruktur auf: 40.000 Agenten pro Rack mit Multimodell-Koordination

Einleitung

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:

1. CPU-native, flüssigkeitsgekühlte Rack-Server, die dafür ausgelegt sind, in einem einzigen Rack über 40.000 gleichzeitige Agenten zu unterstützen.
2. Die Kombination des MetaBrain SD200 Supernodes mit der EPAI Multi-Modell-Fusions-API, die es mehreren großen Sprachmodellen ermöglicht, für komplexe Aufgaben Antworten zu generieren, zu prüfen und zu kombinieren.

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.

Unterschiedliche infrastrukturelle Herausforderungen durch Agenten-Workloads

Die herkömmliche Inferenz großer Sprachmodelle folgt in der Regel einem einfachen Muster:

1. Der Benutzer sendet eine Anfrage.
2. Das Modell führt die Inferenz durch.
3. Das System gibt eine Antwort zurück.
4. Die Sitzung endet oder wartet auf die nächste Anfrage.

Der Ausführungspfad einer Agentenanwendung ist jedoch wesentlich länger.

Eine einzelne geschäftliche Aufgabe kann Folgendes umfassen:

• Planung
• Aufgabenzerlegung
• Abruf
• Werkzeugaufruf
• Codeausführung
• Berechtigungsprüfung
• Sandbox-Prozesse
• Mehrstufige Inferenz
• Koordination von Sub-Agenten
• Ausgabeprüfung
• Ergebnisaggregation
• Langzeit-Zustandsverwaltung

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.

GPU erzeugt Tokens

GPUs sind in den folgenden Bereichen unverzichtbar:

• Inferenz großer Sprachmodelle
• Prefill und Decode
• Embedding-Generierung
• Multimodale Verarbeitung
• Hochdurchsatz-Token-Produktion
• Parallele Modellausführung

CPU betreibt die Agent-Umgebung

Die CPU erledigt einen Großteil der peripheren Arbeit:

• Prozess-Scheduling von Agenten
• Werkzeugaufruf
• Kontext- und Statusverwaltung
• Interaktion mit Geschäftssystemen
• Sandbox-Ausführung
• Netzwerk- und Speicheroperationen
• Authentifizierung und Autorisierung
• Workflow-Koordination
• Ergebnisaufbereitung

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.

Warum die CPU-Dichte immer wichtiger wird

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.

Ein Rack kann über 40.000 Agenten unterstützen

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.

Erweiterung von CPU-Kühlplatten auf die Kühlung aller Komponenten

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:

• CPU
• Arbeitsspeicher
• Netzwerkkarten
• Optische Module
• Solid-State-Laufwerke (SSDs)
• Kommunikationskomponenten

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)

Kompakte Recheneinheit

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:

• Große Lüfter
• Luftkanäle
• Kühlleitungen
• Interne Kabel
• Herkömmliche Server-Tabletts

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.

Warum OCM wichtig ist

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:

• Mehr Hardware-Auswahl
• Einfachere Plattform-Upgrades
• Weniger Redundanz im Design
• Bessere Kompatibilität mit x86- und Arm-Architekturen
• Verlängerte Lebensdauer der Rack-Infrastruktur

Die tatsächliche Wirksamkeit hängt von der Ökosystem-Kompatibilität, Interoperabilität und Verfügbarkeit der zugehörigen Komponenten ab.

Größe ist nicht gleich Intelligenz

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:

• Logisches Denken
• Code-Erstellung
• Analyse langer Texte
• Technische Forschung
• Natürliches Schreiben
• Strukturierte Extraktion
• Mehrsprachige Aufgaben

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.

Mehrere Modelle bearbeiten gemeinsam dieselbe Aufgabe

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:

• Gemeinsame Schlussfolgerungen
• Widersprüchliche Aussagen
• Fehlende Informationen
• Einzigartige Erkenntnisse

Nicht unterstützte Aussagen:

• Bereiche, die Koordination erfordern

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:

1. Kandidatengenerierung
2. Modellübergreifende Prüfung
3. Analyse von Unterschieden und Auslassungen
4. Fusion zur endgültigen Ausgabe

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.

Einfache Aufgaben verwenden weiterhin ein einzelnes Modell

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.

Aufgaben, die für ein einzelnes Modell geeignet sind

Leichte Modelle sind möglicherweise ausreichend für:

• Einfache Frage-Antwort-Aufgaben
• Formatkonvertierung
• Basis-Extraktion
• Klassifizierungsaufgaben
• Kurze Tool-Aufrufe
• Routinemäßige Inhaltskonvertierung

Aufgaben, die eher für die Multi-Modell-Fusion geeignet sind

Mehrere Modelle könnten nützlich sein für:

• Tiefgehende Recherche
• Technische Vergleiche
• Architekturanalyse
• Komplexe Planung
• Lange Text-Inferenz
• Kritische Prüfungen
• Aufgaben mit unklaren Beweisen
• Ausgaben, die unabhängige Verifizierung erfordern

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.

EPAI Multi-Modell-Fusion-Workflow

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:

• Auswahl der Kandidatenmodelle
• Parallele Aufgabenverteilung
• Sammlung von Antworten
• Ausführung des Bewertungsmodells
• Analyse von Unterschieden
• Generierung der endgültigen Antwort

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:

• Open-Source-Modelle
• Proprietäre Modelle
• Allgemeine Modelle
• Domänenspezifische Modelle
• Lokal bereitgestellte Modelle
• Cloud-API-Modelle

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.

MetaBrain SD200 als Token-Engine

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:

• OCM- und OAM-Open-Computing-Architektur
• 3D-Mesh-Interconnect
• Einheitliche Beschleunigeradressierung
• Hochgeschwindigkeits-Peer-to-Peer-Kommunikation
• Großer gemeinsam genutzter Speicher

Fähigkeiten

• Unterstützung mehrerer Modelle mit Billionen Parametern
• Software-Hardware-Co-Design

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.

Token-Generierungszeit von 4,77 Millisekunden in Inspur-Tests

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.

Multi-Token-Vorhersage

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.

W4A8-Quantisierung

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:

• Speicherbandbreitenbedarf
• Beschleunigerspeichernutzung
• Rechenanforderungen
• Inferenzkosten pro Token

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.

Just-in-Time-Kernel-Kompilierung

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.

Prefill-Decode-Trennung

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.

Modellkompatibilität

Inspur gibt an, dass der SD200 die Leistungsoptimierung für mehrere gängige Open-Source-Modelle abgeschlossen hat, darunter:

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

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.

Enterprise Edition senkt die Einstiegshürde für die Bereitstellung

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:

• Einheitliches Verbindungsdomäne mit 16 Beschleunigern
• Native Speichersemantik-Kommunikation
• Einheitliche Adressierung
• Terabyte-großer, einheitlicher Beschleunigerspeicher
• Über 40 % schnellere Time-to-First-Token für Billionen-Parameter-Inferenz
• Native Unterstützung führender Open-Source-Billionen-Parameter-Modelle
• Geringere Migrations- und Anpassungskosten im Vergleich zum vollständigen SD200-System

Diese Enterprise Edition ist für die folgenden Workloads konzipiert:

• Verständnis langer Dokumente
• Komplexes logisches Denken
• Bereitstellung privater Modelle
• Multi-Agenten-Kollaboration
• Interne Forschung
• Sensitive Geschäftsanwendungen

Es bietet einen kleineren Einstiegspunkt für Organisationen, die eine lokale Modellkontrolle benötigen, aber den 64-Beschleuniger-Supernode nicht rechtfertigen können.

Die Infrastruktur wird integrierter

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:

• Wie viele Agentenprozesse können online gehalten werden?
• Wie schnell rufen sie Modelle und Werkzeuge auf?
• Können mehrere Modelle gleichzeitig ausgeführt werden?
• Wie wird der Speicher gemeinsam genutzt oder isoliert?
• Wie werden Berechtigungen durchgesetzt?
• Kann die Plattform einfache und komplexe Aufgaben unterschiedlich routen?
• Bleibt das System unter hoher Auslastung und Parallelität stabil?
• Wie effizient generiert es nützliche Token?

Was Unternehmen vor der Bereitstellung bewerten sollten

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.

1. Agentenparallelität

Zählen Sie nicht nur die aktiven Benutzer, sondern auch:

• Sub-Agenten pro Aufgabe
• Werkzeugprozesse
• Sandboxes
• Hintergrundjobs
• Beständige Sitzungen
• Lastspitzen
• Fehlerbehebungsprozesse

2. CPU und Speicher pro Agent

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.

3. Modell-Latenz

Es ist zu messen:

• Time-to-First-Token
• Token-zu-Token-Latenz
• End-to-End-Aufgabenzeit
• Wartezeit in der Warteschlange
• Werkzeugaufruf-Latenz
• Latenz unter Parallelität

Niedrige Token-Generierungszeiten in Benchmarks garantieren keine niedrige Latenz für End-to-End-Workflows.

4. Multi-Modell-Ökonomie

Die Fusion mehrerer Modelle kann die Qualität verbessern, aber zu einem exponentiellen Anstieg der Inferenzkosten führen.

Teams sollten vergleichen:

• Genauigkeit Einzelmodell
• Genauigkeit Fusionsmodell
• Verbrauchte Token
• GPU-Auslastung
• Antwortzeit
• Kosten des Überprüfungsmodells
• Fehlerrate
• Reduzierung manueller Überprüfungen

5. Kühlungs- und Infrastrukturkompatibilität

Native Flüssigkeitskühlungs-Racks benötigen eine passende Anlageninfrastruktur.

Es ist zu prüfen:

• Kühlmittelverteilereinheit
• Vor- und Rücklauftemperatur
• Druck- und Durchflussanforderungen
• Leckageerkennung
• Wartungsprozesse
• Abwärmerückgewinnungslösungen
• Stromversorgungskapazität des Racks
• Bodenbelastbarkeit des Rechenzentrums

6. Modell- und Beschleuniger-Portabilität

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:

• Modell-Framework
• Inferenz-Engine
• Quantisierungsunterstützung
• Kernel-Verfügbarkeit
• Treiber-Reife
• Überwachungstools
• Beschleuniger-Austausch
• Upgrade-Prozess

7. Zuverlässigkeit und Governance

Langlaufende Agenten benötigen eine starke Kontrolle über:

• Identitätsauthentifizierung
• Berechtigungseinstellungen
• Schlüsselverwaltung
• Netzwerkzugriff
• Sandbox-Umgebungen
• Prüfprotokolle
• Ratenbegrenzung
• Manuelle Genehmigung
• Modell-Routing
• Datenaufbewahrung

Die Dichte der Infrastruktur sollte nicht auf Kosten der Betriebsisolation gehen.

Häufig gestellte Fragen (FAQ)

Was ist das CPU-native Flüssigkeitskühlungs-Agenten-Rack von Inspur?

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.

Kann ein Rack wirklich 40.000 KI-Agenten ausführen?

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.

Warum brauchen KI-Agenten so viele CPUs?

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.

Was ist OCM 2.0?

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.

Was ist das MetaBrain SD200?

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.

Was ist die EPAI Multi-Modell-Fusions-API?

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.

Ist die Fusion mehrerer Modelle immer besser als ein einzelnes Modell?

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.

Was ist der Unterschied zwischen dem SD200 und dem SD200 Enterprise?

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.

Verwandte Werkzeuge

• Inspur EPA Enterprise-KI-Plattform: Unterstützt Modellverwaltung, Anwendungsentwicklung, Suche, Bereitstellung und Multi-Modell-Workflows.
• Inspur Flüssigkeitskühlungslösungen: Infrastrukturlösungen für den Einsatz flüssigkeitsgekühlter CPU/GPU-Server.
• Open Compute Project: Eine Industriegemeinschaft zur Entwicklung offener Hardwaredesigns für Server, Racks, Stromversorgung, Kühlung und Rechenzentren.
• Kimi: Eine Assistenten- und Modellplattform von Moonshot AI, deren Optimierungsergebnisse im Inspur SD200 zitiert werden.

DeepSeek: KI-Modellanbieter, dessen Open-Source-Modell in die SD200-Kompatibilitätsliste aufgenommen wurde.

Verwandte Links

• Inspur-Ankündigung zur KI-Agenten-Infrastruktur: Offizielle Veröffentlichung zu flüssigkeitsgekühlten CPU-Racks, SD200 und unternehmensweiten Superknoten.
• MetaBrain SD200 4,77ms Leistungsankündigung: Technischer Überblick von Inspur zur SD200-Optimierung und den Ergebnissen der Token-Generierung.
• EPA Multi-Modell-Fusions-API: Offizielle Erläuterung zu Kandidatengenerierung, Prüfung, Fusionsmechanismus und DRACO-Bewertung.
• Inspur EPA-Produktseite: Produktinformationen zur unternehmensweiten großen Modell-Entwicklungsplattform.
• Inspur-Lösung für flüssigkeitsgekühlte Rechenzentren: Offizielle Informationen zur Implementierung flüssigkeitsgekühlter Rechenzentren.
• Open Computing Technology Summit 2026: OCTS 2026 Veranstaltungsseite und verwandte Open-Source-Computing-Ankündigungen.
• Open Compute Project Foundation: Offizielle Informationen zu offenen Infrastrukturstandards und Community-Projekten.

Zusammenfassung

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.