{"id":2634,"date":"2026-09-14T16:49:10","date_gmt":"2026-09-14T14:49:10","guid":{"rendered":"https:\/\/www.it-resell.com\/blog\/?p=2634"},"modified":"2026-09-14T16:49:10","modified_gmt":"2026-09-14T14:49:10","slug":"blogs-a100-gpu-server-llm-inferenz","status":"publish","type":"post","link":"https:\/\/www.it-resell.com\/blog\/it-kaufberatung\/blogs-a100-gpu-server-llm-inferenz","title":{"rendered":"A100 GPU-Server f\u00fcr LLM-Inferenz: Labortest mit 8\u00d7 NVIDIA A100"},"content":{"rendered":"\n
5.187 tok\/s<\/b>Maximaler Gesamtdurchsatz mit Qwen3.6-27B \u00fcber beide Nodes bei 128 parallelen Anfragen<\/span><\/div>
109 tok\/s<\/b>Geschwindigkeit f\u00fcr den Einzelnutzer beim 397B-Modell, mit MTP Speculative Decoding<\/span><\/div>
Faktor 4,2<\/b>Mehr Durchsatz allein durch den richtigen Quantisierungs-Kernel (Marlin statt Triton)<\/span><\/div>
0,27 Wh<\/b>Energieverbrauch je 1.000 erzeugte Tokens beim 27B-Modell unter Volllast<\/span><\/div>
~250 Sessions<\/b>Realistische parallele Nutzerzahl mit dem 27B-Modell \u00fcber beide Nodes hinweg<\/span><\/div><\/div>\n\n\n\n

Kann eine vier Jahre alte NVIDIA-A100-Generation ohne FP8-Unterst\u00fctzung 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\u00fcr den Betrieb gro\u00dfer Sprachmodelle plant, st\u00f6\u00dft schnell auf dieselbe Frage: Reicht gebrauchte NVIDIA-A100-Hardware noch aus, oder f\u00fchrt an teurer Hopper- oder Blackwell-Generation kein Weg vorbei? Hersteller-Datenbl\u00e4tter beantworten das nicht: sie zeigen Peak-Werte unter Laborbedingungen, keine Praxis unter echter Last.<\/p>\n\n\n\n

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 \u00fcber zwei per InfiniBand gekoppelte Server-Nodes. Getestet wurden zwei aktuelle Open-Weight-Modelle, ein gro\u00dfes 397-Milliarden-Parameter-Modell und ein schlankes 27-Milliarden-Parameter-Modell, unter neun Benchmark-Konfigurationen.
Das Ergebnis \u00fcberrascht: Die entscheidende Stellschraube war nicht die Netzwerk-Bandbreite und nicht die Anzahl der GPUs, sondern eine einzige Software-Einstellung. Dieser Artikel zeigt die vollst\u00e4ndigen Zahlen, die Fehler unterwegs und was das f\u00fcr die Kaufentscheidung bedeutet.<\/p>\n\n\n\n

Das Testsystem: HPE Apollo 6500 Gen10 Plus mit 8\u00d7 NVIDIA A100<\/h2>\n\n\n\n

Das Testsystem bestand aus zwei HPE ProLiant XL645d Gen10 Plus Node-Servern im Apollo-6500-Chassis, dem Formfaktor, den HPE f\u00fcr dichte GPU-Workloads wie KI-Training und -Inferenz vorsieht [1]. Jeder Node war mit vier NVIDIA A100-SXM4-40GB-GPUs best\u00fcckt, intern per NVLink-Mesh verbunden, macht acht A100-GPUs mit insgesamt 320 GB HBM2-Speicher im Gesamtsystem.
Die beiden Nodes waren \u00fcber 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 \u00fcber 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\u00fcr Modellgewichte und gespiegelte SAS-Laufwerke f\u00fcr Daten.<\/p>\n\n\n\n

Software-seitig lief Ubuntu Server 24.04 mit NVIDIA-Treiber 580 und CUDA 13, containerisiert \u00fcber Docker mit dem NVIDIA Container Toolkit. Als Inferenz-Engine kam vLLM zum Einsatz, die etablierte Open-Source-L\u00f6sung f\u00fcr produktiven LLM-Betrieb, die auch vielen kommerziellen Inferenz-APIs zugrunde liegt.<\/p>\n\n\n\n

Ein Detail bestimmte die gesamte Modellauswahl: Ampere-GPUs wie die A100 unterst\u00fctzen 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 \u00fcber 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\u00e4hlt. \u00c4hnliche Einschr\u00e4nkungen gelten auch f\u00fcr andere Ampere-Systeme wie die HPE Smart Choice Server-Reihe.<\/p>\n\n\n\n

Testmethodik: Wie belastbar sind die Zahlen?<\/h2>\n\n\n\n

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\u00e4t von 1 \u00fcber 8, 32 und 64 bis zu 128 gleichzeitigen Anfragen.<\/p>\n\n\n\n

Drei Messgr\u00f6\u00dfen bestimmen jede Zeile in den folgenden Tabellen: der Output-Durchsatz in Tokens pro Sekunde (tok\/s) als Kapazit\u00e4t 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 \u00fcber den Health-Endpoint auf vollst\u00e4ndige Bereitschaft gepr\u00fcft, damit keine Anlaufzeiten die Ergebnisse verf\u00e4lschen.<\/p>\n\n\n\n

Das gro\u00dfe Modell: Qwen3.5-397B-A17B im Multi-Node-Betrieb<\/h2>\n\n\n\n

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\u00df f\u00fcr einen einzelnen 4-GPU-Node, weshalb das Modell mit Tensor-Parallel \u00fcber beide Nodes hinweg (TP=8) betrieben wurde, verteilt per InfiniBand.<\/p>\n\n\n\n

\"Konzeptgrafik<\/picture><\/figure>\n\n\n\n

Tensor-Parallel verteilt jede Schicht auf alle Karten, Pipeline-Parallel rechnet Schichtabschnitte nacheinander. Im Test war Tensor-Parallel deutlich schneller. (Quelle: IT-RESELL.COM)<\/em><\/p>\n\n\n\n

F\u00fcnf Konfigurationen, eine Erkenntnis: der Kernel entscheidet<\/h3>\n\n\n\n

Getestet wurden f\u00fcnf aufeinander aufbauende Betriebsvarianten desselben Modells, es \u00e4nderte sich nie das Modell, nur wie vLLM es \u00fcber die acht Karten verteilt und ausf\u00fchrt:<\/p>\n\n\n\n

    \n
  • Basis: <\/strong>Tensor-Parallel \u00fcber 8 GPUs mit generischem Triton-Kernel (Ausgangspunkt, offizielle Recipe-Vorgabe)<\/li>\n\n\n\n
  • PP: <\/strong>Pipeline-Parallel statt Tensor-Parallel, Test der Annahme, das Netzwerk sei der Engpass<\/li>\n\n\n\n
  • A (Marlin): <\/strong>gleicher Aufbau wie Basis, aber mit handoptimiertem Entpack-Kernel f\u00fcr die INT4-Gewichte<\/li>\n\n\n\n
  • B (+MTP): <\/strong>zus\u00e4tzlich Speculative Decoding (Multi-Token Prediction) f\u00fcr den Einzelnutzer<\/li>\n\n\n\n
  • C (+Async Scheduling): <\/strong>l\u00f6st die durch MTP verursachte Scheduler-Last bei vielen Nutzern wieder auf<\/li>\n\n\n\n
  • D (+Expert Parallel): <\/strong>verteilt ganze MoE-Experten statt Schichtscheiben auf die Karten<\/li>\n<\/ul>\n\n\n\n\n\n