Fuyun论文学习：LLM Agent如何做Serverless资源配置

这篇文章基于 AgenticOS 2026 论文《Fuyun: Bridging the Semantic Gap in Serverless Resource Provisioning via LLM Agents》整理，重点讨论 LLM Agent 如何进入 Serverless 资源配置问题，并把“黑盒调参”改写成“基于代码语义的策略合成”。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Fuyun: Bridging the Semantic Gap in Serverless Resource Provisioning via LLM Agents 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_16.pdf
• 论文想解决的是 Serverless 里一个很现实的问题：每个函数到底该配多少资源
• 传统方法很多把函数当黑盒调参，论文则尝试让 LLM 直接阅读代码，生成可验证的资源策略
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文的核心观点是：

Serverless 资源配置不应该只靠黑盒统计模型去猜，而应该利用 source code semantics 先合成一份可验证的参数化策略，再用运行时信号和异步反馈去持续校准。

作者提出的系统叫：

• Fuyun

论文给出的几个关键结果也很抓人：

• 相比高斯过程贝叶斯优化，达到完全可靠性只需要 4 倍更少 的 profiling samples
• 相比保守静态配置，资源浪费率降低 44 个百分点
• 在波动负载上消除了 OOM failures

名词解释

• Serverless：由平台托管运行环境、按调用触发执行的函数计算模式
• resource provisioning：为函数分配 CPU、内存等运行资源的过程
• Bayesian Optimization：一种常见的黑盒调参方法
• Policy Schema：约束策略输出格式和字段的结构化定义
• control plane：负责策略生成、更新和管理的控制面
• data plane：负责线上请求实际执行和快速决策的数据面
• profiling samples：通过实际运行采集到的性能样本，用来推断资源配置效果
• parametric policy：带参数、可根据输入规模或运行状态动态实例化的资源策略
• async feedback loop：执行完成后再异步回流指标和结果，用于后续策略修正的闭环
• OOM：Out Of Memory，内存耗尽导致进程被杀或执行失败
• black-box optimization：不理解程序内部语义，只靠输入输出结果进行调参
• cold start：函数实例首次启动时的初始化开销
• semantic gap：程序真实资源行为与平台可观测黑盒指标之间的信息落差

论文到底在解决什么问题

Serverless 虽然把基础设施藏起来了，但函数资源配置这件事并没有消失。

开发者或平台仍然要回答几个问题：

• 每个函数该配多少内存
• CPU / 并发额度怎么跟着输入变化
• 怎么在可靠性和资源浪费之间找平衡

传统方法一般有两类：

• Bayesian Optimization
• Reinforcement Learning

论文认为这些方法有一个共同弱点：

它们大多把函数当成黑盒，只看输入输出和历史轨迹，不理解程序语义。

这会导致两个问题：

• sample complexity 很高
• 在生产环境里调参成本太大

为什么作者认为 LLM 有机会解决这个问题

作者的观察是，Serverless 函数的资源行为通常和代码结构强相关，比如：

• 处理的是图片还是字符串
• 输入规模怎么影响内存占用
• 有没有明显的阶段性扩容需求

而 LLM 擅长：

• 阅读代码
• 理解控制流
• 总结资源扩展模式

所以作者提出：

与其把资源配置视为“数值预测问题”，不如把它视为“符号化策略合成问题”。

Fuyun 的核心设计

Fuyun 不是把 LLM 直接放进请求热路径，而是采用了一个 control plane + data plane 解耦架构。

1. Control Plane：离线策略生成和更新

控制面负责：

• 分析源码
• 调用 LLM 生成 parametric policy
• 用严格 Policy Schema 做验证
• 运行后根据执行反馈持续调优

论文强调这里有一个非常关键的点：

• LLM 输出不是直接变成基础设施参数
• 而是先变成可验证、受 schema 约束的策略表示

这样可以降低 hallucination 风险。

2. Data Plane：运行时轻量实例化

数据面不再调用 LLM，而是根据：

• 最新策略
• 请求入口信号
• 运行时指标

快速实例化出当前 invocation 的资源配置。

这部分必须足够轻，因为 Serverless 冷启动和函数执行都要求毫秒级响应。

3. Async Feedback Loop：异步演化

运行后，执行轨迹和遥测会回流到控制面，触发异步调优。

于是 Fuyun 形成了一个闭环：

• 静态代码语义
• 运行时即时信号
• 执行后反馈学习

论文把这套路线概括成：

• generate-then-execute
• asynchronous evolution loop

论文为什么不把 LLM 直接放在线路径

作者在引言里把这个问题说得很清楚。

1. LLM 是概率系统，而基础设施配置要求确定性

直接把模型输出映射成资源参数，风险太高。

2. LLM 延迟和 Serverless 时延目标冲突

函数执行要毫秒级决策，但 LLM 推理要秒级，直接同步调用根本不现实。

3. 纯静态代码推断又不够

因为真实环境里还有：

• 运行时噪声
• 硬件异构
• 负载漂移

所以论文最终不是“纯代码推理”，而是：

• 代码语义先给出结构化先验
• 运行时再做轻量实例化
• 事后再异步修正

论文实验结果怎么看

论文的结果非常集中，也比较有说服力。

1. 更少采样就能达到完全可靠

相比 Gaussian-process Bayesian optimization：

• Fuyun 达到 full reliability 所需 profiling samples 少了 4 倍

这说明代码语义确实给了强先验，而不是纯靠试错。

2. 显著减少资源浪费

相比保守静态配置：

• waste ratio 降低了 44 percentage points

这是一个很实在的收益，因为 Serverless 场景里“为了不 OOM 只能超配”是非常常见的问题。

3. 在易波动负载上消除 OOM

论文明确声称：

• Fuyun 在输入敏感的视频处理 benchmark 上消除了 OOM failures

这说明它不只是省资源，而是同时改善了稳定性。

我对这篇论文的几个理解

下面是我自己的理解。

1. 它把 AIOps 从“统计调参”推向了“语义调参”

过去很多自动调优系统做的是：

• 看历史数据
• 拟合资源曲线
• 再继续试探

Fuyun 的路线则是：

• 先看代码
• 先理解任务语义
• 再合成一个策略框架

这相当于把“运维调参”从黑盒优化，向“程序理解 + 在线校准”推进了一步。

2. policy schema 很关键

这篇论文不是简单说“让 LLM 预测资源值”，而是先把输出约束成可验证策略。

这点非常重要，因为它把：

• 模型的生成能力
• 基础设施需要的确定性

通过 schema 和验证层衔接了起来。

3. 这是一个很典型的“LLM 不进热路径，但改变热路径”的系统设计

LLM 没有在每次请求上直接参与决策，但它深刻影响了热路径执行逻辑。

这和很多更务实的 Agent 系统设计是一致的：

• 冷路径重推理
• 热路径轻执行

论文的局限

1. 目前更像特定工作负载验证

论文重点用了输入敏感型视频处理 workload。对更多类型函数，比如 CPU-bound、IO-bound、网络密集型函数，收益大小还需要进一步验证。

2. 代码语义不是全部

有些函数的资源行为高度依赖外部环境，仅靠源码不一定能看全，所以异步反馈闭环仍然不可缺。

3. Policy Schema 的表达能力和泛化性还值得继续研究

如果函数模式越来越复杂，策略 schema 是否足够表达，会是后续关键问题。

对工程实践的启发

1. 做 Serverless 自动调优时，可以考虑把“代码理解”前移

不要只在运行后看指标，很多资源行为在代码结构里其实早有信号。

2. 不要让 LLM 直接在毫秒级热路径上做推理

更现实的方式是把 LLM 放在控制面，数据面走轻量决策。

3. 先做可验证策略，再做在线实例化

这比直接输出裸参数更安全，也更容易纳入平台治理。

总结

如果只用一句话总结这篇论文，我会这样说：

Fuyun 真正有价值的地方，不是让 LLM 去猜一个资源数字，而是让它先从代码中抽取资源扩展规律，合成可验证策略，再让运行时系统用即时信号把策略落成具体配置。

这条路线的意义在于：

• 它保留了 LLM 的代码理解优势
• 又避免了把概率模型直接塞进基础设施热路径
• 同时通过异步反馈补上纯静态分析的不确定性

我觉得这是一篇非常典型、也很务实的 Agentic Systems 论文。

参考

• 论文 PDF：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_16.pdf
• AgenticOS 2026 Workshop：https://os-for-agent.github.io/

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)