vllm-ascend-workspace: Skill for Claude Code

vLLM Ascend Serving

Manage the lifecycle of a single-node colocated vllm-ascend online service on an isolated VAWS session container.

The optional prepared-runtime MCP has a separate binding/execution lifecycle. Its bindings are not legacy session records and must not be fed to serve_start.py --session-id. In that mode use the coordinator's request/preflight/activate/heartbeat/release sequence and existing remote-dev job tools, with pinned source, declared service ports and a new service process. The legacy wrappers here are not yet transparent adapters for pool bindings. Do not allocate a second local NPU lease for the pool run.

Remote substrate rule: use .remote-dev remote tools for ad hoc remote read/edit/bash/search/patch work around a service. Use this skill for the domain service lifecycle contract and keep its scripts as the compatibility backend for managed VAWS sessions.

This skill takes structured parameters, handles all SSH escaping and remote execution internally, and returns machine-readable JSON. The agent never needs to construct raw shell commands for service management.

Use this skill when

• the user asks to start / launch / pull up a vllm-ascend service in a managed session
• the user asks to restart or relaunch a service (possibly with changed flags or env)
• the user asks to check if a running service is alive / ready
• the user asks to stop a running service
• another skill needs to start a service (e.g. ascend-memory-profiling)

Do not use this skill when

• the task is adding, verifying, repairing, or removing a machine (use machine-management)
• the task is syncing code to the remote container (use remote-code-parity)
• the task is running benchmarks (a separate skill's responsibility)
• the task is offline inference
• no session exists yet for the target (use session-management first)

Critical rules

• Serving is session-only. serve_start.py, serve_status.py, and serve_stop.py take an optional --session-id <id> / --session-file <path>. When both are omitted, the session is auto-resolved by walking up from the current working directory to the nearest .vaws-local/current-session.json worktree binding — running from inside a session worktree needs zero target arguments. If no binding is found, the command fails fast with instructions to pass --session-id or create a session with session-management's session_create.py.
• start automatically runs remote-code-parity before launching. If parity fails, start is blocked.
• status and stop do not require parity.
• Each session reads and writes only .vaws-local/sessions/<id>/serving.json and never stops another session's service.
• start / stop operations for the same session are serialized with a serving lock; different sessions remain independent.
• Once a remote PID is launched, serve_start.py writes serving.json with status=starting before health probing so serve_stop.py can clean up even if readiness later fails.
• Service ports are always allocated and released through the session lease mechanism — there is no ad-hoc free-port scanning.
• Managed serving and relaunch require a nonempty live NPU lease matching the session snapshot before touching an existing service. Free cards are never selected as a fallback for an empty lease, and a stale session.json is not trusted after its live lease was released.
• All remote execution goes through the scripts — never construct raw SSH commands for serving.
• Keep local runtime state under .vaws-local/sessions/<id>/.
• Progress on stderr as __VAWS_SERVING_PROGRESS__=<json>, final result on stdout as JSON.
• With a unified workspace alias, new runtime directories use .vaws-runtime/serving/<alias>/<timestamp>/ and the service receives VAWS_AGENT_ID, VAWS_AGENT_ALIAS, and VAWS_PROJECT_ALIAS. Without an alias, preserve the legacy layout.