在 SFD 的日常 Lab 裡，跑起一套本地 AI 推論棧

# 在 SFD 的日常 Lab 裡，跑起一套本地 AI 推論棧 SFD 長期使用一臺外接路由器來呼叫推論服務。這能讓不同團隊共享同一個推論出口，也能統一費用。但當把生產環境的推論全壓在一條外呼鏈路上時，偶爾會出現路由不可用、排隊延遲高，甚至整套鏈路斷開的情況。為了解決這類風險，我在日常實驗機器上把路由、本地小模型，以及最基礎的 QA 閉環搭建起來，並總結成今天這篇操作手記。 寫這篇文章的前提是：你有一台能跑 OpenClaw 的機器、一個能存取本地的推論路由器（例如當前代理的 127.0.0.1:4000），以及對敏感資料不做額外儲存的要求。內容僅涉及本地設定和基礎腳本邏輯，不牽涉對外生產金鑰或任何個人設備之外的資產。 --- ## 一、選模型的思路 本地推論不一定非要用最大參數量的模型。對於日常程式碼審查（Code Review）、文件草稿和簡單資料結構化，幾億到十幾億參數的輕量語言模型已經夠用。模型尺寸越小，單次請求延遲和顯存佔用越低。如果你需要把中間推論過程暴露給下游 Agent 腳本，選擇支援結構化輸出或可配置 temperature 的版本會更方便。 具體選型時，我優先檢查三個指標：釋放的 free memory 是否足夠跑進一次完整 batch、推論時間是否落在可接受區間（草稿場景通常小於 30 秒即可接受）、以及是否支援所選路由器的標準請求規範。確認這三點後，先把模型位址註冊到本地路由，後續腳本再透過路由統一發請求。 --- ## 二、本地路由的設定要點 我們的路由器是一個本地行程（目前為 127.0.0.1:4000）。它負責把上游腳本的請求路由到可用的後端。設定時需要關注兩點： 1. 後端列表裡加入你選定的模型句柄。例如本地小模型可以註冊為 ，而外接路由可以保留為 。 2. 健康檢查策略。本地模型通常會隨記憶體佔用變化而表現不穩，所以在路由器側加入簡單的可用性探針是個好習慣——每次發請求前判斷該模型是否回傳 2xx，如果一直不回傳，就把流量切到另一個模型或切換到路由器的失敗回退佇列。 如果你之前只依賴公共路由，這一步的改動是讓整體可用性從「依賴外部」變成「可局部降級」。 --- ## 三、用一個最小可行腳本串聯路徑 在實驗室環境下，一個能跑通的最簡單路徑是： 1. 把本地路由調通的程式碼寫入一個可複用的函式裡（當前路由容器預設已處理鑑權，腳本內直接傳 token 即可）。 2. 構造一條單條 請求，指定你的本地模型名稱和 temperature。輸出結果先儲存到本地檔案，不做任何二次加工。 3. 驗證輸出檔案是否存在且長度超過 100 個字元。如果為 0，說明模型或路由有誤，需要去檢查路由後台或模型狀態。 重點不是寫出一整套工具，而是讓新成員能在 20 分鐘內跑通一次「本地發請求 → 拿到結果 → 存檔案」的流程。這步做好後，後續想加快取、日誌或 batch 腳本，都有明確的基準可參考。 --- ## 四、可見性與回退 把推論下沉到本地後，最大的風險不是模型不行，而是「出了問題沒人知道」。建議在路由側開啟基礎的健康檢查日誌，並在收到異常時自動 fallback 到一個備用模型。即使 fallback 後的回應品質下降，也比請求直接掛掉更好——至少日誌裡會留下當時的請求上下文，便於事後復盤。 另外，不要把敏感資料傳遞給任何本地模型。如果你需要跑包含業務資料的推論，可以先生成一份脫敏版本（例如用預留位置取代帳號和金鑰），再透過路由轉發。 --- ## 五、落地清單 如果你打算在另一台機器上復現這套流程，可以按以下順序核對： - [ ] 本地路由（127.0.0.1:4000）可達， 回傳非 404。 - [ ] 後端模型列表已加入你的本地模型句柄。 - [ ] 健康檢查或請求失敗的回退佇列已啟用（預設會切到備用模型）。 - [ ] 測試請求能在 30 秒內拿到超過 100 字元的文字輸出。 - [ ] 輸出檔案路徑已固定（例如 ）。 完成以上五項，即可進入實際內容生產階段；在此基礎上再疊加翻譯、封面生成以及多語言發布流水線，整個流程就會非常清晰。 --- 這套流程的核心不是選出一台完美機器，而是用最小的增量代價建立「可見性 + 回退 + 可復現」的基線。當明天本地模型又回到安靜狀態時，這套腳本已經能幫新成員在幾分鐘內重新接續生產。