你的显卡能写代码了：Qwen 3.5 如何跨越本地 AI 的门槛
一个能装进一张游戏显卡的模型，在该领域最难的基准测试中，已经只差最好的商业编程 AI 2个百分点。这句话在半年前还是天方夜谭。Qwen 3.5 的 35B-A3B 在 SWE-bench Verified Hard 上达到 37.8%，在一张 RTX 3090 上跑出 112 tokens/秒。模型准备好了，硬件准备好了。软件栈呢？这才是有趣的地方。
1. 改变一切的数字
先思考一个问题：一个 AI 编程智能体要真正有用，最低需要什么？
你需要两样东西。首先，模型要足够聪明，能理解真实的代码库、规划多步骤修改、并调试自己的错误。其次，它要足够快，让你不用在等待它思考的时候干瞪眼。你需要质量和速度同时满足，而且跑在你买得起的硬件上。
多年来，这个组合在本地运行是不可能的。最好的开源模型要么太大、要么太慢、要么太笨。你可以运行快-但-笨的，或者慢-但-聪明的，但永远无法两者兼得。本地 AI 编程意味着必须接受与云端 API 之间的巨大质量差距。
Qwen 3.5 刚刚填补了这个差距。
阿里巴巴的 Qwen3.5-35B-A3B 在 SWE-bench Verified Hard 上得分 37.8% — 这个基准测试要求模型修复真实开源项目中的真实 Bug。商业模型中最好的 Claude Opus 4.6 大约得分 40%。差距只有 2 个百分点。之前最好的本地可运行模型远远达不到这个水平。
秘密在于架构。“35B-A3B”意味着总共 350 亿参数，但每个 token 只有 30 亿参数在工作。这是混合专家（MoE）设计 — 想象成一组专业子模型轮流上阵，每个 token 只有相关的专家被激活。这意味着你获得了更大模型的智能，却只需要极小模型的速度和内存开销。
而这不仅仅是旗舰版。完整的 Qwen 3.5 家族从 0.8B 到 122B 参数。9B 模型只需 7GB 显存 — 这几乎是手机芯片级别的内存。27B 模型支持 800K+ token 上下文窗口。35B-A3B 在 32GB 显存的消费级 GPU 上支持超过 100 万 token 的上下文。全部使用 4-bit 量化，精度几乎无损。
2. 快到可以实时使用
光有质量不够。如果模型每秒只能生成 10 个 token，每个编程任务都像看油漆干。智能体工作流需要交互级速度 — 大约 30+ tokens/秒才感觉有反应，60+ 才感觉快。
消费级最快的成绩：RTX 5090 跑 bare llama.cpp 配合 Q4_K_XL 量化达到 194 tokens/秒。但真正的惊喜在性价比层。一张单独的 RTX 3090 — 二手大约 800 美元的游戏显卡 — 用同样的配置达到 112 tok/s。而 AMD 的 Radeon AI PRO R9700 通过 Vulkan 达到 127 tok/s，售价 $1,299。
苹果这边，M4 Max 通过 MLX 达到约 70 tokens/秒（4-bit 量化）— 比同芯片上 Ollama 的 llama.cpp 后端快约 2 倍。足够交互使用，但明显落后于独立显卡方案。
NVIDIA 的 DGX Spark 桌面设备 — Grace Blackwell GB10 — 使用 vLLM FP8 标准配置达到约 50 tokens/秒。瓶颈是内存带宽：Spark 的 LPDDR5X 提供约 273 GB/s，而 3090 有约 936 GB/s。
但这里有一个硬门槛：你至少需要 24GB 显存。Q4_K_XL 量化大约占 19.7GB。RTX 5080（16GB）必须把部分层卸载到系统内存，速度骤降到大约 44 tok/s — 差了 3-4 倍。16GB 显存级别在这个模型上根本无法竞争。
性价比的故事非常一边倒。一张二手 RTX 3090 每 1,000 美元提供 140 tok/s — 毫无疑问的性价比之王。RTX 5090 和 Radeon AI PRO R9700 以约 97 tok/s/$1k 并列第二，但 5090 是绝对速度最快的卡。$4,699 的 DGX Spark 论速度性价比最差 — 你付的是小巧外形和 128GB 统一内存的溢价，而不是 token 吞吐量。
在 100+ tokens/秒下，智能体编程会话感觉很流畅。模型阅读你的代码库、规划修改、编写代码、检查结果 — 全部实时完成。
但这些数字背后隐藏着一个陷阱。
3. 你不知道自己在缴纳的 2.5 倍税
不是所有推理方案都一样。运行模型的软件几乎和底层硬件一样重要。
LM Studio 相比 bare llama.cpp 有大约 2.5 倍的性能损耗。 这意味着同样的硬件，bare llama.cpp 能跑 100 tok/s 的，LM Studio 只能跑大约 40 tok/s。仍然可用 — 但这是对你硬件投资的巨大浪费。
这个差距正在驱动本地 AI 社区的一场静默迁移。高级用户正在从 ollama 和 LM Studio 转向 llama-swap — 一个轻量级代理，管理多个 bare llama-server 后端。它按需加载和卸载模型、将请求路由到正确的后端，几乎零额外开销。兼具模型管理器的便利和零性能损失。
教训：如果你用 Qwen 3.5 跑智能体编程，服务软件的选择可能决定了”够快”和”令人沮丧的慢”之间的差别。裸金属胜出。
4. 量化谜题
要在消费级 GPU 上运行 350 亿参数的模型，需要量化 — 把模型权重从 16 位浮点压缩到 4 位整数。做得好，质量几乎无损。做得差，模型开始产生幻觉和微妙的推理错误。
社区的两个发现特别突出：
Unsloth 的动态 GGUF 量化 将最大 KL 散度降低了 51%。KL 散度衡量压缩模型的输出分布与原始模型的偏差 — 越低越好。Unsloth 通过重要性矩阵校准实现：分析哪些权重区域对输出质量影响最大，并以更高精度保留它们。结果是一个行为更接近原始 16 位版本的 4-bit 模型。
但有一个没人警告你的陷阱：Qwen 3.5 需要 bf16 KV 缓存才能正确推理。 KV 缓存是模型的工作记忆 — 它存储对话上下文，让模型不必从头重新阅读所有内容。llama.cpp 默认使用 fp16（另一种 16 位格式），对大多数模型来说没问题。但对 Qwen 3.5，它会悄悄引入推理错误和困惑度下降。
修复方法是两个标志：--cache-type-k bf16 --cache-type-v bf16。如果你在本地运行 Qwen 3.5 却没有设置这些，你的模型正在悄悄出错，而你可能完全不知道。
5. 软件跟不上了
转折来了。模型准备好了。硬件准备好了。但当社区试图真正将 Qwen 3.5 部署到生产智能体工作流中时，他们撞墙了 — 不是模型的问题，而是每个主要推理框架的问题。
Qwen 3.5 引入了几个真正新颖的架构创新：多段旋转位置编码（M-RoPE）、滑动窗口注意力（SWA）和多 Token 预测（MTP）。这些特性让模型如此出色，也正是它们在破坏工具链。
| Framework | Issue | Severity | Status | Impact |
|---|---|---|---|---|
| llama.cpp | Heap buffer OOB (M-RoPE) | Critical | Fixed | Crashes on Qwen 3.5 35B |
| llama.cpp | SWA cache invalidation | High | Open | Full re-process every turn |
| llama.cpp | bf16 KV cache not default | Medium | By Design | Silent quality degradation |
| vLLM | MTP 0% acceptance (NVFP4) | High | Open | Speculative decoding fails |
| vLLM | Spec. decode memory crash | Critical | Open | Crashes on Qwen 3.5 122B |
在 llama.cpp 中，M-RoPE 导致了堆缓冲区越界漏洞。标准 RoPE 每个 token 需要一个位置条目；M-RoPE 需要四个（每段一个）。KV 缓存分配没有考虑到这点，导致内存损坏。对 35B 模型来说这是首次使用就崩溃的 Bug。在 PR #20094 中快速修复了 — 但初始版本是带着 Bug 发布的。
更痛苦的 Bug 仍然未修复：滑动窗口注意力在多轮对话中破坏了 KV 缓存。 每次发送新消息时，滑动窗口之外的位置会被失效，迫使 llama.cpp 从头重新处理整个提示。对于一个与代码库进行 10 轮对话的编程智能体，这意味着每轮都要重新阅读所有内容。每轮复杂度是 O(n) 而非 O(1) — 对智能体用例来说，这是毁灭性的。PR #20087 合并了一个临时方案（--checkpoint-every-nb，定期创建缓存检查点），但这只是权宜之计，不是真正的修复。
在 vLLM 中，122B 大模型的情况更糟。多 Token 预测推测解码 — 本应大幅加速推理的技术 — 在 Blackwell GPU 上与 NVFP4 量化结合时显示 0% 接受率。零。加速技术没有产生任何可用的 token。更糟的是：一位 NVIDIA 工程师确认官方的 Qwen3.5-397B NVFP4 检查点在 GSM8k 上的准确率只有 0.11，而原始模型是 0.90 — 准确率几乎完全崩溃。此外，推测解码会直接崩溃并产生非法内存访问。所有 Bug 仍然未修复。
模式很清楚：Qwen 3.5 的新颖架构正在突破推理框架设计的边界，而框架还没有赶上来。
6. 智能体效率倍增器
尽管存在软件 Bug，社区正在找到创造性的方法让本地 Qwen 3.5 智能体工作 — 其中一个技术从根本上改变了经济学。
智能体间的 KV 缓存状态传递可以节省 73-78% 的 token。 在多智能体工作流中 — 比如四个专业智能体各自处理编程任务的不同部分 — 系统提示和对话上下文对所有智能体是相同的。无需每个智能体独立处理完整上下文，只需计算一次并共享缓存的 KV 状态。每个智能体只处理自己独特的指令（“增量”），节省大约四分之三的计算量。
结合 100+ tok/s 的硬件性能，这个技术让多智能体编程工作流在消费级硬件上真正可行。你不只是运行一个智能体 — 你在运行一个小团队，每个有专门的角色，而 KV 共享意味着协调的开销微乎其微。
7. 接下来会发生什么
软件已经在赶上来了。M-RoPE Bug 在几天内就修复了。llama.cpp 刚刚合并了完整的 MCP 客户端和智能体循环支持，加上一个让大多数模型开箱即用获得工具调用能力的自动解析器 — 它现在是一个原生的智能体平台，而不仅仅是模型运行器。SWA 缓存失效已有临时方案，完整修复路径明确。vLLM 的 NVFP4 问题会随着 Blackwell 部署规模扩大而被修补。
画面越来越清晰：一个接近前沿编程性能的模型，在一张约 800 美元的二手 GPU 上以交互速度运行，通过 KV 缓存共享同时服务多个智能体，由一个几乎零开销的轻量级代理管理。
这就是一个本地 AI 编程实验室。在你的桌面上。没有 API 调用，没有按 token 计费，没有数据离开你的机器。
我们正在进入一个阶段：本地 AI 的瓶颈不再是模型或硬件 — 而是中间件。而中间件恰恰是开源社区最擅长快速解决的问题。仅 llama.cpp 仓库就有数百名活跃贡献者。vLLM 有多家公司的企业支持。这里记录的 Bug 在几个月内就会成为历史注脚。
真正的问题不是本地 AI 编程智能体能否工作 — Qwen 3.5 已经证明了它们可以。问题是到年底有多少开发者会运行自己的智能体集群。如果 Cursor 的发展轨迹数据可以作为参考 — 从自动补全到智能体到并行智能体再到智能体集群 — 答案是：比任何人预期的都多。