[GPU] Skip activation dynamic quantization for 4-bit FC on discrete GPU#36907
Closed
allnes wants to merge 2 commits into
Closed
[GPU] Skip activation dynamic quantization for 4-bit FC on discrete GPU#36907allnes wants to merge 2 commits into
allnes wants to merge 2 commits into
Conversation
For 4-bit weight FullyConnected the GEMM/GEMV is memory-bound by the int4 weights, so quantizing the activation to i8 does not cut the dominant weight traffic. On the discrete-GPU oneDNN path it only adds a per-token quantize dispatch and an i8 GEMM that is slower than f16 at LLM shapes. Skip inserting the activation DynamicQuantize for FullyConnected when the device is a discrete GPU and the weights are 4-bit (i4/u4). The oneDNN FC then runs the f16 path for every batch size. Integrated GPU (bf_tiled internal DQ) and 8-bit weights are left unchanged.
allnes
force-pushed
the
gpu-dq-skip-dgpu-int4
branch
from
ad92d99 to
b98cae3
Compare
isanghao
reviewed
Jul 16, 2026
| GPU_DEBUG_TRACE << root->get_friendly_name() | ||
| << " dyn_quan is turned off: discrete GPU + 4-bit weights" | ||
| " (f16 FC is faster and batch-consistent)" << std::endl; | ||
| return true; |
Contributor
There was a problem hiding this comment.
we should use dynamic quantization for int4 weights because it shows performance gain.
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
5 participants
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.
Problem
#36078 narrowed the runtime skip of
DynamicQuantizein front ofFullyConnected. On discrete GPU the FC runs through oneDNN, which now consumes the i8 activation fromDynamicQuantizeon every token instead of the previous f16 path. This caused a decode throughput regression on discrete GPUs (e.g. ~+57% 2nd-token latency on Arc A770 for 4-bit LLMs), while integrated GPU was unaffected.4-bit weight FC is memory-bound by the int4 weights. Quantizing the activation to i8 does not reduce that dominant weight traffic, so on the discrete-GPU oneDNN path it only adds a per-token quantize dispatch and an i8 GEMM that is slower than f16 at LLM shapes — for both decode and prefill.
Details
Skip inserting the activation
DynamicQuantizeforFullyConnectedwhen:i4/u4).The oneDNN FC then takes the f16 path for every batch size, so it stays batch-consistent (this is not a batch-size threshold switch). Integrated GPU is untouched — its
bf_tiledkernel reproduces the dynamic quantization internally, as kept by #36078 — and 8-bit weights keep the existing path where i8 activations can pay off.