(🚧 OpenAI FT 成本數字有少算 input / output，我回家再算)

🔹 前言

回顧 LoRA 微調之路：

• Day23：介紹三大策略（RAG 增量、OpenAI FT、LoRA 自建）
• Day32：實作 LoRA 本地微調搭配工程調整方法達成 92% 相似度
• Day33：分享 N 次失敗的踩坑經驗（災難性遺忘、過擬合）

今天重新從 DevOps 角度切入，聊聊：如果真的要做微調模型，部署到生產環境可能有哪些考量？

📌 本文定位

💡 如果你的團隊有專業 ML 工程師，請諮詢他們的建議、共同調整本文方案。
本文內容為筆者主觀角度解讀，請依照實際環境斟酌採納文中所提之方案。

🔹 為什麼 SRE 要懂這些 ML 專業術語？

「在經歷 Day33 N 次失敗的微調實驗後，我發現：
Fine-tuning 的 Debug 過程，很像是在做 Root Cause Analysis。」

💡 共同本質：在不確定性中建立因果關係，透過實驗和觀察指標找出問題根源。

SRE 的核心能力之一：跨領域整合

SRE 平常的工作需要和 RD 們密切合作。

即便不是親手實踐程式碼的我們，如果不梳理業務邏輯，便無法制定可以正確反應系統的狀況的指標以及合適的告警機制。換到 LLMOps 的情境亦然，我們 不需要會訓練或是微調模型，但要能評估技術方案與排查線上問題，如果不嘗試了解這些 ML 術語，會增加排查問題時的 溝通成本 和 時間成本（MTTR，平均修復時間）。

三個工作上的實務場景（非常溫和順暢版）：

⚠️ 場景純屬虛構，如有雷同，純屬巧合，且請珍惜。

實務場景 1：用戶抱怨品質不佳，要思考解決方案

老闆：「我從後台看有大量用戶抱怨回答品質不佳、bot 亂回答、沒有解決問題還浪費時間！你們怎麼解決？」

ML 工程師：「我有先確認過這版模型，在測試集的相似度還有 90%，沒有退化。問題比較像是線上的檢索或 Prompt 出狀況。」

SRE：「我這邊也看到異常。更新知識庫後，檢索延遲從 200ms 拉到 500ms，而且有 15% 的查詢抓不到文件。」

Data Engineer：「我查一下新資料。」
 
[1 小時後]
Data Engineer：「發現問題：
1.新資料有 8% 格式異常（空欄位、特殊字元）
2.chunk 平均長度從 400 token → 280 token 
我先產出資料品質報告。」

ML 工程師：「看來是資料問題 + chunk 切法不合。我的方案： 優先順序 
1：調整 chunk size（500/80），預計召回率[註1]可恢復到 >90% 優先順序
2：如果還不行，測試 bge-large 替換 bge-base 
門檻：如果調完召回率還 <85%，建議做 Fine-tuning。」

SRE：「好，我這邊幫你準備 staging 環境做 A/B 測試，同時監控調整前後的延遲、QPS 和錯誤率。召回率的部分你那邊追蹤，我們週五一起看數據。如果需要添加更多 GPU 或調整 replica 數量，跟我說。」

老闆：「可是客訴率都提高到 20% 了，光靠這些修修補補真的夠嗎？」

ML 工程師：「如果 retriever 和 Prompt 都調過了，品質還回不來，那就可能要考慮 Fine-tuning。讓模型直接學我們新添加的資料，才有辦法更穩定。如果調完品質還回不到 85%，我建議做 Fine-tuning。」

老闆：「Fine-tuning 要花多少錢？」 

SRE：「（思考了一下 ROI）預估每月增加 1-3 千美金 GPU 費用，加上 1 個 ML 工程師專職維護。」 

老闆：「（皺眉）這麼貴？有沒有更省錢的做法？」

ML 工程師：「（思考）恩...，我們先把資料和檢索調好，如果召回率能到 85% 以上，就不需要 FT。根據過往數據，召回率每提升 10%，客訴率約降低 5-8%。 如果我們能把召回率從現在的 75% 拉到 85%，客訴率應該能降回 12-15%。

老闆：「下週三給我結果，如果真的非做不可，你們要準備完整的成本效益分析給我看。」 

ML 工程師：「了解，我週三前給你：
1.調整後的召回率數據 
2.是否需要 Fine-tuning 的評估報告」

SRE：「我同步準備 Fine-tuning 的部署方案和成本分析，以防萬一。」

[註1]召回率 (Recall) = 檢索到的相關文件數 / 所有應該被檢索到的相關文件總數，在所有正確答案中，找到了多少個？

SRE 的價值：用決策樹思考避免過度工程化和額外的維護成本，曲突徙薪，選最划算的方案。

這個場景的決策重點：

• ✅ 優先調整 RAG + Prompt（零成本）
• ⚠️ 設定決策門檻：品質 <85% 才考慮 FT
• 📊 思考成本分析（USD$1-3K/月 GPU 費用 + 人力）

實務場景 2：禮拜三到了！老闆要確認改善進度

老闆：「上次不是說要調整檢索和 chunk？現在結果怎樣？」

ML 工程師：「我這邊跑了 embedding 對比，換成 bge-large 確實好一點，召回率提升了 5%。另外做了 Prompt 微調，拒答準確率也提高了。staging 環境測試下來，品質達到 87%。」

QA：「我看了測試報告，功能測試都過了，但我想確認一下：你們 staging 測試的負載量是多少？」

ML 工程師：「大概 10 QPS，主要是驗證模型品質和準確度。」

QA：「10 QPS？但我們線上高峰是 500 QPS，這個負載差距有點大。高流量下的表現需要確認一下。」

SRE：「對，我也有這個疑慮。而且從系統指標來看，延遲壓回到 280ms，P95 latency 在 2.7 秒，單 pod 記憶體 2 GB，在正常負載下都還好。但 500 QPS 的情況我們還沒實測過。我建議這樣：我們先在 staging 環境做 250 QPS 壓測（約 50% 峰值），跑個 20 分鐘看看，觀察 P95、CPU、記憶體、還有外部服務的限流情況。穩住了再走灰度發布。」

ML 工程師：「我補充一下，幻覺率從 3% 增加到 3.5%，這是因為新的 embedding 模型更敏感，會匹配到一些相關性較弱的文件。當模型參考這些邊緣文件時，可能產生不夠準確的回答。不過 3.5% 還在我們設定的 5% 安全範圍內。在高流量下，這個指標可能會有變化，我會持續監控。」

QA：「所以灰度流程是怎樣？我需要知道驗收標準。」

SRE：「灰度流程我是這樣想的：第一天先給 10% 流量，跑 24 小時看看。如果穩定，再往上加到 30%、50%，最後才全量。回滾條件我設了三個：

- 第一個是延遲，P95 如果超過 3 秒，而且連續 15 分鐘都這樣，就回滾
- 第二個是錯誤率，5xx 或業務錯誤超過 0.5%，持續 10 分鐘以上，也回滾
- 第三個是品質，Zero-hit 超過 5%，或者關鍵意圖品質掉到 85% 以下，一樣回滾

這些條件超過就切回舊版。」

ML 工程師：「關鍵意圖品質這個我會持續監控，特別是客訴最多的幾個場景。」

QA：「好，那我這邊準備功能驗收的 checklist，確保核心流程在每個階段都能正常運作。」

老闆：「87%？上次你們不是說低於 85% 才考慮 Fine-tuning？現在看起來應該不用 Fine-tuning 了？」

ML 工程師：「87% 確實超過門檻了。我建議先上線觀察，如果關鍵意圖品質低於 85%，或者 48 小時內持續下滑，我們再考量是否正式執行 Fine-tuning 計畫。」

SRE：「同意。而且現在的方案幾乎不花錢，Fine-tuning 的話，我估的 3000 美金是用 OpenAI FT 的增量推理成本。如果改成自建 GPU，在 500 QPS 高峰下成本會更高。我會在報告裡把兩個方案分開估給您看。」

老闆：「好，那就照這個計畫上線，但我要看到每天的品質報告， 特別是客訴率的變化。如果品質持續下滑或客訴率沒降低，我們就來討論這個 Fine-tuning。下週給我完整報告，把兩種方案的成本都列進去，還有如果最後需要 FT，新版本多久可以上線。」

ML 工程師 & SRE & QA：「了解。」

SRE 的價值：在 ML 關注模型品質、QA 關注測試完整性的基礎上，補充生產環境的容量驗證（壓測）、部署策略（灰度流程）、風險控制（自動回滾條件）和成本分析，確保安全且經濟地上線。

這個場景的決策重點：

• ✅ 容量驗證：壓測 250 QPS（50% 峰值）
• ✅ 灰度流程：10% → 30% → 50% → 100%
• ⚠️ 三個回滾條件（P95、錯誤率、品質）

實務場景 3：突發事件！半夜被報警叫起來排查線上問題 🔥

🚨 告警觸發：幻覺率從 3% 飆到 8% (AM 2:00)

SRE（被手機吵醒，檢查監控）：「幻覺率飆到 8%，我先回滾到 v1.2.0。」

[執行回滾]

SRE（在 Slack）：@ml-team @data-team 「線上已恢復。昨晚 23:45 開始幻覺率飆升，有誰動過索引或資料？附件：[monitoring_dashboard_link]」

ML 工程師：「我們昨天上了 v1.2.1，把 chunk 從 600/100 overlap 改成 350/50，還加了一批新資料。」

SRE：「時間點一致，我在 staging 重現看看。@data-team 麻煩早上幫忙查昨天新添加的資料品質。」

早上會議（AM 10:00）

老闆：「昨天 incident 怎麼回事？」

SRE：「凌晨幻覺率飆到 8%，我在 3 分鐘內回滾到舊索引，線上恢復正常。異常發生在 index@v1.2.1 上線之後。」

Data Engineer：「我早上跑了 profiling，發現昨天入庫的新資料有問題： - 15% 空欄位 - 3.2% 重複樣本 - 平均 token 長度從 450 降到 280」

ML 工程師：「我們發現原因是新資料有格式問題，加上 chunk 調得太小，導致語意切太碎、召回率下降。
今天修復計畫：
1. 清理資料，加上 schema 驗證與空文本檢查
2. 重嵌有問題的資料並重建索引 [index@v1.2.1-hotfix]
3. 驗證關鍵意圖召回率 ≥85%」

SRE：「我的部分：

1. 對 [index@v1.2.1-hotfix] 做 250 QPS 壓測 + P95/CPU/記憶體檢查
2. 灰度 rollout：10% → 30% → 50% → 100%，回滾條件已設好
3. 撰寫 postmortem」

QA：「我會跑回歸測試，驗證核心問答流程。」

老闆：「好，但 bot 後台用戶抱怨沒有顯著提升，不太明白新資料的用途？？今天先上 hotfix ，這週五 sprint 雙週會要有報告和改進方案。」

會後對話

ML 工程師：「老闆那句話...我們是不是方向錯了？」

SRE：「有可能。我看了一下客戶問題分類，80% 是產品功能的問題，不是新資料所提到的關於產品外觀的問題。」

ML 工程師：「所以我們為了提升召回率加的這些跟產品外觀有關的新資料，可能用戶不太在乎這個？」

SRE：「不然下午跟 PM kick-off 會議，談談用戶真正的痛點是什麼？先確認需求優先級，不然之後老闆還是會問一樣問題。」

ML 工程師：「好，先把 hotfix 修好，再來整理改善方向。」

SRE 的價值：有系統化的應對流程（快速止血、找出根因、提出改進），同時將失誤轉化為系統性改進機會，避免事故演變成指責大會。

這個場景的決策重點：

• 🚨 3 分鐘內自動回滾
• 🔍 Root Cause：資料格式 + Chunk 設定
• 📝 Postmortem：系統性改進（Schema 驗證）

上面三個故事場景，展現了 SRE 在技術會議中的價值:

接下來，我們把這些「臨場決策」，整理成「可重複使用的框架和檢查清單」。

🔹 決策起點：要不要做 Fine-tuning？

Fine-tuning 不是 RAG 的替代方案，而是解決不同問題

常見決策誤區 ⚠️

技術特性對比

💡 詳細的技術實作差異請參考 Day23 - 讓 LLM 應用與時俱進：RAG 增量 × Fine-tuning 部署與治理指南

🔹 決策步驟一：成本評估

回到場景 1: 老闆問「Fine-tuning 要花多少錢？」 SRE 答「預估 1-3 千美金／月 GPU 費用 + 1 個 ML 工程師」 這個數字怎麼來的？我們來拆解。

💡 延伸閱讀：Day17 - LLM 部署策略選型：雲端 vs 本地 vs 混合架構（成本與隱私） 已詳細說明隱藏成本（電費、人力、維護），本章聚焦 Fine-tuning 方案差異。
小提醒：本文的數字都是用公開資料和經驗假設來估算，不同公司、不同雲端合約或硬體規格，實際成本可能差很多。別把這篇當成報價單，而是當作參考範例，幫助你思考決策方向。

三種方案比較

成本說明：

• 推理成本：基於 30M tokens/月的流量（與 Day17 一致的是「流量假設」，非單價）；Open AI FT 費用 gpt-4o-mini-2024-07-18 = $3 / 1M
• 維護成本：電費、機房、硬體折舊（不含人力）
• 人力成本：ML/DevOps 工程師年薪 $60–80k，此處以 $66k 為中位數換算 FTE
• 微調成本/次：若每月需重複進行，則需依頻率將單次成本攤入月費。
• 總成本：微調 + 推理 + 基礎設施維護成本 + 人力

成本試算（企業 FAQ Bot，30M tokens/月）

只算基礎設施成本（不含人力）

加上人力成本（完整 TCO）

成本包含：微調、推理、硬體折舊、電費、人力（Day 17 有完整拆解）
TCO：總體擁有成本，Total Cost of Ownership

Break-even（損益平衡點）快速計算

OpenAI FT vs 自建 GPU（只看基礎設施）

OpenAI FT 推理成本（變動）：
├─ GPT-4o mini FT: $3 / 1M tokens
└─ + 微調攤提：$25/月

自建 GPU 成本（固定）：
├─ 硬體攤提：$333/月
├─ 電費：$36/月
├─ 雜支：$0–100/月
└─ 總計：$369–469/月

Break-even（不含人力）：
($469 – $25) / $3 ≈ 148M tokens/月

⚠️ 請注意：
1. 若考慮雲端 GPU，Break-even 約落在 325M–1,000M tokens/月（依租金高低而變）。
2. 此計算未包含人力成本。實際上自建 GPU 需要 0.6–0.8 FTE 維運人力，若加入人力成本後，break-even 點會大幅提高至 > 1.2B tokens/月。

加上人力成本後

OpenAI FT：$115/月（無需專職）
自建 GPU：$3,669–4,869/月（含 0.6–0.8 FTE）

Break-even（含人力）：
最低成本：($3,669 - $25) / $3 ≈ 1,215M tokens/月
最高成本：($4,869 - $25) / $3 ≈ 1,615M tokens/月

結論：
自建 GPU 在 1.2–1.6B tokens/月 之間達到 break-even。
對大多數企業而言，除非月流量 >1.5B tokens，否則 OpenAI FT 更划算。

快速決策參考

⚠️ 此表僅供快速判斷，實際仍需依合約、人力與法規評估」

例外情況（無論流量都要自建）：

• 🔒 法規禁止資料出境（GDPR、個資法）
• ⚡ SLA 要求 <100ms 延遲
• 🎯 需要高度客製化模型
• 👥 已有專職 SRE/MLOps 團隊（理想情況下可大幅降低邊際人力成本，Break-even 降至 150M）

🔹 決策步驟二：技術選型框架

💡 不是為做而做，先驗證需求再選方案。

真實世界必須要依照需求決定要採用哪種方案

說明：

• 流量門檻: 參考前面 break-even 分析（含人力約 1.2–1.6B tokens/月）
• 治理成熟度: 包含 Eval、灰度、回滾、成本監控（見下方檢查清單）

治理成熟度檢查清單

在選擇自建 Fine-tuning 系統前，可以考慮用此清單評估團隊準備度

⚠️ 雲端 GPU 僅解決硬體維運問題，但治理清單要求完全相同。若必備項未達成，即使租 GPU 成本高昂，風險依然存在。

實務分配

混合部署架構（僅供參考，需依照實際自身情境討論）

實務部署流程參考（不同企業比例會有落差，這裡提供的是常見分佈，整理自參考文章）

💡 路由實作以及現成工具參考詳見：Day24 - LLM 應用分流：用任務分類做到省錢可靠

🔹 決策步驟三：監控與風險控制

💡 回到場景 2: SRE 設定了三個自動回滾條件

• P95 延遲 >3s（持續 15 分鐘）
• 錯誤率 >0.5%（持續 10 分鐘）
• 品質下降到 <85%
  雖然情境裡的 SRE 最後不需要真的採用 Fine-tuning，但是如果真的要做的話，這些閾值怎麼設？

監控指標建議

實作參考 Day19 - LLM 可觀測性實戰：監控延遲、Token 與成本(含工具選型)

典型場景範例（參考值，需根據實際環境調整）：

💡 閾值設定原則（參考 Google SRE Book: SLO）：

1. 先跑 1-2 週收集 baseline（真實流量的正常水平）
2. 根據業務需求設定 目標值（如：P95 延遲 <500ms）
3. 告警閾值 = 目標值 × 容忍係數（如：目標 × 1.2）
4. 持續調整：每月檢視誤報率，調整閾值

💡 監控實作細節參考：

• Day19 - LLM 可觀測性實戰：監控延遲、Token 與成本(含工具選型)
• Day20 - LLM 回應品質監控：幻覺偵測與三層防護實作

風險評估與應對

💡 回到場景 3: 凌晨幻覺率從 3% 飆到 8%，這就是「資料 Drift」風險。如何預防以及快速應對？

風險矩陣與優先級

🔹 小結

從實作（Day 32）→ 踩坑（Day 33）→ 部署評估（Day 34），完整涵蓋 LoRA 微調的完整生命週期。

SRE 的核心價值：

• 💰 成本守門：用 Break-even 分析避免過度工程化
• 🛡️ 風險控制：5 階段灰度 / 小步上版
• 🚒 快速止血：快速回滾 + RCA 流程

上線前必檢項目：

1. ✅ 成本分析（微調 + 推理 + 維護）
2. ✅ 監控指標（品質、效能、成本、可用性）
3. ✅ 回滾機制（自動化 + 閾值設定）
4. ✅ 風險評估（風險 + 優先級矩陣）

SRE 的價值：不只是「把服務跑起來」，而是在技術可行性與商業價值間找到平衡點。企業 QA Bot 並不一定要做 Fine-tuning，先用現成工具驗證想法，確認必要性後再投資才是穩健做法。

「工具是手段，解決問題才是目的。」

📚 參考資料 / 延伸閱讀

• A Practical Guide to Maintaining Machine Learning in Production - eugeneyan
• Hidden Technical Debt in Machine Learning Systems (Sculley et al., 2015)
• The Real Cost of Fine-Tuning LLMs: What You Need to Know - Angel Poghosyan
• OpenAI - Fine-tuning 價目表
• AWS SageMaker Pricing
• RunPod Pricing
• Lambda Labs GPU Cloud

決策框架與實證研究

• AWS - Model customization, RAG, or both: A case study with Amazon Nova 可以參考數據的部分，AWS Generative AI Innovation Center 的實驗顯示，結合 RAG 和 Fine-tuning 可以將品質提升 83%，相比單獨使用任一方法（約 30% 提升）效果顯著。
• Monte Carlo Data Blog - Fine-tuning vs RAG: How To Choose The Right Method - Lindsay MacDonald RAG vs FT 以及更多需要考慮的層面
• Fine-Tuning vs RAG: A Comprehensive Guide for Better LLMs - Zach Schwartz 混合策略常見做法是：以 FT 打底品牌語氣與任務套路，再用 RAG 植入即時事實，取得一致性與時效性的平衡。

論文

• TensorShield: Safeguarding On-Device Inference by Shielding Critical DNN Tensors with TEE - Tong Sun 等 微調後模型安全防護，防止反推
• Fine-Tuning vs. Retrieval Augmented Generation for Less Popular Knowledge -Heydar Soudani 等 這篇論文實驗指出：在處理低頻知識時，RAG的效果遠超Fine-tuning， 且成本更低、更新更快。只有在RAG無法滿足品質要求時，才需要考慮搭配Fine-tuning使用。