SGLang Humanize Review

Overview

sgl-project/sglang

• PR metadata
• file path and code language
• GitHub

  diff_hunk

  code context
• original reviewer comment text
• replies grouped into the same review discussion
• original comment language, including non-English and CJK text

Corpus Tools

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --query cuda --limit 5

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --path python/sglang/srt --category correctness --limit 8

python3 skills/sglang-humanize-review/scripts/query_sglang_review_corpus.py \
  --query server_args --format jsonl --limit 3

references/sglang-review-corpus-2024-2025.jsonl.gz

python3 skills/sglang-humanize-review/scripts/collect_sglang_review_corpus.py \
  --repo sgl-project/sglang \
  --start-year 2024 \
  --end-year 2025 \
  --out-dir skills/sglang-humanize-review/references

Review Workflow

1. Inspect the actual diff first.
   • Use

     git diff

     ,

     gh pr diff

     , or the patch supplied by the user.
   • Identify changed SGLang subsystems: server args, scheduler, memory/cache, model runner, attention backend, quantization, kernels, OpenAI API, metrics, docs, or tests.
2. Read

   references/corpus-summary.md

   .
   • Note top review surfaces and categories that overlap with the diff.
   • Preserve the original language of any relevant corpus examples; do not translate user-facing comments unless the user asks.
3. Query similar review threads.
   • Search by path first for touched SGLang modules.
   • Search by risk keyword next, for example

     cuda

     ,

     kv cache

     ,

     server_args

     ,

     openai

     ,

     logprob

     ,

     tp

     ,

     dp

     ,

     eagle

     ,

     fp8

     ,

     benchmark

     , or

     pytest

     .
   • Prefer evidence from the same subsystem over broad keyword matches.
4. Produce a code-review response.
   • Lead with concrete findings ordered by severity.
   • Include file and line references from the reviewed diff.
   • Explain the failure mode, not just the preferred style.
   • Suggest a fix or validation step when the issue is actionable.
   • Keep nits separate from correctness, performance, or compatibility risks.
5. If no issue is found, say so clearly.
   • Mention the main residual risk and the test or benchmark coverage that would increase confidence.

SGLang Review Heuristics From The Corpus

• Model and quantization behavior: model config drift, tokenizer assumptions, FP8/INT4 quantization paths, MoE routing, speculative decoding, and attention backend compatibility.
• Correctness before style: edge cases, failed assertions, unexpected error codes, shape/dtype mismatches, state cleanup, and silent behavior changes.
• GPU and kernel paths: CUDA graph capture, Triton/CUDA kernels, FlashInfer and FlashAttention behavior, launch conditions, SM compatibility, and fallback behavior.
• Server API compatibility: OpenAI-compatible request/response shapes,

  server_args

  , CLI defaults, endpoint behavior, streaming, and backward compatibility.
• Memory and cache lifecycle: KV cache accounting, radix cache resets, memory pool ownership, eviction, fragmentation, and OOM behavior.
• Distributed runtime: TP/DP/PP/EP rank assumptions, NCCL paths, synchronization, worker state, race conditions, and hang risk.
• Tests and benchmarks: ask for targeted tests when behavior changes, and ask for benchmark evidence when a change claims performance or touches a hot path.
• Docs and examples: keep docs aligned with CLI defaults, endpoint names, model support, install steps, and version-specific behavior.
• Observability: review metrics, logs, warning levels, traceability, and error messages when operational behavior changes.

Review Style

• Be terse but specific.
• Prefer a question when intent is ambiguous.
• Call out production-facing behavior changes explicitly.
• Do not invent a corpus precedent; query the corpus when using it as evidence.
• Keep multilingual comments intact. If a relevant thread is Chinese or another language, use it as-is for evidence and answer in the user's language unless the user asks otherwise.
• Avoid cargo-culting old comments. Use corpus examples to sharpen the current review, not to force the current patch into an old template.

Output Contract

• Findings first, ordered by severity, with file/line references.
• Open questions or assumptions.
• Test or benchmark gaps.
• A short summary only after findings.

• likely reviewer concerns
• missing tests or benchmark evidence
• suggested patch cleanup
• corpus queries used