Qwen 3.6 35B A3B 對比 Qwen 3.8 27B：3B 活躍參數，還是 27B 稠密模型？

有兩個數字決定了這個配對，而它們朝相反方向拉扯。 Qwen3.6-35B-A3B擁有 350 億個參數，但針對任何單一詞元只會啟用其中約 30 億個。 Qwen3.8-27B則是稠密模型：其 270 億個參數中的每一個，都會用於你生成的每一個詞元。這表示混合專家模型是較輕量、適合執行的模型，但也是較重、適合持有——根據各自廠商的儲存庫，BF16 權重為 71.9 GB 對上 55.6 GB——而稠密模型每個詞元所需的運算量大約是九倍，且佔用的記憶體較少。這兩者都不是缺陷。它們是對「我擁有多少機器資源」的兩種不同答案，而哪一個答案屬於你，就是這整項決定的全部。

還有第二個理由，讓你值得花時間看這個頁面。這個比較正是讀者在搜尋 35B A3B 相關資訊時所尋找的形式——該模型小型家族中的每一個查詢都是它的一種變體——而 Qwen3.6-35B-A3B 在這裡從來沒有過任何頁面來描述它。所以這個頁面會在兩邊各放一段誠實的說明，然後就直接進入比較。

35B A3B 建置究竟是什麼

Qwen3.6-35B-A3B 是阿里巴巴 2026 年 4 月 Qwen3.6 世代的稀疏模型成員，以 Apache-2.0 授權發布於該廠商自家的 Hugging Face 儲存庫，該儲存庫建立於 2026 年 4 月 15 日。廠商的模型卡將其描述為混合專家模型，「總計 35B、啟動 3B」，由 256 個專家組成，每個 token 會觸發八個路由專家外加一個共享專家。它並非純文字模型：模型卡稱之為「Causal Language Model with Vision Encoder」，而該儲存庫帶有 image-text-to-text 管線標籤，因此它能接收文字、圖像與影片並回傳文字。原生上下文為 262,144 個 token，透過 YaRN 縮放可延伸至約 1,010,000 個。其架構佈局為混合式——十次重複「三個 Gated DeltaNet 線性注意力區塊後接一個閘控全注意力區塊」，隱藏維度 2,048，40 層——而模型卡透過點名兩項它強調的重點，將行銷話術與架構區分開來：代理式編程，以及可保留先前輪次推理脈絡的「thinking preservation」選項。該模型卡上廠商自家的表格將其列為 SWE-bench Verified 73.4、Terminal-Bench 2.0 51.5、MMLU-Pro 85.2、GPQA 86.0 以及 LiveCodeBench v6 80.4——全數為廠商自行報告且未經審核，這也是它們在下方出現時所附的標註。

Qwen3.8-27B 是什麼

Qwen3.8-27B 是阿里巴巴在 Qwen3.8 世代推出的稠密 27B 開放權重模型，以 Apache-2.0 授權釋出；其官方儲存庫建立於 2026 年 8 月 5 日，最後修改於 8 月 14 日。Qwen 自家的模型卡稱其為「精巧、對部署友善的稠密模型」，並將其定位為迄今能力最強的開放 Qwen 世代，宣稱在程式編寫、專業工作、研究與長時程代理式任務上都有所提升。它同樣是視覺語言模型——「具備視覺編碼器的因果語言模型」——除了文字之外也接受圖像與影片，原生脈絡長度為 262,144 個 token，擴充後可達 1,000,000。相較之下，其架構相當傳統：64 層、隱藏維度 5,120，中間維度 17,408 採一般前饋網路而非專家庫，並與同系列兄弟採用相同的「三線性對一全注意力」節奏。35B A3B 的模型卡談的是思考保留，Qwen3.8-27B 的模型卡談的則是彈性思考控制——一個reasoning_effort設定，預設為 xhigh，並提供 medium 與 low，而preserve_thinking則預設為開啟。其模型卡回報 LiveCodeBench v6 90.3、GPQA Diamond 89.2、OSWorld-Verified 84.3、QwenSWEBench 79.0、Terminal Bench 2.1 73.0 與 SWE-bench Pro 61.7——同樣為廠商自行回報且未經稽核。其權重總計 55.6 GB，分散於十八個 safetensors 分片，而計入視覺塔後，參數量為 278 億，這正是該模型被稱為 27B、實測為 27.8B 的原因。

最常決定這一切的關鍵數字：活躍參數

檔案對應的是總參數量，速度對應的是啟用參數量。它們是規格表上兩個不同的欄位，但讀者常把它們混為一談，這就是為什麼有人會下載 22 GB 的混合專家模型，卻期望它能裝進 16.5 GB 稠密模型所能裝進的地方。

這個機制值得直白說明，因為這正是整個取捨的核心。稠密模型在產生每個 token 時，都必須讀取自身的全部權重；稀疏混合模型則只讀取路由器所選的專家。Qwen3.6-35B-A3B 每個 token 大約讀取三十億參數的量，而 Qwen3.8-27B 讀取兩百七十億——因此混合模型在每 token 運算與解碼吞吐量上具有結構性優勢，而這項優勢確實存在。但其他專家並非免費：它們必須常駐在某處，無論是 VRAM 還是系統記憶體，否則路由器最終就得把它們抓取過來，而一次抓取的成本可能高於它省下的算術運算。所以這項優勢是有條件的，取決於能否持有完整的 35B。這是混合專家解碼的運作方式，而不是對這兩個特定模型的實測，這也是為什麼「裝不裝得下」的問題會先於「速度」的問題，而不是反過來。

• 磁碟上的總參數量，BF16 — Qwen3.6-35B-A3B：35.95B，分布於 26 個 safetensors 檔案，71.9 GB。Qwen3.8-27B：27.78B，分布於 18 個分片，55.6 GB。依據各家廠商自家的 Hugging Face 儲存庫，讀取於 2026-10-13。

• 每個 token 的活躍參數量 — Qwen3.6-35B-A3B：約 3B。Qwen3.8-27B：全部 27B，因為 dense 就是 dense。

• 架構 — Qwen3.6-35B-A3B：256 個專家，每個 token 有 8 個路由專家加上 1 個共享專家，40 層，隱藏維度 2,048。Qwen3.8-27B：單一前饋層，中間維度 17,408，64 層，隱藏維度 5,120。

• 原生上下文——兩者皆為 262,144 個 token。Qwen3.6-35B-A3B 搭配 YaRN 可延伸至約 1,010,000；Qwen3.8-27B 的規格卡則載明搭配擴展可達 1,000,000。

• 授權 — 兩者皆採用 Apache-2.0。兩者皆可從供應商下載，兩者皆為開放權重，且兩者均不附帶按席位或按呼叫計費的條款。

每一個每 token 要花你多少

這兩個模型都在 OrcaRouter 上提供服務，所以你不必下載任何東西就能解決這個問題。以下是我們在 2026-10-13 的即時目錄資料，qwen/qwen3.6-35b-a3b 的價格為每百萬輸入 token 0.248 美元、每百萬輸出 token 1.485 美元，具有 262,144 個 token 的視窗，以及 65,536 個最大輸出 token 數。qwen/qwen3.8-27b 則是每百萬輸入 0.330 美元、每百萬輸出 2.400 美元，同樣是 262,144 個 token 的視窗。兩者在我們的目錄中也以第二個主機 ID、較高的價格列出，所以在比較帳單之前，請確認你實際呼叫的是哪個識別碼。

在一個包含一百萬個輸入 token 與二十五萬個輸出 token 的工作負載上——對小型編碼代理部署而言，這是個合理的一個月用量——算術結果如下。Qwen3.6-35B-A3B：1.00 × $0.248 加上 0.25 × $1.485，約為 $0.62。Qwen3.8-27B：1.00 × $0.330 加上 0.25 × $2.400，約為 $0.93。較新的稠密模型在那種流量型態下的成本大約高出五成，而差距在輸出 token 上最大，約為 62%。

有兩件事比這些數字更重要。首先，這些是我們的目錄價格，我們不會在供應商公布的定價上加收任何費用——因此供應商調價的當天，這個頁面就會同步更新，沒有延遲，也不需要另外簽約。其次，之所以要用一個鍵而不是兩個鍵來比較它們，原因在於切換成本：這兩個 id 位於同一個端點之後，所以從一個換到另一個只是改個字串，而不是一次遷移，而自動容錯移轉意味著你可以把兩者中較不熟悉的那一個用在部分流量上，而不必把正式環境的關鍵路徑押在它上面。如果你是因為前面提到的運算成本論點而第一次評估混合專家模型，這就是檢驗該論點是否適用於你的工作負載的便宜做法。

什麼適合你的機器

這就是兩個模型真正有分歧的問題，而它取決於同樣的「總參數對活躍參數」區分。比較兩個模型都有的社群 GGUF 建置——這些是第三方儲存庫，不是原廠發行，而且檔名各自不同——相同的量化標籤會讓你得到實質不同的檔案大小：

• Q3 級，最小且合理的選項 — Qwen3.6-35B-A3B：UD-Q3_K_M 下為 16.60 GB。Qwen3.8-27B：UD-Q3_K_XL 下為 13.15 GB。

• 約 IQ4 — Qwen3.6-35B-A3B：UD-IQ4_XS 為 17.73 GB，UD-IQ4_NL 為 18.04 GB。Qwen3.8-27B：UD-IQ4_XS 為 14.25 GB。

• Q4_K_S — Qwen3.6-35B-A3B：20.89 GB。Qwen3.8-27B：15.36 GB。

• Q4_K_M，一般預設值——Qwen3.6-35B-A3B：22.13 GB。Qwen3.8-27B：16.46 GB。

• Q4_K_XL — Qwen3.6-35B-A3B：22.36 GB。Qwen3.8-27B：17.56 GB。

• Q5_K_M — Qwen3.6-35B-A3B：26.46 GB。Qwen3.8-27B：19.77 GB。

• Q8_0 — Qwen3.6-35B-A3B：36.90 GB。Qwen3.8-27B：29.05 GB。

• BF16，出貨時 — Qwen3.6-35B-A3B：71.9 GB。Qwen3.8-27B：55.6 GB。

• 另已發布——Qwen3.6-35B-A3B 在廠商自家儲存庫中有一個 FP8 檢查點，社群建置版本中則有 21.71 GB 的 MXFP4 混合版本；Qwen3.8-27B 在廠商儲存庫中同樣有一個 FP8 檢查點。

把這兩欄對照著讀，規則就自然浮現。在每一個對應的標籤上，同樣的名目壓縮率下，混合模型會重上四到八 GB，因為檔案必須裝下全部 35B，而一次只用到其中 3B。具體來說：一張 24 GB 的顯示卡跑 Qwen3.8-27B 的 Q4_K_M 還留有上下文空間，跑 Qwen3.6-35B-A3B 的 Q3 或 IQ4 時，KV 快取則在搶空間；而要在混合模型上順暢進行長上下文工作階段，則需要接近 48 GB。若想在其中任一者使用圖像輸入，還得再加上視覺塔本身的檔案。

基準目前的狀況，並不是你希望它們達到的位置。

尚未有人在具名測試框架上，以相同設定發表過這兩個模型的正面對比結果。我們不知道有這樣的結果，而本頁也不會暗示證據不足以支撐的排名。

確實存在的是，兩家廠商卡片在基準測試名稱上的部分重疊，而這點值得精確呈現，正因為它太容易被過度解讀。在兩張卡片都出現的名稱上，Qwen3.8-27B 的數字每一次都較高。SWE-bench Pro：35B A3B 為 49.5，27B 則為 61.7。LiveCodeBench v6：80.4 對 90.3。HLE：21.4 對 30.8。CharXiv 推論題：78.0 對 83.7。OmniDocBench 1.5：89.9 對 91.1。RealWorldQA：85.3 對 85.9。而在 Terminal-Bench 上，兩張卡片甚至無法像該列所暗示的那樣互相比較：35B A3B 的卡片報告的是 Terminal-Bench 2.0 的 51.5，而 27B 的卡片報告的是 Terminal Bench 2.1（Terminus）的 73.0——兩者是不同版本的基準測試，所以那一組數字根本不該拿來互相比減。

上述種種都有三項但書。這些數字來自同一實驗室相隔約四個月發布的兩份不同模型卡，且未經審計。每個模型各自報告的若干基準，只出現在自己的模型卡上，沒有對應項——SWE-bench Verified 73.4 與 MMLU-Pro 85.2 在 35B A3B 這邊；OSWorld-Verified 84.3 與 QwenSWEBench 79.0 在 27B 這邊——因此無法對齊比較。而且同一系列中較新的模型比舊模型得分更高，是預期結果，不是新發現：它只說明世代已經推進，完全無法說明舊模型是否更適合你即將送出的 token。

如果你需要這個比較具有決定性，誠實的做法是在你自己的流量上同時運行兩者。它們使用同一把金鑰、同一個端點，而容錯移轉讓分割測試變得便宜。

你應該選哪一個

選擇Qwen3.6-35B-A3B，如果你的機器能容納 35B 的權重，而且你的工作負載更偏重生成，而非一次性推理。以下是它會是正確答案的情況：

• 你有足夠的記憶體——48 GB 或更多，才能在本地舒適地使用長上下文；或者一張 24 GB 顯示卡搭配 3-bit 級量化，如果你能接受較短的視窗——而且你想要的是每 token 花費最少運算的架構。

• 您的流量屬於高併發或長時生成的類型，此時每詞元（token）成本主導帳單，而混合架構的稀疏解碼在結構上正好對您有利。

• 你想要一個 Apache-2.0 授權的產出物，能接收文字、圖像與影片並回傳文字，而且你想要兩者中較小的下載檔唯有在你自行託管而非下載它時，其中每符元價格在輸入與輸出兩者上都較低。

• 你刻意處於 3B 活躍參數規模——你接受在廠商自家的表格上落後一個世代，以換取每個 token 付得更少，並且是在熟悉的工具呼叫介面背後完成。

選Qwen3.8-27B，若記憶體是主要限制，或你想要這組合中最新的世代。它會是正確答案的情況：

• 單一張 24 GB 顯示卡，而且沒有計畫再買更多。在 Q4_K_M 下它是 16.5 GB，這為上下文留下了實際空間；混合模型則不然。

• 在這組配對中，你想要廠商自行公布最強的代理式與程式設計數據，而且你知道這些數據來自未經審核的模型卡，並非同基準的比較。

• 你的工作負載是相對較少、相對較大的請求——文件與螢幕截圖理解、儲存庫層級推理、電腦使用風格的自動化——在這種情況下，每項請求的吞吐量，不如每項請求是否做對來得重要。

• 你想要更小的下載、更快的冷啟動，以及更短的分片清單來管理。

這一切都無法造就出贏家。這兩個模型並不是在爭奪你機器上的同一個位置，而上述數字也無法證明哪一個在任何方面更優秀——它們證明的是哪一個對你現有機器的要求較低。

最常一錘定音的，是這件事：磁碟上檔案的大小取決於總參數量，而每個 token 的運算量則取決於啟用的參數量。因此，Qwen3.6-35B-A3B 可能是跑得最快、卻同時是裝不下的那一個，而 Qwen3.8-27B 可能是每個 token 成本更高、卻仍舊跑得起來的那一個。先釐清你面對的究竟是這兩個問題中的哪一個，選擇就不再是一場比較。