Skip to content

TurboQuant KV cache (3/4): WebGPU kernels + Safari/Firefox fallback#28562

Draft
TimPietrusky wants to merge 2 commits into
microsoft:mainfrom
TimPietrusky:tim/turboquant/03-webgpu-kernels
Draft

TurboQuant KV cache (3/4): WebGPU kernels + Safari/Firefox fallback#28562
TimPietrusky wants to merge 2 commits into
microsoft:mainfrom
TimPietrusky:tim/turboquant/03-webgpu-kernels

Conversation

@TimPietrusky
Copy link
Copy Markdown

Description

WebGPU EP kernels for the TurboQuant 4-bit KV cache path defined by #28560. Same algorithm and packed-cache layout as the CUDA PR (#28561), implemented as two WGSL programs and a C++ orchestrator that mirrors CUDA's Option-ε pattern.

Same code runs in three places:

  1. Native (--build_wheel --use_webgpu) — Python wheel, Dawn → Metal/D3D12/Vulkan.
  2. Browser (--build_wasm --use_webgpu --enable_wasm_jspi + JS layer --webgpu-ep --jspi) — onnxruntime-web inside transformers.js.
  3. Node.js (--build_nodejs --use_webgpu) — NAPI binding, same Dawn.

Verified numbers (Apple Silicon Metal, in-browser ORT-web via WASM/JSPI, LFM2.5-1.2B)

ctx fp16 decode TQ decode decode speedup
4 K 91.3 ms/tok 74.1 ms/tok 1.23×
16 K 179.1 ms/tok 84.0 ms/tok 2.13×

Same model in onnxruntime-node on the same machine: 28.3 / 20.0 ms/tok (1.41×). Quality: per-step cosine sim 0.993–1.000 vs fp16, top-1 token match 7-of-9 on a 9-step decode chain (matches CUDA in #28561).

What this PR contains

  • contrib_ops/webgpu/bert/turboquant_encode.wgsl.template — packs fresh fp16 K/V into the uint8 slot layout in one pass per (batch, kv_head, present_slot). When s_cache < past_seq_len the shader byte-copies from past_key/past_value; otherwise it does the full encode (||k||, FWHT, Lloyd-Max codebook lookup, V min/max, bit-pack).
  • contrib_ops/webgpu/bert/turboquant_decode.wgsl.template — packed cache → fp16 K/V scratch in BNSH layout. Codebook gather, optional norm correction, vec_norm scale, inverse FWHT, V dequant.
  • contrib_ops/webgpu/bert/turboquant_attention.{cc,h} — the RunTurboQuantAttention orchestrator. Aliases the uint8 cache as uint32 view tensors so WGSL array<u32> bindings work (ORT's ShaderVariableHelper rejects uint8 storage bindings). Branches on WebGPU::Subgroups feature:
    • Subgroups present (Chrome 136+) → ApplyFlashAttention with Q in BSNH, K/V scratch declared BNSH via Q_K_V_BSNH_BNSH_BNSH.
    • Subgroups absent (Safari, Firefox, older Chrome) → transfer Q to BNSH and route through ApplyAttention instead.
    • Env-var escape hatch ORT_TQ_DISABLE_FA=1 forces the fallback on subgroups-capable adapters for dev-machine testing.
  • contrib_ops/webgpu/bert/group_query_attention.cc/.h — TQ-aware dispatch. Reads the new GQA attributes from TurboQuant KV cache (1/4): graph rewrite + schema (foundation) #28560, reads codebook + Hadamard from input slots 14/15, runs rotary inline before the orchestrator (since ApplyFlashAttention's do_rotary path requires packed QKV which we don't have), and computes past_sequence_length from past_key.shape[2] rather than seqlens_k (HF causal-LM exports often leave seqlens_k zero-filled on the prompt step; past_key's shape is the ground truth either way, mirroring what CheckInputs does on the fp16 path).

Fallback numbers (no-subgroups path, Qwen3.5-0.8B-Text @ 4K, Node.js)

FA path Fallback (no subgroups)
TQ decode 28 ms/tok = 36 tok/s 14.3 ms/tok = 70 tok/s
TQ prompt (TTFT) 2.4 s 3.0 s

Decode is actually faster on the fallback for this shape — ApplyAttention's split-Vx decode kernel is more cache-friendly for (small Q, large cached K) than FA on our scratch tensors. Prompt is ~25% slower because of the extra TransferBSDToBNSH. Both produce coherent output (no shape errors, no NaN).

Things worth a careful look

  1. Subgroups fallback path — Q/K/V layouts have to line up with what ApplyAttention expects (BNSH for K/V, BSNH for Q). K/V scratch comes out of the decode shader already BNSH; only Q needs TransferBSDToBNSH. I set past_sequence_length = 0 and feed the entire present cache as K to skip ApplyAttention's internal past-merge.
  2. uint8 → uint32 alias view in turboquant_attention.cc — the underlying buffer never changes layout, only the type ORT sees. slot_bytes is always a multiple of 4 (we pad).
  3. detail::GetEnvironmentVar for the escape hatch — std::getenv breaks MSVC's -Werror (C4996).

Cross-OS

Cross-OS build CI green on Linux + Windows (build/link-only since hosted runners have no GPU). Apple Silicon Metal verified end-to-end on local Mac + a clean GHA macos-15 runner.

Depends on

Does not intersect with

Adds a `TurboQuantKVFusion` graph transformer that rewrites every
GroupQueryAttention node at session-create time to use a TurboQuant
4-bit packed KV cache, plus the schema, session-option keys, and CPU
helpers required for that rewrite.  No kernels in this PR — they
land in follow-ups for CUDA and WebGPU.

What this PR includes:

* `core/optimizer/turboquant_kv_fusion.{cc,h}` — the L2 transformer.
  Enabled by setting `optimization.turboquant_kv_method` to one of
  `turboquant_4bit_nc`, `turboquant_k3v4_nc`, `turboquant_3bit_nc`.
  Runs on CUDA + WebGPU EPs.  Computes Lloyd-Max centroids for the
  given (head_dim, key_bits) and a normalised Walsh–Hadamard matrix,
  injects both as graph initializers, and mutates each GQA node's
  attributes + past/present tensor types to (uint8, slot_bytes).

* `core/graph/contrib_ops/bert_defs.cc` — extends GroupQueryAttention
  with the new attributes (`kv_quant_method`, `key_quant_bits`,
  `value_quant_bits`, `norm_correction`) and two new optional inputs
  at slots 14 / 15 for the shared k_codebook + hadamard initializers.

* `include/onnxruntime/core/session/onnxruntime_session_options_config_keys.h`
  — public option keys `optimization.turboquant_kv_method` and
  `optimization.turboquant_kv_boundary`.

* `contrib_ops/cpu/bert/attention_common.h` + `attention_parameters.h`
  + `group_query_attention_helper.h` — `KVQuantMethod` enum, parameter
  struct extensions, and `CheckInputs` updates so the fp16 codepath
  passes through unchanged when TurboQuant isn't requested.

* `include/onnxruntime/core/framework/int3.h` — new packed `UInt3x8`
  type for 3-bit cache slots.  Used by the (forthcoming) 3-bit
  variants.

* `test/contrib_ops/turboquant_kv_test.cc` — host-side bit-layout
  tests for `UInt3x8`.  Kernel-level correctness is validated by the
  follow-up CUDA / WebGPU PRs.

When `optimization.turboquant_kv_method` is unset or set to "none" /
"off" the transformer doesn't fire and the graph is byte-identical
to today's output.

Design doc + reference NumPy implementation + paper-validation tests
are coming in the Python tooling PR.  The CUDA kernels (16-bit accum
WMMA + 4-bit packed cache) and the WebGPU kernels (WGSL encode/decode
with an ApplyAttention fallback for browsers without Subgroups) come
in separate PRs that each depend on this one.

Benches (LFM2.5-1.2B, RTX A40, all measured):

  ctx      fp16 decode    TQ decode      speedup
   4 K     6.2 s reply    6.0 s reply    tied
  32 K     26 s           24 s            7 %
  64 K     63 s           41 s           53 %
  128 K   (fp16 OOM)      65 s           TQ only
WebGPU EP TurboQuant kernels referenced by the graph rewriter in
microsoft#28560.  Same packed cache layout and same algorithm as the CUDA
PR (microsoft#28561), implemented as two WGSL programs + a C++ orchestrator
that mirrors CUDA's Option-ε pattern.

Same code runs in three places:
  1. Native: `--build_wheel --use_webgpu` (Python wheel, Dawn → Metal
     / D3D12 / Vulkan).
  2. Browser: `--build_wasm --use_webgpu --enable_wasm_jspi` + the JS
     layer built with `--webgpu-ep --jspi` — onnxruntime-web inside
     transformers.js.
  3. Node.js: `--build_nodejs --use_webgpu` (NAPI binding, same Dawn).

What this PR contains:

* `contrib_ops/webgpu/bert/turboquant_encode.wgsl.template` — packs
  fresh fp16 K/V into the uint8 slot layout in a single pass per
  (batch, kv_head, present_slot).  When `s_cache < past_seq_len` the
  shader byte-copies from past_key / past_value; otherwise it runs
  the full encode (||k||, FWHT, Lloyd-Max codebook lookup, V min/max,
  bit-pack).
* `contrib_ops/webgpu/bert/turboquant_decode.wgsl.template` — packed
  cache → fp16 K/V scratch in BNSH layout.  Codebook gather, optional
  norm correction, vec_norm scale, inverse FWHT, V dequant.
* `contrib_ops/webgpu/bert/turboquant_attention.{cc,h}` — the
  `RunTurboQuantAttention` orchestrator.  Aliases the uint8 cache as
  uint32 view tensors so WGSL `array<u32>` bindings work (ORT's
  ShaderVariableHelper rejects uint8 storage bindings).  Branches
  on `WebGPU::Subgroups` feature: when present, post-decode attention
  goes through `ApplyFlashAttention` (Q stays BSNH, K/V scratch
  declared as BNSH via `Q_K_V_BSNH_BNSH_BNSH`); when absent (Safari,
  Firefox, older Chrome) we transfer Q to BNSH and route through
  `ApplyAttention` instead.  An env-var escape hatch
  (`ORT_TQ_DISABLE_FA=1`) forces the fallback on subgroups-capable
  adapters for dev-machine testing.
* `contrib_ops/webgpu/bert/group_query_attention.cc/.h` — TQ-aware
  dispatch in the WebGPU GQA op.  Recognises the new attributes from
  microsoft#28560 (`kv_quant_method`, `key_quant_bits`, `value_quant_bits`,
  `norm_correction`), reads codebook + Hadamard from input slots
  14/15, runs rotary inline before the orchestrator (since
  `ApplyFlashAttention`'s do_rotary path requires packed QKV which
  we don't have), and computes `past_sequence_length` from
  `past_key.shape[2]` rather than `seqlens_k` (the HF causal-LM
  exports often leave seqlens_k zero-filled on the prompt step; the
  past tensor's shape is the ground truth either way and matches what
  `CheckInputs` does for the fp16 path).

Verified Apple Silicon Metal numbers (M-series, in-browser ORT-web
via WASM/JSPI; LFM2.5-1.2B-Instruct-ONNX):

  ctx     fp16 decode    TQ decode      decode speedup
   4 K    91.3 ms/tok    74.1 ms/tok    1.23x
  16 K   179.1 ms/tok    84.0 ms/tok    2.13x

Same model in onnxruntime-node on the same machine:

   4 K    28.3 ms/tok    20.0 ms/tok    1.41x

Quality: cosine-sim 0.993 - 1.000 vs fp16 across a 9-step decode
chain.  Top-1 token match 7-of-9 (= matches CUDA in microsoft#28561).

Fallback path (no subgroups, `ORT_TQ_DISABLE_FA=1`):

   Qwen3.5 4K, Node.js — TQ decode 14.3 ms/tok = 70 tok/s
                         (vs 28 ms/tok = 36 tok/s on FA path).
                         Faster on this shape because
                         ApplyAttention's split-Vx decode kernel
                         is more cache-friendly for (small Q, large
                         cached K).  Prompt step is slower (~25%)
                         because of the BNSH transfer overhead.

Cross-OS build (Linux + Windows) green on GHA — both compile clean.

Things worth a careful look:

1. **Subgroups fallback path** — `ApplyAttention` is the existing
   non-flash GQA path.  Q/K/V layouts have to line up with what it
   expects (BNSH for K/V, BSNH for Q).  K/V scratch comes out of the
   decode shader already in BNSH, so only Q needs `TransferBSDToBNSH`.
   I set `past_sequence_length = 0` and feed the entire present cache
   as `K` to skip ApplyAttention's internal past-merge.

2. **uint8 → uint32 alias view** in turboquant_attention.cc — the
   underlying buffer never changes layout, only the type ORT sees.
   `slot_bytes` is always a multiple of 4 (we pad).

3. **`detail::GetEnvironmentVar`** for the escape hatch — using
   `std::getenv` breaks MSVC's `-Werror` for C4996.

Depends on microsoft#28560.  Does not intersect with microsoft#28561 (CUDA) or the
Python tooling PR.
@microsoft-github-policy-service
Copy link
Copy Markdown
Contributor

@TimPietrusky please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

  • (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.
@microsoft-github-policy-service agree
  • (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.
@microsoft-github-policy-service agree company="Microsoft"
Contributor License Agreement

Contribution License Agreement

This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your
contributions to Microsoft open source projects. This Agreement is effective as of the latest signature
date below.

  1. Definitions.
    “Code” means the computer software code, whether in human-readable or machine-executable form,
    that is delivered by You to Microsoft under this Agreement.
    “Project” means any of the projects owned or managed by Microsoft and offered under a license
    approved by the Open Source Initiative (www.opensource.org).
    “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
    Project, including but not limited to communication on electronic mailing lists, source code control
    systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
    discussing and improving that Project, but excluding communication that is conspicuously marked or
    otherwise designated in writing by You as “Not a Submission.”
    “Submission” means the Code and any other copyrightable material Submitted by You, including any
    associated comments and documentation.
  2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
    Project. This Agreement covers any and all Submissions that You, now or in the future (except as
    described in Section 4 below), Submit to any Project.
  3. Originality of Work. You represent that each of Your Submissions is entirely Your original work.
    Should You wish to Submit materials that are not Your original work, You may Submit them separately
    to the Project if You (a) retain all copyright and license information that was in the materials as You
    received them, (b) in the description accompanying Your Submission, include the phrase “Submission
    containing materials of a third party:” followed by the names of the third party and any licenses or other
    restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
    guidelines concerning Submissions.
  4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
    for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
    Submission is made in the course of Your work for an employer or Your employer has intellectual
    property rights in Your Submission by contract or applicable law, You must secure permission from Your
    employer to make the Submission before signing this Agreement. In that case, the term “You” in this
    Agreement will refer to You and the employer collectively. If You change employers in the future and
    desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
    and secure permission from the new employer before Submitting those Submissions.
  5. Licenses.
  • Copyright License. You grant Microsoft, and those who receive the Submission directly or
    indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
    Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
    the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
    parties.
  • Patent License. You grant Microsoft, and those who receive the Submission directly or
    indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
    Your patent claims that are necessarily infringed by the Submission or the combination of the
    Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
    import or otherwise dispose of the Submission alone or with the Project.
  • Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
    No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
    granted by implication, exhaustion, estoppel or otherwise.
  1. Representations and Warranties. You represent that You are legally entitled to grant the above
    licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
    have disclosed under Section 3). You represent that You have secured permission from Your employer to
    make the Submission in cases where Your Submission is made in the course of Your work for Your
    employer or Your employer has intellectual property rights in Your Submission by contract or applicable
    law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
    have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
    You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
    REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
    EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
    PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
    NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
  2. Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
    You later become aware that would make Your representations in this Agreement inaccurate in any
    respect.
  3. Information about Submissions. You agree that contributions to Projects and information about
    contributions may be maintained indefinitely and disclosed publicly, including Your name and other
    information that You submit with Your Submission.
  4. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
    the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
    Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
    exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
    defenses of lack of personal jurisdiction and forum non-conveniens.
  5. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
    supersedes any and all prior agreements, understandings or communications, written or oral, between
    the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants