The host-pool size check used psutil.virtual_memory().available -- regular RAM -- unconditionally. But
hugepages are carved OUT of regular RAM, so reserving e.g. 1 TB of 2M hugepages drops psutil.available
by ~1 TB, and the check then spuriously fails ("Not enough host memory ... only have 897 GB free") even
though the slab is allocated from the hugepages, not regular RAM. It was inspecting the wrong pool.
Two fixes:
- memory_pool_host.py: gate the psutil check on the DEFAULT (regular-malloc) allocator. A custom
host_tensor_allocator (the CP shared-L2 slab over hugetlbfs) owns its own capacity check, so skip the
regular-RAM check for it.
- cp_shared_l2_pool.py: add cp_shared_l2_hugetlbfs_free_bytes() + check_cp_shared_l2_hugetlbfs_capacity()
(statvfs the hugetlbfs mount: f_frsize = hugepage size, f_bavail = free hugepages) and call it in
create_cp_shared_host_slab before ftruncate/mmap. Now insufficient hugepages fail LOUD with a clean,
actionable message ("insufficient hugepages in /dev/hugepages: need X GB (N x 2M pages) but only Y GB
free; reserve more or reduce --hicache-size") instead of a cryptic mmap ENOMEM. Per-slab + sequential,
so each payload's slab sees the free remaining after the prior ones.
Unit-tested (capacity check: tiny fits, over-capacity fails loud). Pre-existing 2b L2-pooling code (not L3).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Run Unit Tests
SGLang uses the built-in library unittest as the testing framework.
Test Backend Runtime
cd sglang/test/srt
# Run a single file
python3 test_srt_endpoint.py
# Run a single test
python3 test_srt_endpoint.py TestSRTEndpoint.test_simple_decode
# Run a suite with multiple files
python3 run_suite.py --suite per-commit
Test Frontend Language
cd sglang/test/lang
# Run a single file
python3 test_choices.py
Adding or Updating Tests in CI
- Create new test files under
test/srtortest/langdepending on the type of test. - For nightly tests, place them in
test/srt/nightly/. Use theNightlyBenchmarkRunnerhelper class innightly_utils.pyfor performance benchmarking tests. - Ensure they are referenced in the respective
run_suite.py(e.g.,test/srt/run_suite.py) so they are picked up in CI. For most small test cases, they can be added to theper-commit-1-gpusuite. Sort the test cases alphabetically by name. - Ensure you added
unittest.main()for unittest andsys.exit(pytest.main([__file__]))for pytest in the scripts. The CI run them viapython3 test_file.py. - The CI will run some suites such as
per-commit-1-gpu,per-commit-2-gpu, andnightly-1-gpuautomatically. If you need special setup or custom test groups, you may modify the workflows in.github/workflows/.
CI Registry System
Tests in test/registered/ use a registry-based CI system for flexible backend/schedule configuration.
Registration Functions
from sglang.test.ci.ci_register import (
register_cuda_ci,
register_amd_ci,
register_cpu_ci,
register_npu_ci,
)
# Per-commit test (small 1-gpu, runs on 5090)
register_cuda_ci(est_time=80, suite="stage-b-test-1-gpu-small")
# Per-commit test (large 1-gpu, runs on H100)
register_cuda_ci(est_time=120, suite="stage-b-test-1-gpu-large")
# Per-commit test (2-gpu)
register_cuda_ci(est_time=200, suite="stage-b-test-2-gpu-large")
# Nightly-only test
register_cuda_ci(est_time=200, suite="nightly-1-gpu", nightly=True)
# Multi-backend test
register_cuda_ci(est_time=80, suite="stage-b-test-1-gpu-small")
register_amd_ci(est_time=120, suite="stage-a-test-1-gpu-small-amd")
# Temporarily disabled test
register_cuda_ci(est_time=80, suite="stage-b-test-1-gpu-small", disabled="flaky - see #12345")
Choosing Between 1-GPU Suites (5090 vs H100)
When adding 1-GPU tests, choose the appropriate suite based on hardware compatibility:
| Suite | Runner | GPU | When to Use |
|---|---|---|---|
stage-a-test-1-gpu-small |
1-gpu-5090 |
RTX 5090 (32GB, SM120) | Stage A per-commit smoke on 5090 (CUDA) |
stage-a-test-1-gpu-small-amd |
AMD CI runners | ROCm | Stage A per-commit smoke (AMD) |
stage-b-test-1-gpu-small |
1-gpu-5090 |
RTX 5090 (32GB, SM120) | 5090-compatible tests (preferred) |
stage-b-test-1-gpu-large |
1-gpu-h100 |
H100 (80GB, SM90) | Large models or 5090-incompatible tests |
Use stage-b-test-1-gpu-small (5090) whenever possible - this is the preferred suite for most 1-GPU tests.
Use stage-b-test-1-gpu-large (H100) if ANY of these apply:
-
Architecture incompatibility (SM120/Blackwell):
- FA3 attention backend (requires SM≤90)
- MLA with FA3 backend
- FP8/MXFP4 quantization (not supported on SM120)
- Certain Triton kernels (shared memory limits)
-
Memory requirements:
- Models >30B params or large MoE
- Tests requiring >32GB VRAM
-
Known 5090 failures:
- Weight update/sync tests
- Certain spec decoding tests
If a test cannot run on 5090 due to any of the above, use stage-b-test-1-gpu-large which runs on H100.
Available Suites
Per-Commit (CUDA):
- Stage A:
stage-a-test-1-gpu-small(5090),stage-a-test-2,stage-a-test-cpu - Stage B:
stage-b-test-1-gpu-small(5090),stage-b-test-1-gpu-large(H100),stage-b-test-2-gpu-large - Stage C (4-GPU):
stage-c-test-4-gpu-h100,stage-c-test-4-gpu-b200,stage-c-test-4-gpu-gb200,stage-c-test-deepep-4-gpu-h100 - Stage C (8-GPU):
stage-c-test-8-gpu-h20,stage-c-test-8-gpu-h200,stage-c-test-8-gpu-b200,stage-c-test-deepep-8-gpu-h200
Per-Commit (AMD):
stage-a-test-1-gpu-small-amd,stage-b-test-1-gpu-small-amd,stage-b-test-2-gpu-large-amd
Nightly:
nightly-1-gpu,nightly-2-gpu,nightly-4-gpu,nightly-8-gpu, etc.
Running Tests with run_suite.py
# Run per-commit tests
python test/run_suite.py --hw cuda --suite stage-b-test-1-gpu-small
# Run nightly tests
python test/run_suite.py --hw cuda --suite nightly-1-gpu --nightly
# With auto-partitioning (for parallel CI jobs)
python test/run_suite.py --hw cuda --suite stage-b-test-1-gpu-small \
--auto-partition-id 0 --auto-partition-size 4
Writing Elegant Test Cases
- Learn from existing examples in sglang/test/srt.
- Reduce the test time by using smaller models and reusing the server for multiple test cases. Launching a server takes a lot of time.
- Use as few GPUs as possible. Do not run long tests with 8-gpu runners.
- If the test cases take too long, considering adding them to nightly tests instead of per-commit tests.
- Keep each test function focused on a single scenario or piece of functionality.
- Give tests descriptive names reflecting their purpose.
- Use robust assertions (e.g., assert, unittest methods) to validate outcomes.
- Clean up resources to avoid side effects and preserve test independence.
- Reduce the test time by using smaller models and reusing the server for multiple test cases.
Adding New Models to Nightly CI
- For text models: extend global model lists variables in
test_utils.py, or add more model lists - For vlms: extend the
MODEL_THRESHOLDSglobal dictionary intest/srt/nightly/test_vlms_mmmu_eval.py