Am 3. September hat OpenAI GPT-6 Astra vorgestellt, am 8. September hat XPeng in Guangzhou die Produktionslinie für seinen Humanoiden IRON in Betrieb genommen. Beide Ereignisse wurden als Beleg dafür gelesen, wie schnell künstliche Intelligenz derzeit vorankommt. Für Fertigungsbetriebe ist die interessantere Beobachtung eine andere: Die beiden Systeme legen die Intelligenz an völlig verschiedene Orte, und die Konsequenzen daraus sind operativ, nicht philosophisch.

Die Maschine denkt selbst

XPeng fertigt IRON auf einer Linie, deren Kernprozesse nach Unternehmensangaben zu über 80 Prozent automatisiert sind und auf Automobilqualität ausgelegt wurden. Der Roboter verfügt über 76 Freiheitsgrade, davon 21 pro Hand, und über drei hauseigene Turing-KI-Chips mit einer Rechenleistung von bis zu 2.250 TOPS. Auf dieser Hardware läuft XPengs Foundation Model für Physical AI direkt im Gerät. Die Serienfertigung ist zum Jahresende angepeilt, kommerzielle Auslieferungen in China und im Ausland sollen 2027 folgen.

Die Zahl, auf die es ankommt, ist nicht die Zahl der Freiheitsgrade, sondern die Rechenleistung an Bord. XPeng baut keinen Roboter, der eine Verbindung braucht, um zu handeln. Er trägt sein Modell mit sich, und das ist eine bewusste und teure Entscheidung: Siliziumfläche, Kühlung und Energie im Gerät kosten Geld und Gewicht, das an anderer Stelle fehlt.

Das Rechenzentrum denkt mit

Astra steht für das Gegenmodell. OpenAI beschreibt das Modell als Stand der Technik bei der Bedienung von Computern, beim Software Engineering, in wissenschaftlicher und professioneller Arbeit sowie bei mehrstufigen Arbeitsabläufen, in denen es Aufgabengrenzen und Nutzerabsichten zuverlässiger einhält als die Vorgängergeneration. Nach Angaben des Unternehmens stammt es aus dem bislang größten Trainingslauf, erstmals auf mehr als 100.000 GPUs. Es verarbeitet über eine Million Token Kontext. Und es erreicht in der internen Risikoeinstufung von OpenAI die kritische Schwelle im Bereich Cybersicherheit, weshalb die öffentlich verfügbare Version bestimmte sicherheitsrelevante Aufgaben verweigert.

Diese Fähigkeiten existieren ausschließlich im Rechenzentrum. Sie sind nicht in eine Maschine zu bekommen, und sie werden pro Vorgang abgerechnet: Der API-Preis liegt bei zehn US-Dollar je Million Eingabe-Token und 50 US-Dollar je Million Ausgabe-Token. Das ist keine Anschaffung, sondern eine variable Größe, die mit der Nutzung wächst.

Warum das keine Leistungsfrage ist

Der Reflex, beide Ansätze auf einer Skala zu vergleichen und zu fragen, welcher schlauer ist, führt in die Irre. Sie unterscheiden sich in vier Eigenschaften, die in der Produktion schwerer wiegen als jeder Benchmark.

Die Reaktionszeit: Ein Greifvorgang, eine Kollisionsvermeidung oder eine Nahtführung tolerieren keine Netzlatenz. Alles, was im Takt einer Maschine entschieden wird, muss lokal entschieden werden. Alles, was im Takt einer Schicht oder eines Auftrags entschieden wird, kann warten.

Der Datenabfluss: Ein Modell im Rechenzentrum sieht, was man ihm schickt. Bei Konstruktionsständen, Rezepturen und Prüfprotokollen ist das eine vertragliche und regulatorische Frage, keine technische. Ein Modell im Gerät sieht alles und gibt nichts weiter.

Das Ausfallverhalten: Ein lokal rechnendes System degradiert, wenn die Verbindung abreißt, ein cloudgestütztes steht. Für eine Linie, die nicht stehen darf, ist das der entscheidende Unterschied, und er bestimmt, was überhaupt als Rückfallebene taugt.

Das Kostenmodell: On-Device-Intelligenz ist eine Investition mit bekannter Höhe und langer Abschreibung. Cloud-Intelligenz ist ein laufender Posten, der proportional zur Nutzung wächst. Wer eine Anwendung skalieren will, sollte wissen, welche der beiden Kurven er dabei entlangläuft.

Eine brauchbare Entscheidungsregel

Für die meisten Betriebe wird die Antwort nicht ein Ort sein, sondern zwei. Sinnvoll ist eine Trennung nach Taktzeit: Was innerhalb von Millisekunden bis Sekunden entschieden werden muss, gehört ins Gerät, mit einem Modell, das klein genug für die verfügbare Hardware ist. Was innerhalb von Minuten bis Stunden entschieden wird, also Planung, Diagnose, Dokumentation, Angebotskalkulation, Fehleranalyse über mehrere Anlagen hinweg, gehört in die Cloud, weil dort die Fähigkeiten sitzen, die man lokal nicht bezahlen kann.

Die Schnittstelle zwischen beiden Ebenen ist der Teil, der in der Praxis am häufigsten unterschätzt wird. Sie entscheidet, welche Daten das Werk verlassen, wie oft das lokale Modell aktualisiert wird und was passiert, wenn die obere Ebene nicht antwortet. Wer diese Schnittstelle sauber definiert, kann Anbieter auf beiden Ebenen wechseln. Wer sie einem Anbieter überlässt, hat sich für beide Ebenen zugleich entschieden.

Guangzhou und San Francisco haben in derselben Woche gezeigt, dass beide Wege gangbar sind. Die Aufgabe der Industrie besteht nicht darin, sich für einen zu entscheiden, sondern darin, die Grenze zwischen ihnen selbst zu ziehen, bevor es ein Lieferant tut.