{
  "schema_version": 1,
  "builder_plan": {
    "scenario": "Profiling shows attention computation is a bottleneck in your self-hosted service.",
    "change": "Check the supported GPU, tensor shapes, and precision, then replace only the relevant kernel.",
    "baseline": "The existing kernel inside the same complete serving pipeline.",
    "steps": [
      "Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.",
      "Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.",
      "Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.",
      "Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test."
    ],
    "measure": "Numerical differences, end-to-end latency, throughput, and memory at realistic shapes.",
    "decision": "Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation."
  },
  "builder_review": null,
  "arxiv_id": "2609.12923",
  "title": "Dissecting GPU Utilization for LLM Inference on Nvidia Hopper",
  "summary": "The method replaces the single SM utilization percentage with eight counter-validated views derived from raw Nsight Compute reports, mapping utilization gaps to concrete mechanisms such as fragment fill, occupancy limits, stall signatures, wave quantization, and kernel selection. The cost is profiling overhead and engineering effort: NCU runs add measurement time, require hardware counter access, and demand expertise to interpret per-layer kernel roles across the serving stack. It can fail if insights are overfit to the profiled configuration (vLLM, FlashAttention-3, cuBLASLt on H100), since kernel selection and stall behavior shift with different models, runtimes, or GPU generations.",
  "rationale": "Fine-grained NCU-based profiling runs on a single GPU at negligible infrastructure cost and directly informs decode batching and kernel decisions the reader must make in production.",
  "technique": "Counter-based GPU utilization profiling for LLM inference",
  "family": "kernels_e_atencao",
  "recommendation": "adotar",
  "published": "2026-09-11",
  "as_of": "2026-10-18",
  "editorial_status": "indexed",
  "source_url": "https://arxiv.org/abs/2609.12923",
  "independent_implementations": 0,
  "total_implementations": 0,
  "stars": 0,
  "citations": 0,
  "claims": [
    {
      "claim_id": "claim-01",
      "statement": "The method replaces the single SM utilization percentage with eight counter-validated views derived from raw Nsight Compute reports, mapping utilization gaps to concrete mechanisms such as fragment fill, occupancy limits, stall signatures, wave quantization, and kernel selection. The cost is profiling overhead and engineering effort: NCU runs add measurement time, require hardware counter access, and demand expertise to interpret per-layer kernel roles across the serving stack. It can fail if insights are overfit to the profiled configuration (vLLM, FlashAttention-3, cuBLASLt on H100), since kernel selection and stall behavior shift with different models, runtimes, or GPU generations.",
      "basis": "inferred",
      "result": "",
      "baseline": "",
      "conditions": "",
      "source_url": "https://arxiv.org/abs/2609.12923",
      "source_page": null,
      "source_excerpt": ""
    }
  ],
  "exposure_map": [
    {
      "dimension": "quality",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "compute",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "latency",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "operations",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "compatibility",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "security",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "data_and_training",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    },
    {
      "dimension": "reproducibility",
      "basis": "not_evaluated",
      "finding": "",
      "interpretation": "",
      "limitation": "",
      "next_check": "",
      "source_url": "",
      "source_page": null,
      "source_excerpt": ""
    }
  ],
  "risks": [],
  "minimum_test": [],
  "open_questions": [],
  "independent_tests": [],
  "lab_reproductions": [],
  "report_available": false,
  "validation_tier": "unknown",
  "evidence_tier": "unknown",
  "infrastructure_basis": "unknown",
  "equations": [
    {
      "anchor": "S5.Ex4",
      "label": "",
      "section": "5 The Eight-Metric Characterization",
      "role": "metric",
      "latex": "\\text{device-wide compute SOL}=\\text{compute\\_sol\\_pct}\\cdot\\tfrac{\\text{SMs\\_reached}}{132}.",
      "mathml": "<math display=\"block\"><mrow><mrow><mtext>device-wide compute SOL</mtext><mo>=</mo><mrow><mtext>compute_sol_pct</mtext><mo lspace=\"0.222em\" rspace=\"0.222em\">⋅</mo><mstyle displaystyle=\"false\"><mfrac><mtext>SMs_reached</mtext><mn>132</mn></mfrac></mstyle></mrow></mrow><mo lspace=\"0em\">.</mo></mrow></math>",
      "context": "The per-active-SM and warp-pool metrics quantify how hard the SMs a kernel occupies are working, but not how much of the H100’s aggregate matmul capacity is exercised over the kernel’s wall-clock. To capture whole-device matmul throughput, we take NCU’s compute_sol_pct (the Compute (SM) Throughput SOL metric on the SMs the kernel reaches, §3) and scale it by spatial coverage to obtain device-wide compute SOL, a per-kernel analog of model-level MFU:",
      "headline": "",
      "explanation": "",
      "objective": "",
      "symbols": {},
      "evidence": "",
      "evidence_url": "",
      "source_url": ""
    },
    {
      "anchor": "S5.EGx1",
      "label": "",
      "section": "5 The Eight-Metric Characterization",
      "role": "metric",
      "latex": "R_{\\text{eff}} =\\lceil R/8\\rceil\\cdot 8, \\\\ \\eta_{\\text{reg}} =\\min\\!\\left(64,\\ W_{\\text{block}}\\cdot\\left\\lfloor\\tfrac{65536}{R_{\\text{eff}}\\cdot W_{\\text{block}}\\cdot 32}\\right\\rfloor\\right), \\\\ \\eta_{\\text{smem}} =\\min\\!\\left(64,\\ \\left\\lfloor\\tfrac{228\\cdot 1024}{S_{\\text{block}}}\\right\\rfloor\\cdot W_{\\text{block}}\\right),",
      "mathml": "<math display=\"block\"><mrow><msub><mi>R</mi><mtext>eff</mtext></msub><mrow><mrow><mphantom></mphantom><mo>=</mo><mrow><mrow><mo stretchy=\"false\">⌈</mo><mrow><mi>R</mi><mo>/</mo><mn>8</mn></mrow><mo rspace=\"0.055em\" stretchy=\"false\">⌉</mo></mrow><mo rspace=\"0.222em\">⋅</mo><mn>8</mn></mrow></mrow><mo>,</mo></mrow></mrow></math><math display=\"block\"><mrow><msub><mi>η</mi><mtext>reg</mtext></msub><mrow><mrow><mphantom></mphantom><mo>=</mo><mrow><mpadded width=\"1.653em\"><mi>min</mi></mpadded><mo>⁡</mo><mrow><mo>(</mo><mn>64</mn><mo rspace=\"0.667em\">,</mo><mrow><msub><mi>W</mi><mtext>block</mtext></msub><mo lspace=\"0.222em\" rspace=\"0.222em\">⋅</mo><mrow><mo>⌊</mo><mfrac><mn>65536</mn><mrow><msub><mi>R</mi><mtext>eff</mtext></msub><mo lspace=\"0.222em\" rspace=\"0.222em\">⋅</mo><msub><mi>W</mi><mtext>block</mtext></msub><mo lspace=\"0.222em\" rspace=\"0.222em\">⋅</mo><mn>32</mn></mrow></mfrac><mo>⌋</mo></mrow></mrow><mo>)</mo></mrow></mrow></mrow><mo>,</mo></mrow></mrow></math><math display=\"block\"><mrow><msub><mi>η</mi><mtext>smem</mtext></msub><mrow><mrow><mphantom></mphantom><mo>=</mo><mrow><mpadded width=\"1.653em\"><mi>min</mi></mpadded><mo>⁡</mo><mrow><mo>(</mo><mn>64</mn><mo rspace=\"0.667em\">,</mo><mrow><mrow><mo>⌊</mo><mfrac><mrow><mn>228</mn><mo lspace=\"0.222em\" rspace=\"0.222em\">⋅</mo><mn>1024</mn></mrow><msub><mi>S</mi><mtext>block</mtext></msub></mfrac><mo rspace=\"0.055em\">⌋</mo></mrow><mo rspace=\"0.222em\">⋅</mo><msub><mi>W</mi><mtext>block</mtext></msub></mrow><mo>)</mo></mrow></mrow></mrow><mo>,</mo></mrow></mrow></math>",
      "context": "Section 5.2 shows that the warp-pool cap is set by the kernel, not by the architecture. The two resources that most often bind are the register file and shared memory:",
      "headline": "",
      "explanation": "",
      "objective": "",
      "symbols": {},
      "evidence": "",
      "evidence_url": "",
      "source_url": ""
    }
  ],
  "equations_status": "selected",
  "core_kind": "formula",
  "equations_fetched_at": "2026-09-30",
  "equations_source_url": "",
  "equations_source_sha256": "",
  "exposures_reviewed_at": "",
  "exposures_source_sha256": ""
}