[洋垃圾跑大模型 #2] 一張 22G 老卡跑 118B 的 coding 大模型:Poolside Laguna S 2.1 實戰

白話版：118B 塞進一張老卡，靠的是「大部分專家在睡」+「草稿先猜」

上一篇（#1）我用三張 2080 Ti 跑 119B，這篇更狠：一張就跑 118B。能這樣，是因為兩個各自簡單的想法疊在一起。

第一個你上篇看過：MoE（混合專家）。Laguna 有 118B 參數，但每吐一個字只叫醒約 8B 的專家出來算，其他都在睡。既然大多數專家隨時在睡，就沒必要讓它們全擠在昂貴的顯卡記憶體裡——把睡著的丟去便宜的一般 RAM，要用再叫 CPU 算。

第二個是這篇的新招：投機解碼（speculative decoding）。Poolside 另外發一顆很小的「草稿模型」叫 DFlash，讓它先一口氣猜好幾個字，大模型再一次驗證這幾個猜得對不對——猜對就直接收下，等於用一次計算的時間吐出好幾個字。Poolside 把這顆草稿跟本體一起發，你不用自己另外養。

這篇講三件事：Laguna 是什麼、怎麼在一台洋垃圾機上把它跑起來、還有我拿來省空間又加速的三個設定。想自己動手的細節跟坑我收在最後，前面看爽就好。

---

前言

Poolside 是一家專門做「寫程式的 AI」的公司，Laguna S 2.1 是他們 2026 年 7 月剛開放權重的模型。它跟一般聊天模型不太一樣：架構是自己的（HuggingFace 上 model_type 叫 laguna、要 custom code）。Laguna 本體的支援 2026-07 才剛進上游 llama.cpp，但要跑這套 DFlash 投機解碼配對，還是得用他們自己的 fork。

上一篇是三張卡跑 119B、示範「讓專家輪班上工」。這次我改用一張卡，換上更新、也更專注 coding 的模型，再來看看怎麼省一點空間、把速度拉高一點。

---

這顆是什麼：一顆會寫程式的 118B，每次只出動 8B

Laguna S 2.1 的規格很適合拿來單卡跑：

• 118B 總參數、每 token 只啟動約 8B（118B-A8B 的 MoE）——大部分重量隨時在睡，這正是它塞得進便宜硬體的前提。
• 原生 1M context（我這次驗到 262K）、reasoning 模型（會先想再答）。
• 配套的 DFlash 投機解碼草稿（Poolside 跟本體一起發）——後面加速那招的主角。
• 授權 OpenMDW-1.1，權重公開可下載。

一句話：它是那種「參數帳面很嚇人、但實際每步只算一小塊」的模型，剛好對上洋垃圾機「顯卡小、但 RAM 便宜又大」的體質。

---

目標與好處：一顆常駐自己家、會寫 code 的大模型

目標：在單張改裝 2080 Ti 22G（配 EPYC 7402 + 128G 八通道 DDR4）上，把 118B 的 Laguna 跑到「日常能用」的速度，而且開好開滿 context。

好處很直接：一顆 118B 等級、專攻 coding／agentic 的大模型，常駐在自己家、不燒 API、不看別人臉色。它會思考、能吃長 context、跑得動 tool call；你把它掛著，隨時能問。代價就是它是二手零件湊的，得自己花點功夫調——這篇就是幫你把功夫先花好。

---

怎麼跑起來：Poolside 的 fork + 混合 offload + DFlash

三個關鍵決定：

1. 用 Poolside 的 llama.cpp fork。 Laguna 本體支援 2026-07 才剛併進上游，但這套 DFlash 投機解碼配對還沒進上游，要跑就得用他們的 laguna branch 自己 build。

2. 混合 offload：讓睡著的專家住 RAM。 22GB 塞不下 118B 的全部重量，所以 target（本體）大部分住在 CPU 的 128G RAM 裡，只把最吃頻寬的部分留在 GPU。這是 MoE 在小卡上跑得動的根本。

3. 開 DFlash 投機解碼。 把它搭配的草稿模型掛上去（-md + --spec-type draft-dflash），讓它一次多猜幾個字。開了 DFlash，速度就從 target-only 的 21 tok/s 拉到約 29 tok/s。

下面就是我在 ai-lab 上調完、天天在用的完整參數——把 model 路徑跟 IP 換成你自己的，其他整段直接複製就能跑：

llama-server \
  -m laguna-s-2.1-attnQ8.gguf \
  -md laguna-s-2.1-DFlash-Q4_K_M.gguf \
  --spec-type draft-dflash --spec-draft-n-max 4 \
  -ngld 99 \
  -c 262144 \
  -ctk q4_0 -ctv q4_0 -ctkd f16 -ctvd f16 \
  -t 24 -tb 24 -td 12 -tbd 12 \
  -fa on \
  -fit on -fitt 7680 -fitc 262144 \
  --parallel 1 --jinja \
  --reasoning on --reasoning-format deepseek \
  --host 0.0.0.0 --port 8095

幾個調過的關鍵 flag：

• --spec-draft-n-max 4：草稿一次猜幾個字的甜蜜點（官方 BF16 用 15；Turing + Q4 草稿要調小，猜太多反而拖）。
• -ctk q4_0 -ctv q4_0：本體（target）KV 壓 Q4 省 VRAM。-ctkd f16 -ctvd f16：⚠️ 草稿 KV 一定留 F16——壓下去接受率會崩（見下面 debug ②）。
• -t 24 … -td 12：CPU 執行緒，本體 24 / 草稿 12。
• -fit on -fitt 7680：自動多塞 target 上 GPU（把 CUDA buffer 撐到 ~9GiB）。

（量化 attention 用的 laguna-s-2.1-attnQ8.gguf 跟 Q4_K_M 草稿，我壓好放在 coolthor/Laguna-S-2.1-attnQ8-DFlash-Q4-GGUF，直接下載就能配上面的指令跑。）

---

省空間又加速：三招把 21 tok/s 推到 ~29

這節是這篇的重點——都不是重訓、不是換模型，只是換設定。

① attention 換 Q8：省 2.5GB、decode 快 7%。 Poolside 官方的 Q4_K_M GGUF 不是均一 Q4——它故意把 attention 留成 F16（佔比不小），expert 才用 Q4_K/Q6_K，router、norm 這些敏感張量留 F32。我的改動很小：只把那 240 個 F16 attention 張量換成 Q8_0，其他原封不動地複製過去（不碰已經量化好的張量，才不會疊上二次量化的誤差）。結果張量本體從約 70 GiB 掉到 67.6 GiB、省了約 2.5GB。

為什麼變小會變快？因為在這張 22GB 卡上，本體大多放在 CPU RAM；attention 變小後，llama.cpp 能把更多 target 塞進 GPU，也少了 CPU 跟 GPU 之間的資料搬運。實測純跑 target：英文 19.64→21.05 tok/s（+7.2%）、繁中 19.73→21.26（+7.7%）。

② -fit 多塞幾層上 GPU。 -fit on -fitt 7680 讓 llama.cpp 自動多塞 target 到 GPU（把 CUDA buffer 撐到約 9.03GiB）——跟上一招是同一個道理：GPU 上多放一點，CPU 頻寬就少扛一點。

③ DFlash 投機解碼調到 n=4。 加上草稿模型後，英文從 target-only 的 21 跳到 ~29 tok/s、繁中到 ~19.5。--spec-draft-n-max 是「一次讓草稿猜幾個字」——Poolside 官方在 BF16 上用 n=15，但在我這張 Turing 老卡 + Q4 草稿上，n=4 才是甜蜜點（猜太多反而拖）。

品質我也驗過了：strict JSON 正常、原生 tool call 沒問題、min_window coding 題也能跑；換完量化後這幾項都還是過。

---

debug：三個上線前會踩的坑

前面看爽就夠用了；這段給想自己照做的人。

① --tensor-type attn_q=q8_0 這種簡寫對不上。 llama-quantize 的簡寫沒匹配到 Laguna 的完整張量名，等於什麼都沒換到。要生一份含 blk.N.attn_*.weight 完整名稱的 tensor-type 檔，而且先跑 --dry-run 確認「實際會換幾個張量、輸出多大」再真的做。（怎麼做這份檔、怎麼避免二次量化誤差，我另外寫一篇量化教學拆給你看。）

② DFlash 的草稿 KV 千萬留 F16。 我一時手癢把草稿的 KV 也壓成 Q4_0，結果接受率直接崩到 1% 以下、decode 掉到 5–6 tok/s。原因：草稿權重的 Q4 量化誤差，跟執行時 KV 的 Q4_0 誤差是兩套獨立的近似，不會互相抵消，疊起來草稿就猜不準了。本體（target）的 KV 壓 Q4_0 沒問題，這個警告只針對草稿的 -ctkd/-ctvd。

③ 它可能把整個 budget 想光、不吐答案。 Laguna 是 reasoning 模型，有個已知毛病：給它一個小小的 max_tokens，它可能全花在 reasoning_content 裡想，最後一個字的正式答案都沒吐。跑工具／coding 這種要拿到結果的場景，考慮關掉 thinking，或在 agent 層加一個「偵測到空的最終答案就重問」的修補。

---

收穫

最花時間搞懂的地方：我一開始以為「檔案變小 = 一定變快」，但在這種混合 offload 的機器上，真正變快的原因不是模型變小，而是GPU 少扛一點資料、CPU 少走一趟頻寬。如果模型能整顆塞進 GPU，縮小 attention 可能沒什麼感覺；正因為這張卡塞不下、非得靠 CPU，效果才會這麼明顯。

可以帶走的原則：在單卡跑不下、得混合 offload 的大 MoE 上，優先砍的是「留在高精度、又常被搬動」的張量（這裡就是 F16 的 attention）。別急著去 requant 已經壓好的 expert——那只會疊誤差、換不到多少空間。

通用原則：MoE 在便宜硬體上跑多快，八成看你能省下多少 CPU 的資料搬運，不是看帳面上的參數量。

---

收工前的 checklist

1. 用 Poolside 的 laguna fork build，別用通用 llama.cpp（DFlash 解碼器還沒進上游）。
2. target 的 attention 換 Q8_0、其他 COPY 保留；先 --dry-run 對數量跟大小。
3. DFlash 草稿掛上、--spec-draft-n-max 從 n=4 起調；草稿 KV 留 F16。
4. -fit on -fitt 7680 讓它多塞幾層上 GPU。
5. 上線前驗：strict JSON / tool-call / 一題 coding；順手確認它不會把 budget 想光不吐答案。