Motivation

During multi-LoRA decode, each sequence gets its own segment in the Triton sgemm grid — even when many sequences share the same adapter. This means the grid scales with batch_size instead of num_adapters, launching excessive blocks and wasting GPU cycles.

This PR sorts tokens by adapter and merges per-sequence segments into per-adapter segments, so the kernel grid scales with adapter count instead.

Modifications

• kernel_utils.py (new): _resolve_token_positions() Triton JIT helper — gathers/scatters through a permutation when sorted, passes through otherwise.
• All four sgemm kernels (sgemm_lora_a, sgemm_lora_b, qkv_lora_b, gate_up_lora_b): added SORTED_BY_ADAPTER constexpr path with indirection via
  _resolve_token_positions, plus early-exit for empty segments and excess grid blocks.
• triton_backend.py: compute_sgemm_routing() builds merged per-adapter batch info using argsort + searchsorted; called during decode only. CUDA graph buffers pre-allocated in init_cuda_graph_batch_info().
• test_sgemm_sorted_by_adapter.py (new): verifies numerical equivalence (bf16, atol=1e-4) between per-sequence and sorted-by-adapter paths for all four kernels, plus mixed-rank and single-adapter edge cases.

Accuracy Tests

Unit test compares original per-sequence output against sorted-by-adapter output across all kernels.

Speed Tests and Profiling

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations.
• Provide accuracy and speed benchmark results according to Test the accuracy and
  Benchmark the speed.
• Follow the SGLang code style guidance.