Foundry Local vs HyperQwen

Foundry Local

The SDK and its native runtime are MIT, at 2.1.0 on four registries, and pick a CPU, GPU or NPU model variant automatically. The optional local server has no credential, its current routes aren't in the published REST reference, and telemetry is on by default with an opt-out.

HyperQwen

HyperQwen packages a patched vLLM 0.32.0 and requantised Qwen3.8-27B weights into one container with tool calling preset and a loopback bind when no key is set. It runs one model family, its speed figures come from one RTX 3090, and it has no versioned releases, changelog or security policy.

Foundry Local

1. Read the server URL from manager.urls[0] or foundry server status. The port is dynamic unless the owner sets web.urls or foundry server start --port
2. Send the model ID that GET /v1/models returns, not the alias. The alias resolves to a hardware-specific variant
3. Check supportsToolCalling before sending tools. Support differs by variant, and issue #1183 reports Qwen tool calling failing on QNN
4. Set your own request timeout. Inference has no built-in one, and cancellation takes effect only after the current generation step
5. Ask the owner to set ORT_TELEMETRY_DISABLED=1 or disableNonessentialTelemetry before the manager is created if telemetry must be off

HyperQwen

1. Call http://127.0.0.1:18020/v1 with model qwen3.8-27b and the VLLM_API_KEY value, or any string if no key was set
2. Poll /health before the first request. A first start downloads and prepares the model and compiles kernels, which can take over 30 minutes
3. Declare the context window your setup uses (65,536 by default, 131,072 for CTX=long, 245,760 for CTX=huge) so the client doesn't truncate
4. Ask the owner to set VLLM_API_KEY before setting BIND=0.0.0.0, and to front the port with a proxy that allowlists routes
5. Treat the README's tokens-per-second figures as the project's measurements on one RTX 3090 at 250 W