聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

最後一個階段，把 30 天累積的知識收攏成架構思維。第一站是一個貫穿本系列、卻始終沒有完整展開的概念：模型分流（Model Routing）。

先聲明一件事，也是這篇動筆前最重要的查證結論：Claude 官方 API 沒有提供「自動幫你在多個模型之間選擇」的內建功能。 分流不是一個你打開某個參數就會發生的魔法，是你自己設計的架構決策——用哪個訊號判斷任務難度、難度低的送去哪個模型、難度高的送去哪個模型，這整套邏輯要你自己搭。今天要講的，是這套架構背後的學術根據，以及怎麼用本系列前 26 天學過的工具，把它組出來。

本篇引用的學術研究，於 2026 年查證於 arXiv 論文原文與作者資訊；Claude 相關的模型規格與參數，沿用本系列前面各天已查證的內容。

這篇對你的意義：一個你每天都在做、但沒意識到的決定

今天的主角聽起來很像架構師才需要的東西。但它的核心其實是一個你每天都在做的判斷，只是你可能從沒把它當成一個決定。

那個判斷是：這件事，值得用最好的工具嗎？

你不會開跑車去買醬油，也不會用微波爐煮一桌年菜。但回到 AI 上，多數人的預設是「反正就用最強的那個」——因為選擇要花腦力，而用最貴的感覺最安全。

Day 1 就講過這個直覺為什麼是錯的，Day 6 給了一張決策表。今天要做的，是把那個「每次手動判斷」的動作，變成一套可以自動執行的規則。

如果你不寫程式，這篇仍然有兩個帶得走的東西：

1. 理解「為什麼便宜的模型不是次等品」——它們是不同的工具，這個觀念會直接影響你在對話視窗裡怎麼選模型。
2. 一個判斷框架：先問「這題需要什麼」，再問「哪個工具剛好夠」。這個順序反過來（先挑工具再看夠不夠）就是多數人在浪費錢的地方。

如果你在做產品，這篇加上明天的 Day 28，是把前 26 天的省錢技巧真正組裝起來的地方。

目錄

一、學術根據：FrugalGPT 與 LLM Cascade

模型分流不是憑空冒出來的工程直覺，背後有明確的學術出處。2023 年，史丹佛大學的 Lingjiao Chen、Matei Zaharia、James Zou 發表了論文《FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance》（arXiv:2305.05176）。

這篇論文提出三種降低 LLM 使用成本的策略，其中一種正是今天的主題——LLM Cascade（模型級聯）：把多個不同能力、不同成本的模型串成一條鏈，簡單的請求讓便宜模型先處理，只有便宜模型的答案不夠好時，才升級送到更貴的模型。論文報告的結果是：在維持跟最強模型（論文用 GPT-4 當基準）相當表現的前提下，成本最多可以降低 98%；如果成本抓一樣，準確度甚至能比單獨用最強模型再高 4%。

這裡要誠實說明查證的過程：CLAUDE.md 一開始就標記這塊「正確出處尚未確認」，這次動筆前特地重新查證——FrugalGPT 這篇論文的作者、機構、arXiv 編號、核心主張，經多方比對後可以確認無誤，這是目前該領域最常被引用的奠基性研究之一。但要注意：FrugalGPT 是學術研究成果，不是 Anthropic 官方提供的功能或工具，Claude API 本身沒有一個叫「cascade」或「frugal mode」的參數——它是一套你可以參考、自己實作的架構思路。

二、Cascade 只是其中一種做法：Cascade vs Routing

FrugalGPT 論文之後，這個研究方向持續發展，後續文獻通常把「多模型選型策略」拆成兩大類：

Cascade（級聯）：依序嘗試，從便宜模型開始，答案不滿意才往上升級。優點是大部分請求可能第一關就解決，不需要事先知道問題難度；缺點是真的需要升級的請求，要付兩次成本（先讓便宜模型跑一次，才送到貴的模型）。

Routing（路由）：送出前就先判斷這個請求該給哪個模型，直接送過去，不會有「先跑一次再升級」的重複成本。優點是每個請求只跑一次；缺點是判斷難度這件事本身可能不準，如果分類邏輯誤判，一個困難任務可能被誤送到便宜模型，直接拿到品質不夠的答案，而不像 cascade 還有「不滿意就升級」的補救機制。

這兩種策略不是互斥的，多篇後續研究（例如探討路由與級聯統一框架的文獻）都指出，實務上常見的做法是把兩者結合——用路由先做一次篩選，級聯再當最後一道品質保險。

三、把 Cascade / Routing 用 Claude 的詞彙重新講一遍

今天不深入介紹學術文獻裡的技術細節（那需要另一個系列的篇幅），但值得把這套架構思維，對照回本系列已經講過的 Claude 工具：

① 難度判斷,對應 Day 3 的「20 個測試案例」。 Cascade 或 Routing 都需要一套判斷任務難度的機制，最簡單的起點就是 Day 3 提過的「先準備一組有代表性的測試案例，跑過所有候選模型，比較結果」——這份測試集不只是選型時用一次就丟，它是分流邏輯長期依賴的判斷基礎。

② 分流目標，對應 Day 1、Day 4、Day 6 的四階模型光譜。 Fable 5 到 Haiku 4.5，天生就是一組現成的「級聯階梯」——簡單任務先給 Haiku 4.5（Day 4），Haiku 答不好或信心不足再升級到 Sonnet 5、Opus 5，真正棘手的才給 Fable 5。

③ 同一模型內的「輕量升級」，對應 Day 14 的 effort。 如果你不想跨模型切換那麼複雜，Day 14 講的 effort 五檔位，其實提供了一種更輕量的分流方式——同一個模型，簡單請求用 low，複雜請求用 high 或 xhigh。這不是論文原本定義的 cascade（沒有換模型），但解決的是同一類問題：用便宜的處理方式對付簡單任務，把「加碼」留給真正需要的地方。

④ 升級的判斷訊號，對應 Day 20 的驗證技巧。 Cascade 需要判斷「這個答案夠不夠好，要不要升級」，Day 20 教的 Best-of-N 驗證、要求引用來源、允許說不知道——這些技巧產生的訊號（例如模型自己承認「沒有把握」），正好可以當作觸發升級的依據。

四、一個簡化版路由邏輯

❌ Before：一支模型從頭用到尾

def answer(question):
    return client.messages.create(
        model="claude-opus-5",  # 不管問題多簡單，一律用最貴的模型
        max_tokens=1024,
        messages=[{"role": "user", "content": question}],
    )

✅ After：依難度分流，便宜模型優先，必要時才升級

def classify_difficulty(question):
    # 用便宜模型做前置分類，Day 4 講過這正是 Haiku 4.5 的專長：分類、路由判斷
    result = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=10,
        messages=[{"role": "user", "content": f"這個問題複雜嗎？只回答 simple 或 complex：{question}"}],
    )
    return result.content[0].text.strip()

def answer(question):
    difficulty = classify_difficulty(question)

    if difficulty == "simple":
        response = client.messages.create(
            model="claude-haiku-4-5-20251001",
            max_tokens=1024,
            messages=[{"role": "user", "content": question}],
            output_config={"effort": "low"},  # Haiku 不支援 effort，此處僅示意其他模型的等效寫法
        )
    else:
        response = client.messages.create(
            model="claude-opus-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": question}],
            output_config={"effort": "high"},
        )
    return response

Before 版本的問題不是「答案不好」，是每一題都付最貴的價錢，不管題目多簡單。After 版本先用便宜模型做一次分類（這一步的成本遠低於直接送去 Opus 5），再依分類結果決定要不要升級。這正是 Day 4 提過的「用便宜的東西保護貴的東西」在架構層級的完整體現——今天你看到它不只是一句原則，是一套真的可以落地的判斷流程。

註：範例中 Haiku 4.5 那一支請求刻意加了 output_config={"effort": "low"} 只是示意——Day 14 查證過 Haiku 4.5 不在 effort 支援清單內，實務上這個參數在 Haiku 4.5 身上不會產生作用，請依你實際選用的模型決定要不要帶這個參數。

五、分流跟「調 effort」有什麼不一樣

Day 14 學過的 effort 參數,乍看跟今天的分流很像——都是「依難度調整投入的資源」。但兩者的作用範圍不同,值得在架構設計時分清楚。

effort 是同一個模型內部的調節：模型能力的上限不變，改變的是這個模型願意花多少力氣。分流是跨模型的選擇：不同檔位對應的是完全不同的能力上限——Haiku 4.5 開到最高的努力程度，能力上限還是不會超過 Opus 5 的下限。

這代表兩者解決的是不同層次的問題：如果你的任務難度差異在「同一個模型都能勝任、只是要不要多想」的範圍內，effort 就夠用（例如 Day 14 提過的，同樣是 Opus 5，簡單分類用 low、複雜分析用 high）；如果任務難度差異大到「便宜模型即使拚盡全力也做不到」，才需要真正的跨模型分流。 實務上,兩者常常疊加使用——Day 28 的架構範例裡，第二層「依難度選模型」用的正是分流，選定模型之後再疊加 effort 做同一模型內的精細調整。

本篇自我挑戰

• 今日挑戰：盤點你目前所有呼叫 Claude 的地方，有沒有「不管問題難易度、一律用同一個模型」的情況。挑一個流量最大的情境，試著設計一個最簡單的二分類規則（哪怕只是關鍵字比對，不用到 AI），看看能不能把一部分請求導去便宜模型。

• 反思：FrugalGPT 論文的核心洞察，其實是「多數請求並不需要最強的能力」——這句話聽起來理所當然，但多數人設計系統時，直覺反應是「保險起見都用最好的」。這種「保險心態」在什麼情境下是合理的謹慎，在什麼情境下只是沒有算過帳的浪費？

總結

模型分流的學術根據，是 2023 年史丹佛團隊發表的 FrugalGPT 論文，核心概念是 LLM Cascade——簡單請求給便宜模型，答案不夠好才升級，論文報告的成本降幅最高可達 98%。後續研究把這個方向細分成 Cascade（先跑再升級） 跟 Routing（先分類再送出） 兩條路線，兩者常被結合使用。

最重要的一句話收在這裡：Claude API 沒有內建的自動分流功能，這是你自己要設計的架構。但好消息是，本系列前 26 天教過的每一項工具——Day 1/4/6 的模型光譜、Day 3 的測試案例、Day 14 的 effort、Day 20 的驗證技巧——湊起來就是一套現成的分流工具箱，不需要再另外學什麼新東西。

本日關鍵字回顧

• FrugalGPT：Chen、Zaharia、Zou（史丹佛，2023，arXiv:2305.05176）發表的論文，提出 LLM Cascade 等降本策略，成本最高可降 98%。
• LLM Cascade（級聯）：由便宜到貴依序嘗試，答案不滿意才升級，可能產生重複成本但不需事先判斷難度。
• Routing（路由）：送出前先分類難度直接送對模型，每題只跑一次，但誤判會直接影響品質。
• 無內建分流功能：Claude API 沒有自動跨模型分流機制，需自行設計判斷邏輯與升級規則。
• 前置分類器：用便宜模型（如 Haiku 4.5）先做難度判斷，再決定是否升級到更強模型，是最基礎的路由實作方式。

明天把今天的架構思維，擴展成一套完整的分層系統——小模型前置分流、大模型收尾，以及這套架構在失敗時該怎麼處理。

Day 28，LLM 成本優化架構完整拆解。