Qwen3

Qwen3 是阿里云千问团队开发的大语言模型系列，于 2025 年 4 月 29 日首次发布。最初推出的文本模型阵容既包括稠密模型，也包括混合专家模型，模型权重以 Apache 2.0 许可证发布，可供公众下载。该系列是 Qwen2.5 的后续版本，支持多语言文本生成、指令遵循、数学解题、编程以及与外部工具交互。(alibabagroup.com)

最初的 Qwen3 模型的一项显著特点是将“思考”与“非思考”模式集成在同一个模型中：模型既可以在回答前生成中间推理过程，也可以不输出这些额外内容，直接作答。这一设计将模型的行为与神经网络推理阶段分配的计算量联系起来。后续发布的 Qwen3-2507 则将这两种行为分离，分别提供专门的 Thinking 和 Instruct 模型检查点。更广泛的 Qwen3 生态还包括专用于编程、检索、视觉语言及多模态任务的模型，其架构与能力需要与最初的文本模型加以区分。(github.com)

开发与发布历史

Qwen3 由阿里云 Qwen 团队开发，是 Qwen2 和 Qwen2.5 两代模型的后继系列；后两者分别于 2024 年 6 月 6 日和 9 月 19 日发布。该项目也借鉴了团队在 QwQ 推理模型方面的研究成果。“Qwen3”指的是一系列大语言模型及其可下载的检查点，而非单一的聊天机器人或托管产品。Qwen Chat 提供面向用户的对话界面，阿里云百炼（Model Studio）则通过应用程序编程接口（API）提供托管模型访问服务；这些访问渠道与开发者可自行下载并独立运行的模型权重有所区别。(github.com)

2025 年 4 月 29 日，阿里巴巴的公司公告和 Qwen 团队的发布文章《Qwen3：思考更深，行动更快》同时宣布了 Qwen3 的首次发布。首批发布包含八种规模的模型：六款稠密模型和两款混合专家模型，总参数量从约 6 亿到 2350 亿不等。模型权重以 Apache 2.0 许可证通过 Hugging Face、ModelScope 等平台的仓库开放下载。发布文章提供了模型规格、评测结果和运行示例，并区分了经过后训练的检查点及其对应的预训练“Base”检查点。因此，此次公开发布不仅提供了在线演示的访问入口，还包含可下载的模型文件，以及用于识别和使用具体模型的文档。(alibabagroup.com)

4 月发布的后训练模型的一项标志性特征，是在同一个检查点中融合了思考与非思考两种行为模式：前者在给出答案之前生成中间推理过程，后者则直接作答。这不同于分别使用通用聊天模型和推理模型的做法。随后于 2025 年 5 月 14 日首次提交至 arXiv 的《Qwen3 技术报告》，记录了该次发布所涉及的架构、预训练、后训练和评测工作。作者名单包括 An Yang、Binyuan Hui、Junyang Lin 等贡献者。因此，该报告是在首批权重发布后发表的，而非与权重同步发布。(arxiv.org)

Qwen3-2507 更新改变了这种发布形式，转而分别提供 Instruct 和 Thinking 检查点。该轮发布始于 2025 年 7 月 21 日推出的 Qwen3-235B-A22B-Instruct-2507，随后于 7 月 25 日推出 Qwen3-235B-A22B-Thinking-2507。Instruct-2507 仅保留非思考行为，不输出思考内容块；Thinking-2507 则仅保留思考行为，其默认聊天模板会启动推理序列。因此，原版混合模型的模式切换控制方式并不普遍适用于这些更新版本：选择回答风格时，需要选择相应的检查点，而不再只是更改同一个混合模型中的某项设置。(github.com)

规模较小的混合专家模型随后也迎来更新：Qwen3-30B-A3B-Instruct-2507 于 2025 年 7 月 30 日发布，Qwen3-30B-A3B-Thinking-2507 于 7 月 31 日发布。Qwen3-4B-Instruct-2507 和 Qwen3-4B-Thinking-2507 均于 8 月 6 日发布，仓库将其称为 2507 系列的最后一批开放发布。因此，尽管这些模型都采用“2507”标识，实际发布过程延续到了 8 月，且仅涵盖三种规模，并未覆盖 4 月首批模型的所有规模。项目文档随后将最初的混合版本称为“Qwen3-2504”，以区别于这些分别进行后训练的 2507 变体。(github.com)

最初发布的模型阵容与命名

2025 年 4 月 29 日发布时，Qwen3 共提供八种模型配置：六款稠密模型——Qwen3-0.6B、Qwen3-1.7B、Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Qwen3-32B，以及两款稀疏专家混合模型（MoE）——Qwen3-30B-A3B 和 Qwen3-235B-A22B。这些名称中的 B 表示十亿参数，而非模型文件大小或训练数据量。名称中的数字是经过取整的规模标记：例如，Qwen3-8B-Base 的模型卡记载其参数量为 82 亿，而非恰好 80 亿。(qwenlm.github.io)

MoE 模型的名称区分了总参数量与推理时为每个 token 激活的参数子集。因此，30B-A3B 表示总参数量约为 300 亿，激活参数量约为 30 亿；其模型卡给出的更精确数值分别为 305 亿和 33 亿。235B-A22B 表示总参数量为 2350 亿，每个 token 激活 220 亿参数。这两款模型在每个 MoE 层中都会从 128 个专家中选择 8 个。激活参数量描述的是稀疏计算，并不意味着整个检查点存储的参数量减少到了 30 亿或 220 亿。稠密模型不存在这种专家选择上的区分。(huggingface.co)

检查点名称也标明了训练状态。-Base 后缀表示预训练检查点，例如 Qwen3-8B-Base，其模型卡将训练阶段标为“预训练”。最初发布的后训练检查点则采用不带后缀的名称，例如 Qwen3-30B-A3B；这些模型经过了指令遵循适配，并在同一个检查点中集成了思考与非思考两种运行模式。因此，最初的 Qwen3 名称中没有 -Instruct，并不表示它是基础模型。预训练和后训练是不同的检查点阶段，而非额外的模型规模或不同的参数量计数方式。(huggingface.co)

下表列出了最初发布的不带后缀的后训练模型阵容。参数量采用名称中所表示的标称值；“原生上下文”指预训练阶段达到的序列长度。发布公告中的上下文数值单独列出，因为其中的 128K 不应理解为原生训练长度。全部八种配置均完成了长度为 32,768 个 token 的长上下文预训练。(qwenlm.github.io)

表中规格依据发布公告和最初的技术报告。(qwenlm.github.io)

最初的 MoE 模型卡明确区分了原生与扩展上下文窗口：两款模型均注明，原生长度为 32,768 个 token，采用 YaRN 位置缩放后可达 131,072 个 token。另一处文档差异涉及 Qwen3-4B：4 月发布时的表格将其上下文长度列为 32K，而 2025 年 5 月 14 日的技术报告则列为 128K。上表保留了发布时的数值，没有不加说明地替换为后续报告中的规格；这两个数值都不改变文档所记载的 32,768 个 token 的预训练长度。(huggingface.co)

Transformer架构与专家路由

最初发布的 Qwen3 模型采用仅解码器式的 Transformer架构：词元嵌入依次经过由因果自注意力和前馈计算组成的模块，这些子层均设有残差连接。因果掩码阻止当前位置关注后续位置，因此，用于预测下一个词元的表示仅依赖于前面的序列。最后经过归一化和词表投影，得到下一个词元的分数。在自回归生成过程中，每次选出的词元都会先追加到序列中，再进行下一次预测；因此，模型将序列概率表示为 $p(x_1,\ldots,x_T)=\prod_{t=1}^{T}p(x_t\mid x_{<t})$。这一计算结构同时适用于稠密模型和混合专家模型。(github.com)

Qwen3 使用分组查询注意力（GQA），即多个查询头共享一个键值头，而不是为每个查询头分别设置一组键和值。这种设计在保留多个查询投影的同时，减少了生成过程中所需的键值缓存。例如，Qwen3-8B 有 32 个查询头和 8 个键值头，而 Qwen3-235B-A22B 有 64 个查询头和 4 个键值头。旋转位置嵌入（RoPE）在计算注意力分数之前，通过旋转查询向量和键向量来编码位置信息。Qwen3 还采用查询—键归一化：在旋转位置编码之前，分别对每个头的查询向量和键向量进行均方根归一化。技术报告指出，新增这一操作以及移除查询、键和值投影中的偏置，都是为了提高训练稳定性。(arxiv.org)

这些模块采用预归一化布局，在注意力计算和前馈子层之前分别应用 RMSNorm。与先减去均值的层归一化（LayerNorm）不同，RMSNorm 使用向量的均方根值和一个可学习的缩放系数对其进行缩放。前馈网络使用 SwiGLU：先对输入进行两路投影，对其中一路应用 SiLU 激活函数，再将两路结果逐元素相乘，最后通过一次投影，将结果映射回模型的隐藏维度。其简化表示为 $W_{\mathrm{down}}[\operatorname{SiLU}(W_{\mathrm{gate}}h)\odot(W_{\mathrm{up}}h)]$。在稠密模型中，同一层的每个词元都使用同一个前馈网络；稀疏模型则将词元路由至不同的专家网络。(github.com)

在最初发布的混合专家（MoE）模型 Qwen3-30B-A3B 和 Qwen3-235B-A22B 中，每个专家组包含 128 个专家，每个词元从中选择 8 个。通过训练得到的路由器根据词元的隐藏状态为各专家评分，选出得分最高的 8 个，并使用路由权重组合其输出。专家选择取决于具体词元和所在层，而不是将整个请求固定分配给某一个专家。与 Qwen2.5-MoE 不同，这些模型没有负责处理所有词元的共享专家。开发者还表示，模型使用了全局批次负载均衡损失，在促进专家分工的同时调节专家利用率。(arxiv.org)

从 128 个专家中选择 8 个，使专家计算具有稀疏性，但并不意味着模型检查点会缩减为仅包含 8 个专家。最初的旗舰模型约有 2350 亿个参数，每个词元激活约 220 亿个参数；除了选中的专家，注意力及其他非专家组件也会参与计算。因此，$8/128=6.25\%$ 表示的是某一层中被选中专家的比例，而不是全部模型参数中被激活的比例，也不意味着端到端延迟会按相同比例降低。未被选中的专家权重仍是模型的一部分，必须保持可用，以供后续路由选择。这种架构节省的主要是每个词元所需的专家计算量，而非免除了存储全部权重的需求。(arxiv.org)

预训练数据与多语言覆盖

Qwen 团队披露，2025 年发布的初代 Qwen3 使用了约 36 万亿个词元的预训练数据，覆盖 119 种语言和方言；相比之下，Qwen2.5 使用了 18 万亿个词元，覆盖 29 种语言。这些语料规模和语言覆盖范围的数据由开发者报告，并非对语言能力的独立测评结果。公布的语言清单不仅包括英语和汉语，还包括斯瓦希里语、老挝语、高棉语和海地克里奥尔语等。汉语方面则覆盖普通话、粤语以及若干地方变体。(qwenlm.github.io)

该语料库结合了网页材料、从文档中提取的文本以及模型生成的材料。团队使用 Qwen2.5-VL 从 PDF 文档中提取文本，再由 Qwen2.5 对提取出的内容进行优化。Qwen2.5-Math 和 Qwen2.5-Coder 则生成了额外的数学和编程材料，包括教科书、问答对和代码片段。因此，数据扩充既涉及提取现有的书面内容，也包括针对特定领域合成样例，而不只是收集更多网页。(qwenlm.github.io)

质量控制措施包括一套应用于逾 30 万亿个词元的多语言标注系统。该系统对教育价值、学科领域、内容领域及安全相关特征进行标注，为数据筛选和混合方案的选择提供支持。团队借助较小的代理模型和消融实验，测试了样本级的数据混合方案，而非仅在来源或领域层面调整比例。技术报告还介绍了涵盖数十个领域、规模达数万亿词元的合成数据。这些流程是作为语料库构建方法披露的，并不保证每个保留的样本都正确无误。(arxiv.org)

预训练分为三个阶段。S1 使用超过 30 万亿个词元，序列长度为 4,096 个词元，以培养语言能力并积累通用知识。S2 新增约 5 万亿个词元，同时提高 STEM（科学、技术、工程和数学）、编程及推理材料的占比。最后一个阶段使用高质量长序列，将训练上下文窗口扩展至 32,768 个词元。这一训练安排既调整了内容侧重，也在最后改变了序列长度。(qwenlm.github.io)

应当区分宣称的语言覆盖范围与特定任务上的实证结果。报告中针对具体语言的评测涵盖 12 种语言；覆盖面更广的 Belebele 自然语言理解评测则使用了 80 种受支持语言，排除了 42 种被描述为未经优化的语言。在思考模式下，Qwen3-235B-A22B 在西班牙语 MMMLU 上得分为 86.7，在阿拉伯语 MMMLU 上得分为 83.6。这些是经过后训练的模型检查点的成绩，并非单独衡量预训练效果的结果。这些结果说明了为什么比较时需要明确语言、任务、模型检查点和运行模式：被列入 119 种语言并不意味着各语言的能力相当，而知识类基准测试也不能直接衡量翻译质量或对话流畅度。(arxiv.org)

后训练与知识蒸馏

Qwen3 最初的后训练流程先培养长程推理能力，再融入直接作答的行为。Qwen 团队于 2025 年 4 月 29 日发布的说明将这一流程分为四个依次进行的阶段：长思维链冷启动、以推理为重点的强化学习、思考模式融合，以及通用强化学习。冷启动阶段通过对数学、编程、逻辑推理和 STEM 学科的详细解题过程进行微调，在开展奖励驱动的优化之前建立推理模式。(qwenlm.github.io)

第二阶段从模仿解题示例转向依据可验证的结果优化回答。基于规则的奖励为推理任务提供反馈，同时增加强化学习的计算投入，以支持探索不同的解法。技术报告明确列出了 3,995 组查询—验证器配对，并采用组相对策略优化（GRPO）。对于 Qwen3-235B-A22B，开发者报告称，经过 170 步强化学习，其 AIME 2024 得分从 70.1 提升至 85.1。这些数字描述的是该次训练的结果，并不代表模型性能提升的普遍保证。(qwenlm.github.io)

随后，思考模式融合阶段通过进一步的监督学习，将长推理示例与常规指令微调数据相结合。其目的是保留推理行为，同时让同一个模型检查点学会在不输出长篇推理过程的情况下作答。指令示例展示了期望的回答方式，而随后的通用强化学习阶段则针对指令遵循、格式控制和智能体能力等 20 多项任务优化模型行为。因此，在这一流程中，回答模仿与基于奖励的优化发挥着不同的作用。(qwenlm.github.io)

通用强化学习使用了三种奖励机制：通过规则检查可客观评估的要求；由 Qwen2.5-72B-Instruct 参照标准答案为回答评分；由基于人类偏好数据训练的奖励模型，在没有参考答案的情况下为开放式回答评分。与偏好相关的目标涵盖有用性、互动吸引力和风格，作为侧重正确性和格式的奖励的补充，而非替代。(arxiv.org)

较小规模的模型检查点采用了由强到弱的知识蒸馏，而不是各自完整重复上述四个阶段。这一路径涵盖 Qwen3-0.6B、1.7B、4B、8B 和 14B，以及 Qwen3-30B-A3B。最初的离策略蒸馏使用教师模型在两种思考模式下生成的回答。随后的同策略蒸馏则使用学生模型自身生成的回答，通过最小化KL散度，使学生模型的词元预测 logits 与 Qwen3-32B 或 Qwen3-235B-A22B 的相应输出对齐。这使教师模型的指导能够作用于学生模型自行生成的序列，而不只是固定的一组教师答案。开发者报告称，在他们的对比中，这种方法消耗的 GPU 小时数约为四阶段方法的十分之一。(arxiv.org)

思考模式与推理时计算

2025 年 4 月 29 日发布的首批经过后训练的 Qwen3 检查点，在同一套模型权重中融合了思考与非思考两种行为。思考模式会在给出答案前生成中间推理过程，而非思考模式则直接作答，不输出这段额外内容。开发者将其定位为一种根据任务难度分配推理时计算资源的方式：数学或编程问题可以使用更多推理，而日常对话则可以采用更快的模式。这一区别在于同一检查点如何生成回答，而不是在分别加载的不同模型之间进行选择。(github.com)

模式选择分为两个层级。在首批检查点的聊天模板中，tokenizer.apply_chat_template(..., enable_thinking=True) 默认启用思考；将其设为 enable_thinking=False 则相当于一个硬开关，会禁止生成思考内容。在思考功能保持启用的情况下，用户消息或系统消息中的 /think 和 /no_think 可提供更灵活的提示工程层面的控制；在多轮对话中，最近一条指令决定后续回答采用的模式。例如，可以先用 /no_think 要求直接作答，再在下一轮用 /think 要求进行推理。这些文本指令无法覆盖 enable_thinking=False 的设置。使用软性的非思考指令时，输出中可能仍会保留一个空的思考块；使用硬开关时，模型既不会生成思考内容，也不会生成该思考块。(huggingface.co)

思考输出与最终答案位于回答的不同部分，通常用 <think> 和 </think> 分隔。应用程序可以在结束分隔符处拆分生成的序列，而不必将整个序列都作为答案展示。推理服务器的推理解析器可自动完成这种分离：项目示例在通过 vLLM 和 SGLang 部署首批检查点时，均使用 --reasoning-parser qwen3，以便通过 API 分别提供中间文本和答案文本，通常对应 reasoning_content 和 content 字段。解析改变的是返回给外围软件的内容表示形式；它本身并不是决定模型是否生成推理内容的控制机制。(github.com)

思考预算限制的是中间内容的生成量，而不只是从两种模式中选择一种。技术报告描述的方法是：当思考部分达到用户设定的阈值时，停止生成，插入一条要求根据已有推理给出解答的指令以及结束分隔符，然后继续生成最终回答。这与单纯耗尽总输出词元上限不同，后者可能在答案尚未完成时就终止生成。在开发者的实验中，图 2 展示了 Qwen3-235B-A22B 在涵盖数学、编程及科学、技术、工程和数学（STEM）的四项评测中，基准表现随着思考预算增加而逐步改善。生成更多词元意味着需要更多计算，并延长最终答案给出前的等待时间，因此存在延迟与性能之间的权衡。这些汇总结果并不能证明，对于任何一道具体问题，回答越长就越正确；报告也将输出长度扩展到 32K 词元以上视为未来的探索方向，而非已经通过实验确立的结果。(arxiv.org)

Qwen3-2507 系列将这两种行为拆分到不同的检查点中。Qwen3-Instruct-2507 仅支持非思考模式，不生成思考块，也不再需要设置 enable_thinking=False。Qwen3-Thinking-2507 则仅支持思考模式；其默认聊天模板已提供起始标签 <think>，因此新生成的输出可能包含 </think>，却不包含由模型生成的起始标签。相应地，项目的服务部署示例为这些 Thinking 检查点在 vLLM 中指定 deepseek_r1，在 SGLang 中指定 deepseek-r1，而不是使用最初的 qwen3 解析器。因此，不能假定 4 月发布的检查点所采用的混合模式切换控制，同样适用于后来带有 Instruct-2507 或 Thinking-2507 后缀的所有模型。(github.com)

上下文窗口与长文档处理

Qwen3 的上下文窗口以词元为单位衡量，而不是按字数或页数计算。这里的输入长度，是指经过聊天格式化后，由分词与词元化生成的序列长度，其中包括指令、对话历史和文档正文。输入容量、输出上限和序列总容量是不同的概念：max_new_tokens 限制的是新生成的词元数，而非提示词长度；上下文预算则同时涵盖输入与生成的输出。因此，生成的思考内容也会与最终答案一样占用空间。对于总容量为 $C$ 的部署，若输入包含 $I$ 个词元，则最多还可生成 $C-I$ 个词元；如果另有更低的输出上限，还须受该上限约束。Qwen 的示例分别对格式化后的提示词进行词元化，并设置 max_new_tokens；原始 Qwen3-8B 的模型卡也明确说明，长上下文长度同时包括输入和输出。(qwen.readthedocs.io)

2025 年 4 月 29 日发布时的规格为 Qwen3-0.6B、Qwen3-1.7B 和 Qwen3-4B 标注了 32K 上下文，为 Qwen3-8B、Qwen3-14B、Qwen3-32B、Qwen3-30B-A3B 和 Qwen3-235B-A22B 标注了 128K 上下文。这些对外公布的容量不应被理解为相同的原生训练长度：技术报告指出，所有原始模型都在 32,768 词元的长度下接受了长上下文预训练。报告后续的架构表还将 Qwen3-4B 列为 128K，与发布时表格中的 32K 规格不同。因此，有必要区分发布当日的规格与后续文档记载的外推能力。(qwenlm.github.io)

对于原始 Qwen3-8B 检查点，模型卡注明其原生上下文长度为 32,768 词元，使用 YaRN 后可达 131,072 词元。YaRN 是一种将旋转位置编码扩展到原始范围之外的方法。文档给出的配置将 rope_type 设为 yarn，将 factor 设为 4.0，并将 original_max_position_embeddings 设为 32768；vLLM 示例还另外设置了 --max-model-len 131072。因此，仅提高服务器的长度上限并不是文档所述的扩展流程。模型卡还提醒，静态 YaRN 无论实际输入长度如何，都会采用相同的缩放比例，因此可能降低短文本处理性能。(huggingface.co)

Qwen3-2507 将文档标示的上下文规格提升到了 256K；例如，Qwen3-30B-A3B-Instruct-2507 标明其原生支持 262,144 个词元。2025 年 8 月 8 日，项目宣布，30B-A3B 和 235B-A22B 这两种 MoE 规模的 Instruct-2507 与 Thinking-2507 变体专门获得了约一百万词元的支持。它们的模型卡要求用提供的 config_1m.json 替换 config.json，以配置长度外推和稀疏注意力。这一扩展结合了双分块注意力（Dual Chunk Attention）与 MInference 稀疏注意力。文档中的推理服务示例启用了 Dual Chunk Flash Attention 后端，将序列上限设为 1,010,000，并使用分块预填充；235B Instruct 的示例还指定了八路张量并行，并将并发序列数设为一。这些配置针对特定检查点和后端，并非适用于所有 Qwen3 模型的通用设置。(github.com)

长上下文评测检验的是信息能否继续被有效利用，而不只是软件能否接受某个序列。原始技术报告使用了 RULER，其任务不限于单项信息检索，还包括多跳追踪、信息聚合和问答。在使用四倍 YaRN 缩放的情况下，开发者报告称，Qwen3-235B-A22B 在非思考模式下的得分为 4K 长度时 97.7、128K 长度时 90.6；思考模式评测将思考词元上限设为 8,192，在 128K 长度下得分为 86.0。更新后的 30B-A3B Instruct 模型卡报告了一项百万词元版 RULER 评测，每个长度使用 260 个样例：其全注意力配置在启用双分块注意力的情况下，4K 长度得分为 98.0，256K 为 82.5，1000K 为 72.8。这些随长度变化的结果说明，能够接受的最大长度并不等同于始终如一的检索准确率，也不意味着能够可靠地理解任意长文档。(arxiv.org)

能力与基准评测

Qwen 团队的报告分别评估数学推理、科学知识、编程、指令遵循、多语言任务和工具使用能力。数学测试包括美国数学邀请赛（AIME）和 MATH-500：前者的 2024 年及 2025 年评测各包含 30 道竞赛题，后者是一个包含 500 道题目的数学评测集。科学能力评测采用 GPQA，该基准由 David Rein 及其同事于 2023 年提出，包含专家编写的生物学、物理学和化学多项选择题。Qwen3 的原始报告明确采用 GPQA-Diamond 子集，而非将 GPQA 的所有变体视为可以互换的评测。这些任务根据答案评分，并不评估原创科学研究能力。(arxiv.org)

编程评测包括 LiveCodeBench，该基准持续收集来自 LeetCode、AtCoder 和 Codeforces 等平台的竞赛题目。由于题库不断变化，版本和题目收集时间段至关重要：Qwen3 的原始评测使用第 5 版，涵盖 2024 年 10 月至 2025 年 2 月的题目；7 月发布的模型卡则使用第 6 版，涵盖 2025 年 2 月至 5 月的题目。因此，不能将原始旗舰模型在第 5 版上报告的 70.7 分，与 7 月某个模型检查点在第 6 版上的得分直接比较，仿佛两次评测使用的是同一组题目。LiveCodeBench 还区分了代码生成与自我修复、执行推理、测试输出预测等能力。(arxiv.org)

IFEval 由 Jeffrey Zhou 及其同事于 2023 年提出，用于衡量模型对可自动检查的指令的遵循程度，例如字数要求或多次包含指定关键词的要求。其严格的提示级指标要求满足一条提示中所有适用的约束，因此不同于开放式的偏好判断。多语言评测包括考察八种语言指令遵循能力的 Multi-IF、考察 14 种语言知识能力的 MMMLU，以及数学和逻辑推理测试。工具使用能力采用伯克利函数调用排行榜 BFCL v3 评测；原始报告明确说明采用函数调用格式评测，并在多轮测试中配置 64K 上下文。这些评测衡量的是 AI智能体的不同组成能力，而非某种单一的通用能力。(arxiv.org)

为确保可复现性，比较时需要提供确切的模型检查点、推理模式、采样设置、输出上限、基准版本、评测日期，以及结果是由开发者报告还是经独立复现。在 2025 年 5 月 14 日的报告中，思考模式的采样设置为 temperature 0.6、top-p 0.95 和 top-k 20。输出上限为 32,768 个词元，AIME 则提高至 38,912 个词元；AIME 准确率按每道题 64 次采样的结果取平均值，而非按“任意一次尝试成功即算正确”计分。7 月的 Thinking-2507 模型卡规定，高难度推理和编程评测的输出上限为 81,920 个词元，其他评测则为 32,768 个词元。报告发表日期和模型发布日期可用于确定结果的报告时期，但不应替代明确记录的实际运行日期。(arxiv.org)

开发者报告的部分对比结果展示了 7 月版本的变化，但并不能据此确立一个不注明时间的排名。2025 年 7 月 25 日发布的 Qwen3-235B-A22B-Thinking-2507，在其模型卡中与原始 Qwen3-235B-A22B 的思考模式进行比较：AIME 2025 得分从 81.5 提升至 92.3，LiveCodeBench v6 从 55.7 提升至 74.1，IFEval 从 83.4 提升至 87.8。7 月 21 日发布的非思考版本 Qwen3-235B-A22B-Instruct-2507，则与原始模型检查点的非思考模式进行比较：AIME 2025 从 24.7 提升至 70.3，IFEval 从 83.2 提升至 88.7。提升并非体现在所有项目上：同一张 Instruct 评测表显示，Aider-Polyglot 得分从 59.6 降至 57.3。这些数字描述的是指定模型检查点在开发者评测方案下的表现，其中也包含各自不同的计算预算；它们既不是独立复现结果，也不是在固定计算预算下对性能提升的衡量。(github.com)

部署、定制与工具集成

Qwen3 模型检查点可以直接通过 Hugging Face Transformers 运行，也可以集成到独立的推理服务中。项目提供的 Transformers 示例使用 AutoModelForCausalLM 加载权重，加载配套的分词器，应用其聊天模板，然后生成后续文本；文档要求的最低 Transformers 版本为 4.51.0。在服务部署方面，vLLM 和 SGLang 提供兼容 OpenAI 的 API，将模型执行与客户端应用分离。本地运行方案包括 llama.cpp 和 Ollama：前者通过命令行和服务器接口运行 GGUF 格式的模型，后者负责管理模型下载和本地服务。Qwen/Qwen3-8B 这样的检查点标识符用于标识模型文件，而 Ollama 标签或 GGUF 文件名还反映了封装、格式转换以及可能采用的量化方式。因此，这些分发版本的数值精度或运行时默认设置不一定相同。(github.com)

部署所需的硬件资源取决于权重精度、推理内核、加速器显存、序列长度和并发工作负载，而不只是参数量。Qwen 公布的推理测量结果展示了量化的影响：在一张配备 96 GB 显存的 NVIDIA H20 上，使用 Transformers 4.51.3 运行 Qwen3-8B，在批大小为 1、输入长度为 1 个词元、生成长度为 2,048 个词元的条件下，报告的 GPU 显存占用分别为 BF16 下的 15,947 MB、FP8 下的 9,323 MB，以及 AWQ-INT4 下的 6,177 MB。当输入长度增至 30,720 个词元、生成长度保持不变时，BF16 的显存占用增至 20,267 MB，AWQ-INT4 则增至 11,001 MB。这些数据是在特定配置下测得的，并非普遍适用的最低硬件要求。同一基准测试还表明，较低精度并不必然带来更高速度：在短输入条件下，使用 Transformers 的 FP8 测试结果比 BF16 更慢。(qwen.readthedocs.io)

上下文缓存的存储也是影响部署的一个因素：vLLM 文档将 PagedAttention 列为其管理注意力键和值的机制，同时还介绍了连续批处理和张量并行。批处理将多个请求放在一起调度，而张量并行则将模型计算分配到多个加速器上。在 Qwen 的 SGLang 0.4.6.post1 基准测试中，Qwen3-235B-A22B 在 BF16 精度下使用八张 H20 加速卡，张量并行度为 8；在 FP8 精度下则使用四张加速卡，并行度为 4。SGLang 会预先分配 GPU 显存，其中 mem_fraction_static 设为 0.85，因此该基准测试没有将其显存占用作为可与 Transformers 实测分配量直接比较的指标来报告。(qwen.readthedocs.io)

模型定制通过对指令—回答或对话样例进行监督微调来实现，可以更新全部模型参数，也可以采用参数高效适配方法。Qwen 官方训练文档包含专门面向 Qwen3 的 MS-SWIFT 指南，涵盖全参数训练、LoRA、QLoRA 和分布式执行。其中的 Qwen3-8B LoRA 示例采用 BF16，适配器秩为 8，最大训练序列长度为 2,048 个词元，并进行 16 步梯度累积；指南报告该示例的 GPU 显存占用为 22 GB。之后可以将适配器权重合并到基础模型中再导出。这些下游处理流程不同于开发者最初采用的预训练和后训练流程。(qwen.readthedocs.io)

工具集成在模型外围增加了一套执行框架。Qwen-Agent 于 2025 年 5 月 1 日加入了 Qwen3 工具调用演示和模型上下文协议实用指南；其 MCP 配置示例连接了记忆、文件系统和 SQLite 服务器。工具通过名称、描述和 JSON Schema 参数定义来说明。Qwen3 生成所请求调用的函数名称及参数，由框架将其解析为结构化字段；外围应用代码随后调用该函数，并将结果作为另一条对话消息返回。例如，官方函数调用指南提供了温度查询函数，并明确展示了应用如何解码参数、执行选定函数，以及在继续生成前追加函数输出。因此，模型生成的工具请求本身并不等于已执行的操作：对实际服务、文件系统、数据库或解释器的访问能力由外部软件提供。(github.com)

专用分支与架构扩展

Qwen3-Coder 专注于编程智能体和代码仓库级软件工程，而非仅生成孤立的函数。2025 年 7 月 22 日发布时，该系列推出了 Qwen3-Coder-480B-A35B-Instruct，这是一款混合专家（MoE）模型，总参数量为 4800 亿，每个词元激活 350 亿参数。开发者称，该模型使用了 7.5 万亿个词元进行预训练，其中约 70% 为代码，随后进行了执行驱动的强化学习，以及涉及反复调用工具和接收环境反馈的长程训练。其原生上下文长度为 256K 词元，旨在容纳代码仓库规模的材料，包括拉取请求。同期发布的 Qwen Code 是一款独立的命令行智能体，改编自 Gemini CLI，其提示词、解析器和函数调用支持均针对编程模型进行了适配；它是围绕模型构建的应用软件，而非另一个模型检查点。(qwenlm.github.io)

Qwen3-Embedding 和 Qwen3-Reranker 将 Qwen3 的稠密基础模型适配于信息检索，两者均提供 6 亿、40 亿和 80 亿参数的版本。嵌入模型将查询和文档编码为数值表示，并利用这些表示之间的相似度支持检索；文档列出的最大向量维度分别为 1,024、2,560 和 4,096，也可配置为更低的维度。重排序模型则联合考察查询与候选文档，根据“yes”和“no”的相对概率生成相关性分数。这一区别使两阶段搜索流程成为可能：先由嵌入模型筛选候选项，再由重排序模型对这个较小的集合重新排序。两个系列的文档均注明支持 32K 词元的序列长度。它们的主要输出是表示或相关性判断，而非常规的对话回答，不过可以为检索增强生成系统提供文档。(github.com)

Qwen3-VL 将该家族的能力扩展至图像和视频理解。其首批 235B-A22B Instruct 和 Thinking 模型检查点于 2025 年 9 月 23 日发布，随后又推出了规模更小的稠密和 MoE 变体。该架构引入了 DeepStack，用于整合视觉 Transformer 多个层级的视觉特征，并采用涵盖时间、宽度和高度的交错式多维位置编码。基于时间戳的视频处理能够定位序列中的事件，而不是仅将视频视为一组互不相关的静态图像。文档列出的应用包括读取图像中的文字、解读长文档、空间推理，以及根据视觉输入生成代码。这些能力以视觉和语言为输入，并生成文本响应，有别于语音生成流程。(github.com)

Qwen3-Omni 于 2025 年 9 月 22 日发布，可接受文本、图像、音频和视频输入，并增加了流式语音输出。其基于 MoE 的 Thinker–Talker 设计将多模态理解、文本响应生成与语音生成分离。输出模态取决于具体的模型检查点：Qwen3-Omni-30B-A3B-Instruct 包含两个组件，支持文本和音频输出；Thinking 检查点则包含 Thinker，输出文本。另有一个单独微调的 Captioner，用于生成详细的音频文字描述。因此，Omni 这一名称并不意味着每个检查点都会生成语音，而其音频处理能力也使它区别于专注图像和视频的 Qwen3-VL。(github.com)

Qwen3-Next 改变了计算架构，而不只是对原始模型进行专门化训练。80B-A3B 模型的总参数量约为 800 亿，但每个词元仅激活约 30 亿参数。其 48 层结构以三个 Gated DeltaNet 层后接一个门控全注意力层为重复单元，将循环式线性注意力处理与周期性出现的完整注意力机制相结合。稀疏前馈组件为每个词元从 512 个路由专家中选择十个专家，并同时使用一个共享专家。单独发布的 Instruct 和 Thinking 版本均采用这种混合设计，其配置不同于原始 Qwen3 的稠密和 MoE 架构。(huggingface.co)

模型检查点名称也应与托管产品标识符区分开来。例如，Coder 的发布文档使用 qwen3-coder-plus 指代托管 API，而可下载的旗舰模型则命名为 Qwen3-Coder-480B-A35B-Instruct。后续以小数编号的代际同样需要单独说明其架构：Qwen3.5 于 2026 年 2 月 15 日公布时，推出的是一款原生多模态的 397B-A17B 模型，将 Gated Delta Networks 与稀疏 MoE 计算相结合，而非仅仅为原始 Qwen3 的某个检查点改名。(qwenlm.github.io)

许可、透明度与已记录的局限性

最初发布的 Qwen3 模型采用 Apache 许可证 2.0，提供可下载的权重，并公开了推理实现和示例。因此，此次发布允许用户检查特定检查点并在本地运行，而不必完全依赖托管服务。不过，这种可获取性并不等于训练过程完全透明：技术报告介绍了约 36 万亿个预训练词元、数据处理方法以及分阶段训练流程，但此次发布并未提供完整的训练语料，也未提供可执行的原始训练基础设施重建方案。下载检查点有助于复现其推理行为，但仅凭这一点，并不能独立复现其训练过程。(arxiv.org)

该项目提供了多项与可复现性相关的具体材料。例如，Qwen3-8B 仓库包含模型卡、config.json、generation_config.json、五个 SafeTensors 权重分片及其索引，以及包括 tokenizer.json、tokenizer_config.json、vocab.json 和 merges.txt 在内的分词器资源。这些文件公开了加载检查点所需的架构配置、默认生成设置和文本编码资源。模型卡还补充了聊天模板示例、思考输出提取方法、采样设置以及部署说明，同时记录了一个明确的兼容性问题：低于 4.51.0 的 Transformers 版本会产生 KeyError: 'qwen3' 错误。技术报告则通过训练方法说明、基准测试定义、对比表格和消融实验，对这些材料作出补充，而非提供一套完整的端到端训练方案。(huggingface.co)

提示词和输出的处理方式取决于具体检查点。最初的混合检查点通过聊天模板提供 enable_thinking 参数；Qwen3-Instruct-2507 仅支持非思考模式，而 Qwen3-Thinking-2507 仅支持思考模式。后者的模板会插入起始分隔符 <think>，因此生成的文本可能包含结束标签 </think>，而不包含由模型自身生成的起始标签。README 中的服务端示例同样区分了不同的解析器：最初的 Qwen3 使用 qwen3，而 Thinking-2507 在 SGLang 中使用 deepseek-r1，在 vLLM 中使用 deepseek_r1。这些示例表明，不能假定不同发布版本之间的解析器配置可以互换。(github.com)

README 还记录了一项多步骤工具使用方面的注意事项：在会丢弃 reasoning_content 的服务配置中，移除该字段可能会降低思考模型与工具交互的效果。文档给出的解决办法是保留未经提取处理的输出，交由聊天模板处理。模型打包方式还带来了另一个识别问题。项目记录显示，截至 2025 年 8 月，Ollama 的 qwen3:30b-a3b 别名指向的是 qwen3:30b-a3b-thinking-2507-q4_K_M，不一定是较短名称所暗示的最初混合检查点。因此，仅凭别名无法确定具体检查点或权重精度。(github.com)

已公布的评估证据所能支持的结论范围有限，并不能证明模型在所有情况下都可靠。报告中的数学、编程、知识、指令遵循和多语言结果衡量的是模型在指定任务上的表现，并不能证明其在每一种应用或语言中都能给出正确结果。报告对常规得分与 pass@64 等多次采样指标的区分也很重要：多次生成尝试中有一次成功，并不等同于单次回答就能正确。生成的思考文本并不是形式验证证书。同样，报告提及对训练数据使用安全相关标注，描述的是一种筛选机制，并不能证明部署安全或不存在偏见；此类主张需要另行明确的评估作为依据，并说明所用的数据集、威胁模型和评分程序。(arxiv.org)

参考来源

1. GitHub - QwenLM/Qwen3: Qwen3 is the large language model series developed by Qwen team, Alibaba Cloud.github.com
2. Qwen3/README.md at main · QwenLM/Qwen3 · GitHubgithub.com
3. Alibaba Introduces Qwen3, Setting New Benchmark in Open-Source AI with Hybrid Reasoningalibabagroup.com
4. Qwen3: Think Deeper, Act Fasterqwenlm.github.io
5. Qwen3 Technical Reportarxiv.org
6. Qwen3 Technical Reportarxiv.org
7. Qwen/Qwen3-235B-A22B-Instruct-2507 · Hugging Facehuggingface.co
8. Qwen/Qwen3-235B-A22B-Thinking-2507 · Hugging Facehuggingface.co
9. Qwen/Qwen3-8B-Base · Hugging Facehuggingface.co
10. Qwen/Qwen3-30B-A3B · Hugging Facehuggingface.co
11. Qwen/Qwen3-235B-A22B · Hugging Facehuggingface.co
12. transformers/src/transformers/models/qwen3/modeling_qwen3.py at main · huggingface/transformers · GitHubgithub.com
13. transformers/src/transformers/models/qwen3_moe/modeling_qwen3_moe.py at main · huggingface/transformers · GitHubgithub.com
14. Qwen3：思深，行速qwenlm.github.io
15. Qwen/Qwen3-8B · Hugging Facehuggingface.co
16. Quickstart - Qwenqwen.readthedocs.io
17. YaRN: Efficient Context Window Extension of Large Language Modelsarxiv.org
18. Qwen/Qwen3-30B-A3B-Instruct-2507 · Hugging Facehuggingface.co
19. RULER: What's the Real Context Size of Your Long-Context Language Models?arxiv.org
20. GPQA: A Graduate-Level Google-Proof Q&A Benchmarkarxiv.org
21. Instruction-Following Evaluation for Large Language Modelsarxiv.org
22. LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Codearxiv.org
23. GitHub - QwenLM/Qwen3github.com
24. Speed Benchmark - Qwenqwen.readthedocs.io
25. vLLM - Qwenqwen.readthedocs.io
26. MS-SWIFT - Qwenqwen.readthedocs.io
27. GitHub - QwenLM/Qwen-Agentgithub.com
28. Function Calling - Qwenqwen.readthedocs.io
29. Qwen3-Coder: Agentic Coding in the Worldqwenlm.github.io
30. QwenLM/Qwen3-Embeddinggithub.com
31. Qwen3-VL/README.mdgithub.com
32. QwenLM/Qwen3-Omnigithub.com
33. Qwen/Qwen3-Next-80B-A3B-Instructhuggingface.co
34. Qwen3.5: Towards Native Multimodal Agentsqwen.ai
35. Qwen/Qwen3-8B at mainhuggingface.co
36. Qwen/Qwen3-8B · Hugging Facehuggingface.co