The Value of a Negative Result: Closing the Attention Occupancy Investigation on Blackwell GPUs

Introduction

In the high-stakes world of production GPU kernel optimization, not every hypothesis leads to a performance gain. Some of the most valuable findings are negative results—empirical evidence that a promising approach does not work, saving weeks of wasted engineering effort. Message [msg 13576] in this opencode session captures exactly such a moment: the formal close-out of a systematic investigation into attention kernel occupancy tuning for DeepSeek-V4-Flash running on NVIDIA Blackwell (sm_120) GPUs. The message is brief—a summary paragraph followed by a structured todo update—but it represents the culmination of an intense multi-experiment cycle that tested three optimization variants, resolved a critical configuration discrepancy, characterized benchmark noise, and ultimately produced a conclusive finding that reshaped the project's roadmap.

The Context: A Performance Ceiling on Blackwell

To understand why this message matters, one must appreciate the broader context. The assistant had been optimizing the DeepSeek-V4-Flash model's decode throughput on a system of 8 NVIDIA RTX PRO 6000 Blackwell GPUs. The decode attention kernel—a custom Triton implementation of Multi-head Latent Attention (MLA) with split-K parallelism—had been tuned to a baseline configuration of BLOCK_T=16, num_warps=4, num_stages=2 (abbreviated BT16/w4/s2). This baseline, combined with a prior TARGET_CTAS=512 optimization that increased the number of cooperative thread arrays, had yielded meaningful throughput improvements of up to 12.8% at moderate concurrency levels.

However, the decode throughput was still saturating at approximately 845 tokens/second per GPU at high concurrency (C=96 concurrent requests). The assistant hypothesized that this ceiling was caused by a latency-hiding problem: the attention kernel's gather operations (reading key-value data from the MLA cache) were stalling warps, and increasing GPU occupancy through more warps per streaming multiprocessor (SM) or deeper prefetch pipelines could hide this latency and boost throughput. This hypothesis was codified as workstream "#3a" in the project plan: an A/B test of attention kernel occupancy configurations, with the ultimate goal of informing a full register-reducing kernel rewrite that would pack more warps onto each SM.

What Was Tested: Three Variants, Three Rejections

The message succinctly summarizes the experimental results. Variant V1 tested num_warps=8—doubling the warp count per thread block from the baseline of 4. The idea was that more warps would provide the GPU's warp scheduler with more independent instruction streams to issue while others waited on memory operations. The result was a clear regression: throughput dropped by 14-18% at low concurrency and 3-7% at high concurrency. The root cause was identified through subagent code analysis: the MLA decode kernel operates on tiny [16,16] matrix-multiply-accumulate (MMA) tiles. With 8 warps, the work of subdividing these already-small tiles across twice as many warps introduced scheduling overhead and register pressure that dwarfed any latency-hiding benefit.

Variant V2 took a different approach: keeping the efficient 4-warp configuration but deepening the prefetch pipeline from 2 stages to 3 stages (num_stages=3). This increased shared memory usage from approximately 60KB to 81KB—still within the 99KB per-SM limit on Blackwell—and aimed to improve latency hiding by allowing more outstanding memory transactions. However, the per-split loop iterations in the MLA kernel are short (only 4-6 iterations per block at high context lengths), and a 3-stage pipeline cannot fill properly before it must drain. The result was a 9.9% regression at C=64 and smaller regressions elsewhere. The overhead of pipeline fill/drain and increased shared memory pressure dominated any theoretical benefit.

Variant V3—a batch-aware configuration that would dynamically select between 4 and 8 warps based on batch size—was rendered moot by V1's decisive rejection of 8 warps at every batch size.

The Thinking Process: From Hypothesis to Evidence

The reasoning visible in the assistant's earlier messages (particularly [msg 13562], [msg 13568], [msg 13569], and [msg 13571]) reveals a methodical, evidence-driven approach. Before any testing began, the assistant resolved a critical ambiguity: the number of local attention heads per GPU. Initial subagent analysis had suggested block_h=32 with 80KB of shared memory, but the assistant recalculated based on the actual configuration (attn_tp_size=4 with 64 total heads, yielding n_local_heads=16) and determined the correct value was block_h=16 with 60KB of shared memory. This correction was crucial—it meant V2's 3-stage configuration (81KB) would fit within the 99KB limit, whereas the stale 80KB estimate would have suggested it was too close to the boundary.

When V2's initial quick benchmarks showed marginal improvements (~0.5-0.8%), the assistant correctly identified these as potentially within the noise band and ran a full benchmark suite across all concurrency levels. The full results revealed the regression pattern. When the baseline revert appeared to show a throughput drop, the assistant resisted the temptation to assume a configuration loss and instead verified that TARGET_CTAS=512 was still live in the process environment—which it was. The apparent drop was noise, confirmed by re-running the benchmark and observing a range of 775-845 tokens/second across runs.

This led to one of the message's most important contributions: the characterization of benchmark variance at approximately ±5-7%. This finding is itself a valuable piece of output knowledge, as it establishes the signal-to-noise ratio for all future performance experiments on this system.

Why This Message Was Written

Message [msg 13576] serves several distinct purposes. First and foremost, it is a close-out communication: the assistant is informing the user (and itself, through the structured todo system) that the #3a investigation is complete and all tasks are marked done. The message explicitly states that the system is "back to its verified baseline state with the kernel backup harmless and in place"—a reassurance that the experimental changes have been fully reverted and production stability is preserved.

Second, the message is a knowledge distillation. It extracts the key learnings from a complex, multi-day investigation into a concise summary: all three variants rejected, baseline optimal, register-rewrite refuted, benchmark variance characterized. This distillation is essential for the human reader who may not have followed every subagent analysis and benchmark run.

Third, the message is a decision point. By declaring the register-reducing rewrite "not worth pursuing," the assistant redirects engineering effort away from a high-cost, low-probability approach. The message explicitly flags "OEA" (Opportunistic Expert Activation) as the next candidate to explore, setting the stage for the next phase of work.

Assumptions, Mistakes, and Corrections

The investigation was built on several assumptions that were tested and either confirmed or refuted. The primary assumption was that the attention kernel's throughput ceiling was caused by a latency-hiding problem solvable through occupancy tuning. This assumption was refuted by the experimental evidence: both occupancy-increasing levers (more warps, deeper prefetch) regressed performance, indicating that the baseline configuration was already optimal for this kernel shape and that the throughput ceiling had a different root cause (likely gather bandwidth or inherent work pattern limitations).

A secondary assumption was that a full register-reducing kernel rewrite could deliver 15-25% throughput gains by packing 8 warps per SM. This assumption was refuted by V1's regression: 8 warps per SM was tested directly and it performed worse, not better. The message explicitly calls this out: "the register-reducing rewrite isn't worth pursuing."

One potential mistake that was avoided deserves mention: when the baseline revert appeared to show a throughput regression, the assistant did not assume a configuration error. Instead, it verified the environment variables, confirmed TARGET_CTAS=512 was live, and re-ran the benchmark to discover the variance. This disciplined approach prevented a false conclusion.

Input and Output Knowledge

To fully understand this message, one needs knowledge of several domains: the Triton autotune system and its num_warps/num_stages configuration knobs; the MLA (Multi-head Latent Attention) architecture used in DeepSeek models; the sm_120 Blackwell GPU architecture and its shared memory limits; CUDA graph capture semantics and their interaction with autotune; and the project's existing performance baseline and plan documents.

The message creates significant output knowledge: a conclusive empirical finding that BT16/w4/s2 is the optimal feasible configuration for this kernel; a documented benchmark variance of ±5-7% that contextualizes all past and future measurements; a de-prioritization of the register-rewrite approach that saves engineering effort; and a clear next-step recommendation (OEA) that guides the project's trajectory.

Conclusion

Message [msg 13576] exemplifies a crucial but often underappreciated aspect of engineering: the disciplined close-out of a negative result. In a field where positive results (speedups, optimizations, breakthroughs) receive disproportionate attention, the ability to conclusively determine that a promising approach does not work—and to distill that finding into actionable knowledge—is equally valuable. The assistant's systematic investigation of three attention kernel variants, its careful characterization of benchmark noise, its resolution of configuration ambiguities, and its clear communication of the outcome all demonstrate a methodical, evidence-driven engineering practice. The message closes one chapter and opens the next, with the project's roadmap now informed by hard data rather than untested assumptions.