如何在不超支的情况下调整 GPU 大小以实现 AI 推理和 TCO

AI 采用率的激增正在改变从聊天机器人到内容生成的方方面面。尽管如此，一个常见的痛点仍然存在：组织如何自信地调整 GPU 资源以处理推理工作负载，并优化总体拥有成本 (TCO) ？延迟目标、模型选择、奇怪的流量模式和预算限制混合在一起，令人眼花乱，即使在部署单个模型之前，也很容易就会感到迷失在杂草中。

当今的推理格局不仅仅受硬件规格或“每秒 token 数”的影响。团队面临着越来越多的规模决策：哪种延迟才是真正重要的因素、第一 token 时间 (TTFT) 平均值、第 99 百分位延迟、token间延迟等等？您的用例的 token 模式将如何驱动 GPU 显存和计算需求？本地核心容量与基于云的弹性之间的正确平衡是什么？

本文提供了一个实用框架，用于将您的用例映射到正确的 GPU 占用空间，并根据实际工作负载行为 (而非猜测) 调整推理 GPU 基础架构的规模。我们将介绍最重要的输入，包括用例、token模式、延迟目标、并发性、缓存命中率、模型选择和部署策略。在此过程中，开发者和基础设施团队将了解 core-and-flex 容量规划、适当大小的 GPU 以及量化、剪枝和蒸馏等模型优化技术如何在提高性能的同时降低 TCO。

了解您的用例：确定规模和 TCO 的起点

解决噪音问题始于一个看似简单的问题：您要解决什么问题？不同的用例映射到截然不同的基础架构占用空间。总的来说，大多数推理工作负载都属于以下四个类别之一：

• AI 聊天机器人/ 助手
• AI 智能体 (深度研究和推理)
• 内容生成
• 翻译应用

关键配置输入，实现更智能的 TCO

映射您的用例后，请围绕以下维度制定大小规划：

• 模型选择 (LLM) ：更大并不总是更好。考虑使用 Nemotron 3.5 Lightning、Inkling Small、Muse Glimmer 等主流模型，或其他符合您的数据和延迟要求的模型。此外，还可以利用经过微调的较小模型。
• 应用规模：衡量应用的规模并预测用户群增长。
• DAU 和并发：了解您的日常活跃用户 (DAU) ，以及他们将同时发出多少请求。与原始 DAU 相比，高并发对 GPU 显存和延迟的压力更大。
• ISL/OSL：预测输入和输出字符串长度 (每个提示符的token) ，字符串越长，GPU 显存和计算需求就越高。
• 缓存命中率：估算跨请求重复的输入token所占比例，并且可以从 KV 缓存提供服务，而不是重新计算。较高的缓存命中率会跳过这些token的预填充，从而降低 TTFT 和每次请求的成本，这可能会降低相同流量所需的 GPU 容量。
• 延迟指标：TTFT 对于快速响应的用户体验至关重要。考虑一下第 99 百分位和 token 间延迟指标。
• 每天每个 DAU 的请求数：知道数据单位后，乘以每位用户的请求数，即可估算每日总工作负载。
• 合同长度：稳定、可预测的流量可能需要签订长期合同或本地基础设施。灵活的按需 (云或即点) 容量可让不稳定或实验性工作负载从中受益。

实施 Core-and – Flex 模型：降低风险并优化支出

不要让不可预测的工作负载推高成本。采用 Core-and – Flex 策略：

• 核心：为稳定状态的工作负载建立本地或保留云 GPU 容量的基准。这样可以降低价格波动的风险，并确保您的大多数用户都能获得可靠的服务。
• Flex：公有云弹性层 (现货或按需 GPU) ，用于处理激增、发布或实验。这可将运营支出转化为缓冲，在不过度投入的情况下实现创新。

该模型在资本支出 (capex) 和运营敏捷性 (opex) 之间取得了平衡，可确保您不会过度调配或抑制增长。

不要忘记实际因素

• 托管：如果您的数据位于本地且容量稳定，您可以跳过此设置。但是，快速扩展或数据驻留要求可能需要托管合作伙伴进行横向扩展。
• 选择合适的 GPU：将 GPU 与工作负载的内存占用、延迟目标和并发配置文件相匹配。当容量超出工作负载需求时，利用率会下降，每个 token 的成本也会上升；当容量超出工作负载的内存或计算需求时，吞吐量和延迟会受到限制。根据您运行的特定模型和提示长度进行适当调整，可确保性能和成本保持一致。

示例场景

以下场景说明了不同的企业工作负载如何处理 GPU 大小和 TCO 估算。这些示例仅用于演示目的；实际 GPU 数量、配置和成本结果因模型类型、工作负载复杂性、并发性和性能目标而异。

1. 金融服务 – 适用于关系经理的 Copilot

当地信用联盟为客户经理部署 AI Copilot，分析复杂的客户电子邮件 (长输入、短输出) ，以提供快速、量身定制的回复和知识检索。每个 copilot 会话平均每个查询 5000 个输入token和 500 个输出token。

• TTFT：以低于 1 秒的延迟为目标，在客户端通信环境中提供响应灵敏的无缝用户体验。
• 并发性：对于中小型团队而言，规划 10-50 个并发会话通常就足够了。在高流量时段，可能需要突发扩展。
• 精度：对于知识密集型和合规性关键型任务，请使用高精度 ( FP16 或 BF16) 推理模式，以确保输出一致、准确。
• LLM 模型类型：中型 ( 7-130 亿个参数) 指令调整模型，利用内部知识库针对推理、总结和检索增强生成进行优化，通常非常适合需要细致理解书面通信的任务。
• 显存建议：对于较小的 7-8B 型号，建议使用具有 24GB 左右显存的 GPU；对于 13B 型号，建议将其扩展到 48GB，以便在这些提示长度下为 KV 缓存留出空间，同时针对多用户场景和快速检索进行优化。

2. 生命科学 – 用于药物研发的 AI 智能体

制药初创公司实验室使用 AI 智能体为科学研究团队提供支持，处理研究文章 (超长上下文) 的全文，以获得见解并生成结果摘要。查询通常涉及 20000 个输入token和 2000 个输出token。

• TTFT：在非常大的背景下，以 2 秒为目标，平衡响应速度与处理科学输入全文的需求。
• 并发：为 20-30 个并发用户提供处理协作研究的空间；考虑为峰值提供额外的空间。
• 精度：高精度 (FP16 或更高) 至关重要，在处理技术和科学内容以保持事实准确性时。
• LLM 模型类型：采用长上下文模型 ( 16K-3.2 K token) ，通过生物医学文献或特定领域语料库的持续预训练进行微调或调整。
• 内存推荐：选择极高的内存容量 (每个单元通常超过 80GB) ，以支持 ISL/ OSL 请求，并确保在批量或并行工作流期间性能稳定。

3. 媒体和营销 – 实时内容生成器

中型数字营销机构构建了一个生成系统，该系统可根据简短简报 ( 500 个输入，2000 个输出 token) 创建个性化电子邮件和广告文案。随着广告活动的发布需要大量同时在线的用户，以及在制作周期中平衡创意输出速度和成本效益的强烈需求。

• TTFT：对于短输入和中等长度输出，低于 1 秒的 TTFT 可提供响应灵敏的创意生成功能。
• 并发：制定快速扩展计划，以支持活动驱动的突发使用；在营销高峰时段为 50-100% 的同时用户设计。
• 精度：FP16 精度可为创意文案生成和个性化任务提供理想的质量和效率组合。
• LLM 模型类型：使用通用指令调整或对话式 LLM ( 3-7B 参数) ，通过轻量级微调或提示工程进行调整，以遵循营销提示和风格色调。
• 显存推荐：每个 GPU 的 16-24GB 显存通常可适应广告提示大小，并支持大规模高效批量调度。

4. 技术咨询 – 大规模翻译平台

一家企业 IT 公司为客户部署开发了多语种代码和文档翻译工具。每个请求 ( 1000 个 token 输入/ 输出) 来自分布在全球各地的团队。

• TTFT：低 TTFT (远低于 1 秒) 对于流畅的交互式翻译体验至关重要，尤其是在自动化工作流程中。
• 并发性：针对隔夜批处理活动和全球需求激增，调整系统规模以处理数百个并发请求，并制定弹性扩展计划，理想情况下可实现自动扩展。
• 精度：对于语言和代码翻译，FP16 或 INT8 精度可提供足够的保真度，同时具有高吞吐量和成本节约。
• LLM 模型类型：大中型多语言模型 (例如，混合专家模型或扩展词汇表架构) ，为代码和特定领域的翻译提供架构支持，最适合企业级平台。
• 内存推荐：入门级 GPU ( 8-16GB 内存) 适合处理请求，尤其是在分布式、可扩展的云环境中进行编排时。

优化模型以降低 TCO

针对 TCO 进行优化通常归结为战略性地减少模型的内存占用，这是可用的最有效的举措之一。占用空间更小，可以在紧凑或低成本的 GPU 上运行，在许多情况下，可以降低整个 GPU 级别。其中有三个杠杆，大致按照工程工作的顺序排列：

• 量化：降低数值精度 (FP16 -> FP8/ INT8) ，无需重新训练即可将内存减少 25-50%。
• 剪枝：删除不太关键的层或神经元，以缩小参数数量和计算量。
• Knowledge 蒸馏：能够将体型庞大的教师迁移到体型较小、速度更快的学生。

这些工作都不是一次性的；随着模型和工作负载的发展，请重温这些工作。在企业级环境中，硬件、电源和运营开销的累计节省证明了该投资的合理性。

量化：快速致胜

模型通常以 16 位浮点 (FP16/ BF16) 的形式发布，每个参数需要 2 个字节。量化以 8 位格式 ( FP8 或 INT8) 重新表示一个字节的权重，并可选择激活函数和 KV 缓存，大约将权重内存减半。释放的内存可让您占用更小的 GPU，或在同一 GPU 上容纳更大的批量或更长时间的 KV 缓存，从而提高吞吐量并降低每 token 的成本。

这就是“速赢”，因为它不需要重新训练。训练后量化 (PTQ) 可将已训练的模型转换就位，仅使用少量具有代表性的提示进行校正，从而设置每层缩放系数，将 FP16 范围映射为 8 位，并将失真降至最低。

FP8 是推荐的起点，通常接近无损推理，比 INT8 或 INT4 有更大的空间。准确性容差因用例而异；在生产前根据您的工作负载进行验证。当 PTQ 损失超过可接受的值时，请升级到量化感知训练 (QAT) ，该训练会通过前向传递中的量化模拟进行微调，以便权重适应较低的精度。请参阅 ModelOpt 获取更多信息。

NVIDIA ModelOpt 生成了几行 PTQ 代码：

import torch
import modelopt.torch.quantization as mtq
from modelopt.torch.export import export_hf_checkpoint
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B-Instruct", dtype=torch.float16, device_map="auto"
).eval()
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.1-8B-Instruct")

def calibration_loop(model):
    for prompt in ["Summarize this client email:", "What are the key risks here?"]:
        inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
        with torch.no_grad():
            model(**inputs)

model = mtq.quantize(model, mtq.FP8_DEFAULT_CFG, forward_loop=calibration_loop)
export_hf_checkpoint(model, export_dir="./llama-3.1-8b-fp8")

如图 1 所示，FP8 量化可在不重新训练的情况下将 Llama-3.1-8B 权重内存从 16.06 GB 缩减至 9.08 GB，减少了 43.5%。有关更深入的演练，请参阅使用后训练量化优化 LLM 以实现性能和准确性，使用 NVIDIA NeMo 和 TensorRT Model Optimizer 对 LLM 进行后训练量化，以及使用 TensorRT 将 FP8 检查点转换为高性能推理引擎。

剪枝和蒸馏：更进一步

当量化还不够时，剪枝和蒸馏可以实现更深层次的压缩。剪枝会删除不太关键的组件，包括整个图层 (深度剪枝) 或注意力头、FFN 通道和嵌入维度 (宽度剪枝) 。Knowledge 蒸馏通过训练被剪枝的学生来对抗原始教师，从而恢复准确性。一次性计算成本被持续节省的硬件利用率、功耗和运营开销所抵消。

以下示例使用配备 Qwen3-8B 的 NVIDIA NeMo 作为教师，目标受众是大约 60 亿名学生。将 Hugging Face 模型转换为 NeMo Checkpoint 格式，并先对 WikiText-103-v1 进行预处理，然后剪枝。在剪枝步骤中，我们将真正重塑架构，深度剪枝会调整 36- > 24 层，而宽度剪枝会缩小 ffn_hidden_size 12288- > 9216 和 hidden_size 4096- > 3584，两者都会生成大约 60 亿个参数：

预备知识：2 个 NVIDIA H100 或 A100 80GB GPU、支持 Docker 的环境和 NeMo 容器 ( nvcr.io/nvidia/nemo：25.11，nvidia-modelopt++ 0.37.0) 。

步骤：修剪 (深度或宽度)

NEMO_TEACHER_PATH="./nemo_ckpt/Qwen3-8B.nemo"   # original (un-pruned) Qwen3-8B .nemo

# Pruning runs single-GPU — FastNAS asserts tp_size=1 for both depth and width pruning
PRUNE_COMMON="--devices 1 --tp_size 1 --pp_size 1 \
  --restore_path ${NEMO_TEACHER_PATH} --legacy_ckpt \
  --seq_length ${SEQ_LENGTH} --num_train_samples ${NUM_TRAIN_SAMPLES} --mbs ${MICRO_BATCH_SIZE} \
  --data_paths ${DATA_PATHS} --index_mapping_dir ${INDEX_MAPPING_DIR}"
PRUNE="torchrun --nproc_per_node 1 ${NEMO_ROOT}/scripts/llm/gpt_prune.py"

# Step 1a — Depth pruning: 36 → 24 layers (~6B model)
${PRUNE} ${PRUNE_COMMON} --save_path ${ROOT_DIR}/Qwen3-8B-nemo-depth-pruned \
  --target_num_layers 24

# Step 1b — Width pruning: ffn_hidden_size 12288→9216, hidden_size 4096→3584
${PRUNE} ${PRUNE_COMMON} --save_path ${ROOT_DIR}/Qwen3-8B-nemo-width-pruned \
  --target_ffn_hidden_size 9216 --target_hidden_size 3584

#Step 2 — Distillation: train each pruned student against the teacher
TRAIN="torchrun --nproc_per_node ${DEVICES} ${NEMO_ROOT}/scripts/llm/gpt_train.py"

# Step 2a — Depth-pruned student
${TRAIN} \
  --name depth_distill --model_path ${ROOT_DIR}/Qwen3-8B-nemo-depth-pruned \
  --teacher_path ${NEMO_TEACHER_PATH} --log_dir ${ROOT_DIR}/depth_distill_logs --legacy_ckpt \
  --data_paths ${DATA_PATHS} --index_mapping_dir ${INDEX_MAPPING_DIR} --seq_length ${SEQ_LENGTH} \
  --max_steps ${MAX_STEPS} --gbs ${GLOBAL_BATCH_SIZE} --mbs ${MICRO_BATCH_SIZE} \
  --val_check_interval ${VAL_CHECK_INTERVAL} --precision bf16-mixed

# Step 2b — Width-pruned student (same as above, swap the two lines below)
#   --name width_distill --model_path ${ROOT_DIR}/Qwen3-8B-nemo-width-pruned

注意：出于演示目的，此处使用的数据集相对较小，因此应将这些数字视为说明性数据，而非确定性数据。如图 2 所示，在本次运行中，宽度剪枝达到了较低的最终验证损失 ( 3.21 与 3.60) ，而深度剪枝收速度更快。为便于参考，NVIDIA 已发布的运行结果可生成一个 6B 深度剪枝模型，该模型在 MMLU 精度更高 ( 72.5 与 70.0) 的情况下，比 Qwen3-4B 快 30%。

有关完整的工作流、端到端文档和架构建议，请参阅使用 NVIDIA NeMo 框架的 LLM 模型剪枝和知识剪枝_ XDISTILLATIONX_XX、使用 NVIDIA TensorRT Model Optimizer 剪枝和蒸 LLM，以及Llama-3.1-to-Minitron 博客。

下一步行动

GPU 配置是一项持续优化，而不是部署时的固定选择。量化、剪枝和蒸馏为团队提供了在不牺牲性能的情况下降低基础设施成本的具体手段。从量化开始，立即减少占用空间；随着工作负载的成熟，分层进行剪枝和蒸馏；随着模型的发展，重新访问 — — 生成更小、更快速的模型，将 AI 的覆盖范围扩展到移动、边缘和嵌入式应用。

要开始使用模型优化，请查看 NVIDIA Model Optimizer GitHub 和 Hugging Face，深入了解模型量化，了解如何使用 Model Optimizer 进行后训练量化。