Databricks 說得對：模型服務應該自適應，不該靠人工調參

生產環境的模型服務應該依模型與流量自動調整，而不是靠工程師手動調參。

我站在 Databricks 這邊：模型服務的未來是自適應基礎設施，不是團隊長期盯著 replicas、concurrency 和 autoscaling 旋鈕反覆微調。

Databricks 把這件事講得很直接。它的 Custom Model Serving 宣稱可同時支援從 2 MB 的 scikit-learn 分類器到 70B 微調 LLM，涵蓋單 CPU 核心到 8 張 GPU 的部署形態，並能承受 30 萬以上 QPS、p99 額外延遲低於 10ms，對離開自管堆疊的客戶，基礎設施成本最高可降 90%。這不是小修小補，而是把 serving 從內部負擔變成產品能力。

第一個論點：手動調參無法跟上模型多樣性

問題的核心很簡單：不同模型的行為完全不同。排序模型、embedding 模型、反詐欺模型、LLM 對算力、批次處理與並發的需求都不一樣。Databricks 直接指出，xgboost 這類 CPU-heavy 模型可能每核心只能處理 1 個請求，而 agent 類模型可達每核心數百請求，微調過的 13B LLM 則明顯受益於 batching。單一 serving 模板根本不可能同時適配這些場景。

傳統平台把複雜度丟回客戶端，要求團隊自己調整 replica 數、每 replica concurrency、autoscaling 閾值。這不是抽象化，而是把工作延後。每多一個模型，或流量型態一變，就要重新 profile、重新試錯。結果不是更靈活，而是上線延遲、配置脆弱，最後養出一支只負責救火的 serving 團隊。

第二個論點：生產流量要求系統自動判斷，而不是人盯人

Databricks 的架構方向是對的：request-based 與 resource-based 訊號要一起看。前者能快速反應突發流量，後者能告訴系統 CPU 或 GPU 是否真的已經飽和。單看其中一個都不夠。流量暴增時，利用率指標往往還沒追上；只看利用率，又可能在 p99 latency 爆掉之前還誤以為系統很健康。

這在真實業務裡很常見。一次促銷開始，反詐欺 endpoint 可能在幾秒內暴增 10 倍；某個區域功能上線後，白天尖峰、夜間趨近閒置。這種流量不是靠人工巡檢就能穩定處理。能在 runtime 學會模型上限，自動調整 concurrency 與 replica 的 serving 層，才是同時守住延遲、擴展性與成本的唯一務實做法。

第三個論點：真正的收益是組織效率，不只是技術效率

Databricks 把這件事稱為移除「ML Stack Tax」，這個說法很準。這筆稅不只是浪費的算力，還包括每個模型上線後衍生出的會議、儀表板、調參儀式與事故處理。當 serving 是手動的，組織很快就會把目標從「快速交付價值」改成「先撐住不要壞」。

最有說服力的證據，是很多團隊明明已在 dev 驗證模型，卻因為基礎設施還要再調一次而拖了好幾週才進 production。這不是 ops 細節，而是商業成本。如果 serving 平台能自動匹配 runtime 與模型，自動適應流量，並預設提供可觀測性，工程團隊就能把時間花在更好的模型與產品決策上，而不是維持一個脆弱的 serving 堆疊。

反方可能怎麼說

最強的反對意見是：通用自動化會遮蔽重要取捨。有些團隊跑的是極度敏感的工作負載，對延遲、記憶體壓力或成本上限有明確要求，這些情況需要明確控制。黑盒 autoscaler 會讓系統看起來不夠可預測，尤其當同一平台同時服務小型傳統模型與大型 GPU 模型時，操作員自然會想要更多旋鈕，因為旋鈕代表責任邊界。

另一個合理擔憂是平台依賴。若 runtime 選擇或 scaling policy 判斷失準，客戶可能失去針對自身邊緣案例做極致優化的能力。對有深厚 infra 能力的團隊來說，這種控制權流失看起來就是成本。

但這個反對意見並沒有推翻 Databricks 的論點，只是劃出邊界：平台必須在預設路徑上強勢，在訊號上透明。Databricks 的說法之所以更強，不是因為它承諾魔法，而是因為它主張系統在 runtime 學習每個模型的極限，結合流量與資源訊號，並保持請求路徑短且隔離。這比要求每個客戶重新踩一次同樣的調參坑，更像一份可交付的工程契約。

你能做什麼

如果你是工程師，別再把 serving 當成一次性部署任務，而要把它當成產品表面來管理，明確定義延遲、成本與可觀測性目標；如果你是 PM 或創辦人，優先選擇能把調參工作移出關鍵路徑的平台，因為每花一小時調 serving 旋鈕，就少一小時能拿來提升模型價值。選擇會自適應、決策透明、預設可觀測的系統，讓團隊把精力放在模型品質，而不是基礎設施救火。