A100 GPU-Server für LLM-Inferenz: Labortest mit 8× NVIDIA A100

Kann eine vier Jahre alte NVIDIA-A100-Generation ohne FP8-Unterstützung heute noch ein aktuelles Sprachmodell produktiv betreiben? Wir haben getestet: drei Tage, zwei Server-Nodes, acht A100-GPUs, und echte Zahlen statt Datenblatt-Versprechen.Wer heute einen eigenen KI-Server für den Betrieb großer Sprachmodelle plant, stößt schnell auf dieselbe Frage: Reicht gebrauchte NVIDIA-A100-Hardware noch aus, oder führt an teurer Hopper- oder Blackwell-Generation kein Weg vorbei? Hersteller-Datenblätter beantworten das nicht: sie zeigen Peak-Werte unter Laborbedingungen, keine Praxis unter echter Last.

Wir haben deshalb einen A100-GPU-Server drei Tage lang unter realistischer Last getestet: ein HPE Apollo 6500 Gen10 Plus mit acht NVIDIA A100 SXM4 40GB, verteilt über zwei per InfiniBand gekoppelte Server-Nodes. Getestet wurden zwei aktuelle Open-Weight-Modelle, ein großes 397-Milliarden-Parameter-Modell und ein schlankes 27-Milliarden-Parameter-Modell, unter neun Benchmark-Konfigurationen.
Das Ergebnis überrascht: Die entscheidende Stellschraube war nicht die Netzwerk-Bandbreite und nicht die Anzahl der GPUs, sondern eine einzige Software-Einstellung. Dieser Artikel zeigt die vollständigen Zahlen, die Fehler unterwegs und was das für die Kaufentscheidung bedeutet.

Das Testsystem: HPE Apollo 6500 Gen10 Plus mit 8× NVIDIA A100

Das Testsystem bestand aus zwei HPE ProLiant XL645d Gen10 Plus Node-Servern im Apollo-6500-Chassis, dem Formfaktor, den HPE für dichte GPU-Workloads wie KI-Training und -Inferenz vorsieht [1]. Jeder Node war mit vier NVIDIA A100-SXM4-40GB-GPUs bestückt, intern per NVLink-Mesh verbunden, macht acht A100-GPUs mit insgesamt 320 GB HBM2-Speicher im Gesamtsystem.
Die beiden Nodes waren über ConnectX-6-Adapter direkt per InfiniBand HDR100 verkabelt, ohne Switch dazwischen: gemessen wurden 11,5 GB/s Bandbreite und 15,3 GB/s Allreduce-Bandbreite über NCCL bei allen acht GPUs gemeinsam. Als Prozessoren kamen AMD-EPYC-CPUs mit 128 Threads und rund 500 GB RAM pro Node zum Einsatz, dazu 745 GB NVMe-Storage für Modellgewichte und gespiegelte SAS-Laufwerke für Daten.

Software-seitig lief Ubuntu Server 24.04 mit NVIDIA-Treiber 580 und CUDA 13, containerisiert über Docker mit dem NVIDIA Container Toolkit. Als Inferenz-Engine kam vLLM zum Einsatz, die etablierte Open-Source-Lösung für produktiven LLM-Betrieb, die auch vielen kommerziellen Inferenz-APIs zugrunde liegt.

Ein Detail bestimmte die gesamte Modellauswahl: Ampere-GPUs wie die A100 unterstützen weder FP8- noch NVFP4-Datentypen und keine der Hopper-spezifischen Kernel wie Sparse-MLA oder FlashAttention 3. Damit schieden aktuelle Flaggschiff-Modelle wie GLM-5.3-Flash, DeepSeek V4, MiniMax M3 oder Kimi K3 von vornherein aus, ebenso alle Modelle über etwa 350 Milliarden Gesamtparametern, da deren komprimierte Gewichte selbst als INT4 nicht mehr in 320 GB HBM2 passen. Wer mit gebrauchter Ampere-Hardware plant, muss diese Grenze kennen, bevor er ein Modell auswählt. Ähnliche Einschränkungen gelten auch für andere Ampere-Systeme wie die HPE Smart Choice Server-Reihe.

Testmethodik: Wie belastbar sind die Zahlen?

Alle Messungen liefen mit vllm bench serve gegen den laufenden Server, nicht gegen synthetische Microbenchmarks. Als Eingabe dienten Zufallsdaten mit 2.048 Input- und 1.024 Output-Tokens, jeweils drei Prompts pro Lastszenario, bei steigender Parallelität von 1 über 8, 32 und 64 bis zu 128 gleichzeitigen Anfragen.

Drei Messgrößen bestimmen jede Zeile in den folgenden Tabellen: der Output-Durchsatz in Tokens pro Sekunde (tok/s) als Kapazität des Gesamtsystems, die Time to First Token (TTFT) als Wartezeit bis zur ersten sichtbaren Antwort inklusive Warteschlange, und die Time per Output Token (TPOT), aus der sich die von einem einzelnen Nutzer wahrgenommene Geschwindigkeit ableitet. Vor jedem Lauf wurde der Server neu gestartet und über den Health-Endpoint auf vollständige Bereitschaft geprüft, damit keine Anlaufzeiten die Ergebnisse verfälschen.

Das große Modell: Qwen3.5-397B-A17B im Multi-Node-Betrieb

Qwen3.5-397B-A17B ist ein Mixture-of-Experts-Modell mit 397 Milliarden Gesamt- und 17 Milliarden aktiven Parametern, inklusive Vision-Encoder, 262.000 Token Kontextfenster und Apache-2.0-Lizenz [4]. Als 4-Bit-quantisierte GPTQ-Variante belegen die Gewichte rund 220 GB, zu groß für einen einzelnen 4-GPU-Node, weshalb das Modell mit Tensor-Parallel über beide Nodes hinweg (TP=8) betrieben wurde, verteilt per InfiniBand.

Tensor-Parallel verteilt jede Schicht auf alle Karten, Pipeline-Parallel rechnet Schichtabschnitte nacheinander. Im Test war Tensor-Parallel deutlich schneller. (Quelle: IT-RESELL.COM)

Fünf Konfigurationen, eine Erkenntnis: der Kernel entscheidet

Getestet wurden fünf aufeinander aufbauende Betriebsvarianten desselben Modells, es änderte sich nie das Modell, nur wie vLLM es über die acht Karten verteilt und ausführt:

• Basis: Tensor-Parallel über 8 GPUs mit generischem Triton-Kernel (Ausgangspunkt, offizielle Recipe-Vorgabe)
• PP: Pipeline-Parallel statt Tensor-Parallel, Test der Annahme, das Netzwerk sei der Engpass
• A (Marlin): gleicher Aufbau wie Basis, aber mit handoptimiertem Entpack-Kernel für die INT4-Gewichte
• B (+MTP): zusätzlich Speculative Decoding (Multi-Token Prediction) für den Einzelnutzer
• C (+Async Scheduling): löst die durch MTP verursachte Scheduler-Last bei vielen Nutzern wieder auf
• D (+Expert Parallel): verteilt ganze MoE-Experten statt Schichtscheiben auf die Karten

Konfiguration	Einzeln. tok/s	TTFT	Bester Wert	bei N	TTFT dort
Basis (Triton)	41	1,0 s	155 tok/s	32	5,5 s
PP (TP4/PP2)	34	1,6 s	212 tok/s	128	21 s
A (Marlin)	70	0,6 s	627 tok/s	64	7,3 s
B (+MTP)	109	1,0 s	499 tok/s	64	79 s
C (+Async)	109	1,0 s	661 tok/s	32	2,5 s
D (+Expert Parallel)	104	1,0 s	693 tok/s*	32	2,6 s

* Konfiguration D stürzte bei 64 parallelen Anfragen mit einem Engine-Fehler ab.

Der ursprüngliche Verdacht vor dem Test lautete, das InfiniBand-Kabel zwischen den Nodes sei der limitierende Faktor. Die Pipeline-Parallel-Konfiguration widerlegte das: Obwohl sie weniger Daten über das Netzwerk schickt als Tensor-Parallel, war sie in jeder Lastsituation langsamer, weil die Rechenpausen zwischen den Nodes mehr kosten als das eingesparte Allreduce. Den größten Sprung brachte stattdessen der Kernel-Wechsel: Die offizielle vLLM-Anleitung für dieses Modell empfiehlt einen Triton-basierten Kernel, der für Hopper-GPUs optimiert ist [3]. Auf Ampere-Hardware bremst er dagegen aus: der Wechsel auf den handoptimierten Marlin-Kernel brachte allein Faktor 1,7 beim Einzelnutzer und Faktor 4,2 bei acht gleichzeitigen Anfragen.

Zwei weitere Software-Hebel verbesserten die Latenz für den Einzelnutzer: MTP Speculative Decoding lässt das Modell zwei Tokens im Voraus raten und in einem Durchlauf prüfen: stimmen die Vorhersagen, entstehen mehrere Tokens zum Preis von einem. Das verdoppelte die Einzelnutzer-Geschwindigkeit von 70 auf 109 tok/s, belastete aber den Scheduler so stark, dass die Wartezeit ab 32 gleichzeitigen Anfragen auf über 20 Sekunden anstieg. Erst Async Scheduling, der Scheduler plant den nächsten Rechenschritt, während die GPUs noch arbeiten, löste diese Warteschlange wieder auf und lieferte mit 661 tok/s bei 2,5 Sekunden Wartezeit den besten Gesamtwert des Tests.

Expert Parallel, bei dem ganze Experten statt Schichtscheiben auf einzelne Karten verteilt werden, brachte bei 32 Anfragen noch einen kleinen Vorteil, stürzte aber bei 64 gleichzeitigen Anfragen mit einem Engine-Fehler ab. Für den produktiven Multi-Node-Betrieb ist diese Konfiguration damit nicht geeignet.

Betriebsempfehlung für das 397B-Modell

Für den produktiven Einsatz empfiehlt sich die Kombination aus Marlin-Kernel, MTP Speculative Decoding und Async Scheduling, im Testprotokoll als Konfiguration C geführt. Sie liefert 109 tok/s für den Einzelnutzer bei rund einer Sekunde bis zum ersten Token, schneller als die meisten Cloud-APIs, und bleibt bis etwa 40 gleichzeitigen Sitzungen stabil nutzbar. Darüber sollten Anfragen am Gateway gedrosselt statt direkt durchgereicht werden. Der Erst-Start des Modells dauert rund 15 Minuten für das Laden der Gewichte, danach lief das System im Test über mehrere Stunden Benchmark-Last stabil.

Das schnelle Modell: Qwen3.6-27B im Dauerbetrieb

Qwen3.6-27B ist ein dichtes Modell ohne MoE-Architektur, mit 27 Milliarden Parametern, ebenfalls unter Apache-2.0-Lizenz und mit 262.000 Token Kontextfenster, im Test auf 64.000 Token konfiguriert. Die Gewichte in bf16 belegen rund 55 GB, ein einzelner 4-GPU-Node reicht für den vollständigen Betrieb, Tensor-Parallel über das Netzwerk war nicht nötig. Beide Nodes liefen als unabhängige Endpunkte parallel.

Parallel	1 Node tok/s	TTFT	2 Nodes gesamt	Abweichung
1	69	0,3 s	139	< 1 %
8	459	0,7 s	924	< 1 %
32	1.306	1,5 s	2.618	< 1 %
64	2.093	2,6 s	4.192	< 1 %
128	2.589	5,4 s	5.187	< 1 %

Die Ergebnisse zeigen nahezu perfekte lineare Skalierung: Was ein Node bei einer bestimmten Last leistet, verdoppelt sich mit dem zweiten Node fast exakt, die Abweichung zwischen beiden Nodes lag durchgehend unter einem Prozent. Bei 128 parallelen Anfragen pro Node erreichte das System 5.187 Tokens pro Sekunde Gesamtdurchsatz, wobei jeder einzelne Nutzer noch 23 tok/s bei rund 5 Sekunden Wartezeit erlebte. Rund 250 gleichzeitige Sitzungen über beide Nodes hinweg sind auf dieser Basis realistisch.

Ohne Speculative Decoding erreichte ein einzelner Nutzer 69 tok/s, langsamer als das 397B-Modell mit aktiviertem MTP, aber immer noch komfortabel für interaktiven Chat. Ein MTP-Testlauf für das 27B-Modell stand im dreitägigen Testfenster zeitlich nicht mehr an; ein ähnlicher Geschwindigkeitsgewinn wie beim 397B-Modell wäre aber zu erwarten.

Direkter Vergleich: 397B oder 27B, welches Modell für wen?

Kriterium	Qwen3.5-397B (Config C)	Qwen3.6-27B (2 Nodes)
Maximaler Durchsatz	661 tok/s	5.187 tok/s
Einzelnutzer	109 tok/s (mit MTP)	69 tok/s (ohne MTP)
Nutzbare Parallelität	ca. 40 Sessions	ca. 250 Sessions
Durchsatz je GPU	83 tok/s	648 tok/s
Speicherbedarf	320 GB, beide Nodes	55 GB je Instanz
Stärke	Weltwissen, Vision, Multilingualität	Coding, Durchsatz, Kosten/Token

Auf identischer Hardware liefert das kleinere, dichte Modell knapp das Achtfache an Durchsatz bei sechsfacher nutzbarer Parallelität, aber mit deutlich schmalerem Weltwissen und ohne Vision-Fähigkeiten. Für Unternehmen mit hohem Nutzeraufkommen und klar umrissenen Aufgaben wie Coding-Assistenz, interner Dokumentensuche oder Kundensupport ist das 27B-Modell die wirtschaftlichere Wahl. Das 397B-Modell rechtfertigt sich dort, wo einzelne Anfragen von hoher Qualität, breitem Weltwissen oder Mehrsprachigkeit abhängen und die Nutzerzahl überschaubar bleibt, etwa als internes Experten-Werkzeug für einige Dutzend Fachkräfte statt als unternehmensweiter Chat-Ersatz.

Energieverbrauch: Was ein Token wirklich kostet

Für das 27B-Modell wurde die GPU-Leistungsaufnahme während eines 32-fach parallelen Lastlaufs im Zwei-Sekunden-Raster gemessen. Im Leerlauf mit geladenem Modell zog ein Node rund 320 Watt, unter Volllast im Mittel 1.231 Watt und in der Spitze bis 1.605 Watt, bei einer maximalen GPU-Temperatur von 77 Grad. In 104 Sekunden erzeugte das System dabei 131.072 Tokens: 35,6 Wattstunden GPU-Energie für den gesamten Lauf, oder 0,27 Wattstunden je 1.000 erzeugte Tokens, umgerechnet rund 3,7 Millionen Tokens je Kilowattstunde GPU-Energie.

Geschwindigkeit pro Nutzer: Mit steigender Parallelität sinkt die Einzelnutzer-Rate, bleibt beim 27B-Modell aber lange über der Chat-Komfortgrenze von 10 tok/s. (Quelle: IT-RESELL.COM)

Beim 397B-Modell lag die Leistungsaufnahme in Stichproben bei 130 bis 200 Watt je GPU, deutlich niedriger als beim 27B-Modell, weil die Karten einen Großteil der Zeit auf Kommunikation und Dequantisierung warten, statt zu rechnen. Bei gleichzeitig rund einem Zehntel des Durchsatzes liegt die Energie je erzeugtem Token beim großen Modell grob beim Zehnfachen. Eine vollständige Messreihe für das 397B-Modell konnte im Testfenster nicht mehr aufgenommen werden (siehe nächster Abschnitt); die Größenordnung ist damit als Anhaltspunkt zu verstehen, nicht als exakter Messwert.

Für die Kalkulation eines eigenen Servers zählt neben der GPU auch der Rest des Systems: CPU, RAM, Lüfter und Netzteilverluste kommen bei einem vollausgestatteten Node unter Volllast mit weiteren 400 bis 600 Watt hinzu. Wer diese Zahlen einem TCO-Vergleich zwischen Neu- und Gebrauchtserver gegenüberstellt, sieht schnell, ab welchem Nutzungsvolumen sich die Anschaffung gegenüber laufenden Cloud-API-Kosten rechnet.

Was in der Praxis schiefging: Lessons Learned für den Produktivbetrieb

Ein Labortest ist nur so glaubwürdig wie sein Umgang mit den eigenen Fehlern. Acht dokumentierte Vorfälle bestimmten den zeitlichen Ablauf der drei Testtage und liefern für den Produktivbetrieb wertvollere Erkenntnisse als jede Erfolgsmeldung:

• Nach jedem Reboot brauchte die erste GPU-Initialisierung auf den HGX-A100-Boards rund 60 Sekunden. Ohne Wartelogik lief der Container-Start in einen Timeout, bevor die Treiber bereit waren.
• Die IP-over-InfiniBand-Adressen waren zunächst nur manuell gesetzt und fielen nach jedem Neustart aus, erst eine feste Netzplan-Konfiguration löste das dauerhaft.
• Der Modell-Download über eine langsame Leitung brach mehrfach ab, unter anderem wegen eines fehlerhaften Xet-Backends; stabil lief es erst nach dessen Abschaltung und Verteilung der Gewichte per InfiniBand statt doppeltem Download.
• Eine zu großzügige Kombination aus Batch-Größe, MTP und CUDA-Graphs führte zu einem Speicherüberlauf im KV-Cache, behoben durch eine niedrigere Batch-Größe und mehr Speicherreserve.
• Nach einem harten Container-Stopp blieb eine GPU als „belegt“ hängen und musste manuell freigegeben werden, ein sauberes Shutdown mit ausreichendem Timeout vermeidet das im Produktivbetrieb.

Von 23 durchgeführten Prüfungen bestanden 20 (sechs davon mit Einschränkung oder erst nach Korrektur), zwei schlugen endgültig fehl (Pipeline-Parallel und Expert-Parallel unter Last), eine Messung entfiel wegen der hängenden GPU. Für ein System, das drei Tage lang im Dauertest lief, ist das ein robustes Bild, vorausgesetzt, die dokumentierten Fallstricke sind vorher bekannt.

Lohnt sich ein A100-Server für den eigenen KI-Betrieb?

Die Zahlen aus diesem Test beantworten die Ausgangsfrage klar: Eine vier Jahre alte GPU-Generation ohne FP8-Unterstützung liefert mit dem richtigen Software-Stack noch immer produktionsreife Geschwindigkeiten, für ein 27B-Modell ebenso wie, mit Einschränkungen bei der Nutzerzahl, für ein aktuelles 397B-MoE-Modell. Für Unternehmen mit planbar hohem Token-Volumen und Anforderungen an Datenschutz oder DSGVO-Konformität kann ein eigener Server damit wirtschaftlicher sein als eine dauerhafte Abhängigkeit von Cloud-APIs, insbesondere, weil sensible Unternehmensdaten das eigene Netz nie verlassen.

Der Zugang zu genau dieser Hardware-Klasse ist dabei günstiger, als viele erwarten: HGX-A100-Systeme wie das getestete HPE Apollo 6500 kommen regelmäßig aus Leasing-Rückläufen, Rechenzentrums-Migrationen oder Insolvenzverfahren in den ITAD-Ankaufskanal, oft zu einem Bruchteil des ursprünglichen Neupreises, bei vollständiger technischer Prüfung und zertifizierter Datenlöschung der Vorbesitzer-Daten. Wer sich näher mit dem aktuellen Markt für KI-Server und GPU-Ankauf beschäftigt oder generell GPU-, KI- und HPC-Server kaufen möchte, findet dort auch abseits von A100-Systemen vergleichbare Sweet-Spots zwischen Preis und Leistung.
Ein Wermutstropfen bleibt: Ein solches System ist kein Plug-and-Play-Produkt. Die in diesem Test dokumentierten Stolperfallen, von der Kernel-Auswahl bis zur Netzwerk-Konfiguration, erfordern Ops-Wissen, das viele Unternehmen erst aufbauen oder einkaufen müssen. Wer diese Hürde nimmt, bekommt dafür eine Infrastruktur, die vollständig im eigenen Haus bleibt und sich nach der Anschaffung nicht mehr nach Tokens abrechnet.

Fazit

Drei Tage, zwei Server-Nodes, neun Benchmark-Reihen, und ein Ergebnis, das die Ausgangsfrage eindeutig beantwortet: Acht NVIDIA A100 GPUs ohne FP8-Unterstützung sind 2026 keineswegs obsolet für den Betrieb großer Sprachmodelle. Mit dem richtigen Software-Stack lieferte das getestete HPE-Apollo-6500-System 109 Tokens pro Sekunde für den Einzelnutzer bei einem 397-Milliarden-Parameter-Modell und über 5.000 Tokens pro Sekunde Gesamtdurchsatz bei einem schlanken 27-Milliarden-Parameter-Modell, Werte, die sich vor keiner aktuellen Cloud-API verstecken müssen.
Die wichtigste Erkenntnis war dabei keine Hardware-, sondern eine Software-Frage: Der Wechsel eines einzelnen Quantisierungs-Kernels brachte mehr Durchsatz als jede Netzwerk- oder Parallelisierungs-Optimierung zusammen. Wer Ampere-Systeme mit den für Hopper optimierten Standardeinstellungen betreibt, verschenkt einen Großteil der vorhandenen Leistung, unabhängig davon, wie neu oder alt die GPUs tatsächlich sind.

Für die Kaufentscheidung heißt das: Ein A100 GPU-Server aus zweiter Hand ist eine ernstzunehmende Alternative zu Cloud-APIs, wenn das Nutzungsvolumen hoch genug ist und die Bereitschaft besteht, sich mit Kernel-Auswahl, Netzwerk-Konfiguration und den in diesem Test dokumentierten Betriebsfallen auseinanderzusetzen. Die Hardware selbst ist dabei selten der limitierende Faktor: wie dieser Test zeigt, ist es fast immer die Konfiguration darüber.
Wer den vollständigen Satz an Messwerten oder die reproduzierbare Konfiguration dieses Tests benötigt, findet die Eckdaten in den Kennzahlen und Quellen dieses Artikels.

Hinweis zu diesem Beitrag: Inhalte auf diesem Blog werden mit Unterstützung von KI-Tools erstellt und von unserem Redaktionsteam recherchiert, fachlich geprüft und freigegeben.