HyperQwen vs MLX LM

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.

MLX LM

MIT, with no telemetry found in the source, and the tests passed on the last eight pushes to main. mlx_lm.server has no API key option, answers any origin by default and loads whichever model a request names, and its own docs say it is not recommended for production.

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

MLX LM

1. Keep mlx_lm.server on 127.0.0.1 and pass --allowed-origins with the origins you trust. There is no API key, and the default answers every origin
2. Treat any caller as able to load any model. The model and adapters request fields accept any Hugging Face repository or local path
3. Send max_tokens or max_completion_tokens when you need more than 512 tokens, the server default
4. Read errors as {"error": "<text>"} with 400 for a bad field and 404 for a model that failed to load. They are not OpenAI error objects
5. Poll GET /health before the first request. It answers 503 with unavailable when the generation thread has stopped