qwen3-coder-next-blackhole

Qwen3-Coder-Next (80B total / 3B active MoE: 512 experts, top-10 + shared expert, 48 layers of Gated DeltaNet + gated attention) served on Blackhole through vLLM and the Tenstorrent plugin - four dies (p300x2 / p150x4) or two dies (p300 / p150x2). Tensor-parallel mixers, experts sharded on the intermediate dimension, on-device sampling, per-width decode traces, chunked prefill, tool calling (qwen3_coder), 262144-token context, up to 32 concurrent sequences. Ported from the Qwen3.5-122B-A10B Blackhole autoport (same architecture family).

Runs on p300x2 or p150x4 or p300 or p150x2 — see the serve profiles below.

Packaged and published with tt-model-manager 0.1.0 (manifest schema 5.1).

Quickstart

tt-model pull  raahemnabeel/qwen3-coder-next-blackhole --with-weights
tt-model serve raahemnabeel/qwen3-coder-next-blackhole

pull --with-weights downloads the Docker image and the Qwen/Qwen3-Coder-Next weights at a7fbcb5c0e12d62a448eaa0e260346bf5dcc0feb (into your HF cache; they are not in the image). serve starts an OpenAI-compatible server on port 20000 (or the next free port, if that one is busy); the first start compiles kernels for your device, which takes several minutes, and the server is ready when it logs Application startup complete.

Use with your client

Point an OpenAI-compatible client at http://127.0.0.1:20000 (or the port tt-model serve printed) with model Qwen/Qwen3-Coder-Next. The model does not think (no reasoning block); tool calls use vLLM's qwen3_coder parser (--enable-auto-tool-choice is on). Without sampling parameters a request uses the checkpoint's defaults (temperature 1.0, top_p 0.95, top_k 40).

Profiles

tt-model serve raahemnabeel/qwen3-coder-next-blackhole --profile <name>:

• p300x2 (default) / p150x4 - four dies: the faster profile.
• p300 / p150x2 - two dies: the same features on half the hardware, with bfp4 routed experts. Every profile runs chunked prefill, so long prompts (codebases, long files) do not block short requests.

Fixed defect: word corruption when sampling on device (Hub revisions up to ef463288)

Earlier revisions of this package corrupted about one word in thirty of a long sampled answer ("safetensors" -> "checkpointsetensors", "interpreter" -> "interpreterterpreter") and served greedy by default to hide it. Root cause: the on-device sampler runs on every die of the mesh and each die feeds its own draw back into the model, while the client receives die 0's token; the dies' free-running random generators drifted apart, so the model continued from a token the client never saw. Every die now draws from identical per-step seeds and adopts die 0's token (tt/model.py, _install_lockstep_sampling). Verified on p300x2 at 20K context: 0 of 400 sampled steps disagree across dies (196 before), and the served long-context quality probe scores the same as greedy. The checkpoint's generation config is served again.

Limitations

• The device sampler supports top_k up to 32. This checkpoint's recommended default is top_k 40, which is clamped to 32 rather than moved to host sampling, so a default request is not served with the sampler the model card specifies.
• Agentic benchmarks (SWE-Bench Verified, LiveCodeBench), which is what Qwen publishes for this checkpoint, were not run.

Benchmark evals

Through the served API on four dies with lm-evaluation-harness 0.4.9, at temperature 0: HumanEval pass@1 68.9 %, MBPP pass@1 77.2 %, GSM8K exact match 92.4 %, IFEval prompt-level strict 75.8 %. Re-run at temperature 1.0, HumanEval falls to 60.4 % while the others stay within their error bars - HumanEval is the one task here where a single wrong token fails the whole answer. Qwen does not publish HumanEval or MBPP for this checkpoint, so these are baselines for the port rather than a comparison against a vendor figure.

Serve profiles

One image serves every profile below; pick one with --profile.

profile	hardware	mesh	max_num_seqs	max_model_len
p300x2 (default)	p300x2	P300x2	32	262144
p150x4	p150x4	P150x4	32	262144
p300	p300	P300	32	262144
p150x2	p150x2	P150x2	32	262144

Provenance

The exact sources the image was built from — code/ in this repo is byte-identical to the model code inside the image:

component	built from
tt-metal	a local checkout — commit not published (dirty tree — the image includes uncommitted changes)
vLLM	v0.26.0
vllm-tt-plugin	a local checkout — commit not published
code/ digest	531fa3919941e008 (sha256, first 16 hex digits)
built	2026-10-06T21:22:13+00:00 by tt-model 0.1.0