[LLM 深水區] 一張 24GB 顯卡最強的免費開源模型？我押 ThinkingCap-Qwen3.6-27B——想得少、跑得快、不拒答

白話版：一顆「想更少」的在地模型

你可能聽過「在自己電腦上跑 AI 模型」，但真的天天用的人會遇到一個很煩的問題：會思考的模型，常常想太久。你問它一題數學，它先在心裡碎念一大段「讓我想想，首先⋯⋯再來⋯⋯」，那段吐完你才等到答案。在雲端你感覺不到，因為別人的機器很快；在自己那張二手顯卡上，它多想的每一個字，都是你在乾等。

ThinkingCap 就是來解這件事的。它拿 Qwen 官方的 Qwen3.6-27B，做了一層很輕的微調，教它「想重點就好、別碎念」——同一題，思考的字數平均砍一半，答對率幾乎沒掉。後來有人（huihui-ai）又在上面把「這我不能回答」那種拒答拔掉，做成不設限的版本。我下載的是別人壓好的 Q4_K_S 檔，一張 2080 Ti 22GB 就跑得動，還能開到 192K 的超長對話。

這篇講三件事：ThinkingCap 到底改了什麼、為什麼「思考變短」在自己機器上比在雲端有感得多、還有它做不到的地方——27B 終究是 27B，大型改程式碼的工作我還是交給艦隊裡更大的模型。

---

為什麼要寫這篇

如果你手上有一張 ~24GB 的顯卡（3090、4090，或我這種改裝 2080 Ti 22G），想在自己機器上跑免費的開源模型，能選的其實不少。但我天天開、還 24 小時不關機的，只有一顆 27B——Huihui-ThinkingCap-Qwen3.6-27B-abliterated。名字落落長，拆開來看每一段都是重點。

Part 1 我拆了量化演算法在做什麼，Part 2 實測了 KV cache 壓縮。這篇換個角度——不是拆一個技術，是推薦一顆我真的天天用的模型，順便講清楚它為什麼值得推。

它當然不是天下第一（27B 比不過那些塞不進單卡的龐然大物），但在一張 24GB 顯卡塞得下的免費開源模型裡，兼顧速度、品質、又不拒答，它是我目前擺第一的。原因是它把一件很少人注意到的事做對了：在自己機器上，拖慢你的往往不是模型運算慢，是它決定要多想的那幾百個字。 ThinkingCap 就是專門砍那幾百個字的。

---

ThinkingCap：同一顆 Qwen3.6，想同一題只花一半的字

先講「ThinkingCap」這層是什麼。它是 bottlecapai 拿官方 Qwen3.6-27B 做的微調，官方說法是「用一組精選題目、拿最新演算法做的極輕量微調」，重點是動得很淺——不重訓、不換架構，只調「要不要繼續想下去」這個習慣，答案表現幾乎沒變。

會思考的模型（reasoning model）回答前會先產一段「思考」內容，把推理過程走一遍再給結論。這段思考很有用，但很多模型會過頭——簡單題也碎念好幾百字。ThinkingCap 教它收斂：想到夠了就停。

官方 benchmark 的數字（思考 token 用量，越少越好）：

測試	原本思考 token	ThinkingCap	省下
GSM8K（數學）	3,175	648	↓ 74.1%
GPQA-Diamond（研究所級知識）	10,777	3,351	↓ 67.8%
MMLU-Pro	3,455	1,290	↓ 53.7%

平均砍一半，最好的題目砍超過九成。（表中「省下」是官方報的每題平均縮減，不是拿兩欄平均值相除得來的。）而代價呢？答對率幾乎沒動——GPQA-Diamond 從 85.5% 掉到 83.8%，差不到兩分。這張表看一個重點就好：同一顆模型、同樣答對，吐的字少一半。

---

為什麼「思考短一半」在自己機器上特別有感

這是整篇的關鍵，也是平常用雲端的人最容易忽略的一點。

思考 token 少一半，在雲端你幾乎沒感覺——別人的機器一秒吐幾百個字，多想那幾百字也就多零點幾秒。但在自己那張二手卡上，速度是另一個量級。我這顆跑在單張 2080 Ti、Q4_K_S 量化，開內建 MTP 投機解碼實測 decode ~38 tok/s（關掉 MTP 是 ~28）。

把數字帶進去就懂了。同樣一題 GSM8K：

• 原本要吐 3,175 個思考字 ÷ 38 ≈ 84 秒才等到答案
• ThinkingCap 只吐 648 個字 ÷ 38 ≈ 17 秒

同一個答案，等待從一分半掉到十七秒。這不是「模型變快了」——decode 速度一個字都沒變快，是它決定要吐的字少了。在自己機器上，這個差別比帳面上的 tok/s 還重要。

我隨手丟一題機率給它試（不放回抽球、要分數也要小數）：它答 11/57 ≈ 0.1930，正確，繁中乾淨，整題含思考吐了 1,060 個字、答得乾淨。這就是我天天用的手感——不是最快，但問一題等一下就有、而且不會讓你等它把顯而易見的東西反覆想三遍。

---

abliterated：huihui 把拒答拔掉，省思考留著

名字裡的 Huihui 跟 abliterated 是第三層。huihui-ai 拿 bottlecapai 的 ThinkingCap 版，再做一次 abliteration——把模型權重裡負責「拒答」的那個方向找出來、消掉，讓它不會動不動說「這我不能幫你」。

要講清楚：abliteration 不會讓模型變聰明或變笨，ThinkingCap 的省思考特性也原封不動留著。它只是不再自己踩剎車。我要不設限版有很實際的理由——它在我的多模型議會（/debate）裡當一個免費在地席位，做研究、當草稿、跑我不想被模型說教的東西。設不設限是使用者自己的選擇，這顆給你選項。

三層疊起來、全部 Apache-2.0：官方 Qwen3.6-27B（base model）→ ThinkingCap（省思考）→ huihui abliterated（不拒答）。我實跑的是第四層——mradermacher 壓的 GGUF。

---

MTP 投機解碼：這顆 dense 27B 實測 +40%，同樣手法在 MoE 上卻是零

MTP 不是紙上功能，我在這張卡上 A/B 過。純 baseline（關掉投機）decode 約 27.6 tok/s；打開 MTP（n=5、p=0.75）跳到約 38.6，實測 +40%，draft acceptance 約 90%。同一顆模型、同一張卡，現賺四成速度——因為 draft head 就內建在 checkpoint 裡（GGUF 帶 1 個 MTP layer、4 個 nextn tensors），不用另外養一顆草稿模型。

有趣的是同樣這招，我在另一顆 295B 的 MoE（Hy3）上測根本沒變快。可能的原因在架構：MoE 會把連續的 token 路由到不同的 expert，投機猜出來的那幾個 token 打到的權重可能不一樣，batch 一起驗證就比較攤不掉成本；dense 的 27B 連續 token 都打同一份權重，投機比較划得來。我不會把 dense vs MoE 當成鐵律（MoE 的投機解碼還是個 active 研究題），但在我這兩台機器上，這是「為什麼同一個 head 在這顆有用、在那顆沒用」最乾淨的解釋。

---

誠實邊界：27B 就是 27B

推薦歸推薦，得把它不行的地方講清楚，不然這篇就變業配了。

第一，量化跟 abliteration 都會犧牲一點表現。 ThinkingCap 官方在全精度下 GPQA 是 85.5% → 83.8%（trim 的代價）；我再往下走 Q4_K_S + abliterated，等於又疊了兩層近似。日常對話、推理、寫小工具感覺不出來，但要頂到極限的知識題，它比不過全精度大模型。想少損失一點可以換 Q5/Q6 的 GGUF，代價是 VRAM。

第二，27B 不是大型 agentic coding 的料。 先別誤會——繁中算術、strict JSON schema、原生 tool-call、丟一段壞掉的 Python 叫它跑起來修好，這些我都用腳本自動測過會過，51K token 的 needle 也精確撈得回來。它撐不起來的是大型、多檔案、要在真實 repo 裡連續東改西改那種工作，那種活我在艦隊裡是交給更大的模型。它有個更大的 MoE 兄弟 Qwen3.6 35B-A3B，我在 SWE-bench Lite 上測過（Part 24），48.33%，但那是另一顆、更大、更吃資源。ThinkingCap-27B 的位子是「問一題快快答、不拒答、24 小時在」的那個席位，不是「幫我重構整個專案」的那個。

看清楚它的位子，它就是一顆很划算的在地模型。

---

收穫

最花時間搞懂的地方：一開始我把 ThinkingCap 當成「更快的模型」，量了半天 tok/s 覺得沒特別快。後來才想通——它不是吐得快，是要吐的字少。decode 速度一個字都沒變，省的是「它決定要想多長」。這個軸我以前選模型從來沒算進去。

可以帶走的判準：挑在地模型別只盯參數量跟 tok/s。真正決定你等多久的，是「一題總共要吐多少字」乘上「一個字多少秒」。efficient-thinking 是被大部分人忽略的第三軸——尤其在自己那張慢卡上，它的權重比帳面 tok/s 還高。

通用原則：在自己機器上，慢的常常不是模型，是它決定多想的那幾百個字。

---

一句話總結

一張 ~24GB 顯卡、想養一顆天天用、反應不拖泥帶水、又不會對你說教的免費開源模型，Huihui-ThinkingCap-Qwen3.6-27B-abliterated 的 Q4_K_S 是我目前的第一名。全 Apache-2.0、單卡開 MTP ~38 tok/s、撐 192K、思考只花一半。把大型改程式碼的活留給更大的模型，剩下的日常，它夠了。

---

進階：自己在一張卡上跑起來（不讀不影響使用，想照做再看）

前面的重點看完就夠用了；這段是給想自己動手跑的人。我下載的是 mradermacher 的 i1-GGUF，用 imatrix 校準過的 Q4_K_S，約 16GB。llama.cpp 的實跑指令（IP 換成你自己的）：

llama-server \
  -m Huihui-ThinkingCap-Qwen3.6-27B-abliterated.i1-Q4_K_S.gguf \
  --host 0.0.0.0 --port 8082 \
  -ngl 99 \
  -c 196608 -ctk q4_0 -ctv q4_0 \
  -fa on --jinja \
  --spec-type draft-mtp --spec-draft-n-max 5 --spec-draft-p-min 0.75

幾個關鍵：

• -ngl 99：所有層全丟上 GPU，一張卡吃得下。
• -c 196608：192K context。單靠 16GB 的權重塞不下這麼長的對話記憶——訣竅是 -ctk q4_0 -ctv q4_0，把 KV cache 也壓成 4 bit。整張 22GB 的卡最後大概吃到 21GB，剛好。（開 MTP 時 context 最高只能到 217K；要吃滿原生 256K 得把 MTP 關掉——所以我 production 設 192K 留點緩衝。）
• --spec-type draft-mtp --spec-draft-n-max 5 --spec-draft-p-min 0.75：打開前面講的那個 MTP 投機解碼，就是 +40% 的來源。

一個雷提醒：2080 Ti 是 Turing（sm_75），現在的 llama.cpp 預編 binary 不一定帶這個架構，我是自己編 CUDA 版（cuda75 build）才跑得動。老卡的通則就是這樣——想跑新東西，編譯這關躲不掉。

---

這個系列的其他篇：

• Part 1：量化演算法在做什麼？從 Q4_K_M 到 TurboQuant 的三層拆解
• Part 2：TurboQuant 實測——KV Cache 3-bit 壓縮，真的零損失？
• 它更大的 MoE 兄弟在 SWE-bench 上的失敗解剖：Qwen 3.6 35B 的 155 題