Back to Prompt Library
implementation
Build the application
Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.
Linked challenge: Build a Local Open-Weight Triton Kernel Latency and Memory Auditor
Format
Code-aware
Lines
69
Sections
11
Linked challenge
Build a Local Open-Weight Triton Kernel Latency and Memory Auditor
Prompt source
Original prompt text with formatting preserved for inspection.
69 lines
11 sections
No variables
1 code block
## Build
Benchmark custom open-weight attention and GEMM Triton kernels against baseline implementations on local GPUs. Quantify execution time, register pressure, and SRAM efficiency before serving deployment.
## User
Hardware Kernel Optimization Engineer
## Workflow
1. Ingest profiling trace outputs from local Triton kernel compilation and execution benchmarks.
2. Extract kernel execution times, shared memory allocations, and register spill counts.
3. Compare candidate fused kernels against standard unquantized PyTorch baseline operations.
4. Use hosted Claude API to synthesize kernel tuning recommendations and block size heuristics.
## Interface
Kernel benchmark comparator dashboard with memory footprint graphs and tuning report export.
## Data
Create normalized synthetic benchmark tables representing Triton attention kernel runs across varying tile sizes.
Starter examples below are synthetic. They are not downloaded records.
## Source
[vLLM open-model serving](https://raw.githubusercontent.com/vllm-project/vllm/main/README.md)
Incorporate vLLM optimized attention and GEMM kernel execution references using Triton and CUTLASS.
## Tools
mlflow, anthropic, pandas.
mlflow tracks kernel benchmark metrics, artifacts, and parameter permutations across hardware runs.
Hosted Claude API accessed over HTTPS for code commentary; kernel execution applies strictly to local open code.
## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.
## Acceptance
- Calculates percentage speedup or regression of candidate kernels over baseline operations.
- Identifies register spilling into local memory that causes memory stall cycles.
- Generates structured tuning recommendations for optimal tile and warp dimensions.
## Starter Examples
```json
[
{
"input": {
"kernel_name": "fused_fp8_gemm",
"block_m": 64,
"block_n": 64,
"registers_per_thread": 142,
"spill_stores_bytes": 2048,
"latency_us": 48.2,
"baseline_us": 35.1
},
"expected_output": {
"status": "REGRESSION",
"spill_detected": true,
"speedup_ratio": 0.73,
"recommendation": "reduce_tile_size_to_32x64_to_relieve_register_pressure"
}
},
{
"input": {
"kernel_name": "fused_fp8_gemm",
"block_m": 32,
"block_n": 64,
"registers_per_thread": 96,
"spill_stores_bytes": 0,
"latency_us": 22.4,
"baseline_us": 35.1
},
"expected_output": {
"status": "IMPROVED",
"spill_detected": false,
"speedup_ratio": 1.57,
"recommendation": "adopt_configuration_for_production_profile"
}
}
]
```
## Safety
Benchmarks open-source Triton code in isolated local user environments without accessing closed server systems.
Use mock external writes. Require human review before any real deployment.Adaptation plan
Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.
Keep stable
Hold the task contract and output shape stable so generated implementations remain comparable.
Tune next
Update libraries, interfaces, and environment assumptions to match the stack you actually run.
Verify after
Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.