Repository navigation
Batched benchmark script and more detailed benchmark metrics - #25
Closed
zhuohan123 wants to merge 1 commit into
Closed
zhuohan123 wants to merge 1 commit into
zhuohan123 wants to merge 1 commit into
Conversation
Member
Author
|
Close this PR since it's too outdated. |
luo-cheng2021
pushed a commit
to luo-cheng2021/vllm
that referenced
this pull request
Apr 17, 2024
Disable weight compression on optimum-intel conversion path
z103cb
referenced
this pull request
in z103cb/opendatahub_vllm
May 9, 2024
Cherry-pick of fix commit 6100f4b from ODH: opendatahub-io#17 --------- Signed-off-by: Travis Johnson <tsjohnso@us.ibm.com> Co-authored-by: Daniele Trifirò <dtrifiro@redhat.com>
dtrifiro
added a commit
to dtrifiro/vllm
that referenced
this pull request
May 21, 2024
Ibm main update 2024-05-16
fxmarty
pushed a commit
to fxmarty/vllm-public
that referenced
this pull request
May 31, 2024
Updates to custom PagedAttention for supporting context len upto 32k.
tianyil1
pushed a commit
to tianyil1/vllm
that referenced
this pull request
Jun 5, 2024
* Fix setup.py for HPU * Fix vllm._C import ops -> vllm.hpu import ops * more of the same thing * re-add hpex rmsnorm and rope; but rope is crashing * remove unnecessary comments * add vllm/hpu files * add hpu autodetection * Add HabanaAttention stub * revert accidental changes * revert non-habana backend attention changes * add habana attention/worker/executor, sampling fails now * Restore unnecessarily changed files * enable HabanaMemoryProfiler * Make sampler pass * restore habana fused rope * prefill is now working!!! * fix prefill padding; decode is now working!!!!! * revert accidental changes * remove unused stuff in habana_paged_attn.py * remove diagnostic stuff from llm_engine.py * use HabanaExecutorAsync in async_llm_engine.py * add habana copyright headers to habana_*.py files * fix prefill attention conformance * minor naming fixes * remove naive attention from habana_attn (it never worked anyway) * re-enable profile run * Add fake HPUGraph support * add more metrics * indentation fix * ~~recipe cache metrics don't work lalalala~~ * i'm done with metrics for now * fix corner case in which hl-smi is not available but synapse is * FIXME: temporary setup.py workaround * WIP: add tensor parallelism stubs * habana worker cleanup * tensor parallelism is now working * remove unused files * remove unused func * add hpugraphrunner * improve hpu layernorm * Port pipelined PA * Port context length bucketing * remove cudagraphrunner from hpu runner * restore HPUGraphRunner back from FakeHPUGraphRunner * handle rotary embeddings properly on gaudi3 * oopsie! captured_block_counts was incorrect! * captured_block_counts.append doesn't do anything * Restore habana_main KV cache memory layout * fix memory profiler * overhaul hpugraph capture * memory profiling overhaul * format memory properly in model warmup * add graph compilation profiler for graph capture phase * adroll back log lvl on graph capture message * Remove unnecessary view on residual connection in RMSNorm (vllm-project#25) --------- Co-authored-by: madamczykhabana <110973826+madamczykhabana@users.noreply.github.com>
bigPYJ1151
pushed a commit
to bigPYJ1151/vllm
that referenced
this pull request
Jun 25, 2024
Add IPEX MOE CPU support
yukavio
pushed a commit
to yukavio/vllm
that referenced
this pull request
Jul 3, 2024
yukavio
pushed a commit
to yukavio/vllm
that referenced
this pull request
Jul 3, 2024
Closed
njhill
pushed a commit
to njhill/vllm
that referenced
this pull request
Nov 6, 2024
wuhuikx
pushed a commit
to wuhuikx/vllm
that referenced
this pull request
Mar 27, 2025
### What this PR does / why we need it?
Fix device of tensors created in `AscendAttentionBackendImpl`.
While specifying device to cards except card-0, there'll cause an
**device conflict** because the tensors (such as `attn_mask`) will be
put on card-0 by default.
This pr creates these tensors on the correct card corresponding to the
input.
### Does this PR introduce _any_ user-facing change?
User could specify device with local rank by this pr, and a modify on
vLLM is also needed, will related to this pr when created.
### How was this patch tested?
This is tested by the following code locally. Will add a test case when
the modify in vLLM is also completed.
```python
from vllm import LLM, SamplingParams
prompts = [
"Hello, my name is",
"The president of the United States is",
"The capital of France is",
"The future of AI is",
]
# Create a sampling params object.
sampling_params = SamplingParams(max_tokens=100, temperature=0.0)
# Create an LLM.
llm = LLM(model="~/.cache/modelscope/hub/Qwen/Qwen2___5-7B-Instruct", device="npu:1")
# Generate texts from the prompts.
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}")
```
Signed-off-by: MengqingCao <cmq0113@163.com>
1 task done
1 task done
1 task done
1 task done
1 task done
inkcherry
added a commit
to inkcherry/vllm
that referenced
this pull request
Nov 6, 2025
Co-authored-by: Duyi-Wang <duyi.wang@amd.com>
yma11
added a commit
to yma11/vllm
that referenced
this pull request
Nov 14, 2025
Signed-off-by: Fanli Lin <fanli.lin@intel.com> Co-authored-by: Fanli Lin <fanli0116@gmail.com>
yma11
added a commit
to yma11/vllm
that referenced
this pull request
Nov 16, 2025
Signed-off-by: Fanli Lin <fanli.lin@intel.com> Co-authored-by: Fanli Lin <fanli0116@gmail.com>
dik654
pushed a commit
to dik654/vllm-for-study
that referenced
this pull request
Nov 18, 2025
New Industry Use Cases (vllm-project#21-30): - vllm-project#21 Game Development: AI game testing + balance tuning - vllm-project#22 Construction: Vision AI safety inspection - vllm-project#23 Agriculture/Smart Farm: Crop monitoring + pest detection - vllm-project#24 Government/Public: Document automation + citizen services - vllm-project#25 Energy/Utilities: Grid monitoring + anomaly detection - vllm-project#26 Environment/Sustainability: Carbon tracking + ESG reporting - vllm-project#27 Fashion/Apparel: Trend analysis + inventory optimization - vllm-project#28 Sports/Fitness: Performance analytics + tactical analysis - vllm-project#29 Automotive/Mobility: Autonomous driving simulation - vllm-project#30 Space/Aerospace: Satellite image analysis Advanced Architecture Patterns: 1. Event-Driven Pattern: Webhook → Event Bus → Agent triggers 2. Streaming Pattern: Large dataset processing with chunking 3. Batch Processing Pattern: Celery-based parallel processing 4. Circuit Breaker Pattern: Fault tolerance + auto recovery 5. CQRS + Event Sourcing: Command/Query separation 6. Saga Pattern: Distributed transaction management Guide now covers: - 30+ industry-specific MCP implementations - 6 production-ready architecture patterns - Real-world scalability solutions - Enterprise integration strategies - Total: 8,672 lines (from 7,249)
1 task done
1 task done
yuezhu1
added a commit
to yuezhu1/vllm
that referenced
this pull request
Mar 30, 2026
…ora-resolver-get-desired-slots [Core] Add get_desired_lora_slots() to LoRAResolver interface
amd-xavierwang
pushed a commit
to amd-xavierwang/vllm
that referenced
this pull request
Apr 8, 2026
vllm-project#25) ## Purpose Add `HybridW4A16LinearKernel` that dispatches W4A16 GEMM based on batch size: - **M <= 5**: HIP skinny kernel (`wvSplitK_int4_g`) for fast decode - **M > 5**: Triton fused dequant GEMM (skinny format) for prefill (from vllm-project#37352) Stores weights **once** in skinny layout `[N, K//8]` (ExLlama shuffle). Both the HIP skinny kernel and the triton kernel read from this single weight copy, eliminating the memory overhead of the `HipW4A16SkinnyLinearKernel`'s full fp16 dequantized fallback copy (~5 GB for Qwen3-4B). Tile sizes for the triton skinny-fmt kernel are tuned per-shape on gfx1151 (Strix Halo, 40 CUs) via iterated neighbor sweeps, using K/N ratio heuristics to pick optimal BLOCK_M/N/K and num_warps at runtime. ## Benchmark Results **RedHatAI/Qwen3-4B-quantized.w4a16** on Strix Halo (gfx1151), `--enforce-eager --profile`: | Kernel | Decode (tok/s) | TPOT (ms) | TTFT (ms) | |--------|---------------|-----------|-----------------| | **HybridW4A16** (this PR) | **70.6** | 2722 | 376 | | HipW4A16Skinny (fp16 fallback) | 70.9 | 3910 | **262** | | TritonW4A16 (GPTQ-fmt) | 39.6 | 25.27 | 500 | - **Decode**: Hybrid matches Skinny (both use HIP `wvSplitK_int4_g` at M=1). Triton-only is **1.78x slower**. - **Prefill**: Hybrid matches Skinny's fp16 GEMM fallback. Triton (GPTQ-fmt) is **1.9x slower**. - **Memory**: Hybrid saves ~5 GB vs Skinny by not storing the full fp16 dequantized weight copy. Benchmarked with `vllm-bench.py --gpu-memory-utilization 0.90 --input-len 1/1024 --output-len 128/1`. ### Triton skinny-fmt kernel micro-benchmarks (T/s) Qwen3-4B weight shapes, group_size=128, converged via 4 rounds of neighbor sweeps: | M | qkv (K=2560, N=3840) | o (K=2560, N=2560) | gate_up (K=2560, N=19456) | down (K=9728, N=2560) | |---|---|---|---|---| | 8 | 2.5 | 2.4 | 2.9 | 2.6 | | 32 | 9.8 | 8.8 | 11.4 | 9.8 | | 128 | 21.7 | 18.4 | 25.7 | 22.5 | | 1024 | 26.4 | 25.1 | 26.2 | 26.3 | | 4096 | 25.6 | 24.2 | 25.0 | 24.7 | lm_eval --model vllm --model_args pretrained=RedHatAI/Qwen3-4B-quantized.w4a16,max_num_seqs=1 ``` ┌───────────────┬──────────────────┬──────────────┐ │ dtype │ flexible-extract │ strict-match │ ├───────────────┼──────────────────┼──────────────┤ │ bf16 (native) │ 0.80 │ 0.85 │ ├───────────────┼──────────────────┼──────────────┤ │ fp16 (cast) │ 0.65 │ 0.80 │ └───────────────┴──────────────────┴──────────────┘ ``` ## Test Plan - [x] Micro-benchmark all Qwen3-4B weight shapes at M={8,32,128,1024,4096} - [x] End-to-end benchmark with `vllm-bench.py` (decode + prefill) - [x] Compare against TritonW4A16 and HipW4A16Skinny kernels - [x] Correctness test with `lm_eval` with fp16 - [x] Correctness test with `lm_eval` with bf16 ## Test Result See benchmark tables above
jxmorris12
added a commit
to jxmorris12/vllm
that referenced
this pull request
Apr 21, 2026
* error on cartridge not found in vLLM * update to jack/torch-2.10 * EngineCore bugfix * safetensors save * close open file handles on volume * read files directly from checkpoint * fix flashinfer pin * fix wheels * fix image build * update test & remove workflow
heliubj18
added a commit
to heliubj18/vllm
that referenced
this pull request
Aug 8, 2026
Torch Stable ABI Audit failed in vllm-project#25 six seconds in with ModuleNotFoundError: No module named 'torch_abi_audit'. The package is pinned upstream in requirements/test/cuda.in:48, but the venv only holds what earlier failures asked for, and this step had never actually run: fail_fast cancelled it in every prior build. Installed into the venv and verified by running the step's own command in the test image - "Torch stable ABI check passed", exit 0. Added to setup-test-venv.sh with its verify entry so a venv rebuild keeps it. Co-authored-by: Claude Opus 5
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Sep 14, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
grYe99
pushed a commit
to grYe99/vllm
that referenced
this pull request
Sep 17, 2026
ci: follow the FROM chain when checking a stage's settings
nonameentername
pushed a commit
to nonameentername/vllm
that referenced
this pull request
Oct 7, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Oct 9, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Oct 19, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Oct 20, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Oct 20, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@gmail.com>
cpuchip
added a commit
to cpuchip/vllm
that referenced
this pull request
Nov 5, 2026
Let a bf16 DSpark drafter load beside a quantized target.
get_draft_quant_config asks for the draft's quantization config through the
target's hf_overrides. SpeculativeConfig composes those overrides as a callable
for the DFlash family, and get_quant_config refuses a callable ("hf_overrides
must be a dict"), so a bf16 DSpark head beside the W4A16 target dies at load
before any weight is read. The draft carries no quantization_config of its own,
so there is nothing to look up: return None in that case.
The second thing a published Qwen3 DSpark checkpoint needs is not a patch: vLLM
0.28.0's model registry maps the architecture name "DSparkDraftModel" (which
RadixArk/Qwen3.8-27B-DSpark declares) to the DeepSeek V4 DSpark class and
registers the Qwen3 class as "Qwen3DSparkModel", so the drafter is built against
the wrong model and dies on a DeepSeek-only field. A copy of the checkpoint whose
config.json names Qwen3DSparkModel loads; see the README's DSpark paragraph.
Apply from the installed vllm package directory:
patch -p1 -d venv/lib/python3.12/site-packages/vllm < patches/dspark-draft-quant-config.patch
Validated against vLLM 0.28.0 (issue vllm-project#25, item 15). Reapply after upgrades.
Source: syv-ai/qwen38-27b-rtx3090 patches/dspark-draft-quant-config.patch (at d4c4cc2). Applied as-is from the patch file; the preamble above is the patch's own.
Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Michael Stufflebeam <cpuchip@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.
No description provided.