[cognaiger9]

What

An open-loop variant of the LiveKit 111868 V1.1-warm scenario, so a voice-agent benchmark compares servers at the
same load. Today's lane replay starts a lane's next call the moment its previous call ends, and sends each turn the
logged gap after the previous reply ends: a faster server shortens every call and receives more calls per hour at
the same conc, which hides its latency gain.

Here conc = target mean concurrent calls, and calls arrive by the clock:

• scenarios/custom-agentic-livekit111868-v1.1-warm-openloop.yaml: aiperf fixed_schedule, 10 s client timeout,
  1980 s phase (120 s ramp + 1800 s scored + 60 s tail).
• utils/serving/livekit_openloop.py: rewrites the fetched V1.1-warm trace before aiperf runs. Calls open as a
  seeded Poisson process at conc / 127 s per second (127 s = the trace's mean call length at production reply
  speed), with a linear ramp; arrivals stop 60 s before the end. Each call keeps its logged gaps after the previous
  reply. Calls are reused once all 671 are used: replay k is <room>~k with a play<k> marker at the start of its
  first user message, so its own context is cold again while the shared system prompt still hits.
• benchmark_lib.sh / serve_generic.sh: *-openloop scenarios run the rewrite after the dataset fetch
  (openloop_trace), write openloop.json (arrivals, scoring window) to the run dir, and lift aiperf's session cap
  to 4 x conc (--concurrency caps open sessions in fixed_schedule mode, which would delay arrivals).
  Settings can be overridden from the serving YAML env: (IX_OPENLOOP_CALL_DURATION_S, _RAMP_S, _TAIL_S, _SEED).
• utils/serving/livekit_ttft.py: keeps only calls opened inside the scoring window, maps <room>~k to the plan,
  and adds TTFS (TTFT + 11 chunks) for 5 s turns.
• serving/gemma4-livekit-1gpu-v11-openloop.yaml: example, the 1-GPU prod vLLM arm (gemma4-livekit-1gpu-v1) at conc 8/16/32.
• Brought over from bench/gemma4-livekit-dyn-swa-arms (not yet on this branch): the V1.1-warm trace and plan lock
  entries, and utils/serving/livekit_ttft.py + its test. Merging that branch later will touch the same lines in
  lock.yaml and those two files.

Testing

• utils/test_serving_livekit_openloop.py (new): same seed gives the same trace; openings carry arrival times and
  later turns keep their gaps; replays are renamed and marked; arrival rate and scoring window; duration read from
  the scenario; openloop_trace rewrites the dataset and build_replay_cmd_yaml passes --concurrency 32 at conc 8.
• utils/test_serving_livekit_ttft.py: open-loop window, replayed call ids, TTFS line.
• test_serving_livekit_*, test_serving_replay, test_serving_to_matrix, test_serving_schema,
  test_serving_fetch_dataset: 160 pass; the 2 test_serving_schema runner-message failures are the same on
  vng-benchmark without this PR.
• The scenario resolves with the pinned aiperf (faf3f8b) as build_replay_cmd_yaml launches it: phase
  fixed_schedule, autoOffset, duration 1980, concurrency 4 x conc, endpoint timeout 10 s, sequential sampling.
• Same design run outside CI on hgx-h200-02 (two TP4 servers side by side); results to follow in a comment.
• Not yet run through e2e-tests.yml.

🤖 Generated with Claude Code

[github-actions]

Thanks for the contribution!

• Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
• PR verification: Sweeps only run on labeled PRs. Add full-sweep-fail-fast (strongly recommended); use full-sweep-enabled only when matrix jobs should continue after a failure.
• After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.

中文

感谢你的贡献！

• **审阅：**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER，请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，再通过 Slack 联系核心维护者。必须严格遵循模板，并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have，才能触发签核验证。
• **PR 验证：**扫描仅在带有标签的 PR 上运行。强烈建议添加 full-sweep-fail-fast；仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled。
• **合并后：**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复；参见重新运行失败任务的说明。