AI Capex 压力下，如何用资源治理保住核心业务？

“At the altar of AI capex, Google is sacrificing the golden goose.” 这句评论在近两年生成式 AI 投资讨论中经常被引用。它的意思是在 AI 资本开支AI Capex的巨大投入面前Google 正拿自己最赚钱的核心业务去冒险那只“下金蛋的鹅”就是搜索、广告等核心业务带来的稳定利润。这句话看起来属于财务和战略层面的讨论但落到技术团队手中它还有另一层非常现实的含义当公司把预算、机房、GPU、电力和研发资源大规模倾斜给 AI 之后核心业务是否仍然拥有足够的容量、优先级和稳定性保障。这篇文章从工程视角回答这个问题。先拆解 AI Capex 的成本构成再沿着“算清账、分好资源、做隔离、控成本、保稳定、能排障”这条主线给出一个既支持 AI 项目扩张、又不让核心业务沦为牺牲品的资源治理方案。内容适合负责云基础设施、成本治理、MLOps 平台的开发者和架构师阅读如果你所在团队正在经历“AI 项目增长很快但核心业务扩缩容越来越难”的阶段这篇会更贴近你的处境。1. AI Capex 的工程代价为什么烧钱不只是财务问题1.1 AI 资本开支的钱主要花在哪里AI Capex 与传统的机房扩容有交集但也有明显差异。传统业务的资本开支更多落在服务器、网络设备、存储和机房改造上AI 项目还要多出几块硬成本。成本项说明与传统业务对比GPU/TPU 计算卡单价高采购周期长是资本开支中占比最大的部分传统业务不需要同等规模的加速卡供电与散热高功率设备密度带来更大的电费与散热改造需求电费可以通过利用率反推容易被低估配套基础设施液冷、机柜、网络带宽、存储扩容需要提前数月规划研发与调度平台训练平台、推理平台、监控、成本系统容易被忽视但决定资源使用效率从这个表格可以看出AI 资本开支不只是“买几张卡”而是一条从采购、机房到调度平台的长链路。技术团队感受到的往往不是一次性采购数字而是后面几个月的容量压力、配额审批和成本账单。1.2 为什么大厂愿意承担如此高的资本开支从行业目前可见的信息看搜索、广告和云业务仍是主要利润来源而大模型相关的搜索增强、AI 编程、企业级推理服务又需要大量 GPU 支持。如果不投入产品能力就会落后如果投入过猛就会拖累短期利润率。这是所有 AI 基础设施投入者都要面对的取舍。对工程师来说真正要解决的是两个问题。第一AI 任务是突发性、可延迟的还是持续、在线、延迟敏感的。第二这些任务会不会侵占在线业务的资源池。问题想清楚“资本开支”就不再只是财务数字而是容量、优先级和稳定性之间的博弈。1.3 技术层面的三种失衡现象当 AI 投入开始挤压核心业务时基础设施团队通常先看到以下现象核心业务 Pod 申请扩容被 ResourceQuota 拒绝因为集群 GPU 命名空间的 request 已经占满大部分配额。GPU 节点故障或维护窗口出现时训练任务反复重启但没人能确定哪个任务优先级更高。月底账单显示 GPU 费用翻倍但按团队、按项目拆分不出来成本责任无法落到具体负责人。这三种现象分别对应容量不足、优先级缺失、成本归属不清。后面几章的内容就是围绕这三类问题展开。2. 先建立可解释的成本模型再谈投入产出2.1 单张计算卡的月成本怎么估算成本模型要解决的问题是一个 AI 任务到底花了多少钱。如果连这个数都说不清就谈不上平衡。先把单卡月成本的固定部分拆开# 单卡月度固定成本估算示例 def monthly_gpu_cost( card_price_usd: float, # 单卡采购成本 server_share_price_usd: float, # 服务器、机箱分摊成本 power_kw: float, # 单卡平均功率单位 kW daily_hours: float 24.0, days_per_month: float 30.0, electricity_price_usd: float 0.10, # 每度电价格 depreciation_months: int 36, # 折旧周期 ): hardware_cost (card_price_usd server_share_price_usd) / depreciation_months power_cost power_kw * daily_hours * days_per_month * electricity_price_usd return hardware_cost power_cost cost monthly_gpu_cost( card_price_usd25000, server_share_price_usd5000, power_kw0.7, ) print(fsingle GPU fixed monthly cost: {cost:.2f} USD)这只是一个简化模型实际账单里还要加上机房租金、运维人力、网络带宽、监控和调度平台成本。它的意义不在于精确到个位数而是让团队有一个可以讨论的“分母”知道一张卡挂在界面上即使什么都不跑也会产生固定支出。2.2 算力利用率是成本模型中真正的分母假设一张卡每月固定成本是 1000 美元任务 A 每天实际跑 4 小时任务 B 每天跑 20 小时两者单次运行成本相差很大。下面这张表说明了利用率对单位算力成本的影响。平均利用率每月有效算力小时单位有效算力小时成本对成本的影响20%144 小时约 6.9 美元费用高但产出少50%360 小时约 2.8 美元需要继续优化80%576 小时约 1.7 美元较为健康这里要注意一个常见误区不要只看“GPU 显存有没有被占用”还要看“计算单元是否真的在跑有效算子”。很多任务把显存占满但计算单元大量空转这种状态同样会造成成本浪费。2.3 训练任务和推理任务的成本结构完全不同训练任务通常是短期的、可排队的、失败后可以重新调度的推理任务则是长期运行的、延迟敏感的、并发会波动的。两者不能共用同一套成本优化策略。维度训练任务在线推理任务运行时间分钟到数天不等7x24 小时延迟要求低允许排队等待高必须响应在线请求成本优化重点控制空闲等待提高批次效率控制冗余副本提升单卡并发典型故障影响多花时间多花重训成本用户请求超时核心业务受损理解了这两类任务的差异容量规划时才能设置不同的优先级和弹性策略。训练任务可以等在线推理不能等。2.4 用成本标签和 Showback 让花销可归属成本模型不等于成本分摊。如果账单上的 GPU 费用无法对应到团队和项目责任人就不会重视优化。常见做法是给云资源和 Kubernetes 工作负载强制打标签然后按月出成本报告。# 以标注示例说明成本标签的用途实际字段取决于平台 kubectl label namespace ml-platform teamml cost-centerai-infra ownermodel-platform kubectl label namespace online-biz teamcommerce cost-centercore-biz ownercommerceShowback成本回显和 Chargeback成本结转的区别在于Showback 只向业务方展示费用Chargeback 会把费用真正计入预算。大多数团队建议先做 Showback避免为了分摊成本而消耗过多管理成本。3. 容量规划与预算分配确保 AI 投资不挤压核心业务3.1 从“按需扩容”变成“按预算申请”传统在线业务扩容往往看重性能和可用性GPU 资源则更依赖预算和配额。核心变化是先有预算再有容量先有优先级再决定谁能抢占。可以把容量池拆成三个层次在线核心池只能给核心业务和有 SLO 要求的 AI 推理服务使用。弹性训练池接收可延迟、可排队的训练任务支持缩容和抢占。备用池用于应对突发流量、新模型灰度上线和故障切换。3.2 用节点池表达不同类型容量以云厂商托管 Kubernetes 为例可以把 GPU 节点和 CPU 节点分开再进一步把 GPU 节点按业务类型分成独立节点池。# 节点池划分思路字段以实际平台为准 apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gpu-training handler: nvidia --- apiVersion: v1 kind: NodeSelectorTerm metadata: name: node-pool-term spec: matchExpressions: - key: workload operator: In values: - ai-training - ai-inference实际在云厂商创建节点时通常会使用命令行或控制台创建带标签的多套节点池。以 Google Cloud GKE 为例可以这样创建带上workloadai-inference标签的节点池具体实例型号和参数以云厂商当前控制台为准。# 创建 AI 推理节点池节点带 workloadai-inference 标签 gcloud container node-pools create ai-inference \ --machine-typeg2-standard-24 \ --acceleratortypenvidia-l4,count1,install-gpu-driver \ --node-labelsworkloadai-inference \ --num-nodes1这里的关键不是记住命令而是理解节点池隔离的目的训练任务哪怕写错了调度配置也不能直接抢占在线推理节点的资源。3.3 用 PriorityClass 定义任务优先级同一个集群里在线推理任务和离线训练任务同时抢 GPU 时调度器必须知道谁更重要。Kubernetes 的 PriorityClass 可以做这件事。apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: online-critical value: 1000000 globalDefault: false description: 在线核心业务与 AI 在线推理服务使用 --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: ml-training value: 500000 globalDefault: false description: 可排队、可抢占的 AI 训练任务PriorityClass 的值只代表相对高低。在线核心业务的优先级应该明显高于训练任务这样当节点资源不足时调度器会优先保证高优先级 Pod 的调度必要时驱逐低优先级 Pod。注意PriorityClass 可以让高优先级 Pod 抢占低优先级 Pod但它不是万能的。如果训练任务和在线任务共用同一个节点池驱逐依然会造成节点抖动所以优先级策略必须和节点隔离一起使用。3.4 容量规划的关键指标指标作用预警值建议GPU 资源分配率表示集群是否还有可分配容量超过 80% 需要关注GPU 实际利用率表示算力是否真正被使用长期低于 40% 需要治理训练任务排队时间表示弹性容量是否不足超过业务预期即告警在线服务 P99 延迟表示资源争抢是否影响核心业务超阈值即时告警空闲节点占比表示是否有成本浪费持续超过 20% 需要回收这些指标要按环境和业务区分阈值。学习环境可以允许空闲生产环境必须设置更严格的容量审视节奏。4. 与核心业务共享集群时的隔离与配额设计4.1 用 ResourceQuota 限制命名空间的资源边界如果一个集群要同时承载 AI 和核心业务第一步是给命名空间配额确保任意一方都不能无限占用节点资源。apiVersion: v1 kind: ResourceQuota metadata: name: quota-ai-training namespace: ml-training spec: hard: requests.nvidia.com/gpu: 8 requests.cpu: 64 requests.memory: 256Gi limits.cpu: 128 limits.memory: 512Gi配额的作用是让业务方明确自己的资源上限。上限设置得过大保护作用会失效设置得过小又会影响业务扩张。建议先参照过去 30 天的实际用量和增长趋势来定。4.2 用 LimitRange 管理单容器资源规格ResourceQuota 控制命名空间总量LimitRange 控制单个 Pod 或容器的规格上限。两者配合才能防止某个异常任务把整个命名空间的额度吃光。apiVersion: v1 kind: LimitRange metadata: name: limit-range-ml-training namespace: ml-training spec: limits: - type: Container defaultRequest: cpu: 1 memory: 2Gi default: cpu: 4 memory: 8Gi max: cpu: 8 memory: 32Gi maxLimitRequestRatio: cpu: 2maxLimitRequestRatio是一个容易忽略的字段它限定了单容器 limit 与 request 的比值避免用户把 request 写得很小、limit 写得很大导致资源超卖。4.3 用节点污点实现物理级隔离任何资源管理策略都可能被误配置绕过。对于在线核心业务建议再加一层节点污点隔离只允许打了对应容忍度的 Pod 调度到专用节点。# 给在线核心节点打污点 apiVersion: v1 kind: Node metadata: name: node-a-online spec: taints: - key: workload value: online effect: NoSchedule# 在线业务 Pod 添加 toleration apiVersion: v1 kind: Pod metadata: name: online-pod spec: tolerations: - key: workload value: online operator: Equal effect: NoSchedule没有对应 toleration 的训练任务即使提交到集群也无法调度到这些节点上。这就是物理级隔离的意思。4.4 GPU 共享模式选型GPU 资源不总是需要整卡独占。根据目前常见的 GPU 和云厂商能力可以按场景选择不同的使用模式。模式特点适用场景整卡独占最简单性能稳定训练任务、高可用推理MIG 切分把 GPU 显存和计算单元按比例切分多个小规模推理服务共享时间片共享共享显存但交替使用计算单元实验环境、开发测试虚拟化透传隔离性更好但配置复杂多租户隔离要求高的场景选择共享模式时要关注延迟波动。时间片共享适合对 P99 延迟不敏感的任务不适合在线核心业务。4.5 推荐的多级容量池结构一个比较稳妥的结构是在线核心业务独占一组节点池AI 推理服务使用带独立 PriorityClass 的节点池AI 训练任务使用可被抢占的弹性节点池并通过 ResourceQuota 和 LimitRange 控制每个命名空间。这样即使训练任务投入巨大也不会因为调度问题把在线业务拉入故障。核心目标不是禁止 AI 使用资源而是让每一类资源都有明确边界和逃生路径。5. 用工程手段削减 AI 推理与训练成本5.1 推理侧模型小一点成本低一截推理成本的最大驱动因素是 GPU 占用和在线副本数。不要一上来就按最大模型、最大并发设计优先做模型轻量化。优化手段适用场景注意事项模型蒸馏允许精度小幅下降的任务需要准备训练数据和评估集量化INT8/FP16对数值精度不过度敏感的任务需要验证输出质量批量推理batching离线批量、非实时场景在线场景要控制排队时间结果缓存重复请求比例高的任务设计好缓存键和过期策略模型裁剪结构冗余明显的模型需要重新评估效果一个常见的错误是只做量化不留评估集。量化后模型上线线上效果下降却排查不出来是模型问题还是数据问题。任何模型压缩手段都应该配套一批固定的回归样本。5.2 训练侧让任务排队而不是立即抢占训练任务通常允许延迟。把训练任务放进队列由调度平台统一控制启动时间可以有效削峰。apiVersion: scheduling.incubator.kubernetes.io/v1alpha1 kind: Queue metadata: name: ml-training-queue spec: capacity: 4上面的 Queue 资源只是一个示意不同训练平台字段差异很大。重点是设计“排队-启动-中断恢复”