手册 — NCP-GENL NVIDIA-Certified Professional: Generative AI LLMs

需要在 H100/Blackwell 上获得更低的延迟，同时避免激进的 INT quantization 带来的精度损失。

→通过 TensorRT-LLM 使用 FP8 (E4M3) quantization；Hopper 和 Blackwell 具有原生 FP8 Tensor Cores。

原因: FP8 比 INT8 更好地保留了动态范围，并在 Hopper+ 上以全硬件速度运行，以 INT8 级别的吞吐量提供接近 FP16 的质量。

参考↗

模型几乎不适合 GPU 内存，且吞吐量受内存带宽限制。

→应用 INT4 仅权重 quantization (AWQ 或 GPTQ)；保持激活在 FP16/FP8。

原因: 仅权重 INT4 将内存量大致减半，相较于 INT8，并缓解了带宽压力；激活精度保持较高，因此精度损失很小。

在训练后 quantization 和 quantization 感知训练之间做出选择。

→从 PTQ 开始（在有代表性的样本上校准）；仅当 PTQ 精度损失超出预算时才退回到 QAT。

原因: PTQ 速度快且无需重新训练；QAT 恢复精度但需要一次训练运行，因此将其保留给对精度要求苛刻的模型。

在长上下文服务中，KV cache 占用主导内存并限制 batch size。

→在 TensorRT-LLM 中启用 FP8 或 INT8 KV-cache quantization。

原因: KV cache 随序列长度 × batch 增长；对其进行 quantization 可以为更大的 batches 和更长的上下文释放内存，同时对质量影响最小。

混合请求长度导致静态 batching 时 GPU 空闲。

→在 TensorRT-LLM 中使用 in-flight (continuous) batching，以便完成的序列被逐出，新序列可以在执行过程中加入。

原因: Continuous batching 使 GPU 保持饱和，对于异构请求流，其吞吐量远高于静态 batching。

参考↗

大型教师模型质量达标，但未能达到延迟和成本目标。

→将其蒸馏成一个较小的学生模型，然后对学生模型进行 inference quantization。

原因: Distillation 将能力转移到更便宜的架构；结合 quantization，可以成倍地节省成本/延迟。

单流延迟对于交互式用例来说太高。

→使用小型草稿模型应用 speculative decoding，并由目标模型进行验证。

原因: 草稿模型提出多个 tokens，大型模型一次性验证，从而在不改变输出分布的情况下减少实际运行延迟。

将所有内容 quantization 到 INT4 会导致少数敏感层精度大幅下降。

→使用混合精度：将敏感层（例如，最终投影、attention）保持更高精度，并对其余部分进行 quantization。

原因: 每层敏感度不同；选择性精度在关键部位保护精度，同时仍然缩小大部分权重。

尽管 quantization 方案合理，PTQ 精度仍然很差。

→使用与生产流量匹配的同分布样本（数百个代表性提示）进行重新校准。

原因: 校准设置了激活范围；不具代表性的样本会产生不良尺度和可避免的精度损失。

模型权重超过单个 GPU，但适合单个 NVLink 连接的节点。

→在节点中的 GPU 之间使用 tensor parallelism。

原因: Tensor parallelism 分片每一层并每一步交换激活，因此它需要 NVLink/NVSwitch 的高节点内带宽。

模型太大，无法容纳在一个节点中，必须通过 InfiniBand 跨节点分布。

→在节点之间添加 pipeline parallelism，同时在每个节点内部保持 tensor parallelism。

原因: Pipeline parallelism 仅在阶段边界进行通信，能够容忍较慢的节点间链接；将带宽密集型 tensor parallel 保留给 NVLink。

扩展到更多 GPU 产生的吞吐量收益递减。

→使用 Nsight Systems 进行性能分析以找出瓶颈；如果 collectives 占主导地位，则降低并行度或改进拓扑。

原因: 超过某个点后，all-reduce/all-gather 的开销会超过新增的计算量；诊断是通信瓶颈还是计算瓶颈有助于指导解决方案。

参考↗

在小 batch size 下，每步 kernel 启动开销会增加 decode 延迟。

→启用 CUDA Graphs 来捕获和重放 decode 循环。

原因: CUDA Graphs 将许多小启动合并为一个重放，消除了在低 batch size 下占主导地位的 CPU 端启动开销。

Tensor-parallel ranks 放置在慢速链接上会导致停顿。

→将 tensor-parallel ranks 固定到共享 NVLink/NVSwitch 的 GPU 上；将 pipeline 阶段放置在节点之间。

原因: 不匹配的放置会将高频 collectives 路由到 PCIe 或 InfiniBand 上，从而限制整个 pipeline 的性能。

Attention 是内存受限的，并限制了可实现的上下文长度。

→使用 TensorRT-LLM/NeMo 堆栈提供的 FlashAttention（融合的、IO 感知的 attention kernels）。

原因: FlashAttention 避免了实例化完整的 attention 矩阵，减少了内存流量，并能以更高的速度实现更长的序列。

几个小型模型未充分利用完整的 H100 GPU。

→使用 MIG (Multi-Instance GPU) 分割 GPU，将每个模型隔离在一个 slice 上。

原因: MIG 提供硬件隔离分区，提高了利用率，并为共存的小型 workloads 提供可预测的 QoS。

下游服务每次都需要严格有效的 JSON。

→在服务运行时使用引导/约束 decoding（语法或 JSON 模式），而不是仅仅依靠 prompt 措辞。

原因: 约束 decoding 在生成时屏蔽无效 tokens，保证了模式有效的输出，而 prompt 只能降低失败率。

任务需要一种基本模型处理不一致的统一格式。

→首先尝试 few-shot 示例；仅当基于 prompt 的引导效果停滞不前或 token 成本过高时才转向 fine-tuning。

原因: Few-shot 无需训练且可即时编辑；仅当模式稳定且 prompt 开销造成影响时，fine-tuning 才能胜出。

多步推理任务给出错误的最终答案。

→在最终答案之前，引导 chain-of-thought（“一步一步思考”）或使用结构化推理模板。

原因: 暴露中间步骤可以提高多跳准确性并使错误可审计，但代价是增加额外的 tokens。

一个 prompt 微调悄悄地降低了生产质量。

→将系统 prompt 作为代码进行版本控制，通过评估门控更改，并通过与模型 artifact 相同的 CI 进行部署。

原因: Prompt 是模型契约的一部分；未版本化的编辑会导致未跟踪的回归和不可复现的行为。

模型会虚构其训练数据之外的事实。

→检索相关上下文并将其注入 prompt 中，指示模型仅从提供的上下文回答。

原因: 基于检索到的段落进行 grounding 将模型约束到源材料，并减少了知识密集型查询中的虚构。

由于 prompt 冗长，延迟和成本都很高。

→裁剪和压缩 prompt：删除重复指令，总结检索到的上下文，并将示例限制在保持质量的最小数量。

原因: Prefill 随输入 tokens 扩展；精简的 prompt 可以在不损失可测量质量的情况下，降低延迟和每个请求的成本。

用户提供的文本可以覆盖系统指令。

→使用清晰的分隔符将受信任的指令与不受信任的输入分开，并将检索到的/用户内容视为数据，而不是命令。

原因: 将不受信任的文本连接到指令通道会导致 prompt injection；明确的边界可以减少攻击面。

在有限的 GPU 预算下，将大型基础模型适应到某个领域。

→使用 LoRA：训练低秩适配器并冻结基础权重。

原因: LoRA 训练极少一部分参数，在大多数狭窄任务上与完整 fine-tuning 效果相当，同时大幅削减了内存和计算量。

参考↗

即使是 70B 模型的 LoRA 训练也无法适应可用内存。

→使用 QLoRA：将冻结的基础模型 quantization 到 4-bit (NF4)，并在其上训练 LoRA 适配器。

原因: 将基础模型保持在 4-bit 并仅更新适配器，使得大型模型可以在单个 GPU 上进行 fine-tuning，且精度损失最小。

为新的 fine-tuning 任务选择 LoRA rank。

→从适中的 rank 开始（例如 8-16）；仅当任务复杂且验证损失仍在改善时才提高它。

原因: 更高的 rank 增加了容量和成本；rank 过高可能导致在小型数据集上过拟合，而 rank 过低则限制了可实现的质量。

模型遵循指令，但其输出与人类偏好不符。

→首先进行监督 fine-tuning，然后通过 RLHF 或 DPO 进行偏好对齐。

原因: SFT 教授格式和任务；偏好优化则塑造了人类实际偏好的有效答案。

使用 PPO 的 RLHF 不稳定且操作繁重。

→在偏好数据集上使用 DPO (Direct Preference Optimization)，而不是奖励模型 + PPO 循环。

原因: DPO 直接优化偏好，无需单独的奖励模型或 RL rollout，从而简化了 pipeline 并提高了稳定性。

LoRA 适配器在服务时增加了每个请求的开销。

→当只服务一个适配器时，将适配器权重合并到基础模型中进行部署。

原因: 合并后的模型在 inference 时没有适配器分支；仅当在同一基础模型上热切换多个任务时才将适配器分开。

对狭窄任务进行 fine-tuning 会降低通用能力。

→混入一部分通用/指令数据，降低学习率，并优先选择 PEFT 而非完整 fine-tuning。

原因: 重播通用数据并限制权重移动，可以在学习新任务的同时保留广泛的技能。

预训练/fine-tuning 数据包含大量近似重复项。

→在训练前运行模糊去重（例如 MinHash/LSH）。

原因: 重复数据会浪费计算资源，使模型偏向重复内容，并可能导致记忆化；去重可以提高每个 token 的泛化能力。

训练后 benchmark 分数异常高。

→通过 n-gram 重叠过滤，对训练集进行净化，以去除 benchmark/评估数据中的泄露。

原因: 测试项泄露会夸大指标并掩盖真实质量；净化可以确保评估的公正性。

语料库可能包含受治理规则约束的个人数据。

→在训练前，向数据 pipeline 添加 PII 检测和匿名化阶段。

原因: 使用原始 PII 进行训练存在泄露和合规违规的风险；提前清除比修复泄露模型成本要低得多。

原始网络抓取数据噪音大，降低了模型质量。

→应用质量过滤器（启发式规则加分类器）来删除低质量、样板和垃圾文档。

原因: 数据质量在超过某个阈值后比原始数量更重要；过滤可以在相同的训练预算下产生更好的模型。

Fine-tuning 数据必须干净地输入 NeMo 训练 pipeline。

→转换为预期的 NeMo 格式（例如，带有 prompt/response 字段的 JSONL），并使用模型的 tokenizer 进行 tokenize。

原因: 格式和 tokenizer 不匹配会导致静默截断或标签错误；遵循 NeMo's 的 schema 可以保持训练的可复现性。

参考↗

使用与 OpenAI 兼容的 API 快速建立生产级 LLM 端点。

→使用 NVIDIA NIM 微服务部署；仅在需要非标准预处理/后处理时才构建自定义 Triton ensemble。

原因: NIM 开箱即用，提供优化的 engine 和标准 API；仅当您需要定制的 pipeline 控制时，自定义 Triton 才值得付出努力。

参考↗

独立请求的到达速度超过了单请求服务能处理的速度。

→启用 Triton dynamic batching，将并发请求合并到 GPU batches 中。

原因: Batching 分摊了跨请求的 kernel 开销，以少量、有限的延迟成本提高了吞吐量。

参考↗

单个模型实例导致 GPU 计算资源利用不足。

→在 Triton 中为每个 GPU 配置多个模型实例以重叠执行。

原因: 并发实例填补了内存停顿留下的计算空白，在内存允许的情况下提高了利用率。

流量呈尖峰状，固定副本要么浪费 GPU，要么无法满足 SLO。

→根据队列深度/GPU 利用率自动扩展副本，并设置预热池以吸收冷启动。

原因: LLM 冷启动（engine 加载）很慢；通过前导信号和预热容量进行扩展可以保护流量高峰期间的延迟。

现有客户端期望使用 OpenAI 的 chat-completions API。

→通过 NIM's 与 OpenAI 兼容的端点暴露模型，以便客户端无需重写即可集成。

原因: 一个可直接替换的兼容 API 最大限度地减少了客户端迁移工作，并允许您透明地切换后端。

模型或 prompt 更改不得悄悄地降低质量。

→在 CI 中运行精心策划的 golden 评估集，并阻止低于质量阈值的部署。

原因: 自动化回归门控在质量下降触达用户之前将其捕获，就像单元测试门控代码一样。

开放式输出没有单一的参考答案可供评分。

→使用带有评分标准的 LLM 作为评估者，并根据样本上的人工评分进行校准。

原因: 基于评分标准的评估者可以扩展主观评估；人工校准可以防止评估者自身的偏见。

MMLU 分数很高，但用户抱怨生产任务。

→根据与业务成果相关的特定任务指标进行评估，而不仅仅是通用 benchmark。

原因: 通用 benchmark 与狭窄的部署任务相关性较弱；正确的指标反映了用户实际需求。

离线评估看起来不错，但实际影响不确定。

→运行在线 A/B 测试，将一部分流量路由到新版本，并比较结果指标。

原因: 实时 A/B 测试捕获了离线集合遗漏的分布变化和用户行为，从而确认了真实改进。

需要查看整个服务集群中 GPU 的健康状况和利用率。

→将 DCGM metrics（利用率、内存、ECC、温度）导出到 Prometheus 并对其进行告警。

原因: DCGM 是标准 NVIDIA 遥测源；没有它，GPU 级别的饱和和故障将无法被检测到。

参考↗

用户间歇性地遇到慢响应，但平均延迟看起来正常。

→跟踪 p95/p99 首 token 时间和 token 间延迟，并对百分位 SLO 违规发出告警。

原因: 平均值掩盖了尾部延迟；LLM 用户体验受 p95/p99 影响，因此百分位 SLI 是正确的告警信号。

将新的模型版本部署到高流量端点。

→通过 canary（小流量切片）进行发布，并在 SLO 或质量回归时自动回滚。

原因: 金丝雀部署限制了影响范围，并允许在全面发布之前通过指标确认安全性，这与一次性大规模部署不同。

在负载下吞吐量崩溃，但没有明显的 GPU 计算峰值。

→监控 KV-cache 和 batch-slot 利用率；当 cache 饱和时，进行横向扩展或缩短最大上下文。

原因: KV-cache 耗尽在计算资源耗尽之前限制了并发性；监测它可以解释 GPU 利用率本身无法捕捉到的吞吐量骤降。

KV cache 对于目标 batch 和上下文来说太大。

→优先选择使用 Grouped-Query Attention (GQA) 或 Multi-Query Attention (MQA) 的架构。

原因: GQA/MQA 共享 key/value heads，减少了 KV-cache 内存，并在质量损失很小的情况下提高了可达到的 batch size。

需要将模型的可用上下文扩展到其训练长度之外。

→使用 RoPE 缩放（例如 NTK-aware / YaRN）加上轻量级长上下文 fine-tuning。

原因: RoPE 插值扩展了位置编码；短期的 fine-tuning 使模型适应更长的范围，而无需完全重新训练。

希望获得更大的容量而无需按比例增加 inference 成本。

→考虑使用 Mixture-of-Experts 模型，该模型每个 token 仅激活 top-k 个 experts。

原因: MoE 在保持每个 token 的 FLOPs 较低的同时扩展了参数，但增加了路由复杂性和不均匀的 expert 负载管理。

已部署的模型需要主题、安全和格式边界。

→使用 NeMo Guardrails 封装模型，以强制执行输入和输出 rail（主题、审核、越狱）。

原因: 可编程 rail 在模型周围添加了一个可控制的安全层，而无需重新训练模型。

参考↗

模型偶尔会产生有害或不安全的内容。

→添加输出审核分类器，并阻止/重新生成超过风险阈值的响应。

原因: 单独的审核过程可以捕获不安全的生成，而仅靠 prompt 级别的指令无法可靠地阻止。

利益相关者要求提供模型符合负责任 AI 标准的证据。

→运行偏差和毒性 benchmark，记录结果，并在模型卡中跨版本跟踪它们。

原因: 有文档记录的、可重复的安全评估支持合规性，并在回归触达生产环境之前将其暴露。