Zuletzt überprüft: Juni 2026
Eine übersichtliche Referenz der Architekturmuster, die in der NCP-GENL-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Benötigen geringere Latenz auf H100/Blackwell ohne den Genauigkeitsverlust aggressiver INT quantization.
Verwenden Sie FP8 (E4M3) quantization über TensorRT-LLM; Hopper und Blackwell verfügen über native FP8 Tensor Cores.
Warum: FP8 bewahrt den dynamischen Bereich besser als INT8 und läuft mit voller Hardwaregeschwindigkeit auf Hopper+, was eine Qualität nahe FP16 bei einem Durchsatz der INT8-Klasse bietet.
Modell passt kaum in den GPU-Speicher und der Durchsatz ist durch die Speicherbandbreite begrenzt.
Wenden Sie INT4 weight-only quantization (AWQ oder GPTQ) an; halten Sie activations in FP16/FP8.
Warum: Weight-only INT4 halbiert den Speicher im Vergleich zu INT8 und reduziert den Bandbreitendruck; die activation precision bleibt hoch, so dass der Genauigkeitsverlust gering ist.
Entscheidung zwischen post-training quantization und quantization-aware training.
Beginnen Sie mit PTQ (Kalibrierung an einer repräsentativen Stichprobe); greifen Sie nur auf QAT zurück, wenn der PTQ-Genauigkeitsverlust das Budget überschreitet.
Warum: PTQ ist schnell und benötigt kein Umschulung; QAT stellt die Genauigkeit wieder her, kostet aber einen Trainingslauf, daher sollte es für präzisionskritische Modelle reserviert werden.
Long-context serving, bei dem der KV cache den Speicher dominiert und die Batch-Größe begrenzt.
Aktivieren Sie FP8 oder INT8 KV-cache quantization in TensorRT-LLM.
Warum: Der KV cache wächst mit der Sequenzlänge × Batch; seine Quantisierung gibt Speicher für größere Batches und längere Kontexte mit minimaler Qualitätseinbuße frei.
Gemischte Anforderungslängen verursachen GPU-Leerlaufzeiten bei statischem Batching.
Verwenden Sie in-flight (kontinuierliches) Batching in TensorRT-LLM, sodass abgeschlossene Sequenzen entfernt werden und neue mitten im Flug hinzukommen.
Warum: Kontinuierliches Batching hält die GPU ausgelastet und erhöht den Durchsatz für heterogene Anforderungsströme weit über statisches Batching hinaus.
Ein großes teacher model erfüllt die Qualität, verfehlt aber die Latenz- und Kostenziele.
Destillieren Sie es zu einem kleineren student model und quantisieren Sie den student für die inference.
Warum: Distillation überträgt Fähigkeiten auf eine kostengünstigere Architektur; in Kombination mit quantization potenziert es die Kosten-/Latenzeinsparungen.
Die Latenz eines einzelnen Streams ist für einen interaktiven Anwendungsfall zu hoch.
Wenden Sie speculative decoding mit einem kleinen draft model an, das vom target model verifiziert wird.
Warum: Der draft schlägt mehrere tokens vor, die das große Modell in einem Durchlauf verifiziert, wodurch die Wall-Clock-Latenz reduziert wird, ohne die Ausgabeverteilung zu ändern.
Die Quantisierung von allem auf INT4 beeinträchtigt die Genauigkeit in einigen wenigen sensiblen Schichten stark.
Verwenden Sie mixed-precision: Behalten Sie sensible Schichten (z.B. finale Projektion, attention) in höherer Präzision und quantisieren Sie den Rest.
Warum: Die Schichtempfindlichkeit variiert; selektive Präzision schützt die Genauigkeit dort, wo es wichtig ist, während der Großteil der Gewichte immer noch reduziert wird.
Die PTQ-Genauigkeit ist trotz eines vernünftigen Quantisierungsschemas schlecht.
Rekalibrieren Sie mit einer In-Distribution-Stichprobe (Hunderte repräsentativer Prompts), die dem Produktionsverkehr entspricht.
Warum: Die Kalibrierung legt die activation ranges fest; eine nicht repräsentative Stichprobe führt zu schlechten Skalen und vermeidbaren Genauigkeitsverlusten.
Modellgewichte überschreiten eine einzelne GPU, passen aber in einen NVLink-verbundenen Knoten.
Verwenden Sie tensor parallelism über die GPUs im Knoten hinweg.
Warum: Tensor parallelism zerlegt jede Schicht und tauscht activations bei jedem Schritt aus, daher benötigt es die hohe Intra-Node-Bandbreite von NVLink/NVSwitch.
Das Modell ist zu groß für einen Knoten und muss sich über Knoten via InfiniBand erstrecken.
Fügen Sie pipeline parallelism über Knoten hinweg hinzu, wobei tensor parallelism innerhalb jedes Knotens beibehalten wird.
Warum: Pipeline parallelism kommuniziert nur an Stufengrenzen, wodurch langsamere Inter-Node-Verbindungen toleriert werden; reservieren Sie bandbreitenintensives tensor parallel für NVLink.
Das Skalieren auf mehr GPUs führt zu abnehmenden Durchsatzgewinnen.
Profilen Sie mit Nsight Systems, um den Engpass zu klassifizieren; wenn collectives dominieren, reduzieren Sie den Parallelisierungsgrad oder verbessern Sie die Topologie.
Warum: Ab einem bestimmten Punkt überwiegt der all-reduce/all-gather-Overhead die zusätzliche Rechenleistung; die Diagnose, ob es kommunikations- oder rechengebunden ist, leitet die Behebung.
Der Kernel-Launch-Overhead pro Schritt erhöht die decode-Latenz bei kleinen Batch-Größen.
Aktivieren Sie CUDA Graphs, um die decode-Schleife zu erfassen und wiederzugeben.
Warum: CUDA Graphs fassen viele kleine Launches zu einer Wiederholung zusammen, wodurch der CPU-seitige Launch-Overhead eliminiert wird, der bei geringen Batch-Größen dominiert.
Tensor-parallel ranks, die über eine langsame Verbindung platziert sind, verursachen Verzögerungen.
Fixieren Sie tensor-parallel ranks an GPUs, die NVLink/NVSwitch teilen; platzieren Sie pipeline stages über Knoten hinweg.
Warum: Eine fehlerhafte Platzierung leitet hochfrequente collectives über PCIe oder InfiniBand und drosselt die gesamte Pipeline.
Attention ist speichergebunden und begrenzt die erreichbare Kontextlänge.
Verwenden Sie FlashAttention (fused, IO-aware attention kernels), wie sie vom TensorRT-LLM/NeMo Stack bereitgestellt werden.
Warum: FlashAttention vermeidet die Materialisierung der vollständigen attention matrix, reduziert den Speicherverkehr und ermöglicht längere Sequenzen mit höherer Geschwindigkeit.
Mehrere kleine Modelle nutzen H100 GPUs nicht vollständig aus.
Partitionieren Sie GPUs mit MIG (Multi-Instance GPU), um jedes Modell auf einem Slice zu isolieren.
Warum: MIG bietet hardware-isolierte Partitionen, erhöht die Auslastung und bietet vorhersehbare QoS für gemeinsam genutzte kleine Workloads.
Nachgeschalteter Dienst benötigt jedes Mal strikt gültiges JSON.
Verwenden Sie guided/constrained decoding (Grammatik oder JSON-Schema) in der Serving-Laufzeit, anstatt sich nur auf die Formulierung des Prompts zu verlassen.
Warum: Constrained decoding maskiert ungültige tokens zur Generierungszeit und garantiert eine Schema-gültige Ausgabe, während prompting die Fehlerrate nur reduziert.
Aufgabe erfordert ein konsistentes Format, das das Basismodell inkonsistent verarbeitet.
Versuchen Sie zuerst few-shot exemplars; wechseln Sie nur zur Feinabstimmung, wenn die prompt-basierte Steuerung stagniert oder die token-Kosten übermäßig sind.
Warum: Few-shot ist training-frei und sofort editierbar; Feinabstimmung gewinnt nur, wenn Muster stabil sind und der prompt-Overhead schadet.
Mehrstufige Reasoning-Aufgabe liefert falsche Endergebnisse.
Fordern Sie eine chain-of-thought ('Schritt für Schritt denken') an oder verwenden Sie eine strukturierte Reasoning-Vorlage vor der endgültigen Antwort.
Warum: Das Offenlegen von Zwischenschritten verbessert die Multi-Hop-Genauigkeit und macht Fehler überprüfbar, auf Kosten zusätzlicher tokens.
Eine kleine Prompt-Änderung führte stillschweigend zu einer Qualitätsminderung in der Produktion.
Versionieren Sie system prompts als Code, sichern Sie Änderungen durch Evaluierung ab und rollen Sie sie über dieselbe CI wie Modellartefakte aus.
Warum: Prompts sind Teil des Modellvertrags; unversionierte Bearbeitungen führen zu unnachverfolgten Regressionen und nicht reproduzierbarem Verhalten.
Modell halluziniert Fakten außerhalb seiner Trainingsdaten.
Rufen Sie relevanten Kontext ab und injizieren Sie ihn in den Prompt mit der Anweisung, nur aus dem bereitgestellten Kontext zu antworten.
Warum: Die Erdung auf abgerufenen Passagen beschränkt das Modell auf Quellmaterial und reduziert Halluzinationen bei wissensintensiven Abfragen.
Latenz und Kosten sind hoch, weil Prompts überladen sind.
Kürzen und komprimieren Sie den Prompt: Anweisungen deduplizieren, abgerufenen Kontext zusammenfassen und exemplars auf das Minimum begrenzen, das die Qualität hält.
Warum: Prefill skaliert mit Eingabe-tokens; schlanke Prompts reduzieren sowohl die Latenz als auch die Kosten pro Anfrage ohne messbaren Qualitätsverlust.
Benutzerdefinierter Text kann die Systemanweisung überschreiben.
Trennen Sie vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Eingaben mit klaren Begrenzern und behandeln Sie abgerufene/Benutzerinhalte als Daten, nicht als Befehle.
Warum: Das Verketten von nicht vertrauenswürdigem Text in den Anweisungskanal lädt zu prompt injection ein; explizite Grenzen reduzieren die Angriffsfläche.
Anpassung eines großen Basismodells an eine Domäne mit begrenztem GPU-Budget.
Verwenden Sie LoRA: Trainieren Sie low-rank adapters und frieren Sie die Basisgewichte ein.
Warum: LoRA trainiert einen winzigen Bruchteil der Parameter, wodurch Speicher und Rechenleistung drastisch reduziert werden, während es bei den meisten eng definierten Aufgaben dem vollständigen fine-tuning entspricht.
Selbst das LoRA-Training eines 70B-Modells passt nicht in den verfügbaren Speicher.
Verwenden Sie QLoRA: Quantisieren Sie die eingefrorene Basis auf 4-bit (NF4) und trainieren Sie LoRA adapters darauf.
Warum: Das Halten der Basis in 4-bit, während nur adapters aktualisiert werden, ermöglicht das fine-tuning großer Modelle auf einer einzelnen GPU mit minimalem Genauigkeitsverlust.
Auswahl des LoRA-Rangs für eine neue Fine-Tuning-Aufgabe.
Beginnen Sie mit einem bescheidenen Rang (z.B. 8-16); erhöhen Sie ihn nur, wenn die Aufgabe komplex ist und der Validierungsverlust sich noch verbessert.
Warum: Ein höherer Rang erhöht Kapazität und Kosten; ein zu hoher Rang birgt das Risiko des Overfitting bei kleinen Datensätzen, während ein zu niedriger Rang die erreichbare Qualität begrenzt.
Modell folgt Anweisungen, aber seine Ausgaben entsprechen nicht der menschlichen Präferenz.
Führen Sie zuerst supervised fine-tuning durch, dann preference alignment mit RLHF oder DPO.
Warum: SFT lehrt das Format und die Aufgabe; preference optimization formt, welche gültigen Antworten Menschen tatsächlich bevorzugen.
RLHF mit PPO ist instabil und betrieblich aufwendig.
Verwenden Sie DPO (Direct Preference Optimization) auf einem preference dataset anstelle eines reward model + PPO loop.
Warum: DPO optimiert Präferenzen direkt ohne separates reward model oder RL rollout, was die Pipeline vereinfacht und die Stabilität verbessert.
LoRA adapter verursacht pro Anfrage Overhead zur Serving-Zeit.
Führen Sie die Adaptergewichte für die Bereitstellung in die Basis zusammen, wenn nur ein Adapter verwendet wird.
Warum: Ein zusammengeführtes Modell hat zur inference keine Adapter-Branch; halten Sie Adapter nur dann getrennt, wenn mehrere Aufgaben auf einer Basis hot-swapped werden.
Feinabstimmung auf eine eng definierte Aufgabe beeinträchtigt die allgemeinen Fähigkeiten.
Mischen Sie einen Teil allgemeiner/Anweisungsdaten bei, senken Sie die Lernrate und bevorzugen Sie PEFT gegenüber vollständigem fine-tuning.
Warum: Das Wiederholen allgemeiner Daten und das Begrenzen der Gewichtsverschiebung bewahrt breite Fähigkeiten, während die neue Aufgabe dennoch gelernt wird.
Pretraining-/Fine-Tuning-Daten enthalten viele nahezu Duplikate.
Führen Sie eine Fuzzy-Deduplizierung (z.B. MinHash/LSH) vor dem Training durch.
Warum: Duplikate verschwenden Rechenleistung, verzerren das Modell zu wiederholten Inhalten und können zu Memorization führen; Dedup verbessert die Generalisierung pro token.
Verdächtig hohe Benchmark-Scores nach dem Training.
Dekontaminieren Sie den Trainingsdatensatz gegen Benchmark-/Evaluierungsdaten mittels N-Gramm-Überlappungsfilterung.
Warum: Das Lecken von Testelementen bläht Metriken auf und verbirgt die reale Qualität; Dekontamination hält die Evaluierung ehrlich.
Korpus kann personenbezogene Daten enthalten, die Governance-Regeln unterliegen.
Fügen Sie eine PII-Erkennungs- und -Redaktionsstufe zur Datenpipeline vor dem Training hinzu.
Warum: Das Training mit Roh-PII birgt das Risiko der Wiedergabe und von Compliance-Verletzungen; das vorherige Scrubbing ist weitaus billiger als die Reparatur eines undichten Modells.
Rohdaten aus Web-Scraping sind verrauscht und mindern die Modellqualität.
Wenden Sie Qualitätsfilter (Heuristiken plus einen Klassifikator) an, um qualitativ minderwertige, Boilerplate- und Spam-Dokumente zu entfernen.
Warum: Die Datenqualität übertrifft ab einem Schwellenwert die reine Quantität; Filterung liefert bessere Modelle bei gleichem Trainingsbudget.
Fine-Tuning-Daten müssen sauber in die NeMo Trainingspipeline eingespeist werden.
Konvertieren Sie in das erwartete NeMo-Format (z.B. JSONL mit prompt/response-Feldern) und tokenisieren Sie mit dem Tokenizer des Modells.
Warum: Format- und Tokenizer-Fehlpaarungen verursachen stillschweigende Trunkierungen oder Label-Fehler; die Einhaltung des NeMo-Schemas hält das Training reproduzierbar.
Schnelles Einrichten eines Produktions-LLM-Endpunkts mit einer OpenAI-kompatiblen API.
Bereitstellen mit einem NVIDIA NIM Microservice; ein benutzerdefiniertes Triton ensemble nur für nicht-standardmäßige Pre-/Post-Processing-Anforderungen erstellen.
Warum: NIM liefert optimierte Engines und eine Standard-API out of the box; ein benutzerdefiniertes Triton ist den Aufwand nur wert, wenn Sie eine maßgeschneiderte Pipeline-Kontrolle benötigen.
Unabhängige Anfragen treffen schneller ein, als eine Einzelanfragenbedienung bewältigen kann.
Aktivieren Sie Triton dynamic batching, um gleichzeitige Anfragen zu GPU batches zusammenzufassen.
Warum: Batching amortisiert den Kernel-Overhead über Anfragen hinweg und erhöht den Durchsatz bei geringen, begrenzten Latenzkosten.
Eine einzelne Modellinstanz nutzt die GPU-Rechenleistung nicht vollständig aus.
Konfigurieren Sie mehrere Modellinstanzen pro GPU in Triton, um die Ausführung zu überlappen.
Warum: Gleichzeitige Instanzen füllen Rechenlücken, die durch Speicherengpässe entstehen, und verbessern die Auslastung, wenn der Speicher es zulässt.
Der Datenverkehr ist sprunghaft und feste Replikas verschwenden entweder GPUs oder unterschreiten SLOs.
Autoscale-Replikas basierend auf Warteschlangentiefe / GPU-Auslastung mit einem warmen Pool, um Kaltstarts abzufangen.
Warum: LLM-Kaltstarts (Engine-Load) sind langsam; das Skalieren basierend auf einem führenden Signal mit warmer Kapazität schützt die Latenz während Spitzenbelastungen.
Bestehende Clients erwarten die OpenAI chat-completions API.
Stellen Sie das Modell über NIM's OpenAI-kompatiblen Endpunkt bereit, damit Clients ohne Umschreibungen integrieren können.
Warum: Eine Drop-in-kompatible API minimiert den Client-Migrationsaufwand und ermöglicht den transparenten Austausch von Backends.
Eine Modell- oder Prompt-Änderung darf die Qualität nicht stillschweigend verschlechtern.
Führen Sie ein kuratiertes golden eval set in CI aus und blockieren Sie Bereitstellungen, die unter einen Qualitätsschwellenwert fallen.
Warum: Automatisierte Regressionstests fangen Qualitätseinbrüche ab, bevor sie Benutzer erreichen, genau wie Unit-Tests Code absichern.
Offene Ausgaben haben keine einzige Referenzantwort, gegen die bewertet werden könnte.
Verwenden Sie ein LLM-as-judge mit einer Rubrik, kalibriert anhand menschlicher Bewertungen an einer Stichprobe.
Warum: Ein rubrikenbasiertes judge skaliert die subjektive Evaluierung; menschliche Kalibrierung schützt vor der eigenen Voreingenommenheit des judge.
Hoher MMLU-Score, aber Benutzer beschweren sich über die Produktionsaufgabe.
Evaluieren Sie anhand aufgabenspezifischer Metriken, die an Geschäftsergebnisse gebunden sind, nicht nur an generischen Benchmarks.
Warum: Generische Benchmarks korrelieren schwach mit eng definierten implementierten Aufgaben; die richtige Metrik spiegelt wider, was Benutzer tatsächlich benötigen.
Offline-Evals sehen gut aus, aber die reale Auswirkung ist ungewiss.
Führen Sie einen Online-A/B-Test durch, der einen Teil des Datenverkehrs zur neuen Version leitet und vergleichen Sie die Ergebnis-Metriken.
Warum: Live-A/B erfasst Distributionsverschiebungen und Benutzerverhalten, die Offline-Sets übersehen, und bestätigt echte Verbesserungen.
Benötigen Einblick in den GPU-Zustand und die Auslastung einer Serving-Flotte.
Exportieren Sie DCGM-Metriken (Auslastung, Speicher, ECC, Temperatur) in Prometheus und lösen Sie Warnungen aus.
Warum: DCGM ist die Standard-NVIDIA-Telemetrie-Quelle; ohne sie bleiben GPU-Level-Sättigung und -Fehler unentdeckt.
Benutzer sehen zeitweise langsame Antworten, aber die durchschnittliche Latenz sieht gut aus.
Verfolgen Sie die p95/p99 Zeit bis zum ersten token und die inter-token Latenz und lösen Sie Warnungen bei Überschreitungen der Perzentil-SLOs aus.
Warum: Durchschnitte verbergen tail latency; die LLM UX wird durch p95/p99 bestimmt, daher sind Perzentil-SLIs das richtige Alarmsignal.
Bereitstellung einer neuen Modellversion an einem Endpunkt mit hohem Datenverkehr.
Bereitstellung über Canary (kleiner Traffic-Slice) mit automatischem Rollback bei SLO- oder Qualitätsregression.
Warum: Canarying begrenzt den Explosionsradius und ermöglicht es Metriken, die Sicherheit vor dem vollständigen Rollout zu bestätigen, im Gegensatz zu einer Big-Bang-Bereitstellung.
Der Durchsatz bricht unter Last zusammen, ohne offensichtliche GPU-Rechenspitze.
Überwachen Sie die KV-cache- und Batch-Slot-Auslastung; skalieren Sie hoch oder verkürzen Sie den maximalen Kontext, wenn der Cache gesättigt ist.
Warum: KV-cache-Erschöpfung begrenzt die Parallelität, bevor dies die Rechenleistung tut; die Beobachtung erklärt Durchsatzabstürze, die die GPU-Auslastung allein nicht erfasst.
KV cache ist zu groß für den Ziel-Batch und Kontext.
Bevorzugen Sie eine Architektur, die Grouped-Query Attention (GQA) oder Multi-Query Attention (MQA) verwendet.
Warum: GQA/MQA teilen key/value heads, wodurch der KV-cache-Speicher reduziert und die erreichbare Batch-Größe mit geringem Qualitätsverlust erhöht wird.
Erweiterung des nutzbaren Kontexts eines Modells über seine trainierte Länge hinaus.
Verwenden Sie RoPE-Skalierung (z.B. NTK-aware / YaRN) plus leichtes long-context fine-tuning.
Warum: RoPE-Interpolation dehnt positional encodings; eine kurze Feinabstimmung passt das Modell an den längeren Bereich an, ohne vollständiges Umschulung.
Mehr Kapazität ohne proportional höhere inference-Kosten gewünscht.
Ziehen Sie ein Mixture-of-Experts-Modell in Betracht, das nur top-k experts pro token aktiviert.
Warum: MoE skaliert Parameter, während die FLOPs pro token niedrig bleiben, fügt jedoch Routing-Komplexität und ungleichmäßige expert load hinzu, die verwaltet werden müssen.
Ein bereitgestelltes Modell benötigt Themen-, Sicherheits- und Formatgrenzen.
Umschließen Sie das Modell mit NeMo Guardrails, um Input- und Output-Rails (thematisch, Moderation, Jailbreak) zu erzwingen.
Warum: Programmierbare Rails fügen eine kontrollierbare Sicherheitsebene um das Modell hinzu, ohne es neu zu trainieren.
Modell produziert gelegentlich toxische oder unsichere Inhalte.
Fügen Sie einen Output moderation classifier hinzu und blockieren/regenerieren Sie Antworten, die einen Risikoschwellenwert überschreiten.
Warum: Ein separater Moderationsdurchlauf fängt unsichere Generierungen ab, die prompt-level-Anweisungen allein nicht zuverlässig verhindern.
Stakeholder fordern Nachweise, dass das Modell verantwortungsvolle AI-Standards erfüllt.
Führen Sie Bias- und Toxicity-Benchmarks durch, dokumentieren Sie die Ergebnisse und verfolgen Sie diese über Versionen hinweg in einer Modellkarte.
Warum: Dokumentierte, wiederholbare Sicherheitsbewertungen unterstützen die Compliance und decken Regressionen auf, bevor sie in die Produktion gelangen.