雲端太遠，hook 等不了：低延遲給了本地小模型就業機會
上一篇〈AI 說做完不算數：拿證據來〉把能寫成規則的案件都交給程式處理。那道零工具閘門直接消化掉 66–67% 的回合：有工具活動、宣告至少有跡可循，放行。剩下約三分之一，是它管不到的。
麻煩就出在這三分之一。
有些回合完全沒呼叫工具，AI 卻說「完成了」「已修好」。證據只存在於它講的那句話裡，程式看不到可檢查的指令、參數或結果。這種案子需要理解語意，職缺自然又回到 LLM 身上。
剛好，我手上的本地小模型當時有點失業。
大模型主力做不成，先找份小工作
先前實測過把本地 27–35B 模型接進 Claude Code 當日常主力。現有記憶體塞得下其中幾個型號，長任務需要的協定理解與工具協作卻撐不起來。硬體是一層天花板，認知能力又是一層。
這條路先放著，之後值得獨立寫。本地 LLM 暫時沒有主力位置。
我在跑自建的判官選型測試（一百多筆標註案例，拿幾顆候選模型互比）時發現：Groq 上架的模型跟本機能跑的是同一個 Qwen 家族。本機少一趟網路、延遲天生佔優，我才想到：日常主力做不了，也許能去 hook 裡當判官。
起因與省錢、不信任 Groq 無關。當時只是看到同家族模型分別在雲端與本機，想試試本機能不能接住。那天留下的要求還有一條，當時串列裡排的備援是 Groq 上的兩顆模型：「兩個 Groq 都死的話，記得警告我。」
隔天就兌現了。
上線第一晚，不到一小時內雲端層連續失敗八次。當晚每一層各是哪顆模型，兩份紀錄對不上、不硬考證，只談能確定的部分：雲端八連敗，那些回合的案件沒人接。
差點因為太吵被開除
本地層後來由 Rapid-MLX 在我這台 48GB 記憶體的筆電上跑 Qwen3-8B-4bit，再經過 LiteLLM 接進 hook，hook 端另設六秒逾時上限。服務活下來了，判斷品質卻爛得很有存在感。
上線到改版前的兩個多星期，判官平均每天觸發 14.6 次。五十筆離線審計裡，明確的真案只有 1 筆、其餘是誤報和邊界案例，假陽性約 95%。判官幾乎看到什麼都想抓，差不多等於一個每小時巡邏、每次都說有事的警衛。
原本我以為成本是人被通知到煩。實際受害者主要是 Claude Code（CC）自己。hook 會把提醒塞回 CC 的對話脈絡，讓它撤回完成宣告、補驗證或解釋自己為什麼沒驗。
這段期間約觸發 250 次，可追溯到 244 次提醒注入。抽查十八份對話紀錄，CC 有十六次照單全收，一次合理抗辯，一次沒有後續。明顯誤報也常換來一整輪補驗證，平均又跑數個工具呼叫。
提醒文字本身只有約 3.3 萬字元，真正貴的是後面的兩百多輪機器反應。判官沒把工作帶歪，抽查裡零次讓工作方向走偏；但很會製造加班，方向沒變、回合變多。
同一把尺，砍掉一個、留下一個
這裡得先補一句：當時我手上有兩名判官。本篇主角管完成宣告；上一篇那位管搜程式碼姿勢，專辦證據都寫在工具指令裡的案件。就在總審查的前一天，後者在工作專案 repo 出事了，同一份對話紀錄中連續誤報三次，其中兩次還捏造了根本不存在的證據。開放式要求小模型「自己找證據」，結果就是它連證據一起生給你。
隔天凌晨，到期審查日全撞在一起。我給每個新機制都設觀察期、到期要交成績單，那天剛好七個項目同日到期，兩個判官都在名單上。審到一半，我還問了一句：「真的沒有任何可行性了嗎？」
原因也滿偏心的。我覺得本地模型很有潛力，想證明它有用。起念只是一次靈機一動，投入一段時間後，已經開始替它求情了。
但飯碗不能靠感情保。原本要它抓所有「沒驗證就下結論」的變體，當場收窄成三件事：保住真陽性、壓低假陽性、偶爾吵可以接受。接著用同一把尺、拿歷史案例重測殘餘判別力。
工具證據判官：程式閘門先篩過的 14 筆再交給模型複判，模型放行了 13 筆（蓋章，判定沒問題），等於沒多帶來判別力，模型層全砍。完成宣告判官還留得住，前提是把職責切到夠窄。
新版先由程式檢查這回合有沒有工具活動。有工具就直接放行，完全不問模型。只有零工具的回合才交給 LLM，而且只問一題：這句話算不算結案級宣告？
重測集就是舊版誤中過的那五十筆：新版跑完只剩 3 筆，而且原本唯一的真案還在裡面。
判斷指令寫得再長，也補不了根本問題：舊版只把 AI 的發言餵進卷宗，工具紀錄它從來看不到。先把證據層交還給程式，剩下的語意案件才是小模型該辦的。
八十億參數，窄職位夠用了
改版上線後，觸發頻率從每天 14.6 次降到 1.16 次，少了 92%。六天紀錄有 7 筆觸發。第一輪結案逐筆人工判定，5 筆是真案，命中率 71%（觸發裡有多少是真的，也就是精確率）。我後來重新親驗，剔掉一筆測試觸發、只算自然發生的 6 筆：4 真、1 邊界、1 假，67%。同一段觀察紀錄的兩種統計口徑，樣本都只有個位數，先別急著封神。
四天窗口曾出現零假陽；反向抽查 93 個帶宣告詞的回合，也零漏網。但那也只代表那四天。六天重審已經翻出假陽，之後還多一筆誤報：一段自動化測試的機器輸出（「FAST_OK」這類探針回應）被當成了完成宣告。
這份成績談不上完美，但已經從「看到誰都抓」變成能留在正式環境值班。多數回合被零工具閘門先消化掉，連 LLM 成本都沒有。
速度也符合這份工作的工況。改版上線後、剔除整批重測那天的純營運日裡，判官總共被問了 168 次（被問不等於喊有事：多數回答沒事，喊有事的才是上面那 7 筆），p50 是 1.96 秒，p90 是 2.93 秒。Groq 基準測試的 p50 是 3.6 秒，但兩邊量測條件不同，只能拿來看方向，不能當公平競速。
免費雲端履歷很好看，出勤紀錄不太行
本地層站穩之後，我還是想再給免費雲端一次機會，把 xAI 的 Grok 插到判官串列最前面。先講清楚：Grok 跟前面的推理平台 Groq 只差一個字母，是兩家不同公司；這次走的是 xAI 當時的免費額度。起因很單純：聽說它反應極快，又有高階模型等級的能力，想驗證傳聞。在同一套自建測試集（124 筆標註案例）上，它的漏抓率 16.7%，確實比本地的 45.8% 好看。
至於本地那個 45.8%，是特調困難測試集上的成績；上工後職責被切窄，真實環境反向抽查 53 個帶宣告詞的回合，漏網是零。測試集永遠比日常兇。
Grok 正式上工跑六天，只被真正問到七次：它一失敗就進一小時冷卻、案件直接落回本地層接手，次數自然多不起來。七次全敗：一次配額、兩次逾時、四次解析失敗。聽說極快，最後連速度都沒機會量到。
這些免費通道的行為（撞牆後的鎖定時間、每日容量浮動）是當時的實測快照。到寫這篇為止，xAI Grok Build 文件 與官方模型頁都沒找到免費額度、每日容量或鎖定時間的政策條文。只能說當時那條免費通道七戰全敗，不能把短期行為寫成現在仍保證存在的政策。
Groq 的兩顆 Qwen 到寫這篇為止還在架上，但都標成 Preview。官方也提醒 Preview 模型可能短時間通知後下架，不建議用於正式環境。基準測試能贏，服務能不能每天到班是另一張考卷。
本機層的優勢沒那麼華麗。它就在電腦裡，不會碰到遠端配額，延遲低，也不會因為免費政策變動突然請假。對每回合都可能觸發的 hook 來說，這幾點已經足以定勝負。
本地模型終於找到工作
我現在會先問一個很簡單的問題：這個判斷需要的證據住在哪裡？
工具活動、參數與執行結果都屬於結構化證據，交給程式規則。零工具回合是否在空口喊完成，只能從語言判斷，才交給 LLM。
接著再看工況。呼叫頻率高、延遲上限低、雲端限流會讓整套流程失去作用時，本地小模型就有很難被取代的位置。不限流、隱私、免費、不綁供應商都算優點，低延遲與隨時在位才決定這份工作能不能成立。
就算未來 CC 內建同款判官，我猜功能多半還是要連原廠服務，甚至綁在訂閱裡。我自己實際把模型換成外部 API 後，部分由 LLM 驅動的功能就真的消失了，例如原生的網頁搜尋工具直接不能用。自建 hook 活在外面，換掉底下的模型外殼，它仍然在。
硬體跟本地模型繼續進步，判斷可能會更準，現在這套調校鷹架也可能慢慢縮掉。但「證據只存在於語言裡」的案件不會消失。
至於怎麼持續發現下一個需要監工的卡點，我手上也有一套機制，那是另一篇的案子。
本地 LLM 當日常主力暫時找不到就業機會，縮到 hook 裡，反而拿到一份窄而穩定的工作。