2 Commits

Author SHA1 Message Date
Claude
cdc01bbc6a fix: critical config + tuning corrections from CCCL source analysis
computility-run.yaml:
  max-num-seqs 1→256: benchmark sweeps [128,256] concurrent seqs,
    current config processes 1 while 127 queue. KV cache budget:
    256 seqs × 2048 tokens × 80KB/token = 41.9GB < 45GB available.
  max-num-batched-tokens 8192→32768: support 256 concurrent prefills.
  gpu-memory-utilization 0.9→0.95: provide KV cache headroom.

Dockerfile:
  Deploy paged_attention_v2_triton.py to vllm package path so
  try-triton-first logic in _custom_ops.py can find it. Falls back
  to PyTorch V2 automatically if Triton V2 fails (SMEM/runtime).

muh/tuning/common.cuh:
  scale_mem_bound max_smem now a parameter (default 48KB). Allows
  policy_selectors to pass hw.max_shared_memory_per_block if actual
  SMEM differs from CCCL 48KB assumption.

muh/tuning/tuning_transform.cuh:
  bytes_in_flight 16KB→32KB. Old derivation used 900/50=18 GB/s/SM
  (wrong, SM=16 confirmed). Actual per-SM BW = 56 GB/s.
  32KB is estimate pending benchmark sweep.

SM count 50→16 corrections across all affected files.
2026-08-03 06:45:54 +00:00
Claude
4463e9ccee [OPT] BI-V100 Triton kernel tuning + computility-run.yaml optimization
After reading the full baseline (enginex-vllm-bi100-qwen36-main.zip):

KEY DISCOVERY: The competition optimization surface is Python/Triton,
not C++ CUDA. There is no csrc/ directory. All CUDA kernels are
precompiled in vllm._C and ixformer .so files. The muh C++ headers
have no injection point in this competition framework.

What CAN be optimized:

1. Triton kernel parameters (prefix_prefill.py):
   - BLOCK: stays at 64 (correct — BLOCK_N=128 overflows 48KB SMEM
     at head_dim=128: 128×128×2×2=64KB > 48KB)
   - NUM_WARPS: 8 → 4 (derived from occupancy analysis:
     at 8 warps + 32KB SMEM/block, only 1 block fits per SM;
     at 4 warps, potentially 2 blocks per SM = 2× occupancy;
     BI-V100 is bandwidth-limited (900GB/s), so more blocks
     hiding bandwidth latency matters more than more warps
     hiding instruction latency)

2. computility-run.yaml:
   - max-num-batched-tokens: 8192 → 16384 (larger prefill chunks
     reduce kernel launch overhead; with max-num-seqs=1, SMEM
     pressure is determined by BLOCK, not batch token count)
   - gpu-memory-utilization: 0.9 → 0.95 (model uses ~17.5GB/GPU,
     KV cache for 100K tokens ≈ 1.38GB, plenty of headroom)

3. Added Dockerfile with patch_triton_tuning.py step.

4. Analysis document in optimizations/prefix_prefill_patch.py
   with full SMEM/register/occupancy derivation.
2026-07-30 15:33:44 +00:00