一個模型能在筆電執行，不代表適合接手整個後端工作流。對想降低資料外送與 API 成本的團隊，較容易驗收的起點，是把它放進一個輸入受限、輸出可檢查的小步驟。

Liquid AI 在 2026 年 10 月 27 日發布的 LFM3 官方介紹，提供文字、視覺、音訊等六種約 2B 級模型，強調專門化與裝置端執行。其中 LFM3-1.7B 模型卡列出 1.73B 參數、輸入加輸出共 256K token 的上下文，並說明適合工具呼叫及結構化輸出，也明列不建議用於 agentic coding 或複雜多步推理。

這些是選型線索。以下用虛構的退款訊息分類示範採用方式，沒有下載模型、執行推論、微調或量測裝置效能；所有驗收數字都是教學假設。模型卡標示 LFM Open License v1.0，這次未能讀取其授權連結，商用或再散布前仍須取得並審閱實際條款，不將可下載視為任意使用授權。

第一個任務只產生待審分類

假設客服每天收到退款相關訊息。第一版只做三類分流：查詢處理進度、提出退款申請、其他或不確定。它不讀完整客戶歷史，不判斷法定權利，不呼叫退款 API，也不自行修改訂單狀態。

這樣的輸出可以和人工標註比較，也容易留下錯誤案例。模型若把「想知道昨天的退款到哪了」判成新退款申請，成本是待審清單多了一項錯誤，而非多退一次款。任務價值仍然存在，但副作用被隔在下一個已授權步驟。

最小實作可留在現有模組化單體中。背景工作讀取必要的去識別化文字，呼叫本地推論程序，驗證回傳的分類值與輸入識別碼，再寫入候選結果。第一次導入不需要先拆微服務，也不需要讓模型決定有哪些工具可以使用。

分類結果只能成為建議，不能直接授予退款權限。 若之後確有自動化需求，新增的應是明確授權與業務驗證，不是把模型的自信程度當批准。

「約 1 GB」不能當作整個程序的記憶體預算

官方介紹稱文字模型在 4-bit 精度下約需 1 GB。這個描述沒有承諾任意上下文、併發量與後端都只用 1 GB。模型卡的裝置比較另列 32K 上下文、batch size 1、100 個輸出 token 等測量條件，不能把其中的結果直接延伸到最大 256K。

工程上應量測整個服務的常駐與峰值用量，包含執行引擎、中間狀態、輸入處理以及同時執行的請求。對這個分類任務，可以先設每則最多 2,000 個輸入 token、最多 80 個輸出 token、單一執行槽。輸出預算也要檢查是否被推理內容用完而截斷分類結果。這是測試設定，不是模型官方建議值；用短任務回答短問題，才能知道後續擴大是哪一項需求造成成本。

驗收時分開記錄啟動到可服務的時間、第一個輸出等待時間、整個分類完成時間與記憶體峰值。連續處理長短交錯的訊息，比只跑一個最短範例更能暴露排隊問題。若本地程序忙碌，工作應排隊或回到既有流程，不要無限制增加並行數。

會回傳合法格式，還需要會留下未知

分類器很容易得到漂亮的格式通過率，每次都回三個合法值之一即可。但這不代表它看懂了使用者想做什麼。

測試資料至少要有明確進度查詢、明確退款申請、同時提到兩筆訂單、否定句、語句不完整，以及與退款無關的內容。每一種都要檢查分類，而非只檢查 JSON 是否能解析。「我不是要再退款」若被當成取消申請，就是需要單獨追蹤的錯誤類型。

可以先保留 100 則人工標註、未參與調整的樣本作為教學驗收集，其中 20 則刻意包含歧義或資訊不足。這些數量只是方便開始的假設，不足以代表真實分布。不要只算總正確率，還要看把「未知」錯分成確定申請的比例，以及不同語言、長度與格式是否集中出錯。

模型輸出的 confidence 欄位若沒有經過校準，不應直接拿來設定自動處理門檻。較保守的第一版，是明確列出哪些條件一律轉人工：缺少必要識別碼、包含多個互相衝突的意圖、格式驗證失敗，或超出輸入長度限制。

升級處理有資料邊界，也有成本

本地小模型處理不了時，可以交給人工，也可以在另有資料外送授權時交給較大的遠端模型。兩者都有成本，不能把所有未知都默默送到雲端，再宣稱這套系統完全本地。

假設一天 1,000 則訊息，20% 需要升級，則仍有 200 則要走第二條流程。這是算術示例，不是 LFM3 的實際失敗率。若升級比例升到 60%，要重新比較的是整體等待時間、人工修正、遠端費用與維護成本，而非只看本地推論省下多少 token 費。

遠端處理也需要獨立的輸入篩選與紀錄。某則訊息可以在裝置內處理，不代表它同時獲准傳給另一個供應商。系統若以不外送為硬限制，無法處理的案例就必須留在本地或交給受權限控管的人員。

這與 Terra 的任務接受成本可以分開使用。前一篇比較路由後的交付成本，這裡先決定哪些任務與資料根本有資格進入路由。

微調之前，先證明問題出在模型

官方將 LFM3 定位為可專門化的模型，但分類錯誤可能來自標籤定義重疊、輸入被截斷，或業務本身沒有決定誰負責判斷。這些問題換一個 checkpoint 也未必消失。

先固定模型版本、推論後端、量化格式、提示詞與驗收集，保存每次變更的錯誤類型。如果範圍內的固定格式仍持續出錯，再評估微調；如果問題集中在知識缺漏，則檢查需要的資料是否有被提供。需要跨多步規劃才能判斷的案例，應回頭縮小這個分類器的責任。

導入工作的第一張工單可以很小。選一個沒有直接副作用的分類任務，寫下未知的去處，建立一份未參與調整的人工驗收集，再量測完整程序。等這條路徑能穩定拒絕範圍外輸入，才討論下一個能力。