Researchers developed FluidPD to fix LLM serving efficiency bottlenecks
FluidPD dynamically reallocates resources between prefill and decode phases to prevent latency spikes without adding new hardware.

Serving large language models involves two distinct stages: prefill, where the AI digests your input, and decode, where it generates the response. Current systems typically lock their hardware into fixed roles for these tasks. This rigid approach causes problems when traffic patterns shift, leading to idle capacity in one area while another struggles with bottlenecks.
A team of researchers introduced FluidPD, an elastic system that manages these roles on the fly. Instead of keeping servers static, FluidPD allows them to adapt based on current demand. It uses two clever methods to balance the load.
FluidPD improves overall SLO attainment over static SGLang by up to 94.6 percentage points.
First, FluidToken lets the system borrow capacity from the decode side to help with prefill tasks during sudden spikes. This stops the prefill stage from becoming a traffic jam.
Second, FluidRole allows the system to change the role of a server without needing to restart it or reload the model. By shifting workers between prefill and decode duties in place, it maintains high performance even when request types change significantly.
The system is guided by lightweight sensors that measure resource pressure before it results in service delays. Tests on Azure workloads showed that FluidPD significantly improved service quality compared to static configurations like SGLang, achieving up to 94.6% better performance in specific metrics.
Have you ever wondered why your AI chatbot sometimes slows to a crawl during peak hours? This type of intelligent load balancing could eventually make those experiences much smoother.
However, FluidPD focuses primarily on optimizing existing capacity rather than creating new compute power. It was tested on production traces, but its real-world performance may vary depending on specific infrastructure setups and model sizes not covered in this study.
Source: arXiv cs.AI