Two optimizations that target the real bottlenecks:
1. patch_enable_triton.py: Enable Triton Flash Attention for prefill
- Sets HAS_TRITON = True (was hardcoded False)
- Adds try/except wrapper in forward_prefix: tries Triton kernel first,
permanently falls back to PyTorch if it hangs or errors
- Combined with patch_triton_tuning.py (BLOCK=64, NUM_WARPS=4),
this keeps SMEM at 32KB ≤ 48KB limit
- If Triton works: 10-50x prefill speedup (GPU-parallel Flash Attention
vs Python for-loop)
- If Triton still hangs: auto-fallback, no worse than baseline
2. patch_vectorized_decode.py: Raise _PYTORCH_DECODE_THRESHOLD 32768 → 65536
- Compiled ixf_F.paged_attention_v1 is ~100x faster than Python fallback
- Baseline conservatively falls back at 32K, may work fine at 64K
- If v1 crashes at higher seq_lens, threshold can be lowered back
Why these matter (competition scoring):
Token吞吐加权值 = Output TPS × 16.796 + Input TPS × 2.799 + Cache TPS × 0.56
Prefill (Input TPS, 14% weight): _forward_prefix_pytorch is a Python
for-loop doing matmul+softmax per tile. Triton kernel does this in a
single GPU launch with Flash Attention online softmax.
Decode (Output TPS, 83% weight): Every seq_len between 32K-65K that
stays on compiled v1 instead of falling to Python saves ~100x per token.
Deploy order in Dockerfile:
1. patch_ops.sh (baseline functional patches)
2. patch_triton_tuning.py (BLOCK=64, NUM_WARPS=4)
3. patch_enable_triton.py (HAS_TRITON=True + try/fallback)
4. patch_vectorized_decode.py (threshold 32K → 64K)
