From 981ca8313f6d0d20053292013e721826b4102025 Mon Sep 17 00:00:00 2001 From: Liangsheng Yin Date: Mon, 24 Nov 2025 13:50:00 +0800 Subject: [PATCH] [misc] Rename minilb install env & remove files & fix lint (#13831) --- python/sglang/srt/disaggregation/mini_lb.py | 6 ------ sgl-router/bindings/python/setup.py | 10 ++++++++-- test/srt/test_priority_scheduling.py | 14 +++++++------- 3 files changed, 15 insertions(+), 15 deletions(-) delete mode 100644 python/sglang/srt/disaggregation/mini_lb.py diff --git a/python/sglang/srt/disaggregation/mini_lb.py b/python/sglang/srt/disaggregation/mini_lb.py deleted file mode 100644 index 5aaa2a70e..000000000 --- a/python/sglang/srt/disaggregation/mini_lb.py +++ /dev/null @@ -1,6 +0,0 @@ -raise RuntimeError( - """The 'mini_lb' module has been relocated to the 'sglang_router' package. - We recommend installing 'sglang-router' with Rust support for optimal performance. - If you encounter issues building the router with Rust, set the environment variable - 'SGLANG_ROUTER_BUILD_NO_RUST=1' and add '--mini-lb' to the command line to use the Python version of 'mini_lb'.""" -) diff --git a/sgl-router/bindings/python/setup.py b/sgl-router/bindings/python/setup.py index 38cd64011..17d782a79 100644 --- a/sgl-router/bindings/python/setup.py +++ b/sgl-router/bindings/python/setup.py @@ -1,11 +1,13 @@ import os +import warnings from setuptools import setup -no_rust = os.environ.get("SGLANG_ROUTER_BUILD_NO_RUST") == "1" +with_rust = os.environ.get("SGLANG_ROUTER_BUILD_WITH_RUST", None) +with_rust = with_rust is None or (not with_rust.lower() in ["0", "false", "no"]) rust_extensions = [] -if not no_rust: +if with_rust: from setuptools_rust import Binding, RustExtension rust_extensions.append( @@ -15,6 +17,10 @@ if not no_rust: binding=Binding.PyO3, ) ) +else: + warnings.warn( + "Building 'sglang-router' without Rust support. Performance may be degraded." + ) setup( rust_extensions=rust_extensions, diff --git a/test/srt/test_priority_scheduling.py b/test/srt/test_priority_scheduling.py index 923bcb2d3..88d955fa0 100644 --- a/test/srt/test_priority_scheduling.py +++ b/test/srt/test_priority_scheduling.py @@ -291,35 +291,35 @@ class TestPrioritySchedulingMultipleRunningRequests(CustomTestCase): def test_priority_scheduling_preemption_token_offset_calculation(self): """ Verify correct token offset calculation during preemption. - + This test specifically targets the bug where rem_total_token_offset was incorrectly calculated using the incoming request's tokens instead of the preempted request's tokens (related to issue #13111 and PR #13201). - + THE BUG: In schedule_policy.py line 700, the code was using: self.rem_total_token_offset -= self._get_running_request_total_token_offset(req) Instead of: self.rem_total_token_offset -= self._get_running_request_total_token_offset(running_req) - + WHY THIS TEST CATCHES THE BUG: - Request 1 (preempted): 8000 tokens - This is what SHOULD be freed - Request 3 (incoming): 1000 tokens - This is what WAS freed (bug) - Token difference: 8000 - 1000 = 7000 tokens incorrectly accounted - + With the bug, the system thinks it only freed 1000 tokens instead of 8000 tokens. This causes incorrect memory accounting and can lead to: 1. Scheduler believes less memory is available than actually is 2. Subsequent requests (like Request 4) may fail to schedule or cause issues 3. Memory calculations become increasingly inaccurate with each preemption - + The test creates a scenario where: 1. A low-priority request with many tokens (8000) starts running 2. A high-priority request with few tokens (1000) arrives and triggers preemption 3. The system must correctly free 8000 tokens from the preempted request 4. Additional requests can be scheduled only if tokens were correctly freed 5. Execution order validates priority-based scheduling works correctly - + The large token difference (8x) makes the bug's impact obvious and testable. """ responses = asyncio.run( @@ -360,7 +360,7 @@ class TestPrioritySchedulingMultipleRunningRequests(CustomTestCase): _verify_genereate_responses( responses, expected_status_and_error_messages, e2e_latencies ) - + # Verify execution order: high priority requests finish before low priority ones # Request 3 (priority 100) should finish first # Request 4 (priority 50) should finish second