[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend #7257

bigPYJ1151 · 2024-08-07T09:01:52Z

This PR provides corresponding CPU kernels of the compressed-tensor INT8 W8A8, based on oneDNN, to enable lowering compressed-tensor operations to CPU device.

Both of the static and dynamic mode are supported, and verified with related unit tests.

We initially got ~40% (static) and ~30% (dynamic) throughput improvement on llama3-8b model, with limited accuracy drop.

Tasks	Dtype	PPL
wikitext-2	BF16	9.9479
	W8A8	10.6414

PR Checklist (Click to Expand)

Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.

PR Title and Classification

Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.

Code Quality

The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes

Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.

What to Expect for the Reviews

The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
After the review, the reviewer will put an action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You

Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

github-actions · 2024-08-07T09:02:06Z

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which consists a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of default ones by unblocking the steps in your fast-check build on Buildkite UI.

Once the PR is approved and ready to go, please make sure to run full CI as it is required to merge (or just use auto-merge).

To run full CI, you can do one of these:

Comment /ready on the PR
Add ready label to the PR
Enable auto-merge.

🚀

bigPYJ1151 · 2024-08-15T10:01:28Z

/ready

bigPYJ1151 · 2024-08-15T10:33:52Z

Hi @robertgshaw2-neuralmagic @mgoin @WoosukKwon, I think this PR is ready. Would you please help to review it? Thanks!

mgoin

This looks reasonable, but could you implement a CPU test for this?

Dockerfile.cpu

csrc/cpu/quant.cpp

mgoin · 2024-08-17T17:29:37Z

csrc/cpu/torch_bindings.cpp

I think it is confusing to call this cpu implementation cutlass_scaled_mm, especially since this only supports int8 while the GPU cutlass_scaled_mm supports fp8 and int8. I would prefer to keep int8 and possibly dnnl in the name.

I understand reusing this name likely provides some ease in re-using the testing we have for cutlass_scaled_mm, so I'm open to thoughts here. cc @tlrmchlsmth

Using the same function signature makes the kernel replacement seamlessly. The kernel for CPU will check the input types and throw error message when they are not INT8.

Maybe change cutlass_scaled_mm to a general name is more clear, like scaled_mm or compressed_tensor_scaled_mm.

Okay that is fair enough to land now for easy functionality

Maybe change cutlass_scaled_mm to a general name is more clear, like scaled_mm

I'm in favor of this as long as we maintain a consistent interface. (I don't think compressed_tensor_scaled_mm is right though, since we use the kernels for other model formats, like fb_gemm)

mgoin · 2024-08-17T17:32:15Z

vllm/platforms/interface.py

Maybe we should implement a CPU device capability? Curious on your thoughts @youkaichao

I would prefer to provide explicit feature checking interfaces, like support_compressed_tensor_fp8, which will make the Platform more extensible and portable.

mgoin · 2024-08-17T17:35:09Z

tests/kernels/test_cutlass.py

Like the previous mention on overloading the name cutlass_scaled_mm, I think it makes sense to duplicate a separate kernel test for CPU gemm

I appreciate the kernel testing but I would like to see an e2e test making sure model loading, weight packing, etc works since this PR plugs into compressed-tensors - just loading the model and generating a few tokens should be sufficient

We can use cases from test_compressed_tensors.py and execute E2E tests to verify the feature workflow on the CPU backend.

The kernel tests will be keep internally and executed regularly.

zhouyuan · 2024-09-09T03:14:14Z

Hi @mgoin gentle ping, would you please kindly help to take a look again?

thanks, -yuan

mgoin

This looks to be in a good place, I just would like to see more care placed on the short-circuit in _check_scheme_supported. It would be great if you could start implementing a CPU platform class so we could check for hardware features like avx512

mgoin · 2024-09-10T16:46:51Z

csrc/cpu/torch_bindings.cpp

Okay that is fair enough to land now for easy functionality

mgoin · 2024-09-10T16:48:11Z

vllm/executor/cpu_executor.py

+def _verify_and_get_parallel_config(config: ParallelConfig) -> ParallelConfig:
+    config.distributed_executor_backend = "mp"
+    return config


It might be worth leaving a log here saying that we are overriding X to "mp"

mgoin · 2024-09-10T17:46:09Z

vllm/model_executor/layers/quantization/compressed_tensors/compressed_tensors.py

+                    f"Current capability: {capability}.")
+            return supported
+        else:
+            return True


If capability is None, we say the scheme is supported? This does not seem like good logic to do for all CT schemes, but I'm not sure how to get around this.. Could you at least put a warning here that we couldn't detect device capability and are allowing the scheme to pass

I noticed this function is only used to checking FP8 support, so it should return False on non-cuda devices by default.

This reverts commit 9eeddeab118a6aef5304c3134c9e3d57f9447454.

This reverts commit d9bcfb2d4ae31177aac85047c31edbf39b4b4e90.

bigPYJ1151 · 2024-09-11T16:31:44Z

Hi @mgoin , thanks for your comments! I made some modification based on the comments. For now, the Instruction set checking is done during the compilation time. I added a basic CpuPlatform, we can try to move the checking into it at next.

mgoin

I appreciate the changes a lot, this looks good to me!

youkaichao · 2024-09-12T00:57:56Z

vllm/config.py

            backend = "mp"
            ray_found = ray_utils.ray_is_available()
-            if cuda_device_count_stateless() < self.world_size:
+            if (torch.cuda.is_available()


weight loading tests start to fail after this pr , I think this line is to blame. cc @mgoin

…m-project#7257)

ProExpertProg · 2024-09-12T16:01:29Z

@bigPYJ1151 could you take a look at #7270 - I changed the ops bindings for quantization that you added to the CU backend in this PR

…m-project#7257) Signed-off-by: Alvant <alvasian@yandex.ru>

…m-project#7257) Signed-off-by: Amit Garg <mitgarg17495@gmail.com>

…m-project#7257) Signed-off-by: LeiWang1999 <leiwang1999@outlook.com>

bigPYJ1151 marked this pull request as draft August 7, 2024 09:01

bigPYJ1151 mentioned this pull request Aug 7, 2024

[RFC] Initial Support for CPUs #3654

Closed

4 tasks

WoosukKwon added the x86-cpu Related to Intel & AMD CPU label Aug 8, 2024

bigPYJ1151 force-pushed the int8 branch from 8caabc9 to b09b5c7 Compare August 15, 2024 09:31

github-actions bot added the ready ONLY add when PR is ready to merge/full CI is needed label Aug 15, 2024

bigPYJ1151 marked this pull request as ready for review August 15, 2024 10:01

mgoin reviewed Aug 16, 2024

View reviewed changes

Dockerfile.cpu Outdated Show resolved Hide resolved

csrc/cpu/quant.cpp Outdated Show resolved Hide resolved

bigPYJ1151 force-pushed the int8 branch from b52f4bc to 9eeddea Compare August 17, 2024 15:57

mgoin reviewed Aug 17, 2024

View reviewed changes

bigPYJ1151 force-pushed the int8 branch from ab3b29c to 98aabd2 Compare August 26, 2024 05:22

bigPYJ1151 force-pushed the int8 branch from f094e97 to 8f87781 Compare September 3, 2024 08:09

robertgshaw2-redhat mentioned this pull request Sep 3, 2024

Using Quantized Models with vLLM CPU Backend vllm-project/llm-compressor#134

Closed

bigPYJ1151 force-pushed the int8 branch 2 times, most recently from 646e1d9 to 12a859f Compare September 6, 2024 05:00

mgoin reviewed Sep 10, 2024

View reviewed changes

bigPYJ1151 added 11 commits September 11, 2024 06:04

support W8A8

c059f33

add oneDNN

a9e7f00

fix

fe9b55b

format

f02e0d9

trigger

68af6c2

format

b9a2bba

enable kernel tests

25875c6

retrigger

1ec8d94

Revert "enable kernel tests"

1874c2e

This reverts commit 9eeddeab118a6aef5304c3134c9e3d57f9447454.

enable model test

b96c9df

format

11e8379

bigPYJ1151 added 6 commits September 11, 2024 06:07

fix core binding.

7441b3f

fix cmake

1c40481

Revert "fix cmake"

89fc49d

This reverts commit d9bcfb2d4ae31177aac85047c31edbf39b4b4e90.

fix compile

e802d0a

fix ray dep

269f7e7

Add cpuplatform

c42c8d8

bigPYJ1151 force-pushed the int8 branch from ae1b51a to c42c8d8 Compare September 11, 2024 07:47

set fp8 check as false by default.

fa3bbde

mgoin approved these changes Sep 11, 2024

View reviewed changes

WoosukKwon merged commit 0b952af into vllm-project:main Sep 11, 2024

youkaichao reviewed Sep 12, 2024

View reviewed changes

dtrifiro pushed a commit to opendatahub-io/vllm that referenced this pull request Sep 12, 2024

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend (vll…

e05ea88

…m-project#7257)

NickLucche mentioned this pull request Sep 12, 2024

gha: use vllm v0.6.1 for testing opendatahub-io/vllm-tgis-adapter#125

Merged

zhouyuan mentioned this pull request Sep 18, 2024

[Feature]: Quantisation Support with CPU Backend #8547

Closed

1 task

Alvant pushed a commit to compressa-ai/vllm that referenced this pull request Oct 26, 2024

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend (vll…

508e3d7

…m-project#7257) Signed-off-by: Alvant <alvasian@yandex.ru>

garg-amit pushed a commit to garg-amit/vllm that referenced this pull request Oct 28, 2024

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend (vll…

ebb9640

…m-project#7257) Signed-off-by: Amit Garg <mitgarg17495@gmail.com>

AlpinDale mentioned this pull request Dec 26, 2024

cpu: add support for W8A8 quantization via compressed-tensor aphrodite-engine/aphrodite-engine#1017

Merged

LeiWang1999 pushed a commit to LeiWang1999/vllm-bitblas that referenced this pull request Mar 26, 2025

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend (vll…

91e97a3

…m-project#7257) Signed-off-by: LeiWang1999 <leiwang1999@outlook.com>

Uh oh!

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend #7257

[Hardware][Intel] Support compressed-tensor W8A8 for CPU backend #7257

Uh oh!

Conversation

bigPYJ1151 commented Aug 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Title and Classification

Code Quality

Notes for Large Changes

What to Expect for the Reviews

Thank You

Uh oh!

github-actions bot commented Aug 7, 2024

Uh oh!

bigPYJ1151 commented Aug 15, 2024

Uh oh!

bigPYJ1151 commented Aug 15, 2024

Uh oh!

mgoin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bigPYJ1151 Aug 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhouyuan commented Sep 9, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mgoin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bigPYJ1151 commented Sep 11, 2024

Uh oh!

mgoin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ProExpertProg commented Sep 12, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

bigPYJ1151 commented Aug 7, 2024 •

edited

Loading

bigPYJ1151 Aug 18, 2024 •

edited

Loading

zhouyuan commented Sep 9, 2024 •

edited

Loading