Skip to content

[DSV4.1] Keep Engram extend batch shape out of Triton constexprs (fix for sgl-project/sglang#42159) - #15

Merged
Oasis-Git merged 1 commit into
Oasis-Git:perf/dsv41-engram-extend-hashfrom
ShangmingCai:engram-extend-hash-runtime-shapes
Oct 12, 2026
Merged

Oasis-Git merged 1 commit into
Oasis-Git:perf/dsv41-engram-extend-hashfrom
ShangmingCai:engram-extend-hash-runtime-shapes

Conversation

@ShangmingCai

Copy link
Copy Markdown

Follow-up fix for sgl-project#42159, targeting its branch.

Problem

engram_hash_extend_and_commit passes the batch size (EXTEND_BS, SEARCH_STEPS) and the token count (NUM_TOKENS) as tl.constexpr. So every new prefill shape compiles and device-loads a new specialization of _engram_hash_kernel / _engram_commit_extend_history_kernel while the server is running.

In production with SGLANG_OPT_ENGRAM_EXTEND_HASH=1, the warning Triton kernel '_engram_commit_extend_history_kernel' device-loaded after serving started (free device mem: 0.37–0.62 GiB) was logged hundreds of times. The scheduler then died with CUDA OOM and the pod was killed by the liveness probe. Because the number of shapes is unbounded, warming up at startup can't cover them.

Fix

  • extend_bs, search_steps and num_tokens become runtime arguments. The row binary search now uses a runtime-bounded range.
  • One ROWS_FROM_STARTS constexpr chooses between the row map and the search, so the number of specializations stays fixed.

Verification (RTX 4090, triton 3.8.0, torch 2.14.1)

  • test/manual/quantization/test_engram_extend_hash.py: all existing bit-exact parity subtests pass (28).
  • New test_batch_shapes_reuse_compiled_kernels: on the current branch head it fails, with each kernel compiled 4 times for 4 batch shapes. With this change it passes, with 1 compiled kernel each.
  • Eager timing is unchanged:
tokens / bs before after
8192 / 1 69.7 µs 70.2 µs
8192 / 64 70.5 µs 70.9 µs
4096 / 256 68.9 µs 69.9 µs

🤖 Generated with Claude Code

engram_hash_extend_and_commit passed the batch size (EXTEND_BS, SEARCH_STEPS)
and the token count (NUM_TOKENS) as tl.constexpr, so every new prefill shape
compiled and device-loaded a fresh specialization of _engram_hash_kernel and
_engram_commit_extend_history_kernel while serving. With little free device
memory those late cuModuleLoadData calls can fail with CUDA OOM and kill the
scheduler.

Pass them as runtime arguments instead (the row search loop takes a runtime
trip count), keeping a single ROWS_FROM_STARTS constexpr. Hash and history
outputs are unchanged and the eager timing is the same (~70 us on a 4090 for
8192 tokens at bs 1/64/256). Add a test that new batch shapes reuse the
compiled kernels; it fails with 4 compiled variants before this change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Oasis-Git
Oasis-Git merged commit f5bca84 into Oasis-Git:perf/dsv41-engram-extend-hash Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants