Benchmarking LLM-Guided Control-Plane Policies for Backend Fault Isolation in HAProxy
作者: Aman Chauhan, Vishnu Pendyala
分类: cs.NI, cs.LG
发布日期: 2026-08-11
备注: 43 pages, 6 figures, 15 tables. Submitted to Journal of Network and Computer Applications (Elsevier)
💡 一句话要点
提出LLM引导的控制平面策略以解决HAProxy后端故障隔离问题
🎯 匹配领域: 支柱九：具身大模型 (Embodied Foundation Models)
关键词: 负载均衡 故障隔离 大型语言模型 HAProxy 动态路由 遥测数据 云计算 分布式系统
📋 核心要点
- 现有的静态负载均衡策略无法有效处理后端服务器的降级情况，导致流量持续发送到故障服务器。
- 本文提出利用大型语言模型（LLM）动态读取遥测数据并通过API隔离故障服务器，从而替代静态路由策略。
- 实验结果表明，活跃参数达到3B时，LLM策略能将5xx错误减少约88%，但也带来了尾部延迟的显著增加。
📝 摘要（中文）
静态负载均衡器无法有效处理降级而非宕机的后端服务器，导致流量持续路由到返回HTTP 500的服务器。本文探讨了大型语言模型（LLM）能否替代静态路由策略，通过每10秒读取HAProxy和Prometheus的遥测数据，利用HAProxy数据平面API隔离故障服务器。在一个具有持久结构故障的可重复基准测试中，研究了15个开放权重模型，发现当活跃参数接近3B时，LLM策略的可靠性显著提高，能够将客户感知的5xx错误减少约88%。然而，增加可用性会导致尾部延迟显著上升，且推理过程的开销也显著增加。
🔬 方法详解
问题定义：本文旨在解决静态负载均衡器在后端服务器降级时无法有效隔离故障的问题。现有方法在处理返回HTTP 500的服务器时表现不佳，需人工干预。
核心思路：通过引入大型语言模型（LLM），动态读取HAProxy和Prometheus的遥测数据，利用HAProxy数据平面API自动隔离故障服务器，从而实现更智能的流量路由。
技术框架：整体架构包括数据采集模块（每10秒读取遥测数据）、LLM决策模块（基于遥测数据做出路由决策）和HAProxy控制模块（执行隔离操作）。
关键创新：最重要的创新在于使用LLM替代传统的静态路由策略，能够根据实时数据动态调整流量路由，显著提高了故障隔离的效率。
关键设计：实验中使用了15个不同架构的开放权重模型，参数范围从0.35B到35B，重点关注模型的活跃参数数量及其对性能的影响。
🖼️ 关键图片
📊 实验亮点
实验结果显示，当活跃参数达到3B时，LLM策略能够将客户感知的5xx错误减少约88%，相比于静态基线有显著提升。然而，尾部延迟也随之增加2.6到2.8倍，推理过程的开销增加了约十倍，影响了控制间隔的有效性。
🎯 应用场景
该研究的潜在应用领域包括云计算环境中的负载均衡、微服务架构中的故障管理以及大规模分布式系统的自动化运维。通过实现智能故障隔离，能够提高系统的可用性和用户体验，降低运维成本，具有重要的实际价值和未来影响。
📄 摘要（原文）
Static load balancers cannot mitigate a backend that is degraded rather than down: round-robin and least-connections keep routing traffic to a server returning HTTP 500s until an operator intervenes. We ask whether a Large Language Model can replace the static routing policy itself, reading HAProxy and Prometheus telemetry every 10 seconds and isolating faulty servers through guardrailed calls to the HAProxy Data Plane API. On a reproducible benchmark with a persistent structural fault built into roughly one-third of a heterogeneous fleet, we sweep 15 open-weight models across five families (0.35B to 35B total parameters; dense, mixture-of-experts, and efficient-sparse architectures), reasoning modes, fleet scales of 3 to 9 backends, and two routing algorithms, totaling 240 runs. We find a capability threshold near 3B active parameters. Below it, LLM policies are typically unreliable and sometimes worse than no policy; above it, every model, regardless of architecture, saturates near an 88% reduction in client-perceived 5xx errors over the static baseline. The threshold is approximate: Gemma 4 E2B clears it with 2B active parameters, while the dense 3B Granite 4.0 Micro does not. The availability gain has costs. Draining concentrates load onto surviving servers, inflating tail latency 2.6 to 2.8 times, and enabling reasoning multiplies token spend roughly tenfold, overrunning the control interval and degrading effectiveness. The efficient operating point is a supra-threshold model in its cheapest non-reasoning mode, wrapped inside deterministic guardrails.