> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Qwen 3.5 35B-A3B
- URL: https://www.hubwiz.com/blog/qwen-3-5-35b-a3b/
- Published: 2026-03-02T00:59:15.000Z
- Updated: 2026-03-02T00:59:15.000Z
- Description: 让我们分解一下 Qwen 3.5 35B-A3B 到底是什么，为什么架构值得理解，如何获得人们发布的性能数字，以及真正的权衡隐藏在哪里，而这些是没人会在推特上谈论的。
- Author: admin
- Tags: MODEL-ZOO, QWEN3.5, #Import 2026-10-14 14:41

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

但是，当一个 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 亿激活参数中预期能做到这些：自主的多文件智能体编码、无审查的自动化管道、交互速度下的完整上下文推理。

性价比非常吸引人。

![ArtificialAnalysis](https://www.hubwiz.com/blog/content/images/2026/03/1-bXGu5H0Q3D3aKa2wZzNNLg.png)

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

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

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

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

首先，阿里巴巴的 Qwen 团队发布了 [Qwen 3.5 中型模型系列](https://unsloth.ai/docs/models/qwen3.5?ref=hubwiz.com)，其中包括四个 Apache 2.0 下的模型：

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

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

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

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

其次，[Unsloth 团队提供了优化的 GGUF 量化](https://unsloth.ai/docs/models/qwen3.5?ref=hubwiz.com)，包括从零开始访问，包括他们的 Dynamic 2.0 量化，它将重要层升级到 8 位或 16 位，同时保持模型紧凑。

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

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

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

在 48 小时内，就有报告称[某人从单一提示自主构建了整个游戏](https://x.com/sudoingX/status/2027728083655266601?ref=hubwiz.com)，无审查的智能体管道自动注册服务，以及用三个标志使生成速度翻倍的吞吐量优化。

## 2、Qwen 3.5 35B-A3B 是什么

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

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

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

以下是完整阵容的对比：

![Qwen 3.5 models comparison](https://www.hubwiz.com/blog/content/images/2026/03/1-bXGu5H0Q3D3aKa2wZzNNLg.png)

所有模型均以 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 缓存，通常关闭闪存注意力，并且不给你对批量大小的控制权。

你可以在[此处的社区讨论中找到更多详细信息。](https://www.reddit.com/r/LocalLLaMA/comments/1rg4zqv/followup%5Fqwen3535ba3b%5F7%5Fcommunityrequested/?ref=hubwiz.com)

## 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](https://agentnativedev.medium.com/qwen-3-5-35b-a3b-why-your-800-gpu-just-became-a-frontier-class-ai-workstation-63cc4d4ebac1?ref=hubwiz.com)

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