Walkthrough

This PR adds the Qwen3.6 35B-A3B NVFP4 model to the vLLM model registry, introduces per-model serve environment exports, updates platform-specific vLLM container images and defaults, adjusts Docker download/start invocations, and updates tests and docs to reflect the new Spark default.

Changes

Qwen3.6 35B-A3B NVFP4 Model Integration

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers:

• cv

🐰 A rabbit hops through the models with grace,
Adding Qwen's strength to the serving space,
Environments exported, containers aligned,
Platform defaults refined,
Tests passing, docs bright—the stage is set right! ✨

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: medium

Required E2E

• onboard-inference-smoke-e2e (low): This PR changes local inference onboarding behavior. This regression E2E verifies onboarding does not report success until the configured inference route can serve a real chat completion and surfaces actionable diagnostics on failure. It is the closest existing merge-blocking inference-onboard guard, though it does not exercise the managed vLLM container itself.

Optional E2E

• gpu-e2e (high): Useful live confidence for local GPU inference onboarding, sandbox reachability, and in-sandbox inference on a GPU runner. It uses Ollama rather than vLLM, so it is adjacent coverage only for this PR's managed-vLLM changes.
• inference-routing-e2e (medium): Validates gateway inference routing, credential isolation, and error classification around configured providers. It is useful because managed vLLM ultimately configures an inference route, but it does not validate the vLLM install/start command.
• docs-validation-e2e (low): Checks documentation and CLI/reference drift after updates to local inference and command environment-variable docs.

New E2E recommendations

• managed-vLLM DGX Spark install (high): No existing E2E appears to run NEMOCLAW_PROVIDER=install-vllm on a Spark-class host and verify the new nvidia/Qwen3.6-35B-A3B-NVFP4 default, upstream nightly image, hf download entrypoint, serve environment exports, vLLM readiness, /v1/models detection, and sandbox chat/completions through the configured local route.
  • Suggested test: Add a DGX Spark managed-vLLM E2E job that runs non-interactive onboarding with NEMOCLAW_PROVIDER=install-vllm, asserts the selected default model/image, waits for vLLM readiness, and sends a real OpenClaw chat completion through the sandbox.
• managed-vLLM profile matrix (medium): This PR intentionally diverges Spark from Station and generic Linux defaults. Existing unit tests cover profile selection, but there is no E2E that validates the profile-specific Docker image/model defaults on real or emulated hosts.
  • Suggested test: Add an E2E or scenario job that exercises managed-vLLM profile selection for Spark, Station, and generic NVIDIA Linux, at least in dry-run/plan mode with assertions for image, default model, Docker flags, and command line.

Dispatch hint

• Workflow: regression-e2e.yaml
• jobs input: onboard-inference-smoke-e2e

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. The behavioral changes are in the managed vLLM installer/model registry, but the current dispatchable scenario ROUTES table has no vLLM/install-vLLM scenario. Existing scenario routes cover cloud, OpenAI-compatible, Ollama GPU, platform, messaging, and lifecycle coverage, so no scenario E2E job would directly exercise this changed surface.

Optional scenario E2E

• None.

Relevant changed files

• src/lib/inference/vllm-models.ts
• src/lib/inference/vllm.ts

🛠️ Needs attention

• None.

🔎 Worth checking

• Digest-pin or verify the new Spark vLLM nightly image (src/lib/inference/vllm.ts:57): The DGX Spark managed-vLLM path now pulls Docker Hub image `vllm/vllm-openai:nightly-1fc2cee50a09a094b9f2bbdfcb0ab0cadb536712`. Docker tags are mutable, and this image is then run with GPU access, `--ipc=host`, a mounted Hugging Face cache, and vLLM `--trust-remote-code`. That makes the image reference an installer trust boundary for a high-risk inference/network path.
  • Recommendation: Use an immutable digest reference for the Spark image, or add an explicit image verification/update process and document why a mutable nightly tag is acceptable for this managed installer path.
  • Evidence: `UPSTREAM_VLLM_IMAGE` is a tag string at `src/lib/inference/vllm.ts:57`; `SPARK_PROFILE.image` uses it at line 119. The profile retains `--gpus all`, `--ipc=host`, and the HF cache mount, while shared vLLM args include `--trust-remote-code` in `src/lib/inference/vllm-models.ts`.
• Quote or validate registry values before composing the shell serve command (src/lib/inference/vllm-models.ts:253): `buildVllmServeCommand()` now prepends `serveEnv` as raw `export ${key}=${value}` fragments and then joins model ids and args into a command executed through `bash -lc`. The current registry values are code-controlled literals, so this is not a user-controlled injection path today, but it creates a fragile local trust boundary where a future model entry with shell metacharacters could alter the command inside a GPU-enabled container.
  • Recommendation: Validate `serveEnv` keys against a strict environment-variable-name pattern and shell-quote values, or build the container command from argv-safe components. Add a regression test with metacharacters to prove registry additions cannot accidentally change shell structure.
  • Evidence: `serveEnv` is rendered with `.map(([key, value]) => `export ${key}=${value}`)` at line 253, and the resulting command is passed to Docker via `--entrypoint /bin/bash ... -lc ${JSON.stringify(buildVllmServeCommand(model))}` in `src/lib/inference/vllm.ts:353`.
• Add runtime validation for the changed vLLM image and entrypoint behavior (src/lib/inference/vllm.ts:260): The tests assert profile selection and generated command strings, but the changed behavior depends on external image/runtime properties: the new upstream image must contain `hf` and `/bin/bash`, `--entrypoint hf ... download` must work for both the upstream and NGC images, and the Spark NVFP4 flags/env must boot to the ready marker on DGX Spark. This is an infrastructure path where string-level unit tests are not enough to catch image or entrypoint drift.
  • Recommendation: Add or reference targeted runtime validation for managed Spark vLLM startup, including the pre-download command and the `--entrypoint /bin/bash -lc` serve command. At minimum, add a unit-level test for the complete Docker argv/string composition and keep a DGX Spark smoke validation in the release checklist.
  • Evidence: New tests in `vllm-models.test.ts` and `detect-vllm-profile.test.ts` cover registry/profile strings. Runtime-sensitive changes are at `src/lib/inference/vllm.ts:260` (`--entrypoint hf`) and `src/lib/inference/vllm.ts:353` (`--entrypoint /bin/bash ... -lc`).

🌱 Nice ideas

• None.