什麼是佈建的輸送量？

佈建的輸送量功能可讓您指定部署中所需的輸送量。 服務接著會配置必要的模型處理容量，並確認可供您使用。 輸送量會以佈建的輸送量單位 (PTU) 定義，這是表示部署輸送量的標準化方式。 每個模型與版本組都需要部署不同的 PTU 數量，並為每個 PTU 提供不同的輸送量。

佈建和全域佈建的部署類型提供什麼？

• 可預測的效能：穩定統一工作負載的最大延遲和輸送量。
• 保留的處理容量：部署會設定輸送量。 部署之後，不論是否使用，都會提供該輸送量。
• 節省成本：高輸送量工作負載有機會節省成本 (相較於權杖型使用量)。

Azure OpenAI 部署是特定 OpenAI 模型的管理單位。 部署可讓客戶存取模型以進行推斷，並整合更多功能，例如內容仲裁 (請參閱內容仲裁文件)。 全域部署可在與非全域部署類型相同的 Azure OpenAI 資源中使用，但可讓您利用 Azure 的全域基礎結構，以動態方式將流量路由傳送至資料中心，並針對每個要求提供最佳可用性。

您可得到什麼結果？

每個模型每個 PTU 的輸出量

每個 PTU 取得的輸送量量（每分鐘或 TPM 的令牌數）是分鐘內輸入和輸出令牌的函式。 產生輸出令牌需要比輸入令牌更多的處理，因此產生整體 TPM 的輸出令牌越多。 服務會動態平衡輸入和輸出成本，因此使用者不需要設定特定的輸入和輸出限制。 這種方法表示您的部署可復原工作負載圖形中的波動。

為了協助簡化重設大小工作，下表概述 和 gpt-4o-mini 模型的 TPM 每個 PTU gpt-4o

** 如需完整清單， 請參閱 AOAI Studio calcualator

重要概念

部署類型

在 Azure OpenAI Studio 中建立佈建的部署時，[建立部署] 對話方塊上的部署類型為「佈建受控」。 在 Azure OpenAI Studio 中建立全域佈建的受控部署時，[建立部署] 對話方塊上的部署類型為「全域佈建受控」。

透過 CLI 或 API 在 Azure OpenAI 中建立佈建的部署時，您必須將 sku-name 設定為 ProvisionedManaged。 透過 CLI 或 API 在 Azure OpenAI 中建立全域佈建的部署時，您必須將 sku-name 設定為 GlobalProvisionedManaged。 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 

配額

佈建的輸送量單位

佈建的輸送量單位 (PTU) 是模型處理容量的一般單位，可用來調整佈建部署的大小，以達到處理提示和產生完成所需的輸送量。 布建的輸送量單位會以配額的形式授與訂用帳戶。 每個配額都專屬於某個區域，並定義可指派給該訂用帳戶和區域中部署的 PTU 數目上限。

模型獨立配額

不同於其他 Azure OpenAI 供應項目所使用的每分鐘權杖 (TPM) 配額，PTU 與模型無關。 PTU 可用來在區域中部署任何支援的模型/版本。

針對佈建的部署，新的配額會在 Azure OpenAI Studio 中顯示為名為佈建受控輸送量單位的配額項目。 針對全域佈建的受控部署，新的配額會在 Azure OpenAI Studio 中，顯示為名為全域佈建受控輸送量單位的配額項目。 在 [Studio 配額] 窗格中，展開配額專案會顯示導致每個配額使用量的部署。

取得 PTU 配額

PTU 配額預設可在許多區域中取得。 如果需要更多配額，客戶可以透過 [要求配額] 連結來要求配額。 您可以在 Azure OpenAI Studio 中布建的受控輸送量單位或全域布建的受控輸送量單位配額索引卷標右側找到此連結。 該表單可讓客戶要求增加指定區域的指定 PTU 配額。 一旦核准要求，客戶就會在內含位址收到電子郵件，通常是在兩個工作天內。

每一模型 PTU 最小值

每個單位相關聯的最小 PTU 部署、增量和處理容量會因模型類型和版本而有所不同。

容量透明度

Azure OpenAI 是一項熱門服務，其客戶需求可能會超過服務 GPU 容量。 Microsoft 努力為所有需求區域和模型提供容量，但總是有可能在某個區域銷售一空。 此條件約束可以限制某些客戶在所需區域中建立所需模型、版本或 PTU 數目的部署能力，即使該區域有可用的配額也一樣。 一般來說：

• 配額會限制可在訂用帳戶和區域中部署的最大 PTU 數目，且不保證容量可用性。
• 容量會在部署時配置，只要部署存在，就會保留容量。 如果沒有服務容量，部署將會失敗
• 客戶會使用配額/容量可用性的即時資訊，為具有必要模型容量的案例選擇適當的區域
• 縮小或刪除部署會將容量釋放回區域中。 但如果之後擴大或重新建立部署，則無法保證容量可供使用。

區域容量指引

若要尋找其部署所需的容量，請使用容量 API 或 Studio 部署體驗來提供容量可用性的實時資訊。

在 Azure OpenAI Studio 中，部署體驗會識別區域何時缺少部署模型所需的容量。 這會查看所需的模型、版本和 PTU 數目。 如果無法使用 cpacity，體驗會將用戶導向至選取替代區域。

如需新部署體驗的詳細資料，請參閱 Azure OpenAI 佈建入門指南。

新的 模型容量 API 可用來以程式設計方式識別指定模型的大小上限部署。 API 會考慮區域中的配額和服務容量。

如果可接受的區域無法支援所需的模型、版本和/或 PTU，客戶也可以嘗試下列步驟：

• 嘗試使用較少的 PTU 數量進行部署。
• 嘗試在不同的時間部署。 容量可用性會根據客戶需求動態變更，之後可能會有更多容量可供使用。
• 確定所有可接受的區域都有可用的配額。 模型容量 API 和 Studio 體驗會 在傳回替代區域以建立部署時考慮配額可用性。

判斷工作負載所需的 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 分鐘的增量來測量指定的部署使用率。 佈建受控和和全域佈建受控部署已最佳化，確保接受的呼叫會以一致的模型處理時間進行處理 (實際的端對端延遲取決於呼叫的特性)。

當我收到 429 回應時，該怎麼辦？

429 回應不是錯誤，而是告知使用者特定部署在某個時間點使用率滿載的一種設計。 藉由提供快速失敗的回應，您可以透過最符合應用程式需求的方式，控制這些情況的處理方式。

回應包含 retry-after-ms 和 retry-after 標頭，用於告知接受下一個呼叫之前須等待的時間。 要如何處理此回應取決於您的應用程式需求。 以下是一些考量：

• 您可以考慮將流量重新導向至其他模型、部署或體驗。 此選項是最低延遲解決方案，因為只要收到 429 訊號就可以採取此動作。 如需有效實作此模式的想法，請參閱這篇社群文章 (英文)。
• 如果您能夠接受較長的每次呼叫延遲，請實作使用者端重試邏輯。 此選項可讓您達到每個 PTU 的最大輸送量。 Azure OpenAI 使用者端程式庫包含處理重試的內建功能。

服務如何決定傳送 429 的時機？

在佈建受控和和全域佈建受控供應項目中，每個要求都會根據其提示大小、預期的生成大小，以及模型個別評估來判斷其預期的使用率。 這與隨用隨付部署正好相反，後者具有根據預估流量負載的自訂速率限制行為。 針對隨用隨付部署，如果流量未平均分散，可能會導致在超過定義的配額值之前就產生 HTTP 429 錯誤。

針對佈建受控和和全域佈建受控，我們會使用漏桶 (leaky bucket) 演算法的變體將使用率維持在 100% 以下，同時允許流量中的某些高負載。 高階邏輯如下所示：

1. 每位客戶都有一組可在部署上使用的容量

2. 提出要求時：

   a. 如果目前的使用率高於 100%，服務會傳回 429 代碼，retry-after-ms 標頭設定為使用率降至 100% 以下所需的時間

   b. 否則，服務會藉由結合提示權杖和呼叫中指定的 max_tokens ，估計為要求提供服務所需的增量變更。 max_tokens如果未指定 參數，服務會估計值。 當實際產生的權杖數目很小時，此估計可能會導致並行存取率低於預期。 若想達到最高的並行存取，請確保 max_tokens 值盡可能接近真正的產生大小。

3. 當要求完成時，現在我們知道呼叫的實際計算成本。 為了確保準確的計量，我們會使用下列邏輯來更正使用率：

   a. 如果實際值 > 估計值，則會將差異值新增至部署的使用率 b. 如果實際值 < 估計值，則會減去差異值。

4. 整體使用率會根據部署的 PTU 數目，以連續速率遞減。

我可以在部署上擁有多少個並行呼叫？

您可以達成的並行呼叫數目取決於每個呼叫的結構 (提示大小、max_token 參數等等)。 服務會繼續接受呼叫，直到使用率達到100%。 若要判斷並行呼叫的近似數目，您可以在容量計算機中針對特定呼叫圖形，計算每分鐘要求數上限。 如果系統生成少於取樣權杖數目 (例如 max_token)，則會接受更多要求。

哪些模型和區域有提供佈建的輸送量？

下一步

• 了解已佈建部署的上線步驟 (部分機器翻譯)
• 佈建的輸送量單位 (PTU) 使用者入門指南