Qwen3.6 35B A3B 实测：优势、上下文窗口与实际用例

Qwen3.6 35B A3B 是什么

Qwen3.6 35B A3B 属于阿里巴巴的 Qwen 模型系列，在 OpenRouter 上以以下 ID 提供：

qwen/qwen3.6-35b-a3b

模型名称提供了几条有用的线索，但一些实现细节仍在逐步明朗。

已确认的部署相关信息如下：

• 模型系列： Qwen
• OpenRouter ID： qwen/qwen3.6-35b-a3b
• 上下文长度： 262144 token
• 提示词价格： $0.00000014 每 token
• 生成内容价格： $0.000001 每 token
• 集成方式： 可通过 OpenRouter 上兼容 OpenAI 的 API 使用

“35B A3B”后缀强烈暗示该模型大约具有 35B 个总参数 以及约 3B 个激活参数 用于处理每个 token，很可能采用稀疏架构或混合式架构。这种解读符合现代高效大模型常见的命名方式，但除非推理服务提供商或模型卡明确确认相关细节，否则我会认为具体的架构机制仍有待明确。

这种区分很重要。一个模型的总容量可以达到“35B”，但如果每次只有部分权重处于激活状态，其每个 token 的推理成本就可能更接近小得多的稠密模型。在实践中，这可以形成一种实用的性能与成本平衡：

• 比小型模型拥有更好的知识能力和指令遵循能力
• 比总参数量相近的稠密模型具有更低的延迟和成本
• 最高推理能力不及最好的前沿模型
• 非常适合长上下文综合整理、编程辅助、信息提取和路由

它在当前模型中的定位

如今的模型格局已不再是一张简单的排行榜。在生产系统中，我通常按 任务类型来划分模型，而不是依据单一的“最佳”分数。

Qwen3.6 35B A3B 并不试图占据与 Claude Opus 4.8 或 GPT-5.5 相同的定位。对于法律风险备忘录、会做出不可逆决策的多步骤研究智能体，或最后 5% 的准确率就是产品核心价值的复杂推理基准测试，我不会将它选作默认模型。

我会考虑将它用于：

• 阅读大型内部文档
• 总结代码仓库
• 从长篇转录文本中提取结构化数据
• 预处理上下文，再将精简后的信息包发送给前沿模型
• 在更大的智能体系统中充当低成本的长上下文处理单元
• 生成初步的代码解释、差异说明和迁移说明

最后这种模式被低估了：使用一个能力出色且经济实惠的长上下文模型来 压缩并结构化 杂乱的信息，然后仅将提炼出的高难度推理步骤交给 Opus、GPT-5.5 或 Gemini 3。

262k 上下文窗口改变了系统设计

262,144 token 的窗口足够大，能够改变你构建检索系统和智能体系统的方式。

它并不会消除 RAG，而是改变了 RAG 应处的位置。

在上下文为 8k 或 32k 时，你不得不大量依赖检索。而在 262k 的上下文中，你通常可以纳入：

• 完整的设计文档
• API 模式定义
• 多个源文件
• 近期的问题记录
• 某次事件时间段内的日志
• 精简的知识库片段
• 用户专属配置

对于许多工程工作流，这可以避免脆弱的“仅使用 top-k 文本块”模式导致的失败：缺失的答案其实就在第 11 个文本块中。

一个常见陷阱： 大上下文并不等于完美的注意力。当你把 200k 个 token 塞进提示词时，实际发生的是：模型有更多机会看到相关事实，但它仍可能遗漏细节、过度重视靠后的文本，或混淆两个相似的章节。你仍然需要组织好内容结构。

在实践中，我会这样使用长上下文提示词：

SYSTEM:
You are analyzing a production incident. Prefer exact evidence over speculation.
If evidence is missing, say what is missing.

USER:
You will receive four sections:
1. Incident timeline
2. Service logs
3. Recent deploy diff
4. Runbook

Return:
- root_cause_candidates
- strongest_evidence
- missing_evidence
- rollback_or_mitigation_steps

Do not summarize unrelated log lines.

<incident_timeline>
...
</incident_timeline>

<service_logs>
...
</service_logs>

<deploy_diff>
...
</deploy_diff>

<runbook>
...
</runbook>

这些标签并非装饰。它们帮助模型保留各个来源之间的边界。对于长提示词，我也更倾向于要求输出附带依据：

{
  "root_cause_candidates": [
    {
      "candidate": "string",
      "confidence": "low | medium | high",
      "evidence": [
        {
          "section": "service_logs",
          "quote": "exact short quote"
        }
      ]
    }
  ],
  "missing_evidence": ["string"],
  "recommended_next_action": "string"
}

这样可以降低生成看似合理却缺乏依据的事件摘要的概率。

成本计算：这个模型为何值得关注

列出的 token 价格如下：

• 提示词： $0.00000014 每 token
• 补全： $0.000001 每 token

这意味着：

输出端的成本明显高于提示词端。这会影响提示词设计。如果你要求模型重写一份完整的 100k token 文档，成本和延迟都会迅速增加。如果你要求它提取 60 条结构化事实，成本效益就会截然不同。

在生产环境中，我会着重优化以下方面：

• 将大量依据放入提示词
• 要求紧凑的结构化输出
• 避免冗长的思维链式回复
• 尽可能使用确定的模式定义
• 在上下文容量允许时，按文档拆分批量任务，而不是按任意 token 文本块拆分

通过兼容 OpenAI 的 API 集成

OpenRouter 通过兼容 OpenAI 的聊天补全接口提供模型访问。一个最简的 curl 调用如下所示：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen/qwen3.6-35b-a3b",
    "messages": [
      {
        "role": "system",
        "content": "You are a precise engineering assistant. Return concise JSON."
      },
      {
        "role": "user",
        "content": "Extract the API changes from this changelog: ..."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 1200
  }'

在 Python 中，你可以通过更改基础 URL 来使用 OpenAI SDK：

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

response = client.chat.completions.create(
    model="qwen/qwen3.6-35b-a3b",
    messages=[
        {
            "role": "system",
            "content": "You extract structured facts from long engineering documents.",
        },
        {
            "role": "user",
            "content": open("design-review.md", "r", encoding="utf-8").read(),
        },
    ],
    temperature=0.1,
    max_tokens=2000,
)

print(response.choices[0].message.content)

在生产环境中，为这段调用添加重试和超时处理：

import os
import time
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
    timeout=90,
)

def call_qwen(messages, max_tokens=1500, attempts=3):
    last_error = None

    for attempt in range(attempts):
        try:
            return client.chat.completions.create(
                model="qwen/qwen3.6-35b-a3b",
                messages=messages,
                temperature=0.2,
                max_tokens=max_tokens,
            )
        except Exception as error:
            last_error = error
            time.sleep(2 ** attempt)

    raise last_error

对于采用 Anthropic 风格的应用，实际的集成模式通常不是“假装所有 API 都完全相同”，而是定义一种内部消息格式，再针对各个提供商进行适配：

def to_openai_messages(system_prompt, turns):
    messages = [{"role": "system", "content": system_prompt}]
    for turn in turns:
        messages.append({
            "role": turn["role"],
            "content": turn["content"],
        })
    return messages

这样，你就可以在 Qwen、Claude、GPT、Gemini 和开放模型之间路由请求，而不必让提供商特有的格式散布在整个代码库中。

适用的架构模式

1. 长上下文初步筛选处理单元

使用 Qwen3.6 35B A3B 阅读原始材料，并产出一份更精简的结果：

{
  "input": "full incident bundle",
  "qwen_output": "ranked timeline + evidence table",
  "frontier_model_input": "only unresolved causal questions"
}

这种模式很有用，因为前沿模型的代价不仅体现在金钱上，也体现在审查所需的注意力上。把困难的部分交给它们，而不是整堆待筛选的材料。

2. 代码仓库讲解器

对于中等规模的代码仓库，你可以输入：

• README
• 依赖文件
• 关键源代码目录
• 测试失败信息
• 近期的代码差异

然后要求生成迁移计划或风险审查。我仍然会避免把生成文件、锁文件、随仓库附带的第三方依赖和构建产物一股脑地放进去。长上下文让偷懒成为可能，但并不意味着这样做明智。

一个实用的文件打包脚本：

{
  echo "# Repository Snapshot"
  find src tests -type f \
    \( -name "*.py" -o -name "*.ts" -o -name "*.tsx" \) \
    -not -path "*/node_modules/*" \
    -print | sort | while read -r file; do
      echo "\n--- FILE: $file ---"
      sed -n '1,240p' "$file"
    done
} > repo_snapshot.md

然后将 repo_snapshot.md 发送给模型，并附上一条范围明确的指令，例如“确定添加 OAuth 设备授权流程所需的最少文件”。

3. 低成本的大规模提取

由于这里的提示词 token 价格低廉，这个模型对于从大型文档中批量提取信息可能很有吸引力。关键在于约束输出：

{
  "contract_terms": [
    {
      "name": "termination_notice_period",
      "value": "30 days",
      "evidence_quote": "Either party may terminate with thirty days written notice."
    }
  ]
}

除非你确实需要，否则不要要求“详细分析”。输出 token 是成本的主要来源。

我预期它在实践中的优势

根据其所属系列和部署特点，我预计 Qwen3.6 35B A3B 在以下方面最为擅长：

• 长上下文摘要： 将大量输入转化为结构化简报
• 代码理解： 解释不熟悉的代码，并生成局部修改
• 信息提取： 从长篇半结构化文本中生成 JSON 输出
• 多语言工作负载： Qwen 模型以往在非纯英语场景中也表现出实用价值
• 智能体子程序： 分类、路由、工具参数拟定和上下文压缩

对于以下任务，我会更加谨慎：

• 类似定理证明的深度推理
• 存在歧义的产品判断
• 高风险的法律或医学解读
• 长时间的自主智能体循环
• 需要在 200k+ token 范围内实现完美信息回忆的任务

正确的理解方式是： 实用性强的长上下文处理模型，而非能全面替代前沿模型的选择。

提示词编写中的常见陷阱

使用这类模型时，以下习惯会有所帮助：

• 将指令放在数据之前。
• 为每个主要部分添加标签。
• 当事实准确性很重要时，要求引用原文作为依据。
• 保持输出简短，并明确数据类型。
• 避免在一个庞大的提示词中混合无关任务。
• 在信息提取和业务操作工作流中使用低温度参数。

例如，下面的写法比“总结所有内容”更好：

Return exactly five risks from the design document.

For each risk include:
- risk_name
- severity: low | medium | high
- affected_component
- evidence_quote
- mitigation

If the document does not support a risk, do not include it.

最后那句话很重要。没有它，许多模型会通过补充看似合理的风险来“补全模式”。

局限与未知之处

在将 Qwen3.6 35B A3B 用于关键环节之前，我仍会核实以下细节：

• 确切的架构及激活参数的行为
• 如果应用依赖严格的函数调用，需核实工具调用的可靠性
• 长上下文压力下的 JSON 有效率
• 提示词长度为 100k、200k 以及接近 262k 个 token 时的延迟
• 在特定领域评估集上的表现
• 提供商侧的速率限制与可用性特征

模型列表已确认其上下文长度，但实际的长上下文质量取决于具体工作负载。模型即使能够接收 262k 个 token，也可能仍需精心组织提示词才能获得最佳表现。

我的标准评估会包括：

1. Needle retrieval from early, middle, and late prompt regions
2. Multi-document contradiction detection
3. JSON schema adherence
4. Long-log incident diagnosis
5. Codebase question answering
6. Cost and latency at p50 / p95 prompt sizes

如果你选择它的原因是长上下文能力，就不要只用简短的聊天提示词进行基准测试。

实践要点

如果你需要一个成本效益高、能够接收超大提示词并返回简洁实用输出的模型，Qwen3.6 35B A3B 值得测试。

• 将它用于长上下文综合分析、信息提取、代码仓库分析和智能体预处理。
• 不要假定它能在最困难的推理工作负载中替代 Claude Opus 4.8、GPT-5.5 或 Gemini 3。
• 除非提供商给出明确的模型卡，否则应将“35B A3B”的架构细节视为尚在逐步明确的信息。
• 设计提示词时，使用带标签的章节、精简的结构定义以及证据要求。
• 注意生成内容的长度：按照所列价格，输出 token 的费用远高于输入 token。
• 使用真实的长上下文任务进行评估，尤其关注召回能力、JSON 有效性、延迟以及失败时的行为。

最值得关注的用例，并不是让 Qwen3.6 35B A3B 成为技术栈中最聪明的模型，而是让它以可负担的成本读取全部内容、整理杂乱信息，并将困难的部分交给合适的下一环节。