Kubernetes 跑 AI 推理，但算不清真实成本

能跑起来，不等于能算明白

Kubernetes 已经成为 AI 推理部署的事实标准：GPU 调度、弹性伸缩、多模型混部，这些能力让推理服务上线变得前所未有的简单。但一个被严重低估的问题随之浮现——Kubernetes 能调度推理任务，却很难准确核算这些任务究竟花了多少钱。

这不是一个抽象的财务问题。当团队每月收到一笔包含 GPU 实例、网络带宽、存储 I/O、镜像拉取、负载均衡在内的混合账单时，很难把每一分钱对应到具体的模型、请求或用户身上。成本分摊的模糊性，直接导致优化无从下手。

成本黑洞藏在哪里

AI 推理场景下的成本失真，通常来自以下几个层面：

GPU 利用率与计费方式的错配

GPU 实例按整卡计费，但推理请求是间歇性的。一个模型可能只在 10% 的时间里真正占用 GPU 算力，其余时间处于空转或排队状态。Kubernetes 的调度器看到的是「GPU 已分配」，账单上体现的是「GPU 已购买」，两者之间的差额就是隐性浪费。

弹性伸缩的滞后成本

HPA（Horizontal Pod Autoscaler）根据 CPU 或自定义指标扩缩容，但 GPU 推理的响应延迟远高于传统 Web 服务。扩容时多出来的 Pod 需要预热模型（加载权重到显存），这段时间内资源已占用但尚未产生有效推理。缩容时同理，延迟释放意味着多付了「空跑」费用。

多模型混部的资源争抢

当多个模型共享同一批 GPU 节点时，显存碎片化、上下文切换开销、批处理队列竞争都会降低整体吞吐。Kubernetes 的资源请求（requests）和限制（limits）机制无法精确描述 GPU 显存的动态分配行为，导致实际利用率与预期严重偏离。

怎么把成本算清楚

第一步：建立细粒度成本标签

在 Deployment 和 Service 层面注入统一的成本标签，例如 cost-center、model-name、request-type。所有推理请求通过 API Gateway 或 Sidecar 代理时，将标签透传到日志和指标中。这是后续所有成本分析的基础。

第二步：采集 GPU 级别的利用率指标

仅靠 Kubernetes 原生的 container_memory_working_set_bytes 远不够。需要部署 DCGM（Data Center GPU Manager）或类似的 GPU 监控代理，采集以下关键指标：

• GPU 利用率（DCGM_FI_DEV_GPU_UTIL）：显存和计算单元的实际占用率
• 显存使用量（DCGM_FI_DEV_FB_USED）：已分配显存的绝对值
• 能耗（DCGM_FI_DEV_POWER_USAGE）：GPU 的实际功耗，直接关联电费
• 批处理大小与吞吐：每批次处理的 token 数和推理延迟

第三步：关联请求量与资源消耗

将推理请求日志（含模型名称、token 数、延迟、响应时间）与 GPU 指标按时间窗口关联。核心公式：

单次推理成本 =（GPU 实例小时成本 × 该请求占用的 GPU 时间占比）÷ 请求量

这一步通常需要借助 Prometheus + Grafana 做可视化，或用自建的成本分摊服务在日志管道中实时计算。

第四步：识别闲置与低效模式

通过上述数据，可以精确定位以下浪费场景：

浪费类型	识别信号	优化方向
模型空载	GPU 利用率 < 5% 持续超过 1 小时	设置自动缩容到 0 副本
过度预留	requests 远大于实际使用量	调整资源请求值，启用 bin-packing
冷启动浪费	扩容后 30 秒内无有效请求	优化模型加载流程，使用预热池
批处理不足	单请求占用 GPU 时间过长	增大 batch size，提升吞吐

对谁有价值

• 平台工程团队：需要为多业务线分摊 GPU 成本，建立内部计费模型
• AI 应用开发者：需要知道每个模型的推理成本，做出性能与成本的权衡
• 技术管理者：需要在预算约束下最大化推理吞吐量，避免资源浪费

小结

Kubernetes 解决了 AI 推理的「部署」问题，但「成本核算」仍然需要团队自己补齐。关键在于：从 GPU 利用率指标入手，建立请求级别的成本追踪，把模糊的账单拆成可优化的数据点。没有这一步，再精细的调度策略也只是在黑暗中优化。