Справочник - 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.