Qwen3.5-Coder

• 1. 概要 （共 244 字）

  Qwen3.5-Coder 是阿里通义千问团队在 Qwen 3.5 家族基础上推出的代码专用开放权重模型系列，定位与 Qwen3-Coder、Qwen3-Coder-Next 一脉相承，但绑定在 2026 年 2 月发布的 Qwen 3.5 混合架构之上。目前已经披露两个尺寸：7B 与 32B，均原生支持 256K 上下文、开放权重、Apache 2.0 许可可商用，面向本地部署与软件工程智能体（Coding Agent）场景。它的核心卖点很直接——用开源权重把「仓库级编程 + 工具调用 + 长上下文」塞进消费级硬件能跑的体量里。

• 2. 产品背景 （共 397 字）

  通义千问（Qwen）是阿里云自 2023 年起打造的开源大模型家族，到 2026 年已成为全球下载量最大的开源模型系列之一。2026 年 2 月 16 日，阿里正式发布 Qwen 3.5（旗舰 Qwen3.5-397B-A17B），采用 Gated DeltaNet 线性注意力与稀疏 MoE 混合架构，支持 201 种语言、原生多模态、最高 1M 上下文。Qwen3.5-Coder 就是这一代架构在「代码」维度的专门化分支。据 LLM Reference 收录，Qwen3.5-Coder 两个变体（7B、32B）的发布时间标注为 2026 年 1 月，早于 Qwen 3.5 旗舰的 2 月发布，时间线略显错位，但二者同属 3.5 代技术栈。值得一提，官方 Qwen 3.5 主博客并未单独列出「Coder」子型号，而是强调 Qwen Code 这款命令行编程工具；独立的 Qwen3.5-Coder 信息主要来自 Qwen 官方博客的 coder 专页与 Hugging Face 模型集。

• 3. 产品功能与使用体验 （共 376 字）

  两个开放权重变体规格清晰：Qwen3.5-Coder-7B（2026-01，256K 上下文，7B 参数）与 Qwen3.5-Coder-32B（2026-01，256K 上下文，32B 参数），均标注支持代码执行。它延续了 Qwen 代码模型的两条传统优势：一是原生 256K 长上下文，可一次性读入整个代码仓库，适配仓库级重构与跨文件依赖分析；二是 Agent 友好，能配合 Qwen Code、Claude Code、Cline、Kilo、Trae 等工具做「写代码—跑测试—读报错—修 Bug—验证」的自主闭环。社区还出现了基于官方 Ollama 版 Qwen3.5 调参出的 Coder 变体（如 mdq100/qwen3.5-coder:35b），通过降低温度、加 presence penalty 让输出更确定，并保留视觉输入与工具调用能力，便于在 OpenCode 等本地编程工具里即开即用。

• 4. 定价与商业模式 （共 300 字）

  作为开放权重模型，Qwen3.5-Coder 本身免费、Apache 2.0 可商用，开发者可在 Hugging Face / ModelScope 直接下载权重本地部署。若走托管 API，则复用阿里云百炼的 Qwen 3.5 系列计费：Qwen3.5-Plus（1M 上下文、内置工具）在中国内地按阶梯计价，约 0.8 元/百万输入 token（0–128K）、4.8 元/百万输出 token（0–128K），长上下文与思考模式另有加价；另有阿里云托管版 Qwen3.5-Plus 与社区路由（Together、OpenRouter、Ollama）等多条获取路径。对比闭源旗舰，开源权重的最大价值在于「一次下载、永久自有、数据不出域」。

• 5. 用户评价 （共 295 字）

  正面反馈集中在三点：一是成本结构——开源免费、可本地跑，对预算有限的个人与小团队极友好；二是中文与中英混合代码场景的原生优化，这在中文开发者社区被反复提及；三是长上下文带来的仓库级理解，让多文件重构、PR 分析不再是玩具级演示。负面与保留声音则指向：相比 Qwen 3.5 旗舰与 Qwen3-Coder-480B 这类超大 MoE，7B/32B 的 Coder 变体在复杂多步 Agentic 编码上仍有差距；社区 Coder 调参版（如 :35b）的基准来自基础 Qwen3.5 模型而非独立评测，存在「代际借用分数」的嫌疑；部分第三方页面把 1 月发布的 Coder 变体与 2 月发布的 Qwen 3.5 旗舰混为一谈，容易误导选型。

• 6. 行业评价 （共 350 字）

  在 SWE-bench Verified 这一编程智能体黄金基准上，Qwen 3.5 旗舰（397B-A17B）达到 76.4，逼近 Claude 4.5 Opus（80.9）与 GPT-5.2（80.0），显著领先上一代 Qwen3-Max-Thinking（75.3）。社区 Coder 变体（mdq100/qwen3.5-coder:35b）公布的基准为 SWE-bench Verified 69.2、LiveCodeBench v6 74.6、CodeForces 评分 2028，处于开源代码模型第一梯队。横向看，它面对 DeepSeek-V3.2、Kimi-K2、Qwen3-Coder-Next（仅 3B 激活即达 70.6%）等一众高效开源竞品，优势在于「Qwen 3.5 新架构 + 官方生态（Qwen Code、百炼 API）」的连贯性。

• 7. 争议与风险 （共 298 字）

  首要风险是信息源可信度参差。Qwen3.5-Coder 的权威披露相对单薄：官方 Qwen 3.5 主博客未单列该型号，独立 coder 专页与 Hugging Face 集是唯一一手来源，而 7B/32B 的具体基准分数多来自第三方聚合站与社区调参版，并非阿里官方统一评测。其次，发布时间标注（2026-01）早于 Qwen 3.5 旗舰（2026-02），意味着「代际归属」与「是否完全开放权重」仍需以官方模型卡为准。最后，开源代码模型的普遍隐忧——本地部署的硬件门槛（32B 量化仍需数十 GB 显存）、长上下文下的推理速度与显存占用、以及与闭源 API 在超复杂长程任务上的真实落差，都需要开发者在选型时实测验证而非只看榜单。

• 8. 适用人群与使用建议 （共 339 字）

  适合谁：希望代码不出域、需要本地或私有化部署的团队；中文 / 中英混合开发场景；预算敏感、想用 Apache 2.0 商用又不愿付闭源 API 费用的个人开发者与小公司；做 Coding Agent、IDE 插件、DevOps 自动化的工程团队。不适合谁：追求极致复杂多步 Agentic 编码且能接受云端成本的用户（应直接上 Qwen 3.5 旗舰或 Claude/GPT 闭源旗舰）；需要官方 SLA 与商业支持、对「社区调参版」信任度低的企业。替代方案：同代可选 Qwen3-Coder-Next（3B 激活、SWE-bench 70.6%、极致性价比）、Qwen3-Coder-480B（API 向超大 MoE）；跨家族可选 DeepSeek-V3.2、Kimi-K2；闭源向可选 Claude Sonnet / GPT-5 系列。

• 9. 总结 （共 181 字）

  Qwen3.5-Coder 是 Qwen 3.5 新架构在代码维度的开源延伸，用 7B/32B 两个开放权重尺寸把「长上下文 + 代码执行 + Agent 友好 + Apache 2.0 商用」打包给本地部署场景，对中文开发者与隐私敏感团队尤为友好。它的真实水位需要等阿里官方模型卡与统一基准坐实，但方向已经很清楚：开源代码模型正在把「仓库级编程」从云端奢侈品变成可以装进自己机器的合规组件。

暂无深度报告

• 

  孔梅

  —

  这两天试了下 Qwen3.5-Coder 32B 量化版，跟 Cline 配合做代码审查，比之前用的 Qwen2.5-Coder 准了不少，尤其是跨文件重构的时候上下文保持能力提升明显。不过推理速度确实比预期的慢，同样硬件上比 Qwen3-Coder-Next 慢了将近一倍，期待后续优化版本能把推理效率提上来。

---

• 

  TheAnastasijaLazić_dev

  —

  256K 上下文确实不是虚标，我把整个项目丢进去让它分析依赖关系，效果比预期好。

---

• 

  6x7ghcy99

  —

  卡成 PPT……32B 量化版在 16GB 显存上跑推理速度不到 8t/s，还是得换 7B。

---

• 

  realKathyShaw_dev

  —

  本地跑 Coder 最大的价值是数据不出域，代码仓库丢给云端 API 始终不放心，Apache 2.0 商用随便改，这比 Claude 香多了。

---

• 

  BitSharkSimmons

  —

  说实话跟 Qwen3-Coder-Next 比提升没想象中大，3.5-Coder 7B 在 SWE-bench 上可能就多了两三个点，但模型体积涨了不少，部署性价比存疑。

---

• 

  DAram

  —

  试了 Coder 7B 做 Python 代码补全，日常够用，但遇到复杂的数据结构题就露馅了，还是要靠 32B。

---

• 

  Sophia_SimmonsII666

  —

  最香的是阿里云百炼 API 价格，Qwen3.5-Coder 的 Plus 版本才 4 块多每百万输出 token，比 Claude 便宜 10 倍，做批处理完全不心疼。但注意长上下文阶梯计价，超过 128K 输入价格直接翻倍，大项目要算好成本，别等账单来了才傻眼。

---

• 

  Evelyn_Miller_Pro

  —

  部署踩了个大坑，官网写的 HF 模型卡跟我下载的不一致，折腾了一上午才跑起来，新手建议直接用 Ollama 官方版。

---

• 

  PilarLozano

  —

  用 openclaw 接 Coder 做了个自动修 Bug 的 Agent，昨晚跑了 4 个小时没中断，GitHub issue 闭环率大概六成左右，偶尔会改坏。不过对于简单的语法错误修复，成功率接近九成，日常维护够用了。

---

• 

  JaniceHall_Pro82

  —

  yyds，32B 量化跑 llama.cpp 写 Rust 的网络服务，自己处理 API 轮询加数据库写入，全程没插手。

---

• 

  JamesPatelX

  —

  代码审查功能确实不错，帮我揪出了一个多线程竞态条件，以前这种 Bug 至少得 debug 半天。

---

• 

  BettyFloresSr

  —

  问一下，7B 版本的 GGUF 文件大概多大？想在 MacBook 上跑，不知道 16GB 内存够不够。

---

• 

  Debra.Reed_2023

  —

  7B 版大概 4-5GB 量化文件，16GB 内存完全够。M 芯片还能用 Metal 加速，我 M2 跑大概 20t/s，日常补全很流畅。

---

• 

  ixtyoucl5

  —

  跟 DeepSeek-V3.2 比，Coder 在中文注释理解上强很多，DeepSeek 经常把中文注释写得像机翻。

---

• 

  HsshBase

  —

  Apache 2.0 许可就是定心丸，公司法务审查后直接放行，不用走额外的合规流程。

---

• 

  Frank.Cook_7

  —

  遇到个问题，长上下文推理到 100K 左右的时候，质量明显下降，指令跟随开始漂移，不知道是不是我量化精度选太低了。用的是 Q4_K_M 量化，有没有大佬试过 Q8 甚至 FP16 在高上下文长度下的表现，会不会好一些。

---

• 

  HelenSchmidt

  —

  回不去了，用惯本地模型之后再也忍受不了云端 API 的延迟和配额限制，哪怕慢一点也是自己的。

---

• 

  BobbyGreen_2022

  —

  发现 Coder 32B 的 FIM 内联补全能力比同参数的通用模型好不少，特别是写 SQL 的时候效率翻倍。

---

• 

  PRamirez_2020

  —

  7B 跑 Agent 多步骤任务容易崩，三步以上就开始丢上下文，建议至少上 32B 或者用 API 版。不过如果只是做单步代码补全或者写单元测试，7B 的性价比反而是最高的。

暂无评论