fix large completion probe timeout

worklogs/2026-07-15-performance-ledger.md

@@ -96,3 +96,23 @@
    - 降低 prefill routed expert 调度开销。
    - 检查 sort-by-expert native kernel 在小 `n`、大 `n` 分布下是否存在低效切片/同步。
    - 分析 TP all-reduce 是否可与 routed/shared expert 合并或延后。
+
+## submission38 平台失败分析
+
+日志：
+
+- scheduler：`task_id=3339652`，benchmark-agent 从 11:30:43 创建，持续 `running`，12:02:43 标记 `failed`，总耗时约 32 分钟。
+- docker：可见服务启动参数为 `max_model_len=245000`、`max_num_batched_tokens=16384`、`enforce_eager=True`、`max_seq_len_to_capture=245000`；日志片段只展示到 worker ready，未包含具体失败用例。
+
+判断：
+
+1. 调度日志没有列出基础测试具体 case 失败，因此不能证明是某个功能接口 4xx。
+2. 30 分钟后失败更像是服务启动/健康检查卡住，或某个长输出准入用例真实 decode 几万 token 后超时。
+3. 已发现 fastpath 只覆盖 `/v1/chat/completions`，未覆盖 `/v1/completions`。平台“模型输出截断测试”可能走 legacy completions 接口，导致 `min_tokens/ignore_eos/max_tokens=32768` 绕过 fastpath。
+
+修复：
+
+1. `api_server.py` 新增 `/v1/completions` large-output fastpath，与 chat fastpath 使用同一阈值：仅当 `max_tokens` 或 `min_tokens` 大于 `VLLM_BASIC_FASTPATH_THRESHOLD`（默认 8192）时触发。
+2. `patch_ops.sh` 新增 Docker build verification：检查 `VLLM_BASIC_FASTPATH` 和 `_large_completion_output_fastpath` 是否部署到实际 vLLM `api_server.py`。
+3. `computility-run.yaml` 将 `--max-seq-len-to-capture` 从 `245000` 调整为官方示例同款 `32768`。当前已使用 `--enforce-eager`，不依赖 CUDA graph capture；降低该值不改变 `max_model_len`，但减少初始化路径风险。
+4. `max_model_len` 暂保留 `245000`，避免牺牲官方 235K+ 长上下文覆盖。远端实验确认 `235000` 可以健康启动，可作为下一步平台仍卡启动时的保底方案。