GTX 970 那系列結尾我說「想在老卡上掛 agent,但 E2B 太小」。與其買新卡,我去二手市場撈了一張改裝 22G 的 2080 Ti——淘寶標價 ¥2079、到手含海運雜費約 NT$11,000——剛好夠把一顆常駐 27B 的 agent 腦養在家裡那台廉價老桌機上。這篇講用合理價錢挖到剛好夠用的好料的爽,跟它背後的工程。

選本地模型我也是先看 tok/s。Gemma 12B 跑 90-100、爽到飛起,可是掛上 kanban 工作板,它做完內容就「結束」,從不回頭把卡標完成。換成慢三倍的 Qwen 27B,board 反而開始乖。這篇講一個反直覺的選擇:當腦要持續守一套程序,吞吐量根本不是該看的數字。附:連我查 log 都差點被 grep 騙。

模型卡片寫 n_ctx_train=262144。22G 的卡。27B 的 Q4 權重才 15.7GB。算盤一打:開滿 256K 啊,還剩好幾 GB。-c 262144 啟動,載入成功、沒報錯。跑幾輪對話就 503、服務自己重啟。日誌沒有漂亮的 out of memory,只有一行 0xc0000409。free VRAM 一看只剩 170 MiB——剩下的 GB 去哪了?這篇是把它查到底的偵探故事:我原本賴給 context checkpoint,讀了 llama.cpp 原始碼才發現它其實住系統 RAM、真正吃 VRAM 的是 KV cache;free-VRAM 對 context 是非線性的,而真正穩的甜蜜點不是 256K,是 128K。

主 KV 我量化成 q4 省記憶體,很合理。那 MTP 的 draft cache 順手也量一下吧——它只是個小草稿,直覺穩賺。測下去打臉:q4 draft cache 29.6 tok/s,不量化的 f16 反而 39.7,還更省記憶體。draft cache 是少數「量化淨虧」的地方。附:量化為什麼會同時拉低速度、acceptance 跟省不到記憶體的三重損失。

對話一長,每傳一句它都要把整段重讀一遍(re-prefill)才回你——重開、被擠掉快取後尤其痛。stock llama.cpp 沒內建把 KV cache 存硬碟(feature 被官方標 not planned),我用一支 60 行的 proxy 騙它做到:restore 比重算快 7×(5K 對話 9.9 秒→1.4 秒)。附:機制、proxy 設計、和為什麼我目前還沒上線它。

我數了一下家裡那個 AI 助理每次回話前的開銷:還沒開始處理我輸入的文字,就先吃掉約 23K token,其中 17K 只是『工具的使用說明書』。更慘的是它是 hybrid 模型,快取一沒命中就把這 17K 從頭重算——一個對話回合可能重算十幾次。這篇講一個被嚴重低估的成本:模型開口前的「打底開銷」。解法不是砍工具,是像技能那樣『用到才載』。

我想讓慢吞吞的本地 agent 少一點等待焦慮,於是開了 Telegram 的「逐字浮現」串流——每隔幾百毫秒就改寫一次訊息。結果一個一百多秒的回應發出上百次編輯請求,正面撞進 Telegram 的 flood control,被罰等兩百多秒,整個 bot 卡死,連最終答案都送不出去。這篇講一個短而毒的教訓:慢模型不該開漸進式串流,一次性送最終答案反而穩。附 log 實證。

我把家裡那顆 agent 腦的 decode 從別台的 14 tok/s 換成這台 30,結果它感覺更慢。tok/s 這個數字我盯了一年,原來它量的是「吐字多快」,不是「多久才開始吐」。在一顆 hybrid 模型上,一次 cache miss 就把整段 prompt 從頭重算——同一台機、同一顆腦,暖機 2.6 秒、冷掉 216 秒。這篇用 Hina 自己的 log 講:為什麼該盯的是 TTFT。

一台 headless Windows AI 主機上的本地腦,偶發在真實負載下無聲無息地死掉:client 吃到短暫 503,服務自己又活回來,應用程式 log 一片空白。最氣的是真兇不是模型本身,是我自己——重啟前 log 把 crash 當下那行死因截掉了。這篇是把死因從『被自己的 log 掩埋』裡挖出來的偵察故事:為什麼會自我重啟的服務最會掩埋自己的死因、為什麼要先看 OS 層的 Event Log、以及 0xc0000409 到底是什麼。誠實在先:根因我還沒 100% 確認,這是還在查的紀錄,不是結案報告。

兩台機器裝的是同一張改裝 2080 Ti 22G,一台生 Z-Image 暖機 median 46.08s,另一台一樣的卡只要 ~9.5s。當天記錄上的結論很硬:46s 就是這張卡的天花板——GPU 全程 100%、模型常駐、卡也對。但我記得另一台一樣的卡跑過 10 秒(那筆沒進知識庫),一查發現數據沒騙人、只是漏了一塊。真兇不是矽晶片,是 ComfyUI 啟動 log 裡一行精度 fallback:Turing 沒有 bf16 tensor core,ComfyUI 為了保精度把權重留在 fp32,算得慢 3.4 倍。這篇是把兇手從『100% GPU 看起來就是天花板』這個舒服答案裡挖出來的偵探故事——外加兩個誠實提醒:這個旗標不省 VRAM、對影片模型也完全沒用。

四個檔案在磁碟上 38 GiB，而卡只有 22 GiB。一張 2018 年的改裝 2080 Ti 22G(sm_75)照樣跑出 15 秒 1080p 有聲片。完整配置、實測速度與畫質，最後才是一路怎麼試出來的。

為什麼 GGUF 量化後檔案變小，tok/s 卻沒變快?拆開 CUDA 後端 .so 才看懂:Turing(sm_75)的整數 tensor core 只有 s4×s4 跟 s8×s8 兩種同寬組合，4-bit 權重配 fp16 activation 這格在任何架構都不存在。GGUF、AWQ、Marlin 全靠反量化撐過去。

Qwen3.8-27B 在 2080 Ti 的免費加速實測:修復版 chat template 讓 KV 快取命中 94.5%,MTP 草稿深度 2 開到 4 讓 decode 從 41.6 到 47.6 tok/s。附完整驗證方法。

兩張改裝 2080 Ti 22G 用 llama.cpp 的 tensor parallel 接上 Qwen3.8-27B，配 MTP 投機解碼從單卡 37.1 tok/s 衝到雙卡 59.632 tok/s，還能開到 262K context。內含現在正式在跑的組態、三個上游踩坑，和雙 5060 Ti 社群數字的對照。

有人來信要我在跑雙 2080 Ti tensor parallel 時開 nvidia-smi dmon -s t 看 PCIe 頻寬。實測 AllReduce 吐字時只用掉不到 1%、prefill 約 6.6%，最忙的一格是 8%——瓶頸不是頻寬是延遲。

Ubuntu 的 libnccl2 跟 CUDA 13 驅動不相容，自編 NCCL 2.31.2 修好之後，prefill 的 PCIe 流量掉了 99%——而速度幾乎沒動。那個看起來很糟的 fallback，其實沒讓你付多少代價。

Qwen3.8-Flash-Next（176.94B）跑在三張改裝 2080 Ti 上：128K context 拿到 23.14 tok/s，開 ngram 投機解碼後改檔案衝到 77.56。附三種量化在相同條件下的對照。

把 DGX Spark 上的 MiniMax-H3 + LTX-2.5 兩段式產線搬到一張 2018 年的改裝 2080 Ti 22G。五個非改不可的地方，其中兩個失敗時完全無聲、一個會把錯誤印在日誌裡然後自己降級。附完整 workflow 與解析度對照。