Databricks Model Serving 讓 LLM 部署變簡單

我拆 Databricks Model Serving 的部署思路，順手給你一份可直接套用的 LLM endpoint 模板。

我用 Databricks Model Serving 一陣子了。模型能訓練、能註冊、能點 endpoint，聽起來一切都很順。但我一直覺得哪裡卡卡的：你以為自己在做部署，實際上是在把一堆 serving 零件拼成一個勉強能活的系統。版本對不上、wrapper 越寫越厚、autoscaling 行為像在跟你鬧脾氣，最後大家還是回到那句老話：到底是模型難，還是上線難？

我後來去看了 Flexera 的文章 How to: Deploy LLMs with Databricks Model Serving (2026)，才比較確定我在意的點不是功能有沒有，而是它到底有沒有把 serving 變成一個可以管理的流程。Databricks 官方現在把這套叫 Mosaic AI Model Serving，名字很長，但重點很單純：它想把部署這件事收斂到平台裡，不要每個團隊自己發明一套。

我就是想拆這個方法論。不是看它會不會說漂亮話，而是看它到底把哪些麻煩真的吃掉了，哪些只是換個地方繼續痛。

這篇的觸發點是 Flexera 那篇整理，原始內容有提到 Databricks Model Serving 的價格、限制、CPU/GPU 差異和實際部署流程，這些都是我覺得最值得拆的地方。

先別把 serving 當 notebook 的延伸

“Deploying a trained ML model is a different problem from training one.”

翻譯一下就是：訓練和上線根本不是同一種工作。訓練可以慢、可以重跑、可以 batch、可以容忍一堆 retry；serving 不行。serving 要的是穩、快、可觀測，而且不能每次流量一來就把整個團隊叫起來救火。

我之前做推薦系統時就踩過這個坑。訓練流程很乾淨，Notebook 跑完、模型 log 好、指標也漂亮，大家都很開心。結果一進 serving，事情開始變形：一段 Python wrapper、一個容器設定、幾個手工 patch，再加上沒人想碰的 autoscaling 參數。模型本身沒問題，真正出事的是 inference stack。

這也是 Databricks Model Serving 值得看的地方。它不是叫你把模型丟上去就算了，而是想把 serving 變成平台能力，至少不用每次都從零搭一個 endpoint 周邊系統。Databricks 文件本身也把它定位成 managed 的模型部署方式，這跟自己手刻 API server 的思路差很多。你如果還在把 serving 當成 notebook 的附屬品，最後通常就是一堆臨時補丁。

實操上，我會先把問題改寫成三件事：這個 endpoint 要怎麼版本化、怎麼 rollback、怎麼監控。只要這三件事沒答案，其他 UI 再漂亮都只是 demo。

真正省事的不是按 Deploy，是 registry 當單一真相來源

我看 Flexera 那篇最有感的一點，不是它在講按鈕，而是它一直在暗示：真正的捷徑是 MLflow Model Registry，不是 serving UI 本身。這點我很同意。因為大家常常誤會部署很難，實際上最煩的是版本管理。

你要知道哪個 artifact 是 live 的、哪個是 staging 的、哪個 retrain 後已經過期、哪個 endpoint 還在吃舊模型。這些事情如果靠手動對檔名、對路徑、對 Slack 訊息，遲早會炸。Registry 的價值，就是把模型生命週期變成可追蹤的狀態流，而不是一堆散落的檔案。

Databricks 的 serving 跟 MLflow Model Registry 接在一起，優點就是 promotion 變成一個有邏輯的動作，不是重複上傳。你把模型先註冊，標 staging，再測試，最後切 production，整條路徑清楚很多。

• 先 log 模型，再註冊版本
• 先在 staging 驗證，再進 production
• rollback 直接回上一版，不用重建整個部署流程

我自己的做法是：只要團隊還在手動搬模型檔，我就不讓他們碰 serving。先把 registry 當唯一真相來源，endpoint 只是消費它。這樣 retrain 完之後，才不會每次都像重新裝一次系統。

Serverless 很香，但別把每種 endpoint 都想成免錢

Flexera 有講到 Databricks Model Serving 的 serverless 特性，這點確實是它好用的地方。對 CPU 型 custom model 來說，你不用自己管基礎設施，endpoint 也可以在沒流量時縮到零。這對很多團隊來說很爽，因為終於不用再養一台只在半夜出事的機器。

但我不想幫它講得太滿。文章也有提到 CPU endpoint 跟 GPU provisioned throughput 是兩種不同模式。這差很多。CPU serverless 比較像「用多少付多少」的體驗；GPU provisioned throughput 則比較像你先把容量租下來，換穩定延遲和可預期吞吐。不要看到 serverless 就以為所有工作負載都會自動變便宜。

我看過最常見的誤會，就是團隊聽到 serverless 就以為不用算成本。結果一上 GPU、又要低延遲、又要高吞吐，最後帳單比想像中兇很多。這不是平台坑你，是你把不同計價模式混在一起想。

實操上，我會這樣切：

• 輕量 custom inference：先用 CPU serverless
• 延遲敏感、流量穩定：考慮 GPU provisioned throughput
• 流量波動大：先做壓測，再決定要不要為峰值付費

如果你現在還在猜，別猜。直接拿真實流量形狀去對成本模型，這比在會議室裡討論「應該」便宜太多。

一個介面收所有模型，比三套半殘流程正常多了

Flexera 文章裡有一個我覺得很實際的點：Databricks 想把 custom models、fine-tuned transformers、open-source checkpoints、third-party foundation models 收進同一套部署路徑。這聽起來很平凡，但我反而覺得這才是重點。因為模型種類越來越雜，團隊如果還每種都一套流程，最後就是運維地獄。

沒有統一介面時，通常會長成這樣：一種模型一個 wrapper、一種部署一套 script、一種監控一個 dashboard、一種失敗方式一個 on-call 群組。你表面上是在做 AI，實際上是在養很多個互不相干的小系統。

Databricks 的做法比較像是把 endpoint 當抽象層，模型類型只是底下的實作差異。這樣至少 client 端不用每次換模型就重寫呼叫方式。更重要的是，治理、權限、rate limit、監控也比較容易集中處理。

我自己的實務原則很簡單：對外只保留一種 serving contract。內部可以有不同模型、不同硬體、不同成本結構，但外部 request/response 盡量固定。這樣你才不會每次換模型都順便換掉整個產品介面。

• 統一 auth，不要每個 endpoint 各玩各的
• 統一 log 格式，方便查問題
• 統一 request schema，減少 client 改動

你如果能讓使用者感覺 endpoint 很無聊，代表你做對了。serving 最怕的不是不酷，是每次都要人猜。

真正先壞掉的通常是 latency，不是 accuracy

Flexera 把 real-time ML 會遇到的問題列得很完整：latency、throughput、real-time features、monitoring、deployment pipeline、versioning、data quality、整合既有系統。這串清單看起來像教科書，實際上很像事故報告。

我自己的經驗是，很多 production ML 根本不是死在「模型不準」，而是死在系統太慢、資料太舊、或根本看不到問題。使用者不會原諒一個 500ms 以外的推薦 endpoint；風控模型如果卡在 feature lookup，錢就是這樣漏掉；模型如果 drift 了但沒人知道，等於你在 production 裡放了一台默默變爛的機器。

這也是我為什麼會特別注意 Databricks 跟 online feature store、Vector Search 的整合。因為如果你做的是即時推論，資料新鮮度就是模型品質的一部分。資料慢半拍，模型再好也只是慢半拍的猜測。

實操上，我建議你在 launch 前先回答三個問題：

• 延遲能不能達標
• 資料是不是夠新
• 出問題時我能不能第一時間知道

這三題答不出來，就先不要跟別人說你已經 production-ready。那只是把風險包裝得比較像產品。

價格不是附錄，是你會不會後悔的地方

Flexera 的 pricing 段落我覺得很值得看，因為它沒有裝作成本是小事。文章提到價格會受 cloud、region、plan tier 影響，而且 Standard tier 正在退場，現在多半要看 Premium 或 Enterprise。這種資訊很煩，但也很重要，因為它會直接影響你怎麼規劃預算和遷移。

我一直覺得 serving 成本最容易被低估。訓練是偶發，serving 才是每天燒錢的地方。你如果把模型部署出去，然後流量一多，真正長期存在的不是模型誤差，而是月帳單。

不同計價模式的差異要分清楚：

• CPU serverless：偏使用量計費
• GPU provisioned throughput：偏預留容量計費
• foundation model 的 pay-per-token：偏 token 用量計費

我會先估 request volume、latency target、idle time，再去對應計價方式。不要反過來，先選一個看起來最潮的方案，再回頭硬湊需求。那種做法通常最後都很貴，而且貴得不明不白。

可抄的模板

# Databricks Model Serving LLM endpoint 模板（可直接改成你自己的版本）

## 1. 先選服務模式
- 輕量 custom LLM：CPU serverless
- 延遲敏感或高吞吐：GPU provisioned throughput
- foundation model：先算 token 成本，再決定要不要上線

## 2. 先把模型放進 MLflow
- log 模型 artifact
- 註冊 model version
- 標記 stage：staging / production / archived

## 3. 定義固定的 endpoint contract
Request:
{
  "prompt": "...",
  "system_message": "...",
  "max_tokens": 256,
  "temperature": 0.2,
  "metadata": {
    "team": "...",
    "env": "prod"
  }
}

Response:
{
  "generated_text": "...",
  "model_version": "...",
  "latency_ms": 123,
  "request_id": "..."
}

## 4. 建立 serving endpoint
- 綁定已註冊的 model version
- 設定 access control
- 開啟 autoscaling 或預留容量
- 外部服務就加 rate limit

## 5. 把即時資料接進來
- 需要最新特徵就接 online feature store
- 需要檢索就接 Vector Search
- 在 log 裡記錄 feature freshness

## 6. 觀測一定要做
- request_id
- model_version
- latency_ms
- tokens_in
- tokens_out
- error_code
- p95 latency
- error rate

## 7. rollback 要先演練
- 保留上一版 model version
- staging 過了才切 production
- 出事就切回上一版，不要現場重建

## 8. 成本先估再上
- CPU serverless：看使用量
- GPU provisioned throughput：看預留容量
- 一週真實流量後再修正成本假設

## 9. 最小 release checklist
- auth 正常
- logs 可查
- latency 達標
- rollback 可用
- ownership 明確

## 10. 最小可用 payload
{
  "prompt": "Summarize this customer issue in one paragraph.",
  "system_message": "Be concise and factual.",
  "max_tokens": 200,
  "temperature": 0.2,
  "metadata": {
    "team": "support",
    "env": "prod"
  }
}

這份模板故意寫得很無聊，因為 serving 本來就不該靠花俏撐場面。你要的是可重複、可監控、可 rollback，不是每次發版都像在做表演。

我這篇的拆解主要來自 Flexera 的原文 https://www.flexera.com/blog/finops/databricks-model-serving/，另外也參考了 Databricks 官方文件 Mosaic AI Model Serving、MLflow Model Registry、online feature store 與 Vector Search。上面那份模板是我自己整理的，可直接拿去改。