小丁的家

標籤: Token 優化

  • Claude 分流實戰:訂閱 / API / Foundry / 本地怎麼選 + 省 Token

    重點摘要

    • 真正的重點不是「省幾個 token」,是哪種工作走哪個通道:公開/通用 → 訂閱、公司資料 → Azure Foundry(留 Azure 邊界)、機敏/不確定 → 本地 LLM。
    • 從零開發:原型用訂閱(便宜、快迭代),第一次「真公司資料 / schema / 憑證」要進 prompt 才切 Foundry——切換點是資料事件,不是階段名。
    • 真機敏用「假資料 → 雲端產出 → 換回真值」混合法,真值永遠不出公司。
    • 公司的東西用「公司商用訂閱(Team/Enterprise)或 API/Foundry」,不是員工個人 Pro/Max——非機敏也不該走消費級條款。
    • 底層功夫:context 是每輪重算的乘數,長 context 又貴又笨(準確率掉 13.9–85%);同事續用 compact、換事用 clear、怕忘的寫進檔案。
    • 各模型快取門檻不按貴賤排:Opus 4.8 與 Haiku 4.5 都要 4,096 tokens,Sonnet 4.6 與 Fable 5 只要 2,048。

    很多人把「用 AI 怎麼划算」想成「省 token」,其實真正的重點在更上層:哪種工作該走哪個通道(訂閱 / API / Azure Foundry / 本地),以及怎麼分階段切換。把通道分對、把資料分流對,比你在單一通道裡省那幾個 token 重要太多。這篇先講分流與分階段(大局),再講進了通道之後怎麼省 token、保持聰明(底層功夫)。所有定價與快取數字都以官方資料核對過。

    Part 1|分流:哪種工作走哪個通道

    第一件要釐清的事:「訂閱 vs API」不是「機密與否」的軸。訂閱和 API 都是把資料送到 Anthropic 雲端,兩者差別是計費方式與資料條款,不是「資料會不會外洩」。真正的機密分流要靠第三、第四個選項:留在你既有雲邊界的 Azure Foundry,以及完全不出公司的本地 LLM。先把三條軸分開:

    • 機密軸:本地 ↔ 雲端。決定資料能不能離開公司。
    • 信任邊界軸:Anthropic 自己的雲 ↔ 你既有的雲(Azure/AWS/GCP)。Foundry 讓資料留在公司已核准的 Azure 邊界。
    • 計費 + 模式軸:訂閱(互動、固定費)↔ API(程式化、按量、商用條款)。

    哪些資料可以做哪些:三層分流

    資料類型 走哪 為什麼
    公開 / 不重要 訂閱 便宜;公開資料不怕被拿去訓練
    內部但不機密(已在 Azure) Azure Foundry(或商用 API) 留 Azure 邊界、預設不訓練、可開 ZDR
    機敏 / 涉密 / 不確定 本地 / 地端 LLM 絕不上雲;default-deny,不確定就當機敏

    為什麼公司資料走 Foundry 是最佳解?因為信任邊界早就跨過了。如果你的 code 已經在 Azure DevOps、公司也接受 Azure Foundry,那走 Foundry 的 Claude 是留在同一個 Azure 邊界裡推論,不是再送到 Anthropic 自己的雲——邊際的資料暴露趨近於零。它複用你早就過關的 Azure 合約與資料條款,比直連 Anthropic API 更乾淨。(注意:Foundry 是功能子集,不支援 Anthropic 的 Managed Agents 與 server 端工具,純 code 生成 / 對話 / 一般 tool use 沒問題。)

    你的工作 → 用哪個

    工作 性質 用哪個
    ESG 討論 / 問問題 公開、通用 訂閱
    ESG 文案(通用骨架) 公開 訂閱
    ESG 文案(含公司真實數據) 內部 Foundry 或假資料混合
    專案討論(通用、不涉密) 一般 訂閱
    專案討論(涉公司設計 / 架構) 公司資產 Foundry
    開發 / BUG(公司 code) 公司資產 Foundry

    切換規則:只要問 2 個問題

    ① 碰到「公司機密 / 內部資料 / code」嗎?
    否(公開 / 通用) → 訂閱
    是 → ② 真機敏 or 不確定?
    不(內部但可上 Azure) → Foundry
    是 → 假資料混合 / 本地

    預設是訂閱(互動 + 公開),只有「踩到公司資料」或「要自動化」才翻到 Foundry / API。重點:這是按任務類型路由,不是每句話狂切——你開一個工作時就決定走哪條,不會中途換。兩個帳戶(訂閱 + Foundry/API)各管各的場景,既省又乾淨:訂閱吃高頻互動 + 公開的大量量(已預付、邊際成本趨近 0),Foundry/API 只碰公司資料 + 自動化(貴通道只餵小東西)。

    公司用的「訂閱」是商用方案,不是員工個人帳號

    上面講「公司資料用訂閱也行」時,有個關鍵前提要釘清楚:處理公司的東西,要用「公司開的商用訂閱」(Team / Enterprise),不是員工個人的消費級 Pro / Max。這跟資料機不機密是兩道分開的閘——就算沒有機敏問題,帳戶條款與治理仍是另一關。

    帳戶 處理公司(非機敏)事 為什麼
    員工個人 Pro / Max(消費級) ⚠️ 不建議 消費級條款,資料預設可能被拿去訓練(除非手動關);無 DPA;公司無管控/稽核;工作綁個人帳號,人離職就失去
    公司開的 Team / Enterprise ✅ 可以 商用條款、不訓練、有 DPA、admin 管控、帳號歸公司
    公司 API / Azure Foundry ✅ 可以 商用條款、可自動化;Foundry 還能留 Azure 邊界

    一句話:非機敏不代表可以走消費級條款。公司的東西用公司商用帳戶,別躺在某個員工的個人訂閱裡,否則訓練、稽核、離職交接、IP 歸屬全是漏洞。(消費級的確切訓練/保留條款 Anthropic 改過幾次,對外講死前建議查當下版本;但商用 vs 消費級的分野是穩的。)

    從零開發:原型用訂閱,串真資料才切 Foundry

    把上面的原理套到「從零開發一個東西」的生命週期,就是這篇最實用的一招。原型階段沒有任何公司資料,用訂閱快速迭代;等要串接真實公司資料,才切到 Foundry。但切換點不是「原型做完了」這種階段標籤,而是一個具體的資料事件:

    第一次「真公司資料 / 真 schema / 真憑證 / 真專有邏輯」要進 prompt 的那一刻——在這之前,全部留訂閱。

    換句話說,只要你餵進去的還是假資料 / mock / 通用結構,就算你在寫「串接用」的 code,也還能留在訂閱:

    階段 餵進去的是什麼 用哪個
    原型 / scaffolding 通用架構、mock 資料、假 schema 訂閱(快、便宜、高頻迭代)
    串接(打 fake schema / mock) 仍是假的,只是形狀對 還是訂閱
    串接(碰真 schema / 真資料) 真公司東西 Foundry(留 Azure 邊界)

    有一個判斷會決定你「切多早」:機密的是「值」還是「結構」?

    • 只有資料值機密、schema 是通用的 → 用假資料混合法,幾乎全程留訂閱,真值在自己這端換回去,Foundry 幾乎用不到。
    • schema / 業務邏輯本身就機密(欄位名洩漏商業設計)→ 一碰真結構就切 Foundry,切得比較早。

    三個實務提醒:(1) 原型從第一天就用合成 / mock 資料,別圖方便把真實樣本烤進原型——一旦烤進去,訂閱階段就不乾淨了。(2) 切換是一個真步驟:換後端 / 換 key / 換設定,切完跑個 smoke test 確認行為一致(不同後端 model 版本可能微差)。(3) 快取不跨帳戶,切過去第一次是冷的,正常。

    假資料混合法:真機敏值永遠不出公司

    當產出真的要碰機敏值,用「假資料 → 產出 → 換回真資料」三步,讓你既能用最強的雲端模型產出,真機敏值又完全不離開公司:

    1. 在自己這端,把機敏欄位換成假資料 / 佔位符(masked)。
    2. 把「假資料版」丟給雲端 LLM,產出結構、內容、排版、分析框架。
    3. 在自己這端把真資料 find-replace 換回佔位符。

    讓這招順的關鍵是佔位符要一致、可一鍵全域取代——用穩定命名如 [公司名]、{{2025_範疇一排放量}},不要散落同義變體;需要假數字時標明是佔位值,別混入像真的數字。程式碼也適用:含活憑證(API key、DB 密碼、內部 endpoint)的檔案一律先抽掉再送,那是另一種洩漏面,跟在不在 Azure 無關。

    Part 1 一句話:資料先過機密分類,再決定通道;原型用訂閱、串真資料才切 Foundry、機敏走假資料混合或本地。把通道分對,比省 token 重要得多。

    Part 2|底層功夫:進了通道之後怎麼省 token、保持聰明

    通道分對之後,才輪到「在通道裡怎麼用得省又聰明」。這部分是底層功夫——對訂閱省的是「使用額度」,對 API/Foundry 省的是「真金白銀」,而且省 token 不只省錢,還能讓模型保持在最聰明的狀態。

    Context 是乘數:為什麼長對話又貴又笨

    Context(對話視窗)不是只算一次,而是每一輪都重算一次。我讀進一個 2000 行的檔,那 2000 行接下來每一輪對話都重新帶著計費。所以「在對話早期讀一個大檔」會污染後面整段對話的成本。

    更關鍵的是:長 context 不只貴,還會讓模型變笨。Chroma 對 18 個前沿模型(含 Claude Opus 4、GPT-4.1、Gemini 2.5)的實測顯示,每一個都隨輸入變長而退化——即使「需要的資訊 100% 在 context 裡」,準確率仍隨長度掉 13.9% 到 85%。這叫 context rot。所以省 token 同時是讓模型保持聰明。另外兩個失效模式:Lost in the middle(關鍵埋中段準確率掉 30%+,重要指令放開頭、當前問題放最後)、context poisoning(混進一個幻覺會被當前提複製,該截斷到污染點之前重啟)。

    三個動作:繼續、compact、clear 怎麼選

    動作 對之前對話做了什麼 能否接著聊同一件事
    繼續聊 全部逐字帶著 能,但越疊越大、越慢、越貴、越笨
    /compact 壓縮 換成一份摘要(有損,細節掉、重點留) 能,thread 不斷
    /clear 清除 全部丟掉(只剩 CLAUDE.md、auto memory 重載) 不能,這次記憶歸零

    原則:同一件事還要繼續且馬上繼續,用 compact;要停一陣、換事、或 context 已經很肥,先寫筆記再 clear。

    5 層記憶模型:Note 與 Brain 是兩條垂直的軸

    層 存什麼 活多久 / 何時載入
    Context 對話視窗 這次對話的一切 clear 就沒;每輪都在、每輪算錢
    Note 接手筆記 做到哪、下一步 任務做完即丟;叫它讀才讀
    MEMORY.md 你是誰、偏好、專案狀態 跨所有對話;每次開對話自動載
    Brain 踩過的坑 + 領域知識 永久跨專案;宣告 Domain Brain 才載
    Skill 正確做法的模板 永久;用到才呼叫

    最容易混淆的是 Note 跟 Brain,它們是兩條互相垂直的軸:Note 答「這次做到哪」(短期、綁任務、會過期);Brain 答「這類事怎麼做才不踩坑」(永久、跨專案)。clear 時 Note 把工作進度帶過去、Brain 把教訓帶過去——不是二選一,兩個都寫但寫不同東西,一個搬狀態、一個搬智慧。

    Context × Loop:乘數效應在迴圈裡會放大

    用 /loop 或排程反覆跑時,單輪成本是「context 大小 × 1」,帶著肥大 context 的迴圈是「context 大小 × 迭代次數」。所以每一輪開始前把 context 收乾淨,比一路累積更省也更準:每次迭代讀回精簡狀態檔(Note)→ 做這一輪 → 寫回狀態檔 → 收掉工作 context。狀態活在檔案裡,活躍 context 保持小而新鮮,這就是 long-running agent 能跑幾十輪不退化的關鍵。

    ccbot 是 UI 工具,不是 context 容器

    ccbot 這種「review → triage → 逐條修」一次幾十條 finding 的流程,最容易把上面所有原理一次踩雷。它應該被當成一個「UI 工具」——讓你逐條決策的介面——而不是用來長壓 context 的容器。心法:一個 finding(或一個 cycle)就是一個任務邊界,分批做、批次之間 clear,絕不一個對話硬幹幾十條。到約 100K token 時 context rot 發作,後面越判越糊;分批 clear 反而讓每條都用最乾淨的腦判,還更省 token。每條判完把「決定→存檔、教訓→Brain、進度→Note」三件事歸位,再開乾淨 context 做下一條。

    API / Foundry 端怎麼算成本(含程式範例)

    走 API / Foundry 時 token 直接是帳單,值得認真算。先講怎麼量——不要用 tiktoken(那是 OpenAI 的 tokenizer,對 Claude 會低估 15–20%)。用官方 count_tokens:

    from anthropic import Anthropic

client = Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("CLAUDE.md").read()}],
)
print(resp.input_tokens)

    成本公式:(input ÷ 1,000,000 × input 單價) + (output ÷ 1,000,000 × output 單價)。以 Opus 4.8($5 / $25)、50,000 input + 2,000 output 為例:input $0.25 + output $0.05 ≈ $0.30/次。加上 prompt caching(同一大前綴重複用):讀取只要基礎 input 價約 0.1 倍,寫入 1.25 倍(5 分鐘)或 2 倍(1 小時)。同樣 50K 前綴重複 10 次:不快取 $2.50,有快取 ≈ $0.54,省約 78%。

    response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    system=[{
        "type": "text",
        "text": LARGE_STABLE_CONTEXT,        # 穩定的大前綴
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": user_question}],  # 變動內容放後面
)
print(response.usage.cache_read_input_tokens)   # 驗證命中;一直是 0 = 前綴被污染

    快取是前綴完全比對,差一個字元就全 miss——常見元兇:datetime.now()、UUID、沒排序的 json.dumps()、或工具清單變動(工具一改整個快取全滅)。非即時的批量工作可走 Batches API,直接半價。

    各模型定價與快取門檻(官方數字)

    模型 Input $/1M Output $/1M Context 適合的活
    Fable 5 $10 $50 1M 最難的長程推理 / agentic
    Opus 4.8 $5 $25 1M 架構決策、複雜推理、跨檔案邏輯
    Sonnet 4.6 $3 $15 1M CRUD、API 對接、測試、文件
    Haiku 4.5 $1 $5 200K 檔案掃描、目錄盤點、簡單搜尋

    「最低可快取前綴」門檻各模型不同,而且不按貴賤排——這點最反直覺:

    模型 最低可快取前綴
    Opus 4.8 / Haiku 4.5 4,096 tokens
    Sonnet 4.6 / Fable 5 2,048 tokens

    具體後果——同樣一段 3,000 token 的前綴,在 Sonnet 4.6 與 Fable 5(門檻 2,048)快取得起來,在 Opus 4.8 與 Haiku 4.5(門檻 4,096)卻會靜默不快取,你不會收到錯誤,只會發現帳單沒省到。所以用 Haiku 做大量小請求時,若前綴不到 4,096,拿不到任何 cache 折扣。門檻不按貴賤排,別憑感覺假設;不同模型 tokenizer 也不同,跨模型估成本一定要用該模型自己的 count_tokens 重算。

    省過頭反而害事:三個要避免的過度優化

    1. 壓縮砍太狠:摘要寧可先求高 recall(多留)再慢慢收。一開始壓很乾,會砍掉日後才變關鍵的細節,逼出更多來回反而更貴。
    2. 為省而硬拆多輪:研究顯示同一 prompt 拆成多輪累積,品質掉 39%(context clash)。該一次講清的別硬切。
    3. 濫用子代理:多代理約用 15 倍 token。廣度研究、檔案掃描很划算;緊耦合、要共享上下文的事用子代理反而又貴又糊。判準:任務價值 > token 成本才划算。

    一句話心法

    先分流,再省 token。哪種工作走哪個通道才是大局:公開/通用走訂閱、公司資料走 Foundry(留 Azure 邊界)、機敏走假資料混合或本地;從零開發時原型用訂閱、第一次碰真公司資料才切 Foundry——切換點是資料事件,不是階段名。通道分對之後,底層才講省 token:context 是每輪重算的乘數、長 context 又貴又笨,同事續用 compact、換事用 clear、怕忘的寫進檔案,API 端認真做快取並按模型選對 tier。把通道分對的價值,遠大於在單一通道裡省那幾個 token。