Hybrid CUDA library tasks for single-token decode: parity, not a win — measured findings + llama.logitsLib switch - #131
Open
mikepapadim wants to merge 1 commit into
Conversation
…t) + findings: cuBLAS/cuBLASLt at parity with JIT on n=1 decode (bandwidth wall, launch-bound regime); CUDA graphs remain the single-token lever
mikepapadim
added a commit
to mikepapadim/GPULlama3.javaF
that referenced
this pull request
Jul 23, 2026
…ign edits into RFC - Add docs/VLLM-ALIGNMENT-AND-FEATURES.md: vLLM v1 (engine/core/worker/executor/ sample/spec_decode/attention) -> GPULlama3 target mapping; supported-vs-planned feature matrix; open-PR analysis + land order. - RFC + roadmap: fold in four vLLM-derived edits -> M4 chunked prefill + KVCacheSpec + EngineCore/async(sync) + persistent batch; M3 pluggable attention-backend seam (flash-attn gap); P0 land order beehive-lab#132->beehive-lab#128->beehive-lab#134->beehive-lab#129 then beehive-lab#120/beehive-lab#137, beehive-lab#131 findings-only.
orionpapadakis
added a commit
that referenced
this pull request
Aug 28, 2026
…dings The handoff still told the next session to retarget #129, assess #142 and expect three conflicting PRs. All four landed on 2026-08-28, so that guidance would have sent someone to do work that is done — the same failure mode the 2026-08-03 notes had, which this file already warns about. - The pending-PR table becomes a landed table: what each cost to adapt, and which PRs are genuinely still open (#131, #146, #148, and #149 which is this branch). - The merge guidance is gone rather than kept as history. It described a decision — which base to merge into — that has been made and acted on. - Records that CI had been dead for a month, why a green code-quality check hid it, and that build-and-run.yml draws from a pool with both a Mac and a Linux runner, so an unpinned job can pass on one and fail on the other. - Records the CUDA Q8_0 batch-prefill skip and the TornadoVM issue behind it. - Git state: the branch is pushed and open as draft PR #149, its history was rewritten, and force-pushing now needs asking because it is no longer local-only. Immediate next actions now say plainly that M6 cannot start until D-10, D-12 and D-14 close, and lists what is actually actionable meanwhile: the T1.7 recording call, wiring the benchmark gate into CI (only #146 still in the way), and taking the packed-half2 numerics question back to #138. Adds the defects found while landing the four PRs, with what they share: each was invisible because the thing that would have caught it was not running — no golden for that family, no CI, or no test exercising that overload. Architecture link validation: 326 internal links across the docs all resolve.
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.
Can the hybrid CUDA library API speed up single-token decode? — findings + reproducible switch
Explores whether the TornadoVM hybrid library tasks (cuBLAS / cuBLASLt, riding the task graph on the CUDA backend) can improve single-request, single-token decode. Companion to #127 (MMA batch prefill) and #129 (batched decode), which are where these libraries do win.
Answer: no — and this PR documents exactly why, with a switch anyone can re-run.
What's in the PR (additive, default behavior unchanged)
-Dllama.logitsLib={jit,gemmEx,lt}: the logits vocabulary projection (biggest single matvec, ~23% of decode bytes on Llama-1B) can be swapped between the stock JIT matvec, aCuBlas::cublasGemmExFP16FP32library task, and aCuBlasLt::ltMatmulFP16library task (+1.2 µs FP16→FP32 copy). Defaultjit.tornado-cublasdependency +tornado.cublasmodule on the CUDA launch path.HYBRID_DECODE_LIBS.md: full numbers + analysis.Key numbers (RTX 4090, TornadoVM 5.0.1-jdk21-dev CUDA backend)
Per-kernel (nsys, logits GEMV 128256×2048 FP16, avg of 101 calls):
matrixVectorGenericgemvx(gemmEx)gemvxEnd-to-end (3 runs, tok/s): Llama-1B jit 88.7–91.3 vs lt 88.3–90.5 (graphs off); 98.1–102.4 vs 99.9–102.2 (graphs on). Mistral-7B: 23.5 vs 23.7. Statistical ties; output coherent on every config.
Why (the useful part)
gemvxkernel is 0.6% faster: parity).fusedRmsNormFFNGateUp,fusedQKVMatmulX, matvec+residual) exist to remove launches — library tasks would de-fuse them and add launches for ~13 µs/layer of GPU savings: net loss.--cuda-graphs, +8–12% on every config) and kernel fusion.The library integration itself checks out: correct results, same CUstream as JIT kernels, CUDA-graph-capturable.