Qwen 3.6 27B (Thinking)

Qwen 3.6 27B is Alibaba’s dense Open Weights model with 27.8 billion active parameters, which according to the manufacturer outperforms its own MoE sibling model 35B-A3B in coding, agent, and vision tests. Released on April 22, 2026 under Apache 2.0 for local deployment, the architecture combines hybrid attention with native multi-token prediction for noticeable throughput gains. This Card covers the NVFP4 variant — a performance update for vLLM on NVIDIA Blackwell: NVFP4 is a 4-bit floating-point format with two-level micro-block scaling (E4M3 per 16-value block plus FP32 per-tensor scale), reducing memory requirements by ~3.5× compared to FP16 and ~1.8× compared to FP8 at under 1% accuracy loss. Predecessor profile without NVFP4: qwen3_6-27B-pre025 (Card qwen3_6-27B-pre025–VSPK.json, tests 2026-07-09, vLLM prior to 0.25.1).

Alibaba Version 3.6 Commercial use permitted Dense 27.8 B (27.8 B active) 262 K Context 12/2025 locally tested

Open Weights
Workstation
vLLM
Text
Vision
Video
Instruction-Tuned
Unusable

Sovereign Risk: MEDIUM The developer Alibaba is headquartered in China, which poses a potential risk regarding Chinese legislation (NSL) when using the manufacturer’s cloud services. However, since the model weights are openly available under the Apache 2.0 license and this model is designed for purely local operation, no data is transmitted to the manufacturer’s servers. The risk is therefore classified as ‘medium’, as the origin lies in a high-risk jurisdiction, but the practical danger when used locally is minimized.

Tool-use details

Asset performance, reliability, and runtime profile

Name	P1	P2	Combined
EU License Research	100	20	52
HTTP Fetch & Extract	80	35	57.5
Tool Failure Handling (404)	80	80	80
Web Search & Tool Selection	100	80	91
URL Construction & Fetch	80	80	80
Multilingual Search & Synthesis	100	60	80

Name

Combined

EU License Research

100

HTTP Fetch & Extract

57.5

Tool Failure Handling (404)

Web Search & Tool Selection

100

URL Construction & Fetch

Multilingual Search & Synthesis

100

CrucibleMark evaluates tool use across 6 independent tests. Click a test name for details.

Reliability

Tool Call Valid: No

Retry: Not required

Hallucination: Detected

Reliability measures how consistently a model actually executes tool calls: Tool Call Valid schema and format accepted, Retry Required successful only after retry, Hallucination Flag fabricated tools or parameters detected. All three green means production-ready.

Runtime profile

Call 1: 8.91; First Request

MCP: 1.23; Protocol Latency

Synthesis: 85.9; Response Generation

Total: 576.21; Sum of All Phases

Token: 21726; Input + Output

Cost: $0; Cost per Run

The runtime profile shows the latency and cost metrics for the model run: Call 1 First Request, MCP Protocol Latency, Synthesis Response Generation, Total sum of all phases, supplemented by Token input and output and Cost cost per run.

Deployment Verdict

Conditional deploy, because tool execution is mostly strong, but synthesis fidelity is too weak, and an invalid tool call in an MCP pipeline creates a real trust problem.

Tool Execution Profile

Qwen 3.6 27B shows genuine tool intelligence, not just rigid pattern matching. In the Web Search & Tool Selection test — which checks the choice between search and direct retrieval without an explicit hint — it reliably identifies the need for web_search. This points to usable planning logic in open research paths. In the URL Construction test, which checks whether the model can derive the target URL itself and then execute fetch correctly, it remains usable but not deterministic enough. P1 is solid there, not robust.

The core caveat is protocol-level: Tool-Call valid is false. This does not mean the model fundamentally fails to understand tools. It does mean, however, that the MCP layer should not be handed off without guardrails. For production tool chains, call validation, schema checking, and — when in doubt — a broker that intercepts malformed calls before side effects occur are all required.

Synthesis Fidelity

How well does it condense tool results? Only to a limited degree. The P2 score shows that Qwen 3.6 27B often fails to synthesize retrieved content with sufficient precision. This is particularly visible in EU License Research, where tool use succeeds formally but condensation drops to 20, and in HTTP Fetch & Extract, which is supposed to pull structured facts from real page content and only reaches 35. For compliance, regulatory work, and any pipeline with exact detail fields, that is too imprecise.

Does it stay within tool output or fall back on training? The honeypot result is contradictory: no hallucination flagged in the individual case, but global hallucination detected true. That is precisely the security risk. Once a model in a tool pipeline can present fabricated facts as originating from tools, it is not just answer quality that is affected — it is the evidentiary integrity of the entire infrastructure.

Error Resilience

The model is usable here. In the 404 test — which checks whether a failed tool call is communicated transparently rather than replaced with invented page content — Qwen 3.6 27B stays clean. It does not substitute the error with fabricated content. That is acceptable for production and considerably more important than stylistic answer quality.

Operational Profile

Call 1: 8.91s. MCP latency: 1.23s. Call 2: 85.90s. Total: 576.21s. Locally operable. Direct runtime cost per run: local. For the performance shown, that is slow.

Conclusion & Recommendation

Suitable for local research and orchestration pipelines with strict tool call validation, response checking, and downstream fact verification. Not suitable for compliance-adjacent, citation-required, or extraction-critical workflows in which tool results must be condensed precisely and passed on reliably. As an agent that often finds the right tool and reports errors transparently, it is usable. As a trustworthy final synthesis layer, it is not yet stable enough.

This analysis was generated automatically based on benchmark data. Model used: GPT 4.5 by OpenAI. The raw data and full methodology are documented in the GitHub project.