Qwen 4 Roadmap: Confirmed Training and Unverified 27B Report

Decisions that need different evidence

October 1 update: a migration deadline is separate from the Qwen 4 roadmap

As of October 1, Alibaba’s DeepSeek API documentation, updated September 28, lists October 10, 2026 as the delisting date for deepseek-v3, deepseek-v3.1, deepseek-v3.2, deepseek-v3.2-exp, deepseek-r1, deepseek-r1-0528 and the deepseek-r1-distill-qwen variants at 7B, 14B and 32B. The provider recommends qwen3.7-plus, qwen3.7-max and qwen3.6-flash. This is a Model Studio service notice; it does not establish that DeepSeek has discontinued those models everywhere. Official affected IDs and suggested models.

Alibaba’s retirement policy says API calls to retired models will fail from the retirement date, while request and token quotas decline beforehand. Its guidance is to inspect usage in the relevant region and test a replacement before switching. The page links separate October 10 notices, so this is a selected DeepSeek list rather than an inventory of every affected language or image model. Check the exact model ID and service region for your application instead of inferring coverage from a family name. Retirement impact and regional usage checks.

For a team using one of these hosted IDs, our editorial recommendation is to evaluate a documented replacement now rather than make the migration depend on the reported Qwen 4 tiers. The notice names other Qwen versions; it supplies no Qwen 4 launch date. A suggested replacement is also not evidence of equal behavior: retain checks for structured output, tool arguments and failure recovery, then compare results against your current acceptance criteria. We did not make inference calls or verify account-specific availability. The older roadmap and rumor sections below retain their original evidence dates. Provider replacement guidance.

The official announcement has a narrow meaning

Alibaba’s September 22 Apsara announcement says Qwen 4 is in training. It places Qwen 4.5 and Qwen 5 on a later roadmap projected at 5–10 trillion parameters. Those numbers refer to the later series, not a published specification for every Qwen 4 variant. Alibaba Cloud, September 22: official Qwen roadmap

Read a roadmap as a statement of intended development. A production decision needs a different evidence trail: a named artifact or service, documented conditions, and behavior that can be checked. Even an official announcement of training does not itself settle when a particular account can make a request. We have not established a current Qwen 4 release date, public endpoint, final context limit or price in this review.

For a project manager, the immediate benefit is a clear dependency list. Put model availability in the evaluation backlog rather than on the critical path of a delivery promise. If a planned feature needs a capability that the current system lacks, define that requirement now. Later, check the actual candidate against it instead of allowing an anticipated model name to stand in for a working implementation.

The 27B story is secondary reporting in this review

Yotta Labs’ September 23 article attributes four tiers—Max, Plus, Flash and 27B—to Apsara, describing 27B as intended for local use with open weights. We verified that this report exists. We did not independently authenticate its tier list against a primary model card or the original presentation. Yotta Labs, September 23: secondary 27B account

The distinction is not an accusation that the report is wrong. It is the boundary of our verification. The official announcement inspected for this article does not enumerate that list. Its omission neither disproves a conference slide nor authenticates the secondary account. Consequently, the 27B details stay attributed here, rather than becoming factual specifications in a canonical model profile. Alibaba Cloud, September 22: official Qwen roadmap; Yotta Labs, September 23: secondary 27B account

The potential impact is substantial if the reported local-deployment option becomes available: teams could investigate whether a new candidate fits their own hardware and operating requirements. That potential does not make release timing more certain. A useful follow-up would connect an official repository or model card to the precise version, license and supported inference implementation. Repeated articles describing the same conference are not automatically independent confirmations of those details.

September 30 follow-up: the unverified quality claim concerns Max

A public r/singularity post by PrisonOfH0pe claims that early Qwen 4 samples approach Fable / Opus-level quality. In a reply to a reader anticipating that performance from 27B, the poster says the claim concerns Max and leaves 27B’s eventual ability open. Search results associate the discussion with September 29; the fetched page displays relative ages. This is an unverified public quality rumor, not our assessment of either variant. Public claim and clarification.

The accessible text does not provide an authenticated original evaluator, exact checkpoints, prompts or reproducible results. A commenter objects that the circulated material lacks attribution; that objection is itself a public comment, not proof of fabrication. We verified the discussion and the poster’s clarification, not the underlying performance claim. If a future hosted model approached a relevant alternative on a reader’s tasks, it could change an evaluation shortlist. It would still say nothing by itself about a separate local model. Do not transfer the headline to 27B, infer a specific Opus version from the title, or treat this conversation as evidence of downloadable weights or working access. Discussion and attribution limitations.

A parameter label is not a hardware purchase order

Our recommendation for readers interested in the reported local variant is to wait for the actual deployment specification before buying equipment around its name. Keep architecture, weight precision, runtime overhead and intended context length as separate planning fields. A short model label cannot resolve all of them.

For a concrete evaluation, write down the workload first. A private document assistant processing one short question at a time and a service serving several long conversations need different capacity plans. Record the longest representative input, the desired output length, the number of concurrent requests and the response time the application can tolerate. These requirements remain useful regardless of whether the rumored variant eventually arrives.

Then test the documented artifact on equipment you already have access to, if appropriate, before committing to a larger deployment. Record failures such as allocation errors, unsupported operators or unacceptable response times separately from answer quality. These are proposed tests, not measurements of Qwen 4. Do not copy another generation’s memory estimate or license into the future model’s row; leave that row incomplete until the specific release supplies the missing evidence.

API teams should evaluate the service as well as the model

For a hosted integration, make the acceptance checklist specific to the application. An assistant that must return valid structured records needs checks for schema compliance and incomplete responses. A coding agent needs checks for tool arguments, error recovery and changes outside the requested scope. These are evaluation criteria, not claimed Qwen capabilities.

Save a small set of sanitized requests from the current system, together with the target outcomes. Include ordinary cases and cases that previously failed. When a documented candidate is usable, record its exact identifier, controls and service region alongside each run. If it exposes a different reasoning setting, explain the difference instead of presenting similarly named controls as equivalent. Keep retries visible because they affect both user experience and cost.

A provider’s token price is only one input to a deployment budget. Compare the total work needed for an acceptable outcome using the published billing rules at that time, including any separately charged features you actually use. Avoid a speculative price table while those rules are unknown. The practical preparation today is an evaluation harness with inspectable outputs, not a migration script aimed at a guessed endpoint.

What would justify a comparison or a confirmed profile

A useful future comparison should answer a defined choice: which available language model completes a particular task under acceptable access and operating conditions? It should not begin by assigning an unreleased candidate a position in a comparison. Our Qwen 4 entry remains a roadmap and reporting page until more specific evidence supports a versioned profile.

For local use, match candidates by feasible deployment conditions before comparing outputs. For an API assistant, match them by the application’s requirements and document any differences in tools or inputs. Preserve prompts and configuration revisions so a later result can be traced to what actually changed. DualView’s prompt-diff page can help inspect those text revisions; it does not turn them into an measurement of intelligence.

We will revisit the public claim when a provider announcement, model card or documented service adds concrete information. A new source could confirm the reported variant, change its name or leave its status unresolved. Any update should retain the original attribution and explain what changed. Until then, the useful outcome is a prepared decision process with explicit missing fields, rather than a claim that an impressive roadmap has already delivered a better model.

FAQ