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

AI 的快速普及正在改变从聊天机器人到内容生成的方方面面。然而，一个常见的痛点依然存在：企业如何有把握地为推理工作负载确定 GPU 资源规模，并优化总拥有成本（Total Cost of Ownership，TCO）？延迟目标、模型选择、变幻莫测的流量模式和预算约束交织在一起，哪怕还没部署任何一个模型，也很容易陷入细节的泥潭。

如今的推理格局，早已不只由硬件规格或“每秒词元数”决定。团队要面对越来越长的规模决策清单：究竟哪种延迟才重要，是首词元时间（Time to First Token，TTFT）的平均值、99 分位延迟、词元间延迟，还是别的指标？你的用例的词元模式会如何决定 GPU 显存和算力需求？本地核心容量与云端弹性之间，怎样才是合适的平衡？

本文提供一个实用框架，帮助你把用例映射到合适的 GPU 规模，依据真实的工作负载行为而非猜测来规划推理 GPU 基础设施。我们将逐一梳理影响最大的输入项，包括用例、词元模式、延迟目标、并发、缓存命中率、模型选择和部署策略。在此过程中，开发者和基础设施团队将看到，核心加弹性（core-and-flex）的容量规划、恰当选型的 GPU，以及量化、剪枝和蒸馏等模型优化技术，如何在提升性能的同时降低 TCO。

了解你的用例：规模与 TCO 的起点

要拨开迷雾，先要回答一个看似简单的问题：你要解决什么问题？不同的用例对应的基础设施规模天差地别。总体而言，大多数推理工作负载可归入以下四类：

• AI 聊天机器人/副驾驶（Copilot）
• AI 智能体（深度研究与推理）
• 内容生成
• 翻译应用

表 1. 不同工作负载场景下 GPU 的输入与输出词元用例；这些数字仅为示意，真实生产环境中的观测值可能大不相同

影响 TCO 的关键规模输入项

完成用例映射后，围绕以下维度制定你的规模规划：

• 模型选择（LLM）：模型并非越大越好。可以考虑 Nemotron 3.5 Lightning、Inkling Small、Muse Glimmer 等主流模型，或其他符合你的数据与延迟要求的模型。也可以采用经过微调的较小模型。
• 应用规模：评估你的应用规模，并预判用户群的增长。
• 日活用户（DAU）与并发：了解你的日活用户数（Daily Active Users，DAU），以及他们同时发出多少请求。相比 DAU 的绝对数量，高并发对 GPU 显存和延迟的压力更大。
• ISL/OSL：预测输入和输出序列长度（每条提示的词元数），序列越长，对 GPU 显存和算力的需求越高。
• 缓存命中率：估算在多次请求之间重复出现、可直接从 KV 缓存读取而无需重新计算的输入词元占比。缓存命中率越高，这些词元的预填充（prefill）就可以跳过，从而降低 TTFT 和单次请求成本，也就可能减少相同流量下所需的 GPU 容量。
• 延迟指标：TTFT 对响应灵敏的用户体验至关重要。同时也要考虑 99 分位延迟和词元间延迟指标。
• 每位 DAU 每日请求数：知道 DAU 后，乘以每位用户的请求数，即可估算每日总工作负载。
• 合约期限：稳定、可预测的流量适合长期合约或本地基础设施；波动大或处于实验阶段的工作负载则更适合灵活的按需（云或 Spot）容量。

落地核心加弹性模式：降低风险，优化支出

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

• 核心：为稳态工作负载建立由本地或预留云 GPU 构成的容量基线。这可以降低价格波动的风险，并确保为大部分用户提供可靠的服务。
• 弹性：叠加公有云的弹性（Spot 或按需 GPU），用来应对流量激增、产品发布或实验。这样就把运营支出（opex）变成缓冲，让创新无需过度投入。

该模式在资本效率（capex）与运营灵活性（opex）之间取得平衡，既避免过度配置，也不会束缚增长。

别忽略这些实际因素

• 托管机房（Colocation）：如果你的数据在本地且容量稳定，可以不考虑这一项。但如果业务快速扩张或有数据驻留要求，可能需要借助托管合作伙伴来横向扩展。
• 选择合适的 GPU：让 GPU 与工作负载的显存占用、延迟目标和并发特征相匹配。容量超出工作负载所需时，利用率下降，每词元成本上升；容量低于工作负载的显存或算力需求时，吞吐量和延迟则会受限。根据所运行的具体模型和提示长度来合理选型，才能让性能与成本保持一致。

示例场景

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

1. 金融服务——客户经理的副驾驶

一家本地信用合作社为客户经理部署了 AI 副驾驶，分析复杂的客户邮件（长输入、短输出），以提供快速、定制化的回复和知识检索。每次副驾驶会话平均每个查询包含 5,000 个输入词元和 500 个输出词元。

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

2. 生命科学——药物研发 AI 智能体

一家制药初创实验室使用 AI 智能体支持科研团队，处理全文研究论文（超长上下文），提炼洞见并生成结果摘要。查询通常涉及 20,000 个输入词元和 2,000 个输出词元。

• TTFT：考虑到上下文非常长，目标是低于 2 秒，在响应速度与处理全文科学输入的需求之间取得平衡。
• 并发：为支持协作式研究，按 20-30 个并发用户配置；高峰时段可考虑预留更多余量。
• 精度：处理技术和科学内容时，高精度（FP16 或更高）对保持事实准确性至关重要。
• LLM 模型类型：采用长上下文模型（16K-32K 词元），并在生物医学文献或特定领域语料上通过微调或持续预训练进行适配。
• 显存建议：选择超大显存容量，通常每块 GPU 超过 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 缓存，从而提高吞吐量、降低每词元成本。

它之所以是“快速见效”的手段，是因为无需重新训练。训练后量化（Post-Training Quantization，PTQ）直接就地转换已训练好的模型，只需一小批有代表性的提示进行校准，设定各层的缩放因子，把 FP16 的数值范围以最小的失真映射到 8 位。

推荐从 FP8 入手——推理时通常接近无损，相比 INT8 或 INT4 有更大的余量。精度容忍度因用例而异；上线生产前请针对你的工作负载进行验证。当 PTQ 的损失超出可接受的阈值时，可升级到量化感知训练（Quantization-Aware Training，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.06GB 降到 9.08GB——减少 43.5%，且无需重新训练。更深入的讲解请参阅 Optimizing LLMs for Performance and Accuracy with Post-Training Quantization、Post-Training Quantization of LLMs with NVIDIA NeMo and TensorRT Model Optimizer 以及 Turning FP8 Checkpoints into High-Performance Inference Engines with TensorRT。

剪枝与蒸馏：更进一步

当量化还不够时，剪枝和蒸馏可以实现更深层的压缩。剪枝会移除不太关键的组成部分，包括整层（深度剪枝），或注意力头、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"   # 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 模型，其速度比 Qwen3-4B 快 30%，MMLU 准确率更高（72.5 对 70.0）。

完整的流程、端到端文档和架构建议，请参阅 LLM Model Pruning and Knowledge Distillation with NVIDIA NeMo Framework、Pruning and Distilling LLMs Using NVIDIA TensorRT Model Optimizer 以及 Llama-3.1-to-Minitron 博文。

下一步

GPU 规模规划是一项持续的优化，而非部署时一次性做出的固定选择。量化、剪枝和蒸馏为团队提供了在不牺牲性能的前提下削减基础设施成本的具体手段。先从量化入手，立即缩小占用；随着工作负载成熟再叠加剪枝和蒸馏；并随着模型的演进不断回头复查——最终得到更小、更快的模型，把 AI 的触角延伸到移动、边缘和嵌入式应用。

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