自架跟雲端/商業方案的成本抉擇，關鍵在兩條成本曲線的交叉點。這兩條曲線的形狀根本不同：自架的成本成長得很慢（sublinear）——處理 1 個用戶跟 100 個用戶的基礎設施成本差異極小，只在規模拉大、維運人力上來時才逐步爬升；商業或雲端託管的成本隨規模線性上升——按事件量、用戶數、或主機數計費，業務成長直接乘上費用。小規模時自架的平坦曲線更低，某個規模之後商業的規模經濟勝出，交叉點就在兩條線相交的地方。

兩條曲線為什麼形狀不同

自架成本成長慢，是因為它的主要成本是一次性的建置與相對固定的維運，跟用量幾乎脫鉤（真正隨規模上升的是維運人力，不是機器）。一套自己跑的監控、資料處理，處理的事件多一個數量級，機器可能只需要多開一點，但架構、維護的成本不變。商業成本線性，是因為它的計量單位（事件、主機、席位）直接綁在業務成長上——用戶翻倍、事件翻倍，帳單就翻倍。這是計量模式跟業務規模綁定的結果，不是單價高低的問題。

交叉點的位置沒有硬數字，是經驗估算：使用者數少（約百人以下）時，自架的總成本（建置加維護加硬體）通常低於商業方案的年費；規模大（約千人以上）時，商業的規模經濟與省下的人力勝出。中間是一段灰色地帶，取決於功能需求與團隊能力。給幾個錨點感受量級——典型商業監控方案年費約數百美元起、按規模往上，不少方案有免費額度（如某些錯誤追蹤方案免費到每月數千個事件、某些分析方案免費到每月百萬級事件），小規模可以零成本起步。這些免費額度耗盡後轉按量付費，帳單就開始爬那條線性曲線。

交叉點不是一個點，是一段光譜

把選擇當成「自架」跟「用雲端」的二元，會錯過中間大片的漸進選項。真實的選擇是一道光譜，差別在「哪些層自己管、哪些交給平台」：完全用商業 SaaS（只管埋點、其餘全外包）、用 BaaS 加 serverless（自己寫邏輯、平台管伺服器與資料庫維運）、用 PaaS（跑自己的程式碼、平台管佈署與 TLS）、到完全自架（全部自己管）。從左到右，自己扛的越來越多、單位成本越來越低、但人力投入越來越大。

這道光譜讓「交叉點」變成「可漸進遷移的區間」。小規模時用商業方案的免費額度零成本起步、同時保留自訂的彈性；規模成長、成本爬升到某個點，再往光譜的自架端遷移。關鍵是遷移方向的成本不對稱——從自架換到商業容易（改個埋點端點就好）、從商業換回自架難（要從零建起整套收集、儲存、儀表板）。所以起步時選哪個位置，要把「將來往哪個方向遷」算進去。

不在帳單上的成本

自架的帳單很便宜，但它的主要成本不在帳單上——在人力。自架系統的功能上限等於團隊願意投入的工程量：基本的查詢自己寫幾行就有，但儀表板、告警、進階分析，每一個功能都是數週到數月的開發；規模大了之後，高可用、擴容、備份的維運又是持續的人力。這些是自架真正的成本，只比雲端帳單而忽略人力，會嚴重低估自架的代價——這跟 模組五 成本模型 講的「自建與託管人力差 3 到 10 倍」是同一件事。

商業方案的隱藏成本則在 lock-in 與合規。深度用了某個 vendor 的私有 schema 與功能，遷出的代價很高——這是前面說的方向不對稱。合規則可能把天平推向自架、且與規模無關：資料落地（data residency）的要求下，自架能完全控制資料位置，商業方案只有部分供應商提供特定區域、免費方案的區域選擇還可能受限。一個有嚴格資料落地要求的服務，可能不管規模多小都得自架。算自架划不划算，要把人力、lock-in、合規這三筆帳單外的成本一起算進去，才是真實的交叉點。

下一步路由