【2026 最新】DeepSeek API 成本控制：Cron 離峰排程、Cache Hit 監控與超價自動切模型

DeepSeek API 成本控制，從 2026 年 8 月 17 日台北時間零時起，不能只靠「少用一點 token」。想像你的 Agent 每天早上整理 300 份文件：內容不急，卻剛好在高價時段啟動；前綴明明重複，Cache Hit 掉了也沒人知道；某次工具失敗後連續重試，直到月底才從帳單看見異常。真正要控制的不是一次 prompt，而是整條工作流。

這不是紙上問題。截至 2026 年 8 月 14 日，8 月 13 日的 Hacker News 討論已有 125 points、50 comments；同日 r/DeepSeek 討論直接追問：誰會把 workload 搬到離峰，又該切去哪個模型？抱怨漲價很容易，讓系統自己避開高價時段才是可重複的解法。

這篇專為第一次做 Agent 成本工程的讀者寫。你不需要先懂排程系統；我會從時區換算、單次成本公式開始，帶你把 Cron、queue、Cache Hit 遙測、fallback model、kill switch 與即時告警串成一套能上線的最小版本。

先說結論：Agent 成本護欄＝時段閘門 × 真實 usage × 預算斷路器

🐳 記憶把手：Agent 成本護欄＝時段閘門 × 真實 usage × 預算斷路器。
時段閘門決定「現在跑不跑」；真實 usage 回答「這次到底花多少」；預算斷路器負責「超價時降級、暫停與通知」。少任何一個，帳單仍可能失控。

• 台北尖峰：09:00–12:00、14:00–18:00；其他時段為離峰。
• 生效瞬間：官方寫的是 2026/8/16 16:00 UTC，換成台北是 8/17 00:00。
• 成本三塊：Cache Hit input、Cache Miss input、output 必須分開乘上各自單價。
• 排程原則：只延後可延後的批次工作；客服回覆、告警處理與有 deadline 的工作不能硬塞進離峰。
• 護欄順序：先查 kill switch，再看時段與預算，接著選 primary／fallback，最後把每一個模型呼叫都寫進 ledger。

DeepSeek API 成本控制第一步：把 UTC 尖峰換成台北時間

DeepSeek 在 官方價格頁列出兩段尖峰：01:00–04:00 UTC、06:00–10:00 UTC。台北全年使用 UTC+8，因此分別是 09:00–12:00、14:00–18:00；離峰則是 00:00–09:00、12:00–14:00、18:00–24:00。最長的低價窗口是傍晚 18:00 到隔天 09:00，很適合夜間報表、索引、評測與批次摘要。

還有一個最容易寫錯的日期：新價格在 2026 年 8 月 16 日 16:00 UTC 生效，台北已經是 8 月 17 日 00:00。程式應保存 UTC aware datetime，再在介面顯示本地時間；不要把「UTC 日期」直接抄成使用者看到的本地日期。

截至 2026 年 8 月 14 日，官方頁面只寫整點區間，沒有定義端點是否包含，也沒有說長請求跨過邊界時按開始、結束或其他時點計價。因此本文把區間視為半開區間只是排程慣例，worker 會把切換點前後 5 分鐘當成高價安全帶。實務上，讓批次工作在 12:05 或 18:05 後再送，比爭論 12:00:00 的一秒屬於哪一邊更划算。

先把任務分成三種，不要全部延後

• 可延後：隔日報表、文件索引、離線評測、批次翻譯、非即時資料清理。放進 queue，設定 delayable=true 與 deadline。
• 不可延後：使用者正在等待的聊天、資安告警、交易前檢查、會阻塞其他服務的工作。即使在尖峰也要跑，但可套用預算與 fallback。
• 有期限：本來可延後，但距 deadline 只剩 15 分鐘。worker 應讓 deadline 優先，並在高價時段選成本可接受的模型。

DeepSeek 新費率怎麼算？先拆成 Hit、Miss、Output

截至 2026 年 8 月 14 日，官方同時列出切換前費率與 8 月 16 日 16:00 UTC 後的新費率。新制中，同一模型的離峰三種 token 單價都剛好是尖峰的一半。Flash 與 Pro 的價差則不同，因此「等離峰」和「切 Flash」是兩個可分開使用的旋鈕。

目前 Quick Start把 deepseek-v4-flash對應到 V4-Flash-0731、deepseek-v4-pro對應到 V4-Pro-0813。官方 4 月 24 日更新曾把舊名稱 deepseek-chat、deepseek-reasoner的停止日期排在 7 月 24 日；8 月 14 日的現行教學與模型表只列兩個 V4 ID，所以本文程式碼不再沿用舊名稱。

公式只有一行：

單次成本 =
  Cache Hit tokens  × Hit 單價
+ Cache Miss tokens × Miss 單價
+ Completion tokens × Output 單價
以上合計再除以 1,000,000

把圖中的 Flash 離峰算式攤開：180,000×0.007/1M = 0.00126、20,000×0.22/1M = 0.0044、10,000×0.66/1M = 0.0066，合計 US$0.01226。尖峰三個單價全數加倍，成本就變成 US$0.02452。

注意 output 可能才是最大塊。Cache Hit rate 很漂亮，不代表整個任務一定便宜；如果 Agent 思考太久、工具迴圈沒有上限，output 與重試仍會把省下來的 input 吃掉。這也是為什麼要看 cost-per-completed-task，而不是只盯 Cache Hit 百分比。

Cache Hit 監控：別猜，直接讀 DeepSeek usage

DeepSeek 的 Context Caching 文件說明，硬碟快取預設啟用；後續請求只有完整重用已持久化的 prefix unit，對應部分才會命中。快取建立需要時間，而且是 best effort：兩個有共同前綴的早期請求可能都 miss，系統辨識並保存共同前綴後，第三個請求才開始 hit。

Chat Completions 的 官方 schema提供三個成本欄位：prompt_cache_hit_tokens、prompt_cache_miss_tokens、completion_tokens；並定義 prompt_tokens = hit + miss。reasoning_tokens是 completion 的細分，不能再加一次，否則會重複計費。

python -m pip install -U openai
read -s DEEPSEEK_API_KEY
export DEEPSEEK_API_KEY

python - <<'PY'
import json, os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
    max_retries=0,  # retry 交給 queue，避免兩層重試疊加
)

r = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "把輸入整理成三點摘要。"},
        {"role": "user", "content": "你的批次文件內容"},
    ],
    stream=False,
)

u = r.usage.model_dump()
hit = u.get("prompt_cache_hit_tokens")
miss = u.get("prompt_cache_miss_tokens")
if hit is None or miss is None or hit + miss != u["prompt_tokens"]:
    raise RuntimeError("usage schema drift：先暫停高成本工作並告警")

row = {
    "response_id": r.id,
    "model": r.model,
    "hit": hit,
    "miss": miss,
    "output": u["completion_tokens"],
}
print(json.dumps(row, ensure_ascii=False))
PY

範例刻意使用 non-streaming，讓完整 usage 一次出現。如果改成 streaming，官方要求設定 stream_options.include_usage=true，並讀完 [DONE] 前最後一個 JSON usage chunk。官方 schema 把 cache 欄位列為 required，但頁面上的舊範例仍有省略欄位的回應；因此缺欄位不能默默記成「0% 命中」，應先觸發 schema-drift 告警，成本則暫用 all-miss 做保守估算。

Cache Hit rate 要用 token 加權

token-weighted cache hit rate =
  SUM(hit_tokens) / SUM(hit_tokens + miss_tokens)

cost per completed task =
  期間內所有 API call 成本 / completed job 數

不要把每個 request 的百分比直接平均：100-token 小請求和 200K-token 大請求不該有相同權重。第二個公式的分子也要包含失敗、重試與 fallback 的成本；只有這樣，才是在問「完成一件工作真正花多少錢」。想先補齊模型、工具、loop、memory 與 stop condition，可搭配 AI Agent Harness 心智模型。

Cron／Queue 實作：Cron 只喚醒，worker 才決定要不要跑

最穩的分工不是寫兩張「台北尖峰 Cron 表」，而是讓 Cron 每 5 分鐘喚醒一次 worker；worker 用 UTC aware datetime 讀價格版本、尖離峰、deadline 與預算。這樣主機設成 UTC、台北或其他時區，都不會改變費率判斷。

# crontab -e
*/5 * * * * /opt/deepseek-agent/.venv/bin/python /opt/deepseek-agent/worker.py --drain >> /var/log/deepseek-agent.log 2>&1

Queue 裡每個 job 至少要有 task_id、delayable、deadline_at、expected_tokens、max_task_usd 與 allow_fallback。Cron 只說「起床看一下」；能不能跑，永遠由 job 的資料決定。

{
  "task_id": "nightly-index-20260817",
  "delayable": true,
  "deadline_at": "2026-08-17T22:00:00Z",
  "expected_tokens": {"hit": 180000, "miss": 20000, "output": 10000},
  "max_task_usd": 0.02,
  "allow_fallback": true
}

下面是費率判斷核心。它保留生效前價格；每日尖離峰邊界與 8 月 16 日 16:00 UTC 的一次性生效點，前後 5 分鐘都用新制 peak 成本估算。這不是猜 DeepSeek 的內部帳單規則，而是讓自己的 scheduler fail closed。

from datetime import datetime, timedelta, timezone

EFFECTIVE_AT = datetime(2026, 8, 16, 16, 0, tzinfo=timezone.utc)
OLD = {
  "deepseek-v4-flash": {"hit": .0028, "miss": .14, "output": .28},
  "deepseek-v4-pro":   {"hit": .003625, "miss": .435, "output": .87},
}
NEW = {
  "deepseek-v4-flash": {
    "off_peak": {"hit": .007, "miss": .22, "output": .66},
    "peak":     {"hit": .014, "miss": .44, "output": 1.32},
  },
  "deepseek-v4-pro": {
    "off_peak": {"hit": .022, "miss": .66, "output": 1.98},
    "peak":     {"hit": .044, "miss": 1.32, "output": 3.96},
  },
}

def band(now_utc):
    if now_utc.tzinfo is None:
        raise ValueError("now_utc 必須包含時區")
    now_utc = now_utc.astimezone(timezone.utc)
    if abs((now_utc - EFFECTIVE_AT).total_seconds()) <= 5 * 60:
        return "boundary_buffer"
    if now_utc < EFFECTIVE_AT:
        return "legacy"
    minute = now_utc.hour * 60 + now_utc.minute
    if any(abs(minute - x) <= 5 for x in (60, 240, 360, 600)):
        return "boundary_buffer"
    return "peak" if 60 <= minute < 240 or 360 <= minute < 600 else "off_peak"

def estimated_cost(model, tokens, now_utc):
    tier = band(now_utc)
    if tier == "legacy":
        price = OLD[model]
    else:
        bill_as = "peak" if tier in ("peak", "boundary_buffer") else "off_peak"
        price = NEW[model][bill_as]
    return sum(tokens[k] * price[k] for k in ("hit", "miss", "output")) / 1_000_000

正式 queue 還要補三件事：原子 claim／lease，避免兩個 worker 同時拿到同一 job；dead-letter queue，收容 400／422 這類程式或 payload 問題；把 idempotency key 寫進具唯一約束的去重表／outbox，或交給支援去重的下游 API 強制執行，才有機會避免 worker 在 API 成功後、寫入資料庫前崩潰，重啟又把同一個外部工具動作做一次。只產生一串 key 本身不會阻止重複。想看最小 Agent loop 如何分層，可接著讀 30 行 AI Agent Harness 實作。

超價自動切模型：預算、Fallback、Kill Switch 怎麼串

① 軟門檻：切到較低成本模型

先用同類任務最近 7 天的 p95 Hit／Miss／Output tokens 預估下一次成本。若 deepseek-v4-pro 超過 max_task_usd，且 job 明確允許 fallback，就再估一次 deepseek-v4-flash；Flash 通過才執行。Fallback 是品質與成本的交換，不應偷偷發生，所以 ledger 必須保存 requested_model、actual_model 與 fallback_reason。

② 硬門檻：兩個模型都超價就不呼叫

單 task 硬門檻、每日硬門檻或未知價格版本一旦觸發，就建立 kill.switch 檔案或把 AGENT_KILL_SWITCH=1。Worker 在 claim job 前、每次模型 turn 前，以及每個會改變外部狀態的 tool call 前都要檢查。檔案只適合單機，環境變數通常要重啟或 reload 才會更新；多機 worker 應把開關放在共用資料庫、Redis 或 feature-flag 服務。這個範例阻擋的是下一次呼叫；已送出的 in-flight request 仍可能完成，所以還要限制 max_tokens、max_turns 並預留安全額度。

③ 告警：只送成本欄位，不送 prompt

至少對 80%／100% 預算、fallback 啟用、Cache Hit 異常、單 call 超價、401／402、429／5xx、dead letter 與 kill switch 發出 webhook。告警 payload 只放 job ID、model、token、cost、HTTP code 與 timestamp；API key、prompt、工具結果與使用者資料不應進通知頻道。

def utc_deadline(raw):
    deadline = datetime.fromisoformat(raw.replace("Z", "+00:00"))
    if deadline.tzinfo is None:
        raise ValueError("deadline_at 必須包含時區")
    return deadline.astimezone(timezone.utc)

def route(job, now_utc, remaining_usd):
    if kill_switch_on():
        return "STOP", None
    tier = band(now_utc)  # 同時驗證並正規化時間語意
    now_utc = now_utc.astimezone(timezone.utc)
    deadline_is_close = now_utc >= utc_deadline(job["deadline_at"]) - timedelta(minutes=15)
    if (job["delayable"] and not deadline_is_close
            and tier in ("peak", "boundary_buffer")):
        return "DEFER", None

    for model in ("deepseek-v4-pro", "deepseek-v4-flash"):
        if model.endswith("flash") and not job["allow_fallback"]:
            break
        projected = estimated_cost(model, job["expected_tokens"], now_utc)
        if projected <= min(job["max_task_usd"], remaining_usd):
            return "RUN", model

    trip_kill_switch(reason="budget_block", task_id=job["task_id"])
    return "STOP", None

錯誤也要分類。DeepSeek 的 官方錯誤碼把 401 指向金鑰、402 指向餘額、429 指向請求過快，500／503 則建議稍後重試。Queue 應對 429／500／503 做有限次 exponential backoff＋jitter；400／422 進 dead letter；401／402 直接全域暫停並告警。SDK 若自動重試、queue 又重試，單次 attempt 可能被放大，因此上例把 max_retries=0，只留一個重試負責人。

完整算一次：一個完成任務為什麼不是最後一筆的成本

假設一個 Flash 離峰索引任務跑了三個模型 turn。第一筆讀文件：180K Hit、20K Miss、10K Output，US$0.01226；第二筆工具回傳後重試：190K Hit、10K Miss、8K Output，US$0.00881；第三筆驗收：40K Hit、5K Miss、2K Output，US$0.00270。

• 整個 task 成本：0.01226 + 0.00881 + 0.00270 = US$0.02377。
• Token-weighted Cache Hit：410K ÷ 445K = 92.13%。
• Cost per completed task：若期間內只有這一個 completed job，就是 US$0.02377；失敗 task 的花費仍要留在分子。

只記 final response 會把前兩筆成本藏掉；只看 Cache Hit 又會忽略 20K Output。這就是「真實 usage」在記憶公式裡的工作：每一個 model turn 先持久化，再允許下一個 tool side effect。想進一步比較快取命中和任務驗收的關係，可讀 Reasonix Cache Hit 99% 公開實測；若你仍在使用舊版 DeepSeek 接法，先看 DeepSeek V4 Flash API／Codex 教學。

DeepSeek API 成本控制的 6 個常見坑

坑 1：把 8 月 16 日直接當成台北生效日

官方時間是 UTC；台北的切換瞬間已經是 8 月 17 日 00:00。價格表要用帶時區的 timestamp 選版本。

坑 2：Cron 只在 18:00 跑，卻沒有 queue

服務重啟、job 延遲或一次塞進太多工作，都會破壞單一 Cron 的假設。Cron 負責喚醒，queue 負責 deadline、lease、retry 與 concurrency。

坑 3：把缺少 cache 欄位當成 0 Hit

那會把 schema drift 偽裝成效能退步。缺欄位要另記 cache_schema_ok=false、發告警，並用 all-miss 只做保守成本估算。

坑 4：把 reasoning tokens 再乘一次 output 價

reasoning_tokens已包含在 completion/output 的細分裡；再加一次會雙重計算。

坑 5：Fallback 沒有限次數與驗收

Pro → Flash 最多一次，並保存實際模型。若兩者都超價或任務不允許降級，就停止；不要在模型間反覆跳轉。

坑 6：只在任務開頭檢查 Kill Switch

Agent 可能跑十幾個 turn。每次模型呼叫與外部 side effect 前都要重查，並設定 max turns；否則關掉開關後，已 claim 的長任務還會繼續花錢。

上線順序：先 Shadow，再限額放量

1. Shadow 一週：不延後、不切模型，只記 Hit／Miss／Output、價格版本、tier、task 狀態與成本。
2. 校準預估：按 job type 算 p50／p95 tokens、cost-per-completed-task 與失敗成本。
3. 只開離峰排程：先挑真正 delayable 的工作，確認 deadline 沒被拖過。
4. 再開 soft fallback：只對通過 Flash 驗收的 job type 開啟，觀察完成率與人工返工。
5. 最後開 hard kill：先測 80% 告警、100% 暫停、人工恢復與 dead-letter 回放。

這個順序的重點是先有觀測，再改行為。若你還想從 prompt 長度、工具說明與 context 管理壓低整體 token，可接著看 AI Token 節省實戰；原理雖以 Claude 為例，穩定前綴、限制迴圈與按任務驗收的做法同樣適用。

DeepSeek API 成本控制 FAQ

1. 所有 Agent 工作都該排到離峰嗎？

不該。只延後有明確 delayable=true、且距 deadline 足夠遠的批次工作；互動、告警與阻塞性任務照常處理。

2. 台北的 8 月 16 日晚上已經是新價格嗎？

還不是。官方生效點 8/16 16:00 UTC，換成台北是 8/17 00:00。

3. Cache Hit 越高，任務一定越便宜嗎？

不一定。Hit 只降低部分 input 價格；Output、失敗重試與過長的 Agent loop 仍可能主導成本。

4. DeepSeek Cache 要手動開嗎？

不用另外啟用。目前官方文件說明硬碟快取預設開啟；你要做的是維持可重用的穩定前綴，並從 usage 量實際命中。

5. Cron 設在 18:05 就完成成本控制了嗎？

沒有。Cron 只負責喚醒；queue 還要處理 deadline、重試、併發、預算與 kill switch。

6. 超價時一定要從 Pro 切 Flash 嗎？

不一定。只有事先用相同驗收測過 Flash、且 job 允許 fallback 才切；否則停止並交給人工。

7. Kill switch 能追回已送出的那一筆嗎？

本文範例不能。它在下一次模型 turn 或 tool side effect 前擋住流程；因此仍要用 max tokens、max turns 與預算安全額限制單次超額幅度。

8. 預算門檻一開始該設多少？

先從資料決定。Shadow 期間按 job type 收集 p95 成本，再把 soft threshold 設在正常高位、hard threshold 設在可接受上限；沒有歷史資料時先用小額、少量 job 驗證。

給新手的 7 個重點

1. 台北尖峰是 09:00–12:00、14:00–18:00。
2. 台北新費率從 2026/8/17 00:00 開始。
3. 單次成本要拆 Hit、Miss、Output 三塊。
4. Cache Hit rate 用 token 加權，不平均 request 百分比。
5. Cron 喚醒 worker，queue 決定 defer／run。
6. Fallback 必須事先驗收、只切一次並記錄實際模型。
7. Kill switch 要在每個 model turn 與外部 side effect 前檢查。