GPU全占满、队列还在涨，为什么先别急着扩容？

周三下午，一个团队盯着监控面板：GPU 池全部占满，批处理队列还在往上爬。第一反应几乎都是加卡。但队列变长这件事，可能指向的是时间安排、服务容量，或者模型与硬件的选择，而不是算力不够。

在 Kubernetes 上跑 AI 负载的团队，容易把"GPU 已分配""GPU 很忙""负载产出了有价值的结果"当成同一件事。这三者并不等价。先把它们的关系理清，往往能在真正需要扩容之前，把现有容量用得更充分。

先定义结果和截止时间

看负载，也看它支撑的具体用例。客服机器人可能需要全天候的推理容量，而一次模型评估任务的结果，也许只要赶在下一次内部发布同步之前出来。把负载粗分成"推理"和"训练"两类，并不能决定紧迫性：有些批推理可以等，有些训练任务却卡着硬期限。

对每个负载，记录它的截止时间、预期运行时长、资源需求，以及是否允许被中断。同时要定义什么算有价值的输出。推理服务应当有任务相关的质量阈值和延迟目标。一个请求跑完、或者返回了一段合法 JSON，本身并不能说明这个负载达成了目标。

还要把"启动时间可灵活"和"可容忍中断"分开看。一个可以晚点开始的任务，开始之后可能仍然需要不被打断地跑完。

先用调度弹性，再谈扩池

设想中午到下午五点之间，有四块兼容的 GPU 可用于批处理。中午时四个独立的评估任务就绪，每个需要两块 GPU 跑一小时，所有结果五点前要交。

四个任务同时开跑，需要八块 GPU。但中午先跑两个、一点再跑两个，用现有的四块 GPU，两点就能全部跑完。在运行时长和配套资源不变的前提下，两种排法消耗的都是八个 GPU 小时，启动开销另算。

错峰降低了峰值需求，任务照样按时完成，池子不用扩。在为了清空队列而加卡之前，先看看启动时间上还有多少弹性空间。Kueue 这类工具提供了准入控制点，按配置好的配额和策略决定工作何时被接纳；至于如何表达和强制执行截止时间与负载要求，仍然要团队自己定。灵活的排队既能支撑容量规划，也能减少"早早启动、随后又被抢占"的浪费。

测出这套部署能稳定产出多少有用功

灵活调度能缓解容量紧张，但推理团队还得看模型和服务配置跟这份工作匹配得如何。

GPU 活动率高，并不能说明还有多少额外吞吐可用。英伟达的性能分析文档指出，流式多处理器活动可能包含正在等待内存的 warp。运行中请求数、等待中请求数、缓存占用这类服务指标能补充上下文，抢占计数则有助于解释行为。在 vLLM 中，KV 缓存使用率衡量的是已占用缓存块的比例，并不直接衡量总服务容量。

要测可持续容量，得用有代表性的负载测试：模型、硬件、服务设置、请求组合保持不变，逐步提高到达率，观察吞吐、质量和延迟。在满足负载要求（包括错误上限和选定的延迟分位数）的前提下，能持续维持的最高速率，才是有用的容量估计。对交互式生成，要算上首 token 时间和后续 token 的交付速度，不能只看平均完成时间。DistServe 的工作说明了为什么应当对照应用层目标来评估服务容量。

再把生产流量和测出的容量做对比。缓存占用低值得进一步排查，但要说吞吐能翻十倍，得先有吞吐测试。短暂的队列可能只是临时突发，持续存在的队列才可能需要诊断。单看哪一项，都定位不了瓶颈资源。

把成本数据和验证过的结果接起来

FinOps 社区把 AI 效率落在成本和有用结果上。对 AI 负载来说，成本只有和基础设施帮助交付的结果挂钩，才更有意义。Kubernetes 团队可以把负载成本、服务行为和业务结果三者拼到一起。

用 OpenCost 的分配 API 按固定间隔取负载成本，再通过负载标识和时间戳，把这份数据与服务遥测、结果记录关联起来。OpenCost 还提供可选的推理成本追踪，包括每百万 token 成本。计算单结果成本时，要把适用的 GPU、CPU、内存及其他基础设施成本算进去，并记录共享成本和空闲成本是如何分摊的。OpenCost 之外的相关成本单独加上，别重复计算。

一个有用的指标是"每个已验证结果的成本"：可归属总成本，除以满足既定质量要求、且在要求时间内交付的结果数量。重试、失败、启动和空闲时段，只要计入总成本，就要一并考虑。最终业务结果只计一次。如果正确率是靠抽样评审估计的，要写明抽样方法和不确定性。

OpenCost 提供成本分摊的细节，应用侧提供结果定义和评估证据，容量则仍需单独测量。OpenCost 提案 3915 在探索把服务引擎遥测纳入成本模型，该提案目前仍是草案，不是已发布的饱和度或正确性评分。

测一测闲置容量值不值这个钱

举个示例：某服务每小时收到 1000 个任务，正确率要求 98%。一个只能做到 90% 的小模型不合格，哪怕它的 GPU 便宜且占满。

换成更强的模型，每小时花 2 美元，产出 990 个正确且及时的结果，而它只用了实测服务容量的一小部分。折算下来，每 1000 个合格结果约 2.02 美元，这部分闲置容量可以视为满足质量要求、吸收突发活动的合理代价。

下一个测试是：更小的 GPU、更少的副本，或者不同的批处理设置，能不能保住这些结果和所需可靠性。如果某个经过测试的配置用 1.50 美元产出同样的 990 个合格结果，成本就降到每 1000 个合格结果约 1.52 美元。省下来的钱来自用更少资源交付同样结果。在原 GPU 上提高利用率却不改善结果，带不来可比的价值。

当两个模型都满足最低要求时，额外的质量提升如果意味着更少严重后果的错误、或更少人工复核，可能值得更高的成本。把这个价值和实际需求比一比。只有在被比较的结果价值相近、错误后果相近时，单正确结果成本才最有用。

一次只改一个主要变量，然后在有代表性的需求下比较成本、已验证结果、延迟和截止时间达成情况。为突发和故障留出容量，并确认低活动确实对应可用容量——独占给某个 Pod 的 GPU，在释放之前没法分给别的 Pod。

做完这些，团队可以按证据支持的选项来选：推迟弹性任务、改进批处理、调整部署规模、换模型，或者真的加 GPU。目标是一套以站得住脚的成本交付所需结果、同时留足余量的部署。