Repository navigation
[Pooling] Reduce Clef metadata overhead - #63495
Merged
Merged
Conversation
taneem-ibrahim
marked this pull request as ready for review
October 24, 2026 21:20
taneem-ibrahim
requested review from
gty111,
noooop and
yewentao256
and removed request for
gty111 and
noooop
October 24, 2026 21:20
Build schema indices with NumPy and pack integer metadata into one host-to-device transfer. Use named unpacking for the resulting tensors while preserving per-request staging and decision-head computation. Signed-off-by: Taneem Ibrahim <taneem.ibrahim@gmail.com>
taneem-ibrahim
force-pushed
the
clef-speedup
branch
from
October 25, 2026 03:08
34d428c to
124d499
Compare
yewentao256
approved these changes
Oct 25, 2026
yewentao256
left a comment
Member
There was a problem hiding this comment.
LGTM, thanks for the work!
Contributor
Author
|
/ci run |
|
✅ Triggered Buildkite CI #97139 for commit |
Micador
pushed a commit
to Micador/vllm
that referenced
this pull request
Oct 27, 2026
Signed-off-by: Taneem Ibrahim <taneem.ibrahim@gmail.com> Signed-off-by: Christopher Mackenzie <christopher.mackenzie.software@gmail.com>
Micador
pushed a commit
to Micador/vllm
that referenced
this pull request
Oct 27, 2026
Signed-off-by: Taneem Ibrahim <taneem.ibrahim@gmail.com> Signed-off-by: Christopher Mackenzie <christopher.mackenzie.software@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Overview
Clef builds and copies several small metadata tensors for every request. This uses NumPy for the CPU work and reduces the pooler’s host-to-device copies from nine to three per request, leaving the decision-head math unchanged.
Validation
Model: Cloudflare/clef-flash, BF16, MRV2, native
/v1/systemone. All pairs below are main → PR; C means concurrent requests, and input tokens are rounded means.B300: measured roughly 3–5% higher throughput on the tested short, single-question workloads; longer inputs were effectively flat. The controlled study and profiling details below qualify that result.
The reference test passed on both versions, 306 CPU + 306 GPU metadata cases matched across four streams, and all 1,024 question results matched main versus PR within serial/C16 modes. Another 112 requests passed with
VLLM_GPU_SYNC_CHECK=erroron B300. Timed requests for the displayed cases: 93,272 on B300, zero errors. These checks establish output parity, not labeled task accuracy.Controlled input-length study (B300)
This separate C16 study fixes three options per question and verifies the total input-token count on every response. Each version used two fresh servers in main → PR → PR → main order, with two 30-second windows per case/server after 10 seconds of warmup. The last two servers reversed case order. Profiling was disabled.
With one question, the serving gain becomes effectively flat as input length increases. At 4,096 tokens, changing question count from 1 to 8 to 32 also leaves serving throughput effectively flat; the isolated B16 pooler still improves by 3.0%, 4.6% and 8.5%, respectively. Those pooler timings use real head weights with synthetic hidden states and lexical embeddings.
The short-input mean is variable: main windows ranged from 154.18–155.95 requests/s and PR windows from 156.86–172.07; +4.64% is an observed average, not a guaranteed gain. There were 73,659 timed requests with zero errors and 344 exactly matching question results in separate parity checks. Peak sampled whole-device/process memory was 93,462/92,510 MiB on both versions; these include KV cache and retained allocations.
This study uses
--max-num-seqs 16 --max-num-batched-tokens 65536, allowing C16 × 4,096 tokens without the original table’s token-budget limit. The other model, dtype, affinity and prefix-cache settings are unchanged. More questions replace state padding and increase total options; this separates total length from question count, not question overhead from option overhead. Both arms use the same existing source/wheel environment with the exact baseline/PR pooler methods applied, not separate current-main rebuilds.Focused CPU/GPU profile (B300)
Nsight Systems captured warmed-up Q1/C16 requests at 256 and 1,024 total tokens, with temporary NVTX markers around schema parsing, indices, transfers, head execution and frontend encoding. Four fresh servers supplied one accepted three-second capture per variant/length: 1,207 requests, zero errors. Capture head counts match client completions; eight separate paired requests matched exactly.
_indiceshost duration/request, main → PRBytes transferred remain 779/request for these inputs. GPU activity overlaps about 31–37% of the pooler host span at 256 tokens and 77–82% at 1,024 tokens. This supports CPU/GPU overlap as an explanation, but profiling perturbs timing and batch formation, so it does not attribute the full unprofiled throughput gain. These are instrumented host spans, not CPU time saved on the critical path.
For short inputs, the head still occupies about 88% of the PR pooler’s host span, including kernel dispatch; frontend encoding is about 0.60 ms/request on both versions. Other frontend costs are not conclusively attributed. Any head-batching experiment belongs in a separate PR.
Capture configuration: CUDA/NVTX/OS-runtime tracing, 100 Hz Python sampling, CUDA graph tracing at graph granularity, 15 seconds of warmup, then a three-second capture started/stopped through the native profiling endpoints. No profiler timings are used in the serving tables. Nsight lost its agent on later captures; only complete first captures from verified fresh servers were retained and checked against client counts.
Methodology, reproduction and test commands
Reproducer: start a fresh server for each arm, selecting its source tree on
PYTHONPATH. B300 used GPU 0, server CPUs 0–15, client CPUs 16–19 and--gpu-memory-utilization 0.3:CUDA_VISIBLE_DEVICES=0 OMP_NUM_THREADS=1 VLLM_USE_V2_MODEL_RUNNER=1 \ PYTHONPATH=/path/to/base-or-branch \ taskset -c 0-15 .venv/bin/python -m vllm.entrypoints.cli.main serve /path/to/clef-flash \ --served-model-name clef --dtype bfloat16 --max-model-len 8192 \ --max-num-seqs 64 --max-num-batched-tokens 16384 --gpu-memory-utilization 0.3 \ --limit-mm-per-prompt '{"image":0,"video":0}' --no-enable-prefix-caching \ --host 127.0.0.1 --port 18971 --seed 0 taskset -c 16-19 .venv/bin/python bench_confirm.py --label main-A --duration 15 --rounds 2The client warms up each case with
max(C, 8)requests, includes draining outstanding requests in elapsed time, and samples memory/clocks every 0.5 seconds.vllm bench servehad no native SystemOne adapter in the tested versions. Save asbench_confirm.py:Test plan: run the existing self-contained reference test on each source tree (parent conftest disabled), selecting the reserved GPU:
AI assistance disclosure: Codex (GPT-6) helped draft the code and ran the benchmark/parity checks reported here.