【2026 最新】舊本機 LLM 該刪嗎？12 題 Model Retirement Eval＋保留／封存／刪除決策樹

舊本機 LLM 佔滿硬碟時，最直覺的做法是留下排行榜較高的新模型，把舊權重全部刪掉。但 2026 年 8 月，一位 LocalLLaMA 使用者分享自稱刪過約 10TB 權重後，主觀認為舊版 DeepSeek V3.2 在一個未公開 prompt 的硬體相關問題上，反而比他手上的幾個新模型更合用。這只是沒有完整 prompt、設定、答案鍵與重複試驗的個人案例，不能證明舊模型普遍較好；它真正提醒我們的是：「新版」和「能取代你的工作」是兩件事。

這篇專為第一次整理本機模型庫、會啟動模型但不熟悉評測的讀者寫。我們不做另一張模型排行榜，也不替任何模型宣布勝負；你會建立一份 12 題私有測組，固定 Runtime 與生成設定，同時計算品質、延遲、記憶體、容量和重新取得風險，最後產出 KEEP／COLD-ARCHIVE／REDOWNLOAD／DELETE 決策收據。

先說結論：永久刪除要連過兩道門

一句話記住本文的 Model Retirement Eval：

先驗收可替代，再驗證可恢復，最後才刪。

對可用且來源可信的候選模型，「可替代」只表示：在預先定義、版本化的 acceptance set 與風險容忍度內，沒有觀察到不可接受的退步；不是證明所有未來任務都不會回歸。「可恢復」則是保存來源、完整 revision、檔名、量化、雜湊、授權與重抓指令，並在隔離快取中實際重抓、比對 SHA-256、完成最小推論。第一道沒過，依使用頻率分到 KEEP 或 COLD-ARCHIVE；第一道通過、第二道沒過，也先 COLD-ARCHIVE。只有兩道都過，才能移除本機權重，再按未來是否需要重抓分成 REDOWNLOAD 或 DELETE。

為什麼舊本機 LLM 不能只看排行榜？

公開 benchmark 適合篩選候選模型，不等於你的驗收單。Hugging Face 曾用同一份 MMLU 資料比較三種評測實作，結果分數差距足以改變模型排序；提示格式、tokenization 與評測程式都可能影響成績。官方 LM Evaluation Harness v0.4.12 提供 --show_config、--log_samples 與 --output_path，但要顯式開啟並保存輸出，不會自動替你完成整套追溯紀錄。

你的私人需求更窄：也許是保留專有名詞的改寫、離線查詢某代硬體、修改一種舊程式碼，或輸出完全符合 schema 的 tool call。新模型總分較高，仍可能在其中一項關鍵工作退步。相反地，舊模型贏一題，也不代表它整體較強；12 題的用途是找出不可替代的局部能力，不是頒發通用冠軍。

LM Evaluation Harness 適合把多選、生成與固定資料集任務做成可重跑的 machine-graded sanity check；寫作、私有知識和 Tool Call 則可用自己的 JSON 測組與 grader。兩者都應顯式設定輸出路徑，保存設定與原始輸出；不要把 12 個自訂題目包裝成具統計代表性的公開 benchmark。

如果你還在選「要下載哪個模型」，先看 AI 模型任務路由 Eval；若問題是硬體放不放得下，搭配 本機 LLM VRAM 指南與 GGUF 量化教學。本文接的是下一步：模型已經下載、用過，現在該怎麼退役。更多模型與 Agent 教學可從 AlphaLab AI 專區開始。

舊本機 LLM 退役第一步：先做模型護照

不要先憑檔名刪除。每個候選模型建立一列「模型護照」，至少記下：顯示名稱、上游 repo、完整 revision commit、檔名、格式與量化、檔案 bytes、SHA-256、model card／授權快照、下載日期、Runtime 版本、常用任務，以及是否需要申請 gated access。Hugging Face Model Cards 文件說明卡片應包含用途、限制、訓練資料、評測與授權 metadata，但作者提供的欄位可能缺漏；保存 pinned revision 的 README.md、LICENSE／NOTICE，缺項明記 unknown。

模型護照前還有一道「Gate 0」：來源不可信、hash 與既有 manifest 不符，或已確認只是另一份良好副本的重複檔，都先隔離，不啟動也不送進 12 題 Eval。保存檔名、hash、發現原因與人工確認後，依你的資料處置政策清除；下面的四分支決策樹只處理可正常載入、來源可信的模型。

python -m pip install "huggingface_hub==1.28.0"
hf version

# macOS；Linux 可改用 sha256sum
shasum -a 256 "MODEL.gguf"

# 查看 Hugging Face 快取與 revision
hf cache ls --revisions --no-truncate

# 驗證特定 repo revision 的快取檔案
hf cache verify OWNER/REPO \
  --revision FULL_40_CHAR_COMMIT_SHA

hf cache verify 會呼叫 Hub API；gated／private repo 先執行 hf auth login，但不要把 token 寫進收據。若遠端存取已被撤銷，verify 失敗不等於本機 bytes 已損壞。雜湊是檔案身分證，不是品質分數：兩個檔案的本機 SHA-256 相同，是 bytes 相同的極強證據，也能在冷封存後偵測改變；要修復損壞，仍需要另一份經驗證的良好副本。別把 repo commit SHA、Git blob SHA-1、LFS SHA-256 與本機整檔 SHA-256 混成同一欄，它們指認的對象不同。

第二步：鎖住四個變因，再讓新舊模型同場

公平比較不是只把 prompt 複製兩次。每輪都要鎖住四層：

1. 權重層：完整檔名、量化、revision 與 SHA-256。
2. 執行層：每個可部署 stack 都鎖 Runtime commit、硬體、GPU offload 與 threads；主驗收採相同工作負載與資源／延遲預算。若兩模型支援同一 Runtime，再另跑 matched-runtime 診斷，不把層數不同的模型硬套相同 offload 數。
3. 提示層：相同任務內容與限制；各模型使用原生、已記錄的 chat template，並鎖住 context 上限、temperature、top-p、seed 與停止字串。
4. 評分層：同一份題目、答案規格、權重、grader 版本與測組雜湊。

固定 seed 和 temperature 能降低抽樣差異，但不保證不同硬體或 Runtime 會逐位元輸出相同結果，所以仍要保留原始輸出並重跑。使用 llama.cpp 時，先把版本和效能參數寫進收據；下例固定 threads、GPU offload 與 flash attention，只示範版本／throughput 紀錄，不是 12 題回答 runner：

./build/bin/llama-cli --version > llama-version.txt
./build/bin/llama-bench -m MODEL.gguf -p 512 -n 128 -r 5 \
  -t THREADS -ngl N_GPU_LAYERS -fa off -o json > bench.json

這裡的 -p 512 與 -n 128 是分開的 prompt-processing／text-generation 測試，工具會使用預設 warmup；它不會產生一個完整 512→128 對話，也不會替你分出 cold／warm 端到端延遲。12 題主驗收仍要按 model card／GGUF metadata 確認並記錄原生 chat template 與 context 設定，另存每次 prompt、輸出和 wall time。

第三步：建立 4 組共 12 題私有測組

每組三題，只放你真的會做的工作。題目、輸入檔與預期格式都要版本化；知識題使用穩定、可查證且有答案鍵的事實，不拿「今天價格多少」這種會變動的問題測模型記憶。

Q1～Q3：寫作與格式控制

1. 忠實改寫：保留五個指定事實，不新增資訊，改成你的語氣。
2. 限制遵從：在字數、段落、禁用詞與輸出格式同時存在時完成任務。
3. 長文整合：從一份你有權使用的文件找出三個分散條件，摘要時附來源段落。

Q4～Q6：穩定知識與不確定性

4. 領域知識：用答案鍵驗證一個常用、穩定的硬體或專業問題。
5. 反例辨識：題目藏一個錯誤前提，通過條件是先指出問題再回答。
6. 誠實邊界：資料不足時列出缺口與驗證方法，不編造型號、日期或來源。

Q7～Q9：程式與除錯

7. 修 bug：給一個會失敗的測試，只接受能讓測試通過的最小修補。
8. 受限修改：要求只能改指定檔案，不能新增套件或破壞既有 API。
9. 根因解釋：從錯誤訊息與最小案例找根因，提出可驗證而非猜測的下一步。

Q10～Q12：Tool Call 與安全停手

10. Schema：輸出可解析、欄位與型別都正確的 JSON。
11. 工具路由：從三個假工具選對一個，參數不可遺漏或發明。
12. 安全停手：遇到缺少必要確認的刪除要求時，不呼叫工具，先指出缺少什麼。

Tool Call 題只連 localhost mock server 與合成資料，不要真的刪檔或送出外部請求。若你的主要用途不是程式或工具，就把那三題換成翻譯、研究或客服；保持四種能力面向，是為了避免測組全被單一強項綁架。

第四步：盲測、配對、分級，不被總分騙

先把模型名稱換成 A／B，隨機交錯順序，再用同一份 rubric 判分。每題採 0／1／2：0 是錯誤或不可用，1 是部分完成、仍需人工修正，2 是直接可用。常用且關鍵的題目權重 3、常用題權重 2、偶發題權重 1；權重由你在看答案前寫好，避免看完結果才替偏好的模型加分。

第一次建立流程時，確定性任務先跑一次冒煙測試，帶隨機性的生成每題先跑三次並保存所有輸出；這只是 starter default，不是統計保證。高風險或高變異任務要增加題目與 trials，並持續把 production log、邊界案例和真實失敗加回測組。報告加權品質之外，還要單列「關鍵題退步」：新模型即使總分較高，只要在不能人工補救的任務出現不可接受回歸，就不能通過這一版驗收。這和 AI Agent Harness 的思路相同：總分只是摘要，失敗路徑才決定能不能交付。

第五步：把品質、速度、記憶體與容量放進同一張收據

Model Retirement Eval 至少保存五組結果：加權品質與關鍵題退步；端到端延遲的 median；prompt／generation throughput；尖峰 RAM／VRAM；權重 bytes、備份份數和預估重抓時間。速度要分 cold 與 warm，硬體、Runtime commit、context 與 batch 設定也要跟著記，否則兩個 tok/s 數字不能公平相比。llama-bench 報告 prompt processing／text generation throughput，不包含 tokenization 與 sampling；端到端延遲和 TTFT 要另外量。

重新取得成本不是只有頻寬。Hugging Face 的 gated model 存取由擁有者控制，可設為自動或手動核准，且 擁有者可撤銷個別使用者的存取；官方也把 repo 刪除列為不可逆操作。若來源受限、revision 已消失、授權快照不完整，或下載耗時會中斷工作，重抓風險就應提高。先用官方 CLI 的 dry run 預覽客戶端計畫中的檔名與 bytes，但不要把它當成遠端仍可取得的證據：

hf download OWNER/REPO FILE.gguf \
  --revision FULL_40_CHAR_COMMIT_SHA \
  --dry-run

把 dry run 日期、列出的檔名與 bytes，以及命令中的完整 commit 存進收據。它只產生下載計畫，不能證明 payload 能完整下載或通過雜湊；要取得 REDOWNLOAD 資格，還要用隔離快取做一次真實重抓：

VERIFY_ROOT=$(mktemp -d)

DOWNLOADED=$(HF_HUB_CACHE="$VERIFY_ROOT/hub" \
  HF_XET_CACHE="$VERIFY_ROOT/xet" \
  hf download OWNER/REPO FILE.gguf \
  --revision FULL_40_CHAR_COMMIT_SHA --quiet)

shasum -a 256 "$DOWNLOADED"

gated／private repo 先以 hf auth login 完成授權，但 token 不寫進收據；這裡只把 Hub payload 與 Xet chunks 指到新的隔離快取，避免沿用既有模型 bytes。上例只示範單一 GGUF；有多個 shards、tokenizer、config 或其他必要檔時，全部列入 manifest、逐一重抓與比對，再以重抓套件完成最小推論。若容量、頻寬或 access 讓你無法做真實驗證，就選 COLD-ARCHIVE。

第六步：走完 KEEP／COLD-ARCHIVE／REDOWNLOAD／DELETE 決策樹

• KEEP：舊模型在這版測組仍有不可接受的替代缺口，而且每月都會用。留在熱儲存，環境或任務改變時複測。
• COLD-ARCHIVE：測組仍見替代缺口但少用，或雖已通過替代驗收、卻還沒證明能完整恢復。保留完整運行套件，不從所有副本移除。
• REDOWNLOAD：這版測組涵蓋的關鍵項目都通過替代驗收，且隔離快取實際重抓、SHA-256 比對與最小推論都成功；未來仍可能用到，所以移除工作副本、保留 pinned 恢復收據。
• DELETE：這個可用、可信模型在目前定義的任務範圍內沒有保留價值，也不打算依賴未來重抓。只留「為何刪」的稽核紀錄，不把它列為可恢復資產。

冷封存不是把唯一一顆外接硬碟拔掉。對難以重建的模型，至少保留兩份獨立、已驗證的副本，定期比對 manifest，並真的做一次還原與最小推論冒煙測試。checksum 只能發現改變；沒有另一份良好副本，就無法靠 checksum 修回資料。

Hugging Face 快取先用 dry run 預覽受影響的 revision 與空間：

hf cache rm FULL_40_CHAR_COMMIT_SHA --dry-run

確認輸出列出的 revision、備份與收據後，再以相同命令移除 --dry-run，由互動提示做最後確認。非快取檔案先移到作業系統垃圾桶，觀察一個工作週期後再清空；不要用模糊萬用字元或遞迴刪除命令處理整個模型目錄。

一個合成例子：總分高，不等於可以直接刪

假設 Model B 在 12 題的加權總分、速度與 VRAM 都優於 Model A，但 A 在每週必做的「保留五個硬體限制的改寫」拿 2，B 三次都只拿 0 或 1。這時 A 仍未被完全取代：若每月都用，判 KEEP；若一季才用一次，判 COLD-ARCHIVE。只有當 B 修正這項關鍵退步，且 A 的指定 revision 能實際重抓、通過 hash 與最小推論，才有資格移到 REDOWNLOAD；若已確定未來也不需要，才選 DELETE。

這是示範如何讀收據的合成情境，不是 AlphaLab 對任何真實模型的跑分。真正的門檻要反映你的人工補救時間、資料敏感度與停機成本；不要把範例權重原封不動搬去做公司政策。

三個最常讓退役結論失真的坑

1. 只改模型，卻沒鎖 chat template：格式差異可能被誤判為能力差異。保存模板與 Runtime commit。
2. 讓模型自己當唯一裁判：JSON、測試與答案鍵能程式判分就不要改成主觀印象；寫作題至少盲化模型名稱並保留人工 rubric。
3. 只看平均分：DELETE 是不可逆動作，關鍵題退步、來源失效或 hash 缺失任何一項，都比漂亮總分更重要。

每季重跑一次是實用的起點，不是科學定律。只要你更換 Runtime、GPU、量化、chat template、主要任務或評分規則，就提早複測；沒有變動時保留上季收據，能分辨驗收結果的變化來自任務能力，還是環境漂移。

常見問題 FAQ

1. 新模型排行榜更高，舊模型就能刪嗎？

不能直接刪。先跑你的關鍵任務，再確認指定 revision 與檔案可恢復。排行榜適合選候選人，不是永久刪除授權。

2. 12 題足以證明哪個模型比較好嗎？

不足以證明通用強弱。它只驗收你選定的 12 個工作切片；任務改變，就要換題與重跑。

3. temperature 設 0，還需要重跑嗎？

需要。硬體、Runtime 與數值路徑仍可能造成差異。至少保存原始輸出；對關鍵題做多次試驗。

4. SHA-256 相同就代表模型安全又好用嗎？

不是。相同的本機 SHA-256 是 bytes 相同的極強證據；來源信任、授權、模型行為與品質仍要另行驗證。

5. 冷封存只留 GGUF 就好嗎？

不夠。還要留 tokenizer、config、chat template、Runtime 版本、model card／授權快照、hash 和評測收據，否則未必能重建相同行為。

6. REDOWNLOAD 和 DELETE 有什麼不同？

REDOWNLOAD 保留 pinned 恢復路徑。它移除工作副本，但未來仍可能再用；DELETE 只留刪除理由與必要稽核證據，不再把該權重列入可恢復資產。

7. 每個舊本機 LLM 都要跑完整 12 題嗎？

第一次退役建議完整跑。之後可先用護照找出重複 hash、損壞檔與從未使用的候選，再把完整 Eval 集中在可能有價值的模型。

8. 多久複測一次最合理？

先用季度節奏。但 Runtime、硬體、量化、主要任務或來源狀態一變，就不要等到季末。

給新手的 6 個重點

1. 舊本機 LLM 的價值由你的任務決定，不由發布日期決定。
2. 先建模型護照：能取得的 revision、檔名、量化、SHA-256、授權與 Runtime 盡量記完整，缺項明記 unknown；重新建構所需檔案與設定不可漏。
3. 每個候選 stack 鎖定環境，用 12 題真實任務做盲化配對。
4. 總分之外，單列關鍵題退步、RAM／VRAM、延遲、容量與重抓風險。
5. 測組仍見替代缺口且常用選 KEEP；少用或未證明可恢復選 COLD-ARCHIVE；通過替代與恢復驗收、未來可能再用才選 REDOWNLOAD。
6. DELETE 只給目前任務範圍內沒有保留價值的檔案；先預覽目標、保存刪除理由，並再次人工確認。