如何为 AI 推理确定 GPU 规模并优化 TCO：NVIDIA 实用框架

AI 采用的激增正在改变从聊天机器人到内容生成的一切。然而，一个常见的痛点依然存在：组织如何能够自信地为推理工作负载确定 GPU 资源规模并优化总拥有成本（TCO）？面对令人眼花缭乱的延迟目标、模型选择、奇特的流量模式和预算限制，即使在部署单个模型之前，也很容易感到迷失在细节中。

当今的推理格局不仅仅由硬件规格或“每秒令牌数”决定。团队面临越来越多的规模决策：哪种延迟真正重要，是首令牌时间（TTFT）平均值、第 99 百分位延迟、令牌间延迟，还是其他？您的用例的令牌模式将如何驱动 GPU 内存和计算需求？本地核心容量与基于云的弹性之间的正确平衡是什么？

本文提供了一个实用框架，用于将您的用例映射到正确的 GPU 占用空间，围绕真实工作负载行为而非猜测来确定推理 GPU 基础设施的规模。我们将介绍最重要的输入，包括用例、令牌模式、延迟目标、并发性、缓存命中率、模型选择和部署策略。在此过程中，开发人员和基础设施团队将看到核心与弹性容量规划、适当规模的 GPU 以及模型优化技术（如量化、剪枝和蒸馏）如何在提高性能的同时降低 TCO。

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

拨开迷雾始于一个看似简单的问题：您要解决什么问题？不同的用例映射到截然不同的基础设施占用空间。在高层次上，大多数推理工作负载属于以下四类之一：

• AI 聊天机器人/助手
• AI 代理（深度研究和推理）
• 内容生成
• 翻译应用

表 1. 各种工作负载场景中 GPU 输入和输出令牌的用例；这些是说明性数字，实际生产场景中观察到的值可能会有很大差异

实现更智能 TCO 的关键规模输入

映射您的用例后，围绕以下维度构建您的规模计划：

模型选择（LLM）： 更大并不总是更好。考虑主流模型，如 Nemotron 3.5 Lightning、Inkling Small、Muse Glimmer，或其他符合你的数据和延迟要求的模型。也可以利用更小的微调模型。应用规模： 评估你的应用规模，并预测用户群的增长。DAU 与并发： 了解你的日活跃用户（DAU）以及他们将同时发出多少请求。高并发对 GPU 内存和延迟的压力比单纯的 DAU 更大。ISL/OSL： 预测输入和输出字符串长度（每个提示的 token 数），更长的字符串意味着更高的 GPU 内存和计算需求。缓存命中率： 估算在请求之间重复、且可以从 KV 缓存提供而无需重新计算的输入 token 占比。更高的缓存命中率会跳过这些 token 的预填充，降低 TTFT 和每请求成本，从而在相同流量下降低你所需的 GPU 容量。延迟指标： TTFT 对于响应迅速的用户体验至关重要。还要考虑第 99 百分位和 token 间延迟指标。每 DAU 每日请求数： 一旦知道 DAU，乘以每用户请求数即可估算每日总工作负载。合同期限： 稳定、可预测的流量可能适合长期合同或本地基础设施。波动性或实验性工作负载则受益于灵活、按需（云或竞价）容量。

实施核心加弹性模型：降低风险并优化支出

不要让不可预测的工作负载推高成本。采用核心加弹性策略：

核心： 为稳态工作负载建立本地或预留云 GPU 容量的基线。这降低了价格波动的风险，并确保为大多数用户提供可靠的服务。弹性： 叠加公共云弹性（竞价或按需 GPU）以应对高峰、发布或实验。这将运营支出转化为缓冲，使创新无需过度承诺。

该模型在资本效率（capex）和运营敏捷性（opex）之间取得平衡，确保你既不会过度配置，也不会抑制增长。

不要忘记实际因素

托管： 如果你的数据在本地且容量稳定，你可能可以跳过这一点。然而，快速扩张或数据驻留要求可能需要托管合作伙伴来实现扩展。选择合适的 GPU： 将 GPU 与你的工作负载的内存占用、延迟目标和并发特征相匹配。当容量超前于工作负载所需时，利用率下降，每 token 成本上升；当容量落后于工作负载的内存或计算需求时，吞吐量和延迟会受到限制。根据你运行的具体模型和提示长度进行合理配置，可使性能与成本保持一致。

示例场景

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

1. 金融服务——关系经理 Copilot

一家本地信用合作社为关系经理部署了 AI copilot，分析复杂的客户电子邮件（长输入、短输出），以提供快速、量身定制的响应和知识检索。每个 copilot 会话平均每次查询 5,000 个输入 token 和 500 个输出 token。

TTFT： 目标是将延迟控制在1秒以下，以在客户沟通场景中提供响应迅速、无缝的用户体验。并发性： 对于中小型团队，规划10-50个并发会话通常就足够了。在高流量时段可能需要突发扩展。精度： 对于知识密集型和要求合规的关键任务，使用高精度（FP16或BF16）推理模式以确保输出一致、准确。LLM模型类型： 中等规模（7-13B参数）的指令调优模型，针对推理、摘要和基于内部知识库的检索增强生成进行了优化，通常非常适合需要细致理解书面通信的任务。内存建议： 对于较小的7-8B模型，建议使用约24GB内存的GPU，对于13B模型则扩展到48GB，以便在这些提示长度下为KV缓存留出余量，同时优化多用户场景和快速检索。

2. 生命科学——用于药物发现的AI代理

一家制药初创实验室使用AI代理支持科学研究团队，处理全文研究文章（极长上下文）以呈现见解并生成结果摘要。查询通常涉及20,000个输入标记和2,000个输出标记。

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

3. 媒体与营销——实时内容生成器

一家中型数字营销机构构建了一个生成系统，根据简短简报（500输入，2,000输出标记）创建个性化电子邮件和广告文案。随着活动启动需要突发增加的同时用户，并且在生产周期中强烈需要平衡创意输出速度和成本效率。

TTFT： 响应式创意生成受益于短输入和中等长度输出的TTFT低于1秒。并发性： 计划快速扩展以支持突发性、活动驱动的使用；在营销高峰期间设计支持50-100+同时用户。精度： FP16精度为创意文案生成和个性化任务提供了质量和效率的最佳结合。LLM模型类型： 使用通用指令调优或对话式LLM（3-7B参数），通过轻量级微调或提示工程进行适配，以遵循营销提示和风格语调。内存建议： 每个GPU 16-24GB内存通常可容纳广告提示大小，并支持大规模高效批处理调度。

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

一家企业IT公司为客户部署开发多语言代码和文档翻译工具。每个请求（1,000标记输入/输出）来自全球分布的团队。

TTFT：低 TTFT（远低于 1 秒）对于流畅、交互式的翻译体验至关重要，尤其是在自动化工作流中。并发性：对于夜间批处理活动和全球需求高峰，系统规模应能处理数百个并发请求，并规划弹性扩展，最好具备自动扩缩容能力。精度：对于语言和代码翻译，FP16 或 INT8 精度可提供足够的保真度，同时实现高吞吐量并节省成本。LLM 模型类型：中大型多语言模型（例如混合专家或扩展词汇架构），并具备对代码和特定领域翻译的架构支持，最适合企业级平台。内存建议：入门级 GPU（8-16GB 内存）适合处理请求，尤其是在分布式、可扩展的云环境中进行编排时。

优化模型以实现更好的 TCO

针对 TCO 进行优化通常归结为战略性地减少模型的内存占用，这是可用的最高杠杆手段之一。更小的占用让你能够在紧凑型或低成本 GPU 上提供服务，在许多情况下还能直接降低一个 GPU 层级。有三个杠杆，大致按工程投入排序：

量化：降低数值精度（FP16 -> FP8/INT8），将内存减少 25-50%，且无需重新训练。剪枝：移除不太关键的层或神经元，以缩小参数数量和计算量。知识蒸馏：将能力从大型教师模型迁移到更小、更快的学生模型。

这些都不是一次性工作；随着模型和工作负载的演变，需要重新审视它们。在企业规模下，硬件、功耗和运营开销方面的累积节省足以证明这项投资是值得的。

量化：快速见效

模型通常以 16 位浮点（FP16/BF16）形式发布，每个参数占两个字节。量化将权重（以及可选的激活值和 KV 缓存）重新表示为 8 位格式（FP8 或 INT8），每个参数占一个字节，大致将权重内存减半。释放出的内存让你能够降级到更小的 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 量化内存减少

如上文图 1 所示，FP8 量化将 Llama-3.1-8B 权重内存从 16.06GB 减少到 9.08GB——减少 43.5%，且无需重新训练。如需更深入的讲解，请参阅使用训练后量化优化 LLM 的性能与准确率、使用 NVIDIA NeMo 和 TensorRT Model Optimizer 对 LLM 进行训练后量化，以及使用 TensorRT 将 FP8 检查点转化为高性能推理引擎。

剪枝与蒸馏：更进一步

当量化不够时，剪枝和蒸馏可实现更深入的压缩。剪枝会移除不太关键的组件，包括整个层（深度剪枝）或注意力头、FFN 通道和嵌入维度（宽度剪枝）。知识蒸馏通过让剪枝后的学生模型针对原始教师模型进行训练来恢复准确率。一次性计算成本可通过硬件利用率、功耗和运营开销方面的持续节省来抵消。

下面的示例使用 NVIDIA NeMo，以 Qwen3-8B 作为教师模型，目标是约 6B 的学生模型。首先将 Hugging Face 模型转换为 NeMo 检查点格式并预处理 WikiText-103-v1，然后进行剪枝。剪枝步骤是实际重塑架构的环节——深度剪枝将层数从 36 削减到 24，而宽度剪枝将 ffn_hidden_size 从 12288 缩小到 9216，并将 hidden_size 从 4096 缩小到 3584，两者均得到约 6B 参数：

前提条件：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" # 原始（未剪枝）的 Qwen3-8B .nemo
# 剪枝在单 GPU 上运行 —— FastNAS 对深度剪枝和宽度剪枝都断言 tp_size=1
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"
# 步骤 1a —— 深度剪枝：36 → 24 层（约 6B 模型）
${PRUNE} ${PRUNE_COMMON} --save_path ${ROOT_DIR}/Qwen3-8B-nemo-depth-pruned \
--target_num_layers 24
# 步骤 1b —— 宽度剪枝：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
#步骤 2 —— 蒸馏：让每个剪枝后的学生模型针对教师模型进行训练
TRAIN="torchrun --nproc_per_node ${DEVICES} ${NEMO_ROOT}/scripts/llm/gpt_train.py"
# 步骤 2a —— 深度剪枝后的学生模型
${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
# 步骤 2b —— 宽度剪枝后的学生模型（与上面相同，替换下面两行）
# --name width_distill --model_path ${ROOT_DIR}/Qwen3-8B-nemo-width-pruned

图 2. 剪枝验证损失：深度与宽度对比

注意：出于演示目的，此处使用的数据集相对较小，因此这些数字应被视为示例性而非确定性的。如图 2 所示，在本次运行中，宽度剪枝达到了更低的最终验证损失（3.21 对 3.60），而深度剪枝收敛更快。作为规模参考，NVIDIA 公布的运行结果生成了一个 6B 深度剪枝模型，其速度比 Qwen3-4B 快 30%，同时 MMLU 准确率更高（72.5 对 70.0）。

有关完整流程、端到端文档和架构建议，请参阅使用 NVIDIA NeMo Framework 进行 LLM 模型剪枝与知识蒸馏、使用 NVIDIA TensorRT Model Optimizer 进行 LLM 剪枝与蒸馏以及Llama-3.1 到 Minitron 博客。

下一步方向

GPU 规模选择是一项持续进行的优化工作，而非部署时一次性做出的固定选择。量化、剪枝和蒸馏为团队提供了切实可行的手段，可在不牺牲性能的情况下削减基础设施成本。从量化入手可立即减小模型占用，随着工作负载成熟逐步引入剪枝和蒸馏，并随着模型演进不断重新审视——从而产出更小、更快的模型，将 AI 的触达范围扩展至移动端、边缘端和嵌入式应用。

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