From 96f64650cf1adf7326b935da8ec3fe1c39d4e412 Mon Sep 17 00:00:00 2001
From: muh-bot <muh@project6.dev>
Date: Wed, 5 Aug 2026 07:47:07 +0000
Subject: [PATCH] =?UTF-8?q?[CRITICAL]=20yaml=20=E6=81=A2=E5=A4=8D=E5=88=B0?=
 =?UTF-8?q?=E5=9F=BA=E7=A1=80=E5=BC=95=E6=93=8E=E5=8E=9F=E7=89=88=E2=80=94?=
 =?UTF-8?q?=E2=80=94=E5=85=88=E9=80=9A=E8=BF=87=E5=8A=9F=E8=83=BD=E6=B5=8B?=
 =?UTF-8?q?=E8=AF=95=E5=86=8D=E4=BC=98=E5=8C=96=E6=80=A7=E8=83=BD?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

变更:
  --max-num-seqs 8→1 (基础引擎原版值)
  --num-scheduler-steps 16→删除 (默认1)
  --preemption-mode recompute→删除 (默认)
  TRITON_CACHE_DIR/TRITON_PRINT_AUTOTUNING→删除

为什么 num-scheduler-steps=16 可能导致功能测试 fail:
  1. 流式 SSE: 16 步才 flush → delta 粒度不对
  2. stop 序列: 第 3 步出现 stop 但 scheduler 已安排 16 步 → 多生成 token
  3. tool calling: <tool_call> tag 跨越 multi-step 边界 → parser 看到不完整 tag
  4. reasoning: </think> tag 同理

为什么 max-num-seqs=8 可能导致功能测试 fail:
  1. GQA head_mapping 在多序列下可能出错
  2. 多序列下 prefix_cache_hit 的 block_tables 可能交叉
  3. BI-V100 16 SMs 上 8 个并发序列可能导致 OOM

竞赛目标: 首个通过全部功能+效果+性能达标 → 基础奖
策略: 先用最保守配置通过功能测试, 再逐个放开性能参数

CCCL 启示 (dot_products_with_zip.cu): SoA vs AoS 的选择不影响正确性,
只影响性能。先保证正确性 (AoS/保守配置), 再优化性能 (SoA/激进配置)。
---
 computility-run.yaml | 32 +-------------------------------
 1 file changed, 1 insertion(+), 31 deletions(-)

diff --git a/computility-run.yaml b/computility-run.yaml
index 8d71490a..6447abd0 100644
--- a/computility-run.yaml
+++ b/computility-run.yaml
@@ -15,7 +15,7 @@ command:
     - -tp
     - '4'
     - --max-num-seqs
-    - '8'
+    - '1'
     - --disable-log-requests
     - --disable-frontend-multiprocessing
     - --max-num-batched-tokens
@@ -29,36 +29,6 @@ command:
     - --reasoning-parser
     - qwen3
     - --enable-prefix-caching
-    # CCCL-derived optimizations:
-    # Multi-step scheduling reduces Python dispatch overhead per decode iteration.
-    # With max-num-seqs=8 and 4 GPUs, each step processes 8 tokens across 4 devices.
-    #
-    # CCCL single_pass_scan_operators.cuh reveals: for gridDim.x < 500 (our case:
-    # 16 SMs → ~32 CTAs), all delay strategies collapse to __threadfence_block().
-    # This means inter-CTA synchronization cost is near-zero on BI-V100.
-    # The dominant per-step overhead is Python scheduler dispatch (~100μs/step).
-    # num-scheduler-steps=16 batches 16 decode iterations per Python call,
-    # cutting scheduler overhead by ~16x vs default. Pure win for Output TPS (83%).
-    #
-    # Source: cccl_upstream/cub/cub/agent/single_pass_scan_operators.cuh line 180
-    #   if (gridDim.x < GridThreshold) __threadfence_block(); // no real delay
-    - --num-scheduler-steps
-    - '16'
-    # Recompute is cheaper than swap on BI-V100 (limited HBM bandwidth for swap).
-    # When a sequence is preempted, recomputing the prefix is faster than
-    # swapping KV blocks to/from CPU memory over PCIe.
-    - --preemption-mode
-    - recompute
 env:
     - name: VLLM_ENGINE_ITERATION_TIMEOUT_S
       value: 3600
-    # Cache Triton JIT compilations across restarts.
-    # Competition platform rebuilds the container each run — prewarmed cache
-    # saves 30-60s of first-request latency.
-    - name: TRITON_CACHE_DIR
-      value: /tmp/triton_cache
-    # Disable Triton autotuning at runtime (use hardcoded CCCL-derived configs).
-    # Autotuning wastes 5-10s per kernel on first call and the BI-V100 optimal
-    # configs are already baked into prefix_prefill.py and paged_attention_v2_triton.py.
-    - name: TRITON_PRINT_AUTOTUNING
-      value: '0'