[sglang-miles] Cherry-pick #24851: Add routed_experts_start_len for absolute routing slice control

[ByronHsu]

Summary

Cherry-pick of #24851 (merge commit d82e339) onto sglang-miles.

• Adds routed_experts_start_len: int = 0 across the full request lifecycle (GenerateReqInput, TokenizedGenerateReqInput, OpenAI protocol, Engine, Req, tokenizer_manager, scheduler, session_controller, encode_receiver, serving_chat/completions)
• Scheduler validates start_len is non-negative and <= prompt_tokens
• maybe_collect_routed_experts honors start_len, early-returns when return_routed_experts is False, and logs row-count mismatches
• get_routed_experts gains start_len parameter with defensive clamping
• Tests added in test_return_routed_experts.py

Conflict resolution:

• Multiple conflicts due to upstream main evolution (docs_new directory, state_capturer refactoring, indexer_topk module). Resolution:
  • Removed docs_new/ files (directory doesn't exist on sglang-miles)
  • Removed state_capturer/base.py (sglang-miles uses layers/moe/routed_experts_capturer.py)
  • Removed return_indexer_topk / maybe_collect_indexer_topk references (not part of [Session R3] Add routed_experts_start_len for absolute routing slice control #24851, leaked from upstream context)
  • Added start_len parameter directly to sglang-miles get_routed_experts method instead of upstream's get_topk
  • Content conflicts in io_struct, schedule_batch, scheduler, tokenizer_manager, scheduler_output_processor_mixin resolved by taking only the routed_experts_start_len additions

Test plan

• Existing TestReturnRoutedExperts tests should pass (no regression)
• New TestRoutedExpertsStartLen tests cover default behavior, row-count correctness, bounds checking, and cache-hit interaction

Made with Cursor

[gemini-code-assist]

Code Review

This pull request introduces the routed_experts_start_len parameter, allowing users to specify an absolute start position for returned MoE routing information. The changes propagate this parameter through the API protocols, engine entrypoints, scheduling logic, and the expert capturer layer. Review feedback identifies a potential NameError due to a missing logger import in the output processor, inconsistent validation logic in the disaggregation receiver, brittle hardcoded constants in the new tests, and a type hint mismatch in a test utility function.

[gemini-code-assist]

The logger variable is used here but it does not appear to be imported or defined within this mixin file. This will likely result in a NameError at runtime when a row-count mismatch occurs. Please ensure logger is imported from sglang.srt.utils or defined at the module level.

[ByronHsu]

this is wrong. it is above

[gemini-code-assist]

Hardcoding model-specific constants like _QWEN3_30B_A3B_NUM_LAYERS and _QWEN3_30B_A3B_TOPK makes the test brittle if the default test model changes. It would be better to derive these values from the model configuration or the response metadata to ensure the test remains valid across different MoE architectures.

[gemini-code-assist]

The type hint for _send indicates it returns a dict, but the implementation returns a requests.Response object. This mismatch can be confusing for static analysis and future maintenance.

Suggested change

	def _send(self, payload: dict) -> dict:
	def _send(self, payload: dict) -> requests.Response: