Qwen 3.5 35B-A3B

我运行本地模型已经有一段时间了，我以为我对消费级硬件的上限有了相当不错的了解。

但是，当一个 350 亿参数的模型在每令牌仅激活 30 亿参数的情况下，超越了其 2350 亿参数的前辈时，这对于等待可用于生产工作负载的本地模型的开发者来说，是一个转折点。

仅用 30 亿激活参数就达到 Sonnet 4.5 级别的性能，这确实令人印象深刻。这大约是其总权重的 8.6%。

在一台可以大约 800 美元购买的二手 RTX 3090 上，它可以以每秒 112 个令牌的速度生成，并且支持完整的 262K 上下文窗口，或者你可以在像 MacBook Air M4 24GB 这样的规格上运行，速度约为每秒 15 个令牌。

以下是社区报告的其他 UD-Q4_K_XL（19.7GB）统计数据，这适用于任何 24GB 显卡的规格：

2x RTX Pro 6000 Max Q：~2,600 t/s
R9700 32GB：128 t/s Vulkan
5090：~170 t/s
4090：122 t/s
3090：~110 t/s

最后，是 M3 Ultra 512GB 上 Qwen 3.5 MLX 8bit 的统计数据：

Qwen3.5–35B-A3B-8bit：80.6 t/s（39.3 GB）
Qwen3.5–122B-A10B-8bit：42.5 t/s（133.6 GB）
Qwen3.5–27B-8bit：21.3 t/s（32.7 GB）

一位社区成员将其指向 Claude Code，给它一个完整游戏的单一架构规范，然后看着它脚手架了 10 个文件、3,483 行代码，调试自己的碰撞检测，并在首次加载时提供一个可玩的游戏。

这就是为什么 HuggingFace 上所有趋势模型都是 Qwen 3.5 的原因。

说实话，我没有从 30 亿激活参数中预期能做到这些：自主的多文件智能体编码、无审查的自动化管道、交互速度下的完整上下文推理。

性价比非常吸引人。

这背后的架构确实新颖，不仅仅是重新排列的 transformer，而大多数运行它的人因为缺少一些标志而将其吞吐量的 40-60% 浪费在桌面上，修复方案实际上只需要三个 CLI 参数。

让我们分解一下 Qwen 3.5 35B-A3B 到底是什么，为什么架构值得理解，如何获得人们发布的性能数字，以及真正的权衡隐藏在哪里，而这些是没人会在推特上谈论的。

1、为什么我们现在要讨论这个

三件事在同一周发生，我认为这种融合使它变得有趣。

首先，阿里巴巴的 Qwen 团队发布了 Qwen 3.5 中型模型系列，其中包括四个 Apache 2.0 下的模型：

35B-A3B
27B 密集模型
122B-A10B
以及旗舰版 397B-A17B

Qwen 3.5 中型模型在所有以前的 Qwen 模型上表现优异，击败了比它大 6 倍的模型，比 Sonnet 4.5 更智能，几乎可以在任何现代计算机上完全免费运行。

这个公告更有趣的部分是，具有 30 亿激活参数的模型现在超越了前一代具有 220 亿激活参数的模型。

我见过很多次增量改进，但这绝对改变了前沿模型中"小型"的含义。

其次，Unsloth 团队提供了优化的 GGUF 量化，包括从零开始访问，包括他们的 Dynamic 2.0 量化，它将重要层升级到 8 位或 16 位，同时保持模型紧凑。

他们还发现并修复了一个工具调用聊天模板 bug，这个 bug 悄悄地破坏了每个量化上传者的函数调用工作流。

如果你一直在挠头，为什么你的智能体的工具调用一直返回垃圾 JSON，这很可能就是原因。

第三，本地推理社区对此彻底疯狂了。

在 48 小时内，就有报告称某人从单一提示自主构建了整个游戏，无审查的智能体管道自动注册服务，以及用三个标志使生成速度翻倍的吞吐量优化。

2、Qwen 3.5 35B-A3B 是什么

35B 是总参数。A3B 意味着每令牌 30 亿激活参数，这是一个稀疏混合专家模型。

这里需要理解的重要一点是，你在磁盘和 VRAM 中存储了 350 亿参数，但在推理时，你的 GPU 只为 30 亿参数进行数学计算。

你获得了 350 亿模型的内存，即世界知识、训练表示、参数宽度，但计算成本感觉更接近于运行 30 亿模型。

以下是完整阵容的对比：

所有模型均以 Apache 2.0 发布。

35B-A3B 根据你的量化选择占用 17-24GB 内存。Q4_K_M 大约为 20GB。这意味着单个 RTX 3090、4090 或 24GB Mac 可以在感觉交互的速度下运行此模型，并具有完整的 262K 上下文窗口。

这非常棒，因为我们谈论的是一个击败前一代 2350 亿模型的模型，运行在你可能已经拥有的硬件上。

3、使其工作的架构

每个使用长上下文模型的人都遇到了这个问题：标准 transformer 注意力随序列长度呈二次方扩展。

将上下文窗口翻倍，计算量翻四倍。

我们都曾感受到这种痛苦，在尝试使用 100K+ 令牌上下文进行 RAG 时，看着推理速度慢如蜗牛。

Qwen 3.5 混合架构通过以 3:1 比例在两种注意力机制之间交替来解决这个问题：

每 4 个块中的 3 个 使用 Gated DeltaNet，这是一种线性注意力变体，将 Mamba2 的门控衰减与用于更新隐藏状态的 delta 规则相结合。

每一层将输入序列压缩成固定大小的状态，这给你带来近乎线性的序列长度扩展。门控机制（一个自适应地缩放注意力输出的 sigmoid）解决了注意力汇聚问题，并防止了大规模训练时激活爆炸。

每 4 个块中的 1 个 保持标准全注意力（也是门控的）以保留细粒度的令牌到令牌推理。

这些层允许模型精确地关注序列中的任何位置，如果你做过任何代码生成工作，你就知道这对于正确获取导入、变量引用和函数签名有多重要。

这与 Kimi Linear 工作中出现的情况一致，尽管 Kimi 通过通道门控和全注意力层中的多头潜在注意力进行了改进。

看到两个独立团队以相同的 3:1 比例汇聚，告诉我这个领域的发展方向。

4、当你部署它时实际上意味着什么

我在推理运行期间花足够的时间盯着 nvidia-smi，欣赏 3:1 比例在实际中的作用。

三个具体后果：

(1) 你的 KV 缓存内存急剧下降。 线性注意力层将上下文压缩成固定大小的状态，而不是为每个令牌存储键值对。这是 35B-A3B 在具有 262K 上下文的消费级 GPU 上运行的真正原因，有效的 KV 缓存占用是纯注意力模型所需占用的一小部分。这特别有用，尤其是当我处理需要将整个代码库保持在上下文中的智能体管道时。

(2) 上下文扩展几乎平坦。 RTX 5090 上的社区基准测试显示，Qwen 3.5 模型在 512 到 8,192 个令牌上下文之间仅保持 -0.9% 的吞吐量下降。较旧的 Qwen3 30B-A3B（纯注意力 + MoE，无 DeltaNet）在同一范围内下降了 -21.5%。如果你正在构建 RAG 管道或长对话智能体，这很重要。

(3) 你确实需要为架构付出吞吐量代价。 说实话，3.5 模型在相同硬件上的原始生成速度上比较旧的 30B-A3B 慢大约 32%。DeltaNet 层和更大的词汇表（248K 令牌 vs 152K）增加了开销，但作为回报，你获得上下文稳定性。这种权衡是否适合你完全取决于你的工作负载，我认为值得深思熟虑地选择哪一个。

5、顶部的 MoE 层

在混合注意力之上，每个前馈块通过稀疏 MoE 层路由令牌。该模型每个 MoE 层有 256 个专家子网络，学习路由器为每个令牌选择前 9 个。这意味着每令牌只有大约 3.5% 的前馈参数处于活动状态。

线性注意力（减少内存）和稀疏 MoE（减少计算）的结合使模型能够超越其重量级。

6、本地性能以及如何实现它

Ollama、LM Studio 甚至幼稚的 llama.cpp 设置中的默认配置在 24GB+ VRAM 卡上产生 40-70 tok/s。优化设置在完全相同的硬件上产生 100-122 tok/s。

因为大多数工具默认使用 f16 KV 缓存，不为 MoE 专家卸载进行优化，并且跳过闪存注意力标志。

RTX 5080 (16GB) 上的社区基准测试描绘了一幅清晰的画面：

Q4_K_M 与手动 MoE 卸载 (–n-cpu-moe 24)：~70 tok/s
Q4_K_M 与自动适配：~65 tok/s
Q8_0 与完全卸载：~35 tok/s

从 f16 切换到 q8_0 KV 缓存给你带来 12-38% 的吞吐量提升，同时实际上使用更少的 VRAM，我想不出不使用它的理由。

7、实际上让你获得 100+ tok/s 的设置

如果你有 24GB+ VRAM（RTX 3090、4090 或同等配置），这里是让你进入三位数范围的配置。

我一直在运行非常接近这个配置的东西，可以确认它有效：

# 从源代码构建 llama.cpp（必需——预构建二进制文件可能会错过优化）

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

# 使用优化标志启动
./build/bin/llama-server \
-hf unsloth/Qwen3.5-35B-A3B-GGUF:UD-Q4_K_XL \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
-np 1 \
-ngl 99 \
-fa \
--ctx-size 65536 \
--jinja \
--port 8080

每个标志的作用：

--cache-type-k q8_0 --cache-type-v q8_0 比 f16 默认值提高 12-38%
-np 1 将并行请求插槽设置为 1。对于单用户本地推理很重要，因为它消除了调度开销。
-ngl 99 将所有层卸载到 GPU。只有在达到 VRAM 限制时才减少此值。
-fa 启用闪存注意力。

使用此设置：

RTX 3090 (24GB)：100 tok/s（从使用默认标志的 ~50 tok/s 上升）
RTX 4090 (24GB)：122 tok/s（从 ~70 tok/s 上升）
完整的 262K 上下文保留，零速度损失

你应该能够在类似的硬件和设置上重现这些数字。

8、为什么 Ollama 不是这个的正确工具（还）

Ollama 不支持 MoE 专家卸载。

当 MoE 模型超过 VRAM 容量时，Ollama 在层级别进行拆分，它将整个 transformer 块发送到 CPU 或 GPU。所以你的 GPU 就在那里闲置，等待 CPU 完成处理其层。这对于 MoE 架构来说完全是错误的策略。

正确的方法是仅专家卸载（-ot "exps=CPU" 或 --n-cpu-moe），它将注意力、规范和共享专家保留在 GPU 上，同时仅通过 PCIe 路由专家 FFN 权重。

Ollama 还默认使用 f16 KV 缓存，通常关闭闪存注意力，并且不给你对批量大小的控制权。

你可以在此处的社区讨论中找到更多详细信息。

9、Claude Code + 本地 LLM 模式

这对我自己的工作实际上很有用。

Claude Code 可以通过名为 claude-code-router 的工具配置为指向本地 llama-server 端点，而不是 Anthropic 的 API。

你获得 Claude Code 的智能体脚手架，即文件管理、错误恢复、多文件编辑，所有这些好东西，以及本地模型提供的生成。

// 最小 claude-code-router 配置（~/.claude-code-router/config.json）

{
  "providers": [
    {
      "name": "llamacpp",
      "api_base_url": "http://localhost:8080/v1/chat/completions",
      "api_key": "not-needed",
      "models": ["Qwen3.5"]
    }
  ]
}

如果你正在进行繁重的智能体编码，使用托管模型的 API 成本会迅速累积。使用此设置，你只需让它运行。当你知道没有每令牌费用在最后等待时，你会更愿意尝试雄心勃勃的提示。

10、它在哪里崩溃

不过，这个模型不是银弹，我在承诺在其上构建之前遇到了真正的局限性，这些局限性值得了解。

例如，当我向 35B-A3B 投掷多步骤逻辑、细致的代码架构决策或深度数学证明时，我能感觉到它以 27B 密集模型没有的方式挣扎。

仔细想想，这有道理，30 亿激活参数意味着大约 100 亿等效推理深度，而不是 350 亿。知识在那里，但每令牌处理的深度根本上受限于进行工作的参数数量。

所以你可以尝试使用温度为 1.0 的思考模式来处理复杂任务，对于困难的东西，你仍然可以使用密集的 27B 或更大的模型。

原文链接: Qwen 3.5 35B-A3B: Why Your $800 GPU Just Became a Frontier Class AI Workstation

汇智网翻译整理，转载请标明出处