本地大模型上线要几张 GPU？从单实例负载算副本与故障余量

“这款模型能同时跑四个请求”还不能决定买几张 GPU。现有并发、平均延迟和 GPU 利用率，都不能脱离请求长短、目标响应时间、排队与到达形状，直接换算副本数。先得到一个实测的服务边界，再验证多副本接入路由、加载、故障和硬件放置后是否仍能达标。

单实例推理负载试验找出最后一档通过任务质量和服务目标的持续到达率。本文从这个结果出发，回答整个服务需要多少 Ready 副本和 GPU 槽位。本地与云 API 决策选择部署路径，完整工作流成本图计算更广的运行费用；它们都不能替代放置与故障试验。

先定义可比较的单副本容量

c_test 指一个副本在声明的质量、P95 首 Token 与完整响应、拒绝比例及稳定队列规则下，已经实测通过的最高持续请求到达率。它不是厂商宣称的每秒请求量，也不是无限速压测的峰值。记录确切模型文件、引擎版本、每副本 GPU 数、上下文、批处理及缓存设置、输入输出长度组合、流式方式、网关限额和热机状态。变更其中一项，这个数字就不再描述新副本。

λ_design 是服务必须承接的、同类负载和同一观察窗口的到达率。应从真实或预测流量轨迹取得，覆盖相关突发和长请求。全天平均通常低于关键的几分钟。若突发时长短请求比例也改变，应单独实测这种组合或重放轨迹；一个速率数字不能让长短请求变得等价。

再选择 0 到 1 之间的余量比例 h，说明它针对什么：测量不确定性、请求长度漂移、路由不均或计划缓冲。初步公式为：

每个 Ready 副本的规划容量 = c_test × (1 − h)
N_base = ceil(λ_design / [c_test × (1 − h)])
这组候选副本运行占用的 GPU 槽位 = N_base × 每副本 GPU 数

分母必须大于零。负载组合、延迟目标、模型或副本硬件与试验不同，就不能直接套公式。N_base 只是候选数，假设请求能合理分配到各 Ready 副本，且单副本实测边界在网关和集群里仍成立。把余量写明，避免不知不觉算两次，或让一个四舍五入的数字藏住全部假设。

把故障和放置算进去，再说 GPU 数量

先选服务必须承受的故障：一个 Pod、一张 GPU、一台节点，还是整个可用区。逐情景数故障后仍 Ready 的副本，不能只看期望副本数。若失去最大故障域后剩 R_ready，其候选容量是 R_ready × c_test × (1 − h)；在同样的任务和响应门槛下仍须覆盖 λ_design。独立且相同的副本只故障一个时，初算可用 N_base + 1；一台节点放两个副本就会一次损失两个，可用区可能损失更多。冗余是放置结果，不是表格里的一个百分比。

按真实放置把副本转成 GPU 槽位。一个张量并行副本使用两张 GPU，仍是一个服务副本，占两个 GPU 槽位；任意一张 GPU 故障都可能使整个副本不可用。Kubernetes 通过设备插件暴露扩展资源并据此调度 GPU 请求。检查每台节点能否一起提供所需 GPU、显存和互联条件，以及计划中的故障域分布。拓扑分布约束有助于把 Pod 分散到节点或可用区，但仍要核对实际调度结果，并模拟损失后还剩多少。

还要分开正在运行且 Ready 的 GPU与集群峰值或预留 GPU。滚动更新可能临时多启动一个副本；故障节点的替代副本需要别处有空位；备用 Pod 即使已调度也未必 Ready。写清更新时最多新增多少、替代副本放哪里、云上容量是否真的能取得。只数稳定运行的 Pod，可能导致服务无法更新或自动恢复。

扩容要赶在队列失败之前

自动扩容不会瞬间产能。从扩容命令到副本能通过真实推理探针，实测镜像拉取、模型下载、权重加载、预热、健康检查和路由更新时间。Kubernetes 启动探针能给慢启动容器初始化时间，避免存活探针过早杀掉它；就绪探针决定 Pod 是否接收服务流量。HTTP 进程活着不等于模型已加载，就绪信号要用真实推理路径验证。

Kubernetes HPA 可以使用资源、自定义或外部指标。vLLM Production Stack 的文档给出 KEDA 加 Prometheus、使用等待请求等 vLLM 指标的扩容示例；这是一个实现选项，不存在所有系统通用的阈值。vLLM 也提供运行中／等待请求数、首 Token 和端到端延迟指标，可用来解释扩容触发和效果。对比模型预热更短的突发，等待队列往往是太晚的信号；可能需要预热的最低副本数、按已知时间提前扩容、入口限流，或明示等待时间的队列。用目标流量轨迹测试触发、稳定窗口和缩容冷却行为。

案例一：单 GPU 复核服务

下面是虚构教学计算，不是任何硬件的实测性能。某复核助手的单 GPU 副本，在同题负载下通过 c_test = 0.8 请求/秒；计划突发为 λ_design = 2.0 请求/秒，团队选 h = 0.20。规划容量是 0.8 × 0.8 = 0.64 请求/秒，所以 N_base = ceil(2.0 / 0.64) = 4 个 Ready 副本，占四张 GPU。

服务还要求任意一个副本故障后继续达标。四个副本故障一个只剩三个，规划总量 3 × 0.64 = 1.92 请求/秒，低于目标。五个 Ready 副本故障一个还剩四个，候选总量为 2.56 请求/秒；如果故障假设是一台节点，就要让这五个单 GPU 副本分布在独立节点上。滚动更新若可能额外拉起一个副本，调度器在更新峰值可能还要有第六个 GPU 槽位。这些数字都不能证明 P95 延迟：仍要让五副本重放突发，移除一个，再检查余下四个是否通过同一套服务规则。

案例二：双 GPU 副本与可用区故障

这同样是虚构教学计算。一个模型每副本使用两张 GPU；同题压测得到 c_test = 0.5 请求/秒，服务要求 λ_design = 1.2 请求/秒，余量 h = 0.25，故单个 Ready 副本规划容量为 0.375 请求/秒。基础数量 ceil(1.2 / 0.375) = 4 个副本，即八个运行 GPU 槽位。若只要求损失一个副本，五个 Ready 副本会留四个，常态占十张 GPU。

真实要求更高：三个可用区中任意一个失效仍需达标。五个副本按 2、2、1 分布，损失放两个副本的可用区后只剩三个，3 × 0.375 = 1.125，达不到目标。六个副本按 2、2、2 分布，损失一个区后剩四个，候选总量 1.5 请求/秒。这需要跨合适节点和可用区部署12 个 Ready GPU 槽位。若滚动更新必须在六个仍 Ready 时多启动一个双 GPU 副本，峰值放置可能需要14 个 GPU 槽位。还必须实测摘掉一个可用区后的路由、队列和 P95 响应，并检查替代容量能否调度。

假设新副本从下载、加载到预热需要七分钟，而突发两分钟内到顶，事后响应的扩容赶不上这个突发。应保持必要副本预热、按已知日程提前扩容，或改变入口处理方式；未 Ready 的副本不能算故障容量。

填写容量工作表并重放故障

下面的工作台记录单实例来源、算式、放置、预热和集群实测。填写速率单位与观察窗口；每个故障域复制一行情景。算式通过但还没测结果，应保持未测试。

工作表行	至少填写
可比压测	任务与模型版本、每副本 GPU 数、输入输出组合、响应门槛、c_test、队列表现、来源轨迹
需求与余量	λ_design、窗口和突发形状、h 及理由、每副本规划容量和 N_base
故障放置	各节点／区的 Ready 副本、最大损失、剩余 Ready 数、GPU 槽位、更新额外副本与替代空位
扩容	指标与阈值、最低热副本数、拉取／加载／预热耗时、就绪探针、允许的最大等待
实证	正常峰值重放、故障重放、替代副本预热、合格结果、P95 延迟、拒绝、等待趋势、决定与负责人

常见问题

**平均延迟或 GPU 利用率能算副本数吗？**不能。它们有助于诊断，却不能单独指定到达形状、输出长度、尾部延迟、队列稳定性和合格结果。先测目标下的 c_test。

**能用用户并发数除以“每卡请求数”吗？**不能。用户活跃程度不同，在途请求的预填充和生成工作也不同。应用带长度与响应目标的到达轨迹。

**有 HPA 或 KEDA 就不需要热备了吗？**只有新副本能在服务目标被突破前 Ready 才行。要把可用 GPU 放置在内，实测完整扩容延迟。

不适用边界

这份工作表只为指定模型、负载组合、引擎、硬件和服务目标提供副本与 GPU 槽位候选数；它不能证明集群网络、负载均衡、存储、节点可用性、可用区独立性或替代副本可调度。权重、上下文、量化、流量、路由、GPU 类型、扩缩容和滚动更新设置变化后，重做单副本与集群故障试验。只有正常、突发及所要求故障的重放都通过任务和服务门槛，才能据此确定容量。