# 竞赛对比分析 & 修复计划

## 一、核心数据对比

| 模块 | 对手 Sub168 | 我们 Sub508 | 差距 |
|------|-----------|-----------|------|
| **functional** | 48/52 PASS (92.3%) | 21/51 PASS (41.2%) | **-51%** |
| **case_truncation** | score=1.0 (8192 tokens输出完整) | score=0.0 (引擎崩溃) | **致命** |
| **replay_tencent** | score=60194 (94/881成功,tps avg 11.86) | score=0.0 (881/881 connection refused) | **致命** |
| **opencompass** | 0.0 (server也崩了) | 0.0 (同上) | 平 |
| **总分** | **60194.6** | **0.0** | -- |

## 二、Sub508 崩溃根因链

```
t2_n_2 (n=2请求) → get_scheduler_config() 异常 → 引擎进程死亡
→ 后续所有请求 Connection Refused → 30个FAIL级联
→ case_truncation/replay/opencompass 全部0分
```

**关键事实：t2_n_2 崩溃发生在 06:42:45，之后所有模块都是在引擎已死的情况下跑的。**

## 三、对手 Sub168 的弱点（我们已经修复的）

1. **`max_completion_tokens` 被拒** — 对手 `extra="forbid"` 导致 replay 中所有带此字段的请求返回 400。我们已添加该字段到 protocol.py，replay 中不会被拒。
2. **`tool_calls` content=None 被拒** — 对手的 replay preflight 失败（"Each message must have at least one of 'content' or 'reasoning_content'"）。我们已修复 chat_utils.py 中 content=None 的处理。
3. **d06_cache_hit FAIL** — 对手没有 prefix caching，我们 PASS。
4. **t3_max_tokens_1/64/max 3个FAIL** — 对手也有3个max_tokens测试失败。

**对手 replay 中 787/881 失败(89.3%)，只有 94 个成功。我们的目标是超越这个。**

## 四、我们需要修复的问题（按优先级排序）

### P0 — 引擎稳定性（决定能否拿分的前提）

| 问题 | 根因 | 修复位置 |
|------|------|----------|
| **t2_n_2 → 引擎崩溃级联** | `get_scheduler_config()` 异常 + n>1 未处理 | `qwen3_6_scripts/serving_chat.py` + `protocol.py` |
| **引擎OOM死亡** | 单个长请求耗尽GPU内存后整个进程死 | 需要在 worker/model_runner.py 加 OOM catch |

已有 commit 修复（994c657 clamp n>1, c241764 try-catch scheduler），但 **Sub508 用的是修复前的代码**。Sub509 日志确认 d01 能跑（95.85s），但 d03 仍然 FAIL。

### P1 — d03_tool_call FAIL（功能测试核心分）

**Sub508**: `tools=0 finish=stop reasoning[0]` (49.04s)
**Sub509**: `tools=0 finish=stop reasoning[0]` (49.04s)
**对手**: `tool=get_weather args="{'city': 'Beijing'}" finish=tool_calls` (2.12s)

**根因分析**：
- 对手 d03 只用了 2.12s，模型直接输出 tool_call XML，tool parser 正确解析
- 我们用了 49.04s，模型在 thinking 中耗尽了时间，没有产生 `<tool_call>` 标签
- commit e0344b1 说"禁用 tool_call 请求的 thinking"，但 Sub509 的 d03 仍显示 `reasoning[0]`
- **真正的问题**：当 `tool_choice=auto` 且有 tools 时，需要在 chat_template 中设置 `enable_thinking=False`，否则 Qwen3 会先 think 再输出，大量token浪费在思考上

**修复方案**：在 `serving_chat.py` 的 `create_chat_completion` 中，当检测到 `request.tools` 且 `tool_choice != "none"` 时，在 `chat_template_kwargs` 中注入 `enable_thinking=False`。

### P1 — d05_multimodal HTTP 400

对手 PASS (content[374])，我们 HTTP 400。
可能是多模态请求格式/图片解码问题。需要检查 chat_utils.py 的图片处理路径。

### P1 — d07_reasoning_plus_content

对手 PASS (reasoning[3489] content[962])，我们 FAIL (reasoning[131] content[0])。
模型 think 后不产生 content。这是模型行为问题，但可以通过调低 thinking budget 或调整 temperature 来缓解。

### P2 — t1a_thinking_true / t1c_thinking_default

对手 PASS (reasoning[541] / [411])，我们 FAIL (reasoning[0])。
**根因**：模型在短回答场景下不触发 thinking。可能需要在 chat_template 中确保 `enable_thinking=True` 是默认值。检查 Qwen3.6 的 chat_template 是否正确注入了 `<think>` 标签。

### P2 — d10_thinking_disable_ctk 乱码输出

对手输出 `'4'`（正确），我们输出乱码 `"presت< **sama一..."`。
模型在 thinking disabled 模式下输出质量极差。这是模型+chat_template 的交互问题。

### P3 — 速度差距

| 测试 | 对手 | 我们 | 倍数 |
|------|------|------|------|
| d01 | 8.49s | 95.85s | **11x慢** |
| d04 | 17.78s | 128.74s | **7x慢** |
| d03 | 2.12s | 49.04s | **23x慢** |

速度问题核心：BI-V100 硬件本身比 NVIDIA GPU 慢，但 10x 的差距说明还有架构问题。对手的 output_tps 平均 11.86，decode 阶段 tps 在 2.4-22.7 之间。

## 五、修复代码的具体文件

需要修改的文件（全部在 `qwen3_6_scripts/` 中，会被 patch_ops.sh 部署）：

1. **`serving_chat.py`** — tool_call 时注入 `enable_thinking=False`
2. **`protocol.py`** — 确认 `extra="forbid"` 已经去掉（已做），确认 `thinking` 字段被正确传递
3. **`chat_utils.py`** — 多模态请求处理、content=None 容错
4. **`model_runner.py`** — OOM recovery
5. **`qwen3_5.py`** — 检查模型是否正确处理 `enable_thinking` 参数
6. **`computility-run.yaml`** — 考虑调整 `--max-num-seqs` / `--gpu-memory-utilization`

## 六、对手的 replay 得分结构

对手 881 个请求中：
- 94 个成功 (10.7%)
- 77 个因 `max_completion_tokens` extra_forbidden 而 400
- 704 个 connection refused（server也崩了！）
- output_tps_avg = 11.86, output_tps_p50 = 12.97

**关键发现：对手的 server 也在 replay 后期崩溃了（704 个 connection refused）。但他在崩溃前完成了 94 个请求。**

我们的优势：
- 我们已修复 `max_completion_tokens` → 对手的 77 个 400 我们不会有
- 我们已修复 `tool_calls content=None` → 对手的 tool preflight fail 我们不会有
- 我们有 prefix caching → 对手没有

**如果我们能保持引擎稳定不崩溃，仅靠不拒绝 max_completion_tokens 的请求，就能多处理 77+ 个请求，超过对手。**

## 七、下一步行动

1. 修复 `serving_chat.py`：tool_call 时禁用 thinking
2. 确认 n>1 clamp 和 scheduler try-catch 在 patch 文件中生效
3. 测试 OOM 恢复逻辑
4. 调整 computility-run.yaml 参数确保稳定性
5. 提交部署，跑测试