💻 computer science

BudgetFunnel: Coarse-to-Fine Global Budget Allocation for Trace-Driven Serverless Cold-Start Mitigation

BudgetFunnel 是一个由追踪驱动的由粗到精的框架，它通过轻量级筛选和具有前驱感知能力的贪心分配器，在异构无服务器函数之间分配共享的热保留预算，实现了接近最优的冷启动缓解效果，且与全评估及现有基准策略相比，显著降低了评估开销。

原作者： xuming wu, Zhipeng Ye, Gaoyuan Zhao, Zihao Lu, Jiayi Hong, Wen-Yu Peng, Zhibin Shao, Yan Cao

发布于 2026-10-01

📖 1 分钟阅读☕ 轻松阅读

原作者： xuming wu, Zhipeng Ye, Gaoyuan Zhao, Zihao Lu, Jiayi Hong, Wen-Yu Peng, Zhibin Shao, Yan Cao

原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在现代云端，大量的应用程序运行在一种被称为“无服务器计算”（serverless computing）的模型之上。系统并不会为了处理请求而让一台计算机服务器始终保持运行状态，而是仅在用户需要时才唤醒一个全新的、空白的环境，执行任务，然后让其进入休眠。这种方法节省了资金并减少了浪费，但它有一个令人沮丧的缺陷：当用户第一次请求某项服务时，系统必须从头开始构建该环境。这个过程被称为“冷启动”（cold start），会导致明显的延迟。为了解决这个问题，系统管理员可以保持其中一些环境处于唤醒并就绪的状态，这种策略被称为“预热”（prewarming）。然而，保持过多的环境处于唤醒状态会浪费该系统旨在节省的资源。挑战在于，究竟应该让哪些函数保持温暖以及保持多久，尤其是在有成千上万个不同的函数在争夺有限资源池的情况下。

研究人员开发了一种名为 BudgetFunnel 的新方法来解决这一平衡难题。其核心思想是将用于保持环境唤醒的总可用时间视为一个共享预算，必须在海量的工作负载中进行明智的分配。在典型的云系统中，可能会有数千个不同的函数，每个函数都有其独特的用法模式。有些函数被频繁使用，而另一些则使用频率较低，或者呈现出突然且不可预测的爆发式增长。如果管理员试图为每一个函数计算完美的“保持存活”时间以最大限度地减少延迟，那么计算本身所需的时间长到变得不切实际。BudgetFunnel 通过使用一个两步走的流程来解决这个问题，首先将其问题过滤到最关键的部分。

研究人员使用来自微软 Azure 和阿里巴巴两个主要云服务商的真实世界数据日志对他们的方法进行了测试。这些日志包含数百万条记录，显示了不同函数被调用的时间。团队首先使用一种简单、快速的检查方法，来识别哪些函数如果被允许变冷，可能会导致最大的延迟。他们观察了一些基础模式，例如函数的调用频率、使用的不规则程度，以及是否遵循某种每日节奏。基于这些简单的线索，他们仅选择了前百分之十的函数作为“候选对象”进行详细分析。其余的百分之九十则被赋予了一个默认设置零，这意味着系统不会尝试让它们保持温暖。

一旦确定了候选对象，研究人员就在这个规模较小的群体上运行了详细的模拟。他们测试了保持这些特定函数唤醒的不同时长，精确计算了每种选择所能节省的延迟量与所产生的资源成本。最后，他们使用一种贪心算法（greedy algorithm）将总共可用的“温暖时间”预算分配给这些候选对象。该算法的作用就像一位拿着固定金额的谨慎购物者，在选择升级方案时，会优先选择那些能以最小成本换取最大延迟缩减的方案。最终的结果是一个定制化的计划，为最重要的函数分配了特定的保持存活时间，同时忽略了其他函数。

研究结果表明，这种聚焦的方法非常有效。通过仅评估百分之十的函数，该系统实现的计算速度比尝试为每一个函数计算最佳设置的速度提高了九倍。尽管计算时间大幅减少，但结果的质量仍然非常高。在 Azure 数据上，衡量延迟请求占总流量百分比的指标，与进行全量评估的贪心算法（即分析所有函数）产生的结果相比，偏差仅在 1.54% 以内；在阿里巴巴的数据上，偏差也在 1.93% 以内。换句话说，该系统保留了几乎所有的潜在性能收益，同时避免了分析全部内容所带来的沉重计算成本。

该研究还将此方法与其他常见策略进行了对比，例如将所有函数保持在相同的固定温暖时间，或使用平均等待时间来预测保持时长。BudgetFunnel 显著优于这些标准方法，在阿里巴巴的工作负载中，它将冷启动率降低了高达 39%。研究人员证实，他们的方法具有鲁棒性（robust），这意味着即使他们改变了统计延迟的方式或调整了测试的具体时间间隔，该方法依然表现良好。他们还验证了所使用的贪心算法非常接近数学上的最优解，与认证的最优解相比，差异小于 2.6%。

这项工作表明，在复杂的系统中，通常可以通过不检查每一个细节来找到近乎最优的解决方案。通过使用粗略的过滤器来识别最关键的元素，然后仅在重要之处应用详细分析，管理员可以高效地管理资源，而不至于陷入无法完成的计算之中。BudgetFunnel 框架提供了一种实用的方法，使无服务器应用既能保持快速响应，又不会造成过高的成本，证明了通过一点点聪明的过滤，就能在管理云端的隐形机制方面发挥巨大的作用。

技术摘要：BudgetFunnel

1. 问题陈述

无服务器计算（函数即服务，FaaS）面临着一个持久的性能挑战：冷启动。当函数在没有预先存在的热执行环境的情况下被调用时，平台必须配置资源，从而导致显著的延迟峰值。虽然预热（通过生存时间或 TTL 策略保持实例存活）可以缓解冷启动问题，但它会产生“热保留资源”（空闲计算时间）的成本。

本文解决的核心问题是在一组异构的无服务器函数之间分配共享的热保留预算。现有方法通常采用统一策略或仅关注单个函数的优化，未能考虑到不同函数特性（稀疏性、突发性、周期性）与全局资源约束之间的权衡。目标是在固定的全局热实例秒数预算下，最小化冷启动率（CSR）——具体而言，是受请求加权的冷启动调用百分比。

2. 方法论：BudgetFunnel

论文提出了 BudgetFunnel，这是一个由粗到精的追踪驱动框架，旨在高效分配共享的热预算，而无需对每个函数进行详尽评估。该框架分为三个不同的阶段运行：

阶段 0：轻量级代理筛选（粗粒度）

该框架并非模拟每一个函数，而是首先识别出一小部分最有可能从热保留策略中获益的“候选”函数。

特征： 它从调用追踪中计算轻量级统计数据：
- 稀疏性（Sparsity）： 零调用的时间槽比例。
- 突发性（Burstiness）： 请求率的归一化方差。
- 周期性（Periodicity）： 一种轻量级的每日自相关代理指标。
评分： 这些特征经过鲁棒归一化（使用中位数绝对偏差 MAD）并组合成一个等权重代理得分。
选择： 选取前 $\gamma$ 比例的函数（例如 $\gamma = 0.10$ ）作为候选函数。非候选函数被分配默认的 TTL 为 0。

阶段 1：细粒度候选评估（模拟）

只有被选中的候选函数才会进行详细的追踪驱动模拟。

模拟： 框架为每个候选函数在离散的 TTL 网格（范围从 0 到 60 分钟）上进行模拟。
指标： 它估计了相对于基准（TTL=0）进行 TTL 升级时，冷请求减少的边际量（ $\Delta CR$ ）以及热成本增加的边际量（ $\Delta Cost$ ）。
语义： 模拟使用基于槽（slot）的抽象（1 分钟为一个槽），函数在最后一次活动后的 $k$ 个槽内保持热状态。冷启动被计为请求加权事件（即请求到达时函数处于冷状态）。

阶段 2：感知优先级的全局预算分配

一个贪心分配器将全局预算 $B$ 分配给各个候选函数。

机制： 它计算将函数从当前 TTL 等级提升到网格中下一个等级的增益比（单位边际成本的边际收益）。
约束： 算法遵循优先级约束；只有在已分配了较低 TTL 的情况下，函数才能被升级到更高的 TTL。
执行： 使用最大堆，算法迭代选择具有最高增益比且符合剩余预算的升级项，直到预算耗尽。

3. 核心贡献

共享预算公式化： 论文将冷启动缓解建模为一个在共同资源预算下的全工作负载优化问题，而非孤立的单函数决策。
由粗到精的评估： 它引入了一种筛选机制，通过仅关注高潜力候选函数来降低细粒度模拟的计算成本，从而实现显著的加速。
分离的近似分析： 评估严格区分了两个来源的近似误差：
- 筛选损失（Screening Loss）： 通过将“由粗到精”方法与“全量评估”贪心方法（其中 $\gamma=1$ ）进行对比来衡量。
- 分配损失（Allocation Loss）： 通过在相同的缩减工作负载上将贪心分配器与精确的混合整数线性规划（MILP）解进行对比来衡量。
鲁棒的追踪驱动评估： 该框架在两个不同的工作负载（Azure 无服务器追踪和 Alibaba 微服务追踪）上进行了验证，并针对代理特征、TTL 网格、冷计数语义和预算定义进行了广泛的敏感性分析。

4. 实验结果

评估使用了 Azure 无服务器追踪（3 天窗口，前 1000 个函数）和 Alibaba 集群追踪–微服务 v2021（12 小时窗口，前 1000 个微服务）。

效率与准确性的平衡： 在候选比例 $\gamma = 0.10$ （仅评估 10% 的函数）时，BudgetFunnel 与全量评估基准相比，实现了约 9 倍的端到端加速。
性能差距：
- 在 Azure 追踪上，在 $1 \times B_{ref}$ 时，请求加权的 CSR 与全量评估贪心基准的差距在 1.54% 以内。
- 在 Alibaba 追踪上，差距在 1.93% 以内。
- 在整个预算扫描过程中，相对于全量评估贪心方法的最大相对 CSR 差距分别为 2.48%（Azure）和 2.16%（Alibaba）。
与基准对比：
- 在 Alibaba 上，在匹配预算的情况下，BudgetFunnel 比全局 TTL 策略降低了高达 39.4% 的 CSR，比 IAT-Mean TTL 策略降低了 21.8%。
最优性差距： 在缩减后的 Azure 工作负载（50–200 个函数）上的同范围精确 MILP 实验表明，贪心分配器与认证最优解的差距在 1.42–2.60% 之间。
鲁棒性： 该方法的排名和性能在不同的冷计数语义（请求加权 vs 槽级）、代理特征消融、以及特定提供商的追踪窗口下均保持稳定。

5. 重要性与主张

论文适度地声称 BudgetFunnel 提供了一种实用的机制，用于降低在无服务器环境中评估共享热预算的计算成本。

关于“全局”的澄清： 作者明确指出，“全局”是指全工作负载范围内的协调，而非数学意义上的全局最优。贪心分配器是一种启发式算法，而非保证全局最优的优化器。
应用范围： 该框架设计用于离线、追踪驱动的分析。作者指出，由于公开追踪数据是聚合的（缺乏每请求的时间戳），因此延迟结果被视为基于模型的敏感性分析，而非直接的生产环境测量。
互补性： 该工作并不声称要取代系统级优化（如快照或 JIT）或预测性预热。相反，它提供了一种特定的资源分配机制，可以与此类系统集成或并行运行，以优化成本与冷启动性能之间的权衡。

总之，BudgetFunnel 证明了通过将计算精力集中在经过筛选的一小部分函数上，实现具有共享预算的近乎最优的冷启动缓解是可行的，从而使大规模、追踪驱动的预算优化变得切实可行。