Files
sglang/test
Cheng Wan ebb1c88d23 config: stop writing config onto the published ServerArgs at three sites (#33334)
Each of these wrote a value after resolution so a later reader would find it on
the instance. None of them needed the instance: one write was redundant, and the
two that carry a value the resolved-config readback reports move to
get_context().override, which the readback overlays.

- The SM100 GDN prefill default was written onto ServerArgs and read back one
  line later by initialize_linear_attn_config. It is now the return value of
  flashinfer_gdn_prefill_default, threaded into initialize_linear_attn_config
  (an explicit --linear-attn-prefill-backend still wins) and recorded with
  get_context().override so /server_info reports the backend in effect.
- The XGrammar fallback recorded grammar_backend="none" on the instance. No code
  reads the field after the factory reads it once, but get_internal_state
  reports the whole resolved config, so the fallback now lands there instead:
  the readback tells the truth and the seed keeps the requested backend.
- UnifiedRadixCache.init_hicache re-applied the direct-IO layout fixup that
  __post_init__ already applies: init_hicache only runs when hierarchical cache
  is on, which is exactly when _handle_hicache normalizes page_first to
  page_first_direct (pinned by test_hicache_io_backend_and_mem_layout_
  compatibility::direct_with_page_first). Three fixtures reached the fixup by
  building ServerArgs(model_path="dummy"), whose resolution is skipped, so they
  now declare the layout resolution would have produced.

Writer ratchet 34 -> 31.
2026-08-02 21:22:05 -07:00
..

Test and Continuous Integration (CI) System in SGLang

This page covers principles and essentials: folder layout, how to run tests, registration, and suite selection. For complete references, see the skill guides:

CI Pipeline Overview

The CI pipeline runs in three sequential stages: A (pre-flight, ~3 min) → B (basic, ~30 min) → C (advanced, ~30 min). Kernel and multimodal-gen tests run in parallel with stage B. For details on stage gating, fast-fail mechanisms, execution modes (PR vs scheduled vs /rerun-stage), and debugging CI failures, see the CI workflow guide.

Folder Organization

  • registered/: CI test files, auto-discovered by run_suite.py. Most tests live here. JIT kernel tests are an exception (see below).
  • manual/: Non-CI tests for local debugging or special setups.
  • run_suite.py: CI runner — scans registered/ and JIT kernel directories.

The system supports both unittest and pytest. The launcher runs python filename.py -f with failfast enabled by default.

Make sure your file ends with exactly one of:

# for unittest
if __name__ == "__main__":
    unittest.main()
# for pytest
if __name__ == "__main__":
    import sys
    sys.exit(pytest.main([__file__]))

Do not add custom argparse or modify sys.argv before these calls — the CI runner appends -f for failfast.

Run Tests Locally

# Single file
python3 test/registered/core/test_srt_endpoint.py

# Single test method
python3 test/registered/core/test_srt_endpoint.py TestSRTEndpoint.test_simple_decode

# Single JIT kernel test
python3 test/registered/jit/test_add_constant.py

# Run a suite
python3 test/run_suite.py --hw cpu --suite base-a-test-cpu
python3 test/run_suite.py --hw cuda --suite base-a-test-1-gpu-small

# Nightly tests
python3 test/run_suite.py --hw cuda --suite nightly-1-gpu --nightly

# With auto-partitioning (for parallel CI jobs)
python3 test/run_suite.py --hw cuda --suite base-b-test-1-gpu-small \
    --auto-partition-id 0 --auto-partition-size 4

CI Registration

Every CI-discovered test file must call a registration function at module level:

from sglang.test.ci.ci_register import register_cuda_ci

register_cuda_ci(est_time=80, stage="base-b", runner_config="1-gpu-small")

Parameters: est_time (seconds), stage + runner_config (target stage and runner pool from scripts/ci/runner_configs.yml), nightly=True (nightly-only), disabled="reason" (temporarily disable).

Keep est_time, stage, runner_config as literal valuesrun_suite.py collects them by AST parsing.

JIT kernel correctness tests and benchmarks live under test/registered/jit/, same as other registered tests (their helpers stay alongside the kernel source under python/sglang/kernels/jit/ and are imported by absolute path):

  • Correctness tests: test/registered/jit/test_*.pybase-b-kernel-unit-test-1-gpu-large
  • Benchmarks: test/registered/jit/benchmark/bench_*.pybase-b-kernel-benchmark-test-1-gpu-large

Choosing a Suite

Use the lightest suite that meets your test's needs. Full suite tables are in the write-sglang-test skill.

Need Suite
No GPU required base-a-test-cpu
Small GPU (fits 5090, 32GB) base-b-test-1-gpu-small (most tests go here)
Large GPU memory or Hopper features base-b-test-1-gpu-large
JIT kernel correctness base-b-kernel-unit-test-1-gpu-large
JIT kernel benchmarks base-b-kernel-benchmark-test-1-gpu-large
Multi-GPU (2/4/8) base-b-test-2-gpu-large, base-c-test-*
Long-running or experimental nightly-* suites

Steps for Adding a Test

See the write-sglang-test skill for templates, fixtures, model selection, and a complete checklist.

Multi-Hardware Backends

This README mostly describes the NVIDIA GPU CI pipeline. Other hardware backends (AMD, NPU) follow the same practices and use the multi-backend registry system. A scheduled job summarizes test coverage across all backends; here is an example run.

Tips

  • Learn from existing examples in test/registered.
  • Reuse servers — launching is expensive. Share one server across many test methods via setUpClass.
  • Use as few GPUs as possible. Prefer 1-GPU runners.
  • Each test file should take < 500 seconds; split if longer.
  • Each GitHub Actions job should take < 30 minutes; split if longer.
  • If tests are too slow for per-commit, consider nightly suites.

Other Notes

Adding New Models to Nightly CI

  • Text models: Extend the global model list variables in test_utils.py.
  • VLMs: Extend the MODEL_THRESHOLDS dictionary in test/registered/eval/test_vlms_mmmu_eval.py.