创业公司 GPU 成本：Serverless、独占与混合容量

不用供应商小时单价拍脑袋，按有效 GPU 小时、冷启动、闲置、运维和 SLO 计算 Serverless 与独占 GPU 的盈亏平衡点，并设计混合容量迁移路径。

Serverless GPU 和独占 GPU 没有固定赢家。验证期最贵的是等待，稳定生产期最贵的是长期按量溢价，平台能力不足时最贵的是故障和工程师时间。更有用的问题是：“未来三个月的有效 GPU 小时、延迟要求和运维能力分别是什么？”

本文把 Dedicated 统一称为长期独占的 GPU 节点或容量；Serverless 指按请求、任务、容器运行时间或 GPU 秒计费，并由平台负责底层节点和大部分运行环境的服务。不同供应商的最小计费时长、冷启动、镜像缓存和网络费用差异很大，最终计算必须使用自己的账单与压测数据。

先按工作负载判断

工作负载	优先选择	原因
Demo、模型频繁变化、每天只运行几小时	Serverless	少预付，环境切换快，闲置成本低
流量尖峰明显、异步任务可排队	Serverless 或混合容量	峰值不需要永久保留
7×24 小时稳定推理、模型和并发已固定	独占或预留容量	固定成本更容易摊薄，缓存和延迟可控
严格 TTFT/TPOT、不能接受冷启动	独占容量	需要常驻模型、稳定网络和明确故障域
长时间训练、数据量大、检查点频繁	独占容量	数据局部性、网络和运行连续性更重要
基础流量稳定、活动或批任务波动大	混合容量	独占资源承载基线，Serverless 吸收突发

早期团队常犯两个相反错误：看到 Serverless 单价高就过早买固定容量，或者因为 Serverless 上线快，业务稳定后仍不重新算账。

先算盈亏平衡，不猜

设：

C_d：一张独占 GPU 每月总成本。
C_s：Serverless 的有效 GPU 小时成本。
H：每月实际需要的等效 GPU 小时。

忽略性能差异时：

Serverless 月成本 = C_s × H
盈亏平衡小时 H* = C_d ÷ C_s
盈亏平衡利用率 U* = H* ÷ 730

假设独占节点完整月成本为 2,000 美元，Serverless 有效成本为 4 美元/GPU 小时：

H* = 2,000 ÷ 4 = 500 GPU 小时
U* = 500 ÷ 730 ≈ 68.5%

这只是计算示例，不是市场报价。如果预计每月只有 150 个有效 GPU 小时，固定节点大部分时间会空转；如果稳定超过 500 小时，独占容量开始值得认真评估。

C_d 不能只填机器租金，还应包括：

闲置和故障预留容量。
驱动、CUDA、容器运行时和节点镜像维护。
监控、值班、容量规划和故障演练。
存储、网络、负载均衡与跨区流量。
工程师被基础设施占用的时间。

C_s 也不能只抄页面单价，还应包括：

最小计费粒度和容器空闲保留时间。
冷启动期间是否计费。
模型下载、持久卷、对象存储和公网流量。
请求失败、超时和重试产生的重复计算。
平台支持的 GPU、区域、配额和并发上限。

用等效 GPU 小时修正性能差异

不同平台即使写着同一 GPU 型号，CPU、内存、PCIe、网络和运行时配置也可能不同。应按完成相同工作量所需时间换算，而不是直接比较标价。

等效 GPU 小时 = 实际运行小时 × 基准吞吐 ÷ 当前平台吞吐

例如平台 A 每小时完成 1,000 个请求，平台 B 每小时完成 700 个请求。B 的标价即使低 20%，完成同一批请求仍可能更贵。

压测时固定这些变量：

模型 revision、量化方式和推理框架版本。
输入/输出 token 分布，而不是单个短 Prompt。
batch、并发、最大上下文和采样参数。
冷缓存与热缓存分别测试。
记录 TTFT、TPOT/ITL、吞吐、错误率和端到端成本。

最小 HTTP 计时只能做连通性和总延迟基线：

for i in $(seq 1 20); do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_connect} %{time_starttransfer} %{time_total}\n' \
    https://<endpoint>/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $API_KEY" \
    -d @request.json
done

正式结论应来自固定数据集和并发压测工具；不要拿一次 curl 当容量报告。

独占容量真正要求什么

买到节点只是开始。团队至少要能回答：

一台 GPU 节点故障后，服务能否在另一故障域恢复？
驱动、CUDA、GPU Operator 和推理框架如何做兼容验证与回滚？
模型缓存由本地盘、共享卷还是对象存储提供，冷恢复要多久？
GPU 使用率、显存、功耗、Xid、队列和业务延迟是否在同一监控链路？
谁负责容量预测、节点排空、升级窗口和夜间告警？

如果这些问题都由某个业务工程师“顺手处理”，独占 GPU 的真实成本通常被低估了。

反过来，Serverless 的自动扩缩也不是无限容量。需要确认区域配额、GPU 可用性、最大并发、扩容速度和失败时的退避行为。Knative 可以把工作负载缩到零，但 Kubernetes 工作负载缩到零，不等于底层 GPU 节点也立即停止计费；节点层是否缩容取决于集群自动扩缩和供应商实现。

混合容量的最小结构

稳定基础流量放在独占池，突发和异步任务进入弹性池：

flowchart LR Client[Client] --> Gateway[Inference Gateway] Gateway --> Base[Dedicated Base Pool] Gateway --> Queue[Burst Queue] Queue --> Burst[Serverless GPU] Base --> Metrics[Latency / Queue / Cost] Burst --> Metrics

不要只按“独占池 CPU 忙不忙”决定外溢。更有效的信号是预计排队时间、活跃序列、GPU KV Cache 占用和业务 SLO。异步任务直接进队列；同步请求只有在弹性端已预热且能满足延迟要求时才外溢。

两套环境必须保持：

相同模型 revision、tokenizer、量化方式和请求协议。
一致的鉴权、限流、审计和敏感数据处理规则。
可区分的日志、指标和成本标签。
明确的失败策略，避免同一请求在两端重复执行并重复计费。
独立健康检查，不能因某一端故障拖垮整个入口。

训练任务采用混合容量时，先验证检查点格式、对象存储吞吐和中断恢复。一个无法迁移的 20 小时训练任务，不是真正的弹性任务。

什么时候从 Serverless 迁出

以下信号连续出现两到三个账期，才值得迁移，不要被单周活动流量误导：

等效 GPU 小时稳定超过测得的盈亏平衡点。
核心模型和并发形态已经稳定。
冷启动或排队持续违反 SLO。
数据传输和模型下载占总成本的比例过高。
团队已经有人明确负责 GPU 平台，而不是临时兼任。

迁移顺序建议：先迁稳定、可预测的基础负载；突发流量继续留在 Serverless。一次性把所有任务搬到独占集群，只会把供应商风险换成容量风险。

30 天验证计划

时间	动作	交付物
第 1 周	汇总账单、GPU 小时、流量和 SLO	当前总成本与利用率基线
第 2 周	用同一数据集压测两种环境	TTFT、TPOT、吞吐、错误率、单位请求成本
第 3 周	影子流量或低风险任务试跑	冷启动、故障恢复、运维工作量
第 4 周	代入盈亏平衡公式并做故障演练	Serverless、独占或混合方案决策

决策记录应保留输入数据和假设。三个月后重新计算；GPU 价格、模型大小、量化方案和流量结构都会改变答案。

最终判断

需求不稳定、团队小、产品仍在验证：优先 Serverless。
负载稳定、延迟严格、团队能承担平台责任：评估独占容量。
基础负载稳定但峰值明显：通常采用混合容量。

不要为了降低账面 GPU 单价，提前建立一个没人维护的 GPU 平台；也不要因为 Serverless 省事，长期忽略已经稳定的按量溢价。用等效 GPU 小时和业务 SLO 每季度重算，答案会比品牌偏好可靠得多。