Files
sglang/docs
laoyao0822 50d0008705 Enable batched CP shared-KV current reuse correctness
Batch-size > 1 cache-hit traffic must not lose the current/partial-current reuse fast path. This change extends the target MLA/index sync-correct path to validate batched current suffix rows, compose page-aligned prefix spans, and route batched index top-k through current-only or partial-current reuse without falling back to scalar guards.\n\nThe implementation keeps page as the minimum cache unit: prefix cache coverage is page-aligned, while current suffix rows are sliced by valid extend lengths so padded tail rows are not exposed to attention. The index top-k batch path now mirrors the single-request contract: current-only reuses current index KV directly, partial-current materializes once and shares the dense buffer across request segments.\n\nConstraint: CP shared-KV supports in-seq zigzag only; round-robin remains fail-fast for shared-KV.\nConstraint: No new collectives are introduced; this is a sync correctness path, not a new communication scheme.\nRejected: Keep bs>1 current_index_kv fail-fast | disables the cache-hit path that W4 is meant to restore.\nRejected: Pad requests to a common batch length | violates the page-granular contract and exposes padded tails to consumers.\nConfidence: medium\nScope-risk: moderate\nDirective: Do not reintroduce batch_size_not_one or batch_gt1 current-reuse guards without proving an equivalent batched fast path exists.\nTested: Local py_compile for touched runtime/test files.\nTested: Remote g0034 pytest test_nsa_cp_utils.py test_cp_shared_kv_runtime.py => 157 passed, 5 warnings, 2 subtests passed.\nTested: Remote g0034 pytest test_cp_shared_kv_layout.py => 27 passed, 3 warnings.\nNot-tested: Full ETE with live traffic; CUDA kernel-backed batched descriptors; L1 prefetch, HiCache load/backup, and draft/EAGLE bs>1 current reuse.
2026-06-03 07:06:21 +08:00
..
2025-04-03 21:20:21 -07:00

SGLang Documentation

This is the documentation website for the SGLang project (https://github.com/sgl-project/sglang).

We recommend new contributors start from writing documentation, which helps you quickly understand SGLang codebase. Most documentation files are located under the docs/ folder.

Docs Workflow

Install Dependency

Linux:

apt-get update && apt-get install -y pandoc parallel retry
pip install -r requirements.txt

macOS:

brew install pandoc parallel retry
pip install -r requirements.txt

Update Documentation

Update your Jupyter notebooks in the appropriate subdirectories under docs/. If you add new files, remember to update index.rst (or relevant .rst files) accordingly.

  • pre-commit run --all-files manually runs all configured checks, applying fixes if possible. If it fails the first time, re-run it to ensure lint errors are fully resolved. Make sure your code passes all checks before creating a Pull Request.
# 1) Compile all Jupyter notebooks
make compile  # This step can take a long time (10+ mins). You can consider skipping this step if you can make sure your added files are correct.
make html

# 2) Compile and Preview documentation locally with auto-build
# This will automatically rebuild docs when files change
# Open your browser at the displayed port to view the docs
bash serve.sh

# 2a) Alternative ways to serve documentation
# Directly use make serve
make serve
# With custom port
PORT=8080 make serve

# 3) Clean notebook outputs
# nbstripout removes notebook outputs so your PR stays clean
pip install nbstripout
find . -name '*.ipynb' -exec nbstripout {} \;

# 4) Pre-commit checks and create a PR
# After these checks pass, push your changes and open a PR on your branch
pre-commit run --all-files

Documentation Style Guidelines

  • For common functionalities, we prefer Jupyter Notebooks over Markdown so that all examples can be executed and validated by our docs CI pipeline. For complex features (e.g., distributed serving), Markdown is preferred.
  • Keep in mind the documentation execution time when writing interactive Jupyter notebooks. Each interactive notebook will be run and compiled against every commit to ensure they are runnable, so it is important to apply some tips to reduce the documentation compilation time:
    • Use small models (e.g., qwen/qwen2.5-0.5b-instruct) for most cases to reduce server launch time.
    • Reuse the launched server as much as possible to reduce server launch time.
  • Do not use absolute links (e.g., https://docs.sglang.io/get_started/install.html). Always prefer relative links (e.g., ../get_started/install.md).
  • Follow the existing examples to learn how to launch a server, send a query and other common styles.

Documentation Build, Deployment, and CI

The SGLang documentation pipeline is based on Sphinx and supports rendering Jupyter notebooks (.ipynb) into HTML/Markdown for web display. Detailed logits can be found in the Makefile.

Notebook Execution (make compile)

The make compile target is responsible for executing notebooks before rendering:

  • Finds all .ipynb files under docs/ (excluding _build/)
  • Executes notebooks in parallel using GNU Parallel, with a relatively small --mem-fraction-static
  • Wraps execution with retry to reduce flaky failures
  • Executes notebooks via jupyter nbconvert --execute --inplace
  • Records execution timing in logs/timing.log

This step ensures notebooks contain up-to-date outputs with each commit in the main branch before rendering.

Web Rendering (make html)

After compilation, Sphinx builds the website:

  • Reads Markdown, reStructuredText, and Jupyter notebooks
  • Renders them into HTML pages
  • Outputs the website into:
docs/_build/html/

This directory is the source for online documentation hosting.

Markdown Export (make markdown)

To support downstream consumers, we add a new Makefile target:

make markdown

This target:

  • Does not modify make compile
  • Scans all .ipynb files (excluding _build/)
  • Converts notebooks directly to Markdown using jupyter nbconvert --to markdown
  • Writes Markdown artifacts into the existing build directory:
docs/_build/html/markdown/<relative-path>.md

Example:

docs/advanced_features/lora.ipynb
→ docs/_build/html/markdown/advanced_features/lora.md

CI Execution

In our CI, the documentation pipeline first gets all the executed results and renders HTML and Markdown by:

make compile    # execute notebooks (ensure outputs are up to date)
make html       # build website as usual
make markdown   # export markdown artifacts into _build/html/markdown

Then, the compiled results are forced pushed to sgl-project.io for rendering. In other words, sgl-project.io is push-only. All the changes of SGLang docs should be made directly in SGLang main repo, then push to the sgl-project.io.