本地部署大模型要几张 GPU：别只拿参数量乘两个字节

本地部署大模型要几张 GPU：别只拿参数量乘两个字节

“一个 8B 模型需要多少显存”看似是简单算术：FP16 权重大约每个参数两个字节，8B 权重接近 16GB。这个结果只能说明权重是否可能装进显存，无法回答几十个用户同时访问时是否稳定。NVIDIA 9 月 1 日发布的推理 GPU 规划指南，把模型选择、日活、并发、输入输出长度、KV Cache 命中率、首字延迟、Token 间隔和采购期限放进同一套容量模型，正好补上了参数量之外的部分。

聊天、Agent、内容生成和翻译的负载形状差别很大。聊天常见长输入、短输出，多轮历史会持续扩大上下文；Agent 可能携带极长检索材料并多次调用工具；内容生成输入短、输出长；翻译的输入输出长度通常更接近。即便两项业务每天使用相同 Token，总并发与峰值时段不同，也会得到完全不同的 GPU 数量和排队时间。

从一周真实日志估算容量

容量规划可以先收集一周请求日志，按业务场景统计输入 Token、输出 Token、缓存命中、每分钟请求数和并发会话。平均值只适合做预算初稿，生产配置还要看 P95 与 P99。首字延迟决定用户等待多久，Token 间隔影响流式回答是否顺畅，完整耗时则决定后台任务吞吐。三项指标不能合成一个“tokens/s”。

KV Cache 是最容易被忽略的显存占用。上下文越长、并发越高，缓存增长越明显。量化权重省下的空间可以留给更长上下文或更大批量，但 KV Cache 是否一并量化、精度是否可接受，都要单独验证。运行时、通信缓冲、CUDA 图和模型加载峰值也需要余量，按照权重大小刚好塞满的配置几乎没有故障恢复空间。

NVIDIA 文中的示例数字是说明方法，并非通用采购表。它给一个 7–8B、长输入短输出的 Copilot 场景建议约 24GB 显存，13B 扩到约 48GB；另一个长文科研 Agent 场景建议单卡容量超过 80GB。实际数量仍取决于模型架构、精度、推理框架、并发和目标延迟。采购前应在候选硬件上压测真实提示，模拟突发流量和最长上下文。

自托管与模型 API 要算同一份 TCO

稳定且可预测的基础流量适合长期租用或自有 GPU，活动发布、夜间批处理和实验流量更适合弹性资源。NVIDIA 将它概括为 core-and-flex：核心容量承接稳定需求，云端按需或 Spot 资源吸收峰值。对于团队规模较小的项目，直接使用模型 API 也属于弹性层，省去驱动、框架升级、故障切换和值班成本。

自托管 TCO 应包含 GPU、CPU、内存、存储、网络、电力、机房、备件、工程人力和闲置率；API TCO 则包含 Token、缓存、工具调用、网关、出站流量与供应商溢价。比较单位应统一到“完成一次合格任务”，并把错误重试和人工返工算进去。一个单价便宜但完成率低的模型，可能消耗更多总资源。

量化是降低门槛最快的手段之一。NVIDIA 示例中，FP8 将 Llama-3.1-8B 权重显存从 16.06GB 降到 9.08GB，减少 43.5%，且未重新训练；这只是该示例的结果。自己的领域任务要重新校准和回归，代码、数学、医疗等场景对精度变化的敏感度不同。进一步裁剪与蒸馏还会引入训练和维护成本。

如果业务流量仍在变化，可先通过 [AnyAIS 模型列表](/models) 和统一 API 收集一段时间的输入输出长度、延迟与成本，再判断稳定部分是否值得迁回自托管。用真实曲线做 GPU 采购，比从模型参数表反推服务器数量可靠得多。

来源：[NVIDIA：How to Size GPUs for AI Inference and TCO Without Overspending](https://developer.nvidia.com/blog/?p=121993)