微調的成本回收分析：什麼時候真的省到錢

一次性成本

• 資料標註：筆數 × 單筆標註成本（含審核）。通常是最大的一項。
• 工程人力：資料處理、訓練、評測、整合，以人週計。
• 算力：訓練與調參的 GPU 時數，含失敗的實驗。
• 評測建置：評測集標註與評測工具開發。

持續成本

• 推論：自架的 GPU 常駐費用（不是按呼叫計費，是按小時）。
• 維運：監控、值班、故障處理。
• 持續微調：每季的資料回收、標註與重訓。
• 版本管理：多環境部署與回滾機制的維護。

試算模型

# 現況：使用商業 API
api_monthly = calls_per_month * (in_tok * P_IN + out_tok * P_OUT) / 1e6

# 微調後：自架
gpu_monthly  = gpu_count * gpu_hourly * 730 * redundancy   # 備援係數 1.5~2
ops_monthly  = ops_hours_per_month * hourly_rate
retrain_monthly = retrain_cost_per_quarter / 3
self_monthly = gpu_monthly + ops_monthly + retrain_monthly

monthly_saving = api_monthly - self_monthly
breakeven_months = one_time_cost / monthly_saving if monthly_saving > 0 else None

三個常見的算錯

1. GPU 按呼叫量估算：自架的 GPU 是常駐計費，離峰時段一樣要付錢。低利用率會讓自架非常不划算。
2. 忽略備援：單機部署不能上線。至少要乘以 1.5。
3. 忽略持續微調：模型會過時，每季重訓的成本要攤進來。

不只看錢的三個理由

有些情況即使不划算也應該做：資料不得出境的法遵要求、需要極低延遲、或需要模型行為完全可控不受上游改版影響。這些是策略價值，應該在決策文件中明確寫出來，而不是硬拗成成本效益。

建議的決策順序

1. 先算 api_monthly。若每月低於某個門檻（例如工程師一週的成本），直接不考慮微調。
2. 再確認利用率。若尖峰離峰差距超過五倍，自架的閒置成本會很高。
3. 最後才比較品質提升是否值得。