AI 工作负载正在迅速挤压数据中心的计算、存储和供电预算。Dropbox 给出的思路并不是简单地把新增机房容量视为唯一答案，而是从需求预测、服务器利用率、存储密度、硬件生命周期和机架供电等环节继续挖掘现有基础设施。值得注意的是，其中很多工作早于这一轮 AI 热潮：长期积累的效率，最终变成了承接新负载的容量余量。
容量问题不只是“还剩多少台服务器”
传统容量规划容易把 CPU 核数、GPU 数量或存储空间作为主要指标。但在真实数据中心里，可部署容量往往受最先耗尽的资源限制：
- 机架仍有空槽位，但电力预算已经用完。
- 集群平均 CPU 利用率不高，峰值时段却没有调度余量。
- 存储原始容量充足，但副本、纠删码或冷热分层降低了可用密度。
- 旧服务器仍在运行，却在性能功耗比、故障率或维护成本上拖累整体效率。
- 需求预测偏差过大，迫使团队长期保留昂贵的安全冗余。
因此，“AI 还能部署多少”需要同时检查计算、存储、网络、功率和散热约束。一个实用的近似模型是：
可承载的新增负载 = min(
计算资源余量 / 单负载计算需求,
存储余量 / 单负载存储需求,
机架功率余量 / 单负载功率需求,
网络余量 / 单负载带宽需求
)
这个模型虽然简化，却能避免只看服务器采购数量而忽略机架级限制。
五类优化如何共同创造余量
预测决定需要保留多少缓冲
预测不是为了得到一个看似精确的数字，而是为了量化不确定性。容量团队可以同时维护基准、增长和压力情景，并分别计算所需缓冲。预测误差持续收窄后，原本用于防范偏差的闲置资源就可能被释放。
需要警惕的是，AI 需求通常比成熟业务更不稳定。模型训练、批量推理和在线推理的峰值特征不同，不能仅用月均利用率推导采购计划。
利用率优化要关注“可回收容量”
平均利用率从 30% 提升到 40%，并不自动意味着获得了三分之一的新容量。真正有价值的是调度器能否把碎片化资源重新组合，业务能否接受更严格的资源请求，以及低优先级任务能否在高峰期暂停或迁移。
可以重点检查：
- 容器或虚拟机申请量与实际峰值的差距。
- 不同集群之间无法共享的零散资源。
- 长时间闲置但无法自动回收的节点。
- 批处理任务是否支持排队、抢占和错峰运行。
存储密度影响的不只是硬盘数量
提高单机或单机架的有效存储密度，可以减少设备、端口和供电占用，为计算节点腾出空间。但更高密度也可能扩大故障域，提高重建流量，并增加散热压力。因此，密度优化必须和数据保护策略、修复时间目标及网络容量一起评估。
硬件生命周期需要看总效率
延长服务器寿命可以推迟采购和部署，但老旧硬件可能消耗更多电力才能完成同样的工作。相反，过早替换设备也会带来资本支出、迁移风险和供应链压力。合理决策应比较每单位有效工作量的综合成本，而不是使用固定年限一刀切。
机架功率是 AI 部署的硬边界
AI 加速器提高了单机功率密度。即使机房总供电尚有余额，某些机架、配电单元或供电回路也可能先达到上限。容量视图因此需要下沉到机架级，避免把全局余量误认为局部可用容量。
可以这样实践：计算多维度容量余量
下面的 Python 脚本是一个可直接运行的简化示例。它读取当前资源规模、目标安全上限和单个 AI 工作单元的需求，找出真正限制部署数量的资源。
运行前，可以把 capacity 替换为监控或资产系统导出的数据，把 ai_unit 替换为一次推理服务部署或训练任务的实测需求。
from dataclasses import dataclass
@dataclass(frozen=True)
class Resource:
name: str
total: float
used: float
safe_utilization: float
per_ai_unit: float
unit: str
def usable_headroom(self) -> float:
safe_limit = self.total * self.safe_utilization
return max(0.0, safe_limit - self.used)
def supported_ai_units(self) -> int:
if self.per_ai_unit <= 0:
raise ValueError(f"{self.name}: per_ai_unit must be positive")
return int(self.usable_headroom() // self.per_ai_unit)
capacity = [
Resource("CPU", total=120_000, used=72_000, safe_utilization=0.80,
per_ai_unit=32, unit="cores"),
Resource("Storage", total=8_000, used=5_600, safe_utilization=0.85,
per_ai_unit=1.5, unit="TB"),
Resource("Rack power", total=4_000, used=3_100, safe_utilization=0.90,
per_ai_unit=2.4, unit="kW"),
Resource("Network", total=6_000, used=3_900, safe_utilization=0.80,
per_ai_unit=4.0, unit="Gbps"),
]
results = []
for resource in capacity:
supported = resource.supported_ai_units()
results.append((resource.name, supported))
print(
f"{resource.name:12} "
f"headroom={resource.usable_headroom():8.1f} {resource.unit:5} "
f"AI units={supported}"
)
bottleneck, deployable_units = min(results, key=lambda item: item[1])
print(f"\nDeployable AI units: {deployable_units}")
print(f"Binding constraint: {bottleneck}")
执行命令：
python3 capacity_headroom.py
这个示例最重要的不是计算公式，而是把安全利用率显式化。生产环境不应把资源推到理论上的 100%，因为故障切换、预测误差、维护窗口和流量突增都需要缓冲。不同资源也应采用不同阈值，不能共用一个全局百分比。
进一步落地时，可以每天生成机架级快照，并记录三组指标：理论余量、受安全阈值约束后的可用余量，以及经过调度和故障域校验后真正可部署的余量。三者之间的差值，往往就是下一轮优化的入口。
采用这套方法时的检查清单
将现有基础设施效率转化为 AI 容量，需要持续运营，而不是一次性“清理闲置资源”。开始投入前，可以检查以下事项：
- 容量预测是否同时覆盖基准、增长和压力情景。
- 利用率指标是否包含峰值、分位数和持续时间，而非只有平均值。
- 资源是否因为集群、机架或故障域边界而无法实际调度。
- 存储密度提升是否计入重建流量、可靠性和散热成本。
- 硬件更新决策是否比较性能功耗比与总拥有成本。
- 功率数据是否细化到机架、配电单元或回路。
- 为 AI 腾出的容量是否仍保留故障切换和业务增长缓冲。
Dropbox 的经验所揭示的核心并不是某一种单点优化，而是长期形成的基础设施纪律：持续测量约束、减少浪费、校准预测，并把局部改进转换成可调度的真实容量。新增数据中心仍可能是增长计划的一部分，但在采购和建设之前，团队应先弄清现有系统中究竟有多少余量，以及这些余量为什么暂时无法被使用。