Skip to content

[Feature] Wire Metal device selection into the router FFI device paths - #3517

Draft
Bevisy wants to merge 1 commit into
vllm-project:mainfrom
Bevisy:feat/macos-metal-device-wiring
Draft

[Feature] Wire Metal device selection into the router FFI device paths#3517
Bevisy wants to merge 1 commit into
vllm-project:mainfrom
Bevisy:feat/macos-metal-device-wiring

Conversation

@Bevisy

@Bevisy Bevisy commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Related #3516

Purpose

The Metal device resolver added in #3165 Add Metal (Apple Silicon) support to candle-binding (core::device::resolve_device, bounded Metal inference thread pool, queue draining) was only wired into the ModernBERT loader. The router-facing FFI entrypoints that load embeddings, similarity, and MLP selectors still hardcoded a CUDA-or-CPU fallback, so on macOS (Apple Silicon) use_cpu=false ran on the CPU even when the binding is built with --features metal.

This slice routes every inference device-selection site through the shared core::device::resolve_device:

  • ffi/embedding.rs — all init_*_embedding* entrypoints
  • core/similarity.rsBertSimilarity::new
  • classifiers/unified/model_managers.rsLoRAModelManager
  • ffi/mlp.rsdevice_from_type(2) (Metal selector device type; the Go binding already defines MLPDeviceMetal)
  • core/device.rs — Metal-selection unit tests + a metal-build-only device log line

Non-macOS / non-metal builds are unchanged: the non-metal branch of resolve_device is identical to the previous inline code, so Linux/CUDA/ROCm and CPU-only behavior is byte-for-byte equivalent.

Test Plan

  • cargo fmt / cargo check / clippy pass under the CI toolchain (rust 1.90).
  • Unit tests under --features metal on darwin/arm64: resolve_device(false).is_metal(), resolve_device(true) stays CPU, device_from_type(2).is_metal().
  • Runtime (Metal builds cannot run in this repo's CI — all runners are ubuntu-latest, no macOS runner): with the metal feature built, InitModel(<MiniLM dir>, use_cpu=false) + GetEmbedding logs [candle-binding] inference device: Metal(MetalDevice(DeviceId(..))) and returns a 384-dim embedding — a real BERT forward on the GPU.
  • Full cargo test --no-default-features --features metal --lib shows zero regressions vs the base tree (identical failure set, all pre-existing metal-feature kernel gaps / missing local test fixtures unrelated to this slice).

Test Result

All checks above pass locally on darwin/arm64 (rust 1.90 override = CI toolchain). Remaining risk: qwen3/gemma embedding kernels are not yet Metal-covered (tracked in #3516's qualification scope), so this PR only makes the device selection wiring correct — it does not claim full model coverage on Metal.

Every FFI device-selection site (embedding-model init, similarity,
unified-classifier model managers, MLP selector device_type=2) hardcoded a
CUDA-or-CPU fallback, so on macOS use_cpu=false ran on the CPU even when the
binding is built with --features metal (the Metal device resolver from vllm-project#3165
was only wired into the ModernBERT loader).

Route all sites through core::device::resolve_device instead, so use_cpu=false
selects Metal on Apple Silicon builds while Linux/CUDA/ROCm and CPU-only
behavior stays unchanged. Add Metal-selection unit tests for resolve_device and
device_from_type(2), and a metal-build-only device log line.

Related: vllm-project#3516
Signed-off-by: Binbin Zhang <binbin36520@gmail.com>
@netlify

netlify Bot commented Sep 5, 2026

Copy link
Copy Markdown

Deploy Preview for vllm-semantic-router ready!

Name Link
🔨 Latest commit 5c074ae
🔍 Latest deploy log https://app.netlify.com/projects/vllm-semantic-router/deploys/6a9c4b613770e400074f5ed7
😎 Deploy Preview https://deploy-preview-3517--vllm-semantic-router.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@github-actions github-actions Bot added the pr/needs-author Waiting for author changes or response. label Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr/needs-author Waiting for author changes or response.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant