扩容GPU池之前，先衡量产出结果
内容提要
文章指出，GPU池满载和队列增长并不必然意味着需要扩容，应先区分GPU处于“已分配”“忙碌”还是“产生有价值结果”的状态。团队需明确各工作负载的截止时间、运行时长、资源需求和可中断性，并定义有价值输出的标准。通过错峰调度可降低峰值需求，无需扩容即可按时完成任务。高GPU活动率并不代表有额外吞吐量，应通过代表性负载测试测量可持续容量。结合OpenCost等工作负载成本数据与服务遥测、结果记录，可计算“每个合格结果的成本”，在质量、延迟和成本之间权衡，选择延迟任务、优化批处理、调整部署、更换模型或扩容。最终目标是以可辩护的成本交付所需结果，并保留足够余量。
延伸解读
区分“忙碌”与“产出”：先定义成功标准
文章强调，GPU已分配、忙碌与产生有价值结果并非同一回事。团队需为每个工作负载明确截止时间、运行时长、资源需求和可中断性，并定义何为有价值输出。例如推理服务应有任务特定的质量阈值和延迟目标，仅完成请求或返回有效JSON并不代表达标。只有先厘清这些标准，才能判断队列增长是容量不足还是调度或配置问题。
错峰调度：不扩容也能按时完成
文章用示例说明，四个各需两GPU、一小时的评估任务，若同时启动需八GPU，但错开一小时启动，仅用现有四GPU即可在下午2点前全部完成，且总GPU小时数不变。这表明开始时间的灵活性可降低峰值需求。借助Kueue等准入控制工具，团队能按配额和政策决定任务何时被接纳，从而减少为清空队列而提前启动、后又抢占的情况。
高活动率不等于高吞吐：需代表性负载测试
文章指出，GPU活动率高并不证明还有额外吞吐量，因为流式多处理器活动可能包含等待内存的线程。vLLM的KV缓存使用率也不直接衡量总服务容量。应保持模型、硬件、服务设置和请求组合不变，逐步提高到达率，观察吞吐、质量和延迟，找到仍满足错误限制和延迟百分位要求的最高持续速率，以此估算可持续容量。
用“每个合格结果的成本”指导决策
文章建议结合OpenCost的工作负载成本数据、服务遥测和结果记录，计算每个合格结果的成本：总可归属成本除以满足质量要求且按时交付的结果数。示例中，强模型每小时成本2美元，产出990个合格结果，约合每千个合格结果2.02美元；若另一配置以1.5美元达成同样结果，成本降至约1.52美元。该指标帮助在质量、延迟和成本间权衡，但需注意结果价值与错误后果的可比性。
Q&A
GPU池满了、队列也在增长，是不是就该马上扩容？
不一定。文章指出，GPU“已分配”“忙碌”和“产生有价值结果”是三种不同状态。队列增长可能源于调度时机、服务容量或模型/硬件选择问题，应先分析工作负载的截止时间、运行时长、资源需求和可中断性，再决定是否扩容。
如何在不增加GPU的情况下减少峰值需求？
可以通过错峰调度来降低峰值需求。例如，四个各需2块GPU、运行1小时的任务，若全部同时启动需8块GPU；但分两批启动（中午两个、下午1点两个），用已有的4块GPU到下午2点就能全部完成，且总GPU小时数不变。
GPU活动率高是否意味着还有额外吞吐量可以挖掘？
不是。高GPU活动率并不代表有额外吞吐量，因为流式多处理器活动可能包含等待内存的线程。要测量可持续容量，需用代表性负载测试：保持模型、硬件、服务设置和请求组合不变，逐步提高到达率，观察吞吐量、质量和延迟，找到仍满足要求（包括错误限制和延迟百分位）的最高持续速率。
如何计算“每个合格结果的成本”？
用总可归属成本除以在要求时间内交付且满足质量要求的结果数量。成本应包括GPU、CPU、内存等基础设施成本，并记录共享和空闲成本的分配方式；结果需按定义的质量标准验证，考虑重试、失败、启动和空闲时间，最终业务结果只计一次。可结合OpenCost的分配API获取工作负载成本，再与服务遥测和结果记录关联。
在质量、延迟和成本之间如何权衡选择模型或部署？
先确保模型满足最低质量要求（如98%正确率），再比较不同配置下每个合格结果的成本。例如，强模型每小时2美元产出990个合格结果，成本约2.02美元/千个；若换小GPU或调整批处理能以1.5美元产出同样结果，成本降至约1.52美元/千个。每次只改变一个主要变量，在代表性需求下比较成本、合格结果、延迟和截止时间达成情况。
扩容前团队需要明确哪些工作负载信息？
需要为每个工作负载记录：截止时间、预期运行时长、资源需求、是否可中断。同时要定义什么算有价值的输出：推理服务应有任务特定的质量阈值和延迟目标；仅完成请求或返回有效JSON并不代表达成目标。还需将开始时间的灵活性与中断容忍度分开考虑。
