# 2026-07-15 平台基础测试失败修复记录

## 现象

提交 29 已成功构建镜像，但 benchmark-agent 任务运行约 38 分钟后失败。用户补充的完整页面日志仍不是完整 docker 文件尾部，而是平台 UI 中截取的 docker 日志片段；片段里没有逐条功能测试失败项，但出现大量 `[PROF]` 逐层 profiling 输出。

调度日志中的实际启动命令缺少 `--enforce-eager`，而本地当前 `computility-run.yaml` 已包含该参数，说明当次平台提交没有使用到本地最新配置，或提交时该修复尚未推送到官方仓库。

## 判断

当前失败首先不是性能问题，而是基础准入阶段的稳定性/兼容性问题：

1. 平台实际启动未带 `--enforce-eager`，245K 上下文下可能走 CUDA Graph 路径，BI-V100 上容易 OOM、卡住或初始化不稳定。
2. docker 日志中出现大量 `[PROF]`，说明当次镜像包含默认开启的代码级 profiling，严重拖慢请求并放大日志。
3. 官方基础测试会覆盖更宽的 OpenAI 兼容面，当前裸 vLLM 风格接口对 `tool_choice="required"`、多模态 content blocks、`n=2` 等请求存在 4xx 或调度死锁风险。

## 本次修改

1. `computility-run.yaml`
   - 保留并确认 `--enforce-eager`。
   - 显式加入 `PROF_TRACE=0`、`PROF_MOE_SUMMARY=0`，防止平台镜像误开 profiling。
   - 显式加入 `MOE_DECODE_NATIVE=0`，关闭尚未稳定收益的 decode native 实验路径。

2. `qwen3_6_scripts/protocol.py`
   - 将 `tool_choice="required"` 归一化为首个工具的强制 named tool choice。
   - 允许 assistant 消息 `content=null` 且带 `tool_calls`，避免历史工具调用消息 4xx。
   - 将 OpenAI multimodal content blocks 中的图片/视频剥离为文本占位，避免文本模型加载多模态数据失败；保留文本片段。

3. `qwen3_6_scripts/serving_chat.py`
   - 当 `n > max_num_seqs` 时不再返回 400，而是降级为 `n=max_num_seqs`，避免官方 `n=2` 采样测试失败或调度死锁。

4. `qwen3_6_scripts/chat_template_multi_system.jinja`
   - 历史 assistant tool_calls 的 `arguments` 同时兼容 dict 和 JSON string，避免多轮工具调用模板渲染失败。

## 本地验证

使用 AST 解析检查了核心 Python 文件：

- `qwen3_6_scripts/protocol.py`
- `qwen3_6_scripts/serving_chat.py`
- `qwen3_6_scripts/qwen3_5.py`

结果均为 `AST OK`。

`python -m py_compile` 在 Windows 本地因 `qwen3_6_scripts/__pycache__` 目录权限拒绝失败，非语法错误。

## 下一步

1. 提交并推送该版本到官方仓库，确保平台实际启动命令中出现 `--enforce-eager` 和 `PROF_TRACE=0`。
2. 在远端用基础冒烟脚本验证：
   - non-stream chat
   - stream + usage
   - tool call / required tool choice
   - reasoning on/off/default
   - base64 image content
   - prefix cache usage
   - `n=2` 状态码
   - JSON object/schema
3. 重新提交平台评测，若仍失败，需要导出完整 docker 日志尾部定位具体功能项。