作者patvessel (帕特貝賽爾)
看板AI_Art
標題Re: [閒聊] 又有超強小模型? Qwen3.6-27B
時間Fri Apr 24 19:01:40 2026
說說我實際使用的體感好了
很有趣的是在中型模型這塊Qwen和Gemma
不知道是刻意想做出差異還是怎樣
Gemma是Moe模型小一點 Qwen是Dense模型小一點
但是由於差距不是很大
基本上都是Q4量化前後剛好可以在24~32GB的旗艦消費卡運作的等級
追求速度選Moe 追求穩定/品質選Dense
所以我個人是把
Qwen 3.5/3.6 35BA3B
和
Gemma 4 26BA4B
Qwen 3.5/3.6 27B
和
Gemma 4 31B
各自當成接近量級的對手來比較
不管是預充填還是解碼速度都是體感不容易察覺的程度
在Gemma 4出來之前 這個部份我用了微調過的Qwen 3.5好一段時間
而Qwen3.6給我的感覺是3.5的小改版本
似乎對於在長距離程式碼上的表現有特別調整最佳化過
但是其他面相體感差異就不是很大
我當下的工作流程是會給定給約80K~100K的context
然後重複進行內容解析和生成後 把推論過程和推論結果封裝成json添加在末尾傳給下一輪
在這種狀況下
我覺得這兩個系列最大的差異是在
Qwen 3.6/3.5 非常注重格式遵循
它有非常強烈的慾望參考某個特定範例來輸出
如果有給它few-shot Qwen輸出的格式甚至語氣都會非常相似
就算沒有給他few-shot 它也會試圖自己找一個工業化的格式出來套
例如對於事件或行為的描述 我就觀察到它在沒有few-shot的情況下會試圖用WAN的
秒數:描述 格式來進行
很難說這到底是好是壞
如果你的LLM在工作迴圈中做為一個黑箱組件 或是讓他處理固定的格式的時候
比起過去的模型來說 可靠性應該會相當高
很少會出現 almost-json的低級錯誤 (雖然校驗還是必要)
但是如果用來寫作/RP/圖像辨識的時候 這個行為模式就會變得有些死板
Gemma4系列則是反過來
它們語言的自然度和多變性真的讓人印象深刻
能夠寫出相當自然而且靈活的各國語言 很適合做那種發散思維的工作
但是在指令遵循方面 就沒有Qwen的那種安心感
當然以上這只是我個人的體感 沒有實測數據也沒有統計範本
每個人的體感不一樣 請以個人實測結果為準
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.229.28.82 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/AI_Art/M.1777028504.A.B45.html
※ 編輯: patvessel (125.229.28.82 臺灣), 04/24/2026 19:06:02
1F：→ patvessel: 補充一下 我都是在關閉CoT的狀況下使用的 04/24 19:08
2F：推 YCL13: 覺得Qwen3.6是不得不出，因為Gemma4給3.5的壓力很大，像我 04/24 22:19
3F：→ YCL13: 就因此完全棄Qwen3.5了 04/24 22:19
4F：→ patvessel: 就像上面說的 取向不同 所以我目前是兩個都在線上 04/24 22:56
5F：推 YCL13: 確實是看用途，這等級的模型不可能全能，所以我是說壓力大 04/24 23:06
6F：→ YCL13: ，而不是比較強，因為真的各有擅長的地方 04/24 23:06
7F：推 YCL13: 關於您提的關掉思考，我也是關掉用，不過發現都有明顯變笨 04/24 23:08
8F：→ YCL13: 的情況，所以我後來都是用Q6，算是可以補回來 04/24 23:08
9F：→ patvessel: 我覺得開關思考和量化程度是不同層面的損失 04/24 23:30
10F：→ patvessel: 關閉COT是因為我把思維步驟分解到workflow設計層面 04/24 23:32
11F：→ patvessel: COT反而會造成CONTEXT速度消耗增加 結果也不穩定 04/24 23:33
12F：→ patvessel: 量化損失是困惑度問題 COT是推理深度問題 04/24 23:35
13F：推 YCL13: 我的經驗是一些本來可正確執行的事，在停用思考後，就容易 04/25 08:58
14F：→ YCL13: 發生無法完全依命令的情況，沒想到在改用Q6後竟然又能了 04/25 08:58
15F：→ YCL13: 例如板上很多人玩的寫小說，我設定要經過ABCD橋段才能到E， 04/25 08:58
16F：→ YCL13: 停用思考就變的會改變順序或跳過，提升成Q6又恢復乖乖寫 04/25 08:58
17F：→ YCL13: 滿多用途都有這樣的感覺，不過我沒有進行有系統的測試，完 04/25 08:59
18F：→ YCL13: 全是使用的感覺而已 04/25 08:59
19F：推 YCL13: 對了，這是到Qwen3.5才有這樣的感覺，然後Gemma4也有，像另 04/25 09:03
20F：→ YCL13: 一個還會用的GPT-oss-120B就沒有這樣的感覺 04/25 09:03
在我的理解裡面 Q4升到Q6的意思 是模型在預測下一個token的途中
因為預測機率的小數點更多 所以能夠做出更符合無量化模型的預測
簡單而不精確地的舉例就是 同樣是預測某一個token
激進量化的選項可能是 tokenA:70% tokenB 30%
溫和量化的選項可能是 tokenA:72% tokenB 26% Token:2%
因為花費更多空間保留了更細緻的機率分布和一些可能被砍掉的尾部選項
所以在機率差異不是那麼明顯的地方 可能會做出更細緻的抉擇
這就是困惑度/選擇問題 但是因為處理時需要掃過更多的權重
所以單位處理速度會變慢 = 總處理時間變長
而且因為預測是連綿不斷下去的 越長的文章誤差會累積的越大
但是COT的意思是模型會自主展開子任務
最常見的用法就是模型會打草稿或是自己評估預先審核
照你這個例子來說 (ABCDE)來說
很可能就是模型會會先寫一個答案
但是在真的把答案交給你之前會自己回頭看一下
每個步驟都到齊了嗎? 順序正確嗎? 不對就重寫或修改
但也因此原本一次可以做好的事情可能要花兩次以上步驟多次處理
所以處理量變多 = 總處理時間變長
從外部看來兩個選項都是能增進回品質且減慢沒錯 但是手段不同
量化是讓猜答案更準一些 COT是在猜答案之前先想過
所以我才會說這是不同層面的損失 不是這邊減了那邊加回來那種替代關係
你提到的狀況比較像是 Q4容易暴露的邏輯弱點有時候可以被COT攔截補回
而Q6比較不會有這個邏輯弱點 但是終究不能取代COT的推理深度
但是模型自身的COT基本上是個黑箱 展開不穩定
有時候會打草稿 有時候會最終確認 有時候卻自信滿滿什麼都不做
或是想歪去別的地方鑽牛角尖浪費資源 或是根本就不是最佳流程
例如上面說的例子 他可能一次想好五個再回頭檢查 差不多了就給你
但是如果自己設計的話 可能可以切得更精細合理(後面再提)
所以我利用程式碼和json結構來單一模型重複驗證/不同模型交錯驗證
每一步的成果應該是什麼格式 必須包含什麼要素
如果缺漏了 那就退回去重寫 這樣能保證多步推理的穩定性
所以我不使用COT的原因並不是不希望模型多步推理
而是我希望能夠自己控制多步推理的底線品質
依你說的這個狀況來舉例 如果希望模型先有ABCD後才有E
那麼或許就可以設計為
1.分段(原子化):
不試圖一次到位 小規模模型天生容易在複雜任務中迷路
所以
先讓模型預測A 預測完才預測B然後才是C/D/E
沒有先後關係的就設定KVCACAH省時或乾脆併發處理壓榨算力
每個階段後都設置的格式檢查 發現失誤那個小任務重跑就好 不用整個重做
2.最終審核:模型輸出推理結果前 檢查ABCDE是否都到齊了 順序是否正確?
3.潤飾:在不改變結果本身結構的前提下 調整語言風格或表現方式
就能從機制上確保推理不會漏掉或歪掉
而在多步推理的品質能夠透過機制保證的情況下
量化等級就能被概略簡化成 推理速度/context長度=VRAM容量 和 品質 的取捨
※ 編輯: patvessel (125.229.28.82 臺灣), 04/25/2026 10:43:26
21F：推 avans: 推推消息測試心得 04/25 11:38
22F：→ avans: 詳細 (打錯字) 04/25 11:39
23F：推 sudekoma: 推認真分享思路 04/25 13:50
※ 編輯: patvessel (125.229.28.82 臺灣), 04/26/2026 13:08:15
24F：→ ganei: 這邊用3.6 35B A3B 上下文開滿，單純拿來寫文章有些時候要 04/27 04:02
25F：→ ganei: 刷第二次提示詞才會是最佳解，如果情況允許可以試試看 04/27 04:02
26F：→ patvessel: ...情況當然不允許 04/27 18:19