Qwen3

Qwen3 is the third-generation text model family from Alibaba Cloud's Qwen team, released on April 28, 2025. It covers six dense sizes (0.6B to 32B) and two MoE variants, all trained on approximately 36 trillion tokens across 119 languages. A key design choice is a unified thinking and non-thinking mode in every model, so developers can choose between step-by-step reasoning and fast single-pass responses without switching models.

General
Release date	28 Apr 2025
Developer	Qwen / Alibaba Cloud
Type	Open-weight text LLM family
License	Apache 2.0
GitHub	QwenLM/Qwen3
Hugging Face	huggingface.co/Qwen
Documentation	qwenlm.github.io/blog/qwen3

Core Features

Thinking/non-thinking mode: every model supports both step-by-step chain-of-thought reasoning and direct response generation within a single checkpoint.
Thinking budget: developers can set a token budget for the reasoning phase, allowing inference cost to be tuned per request.
Long context: models at 4B and above support 131,072-token context windows; 0.6B and 1.7B support 32,768 tokens.
Multilingual: pretrained on 119 languages and dialects.
Apache 2.0: all weights are released for commercial use, fine-tuning, and redistribution.

Model Variants

Variant	Total Params	Active Params	Context	Best for
Qwen3-0.6B	0.6B	0.6B	32K	Edge and on-device
Qwen3-1.7B	1.7B	1.7B	32K	Lightweight inference
Qwen3-4B	4B	4B	128K	Balanced performance
Qwen3-8B	8B	8B	128K	General tasks
Qwen3-14B	14B	14B	128K	Higher accuracy
Qwen3-32B	32B	32B	128K	Strong reasoning
Qwen3-30B-A3B	30B	3B	128K	Efficient MoE
Qwen3-235B-A22B	235B	22B	128K	Flagship MoE

Benchmarks

The flagship Qwen3-235B-A22B model scores:

AIME '24: 85.7
AIME '25: 81.5
LiveCodeBench v5: 70.7
BFCL v3: 70.8

Tools and Resources

Qwen3 Blog Post: official release notes and technical details.
Hugging Face (Qwen): download model weights and GGUF files.
Technical Report: arXiv paper covering architecture, training, and evaluation.
Ollama: run Qwen3 models locally.
Qwen API Platform: access models via OpenAI-compatible API.

Ecosystem and Integrations

Available on Hugging Face Hub in both standard and GGUF formats.
Accessible via Alibaba Cloud DashScope using an OpenAI-compatible endpoint.
Supported by Ollama, LM Studio, and major inference frameworks including vLLM and llama.cpp.
All sizes available for fine-tuning using standard supervised fine-tuning and RL pipelines.

Qwen3 weights are available immediately on Hugging Face. To access via API, generate a key on the Qwen API Platform and follow the Model Studio documentation.

Trajectory — Decision-Guided Delivery

A customer cancels a subscription renewal and unexpectedly loses access to time they already paid for. Trajectory turns that friction into a decision the people responsible for the experience can make without writing code. A guided GitHub issue captures what happened and the desired result. The installed Trajectory GitHub App presents clear outcomes: keep paid access, end it immediately, or propose a prorated refund. Selecting an outcome prepares a corresponding code and configuration change in a reviewable branch and pull request. Changing the decision creates a separate outcome and invalidates the earlier intent confirmation. A Vultr-hosted Go worker uses Vultr Serverless Inference to generate a bounded access-function candidate. A disposable, isolated container runs independent boundary tests; repository-defined assertions and a comparison against the proposed PR tree check the selected change. GitHub Checks connect the issue, choice, patch, test results and evidence for review. A separate containment demonstration tests that a host canary is inaccessible from the sandbox. The demo uses an illustrative customer and a fixed example proposing $18 for 18 unused days. It does not execute a refund or change a real customer account. Verification covers the stated test cases; intent review remains a human step before merge.

Aperture - Web Retrieval with Traceable Evidence

Aperture is an AI web retrieval agent built for AMD AI League Match 4. It accepts a natural-language question and an optional starting URL, navigates web pages, and returns a concise answer with supporting source URLs. The system combines asynchronous retrieval, structure-preserving parsing, and a locally hosted Qwen3-4B-Instruct-2507 model. It preserves headings, tables, and labeled fields so that names, dates, versions, and numeric values retain their context. Evidence checks verify literal support, source provenance, answer types, and requested qualifiers. When available evidence is insufficient, the agent returns an empty answer. Inference runs locally, and retrieval uses no paid search service or remote inference API. The submission is packaged as a prebuilt Docker image using the required ROCm base, with model weights included. Local validation covers extraction, output formatting, runtime behavior, and factual retrieval. General web accuracy remains limited by search availability, page access, model errors, and time budgets. AMD GPU execution and official evaluator acceptance have not yet been verified. The public repository includes implementation details, benchmark reports, and reproducibility documentation.

Exact Web Answer Agent (AMD AI League Match 4)

Match 4 entry: an agent that reads a natural-language request, navigates the given website (or a saved copy of it) and returns the one specific value the user asked for, with the page it came from. Not a summary and not a list of links. Match 4 image: docker.io/driedsandwich/amd-ai-league:m4-v1 How it works. Each request runs as a fresh python3 /app/app.py process with a 24-second internal deadline. It writes a well-formed placeholder JSON first, then fetches the start page with short timeouts, follows the same-site links whose text best matches the question, cleans each page to text (tables kept as rows) and ranks passages. A Qwen3-4B-Instruct model, loaded once at container start and kept resident on the AMD GPU behind a unix socket, picks the value from the top passages and names the supporting page. A rule-based extractor for prices, dates, versions, numbers and contacts is the fallback when the model has no time left. The answer is the value only; if the pages do not contain it, the agent returns an empty answer instead of guessing. Output: /app/output/<query-id>_output.json with answer, citations (source URLs, or corpus-relative paths when pages are given as a folder), sources, source_url and confidence. Because the detailed Match 4 harness was not published, the image follows the container contract shared by the earlier Matches: the mandated ROCm PyTorch base image, weights shipped inside the image, no downloads at start-up, and the model placed on the GPU explicitly. The script accepts several argument spellings (--query or --question, --query-id or --id, --url, --corpus for saved pages, --index, --input). No API keys; inference runs locally on the AMD GPU. Match 3 and Match 2 images are given in their Mini Challenge fields (docker.io/driedsandwich/amd-ai-league:mc3-v1 and docker.io/driedsandwich/amd-ai-league:mc2-v2).

AMD ROCm Grounded Web Agent

GroundedROCm is a 100% ROCm-native grounded retrieval engine powered by Qwen2.5-0.5B on AMD MI300X delivering verified JSON answers with zero hallucinations. Traditional search suffers from CUDA dependencies, high latency, API costs, and hallucinations. We solve it with a 5-stage local pipeline: Planner (Qwen2.5-0.5B via http://llama.cpp with fast-path for simple queries), Search Layer (Tavily / Qdrant / JSONL pluggable), Evidence Engine (deduplication + BM25 + compression), Synthesizer (warm http://llama.cpp server with schema-constrained JSON, max 96 tokens), and Guardrails (JSON repair + number/name grounding + URL validation). Result: 15MB binary via http://llama.cpp, small Docker size, ∼0.6s latency on MI300X, 98% grounding accuracy, 100% source validity, zero CUDA, zero external cost, instantly switchable to internal Qdrant for enterprise deployment.

GreYat Web Scout: grounded web retrieval

GreYat Web Scout is a Match 4 agent for intelligent web information retrieval. It takes a natural-language question, with an optional start URL, and returns one exact value together with the page it came from. How it works: a language model (Qwen3-4B-Instruct, served on the AMD GPU by a resident process so each query skips the load time) first plans the lookup: search queries, likely official URLs, and package or project names. In parallel the agent queries several search engines and Wikipedia, and for "latest version" questions it reads the authoritative registries directly (PyPI, npm, GitHub releases, endoflife.date). It fetches the best pages, keeps the passages that match the question, and asks the model to extract a single value and say which passage it came from. Grounding comes first. An answer is only returned if the value appears verbatim on the cited page, so the source URL always backs up the answer. If no page confirms it, the agent returns an empty answer instead of a guess, and answers to "latest" questions are never taken from the model's memory. Version strings and numbers are normalised (v-prefixes, LTS labels, thousands separators) to match the grader. Everything runs locally on AMD ROCm with no external API keys. In development, on a 30-question set covering facts, ports, people, dates and live package versions, the pipeline answered 26 correctly (tested with a hosted stand-in model, since GPU time was not available).

WebScout Exact: Match 4 Retrieval Agent

WebScout Exact is my entry for Match 4 of the AMD AI League (Intelligent Web Information Retrieval). The agent takes a natural-language question, optionally with a starting URL, and returns one exact value plus the source page it came from, not a summary or a list of links. It runs as a single Docker container built on the official ROCm PyTorch image, so it works on AMD Instinct GPUs. Pipeline: the question is classified into an answer type (number, date, version, price, name, phone and so on); the agent fetches the given URL or searches the web, follows the most relevant links, and cleans each page into plain text. Candidate values are extracted with rules for each answer type and checked by a local Qwen3-4B-Instruct model served from the container on the AMD GPU, which picks the value that best matches the question. The answer is normalised the way the grader compares answers and written to a JSON file with the answer, source URL and confidence. If the model is not available, a rule-based path still answers. Each query is designed to finish well under 30 seconds and the model loads during the startup window. On my own held-out test set it answers 7 of 8 questions correctly. No API keys are used: all reasoning runs locally on AMD hardware. Image: ghcr.io/solar-depin-hub/amd-match4-agent:v1