~ / blog / series / 改裝 2080 Ti 22G

ls ~/blog/series/改裝-2080-ti-22g

11 篇文章

  • #日期標題
  • 12026-06-22
    [趣味競賽 進階 #1] 老將漢升(GTX 970)退場,天水的麒麟兒(RTX 2080Ti 22G)登場:NT$11k 改裝卡養一顆 27B agent

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

  • 22026-06-23
    [趣味競賽 進階 #2] 我把 100 tok/s 換成 30:快的 Gemma 12B 做完事就走人,慢的 Qwen 27B 才肯收尾

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

  • 32026-06-24
    [趣味競賽 進階 #3] 我把 context 開滿 256K,它載入成功——然後在真實對話裡 crash:一張 22G 改裝卡的 VRAM 偵探故事

    模型卡片寫 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。

  • 42026-06-25
    [趣味競賽 進階 #4] 量化 draft cache 反而更慢:Qwen MTP 投機解碼的反直覺實測(f16 比 q4 快 34%)

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

  • 52026-06-26
    [趣味競賽 進階 #5] 別讓助理每次都重讀整本對話:KV cache 存硬碟,回神快 7 倍

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

  • 62026-06-27
    [趣味競賽 進階 #6] 工具定義稅:還沒開口,就先吃掉 17K token——而且每次重算都重來一遍

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

  • 72026-07-02
    [趣味競賽 進階 #7] 在慢腦上開漸進式串流,我把自己撞進了 Telegram 的 flood control

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

  • 82026-07-03
    [趣味競賽 進階 #8] 為什麼 30 tok/s 體感比 14 還慢:TTFT 才是你真正感覺到的速度

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

  • 92026-07-10
    [趣味競賽 進階 #9] 0xc0000409:當我的 AI 服務靜默暴斃,而 log 把死因吃掉了

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

  • 102026-07-18
    [趣味競賽 進階 #10] 同一張 2080 Ti,一台生圖慢 3.4 倍——兇手是啟動 log 裡一行 dtype fallback

    兩台機器裝的是同一張改裝 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、對影片模型也完全沒用。

  • 112026-08-06
    [趣味競賽 進階 #11] 什麼?2080 Ti 居然跑得動 MiniMax-H3,還生得出 1080p 有聲影片

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