【2026 最新】本機 LLM 變笨？5 關 A/B Test 找出 Chat Template、量化與 Runtime 差異

本機 LLM 變笨，可能是雲端版能守住 JSON、正確選工具，本機版卻漏欄位、重複回答或忘了前文。先別急著把 Q4 換成 Q8：兩邊顯示同一個模型名稱，不代表 checkpoint、tokenizer、Chat Template、system prompt、採樣器與推論路徑真的相同。

你會建立一份 parity manifest，按五關一次只改一個變因，再用 10 題小型 Eval 確認失敗形狀。輸出是第一個不一致層在哪裡、下一步該測什麼。

TL;DR：先證明可比，再討論誰比較聰明

可比性＝模型身分 × 輸入封裝 × 解碼規則 × 記憶體精度 × Runtime；任一欄未知，都不能把差異直接歸咎於模型。

乘號代表排錯順序：前一層未對齊就停。供應商沒公開不可變 revision、實際 template 或量化方式，就寫 unknown；這只能稱「部署比較」，不能宣稱同權重 A/B。

先建 parity manifest：unknown 比猜測更有用

為雲端 A 與本機 B 各建紀錄：完整 revision、權重 SHA-256、tokenizer revision／hash、渲染 prompt 與 token IDs、system overlay、tool schema hash、有效採樣、token 上限、權重量化、K／V cache dtype、Runtime、attention backend、硬體與平行設定。查不到就寫 unknown；「沿用預設值」不是紀錄。

# 若 repo 有 generation_config.json，再把它加進檔名清單
hf download ORG/MODEL config.json tokenizer_config.json \
  --revision FULL_COMMIT --local-dir ./model-meta

# macOS；Linux 可使用 sha256sum
shasum -a 256 model.gguf ./model-meta/*

./llama-server --version
ollama show --modelfile MODEL_NAME

Hugging Face CLI 可鎖完整 commit；Ollama Modelfile 能揭露 FROM、PARAMETER、TEMPLATE 與 SYSTEM。API 只給可變別名時，checkpoint 就寫 unknown。

本機 LLM 變笨第 1 關：模型與 tokenizer 是同一份嗎？

先核對完整 checkpoint，不只看顯示名稱。Base、Instruct、不同 revision、合併權重與轉檔 GGUF 都可能同名近似。無法取得權重 bytes 時，至少記 model ID、公開 revision、服務日期與供應商文件；證據不足就不能通過「同權重」這一關。

tokenizer 也要鎖版。相同文字經不同 tokenizer 或 special token 設定後，token IDs 可能不同。用下例保存可讀字串與 IDs；敏感 prompt 先在本機脫敏：

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained(
    "ORG/MODEL", revision="FULL_COMMIT"
)
messages = [
    {"role": "system", "content": "只輸出合法 JSON。"},
    {"role": "user", "content": "回傳 {\"ok\": true}"},
]
rendered = tok.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True
)
ids = tok.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_dict=False,
)
print(repr(rendered))
print(ids)

本機 LLM 變笨第 2 關：比較渲染後 prompt，不是聊天畫面

Hugging Face Chat Templates 文件指出，套錯控制 token 會傷害表現。保存渲染字串或 token IDs，包含 role、BOS／EOS、generation prompt、system 位置與停止 token；若先渲染再 tokenize，別重複加入 special tokens。

Tool Calling 要固定工具與欄位順序再算 schema hash，並保存 Runtime 最終格式。在 Transformers 流程中，模型看到的是 template 渲染的工具定義，不是 Python 函式本體；詳見 工具模板說明。只在 JSON／工具題失敗時，先查 schema、template 與 parser。

第 3 關：鎖住有效採樣設定，而不是 UI 上的數字

把 temperature、top-p、top-k、min-p、repeat penalty、stop、最大輸出 token、seed 與 reasoning 控制全部記下，並確認服務端是否套用 model repository 的 generation config。vLLM 的 --generation-config 文件區分自動載入與 vLLM 預設值；前端 UI 顯示值不等於有效值，請保存實際 request payload，並核對未明示欄位是否由 generation config 補入。

基準先用低變異設定，然後只改一項。固定 seed 能降噪，卻不保證跨 GPU、Runtime 或 backend 逐位元一致；vLLM 重現性文件也把範圍限制在相同硬體與版本等條件。深入調整可看 LLM 採樣參數指南。

第 4 關：把權重量化、KV Cache、Context 分開測

Q4／Q6／Q8 是權重精度，K／V cache dtype 是記憶精度，context 與截斷則決定模型看見哪些 token；三者不能綁成一個開關。先用較高精度權重＋F16 KV＋短 context 建基準，再依序只改權重、只改 KV、最後拉長 context。容量先看 本機 LLM VRAM 指南，選檔再看 GGUF 量化教學。

./llama-server -m model.gguf -c 4096 -np 1 \
  --no-cache-prompt --no-context-shift \
  -ctk f16 -ctv f16 --sampling-seq k --top-k 1 --seed 42

這組參數只用來縮小變因，不是日常設定建議；4K 也要能容納測試 prompt，並受模型與記憶體支援。llama.cpp server 文件列出 template、cache、context shift 與 sampler 選項；仍以鎖定版本的 --help 為準。

第 5 關：最後才換 Runtime、Backend 與硬體

前四關一致後，才比較引擎版本、attention backend、GPU、driver、平行與 batch。浮點捨入與平行順序可能不同；PyTorch 重現性說明因此不保證跨版本與平台完全一致。

2026 年 8 月的 Level1Techs 案例，在單一 Blackwell 工作站與約 10 萬 token、未公開工具工作流中，僅換 attention backend 就出現可重複分歧。它只說明 Runtime 值得隔離，不能外推。

用 10 題小型 Eval 確認失敗形狀

找到候選差異後，以相同渲染 prompt 跑 10 題：精確擷取、否定句、算術＋格式、JSON Schema、工具選擇、工具參數、指令層級、長文前／中／後 needle、多輪指代、單元測試修補。先寫 pass／fail；工具只接 localhost mock 與合成資料。

10 題只是 regression smoke test，不是有統計代表性的 benchmark。保存 manifest hash、題目版號、原始輸入／輸出與 pass／fail。判分規則確定的題先做 smoke run；關鍵題仍重跑同一 stack，帶抽樣題跑多次並保留全部結果。擴充驗收可沿用 本機 LLM Model Retirement Eval的版本化盲測；Agent 工具鏈參考 本機 Agent 四層故障定位。

怎麼讀結果：找第一個分叉，不追最好看的分數

• 推論前 token IDs 已不同：修 tokenizer、template、system overlay 或 tools，重建基準。
• 只在 JSON／Tool Call 失敗：比對 canonical schema、tool-use template、停止 token 與 parser。
• 只在抽樣回答漂移：核對有效 sampler chain、generation config 與 seed，再做多次 trials。
• 短文通過、長文失敗：檢查截斷位置、實際 context、prompt cache、KV dtype 與 context shift。
• 只在 Q4 失敗，升 Q6／Q8 後恢復：量化成為主要嫌疑，但仍用多題與重跑確認。
• 高精度、相同輸入仍隨 backend 改變：鎖 Runtime／硬體重測並保存版本；這只定位到執行層，不自動證明哪一邊「正確」。

若五關都對齊卻仍有差異，先承認目前證據只能描述兩個部署的行為差異。雲端隱藏的 checkpoint、路由、前後處理或安全層都可能是 unknown；不要用看不到的欄位補一個肯定故事。

常見問題 FAQ

1. 同一個模型名稱就能做 Hosted vs Local A/B 嗎？

可以比較部署，不能自動宣稱同權重。只有不可變 revision 或檔案證據對得上，才把 checkpoint 視為已對齊；其餘標 unknown。

2. temperature 設 0 就完全可重現嗎？

不保證。Runtime、硬體與平行數值路徑仍可能不同；固定版本、保存輸出並重跑關鍵題。

3. Q8 一定比 Q4 聰明嗎？

不能只看 Q8／Q4 標籤判定。較高精度可作診斷基準；是否改善要在同一模型、格式、任務與硬體上重跑。

4. Token IDs 對上就代表輸入完全相同嗎？

不代表整個部署收到的輸入完全相同。Token IDs 只對齊模型輸入序列；system overlay、工具前處理、截斷與路由仍可能未知。

5. 10 題能證明 Runtime 有問題嗎？

不能單獨證明。它用來重現失敗與確認修正；根因仍靠一次一變因和版本化證據定位。

6. Tool Calling 壞掉，先換模型嗎？

先不要。先比 tool schema、tool-use template、generation prompt、停止 token 與 parser；這些都在權重之外。

7. 雲端設定看不到怎麼辦？

標成 unknown。改用供應商公開的 model snapshot、API 版本與日期作觀測邊界，結論只寫「部署差異」。

8. 什麼時候才該換 Runtime？

前四關已對齊後。否則同時換 template、量化與 backend，即使變好也不知道是哪一項生效。

給新手的 6 個重點

1. 模型名稱不是 checkpoint 證據；看不到的供應商欄位寫 unknown。
2. 先保存 rendered prompt 與 token IDs，再比較答案。
3. Tool Call 失敗先查 template、schema 和 parser，不先調 Q4／Q8。
4. 權重量化、KV dtype 與 context 是三個不同變因。
5. 固定 seed 只是降噪，不是跨 Runtime 的確定性證明。
6. 10 題 Eval 只確認你的失敗切片；決策以第一個分叉和下一個 A/B 為準。