什麼是布建輸送量？
布建的輸送量功能可讓您指定部署中所需的輸送量量。 服務接著會配置必要的模型處理容量，並確定它已可供您使用。 輸送量是以布建的輸送量單位 （PTU） 來定義，這是表示部署輸送量的標準化方式。 每個模型版本組都需要不同的 PTU 數量來部署，並提供每個 PTU 的不同輸送量量。
布建的部署類型提供什麼？
- 可預測的效能： 統一工作負載的穩定最大延遲和輸送量。
- 保留的處理容量： 部署會設定輸送量量。 部署之後，不論是否使用，都可以使用輸送量。
- 節省成本： 高輸送量工作負載可能會節省成本與以令牌為基礎的耗用量。
Azure OpenAI 部署是特定 OpenAI 模型的管理單位。 部署可讓客戶存取模型以進行推斷，並整合更多功能，例如內容仲裁（請參閱 con 帳篷模式 ration 檔）。
注意
布建的輸送量單位 （PTU） 配額與 Azure OpenAI 中的標準配額不同，且預設無法使用。 若要深入瞭解此供應專案，請連絡您的 Microsoft 帳戶小組。
您可得到什麼結果？
| 主題 | 已佈建 |
|---|---|
| 這是什麼？ | 提供比現有布建供應專案小的保證輸送量。 針對指定的模型版本，部署具有一致的最大延遲。 |
| 神秘 適合嗎？ | 想要保證輸送量且延遲差異最小的客戶。 |
| 配額 | 指定模型的布建受控輸送量單位。 |
| 延遲 | 從模型限制的最大延遲。 整體延遲是呼叫圖形的因素。 |
| 使用率 | Azure 監視器中提供的布建受控使用率量值。 |
| 估計大小 | 在 Studio 和基準檢驗腳本中提供計算機。 |
如何? 取得已布建的存取權？
您必須與您的 Microsoft 銷售/帳戶小組交談，以取得布建的輸送量。 如果您沒有銷售/帳戶小組，不幸的是，目前您無法購買布建的輸送量。
哪些模型和區域可用於布建的輸送量？
| 區域 | 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 | ✅ | - | ✅ | - | ✅ | - | - |
| 波蘭central | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| southafricanorth | ✅ | ✅ | - | - | ✅ | ✅ | - |
| southcentralus | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| southindia | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| swedencentral | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| switzerlandnorth | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| switzerlandwest | - | - | - | - | - | - | ✅ |
| uksouth | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| westus | ✅ | ✅ | ✅ | - | ✅ | ✅ | ✅ |
| westus3 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
注意
布建 gpt-4的版本：turbo-2024-04-09 目前僅限於文字。
重要概念
布建的輸送量單位
布建的輸送量單位 （PTU） 是模型處理容量的單位，您可以保留和部署來處理提示併產生完成。 與每個單位相關聯的最小 PTU 部署、遞增和處理容量會因模型類型和版本而異。
部署類型
在 Azure OpenAI 中部署模型時，您必須將 設定 sku-name 為 [已布建管理]。 sku-capacity指定指派給部署的 PTU 數目。
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
配額
布建的輸送量配額代表您可以部署的特定輸送量總數。 Azure OpenAI 服務中的配額是在訂用帳戶層級管理。 訂用帳戶內的所有 Azure OpenAI 資源都會共用此配額。
配額是在布建的輸送量單位中指定，且專屬於 （部署類型、模型、區域） 三重。 配額無法互換。 這表示您無法使用 GPT-4 配額來部署 GPT-3.5-Turbo。
雖然我們會嘗試確保配額可部署，但配額並不表示基礎容量可供使用。 服務會在部署作業期間指派容量，如果容量無法使用，部署就會失敗，並發生容量不足錯誤。
判斷工作負載所需的 PTU 數目
PTU 代表模型處理容量的數量。 與您的計算機或資料庫類似，模型的不同工作負載或要求會耗用不同數量的基礎處理容量。 從呼叫圖形特性（提示大小、產生大小和呼叫速率）轉換為 PTU 是複雜且非線性的。 若要簡化此程式，您可以使用 Azure OpenAI 容量計算機 來調整特定工作負載圖形的大小。
幾個高階考慮：
- 世代需要比提示更多的容量
- 較大型的呼叫會逐漸增加計算成本。 例如，1000 個具有 1000 個令牌提示大小的 呼叫，在提示字元中需要少於 1 個具有 100,000 個令牌的呼叫。 這也表示這些呼叫圖形的分佈對於整體輸送量很重要。 包含一些非常大型呼叫的流量模式，每個 PTU 的輸送量可能會比具有相同平均提示和完成令牌大小的較窄分佈還要低。
使用率效能的運作方式
布建的部署提供您配置數量的模型處理容量，以執行指定的模型。
在 [布建管理的部署] 中，超過容量時，API 會立即傳回 429 HTTP 狀態錯誤。 這可讓用戶決定如何管理其流量。 用戶可以將要求重新導向至個別的部署、標準隨用隨付實例，或利用重試策略來管理指定的要求。 服務會繼續傳回 429 HTTP 狀態代碼，直到使用率低於 100%。
如何監視容量？
Azure 監視器中的布建受控使用率 V2 計量會以 1 分鐘的增量測量指定的部署使用率。 布建管理的部署已優化，以確保接受的呼叫是以 consis 處理 帳篷模式 l 處理時間（實際的端對端延遲取決於呼叫的特性）。
當我收到 429 回應時，該怎麼辦？
429 回應不是錯誤，而是告知使用者特定部署在某個時間點完全使用的設計的一部分。 藉由提供快速失敗的回應，您可以控制如何以最符合應用程式需求的方式處理這些情況。
retry-after-ms回應中的和 retry-after 標頭會告訴您接受下一個呼叫之前等待的時間。 選擇處理此回應的方式取決於您的應用程式需求。 以下是一些考量：
- 您可以考慮將流量重新導向至其他模型、部署或體驗。 此選項是最低的延遲解決方案，因為只要收到 429 訊號，就可以採取動作。 如需如何有效實作此模式的想法，請參閱此 社群文章。
- 如果您可以處理較長的每次呼叫延遲，請實作用戶端重試邏輯。 此選項提供每個 PTU 的最大輸送量。 Azure OpenAI 用戶端連結庫包含處理重試的內建功能。
服務如何決定何時傳送 429？
在布建受控供應專案中，每個要求都會根據其提示大小、預期的產生大小和模型個別評估，以判斷其預期的使用率。 這與隨用隨付部署形成對比，這些部署具有 根據預估流量負載的自定義速率限制行為 。 針對隨用隨付部署，如果流量未平均散發，可能會導致在超過定義的配額值之前產生 HTTP 429。
針對 Provisioned-Managed，我們會使用流失貯體演演算法的變化來維持 100% 以下的使用率，同時允許流量中的某些高載。 高階邏輯如下所示：
每位客戶都有一組容量，他們可以在部署上加以利用
提出要求時：
a. 當目前的使用率高於 100%時，服務會傳回 429 程式代碼，
retry-after-ms標頭設定為使用率低於 100% 的時間b. 否則，服務會藉由結合提示令牌和
max_tokens呼叫中指定的 ，來估計為要求提供服務所需的累加變更。max_tokens如果未指定 參數，服務會估計值。 當實際產生的令牌數目很小時，此估計可能會導致並行存取率低於預期。 針對最高的並行存取，請確定max_tokens值盡可能接近真正的產生大小。當要求完成時，我們現在知道呼叫的實際計算成本。 為了確保會計正確無誤，我們會使用下列邏輯來更正使用率：
a. 如果實際 > 估計值，則會將差異新增至部署的使用率 b。 如果實際 < 估計值，則會減去差異。
根據部署的 PTU 數目，整體使用率會以連續速率遞減。
注意
呼叫會接受，直到使用率達到100%。 在短時間內，高載可能只允許超過100%，但隨著時間推移，您的流量上限為100%。
我可以在部署上擁有多少個並行呼叫？
您可以達成的並行呼叫數目取決於每個呼叫的形狀（提示大小、max_token參數等等）。 服務會繼續接受呼叫，直到使用率達到100%。 若要判斷並行呼叫的近似數目，您可以針對容量計算機中的特定呼叫圖形，以模型化每分鐘的最大要求數。 如果系統產生少於取樣令牌數目，例如max_token，則會接受更多要求。