Qwen 3 benchmark performance: cost per million tokens

Qwen 3 cost per million tokens looks cheap on paper, but the number alone tells you little about whether it fits your system. The open-weight family spans dense and MoE variants, and the effective price shifts dramatically between a hosted API, a self-hosted A100, and a quantized edge deployment.

Hosted API pricing is a blended average

Public inference gateways list Qwen 3 models at rates that undercut closed frontier models. The catch is that those rates bundle provider margin, idle capacity, and region-specific electricity into a single figure. You pay per token, but you don’t control batch size or quantization.

A typical call through an OpenAI-compatible client looks identical to any other model:

from openai import OpenAI

client = OpenAI(
    base_url="https://your-gateway.example/v1",
    api_key="sk-...",
)

resp = client.chat.completions.create(
    model="qwen3-235b-a22b",
    messages=[{"role": "user", "content": "Extract keys from this log"}],
    temperature=0.1,
)
print(resp.usage.model_dump())

The usage object returns prompt_tokens and completion_tokens. Multiplying by the published rate gives your Qwen 3 cost per million tokens for that request. But the rate card hides the variance: a 32B dense model and a 235B-A22B MoE have different serving economics, and providers pass those differences to you.

Self-hosting flips the cost model

When you run the weights yourself, the token price becomes a function of hardware amortization and utilization. The model is Apache 2.0, so there is no per-token license fee. Your only floors are silicon and power.

A first-order estimate for a single 80GB A100 serving Qwen3-32B in fp16:

gpu_hourly = 2.00  # $/hr for an A100 80GB on a typical cloud
tokens_per_sec = 31  # memory-bandwidth-bound decode for 32B fp16
tokens_per_hour = tokens_per_sec * 3600
cost_per_million = (gpu_hourly / tokens_per_hour) * 1_000_000
print(f"${cost_per_million:.2f} per million output tokens (single stream)")

That prints roughly $18 per million output tokens for a single uninterrupted stream. Terrible compared to hosted API quotes. The gap closes only when you drive batch utilization toward saturation. With continuous batching, aggregate throughput on the same card can climb by an order of magnitude, pushing the effective Qwen 3 cost per million tokens below hosted rates for high-QPS workloads.

Quantization changes the curve

AWQ or GPTQ at 4-bit shrinks the model to ~16GB, freeing memory for larger batches and enabling smaller GPUs. The tradeoff is measurable quality drop on reasoning-heavy tasks. For log parsing or classification, 4-bit Qwen3-32B is often indistinguishable from fp16. For agent planning, keep fp16.

vllm serve Qwen/Qwen3-32B \
  --tensor-parallel-size 1 \
  --quantization awq \
  --max-model-len 32768

Throughput is the real denominator

Qwen 3 cost per million tokens is inversely proportional to tokens/sec sustained per dollar of compute. A MoE like 235B-A22B activates ~22B params per token, so decode latency resembles a dense 22B even though the weight footprint is larger. That makes it unusually cost-efficient on GPUs with enough VRAM to hold the full expert set.

If your workload is bursty, you lose the utilization that makes self-hosting cheap. Hosted APIs then win because you pay zero when idle. If your workload is steady, owning the stack wins past a break-even QPS that you can compute from the script above.

Context, caching, and routing overhead

Long prompts dominate cost for retrieval-augmented pipelines. Qwen 3 supports prompt caching on several providers; a repeated system prompt billed at write cost once and read cost subsequently cuts effective input price by 5–10x in practice.

Client-side routing directives let you enforce this:

{
  "model": "qwen3-32b",
  "route": {
    "prefer": ["self-hosted-gpu"],
    "fallback": ["cloud-provider-x"]
  },
  "cache_control": {"type": "ephemeral"}
}

An OpenAI-compatible gateway such as n4n.ai forwards those cache-control hints and meters per-token usage, so the Qwen 3 cost per million tokens you see in billing matches the underlying provider rather than a markup. Automatic fallback matters when your self-hosted node saturates: the request spills to a cloud endpoint without code changes, but you still pay that endpoint’s rate for the spilled fraction.

Where Qwen 3 wins, where it doesn’t

Wins

• High-volume, latency-tolerant batch jobs where you can pack batches.
• Self-hosted compliance deployments where data egress fees dwarf token cost.
• Multilingual tasks: Qwen 3’s training mix covers 30+ languages at no extra token price.

Doesn’t

• Spiky interactive traffic under 10 QPS: hosted API avoids idle GPU burn.
• Tasks needing frontier reasoning: you may spend more on retries and eval than on tokens.
• Edge inference on consumer GPUs: 32B is still heavy without aggressive quantization.

Decision framework

Compute your steady-state QPS and average completion length. Plug into the hardware cost script with your own cloud rates. If the resulting self-hosted Qwen 3 cost per million tokens beats the API quote by >30% at your projected utilization, buy the GPU hours. Otherwise, route to a hosted endpoint and use caching to suppress input costs.

For most teams landing here from search, the answer is hybrid: self-host the 32B dense variant for bulk chores, keep a MoE API on standby for peak load. The raw per-million number is a starting point, not a verdict.