Devotd Github
NewLLM infrastructure

guqiong96/lsglang 1.7.2 — expert cache fill path and verification defaults

guqiong96/lsglang 1.7.2 is a release commit that splits the GPU expert cache fill path in two and turns on the speculative verification defaults.

Repositoryguqiong96/lsglang ↗

guqiong96/lsglang 1.7.2 is a release commit that splits the GPU expert cache fill path in two and turns on the speculative verification defaults.

GitHub description: Lsglang is a special extension of sglang that fully utilizes CPU and GPU computing resources with an efficient GPU parallel + NUMA parallel architecture, suitable for MOE model hybrid inference.

stars
★ 147
Forks
17
Language
Python
License
Apache-2.0
Latest release
lsglang-v1.6.0
Read original source ↗View on GitHub ↗

Lsglang extends SGLang into a hybrid inference server for MoE (a model that splits processing across multiple experts) that uses CPU and GPU together. The message of commit 2eee88c dated November 3, 2026 is 'Release 1.7.2', and the three changed files are README.md, RELEASE_NOTES.md, and python/pyproject.toml (137 lines changed, 122 lines added, 15 lines deleted).

The center of this version is the GPU expert cache, i.e. splitting into two the paths that fill the part keeping frequently used experts resident on the GPU. The default value 1 of the new environment variable LK_POOL_NO_STAGE sends each NUMA fragment directly from pinned host pages to the slots by DMA, eliminating host copies. On an 8-node host, asynchronous DMA copies occur about 16 times. The README states that in the same build, for DeepSeek-V4-Flash-0731/DSPARK the expert admission cost fell from 1.1 ms to 0.13 ms, and gather fell from 1669-2494 us to 0 us. If 0 is given, the existing coalesced staging ring, LK_POOL_STAGE, operates instead.

The more visible change is on the speculative decoding side. The default value of LK_VERIFY_RESIDENT changed from 0 to 1, so draft rows ride the expert residency that real tokens created. The README states that on DeepSeek-V4-Flash-0731/DSPARK it is +17.6% versus the CPU-only path, with the acceptance rate unchanged. LK_POOL_MBOX_SPLIT was removed from the recipes because in its single row it is 7.43 ms/step versus 7.07-7.35 ms/step and it was not clear which side was faster, and LK_POWER_SAVING was corrected to be idle-state only and not to reduce power during inference. LK_POOL_LOG, LK_VERIFY_PUMP, LK_POOL_DET_SPLIT, and LK_POOL_SPLIT_PROBE were separated into debug-only sections.

Still, it is too early to judge on these numbers alone. All the values were measured by the README on a specific build, and on DeepSeek-V4.1-Flash-1017 TP2/3090 the conclusion is the opposite. In this configuration, with the per-fragment default the median decode drops from 27.0 tok/s to 21.1 tok/s, and with LK_POOL_NO_STAGE=0 it goes back to 26.0 tok/s. The sample counts also differ, 284 and 11. Therefore the three recipes launch/sglang_serve_dsv41_*.sh are pinned to 0 and the default value 1 is left in place everywhere else. There is no basis for applying this as-is to other models and hardware.