Skip to content

serving-llms-on-instinct: fix Docker check, apply model_overrides, check free VRAM - #284

Open
sabira-shaik wants to merge 1 commit into
amd:mainfrom
sabira-shaik:fix/serving-instinct-validate-overrides-free-vram
Open

sabira-shaik wants to merge 1 commit into
amd:mainfrom
sabira-shaik:fix/serving-instinct-validate-overrides-free-vram

Conversation

@sabira-shaik

Copy link
Copy Markdown

Summary

Three fixes to serving-llms-on-instinct, found while testing the skill on an MI300X.

1. Docker check never fails (scripts/validate.py)

docker ps -q 2>&1 | head -1 returns head's exit code (always 0), and 2>&1 moves Docker's error into stdout, so validate.py reported ready: true with Docker unreachable. It now runs plain docker ps -q.

$ DOCKER_HOST=unix:///nope docker ps -q 2>&1 | head -1; echo "exit=$?"
failed to connect to the docker API at unix:///nope ...
exit=0
$ DOCKER_HOST=unix:///nope docker ps -q; echo "exit=$?"
failed to connect to the docker API at unix:///nope ...
exit=1

2. gfx950 gpt-oss override never applied (SKILL.md)

data/gpu_overrides.json sets VLLM_ROCM_USE_AITER_MOE=0 for openai/gpt-oss on gfx950 (the AITER MoE path corrupts its output), but SKILL.md never mentions model_overrides, so the agent never applies it. Step 4 now merges model_overrides[].env_set when the model ID matches.

3. Fit check ignores memory already in use (scripts/estimate_vram.py, SKILL.md)

The fit check assumed the whole GPU was free. vLLM's --gpu-memory-utilization is a fraction of total VRAM and vLLM refuses to start if that much is not free, so with another vLLM container running, the skill said a model fits and the launch failed. This also makes two models on one GPU a trial-and-error loop.

estimate_vram.py now reads free VRAM from amd-smi metric --mem-usage (or --free-vram-gb for remote hosts), caps gpu_memory_utilization to what is free (2 GB margin), and reports free_vram_gb, min_needed_gb (weights + 4 GB overhead + 2 GB KV) and can_serve. SKILL.md stops before launch when can_serve is false and otherwise uses the computed utilization.

MI300X, with another vLLM container (Qwen3.5-9B at util 0.9) holding 175 GB:

Model Free Before After
Qwen3-0.6B 20.5 GB fits, util 0.9 can_serve: true, util 0.09
openai/gpt-oss-20b 20.5 GB fits, util 0.9, 156 GB for KV can_serve: false (needs 18.8 GB)
Qwen3-32B 20.5 GB fits, util 0.9 can_serve: false (needs 67 GB)
openai/gpt-oss-20b, --free-vram-gb 191.7 191.7 GB fits can_serve: true, util 0.9 (unchanged)

Testing

  • Reproduced the Docker check failure above.
  • Ran estimate_vram.py on an MI300X (ROCm 7.2) for the cases in the table.
  • ./.github/scripts/check.sh passes.

…eck free VRAM

- validate.py: `docker ps -q 2>&1 | head -1` always exits 0 (head's exit code)
  and hides stderr, so a broken Docker setup was reported as ready. Run plain
  `docker ps -q`.
- SKILL.md: Step 4 never read `gpu_configs.<gfx>.model_overrides`, so the
  gfx950 gpt-oss override (VLLM_ROCM_USE_AITER_MOE=0) was never applied.
- estimate_vram.py: the fit check assumed the whole GPU was free. Read free
  VRAM from amd-smi (or --free-vram-gb), cap gpu_memory_utilization to it, and
  report can_serve. SKILL.md stops before launch when can_serve is false.
@danielholanda

Copy link
Copy Markdown
Collaborator

@TwelveNights

This branch has not been deployed

No deployments
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.

2 participants