Справочник — NCP-GENL NVIDIA-Certified Professional: Generative AI LLMs

Требуется более низкая задержка на H100/Blackwell без потери точности от агрессивной INT quantization.

→Используйте FP8 (E4M3) quantization через TensorRT-LLM; Hopper и Blackwell имеют нативные FP8 Tensor Cores.

Почему: FP8 лучше сохраняет динамический диапазон, чем INT8, и работает на полной аппаратной скорости на Hopper+, обеспечивая качество, близкое к FP16, при пропускной способности класса INT8.

Источник↗

Модель едва помещается в память GPU, и пропускная способность ограничена пропускной способностью памяти.

→Примените INT4 weight-only quantization (AWQ или GPTQ); сохраняйте activations в FP16/FP8.

Почему: Weight-only INT4 примерно вдвое уменьшает объем памяти по сравнению с INT8 и снижает нагрузку на пропускную способность; activation precision остается высокой, поэтому потеря точности мала.

Выбор между post-training quantization и quantization-aware training.

→Начните с PTQ (калибровка на репрезентативной выборке); переходите к QAT только в том случае, если потеря точности PTQ превышает бюджет.

Почему: PTQ быстра и не требует переобучения; QAT восстанавливает точность, но требует прогона обучения, поэтому резервируйте ее для моделей, критичных к точности.

Обслуживание длинных контекстов, где KV cache доминирует в памяти и ограничивает batch size.

→Включите FP8 или INT8 KV-cache quantization в TensorRT-LLM.

Почему: KV cache растет пропорционально длине последовательности × пакету; его квантизация освобождает память для больших batches и более длинных contexts с минимальным влиянием на качество.

Смешанные длины запросов вызывают простои GPU при статическом пакетировании.

→Используйте in-flight (непрерывное) batching в TensorRT-LLM, чтобы завершенные последовательности выгружались, а новые присоединялись в процессе выполнения.

Почему: Непрерывное batching обеспечивает насыщенность GPU и значительно увеличивает пропускную способность по сравнению со статическим batching для разнородных потоков запросов.

Источник↗

Большая модель-учитель соответствует требованиям к качеству, но не достигает целевых показателей по задержке и стоимости.

→Distill в меньшую модель-ученика, затем quantize ученика для inference.

Почему: Distillation передает возможности более дешевой архитектуре; в сочетании с quantization это значительно сокращает затраты/задержки.

Задержка одного потока слишком высока для интерактивного использования.

→Примените speculative decoding с небольшой черновой моделью, проверяемой целевой моделью.

Почему: Черновик предлагает несколько tokens, которые большая модель проверяет за один проход, сокращая общую задержку без изменения распределения выходных данных.

Quantizing всего до INT4 значительно снижает точность на нескольких чувствительных слоях.

→Используйте смешанную precision: сохраняйте чувствительные слои (например, final projection, attention) с более высокой precision и quantize остальные.

Почему: Чувствительность слоев различается; выборочная precision защищает точность там, где это важно, при этом сокращая основную часть весов.

Точность PTQ низка, несмотря на разумную схему quantization.

→Перекалибруйте с помощью выборки из распределения (сотни репрезентативных prompts), соответствующей производственному трафику.

Почему: Calibration устанавливает диапазоны activation; нерепрезентативная выборка приводит к плохим scales и предотвратимой потере точности.

Веса модели превышают объем одной GPU, но умещаются в одном NVLink-connected узле.

→Используйте tensor parallelism между GPUs в узле.

Почему: Tensor parallelism разделяет каждый слой и обменивается activations на каждом шаге, поэтому ему требуется высокая intra-node bandwidth, обеспечиваемая NVLink/NVSwitch.

Модель слишком велика для одного узла и должна распределяться по узлам через InfiniBand.

→Добавьте pipeline parallelism между узлами, сохраняя tensor parallelism внутри каждого узла.

Почему: Pipeline parallelism обменивается данными только на границах этапов, допуская более медленные inter-node links; резервируйте bandwidth-hungry tensor parallel для NVLink.

Масштабирование на большее количество GPUs дает уменьшающуюся выгоду в пропускной способности.

→Профилируйте с помощью Nsight Systems, чтобы классифицировать узкое место; если collectives доминируют, уменьшите parallel degree или улучшите topology.

Почему: После определенной точки all-reduce/all-gather overhead перевешивают добавленную вычислительную мощность; диагностика communication-bound vs compute-bound помогает в решении проблемы.

Источник↗

Per-step kernel launch overhead увеличивает decode latency при малых batch sizes.

→Включите CUDA Graphs для захвата и воспроизведения цикла decode.

Почему: CUDA Graphs объединяют множество мелких запусков в одно воспроизведение, устраняя CPU-side launch overhead, которые доминируют при низких batch sizes.

Tensor-parallel ranks, расположенные через медленное соединение, вызывают задержки.

→Привяжите tensor-parallel ranks к GPUs, использующим NVLink/NVSwitch; разместите pipeline stages по узлам.

Почему: Несоответствующее размещение направляет high-frequency collectives через PCIe или InfiniBand, замедляя весь pipeline.

Attention ограничен памятью и ограничивает достижимую context length.

→Используйте FlashAttention (fused, IO-aware attention kernels), предоставляемые стеком TensorRT-LLM/NeMo.

Почему: FlashAttention избегает материализации полной attention matrix, сокращая traffic памяти и позволяя обрабатывать более длинные sequences с более высокой скоростью.

Несколько небольших моделей недостаточно используют полные H100 GPUs.

→Разделите GPUs с помощью MIG (Multi-Instance GPU) для изоляции каждой модели на отдельном slice.

Почему: MIG обеспечивает аппаратно-изолированные partitions, повышая utilization и обеспечивая предсказуемое QoS для совместно расположенных небольших рабочих нагрузок.

Нижестоящий service требует строго валидный JSON каждый раз.

→Используйте guided/constrained decoding (grammar или JSON schema) в serving runtime, а не полагайтесь только на формулировку prompt.

Почему: Constrained decoding маскирует недопустимые tokens во время генерации, гарантируя schema-valid output, тогда как prompting только снижает частоту ошибок.

Задача требует последовательного формата, который базовая модель обрабатывает непоследовательно.

→Сначала попробуйте few-shot exemplars; переходите к fine-tuning только в том случае, если prompt-based steering не улучшается или token cost чрезмерна.

Почему: Few-shot — это zero-training и мгновенное редактирование; fine-tuning выигрывает только тогда, когда шаблоны стабильны, а prompt overhead вредит.

Многошаговая задача рассуждения дает неверные окончательные ответы.

→Вызовите chain-of-thought ('думай шаг за шагом') или используйте структурированный reasoning template перед окончательным ответом.

Почему: Выявление промежуточных шагов улучшает multi-hop accuracy и делает ошибки auditable, ценой дополнительных tokens.

Незначительная корректировка prompt незаметно ухудшила production quality.

→Версионируйте system prompts как код, проверяйте изменения оценкой и развертывайте через тот же CI, что и model artifacts.

Почему: Prompts являются частью model contract; неверсионированные изменения вызывают неотслеживаемые regressions и невоспроизводимое поведение.

Модель галлюцинирует факты, отсутствующие в ее training data.

→Извлеките релевантный context и вставьте его в prompt с инструкцией отвечать только на основе предоставленного context.

Почему: Grounding на извлеченных passages ограничивает модель исходным материалом и снижает hallucination при knowledge-intensive queries.

Latency и cost высоки из-за раздутых prompts.

→Обрежьте и сожмите prompt: dedupe инструкции, summarize извлеченный context и cap exemplars до минимума, который сохраняет качество.

Почему: Prefill масштабируется с input tokens; lean prompts сокращают как latency, так и per-request cost без measurable quality loss.

User-supplied text может переопределить system instruction.

→Отделяйте доверенные instructions от untrusted input с помощью четких delimiters и рассматривайте retrieved/user content как данные, а не команды.

Почему: Concatenating untrusted text в instruction channel провоцирует prompt injection; explicit boundaries уменьшают attack surface.

Адаптация большой base model к домену с ограниченным бюджетом GPU.

→Используйте LoRA: обучайте low-rank adapters и замораживайте base weights.

Почему: LoRA обучает крошечную fraction parameters, значительно сокращая memory и compute, при этом соответствуя full fine-tuning для большинства narrow tasks.

Источник↗

Даже LoRA training модели 70B не помещается в доступную память.

→Используйте QLoRA: quantize frozen base до 4-bit (NF4) и обучайте LoRA adapters поверх.

Почему: Сохранение base в 4-bit формате при обновлении только adapters позволяет большим моделям быть fine-tuned на одной GPU с минимальной accuracy loss.

Выбор LoRA rank для новой fine-tuning задачи.

→Начните со скромного rank (например, 8-16); повышайте его только в том случае, если задача сложна и validation loss все еще улучшается.

Почему: Более высокий rank увеличивает capacity и cost; over-ranking рискует overfitting на small datasets, в то время как under-ranking caps достижимое качество.

Модель следует instructions, но ее outputs не соответствуют human preference.

→Сначала выполните supervised fine-tuning, затем preference alignment с RLHF или DPO.

Почему: SFT учит format и task; preference optimization формирует, какие valid answers люди на самом деле предпочитают.

RLHF с PPO нестабилен и operationally heavy.

→Используйте DPO (Direct Preference Optimization) на preference dataset вместо reward model + PPO loop.

Почему: DPO оптимизирует preferences напрямую без отдельной reward model или RL rollout, что упрощает pipeline и повышает stability.

LoRA adapter добавляет per-request overhead во время serving.

→Объедините adapter weights с base для deployment, если используется только один adapter.

Почему: Объединенная модель не имеет adapter branch при inference; сохраняйте adapters отдельно только при hot-swapping multiple tasks на одной base.

Fine-tuning на narrow task ухудшает general capabilities.

→Добавьте часть general/instruction data, снизьте learning rate и предпочтите PEFT полному fine-tuning.

Почему: Повторное воспроизведение general data и ограничение weight movement сохраняет broad skills, при этом позволяя осваивать новую task.

Pretraining/fine-tuning data содержит много почти дубликатов.

→Запустите fuzzy deduplication (например, MinHash/LSH) перед training.

Почему: Дубликаты тратят compute, bias модель в сторону repeated content и могут вызывать memorization; dedup улучшает generalization per token.

Подозрительно высокие benchmark scores после training.

→Decontaminate training set от benchmark/eval data с помощью n-gram overlap filtering.

Почему: Leakage of test items завышает metrics и скрывает real quality; decontamination сохраняет evaluation honest.

Corpus может содержать personal data, подпадающие под governance rules.

→Добавьте PII detection-and-redaction stage в data pipeline перед training.

Почему: Training на raw PII рискует regurgitation и compliance violations; scrubbing upfront гораздо дешевле, чем fixing a leaky model.

Raw web-scraped data шумны и снижают model quality.

→Примените quality filters (heuristics плюс classifier) для удаления low-quality, boilerplate и spam documents.

Почему: Data quality перевешивает raw quantity после threshold; filtering дает лучшие models при том же training budget.

Fine-tuning data должны чисто подаваться в NeMo training pipeline.

→Преобразуйте в ожидаемый формат NeMo (например, JSONL с prompt/response fields) и tokenize с помощью model's tokenizer.

Почему: Format и tokenizer mismatches вызывают silent truncation или label errors; conforming к NeMo's schema делает training reproducible.

Источник↗

Быстрое развертывание production LLM endpoint с OpenAI-compatible API.

→Разверните с помощью микросервиса NVIDIA NIM; создавайте custom Triton ensemble только для non-standard pre/post-processing needs.

Почему: NIM поставляет optimized engines и standard API out of the box; custom Triton стоит усилий только тогда, когда вам нужен bespoke pipeline control.

Источник↗

Независимые запросы поступают быстрее, чем может обработать single-request serving.

→Включите Triton dynamic batching для объединения concurrent requests в GPU batches.

Почему: Batching амортизирует kernel overhead по requests, повышая throughput с небольшой, bounded latency cost.

Источник↗

Один экземпляр модели оставляет GPU compute underutilized.

→Настройте multiple model instances per GPU в Triton для overlap execution.

Почему: Concurrent instances заполняют compute gaps, вызванные memory stalls, улучшая utilization, когда это позволяет память.

Traffic скачкообразен, и fixed replicas либо тратят GPUs впустую, либо drop SLOs.

→Autoscale replicas по queue depth / GPU utilization с warm pool для поглощения cold starts.

Почему: LLM cold starts (engine load) медленные; scaling по leading signal с warm capacity защищает latency во время spikes.

Existing clients ожидают OpenAI chat-completions API.

→Предоставьте модель через NIM's OpenAI-compatible endpoint, чтобы clients могли интегрироваться без rewrites.

Почему: A drop-in compatible API минимизирует client migration work и позволяет вам swap backends transparently.

Изменение модели или prompt не должно незаметно ухудшать качество.

→Запускайте curated golden eval set в CI и блокируйте deploys, которые опускаются ниже quality threshold.

Почему: Automated regression gates улавливают quality drops до того, как они достигнут users, так же, как unit tests gate code.

Open-ended outputs не имеют single reference answer для оценки.

→Используйте LLM-as-judge с rubric, откалиброванной по human ratings на sample.

Почему: A rubric-driven judge масштабирует subjective evaluation; human calibration guards against the judge's own bias.

Высокий MMLU score, но users жалуются на production task.

→Оценивайте по task-specific metrics, связанным с business outcomes, а не только по generic benchmarks.

Почему: Generic benchmarks слабо коррелируют с narrow deployed tasks; the right metric отражает то, что users на самом деле нужно.

Offline evals выглядят хорошо, но real-world impact неопределен.

→Запустите online A/B test, направляя fraction traffic на new version и сравнивая outcome metrics.

Почему: Live A/B captures distribution shift и user behavior, которые offline sets упускают, confirming real improvement.

Требуется обзор состояния и использования GPU по всему serving fleet.

→Экспортируйте DCGM metrics (utilization, memory, ECC, temperature) в Prometheus и настройте alert по ним.

Почему: DCGM — стандартный NVIDIA telemetry source; без него GPU-level saturation и faults остаются undetected.

Источник↗

Users периодически видят slow responses, но average latency выглядит нормально.

→Отслеживайте p95/p99 time-to-first-token и inter-token latency, и alert о нарушениях percentile SLO.

Почему: Averages скрывают tail latency; LLM UX определяется p95/p99, поэтому percentile SLIs являются правильным alerting signal.

Развертывание new model version на high-traffic endpoint.

→Развертывайте через canary (small traffic slice) с automated rollback при SLO или quality regression.

Почему: Canarying limits blast radius и позволяет metrics подтвердить safety до full rollout, в отличие от big-bang deploy.

Throughput падает под load без obvious GPU compute spike.

→Мониторьте KV-cache и batch-slot utilization; scale out или сокращайте max context при насыщении cache.

Почему: KV-cache exhaustion caps concurrency раньше, чем compute; watching it объясняет throughput cliffs, которые GPU-util alone пропускает.

KV cache слишком велик для целевого batch и context.

→Предпочитайте architecture, использующую Grouped-Query Attention (GQA) или Multi-Query Attention (MQA).

Почему: GQA/MQA совместно используют key/value heads, уменьшая KV-cache memory и увеличивая attainable batch size с little quality loss.

Необходимо расширить model's usable context за пределы ее trained length.

→Используйте RoPE scaling (например, NTK-aware / YaRN) плюс light long-context fine-tuning.

Почему: RoPE interpolation stretches positional encodings; a short fine-tune адаптирует модель к longer range без full retraining.

Нужна большая capacity без proportional inference cost.

→Рассмотрите Mixture-of-Experts model, которая активирует только top-k experts per token.

Почему: MoE масштабирует parameters, сохраняя низкие per-token FLOPs, но добавляет routing complexity и uneven expert load, которыми нужно управлять.

Развернутой модели требуются границы по темам, безопасности и формату.

→Оберните модель с помощью NeMo Guardrails для принудительного применения input и output rails (topical, moderation, jailbreak).

Почему: Programmable rails добавляют controllable safety layer вокруг модели без retraining ее.

Источник↗

Модель иногда производит toxic или unsafe content.

→Добавьте output moderation classifier и block/regenerate responses, которые превышают risk threshold.

Почему: Отдельный moderation pass перехватывает unsafe generations, которые prompt-level instructions alone не могут reliably prevent.

Stakeholders требуют evidence, что модель meets responsible-AI standards.

→Проведите bias и toxicity benchmarks, задокументируйте results и отслеживайте их по versions в model card.

Почему: Documented, repeatable safety evaluation поддерживает compliance и выявляет regressions до того, как они достигнут production.