ci: add vLLM GPU hello-world smoke (T4 / Qwen3-0.6B) - #640
Conversation
|
Unsigned commits: ffbecfa. Please sign your commits. |
|
Missing Signed-off-by: ffbecfa. All commits require sign-off (via |
|
Dispatched vLLM GPU Smoke on this branch ( The job stayed queued with no runner picked up, so Once that runner exists on this org (or we get the exact label), re-run: Smoke itself is the existing |
d1d6ee2 to
bbfccbd
Compare
bbfccbd to
fe8ecee
Compare
Wire a workflow_dispatch job for Qwen/Qwen3-0.6B that runs the existing stateless HELLO-PRAXIS responses check on gpu-t4-4-core (or an override label), without cloning the OGX ec2-github-runner PAT pattern. Signed-off-by: Sumanth Kamenani <skamenan@redhat.com>
8e3df81 to
27f2e6c
Compare
praxis-bot
left a comment
There was a problem hiding this comment.
Review: vLLM GPU Smoke Workflow
Clean workflow with good security practices throughout: minimal permissions, SHA-pinned actions with version comments, digest-pinned container image, proper cleanup, and failure log collection. The workflow_dispatch-only trigger is appropriate for manual GPU testing. The step ordering efficiently parallelizes the Rust build with vLLM model loading.
Consistent with the existing vllm-integration.yaml patterns.
| Severity | Count |
|---|---|
| Critical | 0 |
| Large | 0 |
| Medium | 1 |
Reviewed by praxis-bot
| # Does not use the OGX ec2-github-runner / personal-PAT pattern. | ||
|
|
||
| on: | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Is this just for testing? Presume we will want to also run this on a schedule/PRs/etc.
|
|
||
| env: | ||
| CARGO_TERM_COLOR: always | ||
| VLLM_IMAGE: "docker.io/vllm/vllm-openai:v0.22.1-cu129@sha256:e1668bce9790a4b86682f8fcc99678153a13e12dc70e05348d8e239ffa474b05" |
There was a problem hiding this comment.
@leseb @franciscojavierarceo hey guys, @skamenan7 and I were talking and wanted to loop y'all in on an idea
For the OGX distro, we have automation in place in the repo for building and pushing our own vLLM CPU images with baked-in models, including Dependabot configurations for automatically updating the vLLM base image via a PR. This prevents us from being reliant on HuggingFace credentials/uptime for our testing.
I could replicate those workflows here or in another repo somewhere in Praxis if we were interested in using the same strategy for the testing here, but with CUDA-based GPU images rather than CPU
Let me know your thoughts - if y'all agree I can open a new tracker issue and assign myself for this work - it shouldn't be a heavy lift
There was a problem hiding this comment.
A PoC for this idea can be found here: https://github.com/praxis-proxy/ai/tree/vllm-gpu
There was a problem hiding this comment.
That's a good idea, once this merges.
There was a problem hiding this comment.
Opened an issue to track and assigned myself: #692
Signed-off-by: Sumanth Kamenani <skamenan@redhat.com>
praxis-bot
left a comment
There was a problem hiding this comment.
Review: vLLM GPU Smoke Workflow (round 2)
The Docker/Podman consolidation from the previous review is properly incorporated. The workflow is well-structured: SHA-pinned actions, digest-pinned container image, minimal permissions, proper if: always() cleanup, and good parallelization of service startup with the Rust build.
One remaining item:
| Severity | Count |
|---|---|
| Critical | 0 |
| Large | 0 |
| Medium | 1 |
Reviewed by praxis-bot
|
|
||
| - name: Start OGX | ||
| run: | | ||
| uv run --with 'ogx[starter]' ogx run starter --insecure > /tmp/ogx.log 2>&1 & |
There was a problem hiding this comment.
[Medium] ogx[starter] is not version-pinned. A breaking OGX release will fail this workflow with no corresponding diff to bisect.
Pin to the version you're currently testing against:
uv run --with 'ogx[starter]==<version>' ogx run starter --insecure > /tmp/ogx.log 2>&1 &The existing vllm-integration.yaml has the same gap, but a new workflow shouldn't carry it forward.
leseb
left a comment
There was a problem hiding this comment.
A few thoughts:
- We should use a more capable model, otherwise the value is low
- We need to use this instance with the existing vLLM integration test
| env: | ||
| CARGO_TERM_COLOR: always | ||
| VLLM_IMAGE: "docker.io/vllm/vllm-openai:v0.22.1-cu129@sha256:e1668bce9790a4b86682f8fcc99678153a13e12dc70e05348d8e239ffa474b05" | ||
| VLLM_MODEL: "Qwen/Qwen3-0.6B" |
There was a problem hiding this comment.
Can't we use a more capable model?
| --reasoning-parser deepseek_r1 \ | ||
| --gpu-memory-utilization 0.7 | ||
|
|
||
| - name: Start OGX |
|
|
||
| env: | ||
| CARGO_TERM_COLOR: always | ||
| VLLM_IMAGE: "docker.io/vllm/vllm-openai:v0.22.1-cu129@sha256:e1668bce9790a4b86682f8fcc99678153a13e12dc70e05348d8e239ffa474b05" |
There was a problem hiding this comment.
That's a good idea, once this merges.
Summary
workflow_dispatchGPU smoke workflow for Praxis issue Add vLLM integration tests on GPU and expand CPU coverage #541test_stateless_requestHELLO-PRAXIS check against CUDA vLLM (Qwen/Qwen3-0.6B, max 4096 tokens)gpu-t4-4-corelarger-runner label; runner label is overridableec2-github-runner/ personal-PAT patternTest plan
gpu-t4-4-core(or equivalent) exists onpraxis-proxynvidia-smi, vLLM becomes healthy,test_stateless_requestpasses