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 的價效比反而是最高的。

暫無評論