Back to Blogs & News

Qwen3.8-27B API: Benchmarks, Pricing, and the Complete Developer Guide

28 min read

Qwen3.8-27B is a 27-billion-parameter dense vision-language model released under Apache 2.0 on August 14, 2026. It scores 52 on the Artificial Analysis Intelligence Index and 61.7 on SWE-bench Pro, supports a 262,144-token context window extensible to 1 million, and handles image and video input natively. On Qubrid AI it costs $0.58 per 1M input tokens and $3.45 per 1M output tokens, callable through an OpenAI-compatible endpoint with the model string Qwen/Qwen3.8-27B.

What Qwen3.8-27B is, and why the release landed hard

The Qwen3.8 generation shipped in three parts over twelve days in August 2026. Qwen3.8-Max went generally available on August 3. The 2.4-trillion-parameter open checkpoint, Qwen3.8-2.4T-A95B, landed on August 12. And on August 14 came the one most engineering teams can actually deploy: Qwen3.8-27B.

As the Qwen team documents on the model card, Qwen3.8 is the most capable generation in the open Qwen family to date, built on the architectural foundation of Qwen3.5, with the 27B bringing those advances to a compact, deployment-friendly dense model. Its stated feature set:

  • Core capabilities improved across coding, professional work, research, and long-horizon agentic tasks

  • Agent execution with stronger autonomous planning and better handling of environment feedback

  • Downstream compatibility with popular harnesses and development tools

  • Flexible thinking control via reasoning_effort and preserve_thinking

  • Vision-language understanding covering images and video natively

The reaction was disproportionate to the parameter count. As VentureBeat's Carl Franzen reported, the biggest model release of that week among developers and AI power users was not a frontier cloud model from any of the major labs - it was this 27B. Cybernews reported it passed 3 million Hugging Face downloads in its first three days, and the r/LocalLLaMA community spun up a dedicated megathread purely to consolidate the flood of quantizations, benchmark runs and configuration advice.

The ecosystem numbers on Hugging Face tell the same story: over 3.2 million downloads in the last month, 217 fine-tunes, 856 quantizations, 49 adapters and 47 Spaces built on it at time of writing.

There is a broader signal underneath the excitement. As Business Insider reported using Hugging Face usage data, real-world model usage skews heavily toward smaller models even while enormous frontier releases dominate headlines - models above 70 billion parameters accounted for only a small share of 2026 downloads. A capable 27B is not a consolation prize. It is where the volume already is.

Qwen3.8-27B architecture

Most coverage stops at "27B dense, 262K context." The details matter because they change how you should use the model and what it costs to serve.

Hybrid attention: 48 linear layers, 16 full-attention layers

As the model card specifies, the hidden layout is:

16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))

Of 64 total layers, only 16 run full quadratic attention. The other 48 run Gated DeltaNet, a linear-attention mechanism carrying a constant-size recurrent state instead of a KV cache that grows with sequence length.

As the vLLM Recipes project documents, this is a full_attention_interval of 4, and they call the layer mix the interesting part of the design. It is. Linear attention on three quarters of the stack is what makes a 262K context window affordable on a dense model instead of a memory disaster. It is also why this model fits on a single Blackwell GPU in every precision.

Component

Configuration

Total layers

64

Hidden dimension

5,120

Token embedding

248,320 (padded)

Gated DeltaNet heads

48 for V, 16 for QK, head dim 128

Gated Attention heads

24 for Q, 4 for KV, head dim 256

Rotary position embedding dimension

64

FFN intermediate dimension

17,408

Native context

262,144 tokens

Extended context

1,000,000 tokens via YaRN

Parameters

27B language model, 28B total with vision encoder

Tensor type

BF16

License

Apache 2.0

A vision tower, not a vision bolt-on

The architecture string is Qwen3_5ForConditionalGeneration and config.json carries a vision_config. As the vLLM recipe notes, unlike the 2.4T flagship this is a genuinely multimodal model.

The model card lists native support for image and video understanding, covering STEM diagrams, documents, and hour-scale video. You get one model handling text, images and video through one chat completions interface, rather than routing three separate calls to three separate models.

For long video specifically, the Qwen team recommends raising longest_edge in video_preprocessor_config.json to 469,762,048, corresponding to roughly 224K video tokens, to enable higher frame-rate sampling. The shipped default is deliberately conservative to keep text and image inference efficient. Implementation details are in the relevant vLLM pull request.

Multi-Token Prediction is baked into the weights

Qwen3.8-27B ships a trained MTP (Multi-Token Prediction) draft head inside the checkpoint. As Sebastian Raschka explains in his LLM architecture gallery, a cheaper mechanism predicts several tokens ahead and the main model verifies the guesses in a single forward pass. High acceptance rates mean higher throughput at identical output quality.

The vLLM Recipes team measured acceptance across precisions at 262K context:

Precision

KV cache tokens

Weights per GPU

MTP acceptance

FP8

377,456

14.28 GiB

0.771

NVFP4 (uniform W4A4)

445,875

12.02 GiB

0.897

NVFP4 (mixed-precision)

920,517

10.64 GiB

0.788

Acceptance between 0.77 and 0.90 is high. This matters to you as an API consumer because it is one of the main levers a serving platform pulls to keep latency down on a dense model.

As Simon Willison found in hands-on testing, enabling MTP through llama.cpp on an NVIDIA DGX Spark produced roughly a 72% throughput improvement over his default local configuration. He credits a tip from llama.cpp creator Georgi Gerganov for the serving flags. That is a single-machine result rather than a datacenter benchmark, but the direction is clear and consistent with the acceptance rates above.

The three thinking controls

All three are exposed through the API and all three matter:

  1. enable_thinking - on by default, can be turned off per request for direct answers.

  2. reasoning_effort - xhigh (default), medium, or low.

  3. preserve_thinking - on by default, retains reasoning blocks from every historical message in the conversation.

That third one is underrated and has a direct billing consequence. As the Qwen team notes, preserved thinking maintains a complete reasoning trace across turns, which helps decision consistency in agent scenarios and improves KV cache utilisation. On a metered API, better cache utilisation is money. It also means your prompt prefix grows across turns, which is exactly what implicit caching is built to absorb.

Extending context to 1 million tokens

The 262,144-token native window covers most workloads. If you need more, the model card documents YaRN RoPE scaling. Modify rope_parameters under text_config in config.json:

{
    "mrope_interleaved": true,
    "mrope_section": [11, 11, 10],
    "rope_type": "yarn",
    "rope_theta": 10000000,
    "partial_rotary_factor": 0.25,
    "factor": 4.0,
    "original_max_position_embeddings": 262144
}

One caution the Qwen team makes explicitly: all notable open-source frameworks implement static YaRN, meaning the scaling factor stays constant regardless of input length. That can degrade performance on shorter inputs. Set factor to match your actual typical context rather than maxing it - if your workload runs around 524,288 tokens, use 2.0 rather than 4.0.

Qwen3.8-27B benchmarks: official results

Text performance

Benchmark

Qwen3.8-27B

Qwen3.6-27B

Qwen3.7-Plus

Agentic terminal coding - Terminal-Bench 2.1 (Terminus)

73.0

63.4

64.0

Agentic coding - SWE-bench Pro

61.7

53.5

57.6

Repo-level code generation - NL2Repo-Bench

42.3

36.2

41.1

Agentic coding - DeepSWE 1.1

42.2

13.3

14.2

Software engineering - QwenSWEBench

79.0

49.3

59.2

Long-horizon office work - CoWorkBench

70.7

61.0

65.1

Professional job tasks - JobBench

33.4

21.8

27.6

Frontier agentic tasks - Agents' Last Exam (Pass@1)

20.4

10.6

13.2

Instruction following - IFBench

79.5

69.1

79.1

Scientific reasoning - GPQA Diamond

89.2

87.8

90.3

Multidisciplinary reasoning - Humanity's Last Exam

30.8

24.0

34.7

Competitive coding - LiveCodeBench v6

90.3

83.9

89.6

Two things stand out. The generational jump on agentic coding is large: DeepSWE 1.1 moves from 13.3 to 42.2 and QwenSWEBench from 49.3 to 79.0 against the previous 27B. And the 27B beats the closed-weight Qwen3.7-Plus on most agentic and coding rows while still trailing it on Humanity's Last Exam and GPQA Diamond.

That shape is consistent and worth internalising: this model converts its parameter budget into agentic and tool-use performance unusually well, and into broad frontier knowledge less well. Route accordingly.

As VentureBeat noted, in Qwen's published comparison table the 27B beats the listed Claude Opus 4.6 Max result on SWE-bench Pro and LiveCodeBench, while Opus stays ahead on Terminal-Bench, GPQA Diamond and Humanity's Last Exam. VentureBeat also points out that some evaluations are internal and the harnesses are not identical across every comparison, which makes the numbers poor grounds for declaring a universal winner.

Vision-language performance

Benchmark

Qwen3.8-27B

Qwen3.6-27B

Qwen3.7-Plus

Computer use - OSWorld-Verified

84.3

63.9

73.3

Browser use - WebArena-Verified

64.8

48.8

55.3

Mobile use - AndroidWorld

81.9

70.3

81.0

Application recreation - RecreationBench

47.1

29.8

30.2

Multimodal software engineering - SWE-MM

38.6

25.7

30.0

Visual web development - Vision2Web

62.9

45.0

42.1

Visual math - MathVision (with code interpreter)

94.6

85.1 (without)

90.3 (without)

General visual reasoning - BabyVision (with CI)

85.6

28.9 (without)

70.4

Scientific chart analysis - CharXiv RQ (with CI)

90.2

78.4 (without)

85.9

Document intelligence - OmniDocBench 1.5

91.1

89.4

91.4

Real-world perception - RealWorldQA

85.9

84.1

86.9

Embodied intelligence - ERQA

65.5

62.5

69.8

OSWorld-Verified at 84.3 against 63.9 for the previous generation is the headline. Computer-use agents were the weakest link in open multimodal models for most of the past two years, and a 20-point jump inside one generation at the same parameter count is a real result. WebArena-Verified moving from 48.8 to 64.8 says the same thing about browser automation.

Methodology caveats you should actually read

The model card is unusually transparent about how these numbers were produced. Passing that along honestly:

  • Several benchmarks are in-house. QwenSWEBench, CoWorkBench and RecreationBench are Qwen's own internal evaluations. They are not independently reproducible.

  • The evaluation harness is not neutral across comparisons. SWE-bench Pro, NL2Repo-Bench, DeepSWE 1.1, QwenSWEBench, Vision2Web and SWE-MM were all evaluated using the Claude Code harness. Comparison models were re-evaluated on refined benchmarks, but harness choice affects agentic scores materially.

  • HLE was judged by GPT-4o. LLM-as-judge introduces its own variance.

  • MathVision used a fixed prompt for Qwen3.8-27B while comparison models got the better of two prompt variants.

  • Ground-truth corrections were applied. A small number of incorrect annotations in MathVision and CharXiv were manually corrected before scoring.

  • NL2Repo-Bench disabled network commands such as pip install and git clone to prevent reward hacking.

None of this means the numbers are wrong. It means vendor benchmarks are vendor benchmarks until someone else reproduces them, which is exactly what happened next.

Qwen3.8-27B benchmarks: independent results

The picture changed when Artificial Analysis indexed the model. Unusually, they evaluated each reasoning setting as a separate entry, which makes the quality-versus-verbosity trade-off legible in a way it rarely is.

Setting

Intelligence Index

Output tokens across the index

Peer median

Notes

xhigh

52

160M

48M

Very verbose, notably slow

medium

44

75M

45M

Somewhat verbose

Non-reasoning

35

26M

17M

53.1 tokens/second

Artificial Analysis Intelligence Index v4.1.1 is a nine-evaluation composite: GDPval-AA v2, τ³-Banking, Terminal-Bench v2.1, SciCode, Humanity's Last Exam, GPQA Diamond, CritPt, AA-Omniscience and AA-LCR.

The 52 at xhigh is the number that circulated. As Simon Willison noted when the score landed, it matched GPT-5.6 Luna at maximum reasoning and sat one point behind GLM-5.2 and DeepSeek V4 Pro at max, both of which are vastly larger mixture-of-experts systems.

The reaction from the open-source tooling community explains why it registered. The team behind the Cline coding agent posted: "This is the first time a local model has scored frontier model capability."

The generational comparison

Artificial Analysis also tracks the predecessor. Qwen3.6-27B scores 38 on the Intelligence Index in reasoning mode.

That is a 14-point jump at identical parameter count. Diff the two config files and the architecture is essentially unchanged: same 64 layers, same hidden size, same hybrid Gated DeltaNet layout, same max positions. Every point came from post-training - reinforcement learning environments and on-policy distillation. It is also why llama.cpp supported the model on day one.

The Agentic Index, and a number that gets misquoted constantly

Artificial Analysis publishes a separate Agentic Index measuring tool-use and multi-step task performance. Qwen3.8-27B scores 50.877, displayed as 51, placing it above Claude Opus 4.8 at maximum reasoning effort.

Three corrections worth making, because most coverage gets these wrong:

  1. 52 and 51 are different measurements. 52 is the Intelligence Index. 51 is the rounded Agentic Index. Conflating them produces a better headline and a worse analysis.

  2. The Agentic Index margins are narrow. The lead over the next model down is under one point, and leaderboard comparisons are between specific reasoning-effort variants, not entire model families.

  3. The 27B ranks higher on Agentic than on Intelligence. That is not a contradiction. It means the model converts a compact parameter budget into planning and tool-mediated workflow performance exceptionally well, without leading a broad knowledge suite.

The honest reading, and the one worth building on: a 27B dense open-weight model is now competitive with hosted frontier systems on agentic and tool-mediated work, while trailing them on the hardest frontier reasoning. That is a genuinely new position on the price-performance curve, and it is not the same claim as "beats Opus."

What the leaderboards do not capture

Two capabilities showed up in hands-on testing that no index measures well.

Tool calling holds up in a real agent loop. Willison pointed the model at a real codebase through a coding agent framework and it produced a correct explanation of the authentication architecture after a sequence of reasoning and file-reading tool calls, then wrote and tested a working Python utility in a follow-up session. For API consumers this matters more than most index positions.

Visual grounding is strong. Asked for JSON bounding boxes on a 0-1000 normalised scale, the model returned coordinates that matched the targets closely:

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

If you are doing document layout analysis, UI automation or visual grounding, benchmark it on your own data. This is a strength.

The overthinking problem, and exactly how to fix it

This is the section that will save you the most money, so it gets the space.

Qwen3.8-27B defaults reasoning_effort to xhigh, which the model card describes as intended for complex tasks demanding thorough analysis. It is not a sensible default for general production traffic.

Look again at the three-row table above. Going from medium to xhigh buys 8 index points for slightly more than double the output tokens. Going from non-reasoning to medium buys 9 points for roughly triple. The curve flattens hard at the top, and output tokens are what you pay for.

What that looks like in practice

Willison's hands-on write-up is the vivid version. A request to draw an SVG of a pelican riding a bicycle took 21 minutes and 22,276 reasoning tokens to produce 3,223 tokens of output. The same prompt with reasoning off produced 3,715 tokens in 137 seconds. Priced at output rates, the reasoning alone would cost roughly seven times the answer.

He also asked it to draw a circle. At xhigh, the reasoning trace deliberated over palette options, Bauhaus construction lines and whether to respect reduced-motion preferences, then produced an animated geometric study nobody had asked for. His recommendation, which we agree with, is to start at low or no reasoning rather than the default.

Independently, developer and investor Tomasz Tunguz ran a nine-task comparison in his agent stack and found that with reasoning enabled the model edged ahead on quality but ran roughly 30x slower and 4.5x more expensive. He explicitly cautioned that nine tasks is not a verdict.

The production recommendation

Workload

Setting

Why

Classification, extraction, routing, summarisation

enable_thinking: false

Reasoning adds latency and cost with no measurable gain on structured tasks

Chat, RAG answering, code completion

reasoning_effort: "low"

Enough deliberation to avoid obvious errors, bounded token spend

Multi-step agents, debugging, repo-level changes

reasoning_effort: "medium"

Best cost-per-index-point on the curve above

Hard one-shot problems, research, planning

reasoning_effort: "xhigh"

Use deliberately, on a fraction of traffic, with a token budget

One counterintuitive note straight from the model card, which we agree with: in multi-turn agentic tasks, lower reasoning effort does not always reduce total time or cost. Faster per-turn responses can mean insufficient analysis, more failures, and repeated retries - and retries are billable too. Measure cost per completed task, not cost per request.

Qwen3.8-27B pricing on Qubrid AI

Pay-as-you-go, no minimum commitment, no reserved capacity requirement.

Token type

List price

Qubrid price

Savings

Input

$0.72 / 1M tokens

$0.58 / 1M tokens

20%

Output

$4.31 / 1M tokens

$3.45 / 1M tokens

20%

Implicit cache (input)

$0.14 / 1M tokens

$0.11 / 1M tokens

20%

Output is priced at roughly 6x input. On a model this verbose, that ratio is the whole story - which is why the reasoning section above sits before this one.

How implicit caching changes your real bill

Cached input is billed at $0.11 per 1M tokens instead of $0.58, a roughly 5x reduction.

This matters more on Qwen3.8-27B than on most models, for a specific architectural reason covered earlier: preserve_thinking is on by default, so reasoning blocks from historical messages persist across the conversation. In a multi-turn agent loop that produces a large, identical, growing prefix on every subsequent call. Identical prefixes are exactly what implicit caching is built to catch.

Worked example. A coding agent runs a 12-turn session with a 40,000-token system prompt and tool schema that never changes:

  • Without cache hits: 12 × 40,000 × $0.58 / 1,000,000 = $0.278

  • With cache hits after turn one: (40,000 × $0.58 + 440,000 × $0.11) / 1,000,000 = $0.072

A 74% reduction on the static portion of input spend, before counting the actual conversation.

How to earn cache hits. Put invariant content first: system prompt, tool schemas, few-shot examples, then retrieved documents that persist across turns, then the variable conversation. A single changed token near the start of your prompt invalidates everything after it. This is the cheapest optimisation available to you and it costs one refactor.

Monthly cost estimates

Assuming no cache hits, so treat these as ceilings:

Monthly volume

Input cost

Output cost

Total

5M in / 1M out

$2.90

$3.45

$6.35

50M in / 10M out

$29.00

$34.50

$63.50

250M in / 50M out

$145.00

$172.50

$317.50

1B in / 200M out

$580.00

$690.00

$1,270.00

Two adjustments for your own estimate. Cache hits pull the input column down substantially on agentic and RAG workloads. And leaving reasoning_effort at xhigh can push the output column up by a multiple.

Reasoning tokens are output tokens

Bears repeating in a pricing section. Artificial Analysis measured the model generating roughly 3.3x the peer median in output tokens at xhigh. At $3.45 per 1M output tokens, that multiplier lands directly on your invoice. reasoning_effort is the highest-leverage cost control on this model.

Qwen3.8-27B API: how to call it

The endpoint is OpenAI-compatible. If you have an existing OpenAI SDK integration, this is a two-line change.

Basic text completion

from openai import OpenAI

# Initialize the OpenAI client with Qubrid base URL
client = OpenAI(
    base_url="https://platform.qubrid.com/v1",
    api_key="QUBRID_API_KEY",
)
response = client.chat.completions.create(
    # Must match the exact model ID from the docs - variations will cause errors.
    model="Qwen/Qwen3.8-27B",
    messages=[
        {
            "role": "user",
            "content": "Explain the main benefits of using a chat completion API for text generation."
        }
    ],
    max_tokens=4096,
    temperature=0.7,
    top_p=1,
    stream=False
)
print(response.choices[0].message.content)

The model string is Qwen/Qwen3.8-27B exactly as written. Case and slash placement matter.

Controlling reasoning depth

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=messages,
    reasoning_effort="medium",   # xhigh | medium | low
    max_tokens=4096,
    stream=True,
    stream_options={"include_usage": True},
)

Disabling thinking entirely for structured tasks

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=messages,
    temperature=0.7,
    top_p=0.8,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {"enable_thinking": False},
    },
)

Disabling preserved thinking

By default the model retains thinking blocks from all historical messages. To keep only the latest:

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=messages,
    extra_body={
        "chat_template_kwargs": {"preserve_thinking": False},
    },
)

Worth testing both ways on agentic workloads. Preserved thinking improves decision consistency and cache utilisation but grows your prefix; disabling it shrinks the prefix but discards reasoning context.

Vision input

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "image_url",
                "image_url": {"url": "https://your-domain.com/invoice-scan.png"}
            },
            {
                "type": "text",
                "text": "Extract every line item as JSON with description, quantity, and unit price."
            }
        ]
    }
]
response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=messages,
)

Video input

messages = [
    {
        "role": "user",
        "content": [
            {
                "type": "video_url",
                "video_url": {"url": "https://your-domain.com/walkthrough.mp4"}
            },
            {
                "type": "text",
                "text": "Summarise the key steps demonstrated in this recording."
            }
        ]
    }
]

Streaming with separated reasoning content

When thinking is enabled, reasoning arrives on a separate delta field. Handle it explicitly so it does not leak into user-facing output:

reasoning_content = ""
answer_content = ""
is_answering = False

for chunk in completion:
    if not chunk.choices:
        if chunk.usage:
            print("Usage:", chunk.usage)
        continue

    delta = chunk.choices[0].delta

    if getattr(delta, "reasoning_content", None):
        reasoning_content += delta.reasoning_content
    elif getattr(delta, "reasoning", None):
        reasoning_content += delta.reasoning

    if getattr(delta, "content", None):
        if not is_answering:
            is_answering = True
        answer_content += delta.content

When appending the assistant turn back to your message history, include both fields so preserved thinking works as intended:

messages.append({
    "role": "assistant",
    "content": answer_content,
    "reasoning_content": reasoning_content,
})

Straight from the Qwen model card. Use these as your starting point rather than your framework defaults:

Mode

temperature

top_p

top_k

min_p

presence_penalty

repetition_penalty

Thinking

1.0

0.95

20

0.0

0.0

1.0

Instruct / non-thinking

0.7

0.80

20

0.0

1.5

1.0

If you see repetition loops, raise presence_penalty toward 2.0. The Qwen team notes that pushing it high can occasionally cause language mixing and a slight quality drop, so tune rather than max it.

Output length allocation for agentic work

For long-horizon agent tasks inside the 1M context window, the model card recommends allocating up to 262,144 tokens for reasoning content and 131,072 tokens for the final response. Most API workloads will not need anything close to this, but if you are running long autonomous sessions and hitting truncation, that is where the guidance comes from.

Structured output and document extraction

One independent result that has had less attention than the coding scores: Qwen3.8-27B was evaluated on LlamaIndex's ExtractBench, a structured-extraction benchmark, running the FP8 checkpoint under vLLM with one-shot structured output from files.

ExtractBench split

Score

Mean

89.75

Short documents

94.68

Medium documents

87.54

Combined with 91.1 on OmniDocBench 1.5 for document intelligence and the bounding-box behaviour described above, this makes a coherent case for a workload class that is not "coding agent": invoice and receipt parsing, form extraction, contract clause pulling, chart and table digitisation, and screenshot-to-schema pipelines.

The practical recipe for these tasks is the cheap one. Disable thinking, use the instruct sampling parameters, and let the vision tower do the work:

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": document_url}},
            {"type": "text", "text": "Return JSON matching this schema: " + schema}
        ]
    }],
    temperature=0.7,
    top_p=0.8,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {"enable_thinking": False},
    },
)

Extraction is the workload where turning reasoning off costs you almost nothing in quality and a great deal in tokens.

Qwen3.8-27B hardware requirements

If you plan to self-host rather than use the API, these are the numbers to plan against.

Precision

Approximate weight footprint

BF16 (official safetensors)

~55.6 GB

FP8 (official checkpoint)

~30.9 GB

NVFP4

~24.6 GiB

Q4_K_M (community GGUF)

~16 GB

Weight footprint is not VRAM requirement. Runtime buffers, the vision projector, KV cache, batch size and context length all add on top. Unsloth's deployment guide publishes a full hardware table by quant tier, and notes the model runs on roughly 17GB of combined RAM and VRAM at 4-bit.

The vLLM Recipes team documents deployment friction that anyone planning to self-host should read before buying hardware:

  • On a single 32GB consumer card, only about 31.4 GiB is usable, and NVFP4 fits only with --enforce-eager (CUDA graphs off). Without it, startup dies during CUDA graph capture with an out-of-memory error, and adjusting --gpu-memory-utilization does not help, because graph capture allocates outside that budget.

  • --reasoning-parser qwen3 is effectively mandatory. The chat template opens every assistant turn with <think>, so without the parser the entire reasoning block lands in message.content and can consume a 2048-token budget before the answer starts.

  • MXFP4 does not currently load correctly on NVIDIA devices in vLLM. NVFP4 is the path.

  • Two NVFP4 builds of the same model behave very differently. A mixed-precision build leaves room for roughly twice the KV cache; a uniform W4A4 build drafts better with MTP. They are not interchangeable on 32GB cards.

Serving recipes exist for vLLM and SGLang if you go that route.

Throughput reality on a dense model

Dense models are memory-bandwidth bound, and that is the honest catch. Willison measured roughly 15 to 30 tokens per second on an M5 Max MacBook Pro and a DGX Spark using a Q4_K_M quantization, and identified performance as the single thing keeping the model from being his daily driver. Artificial Analysis measured hosted deployments in the low-50s tokens per second. Neither number is fast by hosted-frontier-model standards.

API versus self-hosting: break-even math

Qwen3.8-27B is Apache 2.0, so self-hosting is a real option rather than a theoretical one. Here is the arithmetic.

A workload at 50M input and 10M output tokens per month costs about $63.50 on the API. A single always-on GPU capable of serving this model at production quality costs considerably more than that before you count engineering time, and the operational surface area listed above is not free either.

Self-host when: you have data residency or air-gap requirements, steady high-volume traffic that amortises reserved GPU cost, custom fine-tunes or LoRA adapters in the serving path, or platform engineers who want to own the vLLM configuration.

Use the API when: traffic is spiky or growing, you are still evaluating whether the model fits your workload, you want to A/B it against other models behind the same key without standing up new infrastructure, or your GPU budget is better spent on training than on inference babysitting.

If self-hosting turns out to be right for you, Qubrid also provides on-demand GPU compute and on-premises AI appliances. Managed API and dedicated hardware do not have to mean changing vendors, and the decision is reversible.

Qwen3.8-27B vs Qwen3.8-Max

Both are available on Qubrid, and they are not substitutes.

Qwen3.8-27B

Qwen3.8-Max

Architecture

27B dense, hybrid attention

2.4T MoE, ~95B active

Vision

Yes, native image and video

Text-focused open checkpoint

Native context

262,144 tokens

1M class

Open weights

Apache 2.0

Custom license on the 2.4T checkpoint

Self-hostable

Single GPU at 4-bit

Datacenter scale

Best for

High-volume agentic work, vision, tool use, extraction

Hardest reasoning, frontier knowledge, complex one-shot problems

The pattern that works in production: route the volume to the 27B and escalate the hard tail to Max. Run the 27B at low or medium reasoning for the bulk of traffic, escalate on confidence thresholds or explicit failure, and you get most of the frontier quality at a fraction of aggregate spend.

Because both sit behind the same OpenAI-compatible endpoint on Qubrid, that routing is a string change in your model parameter, not an integration project.

Troubleshooting and common errors

Reasoning text appearing in your user-facing output. The model wraps thinking in <think>...</think> before the answer. Over the API, read delta.reasoning_content (or delta.reasoning) separately from delta.content as shown above. If you are self-hosting, this is the missing --reasoning-parser qwen3 flag.

Model not found errors. The string is Qwen/Qwen3.8-27B. Not qwen3.8-27b, not Qwen3.8-27B, not qwen/qwen3.8-27b. Case and the organisation prefix both matter.

Responses truncating mid-reasoning. Your max_tokens is being consumed by the reasoning trace before the answer starts. Either raise the budget or lower reasoning_effort. On a small budget with xhigh set, the model can spend the entire allocation thinking.

Repetition loops. Raise presence_penalty toward 2.0, but not to the ceiling - the Qwen team warns that high values can cause language mixing and a slight quality drop.

Degraded quality on short prompts after enabling long context. If you extended context with YaRN, static scaling applies the same factor regardless of input length. Set factor to match your actual typical context, or disable the override for short-prompt traffic.

Unexpectedly high bills. Check reasoning_effort first. It is almost always this.

Migrating an existing integration

If you already call another OpenAI-compatible model, migration is three changes:

  1. Base URL to https://platform.qubrid.com/v1

  2. API key to your Qubrid key

  3. Model string to Qwen/Qwen3.8-27B

Then four things worth doing before you scale:

  • Set reasoning_effort explicitly. Do not inherit the xhigh default by omission.

  • Update your sampling parameters to the model card values in the table above. Framework defaults tuned for other models will underperform here.

  • Restructure your prompt so invariant content comes first, to earn cache hits at $0.11 rather than $0.58.

  • Handle the reasoning delta field if you stream, so thinking does not surface to users.

Frequently asked questions

What is Qwen3.8-27B? A 27-billion-parameter dense vision-language model from the Qwen team, released August 14, 2026 under Apache 2.0. It supports text, image and video input, has a 262,144-token native context window extensible to 1 million tokens, and offers configurable reasoning depth.

How much does Qwen3.8-27B cost per 1M tokens? On Qubrid AI, $0.58 per 1M input tokens and $3.45 per 1M output tokens, with implicit cached input at $0.11 per 1M tokens.

Are reasoning tokens billed separately? No, they bill at the output rate of $3.45 per 1M tokens. Since the model defaults to xhigh reasoning effort and Artificial Analysis measured it generating roughly 3.3x the peer median in output tokens, tuning reasoning_effort is the highest-leverage cost control available.

What is Qwen3.8-27B's Intelligence Index score? 52 at xhigh reasoning effort, 44 at medium, and 35 with reasoning disabled, per Artificial Analysis.

What does Qwen3.8-27B score on SWE-bench Pro? 61.7, per Qwen's own evaluation using the Claude Code harness at temperature 1.0 with a 256K context window.

What does Qwen3.8-27B score on GPQA Diamond? 89.2, per the official model card. This is one of the benchmarks where it trails frontier models rather than leading.

Does Qwen3.8-27B beat Claude Opus? On specific measures, yes. It places above Claude Opus 4.8 on the Artificial Analysis Agentic Index by under one point, and above the listed Opus 4.6 Max result on SWE-bench Pro and LiveCodeBench in Qwen's own table. On Humanity's Last Exam, GPQA Diamond and Terminal-Bench, Opus leads. Narrow benchmark wins are not model equivalence.

Are Qwen3.8-27B's benchmarks independently verified? Partly. The Artificial Analysis Intelligence and Agentic Index scores are independent, as is the LlamaIndex ExtractBench result. QwenSWEBench, CoWorkBench and RecreationBench are Qwen's internal evaluations and have not been reproduced externally.

How does Qwen3.8-27B compare to Qwen3.6-27B? 52 versus 38 on the Artificial Analysis Intelligence Index, at identical parameter count and near-identical architecture. The gains came from post-training rather than scale.

Is Qwen3.8-27B open source? Yes. The weights are published under Apache 2.0, which permits commercial use, modification, fine-tuning and redistribution without royalty obligations.

What is the Qwen3.8-27B context length? 262,144 tokens natively, extensible to 1,000,000 using YaRN RoPE scaling. The Qwen team cautions that static YaRN implementations can degrade performance on shorter inputs.

Does Qwen3.8-27B support vision? Yes, natively. Images and video, including STEM diagrams, document intelligence and hour-scale video understanding. It scores 84.3 on OSWorld-Verified for computer use and 91.1 on OmniDocBench 1.5 for document intelligence.

Why is Qwen3.8-27B so slow, and how do I speed it up? It defaults to xhigh reasoning effort, which produces very long reasoning traces, and dense models are memory-bandwidth bound. Set reasoning_effort to low or medium, or disable thinking for structured tasks.

What hardware do I need to run Qwen3.8-27B locally? Roughly 56GB of GPU memory at BF16, about 31GB at FP8, around 25GiB at NVFP4, and about 16GB at Q4_K_M, before KV cache and runtime buffers. A 24GB-class card is a plausible target at 4-bit.

Is the API cheaper than self-hosting? Below roughly the volume where you would saturate a dedicated GPU, yes, once you count hardware, engineering time and idle capacity. Above it, self-hosting wins.

Can I fine-tune Qwen3.8-27B? Yes. Apache 2.0 permits it, and hundreds of community fine-tunes, adapters and merges already exist on Hugging Face.

Does the price change with context length? No. The rate is flat across the native context window. Longer prompts cost more because they contain more tokens, not because of a tier change.

Get started

Qwen/Qwen3.8-27B is live now on the Qubrid AI platform at $0.58 per 1M input tokens.

  1. Create an account and generate an API key at https://platform.qubrid.com/model/qwen3.8-27b

  2. Point your existing OpenAI SDK at https://platform.qubrid.com/v1

  3. Set model="Qwen/Qwen3.8-27B"

  4. Set reasoning_effort before you scale

Qubrid AI serves 60+ open-source models behind a single OpenAI-compatible API, alongside on-demand GPU compute and on-premises AI appliances for teams that need to own the hardware. Same key, same endpoint, no rewrites when you switch models.

Back to Blogs

Related Posts

View all posts

Don't let your AI control you. Control your AI the Qubrid way!

Have questions? Want to Partner with us? Looking for larger deployments or custom fine-tuning? Let's collaborate on the right setup for your workloads.

"Qubrid's medical OCR and research parsing cut our document extraction time in half. We now have traceable pipelines and reproducible outputs that meet our compliance requirements."

Clinical AI Team

Research & Clinical Intelligence