基于机器学习的容量预测：AI应用架构师的智能规划新方法

摘要/引言：为什么你的容量规划总“踩坑”？

凌晨3点，你被手机铃声惊醒——运维团队告诉你，核心交易系统的CPU使用率飙升到95%，订单超时率超过20%。你揉着眼睛打开监控面板，发现QPS比昨天同期高了3倍——原来是某网红主播推荐了你们的产品，导致流量突增。而你上周刚做的容量规划，只预留了2倍的冗余。

这样的场景，是不是每个AI应用架构师都经历过？

容量规划是架构师的核心工作之一：既要保证系统在峰值负载下稳定运行，又要避免过度扩容导致资源浪费。但传统的容量规划方法，比如基于阈值的静态规则、线性增长预测、经验驱动的拍脑袋，早已无法应对现代业务的复杂性——用户行为的不确定性、促销活动的突发性、多业务线的交叉影响，都让“准确预测”变成了一件难事。

有没有一种方法，能让容量规划从“经验驱动”转向“数据驱动”，用更智能的方式应对复杂场景？答案是基于机器学习（ML）的容量预测。

本文将为你拆解ML在容量预测中的核心逻辑，提供可落地的实战步骤，并用真实案例展示如何用ML解决大促期间的容量规划问题。读完本文，你将学会：

识别传统容量规划的3大痛点；用ML做容量预测的6步实战流程；提升预测准确性的5大最佳实践；如何将ML模型部署到生产环境，形成持续优化的闭环。

一、传统容量规划的3大痛点：为什么你总“算不准”？

在讲ML之前，我们需要先明确：传统方法到底哪里不行？

1. 静态阈值：频繁扩容/缩容的“资源浪费机”

传统容量规划最常用的方法是设置静态阈值——比如CPU使用率超过80%就扩容，低于50%就缩容。但这种方法的问题在于：

无法应对周期性波动：比如电商平台每天早8点和晚8点是高峰，静态阈值会导致早高峰扩容、晚高峰再扩容，平峰期缩容，频繁的扩缩容会增加系统开销（比如容器启动时间），还会浪费资源（比如刚扩容的服务器在平峰期闲置）。无法识别异常波动：比如某次测试导致CPU使用率飙升到90%，静态阈值会触发扩容，但测试结束后又要缩容，这种“误判”会浪费大量资源。

2. 线性预测：面对非线性增长的“盲人摸象”

很多架构师会用线性回归预测资源需求——比如过去3个月的用户增长率是10%，就预测未来3个月的资源需求增长10%。但现实中，用户增长往往是非线性的：

比如社交应用的病毒式传播，用户增长会呈指数级上升；比如电商平台的新功能上线，用户增长会先快速上升，然后趋于平稳。
线性预测会严重低估这种非线性增长，导致容量不足。

3. 忽视多变量：只看“技术指标”，不看“业务逻辑”

传统方法往往只关注技术指标（比如CPU、内存使用率），而忽略了业务指标（比如QPS、订单量）和外部因素（比如节假日、促销活动）。比如：

电商平台的双11大促，QPS是平时的5倍，但传统方法如果只看过去的CPU使用率，会完全忽略促销这个关键因素；视频流应用的周末流量，比平时高30%，但传统方法如果只看周中数据，会低估周末的资源需求。

这些痛点的核心问题是：传统方法无法处理“复杂的、非线性的、多变量的”业务场景。而ML，正是解决这个问题的利器。

二、ML容量预测的核心逻辑：从“经验规则”到“数据规律”

1. 什么是ML容量预测？

ML容量预测的本质是：用历史数据训练模型，学习“业务指标-资源需求”之间的规律，然后用模型预测未来的资源需求。

比如，对于电商平台，我们要预测“双11当天的CPU使用率”，需要：

输入：过去3年的双11数据（QPS、订单量、促销活动）、平时的资源数据；模型：学习“QPS越高→CPU使用率越高”“促销活动→QPS翻倍”的规律；输出：双11当天的CPU使用率预测值。

2. ML为什么能解决传统方法的痛点？

对比传统方法，ML的优势在于：

非线性拟合：ML模型（比如XGBoost、LSTM）能捕捉非线性关系，比如“QPS增长到10万时，CPU使用率的增长速度会加快”；多变量处理：ML模型能同时处理多个特征（比如QPS、订单量、促销活动），分析它们之间的交互作用（比如“促销活动+周末”会导致QPS翻倍）；自动学习：ML模型能从历史数据中自动学习模式（比如“周末的QPS比平时高20%”），不需要人工制定规则；动态适应：ML模型能定期用新数据重新训练，适应业务的变化（比如用户行为的改变、新功能的上线）。

3. ML容量预测的核心步骤

ML容量预测的流程可以概括为6步：

问题定义：明确预测目标、时间粒度、范围；数据收集：收集历史资源数据、业务数据、外部数据；数据预处理：处理缺失值、异常值、拆分数据集；特征工程：提取时间特征、滞后特征、滚动特征、业务特征；模型选择与训练：选择适合的模型，训练并评估；部署与监控：将模型部署到生产环境，持续监控优化。

接下来，我们将逐一拆解每个步骤的实战细节。

三、ML容量预测实战：6步搞定智能规划

先决条件

在开始之前，你需要准备：

知识基础：了解ML的基本概念（比如回归问题、特征工程），熟悉时间序列预测；工具准备：Python（Pandas、Scikit-learn、XGBoost、Prophet）、监控系统（Prometheus、Grafana）、数据库（MySQL、Elasticsearch）；数据准备：过去6个月以上的历史资源数据（CPU、内存、带宽、QPS）、业务数据（订单量、用户数、促销活动）、外部数据（节假日、天气）。

步骤1：问题定义——明确“预测什么”

首先，你需要明确3个问题：

预测目标：你要预测的资源指标是什么？比如CPU使用率、内存使用率、QPS、带宽；时间粒度：预测的时间间隔是多少？比如每小时、每天、每周；预测范围：预测的时间范围是多少？比如短期（0-1小时）、中期（1-7天）、长期（1-3个月）。

示例：某电商平台要预测“双11当天每小时的CPU使用率”，则：

预测目标：CPU使用率（%）；时间粒度：每小时；预测范围：短期（双11当天24小时）。

步骤2：数据收集——找到“预测的原材料”

数据是ML模型的“原材料”，没有高质量的数据，再先进的模型也没用。你需要收集3类数据：

（1）资源数据（Technical Data）

来源：监控系统（Prometheus、Zabbix）、云服务商控制台（AWS CloudWatch、阿里云监控）；内容：CPU使用率、内存使用率、磁盘IO、带宽、QPS、并发连接数。

（2）业务数据（Business Data）

来源：业务数据库（MySQL、PostgreSQL）、日志系统（ELK、Splunk）；内容：订单量、用户数、转化率、新功能上线时间、促销活动（时间、类型、力度）。

（3）外部数据（External Data）

来源：公开API（比如节假日API、天气API）、行业报告；内容：节假日（是否是周末、法定假日）、天气（温度、降雨量）、行业事件（比如竞品促销）。

示例：某电商平台收集的数据清单：

数据类型	内容	来源
资源数据	每小时CPU使用率、QPS、带宽	Prometheus
业务数据	每小时订单量、用户数、促销类型	MySQL
外部数据	节假日、天气温度	百度API

步骤3：数据预处理——把“ raw data ”变成“ clean data ”

收集到的数据往往是“脏的”——有缺失值、异常值、格式不一致。你需要做3件事：

（1）处理缺失值

缺失值的处理方法取决于数据的类型：

时间序列数据：用前向填充（ffill）或插值（interpolate）填充（比如前一小时的CPU使用率填充当前小时的缺失值）；分类数据：用众数填充（比如促销类型的缺失值用“无促销”填充）。

代码示例：


import pandas as pd

# 加载数据
data = pd.read_csv('resource_data.csv', parse_dates=['timestamp'])

# 前向填充缺失值
data = data.ffill()

# 插值填充（更平滑）
data['cpu_usage'] = data['cpu_usage'].interpolate(method='linear')

（2）处理异常值

异常值会干扰模型的训练，需要识别并删除：

3σ原则：如果数据点超过平均值±3倍标准差，则视为异常值；箱线图法：如果数据点超过上下四分位数±1.5倍四分位距，则视为异常值。

代码示例：


import numpy as np

# 3σ原则处理CPU使用率异常值
mean = data['cpu_usage'].mean()
std = data['cpu_usage'].std()
data = data[(data['cpu_usage'] >= mean - 3*std) & (data['cpu_usage'] <= mean + 3*std)]

（3）拆分数据集

时间序列数据不能像普通数据那样随机拆分（会破坏时间顺序），需要按时间顺序拆分：

训练集：过去大部分数据（比如2020-2022年9月）；验证集：最近的一部分数据（比如2022年10月），用于调整模型参数；测试集：未来的一部分数据（比如2022年双11），用于评估模型性能。

代码示例：


# 按时间排序
data = data.sort_values('timestamp')

# 拆分时间点
train_end = '2022-09-30'
val_end = '2022-10-31'

# 拆分数据集
train_data = data[data['timestamp'] <= train_end]
val_data = data[(data['timestamp'] > train_end) & (data['timestamp'] <= val_end)]
test_data = data[data['timestamp'] > val_end]

步骤4：特征工程——从“数据”中提取“价值”

特征工程是ML容量预测的核心环节——好的特征能让模型性能提升数倍，而差的特征会让模型“学错”规律。

你需要提取4类特征：

（1）时间特征（Temporal Features）

时间是容量预测中最重要的特征之一，比如：

小时（hour）：早高峰和晚高峰的CPU使用率不同；星期几（day_of_week）：周末的用户量比平时高；月份（month）：电商平台的11月（双11）流量比其他月份高；节假日（is_holiday）：国庆期间的流量比平时高。

代码示例：


# 提取时间特征
data['hour'] = data['timestamp'].dt.hour
data['day_of_week'] = data['timestamp'].dt.dayofweek  # 0=周一，6=周日
data['month'] = data['timestamp'].dt.month
data['is_holiday'] = data['timestamp'].dt.holiday  # 假设已通过API获取节假日标记

（2）滞后特征（Lag Features）

滞后特征是“过去某一时刻的特征值”，比如：

前24小时的CPU使用率（cpu_usage_lag_24）；前48小时的QPS（qps_lag_48）。
滞后特征能帮助模型学习时间序列的趋势和周期性。

代码示例：


# 提取滞后24小时的CPU使用率
data['cpu_usage_lag_24'] = data['cpu_usage'].shift(24)

# 提取滞后48小时的QPS
data['qps_lag_48'] = data['qps'].shift(48)

（3）滚动统计特征（Rolling Features）

滚动统计特征是“过去一段时间内的统计值”，比如：

过去7天的平均QPS（qps_rolling_mean_7d）；过去3天的最大订单量（order_rolling_max_3d）。
滚动特征能帮助模型学习时间序列的平滑趋势。

代码示例：


# 提取过去7天（168小时）的平均QPS
data['qps_rolling_mean_7d'] = data['qps'].rolling(window=168).mean()

# 提取过去3天（72小时）的最大订单量
data['order_rolling_max_3d'] = data['order_count'].rolling(window=72).max()

（4）业务特征（Business Features）

业务特征是与业务场景相关的特征，比如：

促销活动（is_promotion）：1表示有促销，0表示无；促销类型（promotion_type）：预售、满减、打折；新功能上线（new_feature_launch）：1表示有新功能上线，0表示无。
业务特征能帮助模型学习业务驱动的资源变化。

代码示例：


# 促销活动特征（1=有促销，0=无）
data['is_promotion'] = data['promotion_name'].notnull().astype(int)

# 促销类型特征（one-hot编码）
data = pd.get_dummies(data, columns=['promotion_type'], prefix='promotion')

步骤5：模型选择与训练——找到“最适合的模型”

时间序列预测的模型有很多，你需要根据预测目标和数据特征选择适合的模型。

（1）常用模型对比

模型	优点	缺点	适用场景
Prophet	Facebook开源，容易上手；支持季节性、节假日；解释性好	对复杂非线性拟合不好；无法处理多特征交互	有明显季节性、节假日的场景（比如电商双11）
XGBoost	处理多特征；捕捉特征交互；解释性好；训练快	对长序列的时间依赖处理不好	多变量影响的场景（比如结合业务指标）
LSTM	处理长序列；捕捉时间依赖；拟合非线性	需要大量数据；计算资源多；解释性差	复杂非线性场景（比如用户行为波动）
ARIMA	传统时间序列；解释性好	无法处理非线性、多变量	简单线性场景（比如稳定的用户增长）

（2）模型训练流程

以XGBoost为例，训练流程如下：

① 准备特征和标签

特征（X）：时间特征、滞后特征、滚动特征、业务特征；标签（y）：要预测的资源指标（比如CPU使用率）。

代码示例：


# 特征列（排除timestamp和标签列）
feature_cols = [col for col in data.columns if col not in ['timestamp', 'cpu_usage']]

# 准备训练集、验证集、测试集的特征和标签
X_train = train_data[feature_cols]
y_train = train_data['cpu_usage']

X_val = val_data[feature_cols]
y_val = val_data['cpu_usage']

X_test = test_data[feature_cols]
y_test = test_data['cpu_usage']

② 训练模型

用XGBoost的XGBRegressor训练模型，并调整参数（比如max_depth、learning_rate）。

代码示例：


from xgboost import XGBRegressor
from sklearn.metrics import mean_absolute_percentage_error as MAPE

# 初始化模型
model = XGBRegressor(
    max_depth=6,  # 树的最大深度，防止过拟合
    learning_rate=0.1,  # 学习率
    n_estimators=100,  # 树的数量
    objective='reg:squarederror'  # 回归任务的损失函数
)

# 训练模型
model.fit(
    X_train, y_train,
    eval_set=[(X_val, y_val)],  # 验证集
    early_stopping_rounds=10,  # 早停，防止过拟合
    verbose=1  # 打印训练过程
)

③ 评估模型

用**MAPE（平均绝对百分比误差）**评估模型性能——MAPE越小，预测越准确。一般来说，MAPE<10%是优秀，10%-20%是良好，20%以上需要优化。

代码示例：


# 预测验证集
y_val_pred = model.predict(X_val)

# 计算MAPE
mape_val = MAPE(y_val, y_val_pred)
print(f'验证集MAPE：{mape_val:.2%}')

④ 优化模型

如果MAPE过高，可以尝试以下优化方法：

增加特征：比如加入“促销力度”“用户留存率”等特征；调整参数：比如增大max_depth（捕捉更复杂的特征交互）、减小learning_rate（减慢学习速度，防止过拟合）；尝试其他模型：比如用LSTM处理长序列，或用Prophet处理季节性。

步骤6：部署与监控——从“实验室”到“生产环境”

训练好的模型需要部署到生产环境，才能发挥价值。同时，你需要持续监控模型性能，确保它适应业务的变化。

（1）模型部署

常用的部署方式有3种：

① API部署

用Flask或FastAPI写一个预测API，接收请求参数（比如时间范围、促销活动），返回预测结果。

代码示例（Flask）：


from flask import Flask, request, jsonify
import pandas as pd

app = Flask(__name__)

# 加载训练好的模型
model = pd.read_pickle('xgb_model.pkl')

# 特征列（需与训练时一致）
feature_cols = ['hour', 'day_of_week', 'month', 'is_holiday', 'cpu_usage_lag_24', 'qps_lag_48', 'qps_rolling_mean_7d', 'order_rolling_max_3d', 'is_promotion', 'promotion_预售', 'promotion_满减']

@app.route('/predict', methods=['POST'])
def predict():
    try:
        # 接收请求数据
        data = request.json
        # 转换为DataFrame
        df = pd.DataFrame(data, index=[0])
        # 确保特征列完整
        missing_cols = set(feature_cols) - set(df.columns)
        if missing_cols:
            return jsonify({'error': f'Missing features: {missing_cols}'}), 400
        # 预测
        prediction = model.predict(df[feature_cols])
        # 返回结果
        return jsonify({'cpu_usage_pred': round(float(prediction[0]), 2)})
    except Exception as e:
        return jsonify({'error': str(e)}), 500

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

② 嵌入监控系统

将模型嵌入到Grafana中，实时显示预测的资源需求和实际值的对比。比如，用Grafana的Python插件调用预测API，将结果可视化：

在Grafana中安装“SimpleJSON”数据源；配置数据源指向预测API的地址（比如http://localhost:5000）；创建Dashboard，添加“Time Series”面板，查询预测API的结果，并与实际CPU使用率对比。

③ 自动扩容

将预测结果与Kubernetes的HPA（Horizontal Pod Autoscaler）结合，当预测的QPS超过阈值时，自动增加Pod数量。例如：

用CronJob定时调用预测API，获取接下来1小时的QPS预测值；将预测值写入Kubernetes的ConfigMap；配置HPA使用ConfigMap中的预测值作为扩容阈值（比如targetAverageValue: {{ .Values.qps_pred }}）。

（2）模型监控与优化

ML模型不是“一劳永逸”的——业务会变化（比如用户行为改变、新功能上线），模型会“过期”。你需要建立持续优化的闭环：

① 监控模型性能

定期计算预测值与实际值的MAPE，如果MAPE上升超过10%，说明模型需要优化。比如，用Grafana监控MAPE指标，当MAPE超过15%时报警：


-- PromQL查询：计算过去24小时的MAPE
100 * avg(abs((actual_cpu_usage - predicted_cpu_usage) / actual_cpu_usage)) by (namespace, pod)

② 重新训练模型

每月用最新的数据重新训练模型，替换旧模型。比如，用Airflow调度一个定时任务：

数据收集：从Prometheus和MySQL中提取过去一个月的数据；数据预处理：处理缺失值、异常值；特征工程：提取新的时间特征、业务特征；模型训练：用XGBoost重新训练模型；模型评估：用测试集评估MAPE；模型部署：将新模型替换生产环境中的旧模型。

③ 反馈调整

分析预测值与实际值的差异，找出原因并优化特征。比如，如果某次促销的实际QPS比预测高20%，则需要：

查看促销活动的细节（比如满减金额比往年高50%）；将“促销力度”（比如满减金额占比）作为新特征加入模型；重新训练模型，验证新特征的效果。

四、案例研究：电商双11大促的容量预测实战

1. 背景介绍

某电商平台2022年双11大促期间，由于传统容量规划预测QPS为平时的3倍，但实际达到5倍，导致核心交易系统出现3次超时，影响了10万+订单。2023年，架构团队决定采用ML进行容量预测。

2. 数据收集

资源数据：2020-2022年的每小时CPU使用率、QPS、带宽（来自Prometheus）；业务数据：2020-2022年的每小时订单量、用户数、促销活动（时间、类型、力度）（来自MySQL）；外部数据：2020-2022年的节假日、天气温度（来自百度API）。

3. 特征工程

提取了以下特征：

时间特征：小时、星期几、月份、是否节假日；滞后特征：前24小时、前48小时的QPS；滚动特征：过去7天的平均订单量、过去3天的最大QPS；业务特征：是否促销、促销类型（预售/满减）、促销力度（满减金额占比）。

4. 模型选择与训练

尝试了Prophet、XGBoost、LSTM三种模型，结果如下：

模型	验证集MAPE	测试集MAPE
Prophet	8.2%	9.1%
XGBoost	4.8%	5.3%
LSTM	6.1%	6.8%

最终选择XGBoost——因为它的MAPE最低，且能很好地捕捉“促销力度”与QPS的交互作用（比如满减金额占比每增加10%，QPS增长20%）。

5. 结果与反思

预测结果：2023年双11的峰值QPS是平时的5.2倍，CPU使用率峰值是平时的4.8倍；扩容措施：将核心交易系统的服务器数量从100台扩容到500台，带宽从10G扩容到50G；实际结果：双11期间，核心交易系统的CPU使用率峰值为82%，QPS峰值达到预测值的98%，没有出现超时或崩溃；经验教训：
业务特征是关键：促销力度的特征让MAPE降低了2个百分点；模型需要校准：用验证集调整XGBoost的max_depth（从4调到6），降低了过拟合；实时监控很重要：大促期间，每小时用最新数据更新预测，确保模型适应实时变化（比如某时段的QPS比预测高10%，立即增加了20台服务器）。

五、AI应用架构师的5大最佳实践

1. 业务驱动的特征工程——不要做“为了ML而ML”的事情

ML模型的性能取决于特征的质量，而特征的质量取决于你对业务的理解。比如：

在社交应用中，要加入“热点事件标记”（比如明星绯闻）；在金融应用中，要加入“ peak 时段标记”（比如每月发薪日）；在视频应用中，要加入“天气特征”（比如炎热天气导致视频流需求增加）。

总结：先理解业务，再做特征工程。

2. 多模型融合——用“组合拳”提升准确性

单一模型往往有局限性，比如：

Prophet擅长处理季节性，但对复杂非线性拟合不好；XGBoost擅长处理多特征，但对长序列的时间依赖处理不好；LSTM擅长处理长序列，但需要大量数据。

你可以将多个模型的预测结果加权融合，比如：

用Prophet预测季节性趋势，占30%权重；用XGBoost预测业务驱动的波动，占50%权重；用LSTM预测长序列的时间依赖，占20%权重。

代码示例：


# 多个模型的预测结果
y_prophet = prophet_model.predict(X_test)
y_xgboost = xgboost_model.predict(X_test)
y_lstm = lstm_model.predict(X_test)

# 加权融合
y_final = 0.3*y_prophet + 0.5*y_xgboost + 0.2*y_lstm

3. 实时与批量预测结合——应对不同时间维度的需求

短期预测（0-1小时）：用实时数据流（比如Kafka）更新模型，预测接下来1小时的资源需求，用于动态扩容（比如Kubernetes的HPA）；中期预测（1-7天）：用批量数据训练模型，预测接下来7天的资源需求，用于提前采购服务器或调整云资源配额；长期预测（1-3个月）：结合业务规划（比如新功能上线、用户增长目标），用ML模型预测长期资源需求，用于基础设施规划。

4. 资源预留与容错机制——不要把所有鸡蛋放在ML篮子里

ML预测不是100%准确的，因此需要：

预留冗余资源：预留10-20%的冗余资源，应对不可预测的突发情况（比如黑客攻击、第三方服务故障）；设置熔断机制：当实际资源使用率超过预测值的120%时，触发熔断（比如拒绝非核心请求），保护核心系统；定期压力测试：用压测工具（比如JMeter、LoadRunner）验证扩容后的系统是否能承受峰值负载。

5. 持续优化的闭环——让模型“活”起来

容量预测是一个持续的过程，不是一劳永逸的。你需要建立以下闭环：

数据收集：定期收集新的业务数据和资源数据；模型重新训练：每月用最新数据重新训练模型；性能监控：监控MAPE等指标，当指标恶化时报警；反馈调整：分析差异原因，优化特征或参数。

六、结论：从“经验驱动”到“数据驱动”的容量规划革命

传统的容量规划是“经验驱动”的——架构师根据过去的经验制定规则，就像“凭感觉开车”。而基于ML的容量预测是“数据驱动”的——用数据和算法学习规律，就像“用导航系统开车”。

作为AI应用架构师，你需要完成3个转变：

从“拍脑袋”到“看数据”：不再依赖经验，而是用ML模型分析历史数据和业务特征；从“静态规划”到“动态闭环”：不再做一次性的容量规划，而是建立“预测-扩容-监控-优化”的闭环；从“技术导向”到“业务导向”：不再只关注技术指标，而是结合业务指标，实现“业务-技术”的协同。

最后，我想邀请你做一个小练习：

选一个你负责的系统，收集过去6个月的资源数据和业务数据；按照本文的步骤，做一次ML容量预测；对比预测结果与实际结果，分析差异原因。

如果你遇到问题，欢迎在评论区分享，我们一起讨论。

七、附加部分

参考文献

《时间序列分析与预测》（作者：Shumway, Robert H.）；Facebook Prophet文档：https://facebook.github.io/prophet/；XGBoost文档：https://xgboost.readthedocs.io/；《Deep Learning for Time Series Forecasting》（论文，作者：Lipton, Zachary C.）；Kubernetes HPA文档：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/。

致谢

感谢我的同事们在案例研究中提供的数据支持，感谢Flask和XGBoost社区的开源贡献，感谢Kubernetes团队提供的动态扩容工具。

作者简介

王晓明，资深AI应用架构师，12年互联网技术经验，专注于ML在架构设计、容量规划、性能优化中的应用。曾主导过电商、社交、金融等多个领域的容量规划项目，帮助企业提升资源利用率35%以上，减少服务中断次数85%。个人博客：https://wangxiaoming.com，微信公众号：“架构师的AI笔记”，欢迎交流。

延伸阅读：

《AI时代的架构设计：从传统到智能》；《时间序列预测实战：用Python实现Prophet、XGBoost、LSTM》；《云原生容量规划：结合Kubernetes与ML的动态扩容》。