什麼是佈建的輸送量？
注意
Azure OpenAI 佈建的供應項目已於 2024 年 8 月 12 日收到重大更新，包括使購買模型與 Azure 標準一致，以及轉移成與模型無關的配額。 強烈建議在此日期之前加入的客戶，閱讀 Azure OpenAI 佈建的 8 月更新，以深入了解這些變更。
佈建的輸送量功能可讓您指定部署中所需的輸送量。 服務接著會配置必要的模型處理容量，並確認可供您使用。 輸送量會以佈建的輸送量單位 (PTU) 定義，這是表示部署輸送量的標準化方式。 每個模型與版本組都需要部署不同的 PTU 數量，並為每個 PTU 提供不同的輸送量。
布建的部署類型提供什麼？
- 可預測的效能：穩定統一工作負載的最大延遲和輸送量。
- 保留的處理容量：部署會設定輸送量。 部署之後，不論是否使用，都會提供該輸送量。
- 節省成本：高輸送量工作負載有機會節省成本 (相較於權杖型使用量)。
Azure OpenAI 部署是特定 OpenAI 模型的管理單位。 部署可讓客戶存取模型以進行推斷，並整合更多功能，例如內容仲裁 (請參閱內容仲裁文件)。 全域布建的部署可在與所有其他部署類型相同的 Azure OpenAI 資源中使用，但可讓您利用 Azure 的全域基礎結構，以動態方式將流量路由傳送至數據中心，並針對每個要求提供最佳可用性。 同樣地，數據區布建部署也可用於與所有其他部署類型相同的資源，但可讓您利用 Azure 的全域基礎結構，以動態方式將流量路由傳送至指定數據區內Microsoft指定數據區內的流量，並針對每個要求提供最佳可用性。
您可得到什麼結果？
| 主題 | 已佈建 |
|---|---|
| 這是什麼？ | 提供略高於現有佈建方案的保證輸送量。 針對指定的模型版本，部署會具有一致的最大延遲。 |
| 適用對象為何？ | 想要讓保證輸送量具有最小延遲差異的客戶。 |
| 配額 | 已布建的受控輸送量單位、全域布建的受控輸送量單位，或每個區域指派的數據區域布建受控輸送量單位。 配額可用於任何可用的 Azure OpenAI 模型。 |
| 延遲 | 模型所限制的最大延遲。 整體延遲會受到呼叫結構影響。 |
| 使用率 | Azure 監視器中提供的佈建受控使用率 V2 量值。 |
| 估計大小 | 在 Azure AI Foundry 和基準檢驗腳本中提供計算機。 |
| 提示快取 | 針對支援的模型，我們最多可折扣 100% 的快取輸入令牌。 |
每個模型每個 PTU 的輸送量
每個 PTU 取得的輸送量量（每分鐘或 TPM 的令牌數）是分鐘內輸入和輸出令牌的函式。 產生輸出令牌需要比輸入令牌更多的處理，因此產生整體 TPM 的輸出令牌越多。 服務會動態平衡輸入和輸出成本，因此使用者不需要設定特定的輸入和輸出限制。 這種方法表示您的部署可復原工作負載圖形中的波動。
為了協助簡化重設大小工作，下表概述 和 gpt-4o-mini 模型的 TPM，gpt-4o這些模型代表所有流量都是輸入或輸出的最大 TPM。 若要瞭解輸入和輸出令牌的不同比例如何影響每個 PTU 的 TPM 上限，請參閱 Azure OpenAI 容量計算機。 下表也會顯示每個模型的服務等級協定 （SLA） 延遲目標值。 如需 Azure OpenAI 服務 SLA 的詳細資訊，請參閱 在線服務的服務等級協定 （SLA） 頁面
| 主題 | gpt-4o， 2024-05-13 & gpt-4o， 2024-08-06 | gpt-4o-mini, 2024-07-18 |
|---|---|---|
| 全域和數據區布建的最低部署 | 15 | 15 |
| 全域和數據區布建的縮放增量 | 5 | 5 |
| 區域布建的最低部署 | 50 | 25 |
| 區域布建的縮放增量 | 50 | 25 |
| 每個 PTU 的最大輸入 TPM | 2,500 | 37,000 |
| 每個 PTU 的最大輸出 TPM | 833 | 12,333 |
| 延遲目標值 | 每秒 25 個令牌 | 每秒 33 個令牌 |
如需完整清單， 請參閱 Azure AI Foundry 計算機中的 AOAI。
注意
目前僅支援 gpt-4o、2024-08-06 和 gpt-4o-mini、2024-07-18 模型的全球布建部署。 目前僅支援 gpt-4o、2024-08-06、gpt-4o、2024-05-13 和 gpt-4o-mini、2024-07-18 模型。 如需模型可用性的詳細資訊，請檢閱 模型檔。
重要概念
部署類型
在 Azure AI Foundry 中建立布建部署時，[建立部署] 對話方塊上的部署類型可以設定為全域布建受控、DataZone Provisioned-Managed 或區域布建受控部署類型，視給定工作負載的數據處理需求而定。
透過 CLI 或 API 在 Azure OpenAI 中建立布建的部署時， sku-name 可以設定為 GlobalProvisionedManaged、 DataZoneProvisionedManaged，或 ProvisionedManaged 視指定工作負載的數據處理需求而定。 若要將下面的 Azure CLI 範例命令調整為不同的部署類型，只需更新 sku-name 參數以符合您想要部署的部署類型。
az cognitiveservices account deployment create \
--name <myResourceName> \
--resource-group <myResourceGroupName> \
--deployment-name MyDeployment \
--model-name gpt-4 \
--model-version 0613 \
--model-format OpenAI \
--sku-capacity 100 \
--sku-name ProvisionedManaged
配額
佈建的輸送量單位
佈建的輸送量單位 (PTU) 是模型處理容量的一般單位，可用來調整佈建部署的大小，以達到處理提示和產生完成所需的輸送量。 布建的輸送量單位會以配額的形式授與訂用帳戶。 每個配額都專屬於某個區域，並定義可指派給該訂用帳戶和區域中部署的 PTU 數目上限。
模型獨立配額
不同於其他 Azure OpenAI 供應項目所使用的每分鐘權杖 (TPM) 配額，PTU 與模型無關。 PTU 可用來在區域中部署任何支援的模型/版本。
針對布建的部署，新的配額會顯示在 Azure AI Foundry 中，作為名為布建受控輸送量單位的配額專案。 針對全域布建的部署，新的配額會顯示在 Azure AI Foundry 中，作為名為全域布建受控輸送量單位的配額專案。 針對布建的數據區部署，新的配額會顯示在 Azure AI Foundry 中，作為名為數據區域布建受控輸送量單位的 配額專案。 在 [Foundry 配額] 窗格中，展開配額專案會顯示導致每個配額使用量的部署。
取得 PTU 配額
PTU 配額預設可在許多區域中取得。 如果需要更多配額，客戶可以透過 [要求配額] 連結來要求配額。 您可以在 Azure AI Foundry 中指定布建的部署類型配額索引標籤右側找到此連結。表單可讓客戶要求增加指定區域的指定 PTU 配額。 一旦核准要求，客戶就會在內含位址收到電子郵件，通常是在兩個工作天內。
每一模型 PTU 最小值
每個單位相關聯的最小 PTU 部署、增量和處理容量會因模型類型和版本而有所不同。
容量透明度
Azure OpenAI 是一項熱門服務，其客戶需求可能會超過服務 GPU 容量。 Microsoft 努力為所有需求區域和模型提供容量，但總是有可能在某個區域銷售一空。 此條件約束可以限制某些客戶在所需區域中建立所需模型、版本或 PTU 數目的部署能力，即使該區域有可用的配額也一樣。 一般來說：
- 配額會限制可在訂用帳戶和區域中部署的最大 PTU 數目，且不保證容量可用性。
- 容量會在部署時配置，只要部署存在，就會保留容量。 如果沒有服務容量，部署將會失敗
- 客戶會使用配額/容量可用性的即時資訊，為具有必要模型容量的案例選擇適當的區域
- 縮小或刪除部署會將容量釋放回區域中。 但如果之後擴大或重新建立部署，則無法保證容量可供使用。
區域容量指引
若要尋找其部署所需的容量，請使用容量 API 或 Azure AI Foundry 部署體驗來提供容量可用性的實時資訊。
在 Azure AI Foundry 中，部署體驗會識別區域何時缺少部署模型所需的容量。 這會查看所需的模型、版本和 PTU 數目。 如果容量無法使用，體驗會將用戶導向至選取替代區域。
如需新部署體驗的詳細資料，請參閱 Azure OpenAI 佈建入門指南。
新的 模型容量 API 可用來以程式設計方式識別指定模型的大小上限部署。 API 會考慮您區域中的配額和服務容量。
如果可接受的區域無法支援所需的模型、版本和/或 PTU，客戶也可以嘗試下列步驟：
- 嘗試使用較少的 PTU 數量進行部署。
- 嘗試在不同的時間部署。 容量可用性會根據客戶需求動態變更，之後可能會有更多容量可供使用。
- 確定所有可接受的區域都有可用的配額。 模型容量 API 和 Azure AI Foundry 體驗會考慮在傳回替代區域以建立部署時的配額可用性。
判斷工作負載所需的 PTU 數目
PTU 代表模型處理容量的數量。 如同您的電腦或資料庫，模型的不同工作負載或要求會取用不同數量的基礎處理容量。 從呼叫結構特性 (提示大小、產生大小和呼叫速率) 轉換為 PTU 是一個複雜且非線性的程序。 若要簡化此程序，您可以使用 Azure OpenAI 容量計算機來調整特定工作負載圖形的大小。
一些高階考慮事項：
- 生成需要比提示更多的容量
- 針對 GPT-4o 和更新版本模型，每個 PTU 的 TPM 會分別針對輸入和輸出令牌進行設定。 對於較舊的模型，較大型的呼叫會逐漸增加計算成本。 例如，100 個具有 1000 個權杖提示大小的呼叫，其所需的容量會低於一個在提示中包含 100,000 個權杖的呼叫。 這個階層處理表示這些呼叫圖形的分佈在整體輸送量中很重要。 包含一些大型呼叫的流量模式，每個 PTU 的輸送量可能會比具有相同平均提示和完成令牌大小的較窄分佈還要低。
使用率效能的運作方式
佈建的部署為您提供已配置的模型處理容量，用於執行指定的模型。
在所有布建的部署類型中，超過容量時，API 會傳回 429 HTTP 狀態錯誤。 此快速回應可讓用戶決定如何管理其流量。 用戶可以將要求重新導向至個別部署、標準隨用隨付實例，或使用重試策略來管理指定的要求。 服務會繼續傳回 429 HTTP 狀態代碼，直到使用率低於 100%。
如何監視容量？
Azure 監視器中的 Provisioned-Managed Utilization V2 計量 (部分機器翻譯) 會以 1 分鐘的增量來測量指定的部署使用率。 所有布建的部署類型都會經過優化，以確保接受的呼叫是以 consis 處理 帳篷模式 l 處理時間（實際的端對端延遲取決於呼叫的特性）。
當我收到 429 回應時，該怎麼辦？
429 回應不是錯誤，而是告知使用者特定部署在某個時間點使用率滿載的一種設計。 藉由提供快速失敗的回應，您可以透過最符合應用程式需求的方式，控制這些情況的處理方式。
回應包含 retry-after-ms 和 retry-after 標頭，用於告知接受下一個呼叫之前須等待的時間。 要如何處理此回應取決於您的應用程式需求。 以下是一些考量：
- 您可以考慮將流量重新導向至其他模型、部署或體驗。 此選項是最低延遲解決方案，因為只要收到 429 訊號就可以採取此動作。 如需有效實作此模式的想法，請參閱這篇社群文章 (英文)。
- 如果您能夠接受較長的每次呼叫延遲，請實作使用者端重試邏輯。 此選項可讓您達到每個 PTU 的最大輸送量。 Azure OpenAI 使用者端程式庫包含處理重試的內建功能。
服務如何決定傳送 429 的時機？
在所有布建的部署類型中，每個要求都會根據其提示大小、預期的產生大小和模型個別評估，以判斷其預期的使用率。 這與隨用隨付部署正好相反，後者具有根據預估流量負載的自訂速率限制行為。 針對隨用隨付部署，如果流量未平均分散，可能會導致在超過定義的配額值之前就產生 HTTP 429 錯誤。
針對布建的部署，我們會使用流失值區演算法的變化來維持 100% 以下的使用率，同時允許流量中的某些高載。 高階邏輯如下所示：
每位客戶都有一組可在部署上使用的容量
提出要求時：
a. 如果目前的使用率高於 100%，服務會傳回 429 代碼，
retry-after-ms標頭設定為使用率降至 100% 以下所需的時間b. 否則，服務會藉由結合提示權杖和呼叫中指定的
max_tokens，估計為要求提供服務所需的增量變更。 對於至少包含1024個快取令牌的要求，快取令牌會從提示令牌值減去。 客戶可以根據快取令牌的大小，在其提示令牌上收到最多 100% 折扣。max_tokens如果未指定 參數，服務會估計值。 當實際產生的權杖數目很小時，此估計可能會導致並行存取率低於預期。 若想達到最高的並行存取，請確保max_tokens值盡可能接近真正的產生大小。當要求完成時，現在我們知道呼叫的實際計算成本。 為了確保準確的計量，我們會使用下列邏輯來更正使用率：
a. 如果實際 > 估計值，則會將差異新增至部署的使用率。
b. 如果實際值 < 估計值，則會減去差異值。
整體使用率會根據部署的 PTU 數目，以連續速率遞減。
注意
在使用率達到 100% 之前會持續接受呼叫。 高載可能只會在短時間內允許超過 100%，但您的流量使用率會逐步回到 100% 上限。
我可以在部署上擁有多少個並行呼叫？
您可以達成的並行呼叫數目取決於每個呼叫的結構 (提示大小、max_token 參數等等)。 服務會繼續接受呼叫，直到使用率達到100%。 若要判斷並行呼叫的近似數目，您可以在容量計算機中針對特定呼叫圖形，計算每分鐘要求數上限。 如果系統生成少於取樣權杖數目 (例如 max_token)，則會接受更多要求。
哪些模型和區域有提供佈建的輸送量？
| 區域 | gpt-4o，2024-05-13 | gpt-4o，2024-08-06 | gpt-4o-mini, 2024-07-18 | gpt-4，0613 | gpt-4，1106-Preview | gpt-4，0125-Preview | gpt-4，turbo-2024-04-09 | gpt-4-32k，0613 | gpt-35-turbo，1106 | gpt-35-turbo，0125 |
|---|---|---|---|---|---|---|---|---|---|---|
| australiaeast | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| brazilsouth | ✅ | - | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | - |
| canadacentral | ✅ | - | - | ✅ | - | - | - | ✅ | - | ✅ |
| canadaeast | ✅ | - | ✅ | ✅ | ✅ | - | ✅ | - | ✅ | - |
| eastus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| eastus2 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| francecentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | - | ✅ |
| germanywestcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - |
| japaneast | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ | - | - | ✅ |
| koreacentral | ✅ | ✅ | ✅ | ✅ | - | - | ✅ | ✅ | ✅ | - |
| northcentralus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| norwayeast | ✅ | - | ✅ | ✅ | - | ✅ | - | ✅ | - | - |
| polandcentral | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| southafricanorth | ✅ | - | - | ✅ | ✅ | - | ✅ | ✅ | ✅ | - |
| southcentralus | ✅ | - | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| southindia | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| swedencentral | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| switzerlandnorth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| switzerlandwest | - | - | - | - | - | - | - | - | - | ✅ |
| uaenorth | ✅ | - | - | - | ✅ | - | - | - | ✅ | ✅ |
| uksouth | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| westus | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| westus3 | ✅ | ✅ | - | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
注意
下列佈建版本 gpt-4 版本：turbo-2024-04-09 目前僅限使用文字。
下一步
- 了解已佈建部署的上線步驟 (部分機器翻譯)
- 佈建的輸送量單位 (PTU) 使用者入門指南