MOVZXandHinata
bf3e4af6b1
With a prefix unit finer than the block, a hybrid follow-up resumes from a single GDN state at the previous prompt's tail, and that key sits in the top attention block. Losing any one block of that prefix is a total miss. The waiting-request pins only protect a hit that is still whole when the follow-up is first looked up. Tracing the remaining misses under a long-context multi-turn agent load shows they lost their top attention block before that, in the gap between the previous turn finishing and the next turn arriving. In that gap nothing referenced the prefix. LRU then consumed it ahead of dead blocks freed later (other conversations' handed-over CoW sources and superseded states). A finished turn (stop, length, repetition, or an abort after decoding) now keeps one extra ref on each of its hashed blocks, including its GDN holds, as a grace pin. The ref is taken on both free paths, the immediate free and the deferred pop_blocks_for_free behind an in-flight step, so the prefix never passes through the free queue. A grace is released when: - the next turn is admitted on it. That is the grace holding the deepest hit block of every group, with a hit that reaches its prompt to within two prefix units, so a new turn sharing only a system prompt releases nothing. The table takes the blocks over, with no double ref. - anyone needs blocks. Graces yield before waiter pins, oldest first and one per failed allocation, so they never cause a preemption. - the bound (16) is exceeded. The oldest grace goes. - reset_prefix_cache runs. A head waiter whose admission fails pins its own hit first. It then yields graces and other pins one at a time, and only when everything yieldable covers its shortfall. Otherwise yielding would drop other conversations' prefixes and still not admit it. The shortfall is measured after the pin: the pin takes the proof block past the hit (and any hit block the lookup did not return) out of the free queue, so the shortfall of the failed attempt can be short by those blocks and the guard would yield another conversation's grace for nothing. Its own pinned blocks outside the hit it is admitted on, the proof block past it, go back first: once the hit is taken over they protect nothing, and they cost nobody else anything. At an exact fit they are the blocks it needs, and nothing else ever yields a head waiter's own pin, so without this a request that needs the whole pool waited forever. While any pin or grace is held the scheduler reports no common prefix to cascade attention. Those refs can make a block's count equal the number of running requests when only some of them share it, and cascade attention would then read it for all of them. Graces and waiter pins now follow a producer's GDN hash into its CoW copy, as holds already do. Otherwise they would keep a second ref on a running state block that its owner must own exclusively. Graces apply only to fine-grained hybrid hits (coordinator.enable_partial_hash_hits) and are off with a KV connector; a block-sized unit (the 4096 lane) is unchanged. When graces are active the scheduler logs one startup line saying so, with the bound, the hash unit and the block size. Tests: the arrival-gap reproduction fails on the previous commit (hit 0 instead of 168, both free paths). It passes here. Further tests cover the handover refcounts, yield order and bound, finish statuses, a running request at an exactly full pool, yieldable accounting, moved-hash following, the pin's extras contract, and six runs on the real scheduler: among them a head waiter whose pin raises its shortfall (it gives its proof block back and the one grace that covers the rest yields), a request that needs the whole pool (admitted on its own proof block; it waited forever before), and the common-prefix count under a grace (none reported; the count returns once the pins are gone). Co-Authored-By: Hinata <hinata@idihore.id> Signed-off-by: MOVZX <movzx@yahoo.com>
Easy, fast, and cheap LLM serving for everyone
| Documentation | Blog | Paper | Twitter/X | User Forum | Developer Slack |
🔥 We have built a vLLM website to help you get started with vLLM. Please visit vllm.ai to learn more. For events, please visit vllm.ai/events to join us.
About
vLLM is a fast and easy-to-use library for LLM inference and serving.
Originally developed in the Sky Computing Lab at UC Berkeley, vLLM has grown into one of the most active open-source AI projects built and maintained by a diverse community of many dozens of academic institutions and companies from over 2000 contributors.
vLLM is fast with:
- State-of-the-art serving throughput
- Efficient management of attention key and value memory with PagedAttention
- Continuous batching of incoming requests, chunked prefill, prefix caching
- Fast and flexible model execution with piecewise and full CUDA/HIP graphs
- Quantization: FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ/AWQ, GGUF, compressed-tensors, ModelOpt, TorchAO, and more
- Optimized attention kernels including FlashAttention, FlashInfer, TRTLLM-GEN, FlashMLA, and Triton
- Optimized GEMM/MoE kernels for various precisions using CUTLASS, TRTLLM-GEN, CuTeDSL
- Speculative decoding including n-gram, suffix, EAGLE, DFlash
- Automatic kernel generation and graph-level transformations using torch.compile
- Disaggregated prefill, decode, and encode
vLLM is flexible and easy to use with:
- Seamless integration with popular Hugging Face models
- High-throughput serving with various decoding algorithms, including parallel sampling, beam search, and more
- Tensor, pipeline, data, expert, and context parallelism for distributed inference
- Streaming outputs
- Generation of structured outputs using xgrammar or guidance
- Tool calling and reasoning parsers
- OpenAI-compatible API server, plus Anthropic Messages API and gRPC support
- Efficient multi-LoRA support for dense and MoE layers
- Support for NVIDIA GPUs, AMD GPUs, Intel GPUs, and x86/ARM/PowerPC CPUs. Additionally, diverse hardware plugins such as Google TPUs, Intel Gaudi, IBM Spyre, Huawei Ascend, Rebellions NPU, Apple Silicon, MetaX GPU, and more.
vLLM seamlessly supports 200+ model architectures on Hugging Face, including:
- Decoder-only LLMs (e.g., Llama, Qwen, Gemma)
- Mixture-of-Expert LLMs (e.g., Mixtral, DeepSeek-V3, Qwen-MoE, GPT-OSS)
- Hybrid attention and state-space models (e.g., Mamba, Qwen3.5)
- Multi-modal models (e.g., LLaVA, Qwen-VL, Pixtral)
- Embedding and retrieval models (e.g., E5-Mistral, GTE, ColBERT)
- Reward and classification models (e.g., Qwen-Math)
Find the full list of supported models here.
Getting Started
Install vLLM with uv (recommended) or pip:
uv pip install vllm
Or build from source for development.
Visit our documentation to learn more.
Contributing
We welcome and value any contributions and collaborations. Please check out Contributing to vLLM for how to get involved.
Citation
If you use vLLM for your research, please cite our paper:
@inproceedings{kwon2023efficient,
title={Efficient Memory Management for Large Language Model Serving with PagedAttention},
author={Woosuk Kwon and Zhuohan Li and Siyuan Zhuang and Ying Sheng and Lianmin Zheng and Cody Hao Yu and Joseph E. Gonzalez and Hao Zhang and Ion Stoica},
booktitle={Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles},
year={2023}
}
Contact Us
- For technical questions and feature requests, please use GitHub Issues
- For discussing with fellow users, please use the vLLM Forum
- For coordinating contributions and development, please use Slack
- For security disclosures, please use GitHub's Security Advisories feature
- For collaborations and partnerships, please contact us at collaboration@vllm.ai
Media Kit
- If you wish to use vLLM's logo, please refer to our media kit repo