Zuletzt überprüft: Juni 2026
Eine übersichtliche Referenz der Architekturmuster, die in der NCA-AIIO-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Entscheiden Sie, ob eine Arbeitslast auf GPUs oder CPUs ausgeführt werden soll.
Massiv parallele Mathematik (Deep-Learning-Training/Inferenz, Matrix-Operationen, Simulation) → GPU. Serielle, verzweigungsintensive Steuerlogik, OS-Aufgaben, leichte E/A → CPU.
Warum: GPUs verfügen über Tausende von Kernen, die für den Durchsatz bei parallelen SIMT-Arbeiten optimiert sind; CPUs sind bei latenzempfindlicher serieller Logik überlegen. Die meisten KI-Systeme kombinieren beides.
Wählen Sie den NVIDIA-Baustein: eine komplette Appliance vs. eine Platine für OEM-Systeme.
Schlüsselfertiger integrierter KI-Server (GPUs + CPUs + NVLink + Netzwerk + Software) → DGX. GPU-Basisplatine, um die herum OEMs/Cloud-Anbieter Server bauen → HGX.
Warum: DGX ist NVIDIAs sofort einsatzbereites Referenzsystem; HGX ist die Multi-GPU-Platine, die Hyperscaler selbst integrieren.
GPUs in einem Server benötigen eine schnellere GPU-zu-GPU-Bandbreite, als der Bus bietet.
Verwenden Sie NVLink (und NVSwitch für All-to-All) für eine GPU-Verbindung mit hoher Bandbreite innerhalb eines Knotens; PCIe ist der Ersatz, wenn NVLink nicht verfügbar ist.
Warum: NVLink liefert eine weitaus höhere GPU-zu-GPU-Bandbreite und geringere Latenz als PCIe — entscheidend für modellparalleles und Large-Batch-Training innerhalb eines Knotens.
Alle 8 GPUs in einem Knoten müssen gleichzeitig mit voller NVLink-Bandbreite miteinander kommunizieren.
NVSwitch — ein nicht-blockierendes Switch-Fabric, das jede GPU mit jeder anderen GPU mit voller NVLink-Geschwindigkeit verbindet.
Warum: Punkt-zu-Punkt-NVLink allein bietet keine All-to-All-Bandbreite; NVSwitch stellt das Crossbar für die vollständige GPU-Mesh-Kommunikation bereit.
Unterscheiden Sie Scale-up (innerhalb eines Servers) von Scale-out (über Server hinweg) Interconnect.
Scale-up GPU-Verbindung innerhalb eines Knotens → NVLink/NVSwitch. Scale-out über Knoten in einem Cluster hinweg → InfiniBand (oder RoCE Ethernet).
Warum: NVLink ist internode; InfiniBand verbindet Knoten zu einem Cluster für verteiltes Multi-Node-Training.
Wählen Sie das Cluster-Fabric für groß angelegtes verteiltes Training, bei dem die Latenz kollektiver Operationen am wichtigsten ist.
Geringste Latenz, In-Network-Compute (SHARP), RDMA-nativ → InfiniBand. Vertraut, kostengünstiger, breites Ökosystem → RoCE auf Spectrum-X Ethernet.
Warum: InfiniBand mit SHARP lagert All-Reduce in den Switch aus, was die kollektive Latenz reduziert; Spectrum-X ist NVIDIAs Ethernet-Antwort für AI fabrics.
Lagern Sie Netzwerk-, Speicher- und Sicherheitsprozessierung von der CPU aus, damit Kerne für KI-Berechnungen frei werden.
NVIDIA BlueField DPU — programmierbare Datenverarbeitungseinheit, die Infrastrukturdienste von der Host-CPU/GPU auslagert und isoliert.
Warum: DPUs beschleunigen East-West-Networking, NVMe-oF-Speicher und Zero-Trust-Sicherheit, wodurch die effektive GPU/CPU-Auslastung und die Mandantenisolation erhöht werden.
Benötigen Sie eine Hochgeschwindigkeits-RDMA-NIC für GPU-Knoten ohne vollständige DPU-Auslagerung.
NVIDIA ConnectX SmartNIC — Hochdurchsatz-InfiniBand/Ethernet-Adapter mit RDMA- und GPUDirect-Unterstützung.
Warum: ConnectX bietet Leitungsraten-RDMA; BlueField fügt ein programmierbares Arm-Subsystem hinzu für vollständige Infrastruktur-Auslagerung.
Reduzieren Sie die Latenz, indem Sie Daten direkt in den GPU-Speicher verschieben, ohne den Umweg über den CPU-/Host-Speicher zu nehmen.
GPUDirect RDMA — NICs lesen/schreiben direkt in den GPU-Speicher; GPUDirect Storage tut dasselbe für NVMe-Speicher.
Warum: Das Umgehen des CPU-Bounce-Puffers eliminiert Kopien und Latenz im Datenpfad, was für den Multi-Node-Trainingsdurchsatz entscheidend ist.
Wählen Sie eine aktuelle Data-Center-GPU-Architektur für das Training großer Modelle.
Hopper (H100/H200) ist die etablierte Generation mit Transformer Engine + FP8; Blackwell (B200/GB200) ist die neuere Generation mit höherem Durchsatz und FP4 für die größten Modelle.
Warum: Beide zielen auf Transformer-Workloads ab; Blackwell treibt Skalierung und Inferenz mit geringerer Präzision (FP4) weiter voran. Passen Sie an Budget und Modellgröße an.
Identifizieren Sie die Hardware, die die Deep-Learning-Matrix-Mathematik beschleunigt.
Tensor Cores — spezialisierte Einheiten, die Fused Matrix-Multiply-Accumulate mit gemischter Präzision (FP16/BF16/FP8/FP4) durchführen.
Warum: Sie liefern einen um Größenordnungen höheren Durchsatz bei GEMM/Konvolution als Standard-CUDA-Kerne, was die DL-Leistung vorantreibt.
Ein großes Modell passt nicht; die Speicherbandbreite, nicht die Rechenleistung, ist der Engpass.
Wählen Sie GPUs mit mehr und schnellerem HBM (z.B. H200/B200 mit HBM3e); verwenden Sie Multi-GPU-Modellparallelismus, wenn der Speicher einer GPU nicht ausreicht.
Warum: Training/Inferenz großer Modelle ist oft durch Speicherkapazität und Bandbreite begrenzt; HBM bietet die hohe Bandbreite, die GPUs benötigen.
Stellen Sie einen schlüsselfertigen, validierten Multi-Rack-KI-Supercomputer für das Unternehmenstraining bereit.
NVIDIA DGX SuperPOD — Referenzarchitektur von DGX-Knoten, InfiniBand-Fabric, Speicher und Base Command software.
Warum: SuperPOD ist das vorvalidierte Full-Stack-Design; es beseitigt das Rätselraten bei der Verkabelung von Fabric, Speicher und Orchestrierung im großen Maßstab.
Erhalten Sie Trainingskapazität der DGX-Klasse, ohne die Hardware zu besitzen.
NVIDIA DGX Cloud — verwaltete KI-Trainingsinfrastruktur, die bei großen Cloud-Anbietern gehostet und als Dienst bereitgestellt wird.
Warum: OpEx vs. CapEx: DGX Cloud eignet sich für sprunghaftes oder kurzfristiges Training; On-Prem DGX/SuperPOD eignet sich für anhaltend hohe Auslastung und Data-Gravity-Einschränkungen.
Wählen Sie On-Premises-GPU-Cluster vs. Cloud-GPUs für KI-Workloads.
Anhaltend hohe Auslastung, Datenhoheit, vorhersehbare Ausgaben → On-Prem DGX/SuperPOD. Variable/sprunghafte Nachfrage, schneller Start, kein Rechenzentrums-Footprint → Cloud oder DGX Cloud.
Warum: Eigene GPUs amortisieren sich nur bei hoher, gleichmäßiger Auslastung gut; ungenutzte eigene Hardware ist reine Kosten.
Ein neuer GPU-Cluster überschreitet das Rack-Strom- und Kühlbudget eines bestehenden Rechenzentrums.
Planen Sie für die neuesten GPUs eine hohe Stromdichte (zehn kW/Rack) und Flüssigkeitskühlung; dimensionieren Sie PDUs, Stromschienen und die thermische Kapazität vor der Installation.
Warum: Moderne GPU-Knoten (und GB200-Racks) benötigen weitaus mehr Strom und erzeugen mehr Wärme als ältere Server; Luftkühlung und Standard-PDUs können oft nicht mithalten.
Das Training stockt, weil die Datenpipeline die GPUs nicht schnell genug versorgen kann.
Verwenden Sie einen parallelen/NVMe-Speicher mit hohem Durchsatz und GPUDirect Storage; dimensionieren Sie ihn für eine anhaltende Lesebandbreite, um GPUs gesättigt zu halten.
Warum: Unterdimensionierte Speicher-E/A lässt teure GPUs untätig auf Daten warten; die Speicherebene muss dem aggregierten GPU-Leseanforderungsbedarf entsprechen.
Ein Modell ist zu groß, um innerhalb einer akzeptablen Zeit auf einem einzelnen Knoten trainiert zu werden.
Skalieren Sie auf mehrere Knoten über InfiniBand mithilfe von Daten-/Tensor-/Pipeline-Parallelismus; NCCL übernimmt die kollektive GPU-Kommunikation.
Warum: Multi-Node-Skalierung erfordert ein Fabric mit geringer Latenz und eine optimierte Kollektivbibliotheks (NCCL); ein langsames Fabric vernichtet die Skalierungseffizienz.
Ein einzelner A100/H100 ist überdimensioniert für kleine Inferenz-Jobs; Sie möchten hardware-isolierte Slices.
Multi-Instance GPU (MIG) — teilt eine GPU in bis zu 7 isolierte Instanzen auf, jede mit dedizierter Rechenleistung und Speicher.
Warum: MIG bietet echte Hardware-Isolation und vorhersagbare QoS für Multi-Tenant-Inferenz, im Gegensatz zum Soft Time-Slicing.
Unterscheiden Sie KI vs. maschinelles Lernen vs. Deep Learning.
KI ist das übergeordnete Ziel; ML ist eine Untermenge, die aus Daten lernt; DL ist eine Untermenge von ML, die mehrschichtige neuronale Netze verwendet.
Warum: Sie sind verschachtelt: DL ⊂ ML ⊂ KI. DL treibt die Nachfrage nach modernen GPUs an, weil neuronale Netze massiv parallel sind.
Unterscheiden Sie das Rechenprofil von Training und Inferenz.
Training = rechen- und speicherintensiv, langlaufend, Batch, viele GPUs. Inferenz = latenzempfindlich, leichter, oft einzelne/Teil-GPU, läuft kontinuierlich in Produktion.
Warum: Sie haben unterschiedliche Hardware- und Skalierungsanforderungen; die Dimensionierung eines Clusters erfordert die Trennung der beiden Workloads.
Wählen Sie ein Lernparadigma: gelabelte Daten, ungelabelte Daten oder belohnungsgesteuertes Versuch-und-Irrtum.
Gelabelt → überwacht. Ungelabeltes Clustering/Struktur → unüberwacht. Agent lernt aus Belohnung → Reinforcement Learning.
Warum: Die vorhandenen Daten (und das Ziel) bestimmen das Paradigma; RLHF ist Reinforcement Learning, das durch menschliches Feedback gesteuert wird, um LLMs auszurichten.
Erklären Sie, warum neuronale Netze gut auf GPUs abgebildet werden können.
Sie sind Schichten von gewichteten Matrixmultiplikationen und nichtlinearen Aktivierungen – dichte parallele lineare Algebra, die GPUs effizient ausführen.
Warum: Forward-/Backward-Pässe sind GEMM-intensiv; Tensor Cores beschleunigen genau dies, weshalb DL auf GPUs läuft.
Identifizieren Sie die Architektur hinter modernen LLMs und generativer KI.
Der Transformer — eine auf Attention basierende Architektur, die mit Daten und Parametern skaliert; Foundation Models und LLMs basieren darauf.
Warum: Transformer sind hochgradig parallelisierbar, weshalb sie die Nachfrage nach großen GPU-Clustern und Transformer Engine Hardware antreiben.
Beschleunigen Sie das Training und reduzieren Sie den Speicherverbrauch, ohne die Genauigkeit wesentlich zu beeinträchtigen.
Verwenden Sie gemischte Präzision — FP16/BF16 (und FP8 auf Hopper/Blackwell) für Berechnungen, FP32 für die Akkumulation; Tensor Cores beschleunigen Operationen mit geringerer Präzision.
Warum: Geringere Präzision halbiert den Speicher und vervielfacht den Durchsatz; Loss Scaling / BF16 erhält die numerische Stabilität.
Nennen Sie die Grundlage, die es Software ermöglicht, auf NVIDIA GPUs zu laufen.
CUDA — NVIDIAs Parallel-Computing-Plattform und Programmiermodell; CUDA-X ist die Bibliotheksschicht (cuDNN, cuBLAS, NCCL, RAPIDS, etc.).
Warum: Frameworks wie PyTorch/TensorFlow rufen unter der Haube CUDA-X-Bibliotheken auf; CUDA ist die Technologie, die KI-Software an NVIDIA GPUs bindet.
Beschleunigen Sie Deep-Learning-Primitive (Konvolutionen, Attention) innerhalb eines Frameworks.
cuDNN bietet GPU-optimierte DL-Primitive; cuBLAS verarbeitet dichte lineare Algebra; beide sitzen unter PyTorch/TensorFlow.
Warum: Diese Bibliotheken sind der Grund, warum Frameworks GPU-Geschwindigkeit erhalten, ohne dass Sie CUDA-Kernels schreiben müssen.
Erhalten Sie NVIDIA-optimierte, GPU-fähige Container, Modelle und Helm-Charts.
NGC (NVIDIA GPU Cloud) Katalog — kuratierte Registrierung von optimierten Containern (Frameworks, NIM, Triton), vortrainierten Modellen und SDKs.
Warum: NGC-Container sind für NVIDIA GPUs abgestimmt und getestet, wodurch Abhängigkeits- und Treiberkompatibilitäts-Ratespiele entfallen.
Stellen Sie viele Modelle aus mehreren Frameworks hinter einem standardisierten, GPU-effizienten Endpunkt bereit.
NVIDIA Triton Inference Server — Multi-Framework-Modellbereitstellung mit dynamischem Batching, gleichzeitiger Modellausführung und GPU-Sharing.
Warum: Triton maximiert die GPU-Auslastung für die Inferenz durch Batching und Modellparallelität anstelle eines Prozesses pro Modell.
Stellen Sie ein Foundation Model schnell als produktionsreifer, optimierter Inferenz-Microservice bereit.
NVIDIA NIM — vorgefertigte, containerisierte Inferenz-Microservices mit optimierten Engines und Standard-APIs für gängige Modelle.
Warum: NIM packt Modell + optimierte Laufzeit (TensorRT-LLM/Triton) + API in eine deploybare Einheit und verkürzt die Time-to-Production.
Reduzieren Sie die Inferenzlatenz und erhöhen Sie den Durchsatz für ein trainiertes Modell.
Kompilieren Sie das Modell mit TensorRT (oder TensorRT-LLM für LLMs) — Layer-Fusion, Präzisionskalibrierung (INT8/FP8) und Kernel-Auto-Tuning.
Warum: TensorRT erzeugt eine optimierte Inferenz-Engine für die Ziel-GPU, die den Durchsatz gegenüber dem reinen Framework oft vervielfacht.
Beschleunigen Sie Datenvorbereitung im Pandas-/Scikit-learn-Stil und klassisches ML auf GPUs.
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (Graphen) führen den Data-Science-Workflow auf GPUs aus.
Warum: RAPIDS hält tabellarische ETL und klassisches ML auf der GPU und vermeidet CPU-Engpässe in der Pipeline.
Verwalten Sie KI-Workloads, Jobs und Benutzer in einem DGX/SuperPOD-Cluster.
NVIDIA Base Command — Job-Scheduling, Cluster-Management und Workload-Orchestrierung für DGX-Infrastruktur.
Warum: Base Command ist die Betriebssteuerungsebene für DGX-Systeme; es verwaltet die Job-Einreichung durch mehrere Benutzer und die Ressourcenverfolgung.
Benötigen Sie unterstützte, sichere, produktionsreife KI-Software mit Enterprise-SLAs.
NVIDIA AI Enterprise — die unterstützte Software-Suite (Frameworks, NIM, Triton, RAPIDS, GPU Operator) mit Sicherheitspatches und Enterprise-Support.
Warum: Es bündelt den validierten Stack mit Support- und Lebenszyklusgarantien, die von regulierten/Produktionsumgebungen benötigt werden.
Definieren Sie ein Foundation Model und wie Teams es anpassen.
Großes Modell, vortrainiert auf breiten Daten, anpassbar an viele Aufgaben über Prompting, RAG oder Fine-Tuning, anstatt von Grund auf neu zu trainieren.
Warum: Die Anpassung (Prompt/RAG/Fine-Tune) ist weitaus günstiger als das Vortraining; die meisten Unternehmen nutzen Foundation Models, anstatt sie selbst zu erstellen.
Fügen Sie einer LLM-gestützten Anwendung privates/aktuelles Wissen hinzu.
Häufig wechselnde Fakten → RAG (Abruf aus einem Vector Store bei der Inferenz). Neues Verhalten/Stil/Domänenkenntnisse lehren → Fine-Tuning.
Warum: RAG hält Daten extern und aktualisierbar ohne erneutes Training; Fine-Tuning integriert Verhalten in Gewichte und ist kostspieliger zu aktualisieren.
Beurteilen Sie, ob teure GPUs effizient genutzt werden.
Überwachen Sie GPU-Auslastung, Speichernutzung und SM-/Tensor-Core-Aktivität; geringe Auslastung signalisiert Engpässe in der Datenpipeline, Batch-Größe oder im Scheduling.
Warum: Eine hohe "Beschäftigung" der GPU in Echtzeit kann immer noch eine geringe effektive Rechenleistung verschleiern; achten Sie auf die Tensor-Core-/SM-Auslastung, nicht nur auf die Auslastungsanzeige.
Überwachen Sie GPU-Zustand, Auslastung, Temperatur, Leistung und Fehler in einem Cluster.
NVIDIA DCGM (Data Center GPU Manager) — Telemetrie, Gesundheitsprüfungen und Diagnosen; exportieren Sie Metriken nach Prometheus/Grafana.
Warum: DCGM ist die Standard-GPU-Telemetriequelle; der DCGM Exporter speist Prometheus für clusterweite Dashboards und Warnmeldungen.
Stellen Sie GPU-Treiber, das Container-Toolkit und Monitoring in einem Kubernetes-Cluster bereit, ohne manuelle Einrichtung pro Knoten.
NVIDIA GPU Operator — automatisiert Treiber, Container-Laufzeit, Device Plugin, DCGM und MIG-Konfiguration auf Kubernetes.
Warum: Er verwaltet den gesamten GPU-Software-Lebenszyklus deklarativ und eliminiert fragile Treiberinstallationen von Knoten zu Knoten.
Wählen Sie einen Orchestrator für GPU-Workloads.
Microservices/Inferenz, Cloud-nativ, gemischte Workloads → Kubernetes. Batch-Training-Jobs im HPC-Stil, Gang Scheduling, traditionelle Cluster → Slurm.
Warum: Kubernetes zeichnet sich durch langlebige Dienste und Elastizität aus; Slurm zeichnet sich durch in die Warteschlange gestellte Batch-Jobs mit MPI-ähnlichem Scheduling aus.
Kubernetes-Pods müssen GPUs anfordern und auf ihnen geplant werden.
Das NVIDIA Device Plugin kündigt GPUs als planbare Ressourcen an; Pods fordern `nvidia.com/gpu` an und der Scheduler platziert sie.
Warum: Ohne das Device Plugin kann Kubernetes GPUs nicht sehen oder zuweisen; es ist das, was GPUs zu einer erstklassigen Ressource macht.
Viele kleine Jobs/Benutzer müssen GPUs teilen, um die Auslastung zu erhöhen.
Hardware-Isolation → MIG. Soft Sharing einer GPU → Time-Slicing oder MPS. Kombinieren Sie dies mit Namespace-Quotas für Fairness.
Warum: MIG bietet QoS-Garantien; Time-Slicing/MPS überbuchen eine GPU ohne Isolation. Wählen Sie entsprechend der Isolationsanforderung aus.
Hochprioritäres Training muss niedrigprioritäre Experimente in einem gemeinsam genutzten Cluster präemptieren.
Verwenden Sie Priorität/Präemption und Warteschlangen im Scheduler (Slurm-Partitionen oder Kubernetes PriorityClasses mit Kontingent); planen Sie Multi-GPU-Jobs im Gang-Scheduling.
Warum: Gang Scheduling verhindert Deadlocks bei teilweiser Zuweisung; Prioritätsklassen erzwingen die Geschäftsreihenfolge auf umkämpften GPUs.
Halten Sie GPU-Treiber, CUDA- und Container-Toolkit-Versionen über alle Knoten hinweg konsistent und kompatibel.
Standardisieren Sie über den GPU Operator (Kubernetes) oder NGC-Container; passen Sie den Treiber an die CUDA-Versionen an, die Ihre Frameworks benötigen, und spielen Sie Updates in Wartungsfenstern ein.
Warum: Treiber-/CUDA-/Framework-Diskrepanzen sind eine Hauptursache für Cluster-Fehler; Container-gebundenes CUDA entkoppelt die Anwendung vom Host-Treiber innerhalb unterstützter Bereiche.
Dimensionieren Sie einen GPU-Cluster für den prognostizierten Trainings- und Inferenzbedarf.
Trennen Sie Training (Spitzenlast, Batch) von Inferenz (anhaltend, latenzgebunden); planen Sie Strom-/Kühlungs-/Fabric-Spielraum und streben Sie eine hohe gleichmäßige Auslastung an.
Warum: Überdimensionierung verschwendet CapEx für ungenutzte GPUs; Unterdimensionierung drosselt die Bereitstellung. Planen Sie für den Workload-Mix, nicht für eine einzelne Spitze.
GPUs drosseln oder fallen unter anhaltender starker Last aus.
Überwachen Sie Temperatur und Leistung über DCGM; stellen Sie ausreichende Kühlung sicher (Flüssigkeitskühlung für dichte Racks), legen Sie sinnvolle Leistungslimits fest und alarmieren Sie bei thermischen Schwellenwerten.
Warum: Thermisches Throttling reduziert stillschweigend den Durchsatz; proaktive Telemetrie und Kühlungsdesign schützen sowohl die Leistung als auch die Hardware-Lebensdauer.
Stellen Sie mehreren VMs oder VDI-Benutzern GPU-Beschleunigung von gemeinsam genutzter Hardware bereit.
Die NVIDIA vGPU Software partitioniert eine physische GPU über VMs mit Scheduling und Isolation; MIG kann vGPU-Profile für harte Partitionierung unterstützen.
Warum: vGPU ermöglicht virtualisierten/Multi-Tenant-GPU-Zugriff (VDI, Cloud), den Bare-Metal-Passthrough nicht teilen kann.
Ein Knoten gibt Xid-Fehler oder fehlgeschlagene Jobs zurück; Sie müssen fehlerhafte GPUs isolieren, bevor sie weitere Läufe korrumpieren.
Führen Sie DCGM-Diagnosen und aktive Gesundheitsprüfungen durch; isolieren/leeren Sie den Knoten, ersetzen oder setzen Sie die GPU zurück und geben Sie sie erst dann in den Pool zurück.
Warum: Xid-Fehler und ECC-Fehler kennzeichnen ausfallende GPUs; automatisiertes Health Gating verhindert, dass eine fehlerhafte GPU den Scheduling-Pool vergiftet.