昨天開始記錄 Latency 和 Token Cost 之後，我第一次比較清楚看到一件事，同樣是一個 AI 功能，每次呼叫模型背後花掉的成本其實差很多，而且使用者問的問題越長、RAG 撈回來的內容越多、Prompt 塞進去的規則越完整，最後送進模型的 Token 就會一直往上加。

如果只有自己測試，幾十次 API Call 的差距可能沒有什麼感覺，但一旦真的有人持續使用，每個 Request 多幾千個 Token，累積起來就會變成很直接的成本。

所以今天我開始處理另一個問題，真的每一個請求都需要送給同一個模型嗎？

先把問題拆開來看

前面做 Demo 的時候，我最習慣的做法很簡單，只要使用者送出問題，就把 Prompt、檢索結果和歷史對話全部一起交給模型處理。

這種做法很好開發，因為所有東西都走同一條路，但實際把 Log 拉出來看之後會發現，每個問題的難度其實差很多。

有人只是問一個固定格式的問題，有些需求只需要從資料裡找到一小段答案，也有人真的會丟進一個需要分析、比較甚至跨多份文件才能回答的問題，如果三種情況全部都走同一個模型，系統雖然簡單，成本卻不一定合理。

於是我開始替每一個 Request 多想一層，這個問題到底需要多少能力。

Model Routing 開始有意義了

這時候 Model Routing 就變得很好理解，系統收到問題之後，可以先根據任務類型、輸入長度或需要的能力，決定後面要交給哪一個模型處理。

例如格式整理、分類或簡單資訊抽取，可以先交給比較快、比較便宜的模型，真正需要推理或長上下文的問題，再交給能力比較完整的模型。

這樣做之後，我關心的東西就不只 Accuracy，還要一起看回答品質、Latency、Token 使用量與成本。

如果一個比較小的模型在某類任務上已經可以做到足夠穩定，那每一次都呼叫更大的模型其實沒有太大必要，反過來說，如果為了省成本導致答案品質明顯下降，那這個 Routing 規則也沒有什麼價值。

便宜模型也不能憑感覺換

所以我沒有直接把所有任務換成比較小的模型，而是拿前幾天建立的 Eval Dataset 重新跑一次。

同一批問題分別交給不同模型，再比較原本記錄的正確率、格式錯誤、Latency 和 Token Cost，這時候前面花時間建立 Evaluation 的好處就很明顯，因為我終於可以用同一批資料來判斷「換模型」到底帶來了什麼影響。

有些任務確實幾乎沒有差，尤其是分類、固定欄位抽取這種輸出相對明確的工作，小模型處理起來已經很夠用，但碰到需要綜合多段資料的問題，差距就慢慢出現了。

所以 Model Routing 最後也變成 AI Engineering 裡的一個工程問題，要先知道每一類任務需要什麼能力，再決定資源要放在哪裡。

昨天我只是發現 Token 很貴，今天開始真正處理這件事之後才發現，降低成本其實會一路牽動模型選擇、Evaluation 和系統架構。

接下來我還想處理另外一個很常被浪費掉的地方，如果很多人一直問差不多的問題，真的每一次都需要重新呼叫模型嗎？