Du sprichst eine Frage ins Smartphone, lädst ein Foto hoch oder lässt einen Text zusammenfassen. Wenige Sekunden später liefert die App ein Ergebnis. Auf dem Display sieht das nach einem Fingertipp aus. Hinter den Kulissen ist eher Schichtbetrieb.
Denn eine KI-App besteht selten nur aus dem Modell, das Text, Bilder oder Sprache verarbeitet. Zur eigentlichen Berechnung kommen Datenübertragung, Sicherheitsprüfungen, Vorverarbeitung, Speicherzugriffe und die Ausgabe an das Handy. Ein Teil davon kann direkt auf dem Gerät laufen. Für größere Modelle oder viele gleichzeitige Nutzer übernehmen meist Inferenz-Server die Rechenarbeit.
Wer eine KI-Funktion entwickelt oder in eine bestehende App integriert, sollte deshalb nicht allein über das Modell sprechen. Ebenso wichtig sind Antwortzeit, Auslastung, Datenschutz, Energiebedarf und die Frage, ob eigene Hardware, gemietete Systeme oder Cloud-Ressourcen zum Einsatz kommen.
Bild: Bei vielen KI-Apps wird die Anfrage an einen Inferenz-Server übertragen, von leistungsfähiger GPU-Infrastruktur berechnet und anschließend an das Smartphone zurückgesendet.
Zwischen einer Eingabe und der fertigen Antwort liegen mehrere technische Stationen. Der genaue Ablauf hängt von der Funktion ab, folgt aber häufig diesem Muster:
Gerade das Streaming kann eine KI-App schneller wirken lassen, obwohl die vollständige Berechnung noch läuft. Bei einem Chat zählt daher nicht nur die Gesamtdauer. Auch die Zeit bis zum ersten sichtbaren Wort und das Tempo der weiteren Ausgabe prägen das Nutzungserlebnis.
Eine KI-Funktion muss nicht automatisch in einem großen Rechenzentrum laufen. Moderne Smartphones besitzen spezialisierte Recheneinheiten, mit denen kompakte Modelle direkt auf dem Gerät arbeiten können. Typische Einsatzbereiche sind Bildverbesserung, Spracherkennung, Texterkennung oder kleine Assistenzfunktionen. Einen Überblick über bereits verbreitete Beispiele findest du in unserem Beitrag über KI-Funktionen auf dem Smartphone.
On-Device-Verarbeitung eignet sich besonders, wenn eine Funktion ohne Netz verfügbar sein soll oder sensible Rohdaten das Smartphone möglichst nicht verlassen sollen. Dafür muss das Modell zur Hardware, zum Arbeitsspeicher und zum Energieprofil der unterstützten Geräte passen. Die Leistung unterscheidet sich zudem von Smartphone zu Smartphone. Wie lokale Modelle unter Android verwaltet werden können, zeigt unser Beitrag zu Android AICore und lokal gespeicherten KI-Modellen.
Serverseitige Inferenz verschiebt diese Grenzen. Das Unternehmen kann größere Modelle einsetzen, Kapazität bündeln und Aktualisierungen zentral ausrollen. Dafür kommen Übertragungszeit, Netzschwankungen und der Betrieb einer belastbaren Backend-Infrastruktur hinzu. Hybride Apps nutzen beide Wege, etwa eine lokale Vorverarbeitung und einen Server für die aufwendige Generierung.
Sobald eine KI-Funktion dauerhaft serverseitig oder hybrid arbeitet, muss die Hardware zu Modell, Anfragevolumen und gewünschter Antwortzeit passen. Unternehmen, die dafür einen Server kaufen und nach Workload konfigurieren möchten, können Happyware als Integrator für Server-, GPU- und KI-Infrastruktur einbeziehen. Happyware betreibt dabei keine Cloud oder Hosting-Plattform; die technische Auslegung richtet sich nach dem vorgesehenen System und dessen Einsatzumgebung.
Beim Training lernt ein KI-Modell aus großen Datenmengen. Dabei werden seine Parameter über viele Rechendurchläufe angepasst. Das beansprucht häufig über längere Zeit viel Rechenleistung, Speicherbandbreite und schnellen Datenspeicher. Auch Fine-Tuning verändert Modellparameter und gehört damit grundsätzlich auf die Trainingsseite, selbst wenn Umfang und Ressourcenbedarf geringer ausfallen können.
Inferenz bezeichnet die Nutzung eines bereits trainierten Modells, um aus neuen Eingaben eine Ausgabe zu berechnen. Jede Chatantwort, Bildanalyse oder Transkription in einer App ist ein solcher Inferenzvorgang. Die Parameter bleiben dabei üblicherweise unverändert.
Diese Trennung ist für die Infrastrukturplanung wichtig. Ein Trainingssystem wird oft für lang laufende, stark parallele Rechenjobs ausgelegt. Ein Inferenz-Server muss dagegen viele einzelne Anfragen zuverlässig bedienen und vorgegebene Antwortzeiten einhalten. Derselbe Beschleuniger kann für beide Aufgaben geeignet sein, doch Speicherbedarf, Auslastungsmuster, Software und Betriebsziele unterscheiden sich.
Die Frage nach dem passenden Server beginnt nicht bei einer GPU, sondern bei einem möglichst genauen Lastprofil. Zwei Apps können dasselbe Modell nutzen und trotzdem völlig andere Anforderungen haben. Eine interne Anwendung mit wenigen langen Dokumenten verhält sich anders als ein öffentlicher Chat mit tausenden kurzen Anfragen. Bei Bild- und Video-KI verändern Auflösung, Länge und Anzahl der Verarbeitungsschritte die Last zusätzlich.
Für die Auslegung sollten Unternehmen mindestens diese Punkte erfassen:
Bei großen Sprachmodellen wird der verfügbare GPU-Speicher oft zur ersten Hürde. Neben den Modellgewichten belegen der Kontext mehrerer Sitzungen, Zwischenergebnisse und die Laufzeitumgebung zusätzlichen Speicher. Quantisierung kann den Bedarf senken, kann aber je nach Methode die Qualität, Geschwindigkeit oder Softwarekompatibilität beeinflussen. Eine pauschale Regel wie eine bestimmte Modellgröße brauche immer eine bestimmte Anzahl GPUs greift deshalb zu kurz.
Auch die gewünschte Latenz verändert die Rechnung. Dynamisches Batching kann mehrere Anfragen gemeinsam verarbeiten und dadurch den Durchsatz erhöhen. Das Sammeln wartet jedoch für einen konfigurierten Zeitraum auf passende Anfragen. Eine App mit strenger Echtzeitanforderung benötigt daher möglicherweise eine andere Batch-Strategie als eine Hintergrundverarbeitung, bei der einige zusätzliche Sekunden kaum stören.
Belastbare Kapazitätswerte entstehen in Tests mit dem eigenen Modell, der vorgesehenen Laufzeit und realistischen Eingaben. Synthetische Spitzenwerte helfen wenig, wenn die Produktion längere Prompts, andere Zahlenformate oder zusätzliche Sicherheitsprüfungen verwendet. Als neutrale Referenz für standardisierte Messmethoden können die MLCommons Inference Benchmarks dienen. Die konkrete Beschaffung sollte dennoch auf eigenen Lasttests beruhen.
Nicht jede KI-App braucht einen Server mit mehreren Beschleunigern. Kleine Klassifikations-, Such- oder Vorhersagemodelle können auf CPUs wirtschaftlich laufen, sofern Latenz und Durchsatz zum Nutzungsszenario passen. Ein CPU-System ist außerdem nützlich für Vorverarbeitung, Datenbanken und Aufgaben, die sich kaum auf einem Beschleuniger parallelisieren lassen.
Für generative Modelle, Bildverarbeitung oder hohe Parallelität kommen häufig GPU-Server oder andere Accelerator-Systeme infrage. Ein einzelner Beschleuniger kann für einen Prototyp oder ein kompaktes Modell genügen. Größere Modelle lassen sich je nach Software über mehrere Beschleuniger innerhalb eines Servers verteilen. Steigt die Last darüber hinaus, verteilen mehrere Server Anfragen oder Modellteile über ein Cluster.
Edge-Server stehen näher am Nutzer oder an einer Datenquelle. Sie können Übertragungswege verkürzen und lokale Datenverarbeitung ermöglichen, bieten jedoch meist weniger Platz, Strom und Kühlung als ein zentraler Serverraum. Für Filialen, Produktionsstandorte oder regionale App-Dienste kann das sinnvoll sein. Der Vorteil muss gegen Wartungsaufwand und verteilte Kapazitätsreserven gerechnet werden.
Zur Plattformwahl gehören neben den Recheneinheiten das Chassis, CPU-Sockel, Arbeitsspeicher, Erweiterungssteckplätze, lokale Datenträger, Netzwerkanschlüsse und Netzteile. Auch Firmware, Treiber, Modellformat und Inferenzsoftware müssen zusammenpassen. Eine nicht abgestimmte Plattform kann die nutzbare Leistung begrenzen oder spätere Erweiterungen verhindern.
Eine KI-Anfrage durchläuft eine Kette aus App, Netzwerk, API, Datenaufbereitung, Modellserver und Ausgabe. Die wahrgenommene Geschwindigkeit richtet sich nach dem langsamsten oder überlasteten Teil dieser Kette. Selbst eine leistungsfähige GPU bleibt teilweise ungenutzt, wenn CPU, Arbeitsspeicher, Massenspeicher oder Netzwerk nicht nachkommen.
Die CPU übernimmt häufig Authentifizierung, Tokenisierung, Bilddekodierung und die Steuerung des Modellservers. Reicht ihre Leistung nicht aus, sinkt die Auslastung der teuren Beschleuniger. Zu wenig Arbeitsspeicher führt zu Engpässen beim Laden von Modellen, beim Caching oder bei mehreren parallelen Diensten. Schnelle NVMe-Datenträger verkürzen Modellstarts und versorgen datenintensive Abläufe; sie ersetzen aber keinen ausreichend dimensionierten RAM oder GPU-Speicher.
Das Netzwerk ist sowohl innerhalb eines Servers als auch zwischen mehreren Systemen relevant. Werden Modellteile über mehrere GPUs oder Knoten verteilt, müssen große Datenmengen mit niedriger Verzögerung übertragen werden. Für eine App mit zentralem Inferenzdienst zählt außerdem die Verbindung zwischen Nutzern, API und Rechenstandort. Eine zusätzliche Region kann die Netzlatenz senken, erhöht jedoch den Aufwand für Datenhaltung, Auslieferung und Überwachung.
Zur Gesamtarchitektur gehören außerdem:
Reserven sollten nicht als pauschaler Prozentsatz angesetzt werden. Ein Dienst mit vorhersehbarer Bürozeiten-Last benötigt andere Spielräume als eine App, die nach einer Produktvorstellung plötzlich stark wächst. Auch Redundanz verändert die nutzbare Kapazität: Ein System kann rechnerisch ausgelastet sein und dennoch zu klein ausfallen, wenn beim Ausfall eines Knotens die übrigen Server die Last nicht übernehmen können.
Mit zunehmender Rechenleistung steigen elektrische Anschlussleistung und Abwärme. Vor der Bestellung eines GPU-Servers muss daher geklärt sein, welche Leistung ein Rack dauerhaft aufnehmen kann, wie Stromkreise abgesichert sind und ob redundante Versorgung, USV und passende Stromverteilung vorhanden sind. Die Herstellerangabe zum maximalen Verbrauch ist dabei nur ein Ausgangspunkt; auch Lastverlauf, Netzteileffizienz und weitere Komponenten gehören in die Berechnung.
Die Kühlung muss diese Wärme kontinuierlich abführen. Luftgekühlte Systeme benötigen passende Luftführung, ausreichenden Volumenstrom und freie Wege für Zu- und Abluft. Hohe Leistungsdichten können die Grenzen eines vorhandenen Serverraums erreichen, obwohl im Rack noch Höheneinheiten frei sind. Die Physik lässt sich leider nicht mit dem nächsten App-Update erweitern.
Bei Flüssigkühlung sind zwei Verfahren sauber zu unterscheiden:
DLC und Immersion Cooling sind somit keine austauschbaren Bezeichnungen. Welche Kühlung passt, hängt von Leistungsdichte, Gebäudeinfrastruktur, Wartungskonzept und eingesetzter Hardware ab. Auch Racktiefe, Gewicht, Geräusch, Zugangskontrolle, Leckageerkennung und Servicewege sollten vor der Beschaffung geprüft werden. Offene Branchenhinweise zur Verbindung von KI-Hardware, Stromversorgung, Kühlung und Standortbedingungen bietet das AI Computing Continuum des Open Compute Project.
On-Premise bedeutet, dass das Unternehmen die Systeme in eigenen oder kontrollierten Räumen betreibt. Das ermöglicht weitreichende Kontrolle über Datenwege, Hardware und Wartungsfenster. Bei einer dauerhaft hohen, gut planbaren Auslastung kann eigene Infrastruktur sinnvoll sein. Dafür braucht es Personal, Strom, Kühlung, Ersatzteilkonzept und Kapazitätsplanung.
Cloud-Ressourcen lassen sich meist schneller bereitstellen und bei schwankender Last anpassen. Das eignet sich für Tests, neue Produkte oder saisonale Spitzen. Dem stehen variable Betriebskosten, Datenübertragung, Abhängigkeiten von verfügbaren Instanztypen und Vorgaben zur Datenverarbeitung gegenüber. Diese Punkte müssen anhand des Workloads, der Verträge und der regulatorischen Anforderungen bewertet werden.
Ein hybrides Modell verbindet beide Ansätze. Grundlast oder sensible Verarbeitung können auf eigenen Systemen laufen, während zusätzliche Kapazität zeitweise extern bereitsteht. Das verlangt kompatible Software, ein klares Routing und konsistente Sicherheitsregeln. Ohne diese Voraussetzungen steigen Betriebsaufwand und Fehlerquellen statt der erhofften Flexibilität.
Der passende Beschaffungsweg richtet sich nach Nutzungsdauer, Auslastung, Kapitalplanung und Änderungsrisiko. Beim Kauf gehört die Hardware dem Unternehmen. Das schafft Kontrolle über Konfiguration und Einsatzzeit, bindet aber Kapital und überträgt Betrieb, Wartung sowie das Risiko technischer Alterung an den Eigentümer.
Eine Hardwaremiete kann für Pilotprojekte, vorübergehende Kapazität oder einen noch unsicheren Workload passen. Sie darf nicht mit Cloud-Nutzung verwechselt werden: Gemietet wird ein physisches System für einen vereinbarten Zeitraum, nicht automatisch ein flexibel skalierbarer Online-Dienst.
Leasing verteilt die Zahlungen über eine festgelegte Laufzeit und kann geplante Erneuerungszyklen unterstützen. Vertragsdauer, Restwert, Rückgabezustand, Umbauten und Support müssen jedoch zur technischen Roadmap passen. Wenn sich Modellgröße oder Softwareanforderungen schneller ändern als der Vertrag, verliert die finanzielle Planbarkeit an Nutzen.
Für einen fairen Vergleich reicht der Anschaffungspreis nicht. In die Gesamtkosten gehören Finanzierung, Energie, Kühlung, Stellfläche, Administration, Support, Ausfallrisiken und spätere Erweiterungen. Cloud-Kosten sollten mit denselben Annahmen zu Auslastung, Verfügbarkeit und Datenübertragung gerechnet werden. Nur dann werden Kauf, Miete, Leasing und Cloud als Betriebsmodelle vergleichbar.
Eine tragfähige KI-Infrastruktur entsteht aus Messwerten, nicht aus einer möglichst beeindruckenden Komponentenliste. Zuerst werden Modell, Eingaben, Parallelität, Lastspitzen und Zielwerte für Antwortzeit und Verfügbarkeit beschrieben. Danach folgt ein Test mit der vorgesehenen Software. Erst seine Ergebnisse zeigen, welche Rechenleistung, welcher Speicher und welche Netzwerkanbindung erforderlich sind.
Vor einer Beschaffung sollten Produkt- und Technikteams deshalb gemeinsam prüfen:
So wird aus der abstrakten Frage nach KI-Leistung eine überprüfbare technische Planung. Die App erhält die Antwortzeit, die Nutzer erwarten, und das Unternehmen beschafft keine Hardware, deren stärkste Disziplin am Ende das Herumstehen ist.
Denn eine KI-App besteht selten nur aus dem Modell, das Text, Bilder oder Sprache verarbeitet. Zur eigentlichen Berechnung kommen Datenübertragung, Sicherheitsprüfungen, Vorverarbeitung, Speicherzugriffe und die Ausgabe an das Handy. Ein Teil davon kann direkt auf dem Gerät laufen. Für größere Modelle oder viele gleichzeitige Nutzer übernehmen meist Inferenz-Server die Rechenarbeit.
Wer eine KI-Funktion entwickelt oder in eine bestehende App integriert, sollte deshalb nicht allein über das Modell sprechen. Ebenso wichtig sind Antwortzeit, Auslastung, Datenschutz, Energiebedarf und die Frage, ob eigene Hardware, gemietete Systeme oder Cloud-Ressourcen zum Einsatz kommen.
Bild: Bei vielen KI-Apps wird die Anfrage an einen Inferenz-Server übertragen, von leistungsfähiger GPU-Infrastruktur berechnet und anschließend an das Smartphone zurückgesendet.
Was nach einer Anfrage in der KI-App passiert
Zwischen einer Eingabe und der fertigen Antwort liegen mehrere technische Stationen. Der genaue Ablauf hängt von der Funktion ab, folgt aber häufig diesem Muster:
- Die App erfasst die Eingabe. Das kann Text, Sprache, ein Bild, ein Video oder eine Kombination daraus sein. Zusätzlich sendet sie je nach Anwendung Informationen wie Sprache, Dateiformat oder Sitzungs-ID.
- Die Anfrage wird geprüft und weitergeleitet. Authentifizierung, Größenlimits und Sicherheitsregeln greifen, bevor ein Modell Rechenzeit erhält. Ein Router legt fest, ob die Verarbeitung lokal, auf einem Edge-System oder in einem Rechenzentrum stattfindet.
- Die Daten werden vorbereitet. Texte werden in Tokens zerlegt, Bilder skaliert und Audiodateien in passende Formate umgewandelt. Bei einer Wissenssuche können Dokumente oder Datenbankeinträge ergänzt werden.
- Das Modell führt die Inferenz aus. Es berechnet auf Basis seiner bereits gelernten Parameter eine Ausgabe. Bei einem Sprachmodell entstehen nacheinander neue Tokens, bei einem Bildmodell wird das Ergebnis in mehreren Rechenschritten erzeugt.
- Die Antwort wird aufbereitet. Filter, Formatierung, Komprimierung und Streaming sorgen dafür, dass das Resultat zur App passt und möglichst früh auf dem Display erscheint.
Gerade das Streaming kann eine KI-App schneller wirken lassen, obwohl die vollständige Berechnung noch läuft. Bei einem Chat zählt daher nicht nur die Gesamtdauer. Auch die Zeit bis zum ersten sichtbaren Wort und das Tempo der weiteren Ausgabe prägen das Nutzungserlebnis.
On-Device oder Server: Wo KI-Apps ihre Antworten berechnen
Eine KI-Funktion muss nicht automatisch in einem großen Rechenzentrum laufen. Moderne Smartphones besitzen spezialisierte Recheneinheiten, mit denen kompakte Modelle direkt auf dem Gerät arbeiten können. Typische Einsatzbereiche sind Bildverbesserung, Spracherkennung, Texterkennung oder kleine Assistenzfunktionen. Einen Überblick über bereits verbreitete Beispiele findest du in unserem Beitrag über KI-Funktionen auf dem Smartphone.
Betriebsart | Stärken | Grenzen | Sinnvoll bei |
| On-Device | geringe Netzlatenz, Offline-Nutzung, Daten bleiben eher auf dem Gerät | begrenzter Speicher, Akkuverbrauch, Wärmeentwicklung, kleinere Modelle | kompakten und häufig genutzten Funktionen |
| Serverseitig | größere Modelle, zentral steuerbare Updates, skalierbare Kapazität | Netzwerkabhängigkeit, Betriebskosten, Datenschutz- und Verfügbarkeitsanforderungen | rechenintensiven Funktionen und vielen Geräten |
| Hybrid | lokale Sofortfunktionen plus leistungsfähige Serververarbeitung | komplexere App-Logik, zwei Betriebsumgebungen, aufwendigere Tests | Funktionen mit unterschiedlichen Datenschutz- oder Leistungsstufen |
On-Device-Verarbeitung eignet sich besonders, wenn eine Funktion ohne Netz verfügbar sein soll oder sensible Rohdaten das Smartphone möglichst nicht verlassen sollen. Dafür muss das Modell zur Hardware, zum Arbeitsspeicher und zum Energieprofil der unterstützten Geräte passen. Die Leistung unterscheidet sich zudem von Smartphone zu Smartphone. Wie lokale Modelle unter Android verwaltet werden können, zeigt unser Beitrag zu Android AICore und lokal gespeicherten KI-Modellen.
Serverseitige Inferenz verschiebt diese Grenzen. Das Unternehmen kann größere Modelle einsetzen, Kapazität bündeln und Aktualisierungen zentral ausrollen. Dafür kommen Übertragungszeit, Netzschwankungen und der Betrieb einer belastbaren Backend-Infrastruktur hinzu. Hybride Apps nutzen beide Wege, etwa eine lokale Vorverarbeitung und einen Server für die aufwendige Generierung.
Sobald eine KI-Funktion dauerhaft serverseitig oder hybrid arbeitet, muss die Hardware zu Modell, Anfragevolumen und gewünschter Antwortzeit passen. Unternehmen, die dafür einen Server kaufen und nach Workload konfigurieren möchten, können Happyware als Integrator für Server-, GPU- und KI-Infrastruktur einbeziehen. Happyware betreibt dabei keine Cloud oder Hosting-Plattform; die technische Auslegung richtet sich nach dem vorgesehenen System und dessen Einsatzumgebung.
Inferenz ist nicht Training: Der Unterschied
Beim Training lernt ein KI-Modell aus großen Datenmengen. Dabei werden seine Parameter über viele Rechendurchläufe angepasst. Das beansprucht häufig über längere Zeit viel Rechenleistung, Speicherbandbreite und schnellen Datenspeicher. Auch Fine-Tuning verändert Modellparameter und gehört damit grundsätzlich auf die Trainingsseite, selbst wenn Umfang und Ressourcenbedarf geringer ausfallen können.
Inferenz bezeichnet die Nutzung eines bereits trainierten Modells, um aus neuen Eingaben eine Ausgabe zu berechnen. Jede Chatantwort, Bildanalyse oder Transkription in einer App ist ein solcher Inferenzvorgang. Die Parameter bleiben dabei üblicherweise unverändert.
Diese Trennung ist für die Infrastrukturplanung wichtig. Ein Trainingssystem wird oft für lang laufende, stark parallele Rechenjobs ausgelegt. Ein Inferenz-Server muss dagegen viele einzelne Anfragen zuverlässig bedienen und vorgegebene Antwortzeiten einhalten. Derselbe Beschleuniger kann für beide Aufgaben geeignet sein, doch Speicherbedarf, Auslastungsmuster, Software und Betriebsziele unterscheiden sich.
Aus einer KI-Anfrage wird ein messbarer Workload
Die Frage nach dem passenden Server beginnt nicht bei einer GPU, sondern bei einem möglichst genauen Lastprofil. Zwei Apps können dasselbe Modell nutzen und trotzdem völlig andere Anforderungen haben. Eine interne Anwendung mit wenigen langen Dokumenten verhält sich anders als ein öffentlicher Chat mit tausenden kurzen Anfragen. Bei Bild- und Video-KI verändern Auflösung, Länge und Anzahl der Verarbeitungsschritte die Last zusätzlich.
Für die Auslegung sollten Unternehmen mindestens diese Punkte erfassen:
- Modell und Zahlenformat: Parameterzahl, Architektur, Quantisierung und gewünschte Genauigkeit beeinflussen den Speicherbedarf und die unterstützte Hardware.
- Eingabe und Ausgabe: Bei Sprachmodellen zählen Kontextlänge sowie Eingabe- und Ausgabetokens. Bei Medienmodellen sind unter anderem Auflösung, Bildanzahl, Videodauer und Bildrate relevant.
- Anfrageprofil: Durchschnittliche und maximale Anfragen pro Sekunde reichen allein nicht. Parallelität, Tagesverlauf, Lastspitzen und die Dauer einzelner Jobs gehören ebenfalls ins Profil.
- Zielwerte der App: Zeit bis zur ersten Ausgabe, gesamte Antwortzeit und Durchsatz müssen getrennt betrachtet werden. Für Serviceziele sind beispielsweise der Median und ein hoher Perzentilwert wie p95 aussagekräftiger als ein einzelner Bestwert.
- Betriebsanforderungen: Verfügbarkeit, Datenhaltung, Mandantentrennung, Protokollierung und geplante Modellwechsel wirken sich auf Reserven und Architektur aus.
Bei großen Sprachmodellen wird der verfügbare GPU-Speicher oft zur ersten Hürde. Neben den Modellgewichten belegen der Kontext mehrerer Sitzungen, Zwischenergebnisse und die Laufzeitumgebung zusätzlichen Speicher. Quantisierung kann den Bedarf senken, kann aber je nach Methode die Qualität, Geschwindigkeit oder Softwarekompatibilität beeinflussen. Eine pauschale Regel wie eine bestimmte Modellgröße brauche immer eine bestimmte Anzahl GPUs greift deshalb zu kurz.
Auch die gewünschte Latenz verändert die Rechnung. Dynamisches Batching kann mehrere Anfragen gemeinsam verarbeiten und dadurch den Durchsatz erhöhen. Das Sammeln wartet jedoch für einen konfigurierten Zeitraum auf passende Anfragen. Eine App mit strenger Echtzeitanforderung benötigt daher möglicherweise eine andere Batch-Strategie als eine Hintergrundverarbeitung, bei der einige zusätzliche Sekunden kaum stören.
Belastbare Kapazitätswerte entstehen in Tests mit dem eigenen Modell, der vorgesehenen Laufzeit und realistischen Eingaben. Synthetische Spitzenwerte helfen wenig, wenn die Produktion längere Prompts, andere Zahlenformate oder zusätzliche Sicherheitsprüfungen verwendet. Als neutrale Referenz für standardisierte Messmethoden können die MLCommons Inference Benchmarks dienen. Die konkrete Beschaffung sollte dennoch auf eigenen Lasttests beruhen.
Vom kompakten Edge-System bis zum GPU-Cluster
Nicht jede KI-App braucht einen Server mit mehreren Beschleunigern. Kleine Klassifikations-, Such- oder Vorhersagemodelle können auf CPUs wirtschaftlich laufen, sofern Latenz und Durchsatz zum Nutzungsszenario passen. Ein CPU-System ist außerdem nützlich für Vorverarbeitung, Datenbanken und Aufgaben, die sich kaum auf einem Beschleuniger parallelisieren lassen.
Für generative Modelle, Bildverarbeitung oder hohe Parallelität kommen häufig GPU-Server oder andere Accelerator-Systeme infrage. Ein einzelner Beschleuniger kann für einen Prototyp oder ein kompaktes Modell genügen. Größere Modelle lassen sich je nach Software über mehrere Beschleuniger innerhalb eines Servers verteilen. Steigt die Last darüber hinaus, verteilen mehrere Server Anfragen oder Modellteile über ein Cluster.
Edge-Server stehen näher am Nutzer oder an einer Datenquelle. Sie können Übertragungswege verkürzen und lokale Datenverarbeitung ermöglichen, bieten jedoch meist weniger Platz, Strom und Kühlung als ein zentraler Serverraum. Für Filialen, Produktionsstandorte oder regionale App-Dienste kann das sinnvoll sein. Der Vorteil muss gegen Wartungsaufwand und verteilte Kapazitätsreserven gerechnet werden.
Zur Plattformwahl gehören neben den Recheneinheiten das Chassis, CPU-Sockel, Arbeitsspeicher, Erweiterungssteckplätze, lokale Datenträger, Netzwerkanschlüsse und Netzteile. Auch Firmware, Treiber, Modellformat und Inferenzsoftware müssen zusammenpassen. Eine nicht abgestimmte Plattform kann die nutzbare Leistung begrenzen oder spätere Erweiterungen verhindern.
Warum eine schnelle GPU allein noch keine schnelle KI-App ergibt
Eine KI-Anfrage durchläuft eine Kette aus App, Netzwerk, API, Datenaufbereitung, Modellserver und Ausgabe. Die wahrgenommene Geschwindigkeit richtet sich nach dem langsamsten oder überlasteten Teil dieser Kette. Selbst eine leistungsfähige GPU bleibt teilweise ungenutzt, wenn CPU, Arbeitsspeicher, Massenspeicher oder Netzwerk nicht nachkommen.
Die CPU übernimmt häufig Authentifizierung, Tokenisierung, Bilddekodierung und die Steuerung des Modellservers. Reicht ihre Leistung nicht aus, sinkt die Auslastung der teuren Beschleuniger. Zu wenig Arbeitsspeicher führt zu Engpässen beim Laden von Modellen, beim Caching oder bei mehreren parallelen Diensten. Schnelle NVMe-Datenträger verkürzen Modellstarts und versorgen datenintensive Abläufe; sie ersetzen aber keinen ausreichend dimensionierten RAM oder GPU-Speicher.
Das Netzwerk ist sowohl innerhalb eines Servers als auch zwischen mehreren Systemen relevant. Werden Modellteile über mehrere GPUs oder Knoten verteilt, müssen große Datenmengen mit niedriger Verzögerung übertragen werden. Für eine App mit zentralem Inferenzdienst zählt außerdem die Verbindung zwischen Nutzern, API und Rechenstandort. Eine zusätzliche Region kann die Netzlatenz senken, erhöht jedoch den Aufwand für Datenhaltung, Auslieferung und Überwachung.
Zur Gesamtarchitektur gehören außerdem:
- ein Load Balancer, der Anfragen auf verfügbare Instanzen verteilt
- Warteschlangen und Limits, die Lastspitzen kontrolliert abfangen
- Modellserver, die Batching, Speicherverwaltung und parallele Ausführung steuern
- Datenbanken oder Vektorsuchen, falls die App externe Wissensbestände einbindet
- Monitoring für Latenz, Fehlerrate, Auslastung, Temperatur und Energieverbrauch
Reserven sollten nicht als pauschaler Prozentsatz angesetzt werden. Ein Dienst mit vorhersehbarer Bürozeiten-Last benötigt andere Spielräume als eine App, die nach einer Produktvorstellung plötzlich stark wächst. Auch Redundanz verändert die nutzbare Kapazität: Ein System kann rechnerisch ausgelastet sein und dennoch zu klein ausfallen, wenn beim Ausfall eines Knotens die übrigen Server die Last nicht übernehmen können.
Strom, Kühlung und Serverraum gehören zur Konfiguration
Mit zunehmender Rechenleistung steigen elektrische Anschlussleistung und Abwärme. Vor der Bestellung eines GPU-Servers muss daher geklärt sein, welche Leistung ein Rack dauerhaft aufnehmen kann, wie Stromkreise abgesichert sind und ob redundante Versorgung, USV und passende Stromverteilung vorhanden sind. Die Herstellerangabe zum maximalen Verbrauch ist dabei nur ein Ausgangspunkt; auch Lastverlauf, Netzteileffizienz und weitere Komponenten gehören in die Berechnung.
Die Kühlung muss diese Wärme kontinuierlich abführen. Luftgekühlte Systeme benötigen passende Luftführung, ausreichenden Volumenstrom und freie Wege für Zu- und Abluft. Hohe Leistungsdichten können die Grenzen eines vorhandenen Serverraums erreichen, obwohl im Rack noch Höheneinheiten frei sind. Die Physik lässt sich leider nicht mit dem nächsten App-Update erweitern.
Bei Flüssigkühlung sind zwei Verfahren sauber zu unterscheiden:
- Direct Liquid Cooling: Kühlplatten liegen direkt auf besonders warmen Komponenten wie CPU oder GPU. Ein geschlossener Kreislauf transportiert die Wärme zu einer Verteil- und Kühleinheit. Der Server bleibt im Rack und wird nicht in Flüssigkeit eingetaucht. Je nach Aufbau benötigen Arbeitsspeicher, Spannungswandler oder andere Bauteile weiterhin Luftkühlung.
- Immersion Cooling: Dafür geeignete Elektronik wird in einem Tank in eine elektrisch nicht leitende, dielektrische Flüssigkeit eingetaucht. Die Flüssigkeit nimmt Wärme von vielen Bauteilen auf. Tanks, Kabel, Materialien, Wartungsabläufe und Brandschutz müssen für dieses Verfahren ausgelegt sein.
DLC und Immersion Cooling sind somit keine austauschbaren Bezeichnungen. Welche Kühlung passt, hängt von Leistungsdichte, Gebäudeinfrastruktur, Wartungskonzept und eingesetzter Hardware ab. Auch Racktiefe, Gewicht, Geräusch, Zugangskontrolle, Leckageerkennung und Servicewege sollten vor der Beschaffung geprüft werden. Offene Branchenhinweise zur Verbindung von KI-Hardware, Stromversorgung, Kühlung und Standortbedingungen bietet das AI Computing Continuum des Open Compute Project.
On-Premise oder Cloud: Wo die KI-Infrastruktur betrieben wird
On-Premise bedeutet, dass das Unternehmen die Systeme in eigenen oder kontrollierten Räumen betreibt. Das ermöglicht weitreichende Kontrolle über Datenwege, Hardware und Wartungsfenster. Bei einer dauerhaft hohen, gut planbaren Auslastung kann eigene Infrastruktur sinnvoll sein. Dafür braucht es Personal, Strom, Kühlung, Ersatzteilkonzept und Kapazitätsplanung.
Cloud-Ressourcen lassen sich meist schneller bereitstellen und bei schwankender Last anpassen. Das eignet sich für Tests, neue Produkte oder saisonale Spitzen. Dem stehen variable Betriebskosten, Datenübertragung, Abhängigkeiten von verfügbaren Instanztypen und Vorgaben zur Datenverarbeitung gegenüber. Diese Punkte müssen anhand des Workloads, der Verträge und der regulatorischen Anforderungen bewertet werden.
Ein hybrides Modell verbindet beide Ansätze. Grundlast oder sensible Verarbeitung können auf eigenen Systemen laufen, während zusätzliche Kapazität zeitweise extern bereitsteht. Das verlangt kompatible Software, ein klares Routing und konsistente Sicherheitsregeln. Ohne diese Voraussetzungen steigen Betriebsaufwand und Fehlerquellen statt der erhofften Flexibilität.
Server kaufen, mieten oder leasen
Der passende Beschaffungsweg richtet sich nach Nutzungsdauer, Auslastung, Kapitalplanung und Änderungsrisiko. Beim Kauf gehört die Hardware dem Unternehmen. Das schafft Kontrolle über Konfiguration und Einsatzzeit, bindet aber Kapital und überträgt Betrieb, Wartung sowie das Risiko technischer Alterung an den Eigentümer.
Eine Hardwaremiete kann für Pilotprojekte, vorübergehende Kapazität oder einen noch unsicheren Workload passen. Sie darf nicht mit Cloud-Nutzung verwechselt werden: Gemietet wird ein physisches System für einen vereinbarten Zeitraum, nicht automatisch ein flexibel skalierbarer Online-Dienst.
Leasing verteilt die Zahlungen über eine festgelegte Laufzeit und kann geplante Erneuerungszyklen unterstützen. Vertragsdauer, Restwert, Rückgabezustand, Umbauten und Support müssen jedoch zur technischen Roadmap passen. Wenn sich Modellgröße oder Softwareanforderungen schneller ändern als der Vertrag, verliert die finanzielle Planbarkeit an Nutzen.
Für einen fairen Vergleich reicht der Anschaffungspreis nicht. In die Gesamtkosten gehören Finanzierung, Energie, Kühlung, Stellfläche, Administration, Support, Ausfallrisiken und spätere Erweiterungen. Cloud-Kosten sollten mit denselben Annahmen zu Auslastung, Verfügbarkeit und Datenübertragung gerechnet werden. Nur dann werden Kauf, Miete, Leasing und Cloud als Betriebsmodelle vergleichbar.
KI-Server nach Workload und Betriebsumgebung planen
Eine tragfähige KI-Infrastruktur entsteht aus Messwerten, nicht aus einer möglichst beeindruckenden Komponentenliste. Zuerst werden Modell, Eingaben, Parallelität, Lastspitzen und Zielwerte für Antwortzeit und Verfügbarkeit beschrieben. Danach folgt ein Test mit der vorgesehenen Software. Erst seine Ergebnisse zeigen, welche Rechenleistung, welcher Speicher und welche Netzwerkanbindung erforderlich sind.
Vor einer Beschaffung sollten Produkt- und Technikteams deshalb gemeinsam prüfen:
- Welche Teile der KI-Funktion lokal, serverseitig oder hybrid laufen sollen
- Ob Inferenz, Fine-Tuning oder vollständiges Training vorgesehen ist
- Welche Last heute anfällt und welches Wachstum realistisch erwartet wird
- Wo CPU, GPU, Speicher, Datenträger und Netzwerk zum Engpass werden können
- Ob Stromversorgung, Kühlung und Serverraum zur geplanten Leistungsdichte passen
- Welches Betriebs- und Beschaffungsmodell die gewünschte Kontrolle und Flexibilität bietet
So wird aus der abstrakten Frage nach KI-Leistung eine überprüfbare technische Planung. Die App erhält die Antwortzeit, die Nutzer erwarten, und das Unternehmen beschafft keine Hardware, deren stärkste Disziplin am Ende das Herumstehen ist.