Intel Xeon Server für KI-Inferenz: Wann eine CPU ausreicht und wann eine GPU benötigt wird

Ein Intel-Xeon-Server kann für KI-Inferenz völlig ausreichend sein, wenn die Aufgabe mit Klassifizierung, Embeddings, Dokumentensuche, Datenextraktion, kleineren Sprachmodellen oder Batch-Verarbeitung ohne strenge Latenzanforderungen verbunden ist. Eine GPU ist nicht für jedes KI-Projekt erforderlich. Sie wird dann notwendig, wenn das Modell groß ist, viele Nutzer vorhanden sind, der Kontext lang ist, Antworten schnell generiert werden müssen und Ausfallzeiten oder Anfragewarteschlangen das Unternehmen mehr kosten als die Anschaffung eines Beschleunigers.

Inferenz bedeutet, ein bereits trainiertes Modell auszuführen, um ein Ergebnis zu erhalten: die Antwort eines Chatbots, eine Dokumentenkategorie, eine kurze Zusammenfassung, eine Prognose, erkannte Entitäten oder eine Vektordarstellung von Text. Vereinfacht gesagt kann man Inferenz als die „Nutzung“ eines Modells verstehen. In der Praxis bezeichnen Unternehmen oft jede Maschine für eine solche Last als „KI-Server“, aber das ist eine zu grobe Vereinfachung. In einem Projekt kann ein gewöhnlicher 2-Socket-Server ausreichen, während in einem anderen selbst ein teurer GPU-Server skaliert werden muss.

Die Entscheidung hängt nicht vom Wort „KI“ in der Aufgabe ab, sondern von fünf Faktoren:

• welches Modell verwendet wird;
• wie viele Daten das Modell als Eingabe erhält;
• wie viele Nutzer gleichzeitig auf den Dienst zugreifen;
• wie schnell die Antwort benötigt wird;
• ob Anfragen stapelweise verarbeitet werden können und nicht streng in Echtzeit.

Deshalb lohnt es sich, vor dem Kauf von Hardware nicht nur GPU-Server, sondern auch klassische Intel-Xeon-Server zu prüfen. Für einen Teil der Unternehmensszenarien bieten sie einen vernünftigeren Einstieg: Sie sind günstiger, einfacher zu betreiben, flexibler beim Arbeitsspeicher und bei richtiger Optimierung ausreichend leistungsfähig.

Our most popular servers

Warum nicht alle KI-Aufgaben eine GPU benötigen

Eine GPU eignet sich gut für massiv parallele Berechnungen. Genau deshalb ist sie zur Standardwahl für das Training großer Modelle, die Bildgenerierung, anspruchsvolle Videoanalyse und das Serving großer Sprachmodelle unter hoher Last geworden. Inferenz ist jedoch nicht immer dieselbe Art von Workload.

Es gibt Aufgaben, bei denen das Modell eine kurze Vorhersage trifft:

• den Typ einer Support-Anfrage bestimmen;
• die Stimmung einer Bewertung erkennen;
• einen Betrag und eine Vertragsnummer aus einem Dokument extrahieren;
• eine E-Mail klassifizieren;
• ein Embedding für die Suche erstellen;
• eine kleine Audiomenge transkribieren oder Audio ohne strenge Fristen verarbeiten;
• relevante Fragmente aus einer Wissensdatenbank auswählen.

In diesen Szenarien gibt es keine lange Textgenerierung. Das Modell erhält eine relativ kleine Eingabe und gibt schnell ein Label, eine Zahl, eine Menge von Entitäten oder einen Vektor zurück. Die Last lässt sich gut auf CPU-Kerne verteilen, besonders wenn Anfragen über eine Warteschlange verarbeitet werden.

Ein anderer Fall ist ein Unternehmensassistent auf Basis eines großen Sprachmodells. Er erhält eine lange Frage, Anweisungen, Dokumentfragmente, den Gesprächsverlauf und muss eine ausführliche Antwort generieren. Wenn Dutzende oder Hunderte Nutzer gleichzeitig darauf zugreifen, stößt die CPU schnell an Grenzen bei Generierungsgeschwindigkeit und Speicherbandbreite.

Es gibt auch gemischte Architekturen. Ein System für die Suche in internen Dokumenten kann zum Beispiel so funktionieren:

1. Die CPU nimmt die Anfrage entgegen und bereinigt den Text.
2. Die CPU erstellt oder sucht Embeddings.
3. Die Vektordatenbank findet ähnliche Dokumente.
4. Ein großes Modell generiert die finale Antwort.
5. Die CPU führt Nachbearbeitung, Filterung und Logging aus.

In einem solchen Schema kann eine GPU nur in der Phase der schweren Generierung erforderlich sein. Die übrigen Schritte können problemlos auf Xeon laufen. Intel weist ebenfalls darauf hin, dass in realen KI-Szenarien verschiedene Phasen der Datenverarbeitung unterschiedliche Rechenarten erfordern können: Ein Teil der Last läuft gut auf CPUs, während andere Teile auf spezialisierten Beschleunigern effizienter sind. Dieser Ansatz wird ausführlicher im Intel-Material zur Beschleunigung von Inferenz auf CPUs beschrieben.

Was Intel Xeon bei der Inferenz hilft

Intel Xeon 6.

Bildquelle: newsroom.intel.com

Eine moderne Server-CPU ist nicht nur ein „Universalprozessor“. Für Inferenz-Workloads hat sie mehrere starke Vorteile.

Viele Kerne für parallele kleine Anfragen

Wenn ein Dienst Hunderte kurzer Operationen verarbeitet, kann die CPU sie auf Kerne verteilen. Das ist nützlich für Klassifizierung, Embeddings, Filterung, Suche, Vorverarbeitung und API-Serving.

Wenn zum Beispiel ein Strom von CRM-Tickets verarbeitet werden muss, muss die CPU nicht wie ein Chatbot in Echtzeit antworten. Sie kann Aufgaben aus einer Warteschlange entnehmen und mit akzeptabler Geschwindigkeit verarbeiten.

Großer Arbeitsspeicher

Bei KI geht es nicht nur um Rechenleistung. Häufig sind folgende Punkte entscheidend:

• die Größe des Modells im Speicher;
• Suchindizes;
• Dokumente und Kontextfragmente;
• Caches;
• Aufgabenwarteschlangen;
• Zwischendaten.

2-Socket-Xeon-Server bieten in der Regel mehr Möglichkeiten beim RAM-Ausbau als Workstations oder kompakte GPU-Konfigurationen. Die Geschwindigkeit des Systemspeichers ist natürlich nicht mit HBM vergleichbar, aber pro Gigabyte deutlich günstiger. Das ist wichtig für Document AI, RAG-Systeme und Unternehmens-Wissensdatenbanken, bei denen neben dem Modell viele unterstützende Daten liegen.

Integrierte Beschleunigung für Matrixoperationen

Neuronale Netzmodelle nutzen intensiv Matrixberechnungen. Neue Generationen von Intel Xeon enthalten für solche Aufgaben integrierte Beschleunigungen, darunter Intel AMX. Dieser Mechanismus ist dafür ausgelegt, Matrixoperationen zu beschleunigen, die in Deep-Learning- und Inferenz-Workloads verwendet werden.

Das macht die CPU nicht zu einem vollständigen Ersatz für die GPU in jedem Szenario. Für bestimmte Modelle und moderate Lasten helfen diese Funktionen jedoch, Inferenz auf der CPU schneller und wirtschaftlicher auszuführen als auf älteren Servergenerationen.

Gute Rolle in gemischten Workloads

Viele Unternehmens-KI-Dienste bestehen nicht aus „einem Modell auf einem Server“. Im Umfeld arbeiten außerdem:

• eine Webanwendung;
• eine Datenbank;
• eine Aufgabenwarteschlange;
• Dokumentenspeicher;
• Vektorsuche;
• Monitoring;
• Autorisierung;
• Logging;
• Integrationen mit CRM-, ERP- oder Service-Desk-Systemen.

Ein CPU-Server ist gerade deshalb praktisch, weil er diese gesamte Umgebung bedienen kann. Selbst wenn das System eine GPU enthält, bleibt Xeon das zentrale Element: Er bereitet Daten vor, verwaltet Anfragen, führt Servicelogik aus und verhindert, dass der Beschleuniger untätig bleibt.

Welche Aufgaben meist mit CPU beginnen können

Klassifizierung und Routing

Dies ist eines der besten Szenarien für CPU-Inferenz. Das Modell erhält Text und gibt eine Kategorie, Wahrscheinlichkeit, ein Label oder eine kurze Menge von Merkmalen zurück.

Beispiele:

• Weiterleitung von Support-Anfragen an Abteilungen;
• Erkennung des Themas einer E-Mail;
• Suche nach dringenden Tickets;
• Klassifizierung von Bewertungen;
• Moderation von nutzergeneriertem Text;
• Bestimmung des Dokumenttyps.

Ein großes generatives Modell wird hier selten benötigt. Oft reichen ein kompaktes Modell, Regeln, klassisches maschinelles Lernen oder eine Kombination daraus. CPU funktioniert gut, weil die Antwort kurz ist und Anfragen parallel verarbeitet werden können.

Embeddings und semantische Suche

Ein Embedding ist eine numerische Darstellung von Text, mit der sich ähnliche Dokumente, Produkte, Tickets oder Anweisungen suchen lassen. Solche Modelle sind oft leichter als große generative Modelle.

CPU kann ausreichend sein, wenn:

• die Wissensdatenbank nicht sehr groß ist;
• Dokumente schrittweise hinzugefügt werden;
• es nicht zu viele Abfragen gibt;
• die Indexierung nach Zeitplan laufen kann;
• keine strenge Anforderung besteht, in Sekundenbruchteilen zu antworten.

GPU wird sinnvoll, wenn Embeddings massenhaft für Millionen von Dokumenten neu berechnet werden müssen, wenn der Dienst einen hohen Anfragefluss bewältigen muss oder wenn mehrere Dienste gleichzeitig bedient werden sollen.

Document AI

Bei Aufgaben der Dokumentenverarbeitung ist CPU oft eine rationale Wahl, besonders bei Rechnungen, Verträgen, Abnahmeprotokollen, Anträgen und internen Formularen.

Typische Operationen sind:

• eine Vertragsnummer extrahieren;
• Datum, Betrag, Steuernummer oder Adresse finden;
• den Dokumenttyp bestimmen;
• Felder mit Daten im Buchhaltungssystem vergleichen;
• das Dokument an die richtige Genehmigungsroute senden.

Ein nicht offensichtlicher Punkt: Der Engpass ist hier oft nicht das Modell, sondern die Qualität der Scans, OCR, Dokumentstruktur, Feldvalidierung und Integration mit Geschäftssystemen. Der Kauf einer GPU behebt keine schlechten Vorlagen, unordentlichen PDFs oder instabilen Genehmigungsprozesse.

Kleine Sprachmodelle

Kleine und mittelgroße Sprachmodelle können auf CPU laufen, wenn sie optimiert sind und die Geschwindigkeitsanforderungen moderat bleiben. Das ist besonders relevant für interne Tools, bei denen der Nutzer einige Sekunden warten kann.

CPU kann geeignet sein für:

• einen internen Assistenten für Richtlinien und Vorschriften;
• die Generierung kurzer Entwürfe;
• die Zusammenfassung kleiner Dokumente;
• die Klassifizierung von Dialogen;
• Vorschläge für Support-Mitarbeiter;
• lokale Prototypen ohne Weitergabe von Daten an externe Dienste.

Wichtig ist jedoch, „ein Modell ausführen“ nicht mit „einen bequemen Dienst betreiben“ zu verwechseln. Eine Antwort in einer Testkonsole zu erhalten, ist das eine. Nutzer in einer produktiven Oberfläche zu bedienen, in der Stabilität, Warteschlangen, Sicherheit und vorhersehbare Latenz zählen, ist etwas anderes.

Batch-Verarbeitung

Wenn das Ergebnis nicht sofort benötigt wird, ist CPU häufig ausreichend wirtschaftlich.

Beispiele:

• nächtliche Verarbeitung eines Dokumentenarchivs;
• Neuindexierung einer Wissensdatenbank;
• Massenklassifizierung alter Tickets;
• Vorbereitung von Embeddings;
• Extraktion von Daten aus gesammelten PDFs;
• Erstellung interner Berichte.

Bei solchen Aufgaben kann die Verarbeitung über mehrere Stunden gestreckt, nachts ausgeführt und durch Ressourcengrenzen eingeschränkt werden. Eine GPU nur für seltene Lastspitzen zu kaufen, ist dann nicht nötig.

Wo CPU schnell zur Begrenzung wird

Große Sprachmodelle

Je größer das Modell, desto höher sind die Anforderungen an Rechenleistung und Speicher. CPU kann einige große Modelle in quantisierter Form ausführen, aber das bedeutet nicht, dass die Geschwindigkeit für den geschäftlichen Einsatz ausreicht.

Probleme entstehen, wenn man:

• lange Antworten generieren muss;
• viele Nutzer bedienen muss;
• einen großen Kontext halten muss;
• den ersten Teil der Antwort schnell zurückgeben muss;
• den Dienst ohne lange Warteschlangen skalieren muss.

Die Materialien von NVIDIA zur Optimierung der Inferenz großer Sprachmodelle weisen ausdrücklich darauf hin, dass lange Eingaben und Szenarien mit Abruf aus externen Wissensquellen die Rechenlast erhöhen. Deshalb kann ein RAG-System mit langen Dokumenten schnell schwer werden, selbst wenn die Idee einfach klingt: „Beantworte nur eine Frage anhand der Wissensdatenbank“.

Hohe Parallelität

Ein interner Nutzer und 200 gleichzeitige Nutzer sind zwei unterschiedliche Infrastrukturaufgaben.

CPU kann einen Pilotbetrieb bewältigen:

• 5–10 Mitarbeitende;
• kurze Fragen;
• kleine Dokumente;
• niedrige Anfragefrequenz;
• akzeptable Wartezeit.

Ein öffentlicher oder großer interner Dienst erfordert jedoch eine andere Bewertung. Wenn Nutzer in Wellen kommen, kann die CPU anfangen, eine Warteschlange aufzubauen. Die durchschnittliche Antwortzeit kann noch akzeptabel aussehen, während ein Teil der Nutzer bereits zu lange Verzögerungen erlebt.

Langer Kontext

Kontext ist alles, was das Modell als Eingabe erhält: Frage, Anweisungen, Gesprächsverlauf und gefundene Dokumentfragmente. In RAG-Systemen kann der Kontext schnell wachsen.

Ein langer Kontext erhöht:

• den Speicherverbrauch;
• die Verarbeitungszeit der Anfrage;
• die Kosten pro Antwort;
• die Last bei gleichzeitigen Nutzern;
• die Wahrscheinlichkeit instabiler Latenz.

Manchmal wird das Problem nicht durch den Kauf einer GPU gelöst, sondern durch eine Verkürzung des Kontexts: bessere Dokumentensuche, präziseres Schneiden von Fragmenten, Entfernen unnötiger Anweisungen und Verzicht darauf, dem Modell das gesamte Dokument zu senden.

Video, Bilder und Sprache in Echtzeit

Eine GPU ist fast immer sinnvoller, wenn das System in Echtzeit:

• einen Videostream analysieren muss;
• Sprache erkennen muss;
• Bilder verarbeiten muss;
• mit multimodalen Modellen arbeiten muss;
• Bilder generieren muss;
• komplexe Computer-Vision-Verarbeitung auf einem Stream ausführen muss.

CPU kann für einzelne Phasen und relativ einfache Aufgaben wie Transkription eingesetzt werden, aber die schwere Mathematik solcher Modelle ist auf GPU meist wirtschaftlicher.

Szenariovergleich: CPU oder GPU

Wie man die Last vor dem Serverkauf bewertet

Modellgröße

Die Modellgröße beeinflusst Speicher, Geschwindigkeit und Rechenanforderungen. Ein Server sollte jedoch nicht nur nach der Anzahl der Parameter ausgewählt werden. Auch Modellformat, Quantisierung, Eingabelänge, Ausgabelänge und Anzahl gleichzeitiger Anfragen sind wichtig.

Ein kleines Modell mit hohem Anfragefluss kann für die Infrastruktur schwerer sein als ein größeres Modell, das nur von wenigen Personen genutzt wird.

Eingabelänge

Eine kurze Anfrage wie „Zu welcher Kategorie gehört diese E-Mail?“ und eine Anfrage mit einem 20-seitigen Vertrag sind unterschiedliche Workloads. Selbst wenn dasselbe Modell verwendet wird, verändert eine lange Eingabe die Verarbeitungszeit.

Für Unternehmenssysteme ist das besonders wichtig, weil Nutzer häufig „das gesamte Dokument hochladen“ möchten. Das Modell muss aber selten alles auf einmal sehen. Meist ist es besser:

• das Dokument vorab in Fragmente zu teilen;
• nur die relevanten Teile zu finden;
• Duplikate zu entfernen;
• den Gesprächsverlauf zu begrenzen;
• dem Modell weniger unnötigen Text zu senden.

Anzahl gleichzeitiger Nutzer

Es reicht nicht aus, die Gesamtzahl der Mitarbeitenden im Unternehmen zu zählen. Wichtiger ist zu verstehen, wie viele Personen tatsächlich gleichzeitig auf das System zugreifen.

Nützliche Fragen für die Bewertung:

• wie viele Anfragen pro Minute es an einem normalen Tag geben wird;
• ob es morgendliche oder abendliche Spitzen gibt;
• wie viele Nutzer gleichzeitig arbeiten können;
• ob der Dienst öffentlich sein wird;
• was passiert, wenn die Warteschlange wächst;
• ob es akzeptabel ist, dass ein Nutzer 5–10 Sekunden oder länger wartet.

Wenn der Dienst intern und nicht kritisch ist, kann CPU ein guter Ausgangspunkt sein. Wenn er Teil eines kundenorientierten Produkts ist, wird Latenz zu einer Geschäftsmetrik.

Batch-Verarbeitung

Batch-Verarbeitung bedeutet, dass Anfragen gesammelt und in Gruppen ausgeführt werden können. Das hilft, Hardware effizienter zu nutzen.

Sie eignet sich gut für:

• die Verarbeitung von Archiven;
• nächtliche Indexierung;
• Massenklassifizierung;
• den Aufbau von Embeddings;
• die Vorbereitung von Daten für Analysen.

Sie eignet sich schlechter für:

• Online-Chat;
• Sprachassistenten;
• Hinweise für Operatoren während eines Live-Gesprächs;
• interaktive Suche;
• eine Benutzeroberfläche, in der die Antwort sofort benötigt wird.

Latenz und Durchsatz

Bei der Serverauswahl ist es wichtig, nicht nur zu messen, ob das System „funktioniert“. Für einen nutzerorientierten Dienst sind Latenz, Durchsatz und Kosten der Anfrageverarbeitung wichtig. Der NVIDIA-Leitfaden zum Benchmarking von LLM-Inferenz behandelt diese Parameter als zentrale Metriken zur Bewertung der Qualität und Wirtschaftlichkeit des Model Serving.

Für die Bewertung sollte man betrachten:

• Zeit bis zur ersten sichtbaren Antwort;
• Gesamtdauer der Anfrage;
• Generierungsgeschwindigkeit;
• Anzahl der Anfragen pro Sekunde;
• Verhalten bei Spitzenlasten;
• Anteil langsamer Anfragen;
• Kosten pro Antwort.

Durchschnittswerte können täuschen. Wenn 90 % der Anfragen schnell beantwortet werden und 10 % hängen bleiben, werden sich Nutzer genau an diese 10 % erinnern.

Entscheidungsmatrix: CPU oder GPU

Warum die Gesamtbetriebskosten wichtiger sind als der Serverpreis

Der Kaufpreis ist nur ein Teil der Entscheidung. Bei KI-Infrastruktur müssen die vollständigen Gesamtbetriebskosten berechnet werden.

Dazu gehören:

• der Server;
• GPU, falls erforderlich;
• RAM;
• Speicherlaufwerke;
• Netzwerk;
• Stromverbrauch;
• Kühlung;
• Rackplatz;
• Administration;
• Ersatzkomponenten;
• Kosten von Ausfallzeiten;
• zukünftige Skalierung.

Ein CPU-Server kann am Anfang günstiger sein, aber bei hoher Last können mehrere solcher Maschinen erforderlich werden. Ein GPU-Server ist teurer, kann aber bei dauerhaft hoher Last pro verarbeiteter Anfrage günstiger sein.

Szenarien, in denen sich GPU häufig amortisiert:

• CPU erreicht die erforderliche Latenz nicht;
• die Anfragewarteschlange wächst schneller, als sie verarbeitet wird;
• der Dienst wird von vielen Mitarbeitenden oder Kunden genutzt;
• Antwortgenerierung ist Teil eines kommerziellen Produkts;
• die Last ist hoch und stabil;
• die Kosten der Wartezeit der Nutzer sind höher als die Kosten des Beschleunigers.

Szenarien, in denen GPU überdimensioniert sein kann:

• das Projekt befindet sich in der Pilotphase;
• der Dienst wird von wenigen Mitarbeitenden genutzt;
• Antworten werden nicht sofort benötigt;
• Aufgaben laufen nach Zeitplan;
• das Modell ist klein;
• die GPU wäre die meiste Zeit ungenutzt.

Manchmal ist der wirtschaftlichste Weg, mit Xeon zu beginnen, die reale Last zu messen, das Modell zu optimieren und erst danach eine GPU zu kaufen. Dadurch sinkt das Risiko, für Hardware zu viel zu bezahlen, die nicht vollständig ausgelastet wird.

Wie man Inferenz auf CPU optimiert

Vor dem Wechsel zu GPU sollte geprüft werden, wie gut die CPU tatsächlich genutzt wird. Manchmal liegt das Problem nicht an der Hardware, sondern an einem nicht optimierten Modell, falschen Thread-Einstellungen oder einem übermäßig langen Eingabekontext.

Optimierte Bibliotheken

Für CPU-Inferenz verwenden Teams OpenVINO, ONNX Runtime, oneDNN, llama.cpp und andere Tools. Die Dokumentation zum OpenVINO CPU device gibt an, dass das CPU-Plugin für Hochleistungsinferenz auf Intel-x86-64- und Arm-Prozessoren ausgelegt ist, während neuere CPU-Generationen zusätzliche Leistungsgewinne bieten, besonders bei INT8-Modellen.

Das ist wichtig, weil „ein Modell auf CPU ausführen“ auf verschiedene Weise erfolgen kann. Eine native, nicht optimierte Build kann schwache Ergebnisse zeigen, während ein richtig vorbereitetes Modell bereits akzeptable Geschwindigkeit liefern kann.

Quantisierung

Quantisierung reduziert die Genauigkeit der Zahlen innerhalb des Modells. Statt schwererer Formate können zum Beispiel leichtere Formate wie INT8 oder INT4 verwendet werden. Das Modell belegt weniger Speicher, lädt schneller und kann schneller laufen.

Vorteile:

• geringerer Speicherverbrauch;
• niedrigere Serveranforderungen;
• höhere Geschwindigkeit;
• einfachere CPU-Bereitstellung.

Nachteile:

• die Qualität kann leicht sinken;
• Tests mit realen Daten sind erforderlich;
• nicht alle Modelle vertragen starke Quantisierung gleich gut.

Quantisierung ist besonders nützlich für Pilotprojekte, interne Assistenten, Klassifikatoren und kleinere generative Modelle.

Vernünftiger Kontext

Viele KI-Dienste arbeiten langsam nicht, weil der Server schwach ist, sondern weil zu viel Text an das Modell gesendet wird.

Statt dem Modell das gesamte Dokument zu senden, ist es besser:

• Dokumente in Fragmente zu teilen;
• nur nach relevanten Teilen zu suchen;
• den Gesprächsverlauf zu begrenzen;
• wiederholte Anweisungen zu entfernen;
• Fakten und Metadaten getrennt zu speichern;
• verschiedene Aufgaben nicht in einem Prompt zu mischen.

Das ist besonders wichtig für RAG-Systeme. Je mehr unnötiger Text in die Anfrage gelangt, desto teurer wird jede Antwort.

Thread- und Speichertuning

CPU-Inferenz reagiert empfindlich auf Einstellungen:

• Anzahl der Threads;
• Lastverteilung zwischen Sockets;
• NUMA;
• Speichergeschwindigkeit;
• Konkurrenz mit der Datenbank;
• Festplattenlast;
• Netzwerkaustausch mit dem Speicher.

Wenn Modell, Datenbank, Suche und Webanwendung gleichzeitig auf einem Server laufen, können sie sich gegenseitig stören. Deshalb ist es für produktive Systeme oft besser, Rollen zu trennen: ein Server für API und Warteschlangen, ein anderer für Suche und ein dritter für schwere Generierung.

Hybride Architektur: wenn CPU und GPU zusammenarbeiten

In reifer KI-Infrastruktur lautet die Frage selten „CPU oder GPU“. Häufiger lautet die richtige Antwort: „CPU und GPU, aber jede Komponente für ihren eigenen Teil“.

CPU eignet sich gut für:

• Entgegennahme von Anfragen;
• Autorisierung;
• API-Betrieb;
• Textvorbereitung;
• OCR und primäre Dokumentenverarbeitung;
• Suche in der Wissensdatenbank;
• Warteschlangenbetrieb;
• Logging;
• Integrationen;
• Nachbearbeitung der Antwort.

GPU sollte dort eingesetzt werden, wo wirklich schwere parallele Mathematik nötig ist:

• Generierung langer Antworten;
• Betrieb großer Sprachmodelle;
• multimodale Modelle;
• Videoanalyse;
• massenhafte Erstellung von Embeddings;
• hohe Parallelität.

Dieser Ansatz hilft, GPU-Zeit nicht für Serviceoperationen zu verschwenden. Der Beschleuniger ist mit Generierung oder Modellverarbeitung beschäftigt, während Xeon alles unterstützt, was darum herum liegt.

Beispiel für einen Unternehmens-RAG-Dienst:

1. Der Nutzer stellt eine Frage.
2. Die CPU nimmt die Anfrage entgegen, prüft Berechtigungen und bereinigt den Text.
3. Die CPU oder ein separater Dienst sucht nach relevanten Dokumenten.
4. Die GPU generiert die finale Antwort auf Basis der gefundenen Fragmente.
5. Die CPU prüft das Format, speichert das Log und gibt das Ergebnis an den Nutzer zurück.

Wenn die Last moderat ist, kann Schritt 4 ebenfalls auf CPU bleiben. Wenn die Latenz inakzeptabel wird, ist genau diese Phase die erste, die auf GPU übertragen wird.

Most popular servers

Welche Server man in Betracht ziehen sollte

Dell PowerEdge R760.

Bildquelle: Servermall

Für CPU-Inferenz ist meist nicht ein einzelner Maximalwert entscheidend, sondern das Gleichgewicht der Eigenschaften. Der Server sollte genügend Kerne, Arbeitsspeicher, schnellen Speicher und ausreichende Reserven bei der Kühlung haben.

Für Einstiegs- und mittlere Szenarien lohnt sich der Blick auf 2-Socket-Intel-Xeon-Plattformen:

• Klassifizierung;
• Embeddings;
• Document AI;
• interne Assistenten;
• RAG mit moderater Last;
• Batch-Verarbeitung;
• Dienste mit geringer Parallelität.

Für solche Aufgaben eignen sich universelle 2U-Server, zum Beispiel Dell PowerEdge R760 oder Dell PowerEdge R770, wenn Reserven für neue CPU-Generationen, Speicher, NVMe und die weitere Entwicklung des Dienstes benötigt werden.

Bei der Auswahl eines CPU-Servers sollte man achten auf:

• CPU-Generation;
• Anzahl der Kerne;
• unterstützte RAM-Kapazität;
• Anzahl der Speichersteckplätze;
• NVMe-Konfiguration;
• Netzwerkschnittstellen;
• Möglichkeiten für spätere Erweiterung;
• Stromverbrauch;
• Kühlungsanforderungen.

Wenn die Aufgabe von Anfang an mit großen Modellen, hoher Parallelität, Multimodalität oder Video verbunden ist, sollte man besser GPU-Plattformen prüfen. In der deutschen Version kann man sich auch den Bereich Dell KI-Server ansehen.

Für Unternehmen, die ihre KI-Infrastruktur schrittweise entwickeln wollen, ist es sinnvoll, nicht nur auf ein konkretes Servermodell zu schauen, sondern auch auf die Plattformgeneration. Zum Beispiel können Dell-Server der 17. Generation interessant sein, wenn Reserven für neue Prozessoren, Speicher, Netzwerkkarten und einen längeren Lebenszyklus benötigt werden.

Wie man eine Entscheidung ohne Überzahlung trifft

Die Serverauswahl sollte nicht mit dem Hardwarekatalog beginnen, sondern mit einer Beschreibung der Last.

Die Reihenfolge kann so aussehen:

1. Aufgabentyp definieren: Klassifizierung, Suche, Embeddings, RAG, Generierung, Video, Sprache.
2. Das Modell oder zumindest die Modellklasse festlegen.
3. Verstehen, wie viel Text das Modell als Eingabe erhält.
4. Die Länge der Antwort einschätzen.
5. Die Anzahl gleichzeitiger Nutzer berechnen.
6. Normale Last und Spitzenlast trennen.
7. Akzeptable Latenz definieren.
8. Prüfen, ob Batch-Verarbeitung genutzt werden kann.
9. Die Aufgabe auf CPU testen.
10. CPU-only-, GPU-only- und Hybridoptionen anhand der Gesamtbetriebskosten vergleichen.

Wichtig ist, nicht ein abstraktes Beispiel aus der Dokumentation zu testen, sondern die eigene Aufgabe. Wenn ein Nutzer in der Realität einen 30-seitigen Vertrag sendet, zeigt ein Test mit einer kurzen Frage nicht die tatsächliche Last. Wenn in der Realität 50 Personen den Dienst gleichzeitig nutzen, ist auch ein Test mit einer einzigen Anfrage nutzlos.

Gemessen werden sollte nicht nur, ob „eine Antwort erschienen ist“, sondern konkrete Parameter:

• Zeit bis zur ersten Antwort;
• Gesamtdauer der Anfrage;
• Generierungsgeschwindigkeit;
• Anzahl der Anfragen pro Sekunde;
• CPU-Auslastung;
• Speichernutzung;
• Warteschlangen;
• Stromverbrauch;
• Kosten pro Anfrage.

Ein solcher Test zeigt häufig, dass ein Teil des Systems auf Xeon bleiben kann, während GPU nur für eine schwere Phase benötigt wird. Oder umgekehrt: CPU eignet sich für einen Pilotbetrieb, aber nicht für produktive Last.

Wann Intel Xeon eine vernünftige Wahl ist

Xeon sollte zuerst geprüft werden, wenn sich das Projekt in der Pilotphase befindet oder eine moderate Produktionslast hat. Das gilt besonders dann, wenn das Unternehmen die reale Anzahl der Anfragen noch nicht kennt und nicht sofort einen teuren GPU-Server kaufen möchte.

Eine CPU-Plattform ist geeignet, wenn:

• das Modell klein oder mittelgroß ist;
• Daten über eine Warteschlange verarbeitet werden können;
• Latenz nicht kritisch ist;
• Nutzer intern sind;
• einfache Betriebsführung wichtig ist;
• viel RAM benötigt wird;
• Datenbank, Suche, API und Integrationen neben dem Modell laufen;
• die GPU die meiste Zeit untätig wäre.

Dieser Ansatz hilft, das Projekt schneller zu starten, reale Metriken zu erhalten und eine Überzahlung für einen Beschleuniger zu vermeiden, solange die Last noch nicht bestätigt ist.

Wann GPU von Anfang an nötig ist

GPU sollte von Beginn an in der Architektur vorgesehen werden, wenn die Aufgabe bereits klar und offensichtlich schwer ist.

Das gilt, wenn:

• ein großes Sprachmodell verwendet wird;
• die Antwort schnell generiert werden muss;
• viele gleichzeitige Nutzer vorhanden sind;
• der Kontext lang ist;
• der Dienst Teil eines kundenorientierten Produkts ist;
• Latenz Umsatz oder Servicequalität beeinflusst;
• Video, Bilder, Sprache oder multimodale Daten vorhanden sind;
• ein CPU-Test eine inakzeptable Warteschlange zeigt.

In solchen Projekten kann der Versuch, „an GPU zu sparen“, den gegenteiligen Effekt haben: Es müssen mehr CPU-Server gekauft werden, das System wird schwieriger zu skalieren, und den Nutzern muss erklärt werden, warum der Assistent zu langsam antwortet.

Fazit

Intel Xeon eignet sich für viele KI-Inferenzaufgaben, wenn das Modell nicht zu groß ist, die Last moderat bleibt, der Kontext kontrolliert wird und Latenz keine harte geschäftliche Anforderung ist. Auf CPU kann man mit Klassifizierung, Embeddings, Document AI, internen Assistenten, Batch-Verarbeitung und einem Teil der RAG-Szenarien beginnen.

GPU wird nicht deshalb benötigt, weil das Projekt mit KI zu tun hat, sondern weil es konkrete Anforderungen gibt: ein großes Modell, langer Kontext, viele Nutzer, niedrige Latenz, Multimodalität oder hohe Kosten des Wartens. Der zuverlässigste Weg ist, zuerst die Last zu beschreiben, dann das reale Szenario auf Xeon zu testen, die Gesamtbetriebskosten zu berechnen und erst danach CPU, GPU oder eine hybride Architektur auszuwählen.