Databricks 模型怎麼選區域

我把 Databricks 的模型支援表拆成區域、端點和路由清單，讓你可以直接拿去做選型。

我用 Databricks 的 model serving 一陣子了，越看越有種「文件沒錯，但就是故意不讓你一次看懂」的感覺。你點進 Supported foundation models on Model Serving，表面上像是在挑模型，實際上你是在同時挑 serving mode、AWS region、路由設定、還有是不是已經快退役。最煩的是，很多團隊一開始只盯模型名，等到要上線才發現：同一個模型在不同區域可不一定能跑，pay-per-token、AI Functions、provisioned throughput 也不是同一套邏輯。我看過太多人把「能不能用」當成「模型列表上有沒有」，結果踩得一地都是。

這篇的起點就是 Databricks AWS 文件本身，還有它連到的幾個相關頁面：Model Serving、AI Functions、Unity Catalog。我不是要重寫文件，我是把它拆成工程師真的會拿來做決策的版本。原始頁面有區域矩陣、模型狀態、退役提醒，這些才是上線前會卡你的地方。

先別看模型名，先看你到底要哪種 serving

Model Serving offers flexible options for hosting and querying foundation models based on your needs: Pay-per-token, AI Functions (batch inference), Provisioned throughput, External models.

翻譯一下就是：Databricks 不是給你一個 serving，而是給你四種完全不同的用法。你如果先挑模型、後挑模式，通常就會走錯方向。我真的看過團隊先愛上一個模型，再硬把它塞進錯的 endpoint，最後抱怨 latency 不穩、成本太高、batch 跑得像即時 API 一樣卡。

pay-per-token 比較像「先讓我試試看」。它的優點是快，幾乎不用搭一堆基礎設施就能開始驗證。缺點也很直接，就是你買的是方便，不是控制。適合 demo、短期實驗、概念驗證，不適合你拿來假裝它能扛所有 production 壓力。

AI Functions 則是另一種腦袋。它不是要你拿模型去扮演聊天機器人，而是把模型嵌進資料流程裡做 batch inference。這點很重要，因為很多團隊會把 row-by-row 的資料轉換硬塞進一般 serving endpoint，然後再對成本和吞吐量崩潰。我以前也幹過這種事，結果就是 pipeline 看起來很潮，實際上很醜。

Provisioned throughput 才是你真的在乎效能和穩定性時該看的路。文件很明白地把它放在需要 performance guarantees 的場景，這句我會直接畫線。你要是做的是對外服務、內部 SLA、或者任何不能靠運氣撐住的工作，best effort 根本不算方案。再加上 fine-tuned foundation models 也會走這條路，代表 Databricks 自己也把它當成比較正經的 production path。

• 探索、demo、驗證概念：先看 pay-per-token。
• 資料管線、批次推論：先看 AI Functions。
• 要 SLA、要穩定延遲：先看 provisioned throughput。
• 外部模型治理：再看 external models。

實操上我會先寫一行話：這個模型是拿來做互動、批次、還是 SLA 服務？如果這句話都講不清楚，就先別挑模型。你現在缺的不是模型名，你缺的是 plumbing 的決策。

Databricks hosted 不代表每個 region 都能用

Databricks hosts state-of-the-art open foundation models. These models are made available using Foundation Model APIs.

這句看起來很漂亮，但白話就是：Databricks 幫你托管，不代表你在哪裡都能用。真正麻煩的地方在區域矩陣。模型家族很多，能不能用要看 AWS region、serving mode、還有模型狀態。你如果只看名字不看區域，等於把部署計畫交給運氣。

我很不喜歡這種「看起來像統一入口，實際上每個地區都不一樣」的設計，但這就是雲平台的現實。你在 us-east-1 能跑，不代表 ap-southeast-1 也能跑；你在 real-time inference 能用，不代表 AI Functions 或 provisioned throughput 也一樣。這不是文件寫得亂，是平台本來就不是單一平面。

文件也提到可以用 Foundation model Unity Catalog permissions 去限制組織可用模型。這點我很認同。企業內部最怕的不是沒模型可用，而是每個 team 都自己試、自己開、自己上，最後沒人知道誰批准了什麼。能控權限，就不要放任大家亂選。

實操寫法很簡單：先把你要上的 AWS region 列出來，再看那個 region 支援哪種 serving mode，最後才看模型家族和是否 preview。不要反過來。文件頁面是給人查的，不是給你拿來在 production 當 runtime lookup 的。

• 先鎖定目標 region。
• 再確認 serving mode。
• 最後看 model family 和 status。
• 如果是企業環境，再補上權限檢查。

全球端點不是免費午餐，跨地理路由會咬人

Google Gemini 3.5 Flash requires cross geography routing to be enabled for regions outside the US and EU geos. Google Gemini 3 Flash and Google Gemini 3 Pro are hosted on global endpoints and require cross geography routing to be enabled for every region.

這段的意思很直接：有些模型不是單純看 region，而是看你有沒有開 cross geography routing。也就是說，就算模型在文件裡看起來支援，你的帳號或組織路由設定沒開，還是不能用。這種問題最煩，因為它不是 code error，是 policy error。

我不太愛這種設定，但它很常見。尤其是全球端點型的模型，平台會把 routing 當成一層額外門檻。Gemini 3.5 Flash 在 US 和 EU 以外需要開；Gemini 3 Flash 和 Gemini 3 Pro 更狠，幾乎每個 region 都要開。OpenAI Codex 某些模型也一樣。這表示你的部署決策，不只跟模型有關，還跟組織的網路與資料治理有關。

我看過最典型的卡關場景，就是平台團隊、網路團隊、應用團隊三邊都說自己沒錯。應用端說模型可用，平台端說 region 沒問題，網路端說 routing 沒開。三個人都對，系統就是不動。這種時候，你就知道問題不是模型選錯，是你根本沒把部署前提列清楚。

實操寫法：只要你碰到 global endpoint，就把 cross geography routing 當成 checklist 的一項，不要等到測試失敗才回頭查。若你有資料駐留要求，先把不能碰的模型列黑名單，別讓開發先綁死之後才來改架構。

退役不是公告而已，是你要做 migration

Google Gemini 3 Pro will be retired on March 26, 2026. OpenAI GPT-5.1 Codex Max, OpenAI GPT-5.1 Codex Mini, and OpenAI GPT-5.2 Codex will be retired on July 16, 2026. Anthropic Claude 3.7 Sonnet is no longer available.

這句我會直接當成 migration work，不會當成新聞看。模型退役不是「之後再說」，而是你現在就要安排替代方案。Databricks 文件還提到 Gemini 3 Pro 在特定期間會有 temporary redirection，這種東西更不能偷懶。你如果以為退役只是名字換掉，通常會在最後一週被迫熬夜。

我以前最常看到的錯誤，就是團隊把模型當成永遠存在的 API。結果一旦 provider 改了支援範圍，prompt、輸出格式、latency、甚至成本全都變。正確做法應該是像處理 API version sunset 一樣處理它：先雙跑、再比對、再切換，別等到關門才找替代品。

文件也寫到 Meta Llama 3.1-405B-Instruct 在 pay-per-token 已經不可用，provisioned throughput 也有自己的退役時間。這代表「可用」不是全域屬性，而是 mode-specific。很多人以為模型還在列表裡就代表萬事大吉，實際上它可能只是在某個 serving path 還活著。

實操寫法：做一張內部退役追蹤表，欄位至少要有 current model、serving mode、退役日期、replacement、測試狀態。只要文件提到 temporary redirect，你就立刻測，不要把它當成「之後應該還能用」。

Preview 標籤不是裝飾，是風險提示

Meta Llama 4 Maverick is available for Foundation Model APIs provisioned throughput workloads in Public Preview.

這句話的重點不是「它能用」，而是「它還在 preview」。我對 preview 沒意見，實驗環境本來就該玩新東西；但如果是會碰到客戶的流程，我就會先問：出問題時有沒有 fallback？有沒有 feature flag？有沒有 canary？沒有的話，preview 就只是拿來增加你值班時的血壓。

preview 的本質是契約還沒完全穩。你今天以為輸出格式固定，明天 provider 改了一點點，你 downstream 就開始抖。你以為 token 上限夠，結果某次更新後行為不一樣。這些都不是「模型壞掉」，而是你把 preview 當 GA 在用。

我之前幫團隊收過這種爛攤子：大家很愛新模型，因為 benchmark 很漂亮，結果 rollout 後才發現 prompt 要重調、監控要重寫、fallback 也沒準備。最後不是模型不好，是流程太天真。

實操寫法：只要是 preview，就給它 feature flag、canary、fallback 三件套。文件或內部 runbook 也要把 preview 標得很明顯，別讓人誤以為它跟正式版一樣穩。

即時推論的清單，比你想的短很多

The following model families are supported for real-time inference: OpenAI GPT OSS 120B, OpenAI GPT OSS 20B, Google Gemma 3 12B, Alibaba Cloud Qwen3.5 122B A10B (preview), Meta Llama 4 Maverick (preview), Meta Llama 3.3, Meta Llama 3.2 3B, Meta Llama 3.2 1B, Meta Llama 3.1, GTE v1.5 (English), BGE v1.5 (English).

這段很重要，因為它把 real-time inference 的範圍收得很窄。白話講，不是每個 hosted model 都適合拿來做即時對話或 API 回應。你要的是低延遲，就別幻想 batch-oriented 的模型也能同樣順手。

很多團隊講「我們要最好的模型」，其實真正意思是「我們要一個回得夠快的 endpoint」。這兩句差很多。你如果只看 benchmark，不看是否在 real-time 清單裡，最後很容易把一個適合離線處理的東西硬塞進互動流程。

實操寫法：設計應用時先看互動型態和延遲預算。要即時回應，就先過濾 real-time inference 清單；要處理資料、embedding、批次轉換，就去看 batch 或 provisioned 路線。別把「已經在 workspace 裡」誤認成「適合這個場景」。

可抄的模板

# Databricks foundation model 選型模板（可直接貼到內部 wiki / runbook）

## 1) 先決定 serving mode
- [ ] Pay-per-token：探索、demo、短期驗證
- [ ] AI Functions：batch inference / 資料流程
- [ ] Provisioned throughput：production SLA / 穩定延遲
- [ ] External models：外部模型治理與控管

## 2) 鎖定部署前提
- 目標 AWS region：________________
- 備援 region：____________________
- 資料駐留要求：__________________
- 是否允許跨地理路由：Yes / No

## 3) 依序檢查
1. 這個 serving mode 是否支援
2. 這個 region 是否支援
3. 是否需要 cross geography routing
4. 是否為 Preview
5. 是否有 retirement notice

## 4) 模型記錄欄位
- Model family：____________________
- Databricks model name：___________
- Endpoint type：___________________
- Status：GA / Preview / Retired soon
- Replacement model：_______________
- Routing required：Yes / No
- Owner：___________________________
- Last test date：___________________

## 5) 上線前 guardrails
- [ ] Preview 模型有 feature flag
- [ ] 有 fallback model
- [ ] 已檢查 Unity Catalog permissions
- [ ] 已確認 cross geography routing
- [ ] 已做 target region load test
- [ ] 已更新內部 deprecation tracker

## 6) 決策紀錄句
我們會在 [REGION] 使用 [MODEL] 的 [SERVING MODE]，因為 [LATENCY / COST / GOVERNANCE]。
若 [MODEL] 退役或不可用，會切換到 [REPLACEMENT]，並重新測試 prompt、輸出格式與延遲。

## 7) 最小 runbook
- 這個模型是拿來做什麼：
- 這個模型不是拿來做什麼：
- 壞掉時會影響什麼：
- 下一個替代模型是什麼：
- 誰有切換權限：

這份模板就是我會真的放進團隊文件的版本。它不漂亮，但它能逼你把 region、mode、routing、preview、retirement 這些容易漏掉的事先寫下來。Databricks 的官方頁面是 source of truth，我這裡只是把它整理成能直接拿去用的作業格式。

原始來源是 Databricks 官方文件。我把文件內容重組成工程師可用的決策清單，模型支援狀態、退役日期、路由需求這些資訊都來自原文；上面的模板和判讀方式是我自己整理出來的。