Databricks 應把外部模型服務端點管得更緊

Databricks 外部模型服務端點應由平台集中治理，不能交給團隊各自亂接 LLM。

Databricks 把外部模型端點設成受管基礎設施，這個方向是對的。它明確要求存取控制、速率限制與以 secret 管理的供應商憑證，這代表平台不是在賣「隨便連一個模型」的便利，而是在賣可控的生產能力。若一個工作區端點能幾個點擊就接上 OpenAI 或 Anthropic，真正該問的不是快不快，而是誰能呼叫、花多少錢、用了哪組憑證。

第一個論點

外部模型之所以有價值，是因為它把前沿模型帶進 Databricks 的治理邊界內。文件直接把 centrally governed endpoints、access control、rate limits 放在核心位置，這不是裝飾，而是產品定義。當一個端點變成內部共享能力，沒有管控就會立刻擴散成生產風險；相反地，帶有使用者層級限制與 secret-backed provider token 的單一端點，遠比散落各處的 API key 更適合作為營運單位。

證據就在 REST 範例裡。Databricks 直接示範在端點上設定 rate limit，例如每位使用者每分鐘 100 次呼叫，並同時掛上 tags 與 provider key 的 secret reference。這不是細節，而是平台在告訴買家：外部模型使用必須和倉庫、叢集、作業一樣，進入同一個控制平面。凡是已經在治理資料與運算資源的團隊，就沒有理由對模型存取採取更鬆的標準。

第二個論點

Databricks 先要求使用者選擇任務類型：chat、completion 或 embeddings，再依此更新可用模型清單。這個限制很聰明，因為模型服務最容易失控的地方，就是一個端點想同時扮演所有角色。聊天模型與向量嵌入模型根本不是同一種工作負載，先在建立時把邊界劃清，能降低誤用、客戶端相容性問題，以及成本失控的機率。2024 年多數企業 AI 支出失控案例，根源都不是模型不夠強，而是用途界線太模糊。

文件還把端點形狀鎖得很死：一旦有 external_model，served_entities 只能有一個 served_entity 物件，而且端點不能在外部與非外部配置之間來回轉換。這種硬性規則不是保守，而是避免配置漂移的必要手段。根據 Databricks 的設計，端點不是可任意拼裝的玩具，而是有明確合約的生產服務。對推論系統來說，簡單就是可靠；一旦允許端點被變形成另一類服務，隱藏依賴與脆弱發布流程就會跟著出現。

反方可能怎麼說

最強的反對意見是，Databricks 把速度換成了摩擦。若產品團隊手上已經有 OpenAI key，只想在幾分鐘內把 embeddings 或 chat 跑起來，集中治理、secret scope、任務限制與序列化更新，確實會顯得沉重。有些團隊會主張，最快的價值路徑就是在應用程式裡直接呼叫外部 API，少一層平台就少一層阻力。

這個批評對原型開發成立，但對共享的正式系統不成立。當多個服務開始依賴同一個模型端點，沒有治理的 API key 和臨時配額就會變成風險來源。Databricks 不是在阻擋速度，而是在把速度變成可稽核、可回復、可控管的能力。若團隊只是做實驗，直接呼叫可以接受；一旦要做成長期內部服務，端點就必須被治理、版本化並受限制。平台選擇偏向後者，是正確的。

你能做什麼

如果你是工程師或平台負責人，就把 Databricks 外部模型端點視為正式生產路徑來設計：用 secret scope 管供應商憑證，替每個團隊或使用者設明確 rate limit，端點加上 owner tag，並且一個端點只對應一種清楚任務。若你是 PM 或創辦人，不要先要求「更彈性」，先要求更清楚的 ownership、更嚴的成本控管，以及可回滾的更新流程。這才是把模型存取做成營運能力，而不是事故來源的方法。