随着 AI 应用持续扩大，支撑训练、推理、数据处理和模型服务的基础设施也在快速增长。真正的挑战不只是增加服务器数量，而是让计算、存储、网络和运维资源在需求变化时保持高利用率，同时控制成本、能耗与交付复杂度。
这意味着基础设施建设需要从“堆更多容量”转向“根据需求精确配置容量”。
从容量扩张转向资源效率
AI 工作负载通常具有明显差异：模型训练可能持续数小时甚至数天，推理服务则更关注延迟、并发和稳定性，数据预处理又可能在特定时间集中消耗 CPU、内存和存储带宽。如果所有任务都使用同一种机器规格，往往会出现两类问题：
- 训练任务占用昂贵的加速资源，但实际利用率不高。
- 推理服务为了应对峰值预留大量容量，平时却处于空闲状态。
可以从几个维度改善效率：
- 按工作负载选择资源：区分训练、批处理、在线推理和数据服务，分别设计资源池。
- 提高利用率：通过任务排队、资源共享、自动扩缩容和合理的并发控制，减少空闲资源。
- 缩短交付周期：把基础设施配置标准化，使用可重复的配置文件和自动化流程。
- 建立成本与性能指标：同时观察 GPU/CPU 利用率、每次推理成本、任务等待时间、延迟和错误率。
容量不是越大越好。没有利用率和业务指标作为约束，扩容只会把低效率放大。
用弹性策略应对 AI 需求波动
AI 需求增长并不等于每个时刻的需求都相同。在线请求可能在一天中的某些时间集中出现，训练任务可能按周或按项目启动，批量生成任务则可以延迟到资源更充足的时间执行。
因此，基础设施可以采用分层策略：
- 稳定容量：承载长期运行、延迟敏感的核心服务。
- 弹性容量：在请求或任务增加时临时扩展。
- 可延迟容量：运行不要求即时完成的训练、评测和批处理任务。
下面是一个可改造的 Kubernetes 示例。假设推理服务部署在 Kubernetes 中，并且应用能够暴露 Prometheus 指标 http_requests_per_second。实际使用时，需要根据集群的指标适配器、容器启动时间和模型加载时间调整阈值。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: model-inference
namespace: ai
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: model-inference
minReplicas: 2
maxReplicas: 20
behavior:
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Percent
value: 100
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 25
periodSeconds: 60
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 65
这段配置只展示基于 CPU 的弹性伸缩。对于 GPU 推理服务，更有价值的指标可能是 GPU 利用率、请求队列长度、每个实例的并发数或 P95 延迟。配置自动扩缩容前，应确认指标采集稳定，并为缩容设置足够的稳定窗口，避免模型实例频繁启动和释放。
把效率纳入工程度量
基础设施效率需要被持续观测，而不是在账单增长后才分析。建议至少建立以下指标：
- 资源利用率：计算资源实际使用时间与可用时间的比例。
- 单位任务成本：一次训练、一次批处理或一千次推理的基础设施成本。
- 排队时间：任务从提交到获得资源的等待时间。
- 服务质量：P95/P99 延迟、错误率、吞吐量和可用性。
- 扩缩容开销：实例启动、模型加载和缓存预热所需时间。
- 能耗与容量增长：在数据中心或云环境中，观察功耗和资源增长是否与业务价值匹配。
单独追求高利用率也可能带来风险。例如，把集群长期运行在接近满载的状态，可能降低故障恢复能力，并让突发流量没有缓冲空间。更合理的目标是，在服务质量、成本和容量余量之间找到可接受的平衡。
一份可执行的落地清单
可以按以下顺序开始改造：
- 盘点训练、推理、批处理和数据任务的资源消耗与时间分布。
- 找出长期闲置、峰值预留过高或等待时间过长的资源池。
- 为不同工作负载设置独立的队列、优先级和资源限制。
- 先为非关键服务启用自动扩缩容，再逐步覆盖核心服务。
- 把每次扩容与单位任务成本、延迟和错误率关联起来。
- 为模型加载慢、指标缺失、扩容失败和云资源配额不足准备降级方案。
AI 基础设施的效率提升不是一次性的设备采购决策，而是持续的工程管理过程。随着需求增长，组织需要同时优化资源选择、调度方式、服务弹性和观测体系。只有把容量、成本与业务结果放在同一张表里，扩张才会真正转化为可持续的服务能力。