Skip to content

ci: add vLLM GPU hello-world smoke (T4 / Qwen3-0.6B) - #640

Draft
skamenan7 wants to merge 3 commits into
mainfrom
feat/541-vllm-gpu-smoke
Draft

ci: add vLLM GPU hello-world smoke (T4 / Qwen3-0.6B)#640
skamenan7 wants to merge 3 commits into
mainfrom
feat/541-vllm-gpu-smoke

Conversation

@skamenan7

Copy link
Copy Markdown

Summary

  • Adds a workflow_dispatch GPU smoke workflow for Praxis issue Add vLLM integration tests on GPU and expand CPU coverage #541
  • Runs the existing test_stateless_request HELLO-PRAXIS check against CUDA vLLM (Qwen/Qwen3-0.6B, max 4096 tokens)
  • Defaults to Ken’s offered gpu-t4-4-core larger-runner label; runner label is overridable
  • Avoids the OGX ec2-github-runner / personal-PAT pattern

Test plan

  • Confirm gpu-t4-4-core (or equivalent) exists on praxis-proxy
  • Actions → vLLM GPU Smoke → Run workflow
  • Job shows nvidia-smi, vLLM becomes healthy, test_stateless_request passes
  • Failure path uploads vLLM/OGX logs

@skamenan7
skamenan7 requested review from a team and leseb July 31, 2026 19:36
@praxis-bot-app

Copy link
Copy Markdown

Unsigned commits: ffbecfa. Please sign your commits.

@praxis-bot-app

Copy link
Copy Markdown

Missing Signed-off-by: ffbecfa. All commits require sign-off (via git commit --signoff).

@skamenan7

Copy link
Copy Markdown
Author

Dispatched vLLM GPU Smoke on this branch (runner=gpu-t4-4-core).

The job stayed queued with no runner picked up, so praxis-proxy does not appear to have a gpu-t4-4-core larger-runner yet (Ken offered that shape from another org).

Once that runner exists on this org (or we get the exact label), re-run:
Actions → vLLM GPU Smokegpu-t4-4-core (or override).

Smoke itself is the existing test_stateless_request / HELLO-PRAXIS check against CUDA vLLM Qwen/Qwen3-0.6B.

@skamenan7
skamenan7 force-pushed the feat/541-vllm-gpu-smoke branch 2 times, most recently from d1d6ee2 to bbfccbd Compare July 31, 2026 19:45
@skamenan7 skamenan7 closed this Jul 31, 2026
@skamenan7
skamenan7 force-pushed the feat/541-vllm-gpu-smoke branch from bbfccbd to fe8ecee Compare July 31, 2026 19:45
@skamenan7 skamenan7 reopened this Jul 31, 2026
@skamenan7
skamenan7 marked this pull request as draft July 31, 2026 19:55
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>
@skamenan7
skamenan7 force-pushed the feat/541-vllm-gpu-smoke branch from 8e3df81 to 27f2e6c Compare July 31, 2026 20:04
@nathan-weinberg
nathan-weinberg self-requested a review August 3, 2026 14:36

@praxis-bot praxis-bot left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread .github/workflows/vllm-gpu-smoke.yaml Outdated
# Does not use the OGX ec2-github-runner / personal-PAT pattern.

on:
workflow_dispatch:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

@nathan-weinberg nathan-weinberg Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A PoC for this idea can be found here: https://github.com/praxis-proxy/ai/tree/vllm-gpu

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea, once this merges.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened an issue to track and assigned myself: #692

Comment thread .github/workflows/vllm-gpu-smoke.yaml
Comment thread .github/workflows/vllm-gpu-smoke.yaml Outdated

@praxis-bot praxis-bot left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 &

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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 leseb left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use a more capable model?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps Qwen/Qwen3.5-9B?

--reasoning-parser deepseek_r1 \
--gpu-memory-utilization 0.7

- name: Start OGX

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?


env:
CARGO_TERM_COLOR: always
VLLM_IMAGE: "docker.io/vllm/vllm-openai:v0.22.1-cu129@sha256:e1668bce9790a4b86682f8fcc99678153a13e12dc70e05348d8e239ffa474b05"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea, once this merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants