Exp/remote deepseek coder v2 lite fp8#13
Conversation
Point the remote multi-endpoint smoke config's image: at the pre-built aiperf:0.8.0 image instead of the vLLM serving image, so the client skips the per-job pip install. install_agentic_deps now short-circuits when aiperf is already on PATH, and the endpoint pre-check falls back to busybox wget when curl is unavailable (the distroless image ships wget but not curl). Also narrow the smoke config's conc-list to [2, 4]. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The pre-built full AIPerf image (aiperf:0.8.0) is distroless and runs as non-root UID 1000, so it could not create /workspace/results in the bind-mounted workspace owned by the runner user (mkdir: Permission denied). The old vllm serving image masked this by running as root. Map the container to the host runner's uid/gid and point HOME at the writable workspace so mkdir/results writes succeed and result files stay runner-owned for the upload/cleanup steps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The pre-built full AIPerf image is distroless and ships busybox timeout, which rejects GNU long options: `timeout: unrecognized option '--signal=TERM'`. As a result timeout exited immediately, aiperf never ran, and process_agentic_result.py failed with "profile_export.jsonl not found". Switch to the short flags `-s TERM -k 60`, accepted by both busybox and GNU timeout, so the remote-replay path works on the full image and the pip-install path alike. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers. If additional help is needed, PR authors can reach out to core maintainers over Slack. |
1 participant
No description provided.