vllm-project/semantic-router
View on GitHubfeat: support AMD AI PC edge deployments with local and external model routing
Open
#2,373 opened on Jul 5, 2026
area/environmentarea/model-selectionarea/user-experienceenhancementenvironment/rocmhelp wantedoperationspriority/P2roadmap
Repository metrics
- Stars
- (4,293 stars)
- PR merge metrics
- (PR metrics pending)
Description
Summary
Define and validate a supported AMD AI PC edge profile for running vLLM Semantic Router and routing between explicitly configured local and external logical models.
Parent roadmap: #2287
Related: #1138, #2294, #2331, #2334, #2358, #2372
Audited current-main baseline (2026-07-15)
- The repository's supported local flows are
make vllm-sr-devplusvllm-sr serve --image-pull-policy never, withVLLM_SR_PLATFORM=amd/--platform amdfor the AMD image path. deploy/amd/,deploy/local/, recipes, provider models, and model inventory exist, but they do not establish tested Ryzen AI/NPU support.- Current CLI implementation uses
container_run_command.pyandcontainer_images.py. The previously citeddocker_run_command.pyanddocker_images.pypaths do not exist. - AMD's official Ryzen AI Max+ 395 product page documents CPU/iGPU/NPU platform characteristics, but hardware specifications alone do not prove compatibility with the router's Candle/ONNX/container runtimes.
- Current
maindoes not provide a first-class upstream-error ordered fallback contract; #2294 tracks model failover.
Scope
- Define the supported hardware/software matrix separately for CPU, Radeon iGPU/ROCm where available, and Ryzen AI NPU. Unsupported accelerators must be explicit.
- Reuse the canonical local image/serve flow; add a named edge profile only through existing CLI/container configuration seams.
- Provide a maintained recipe with local and external provider models, explicit local-only/privacy decisions, and ordinary policy-based escalation.
- Define memory/model-size, architecture, quantization, runtime, driver, OS, and container constraints for each tested path.
- Add capability discovery where reliable; otherwise require validated manual configuration and surface “unknown/unsupported” honestly.
- Use lightweight, bounded defaults for single-node storage, observability, and dashboard services.
- Capture reproducible validation receipts with device, OS/kernel, driver/runtime, image digest, model artifacts, config, and test results.
- Coordinate true upstream-error failover/fallback behavior with #2294 instead of implying it already exists.
Non-goals
- Do not claim NPU, iGPU, or unified-memory acceleration without an exercised runtime path.
- Do not assume data-center ROCm settings apply unchanged to AI PCs.
- Do not require every device to support the same model size or feature set.
- Do not send local-only/private traffic to external providers.
- Do not invent a second local serve path.
Acceptance criteria
- A support matrix distinguishes tested, experimental, and unsupported CPU/iGPU/NPU paths.
- The canonical local image/serve flow works for at least one documented AI PC configuration.
- One maintained recipe demonstrates local/external policy without violating local-only constraints.
- Resource limits, failure behavior, and unsupported capability diagnostics are explicit.
- Validation receipts are reproducible and do not contain secrets.
- Privacy decisions are covered by probes/eval/E2E tests.
- Any upstream-error model fallback depends on the contract in #2294.
Likely change surfaces
src/vllm-sr/cli/container_run_command.py, container_images.py, service_defaults.py, deploy/amd/, deploy/local/, deploy/recipes/, src/semantic-router/pkg/config/, modelruntime/, modelinventory/, docs, and tests.
Validation entrypoint
make agent-report ENV=amd CHANGED_FILES="<space-separated changed files>"
Follow the reported AMD/local-image and affected E2E gates.