Pith. sign in

REVIEW 3 cited by

PolyServe: Efficient Multi-SLO Serving at Scale

Not yet reviewed by Pith; the record is open.

This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.

SPECIMEN: schema-true, not a live event

T0 review · schema-true

One-sentence machine reading of the paper's core claim.

pith:XXXXXXXX · record.json · timestamp

arxiv 2507.17769 v1 pith:IXCGSNUB submitted 2025-07-17 cs.DC cs.LG

PolyServe: Efficient Multi-SLO Serving at Scale

classification cs.DC cs.LG
keywords polyserverequestslatencyschedulingauto-scalinglatency-sensitiverequirementsapplications
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved
0 comments
read the original abstract

Advances in Large Language Models (LLMs) have led to a surge of LLM-powered applications. These applications have diverse token-generation latency requirements. As a result, simply classifying workloads as latency-sensitive (LS) or best-effort (BE) overlooks the nuances within the latency-sensitive category and results in suboptimal user experiences and scheduling opportunities. However, efficiently serving requests with multiple SLO requirements poses significant challenges. First, all requests within a batch generate new tokens simultaneously, which can misalign them with their distinct SLO requirements. Moreover, while existing systems focus on auto-scaling for handling various overall request rates, the diversity of SLOs necessitates fine-grained auto-scaling among these SLO tiers. Finally, unlike LS/BE scenarios, where BE requests can be aborted at any time to ensure the SLO attainment of LS requests, those with different latency-sensitive SLOs cannot tolerate prolonged delays, and tail latency must be controlled. To tackle these challenges, we propose PolyServe, a novel multi-SLO scheduling policy at scale that maintains high SLO attainment while maximizing throughput. PolyServe first groups requests into multiple bins based on their per-token latency requirement, then schedules each bin to a subset of the server fleet. PolyServe routes requests to the highest-load but still SLO-attainable server to create a load gradient that facilitates auto-scaling. To increase utilization, PolyServe permits looser-SLO requests to share tighter-SLO instances when their own servers are saturated. PolyServe uses profiling data to guide scheduling decisions and manage tail latency through request-wait-time-aware scheduling, dynamic chunking, and continuous chunked prefill prediction. PolyServe achieves 1.23x goodput gain compared to existing policies, achieving up to 92.5% of optimal goodput.

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. SMetric: Rethink LLM Scheduling for Serving Agents with Balanced Session-centric Scheduling

    cs.DC 2026-07 conditional novelty 6.5

    Balancing only first-turn agent requests while keeping follow-ups cache-aware raises LLM cluster TPS 10-16% (colocation) and prefill TPS 2-34% (disaggregation) over SOTA schedulers on production agent traces.

  2. Beyond Greedy Chunking: SLO-Aware Sliding-Window Scheduling for LLM Inference

    cs.DC 2026-06 unverdicted novelty 6.0

    SlidingServe achieves up to 30% higher service capacity and 16-53% fewer SLO violations in LLM inference by using dynamic chunking and priority-based batch construction.

  3. Simple is Better: Multiplication May Be All You Need for LLM Request Scheduling

    cs.DC 2026-03 conditional novelty 6.0

    Multiplying new-prefill-token count by instance batch size yields a hyperparameter-free LLM scheduler that matches or beats tuned linear and simulation policies on real production traces.