Does Whamp's old short-context throughput gain from int8_per_token_head KV survive on current vLLM, and how does it behave as context depth grows?
- Repo commit:
86699d21b34f53c41ceb00357cb599f57523caa3 - Slug:
vllm/qwen-27b-multi-fast - Image / engine:
vllm/vllm-openai:v0.25.1 - Weights:
Lorbus/Qwen3.6-27B-int4-AutoRound, SHA-verified byscripts/setup.sh - Model recipe: AutoRound INT4, MTP n=3, TP=4, max context 262,144, prefix caching on
- Hardware: 4× RTX 3090, PCIe-only, no NVLink
- Power cap: 230 W on every card before and after both arms
- Driver/module: NVIDIA 595.71.05, patched open module, Linux
7.0.0-28-generic - P2P: enabled at launch with
NCCL_P2P_LEVEL=PHB;nvidia-smi topo -p2p rwreported all 12 directed pairs OK - All-reduce: PYNCCL only; vLLM engine-gated custom all-reduce off at TP=4 in both arms
- Run order: FP8/e4m3, then INT8-PTH
The only intended serving-variable change was KV_CACHE_DTYPE.
| Arm | KV dtype | Attention backend | Candidate list |
|---|---|---|---|
| FP8 | fp8_e4m3 |
FLASHINFER | FLASHINFER, TRITON_ATTN |
| INT8-PTH | int8_per_token_head |
TRITON_ATTN | TRITON_ATTN only |
Three warmups followed by five measured requests per prompt.
| Metric | FP8/e4m3 | INT8-PTH | INT8 delta |
|---|---|---|---|
| Narrative wall TPS | 58.72 | 103.14 | +75.6% |
| Narrative decode TPS | 59.38 | 104.81 | +76.5% |
| Code wall TPS | 74.59 | 133.66 | +79.2% |
| Code decode TPS | 76.34 | 138.13 | +80.9% |
| Narrative TTFT | 188 ms | 153 ms | −18.6% |
| Code TTFT | 184 ms | 156 ms | −15.2% |
The old short-context result survives and is larger on this v0.25.1 run than the original v0.22.0 +57%/+65% wall-TPS result.
One warmup and three measured, salted/cache-busted requests per depth.
| Metric | FP8/e4m3 | INT8-PTH | INT8 delta |
|---|---|---|---|
| Prefill @ ~10K | 1,102.30 tok/s | 1,061.42 tok/s | −3.7% |
| TTFT @ ~10K | 8.751 s | 9.088 s | +3.9% |
| Prefill @ ~90K | 988.72 tok/s | 735.06 tok/s | −25.7% |
| TTFT @ ~90K | 93.276 s | 130.333 s | +39.7% |
Two independent 15-turn fixture sessions per arm. Prompt depth reached ~58K tokens. Values are mean decode TPS across the two sessions.
| Prompt tokens | FP8/e4m3 | INT8-PTH | INT8 delta |
|---|---|---|---|
| ~1.5K warm baseline | 104.8 | 163.6 | +56.1% |
| ~5.0K | 94.2 | 120.9 | +28.3% |
| ~7.7K | 102.8 | 102.1 | −0.7% |
| ~9.1K | 86.5 | 76.6 | −11.4% |
| ~12.4K | 119.8 | 103.0 | −14.0% |
| ~21.5K | 107.2 | 64.4 | −39.9% |
| ~27.7K | 103.9 | 52.6 | −49.4% |
| ~35.4K | 99.3 | 45.5 | −54.2% |
| ~43.3K | 113.2 | 40.5 | −64.2% |
| ~47.5K | 121.5 | 40.6 | −66.6% |
| ~58.1K | 119.2 | 33.5 | −71.9% |
At the deepest point, INT8-PTH TTFT was 19.689 s versus 13.973 s for FP8 (+40.9%). No tool-call misses were reported in either arm.
Observed after canonical benchmark:
- FP8: approximately 22,960–23,000 MiB/card
- INT8-PTH: approximately 22,162–22,202 MiB/card
- INT8-PTH saves roughly 798 MiB/card (~3.1 GiB aggregate)
int8_per_token_head remains a very strong short-context accelerator on this TP=4 Ampere rig, but it is not a generally faster KV format. Its advantage is gone by roughly 8K prompt tokens; thereafter the Triton-only path degrades rapidly. At ~58K, FP8/FlashInfer is 3.56× faster in decode (119.2 vs 33.5 TPS) and has materially lower TTFT.
Practical split:
- Short, interactive requests below roughly 5–8K: INT8-PTH wins decisively and saves VRAM.
- Long-running agents / deep context: FP8/e4m3 is the clear choice.
- Arm order was not counterbalanced: FP8 ran first, INT8-PTH second.
- Agentic completions are sampled, so generated token counts and exact prompt-token depths differ slightly between arms; the fixed fixture and two-session means keep the depth curve comparable, but this is not a token-identical decode microbenchmark.
- One rig, one power cap, one model, one engine version.
- P2P engagement was launcher/log-resolved and driver-reported; this run did not independently generate a new vLLM transfer-cache artifact.
- Rig metadata:
rig.txt - FP8 arm:
fp8/switch.log,fp8/resolved.txt,fp8/bench.log,fp8/bench-agentic.log,fp8/docker.log - INT8-PTH arm:
int8-pth/switch.log,int8-pth/resolved.txt,int8-pth/bench.log,int8-pth/bench-agentic.log,int8-pth/docker-full.log