共用方式為


什麼是佈建的輸送量?

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

佈建的部署類型提供哪些功能?

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

Azure OpenAI 部署是特定 OpenAI 模型的管理單位。 部署可讓客戶存取模型以進行推斷,並整合更多功能,例如內容仲裁 (請參閱內容仲裁文件)。

注意

佈建的輸送量單位 (PTU) 配額與 Azure OpenAI 中的標準配額不同,且不會預設提供。 若要深入了解此供應項目,請連絡您的 Microsoft 帳戶小組。

您可得到什麼結果?

主題 已佈建
這是什麼? 提供略高於現有佈建方案的保證輸送量。 針對指定的模型版本,部署會具有一致的最大延遲。
適用對象為何? 想要讓保證輸送量具有最小延遲差異的客戶。
配額 指定模型的佈建受控輸送量單位。
延遲 模型所限制的最大延遲。 整體延遲會受到呼叫結構影響。
使用率 Azure 監視器中提供的佈建受控使用率量值。
估計大小 在工作室和效能評定指令碼中提供計算機。

如何存取佈建內容?

您必須聯繫 Microsoft 銷售/帳戶小組以取得佈建的輸送量。 如果您沒有銷售/帳戶小組,很抱歉,目前您無法購買佈建的輸送量。

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

區域 gpt-40613 gpt-41106-Preview gpt-40125-Preview gpt-4turbo-2024-04-09 gpt-4o2024-05-13 gpt-4-32k0613 gpt-35-turbo1106 gpt-35-turbo0125
australiaeast
brazilsouth - -
canadacentral - - - - -
canadaeast - - -
eastus
eastus2
francecentral - -
germanywestcentral -
japaneast - - -
koreacentral - - -
northcentralus
norwayeast - - - - -
polandcentral - -
southafricanorth - - - -
southcentralus
southindia -
swedencentral
switzerlandnorth
switzerlandwest - - - - - - -
uksouth -
westus
westus3

注意

下列佈建版本 gpt-4 版本:turbo-2024-04-09 目前僅限使用文字。

重要概念

佈建的輸送量單位

佈建的輸送量單位 (PTU) 是模型處理容量的單位,可供您保留和部署以處理提示並生成完成內容。 每個單位相關聯的最小 PTU 部署、增量和處理容量會因模型類型和版本而有所不同。

部署類型

在 Azure OpenAI 中部署模型時,您必須將 sku-name 設定為 Provisioned-Managed。 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 容量計算機來調整特定工作負載圖形的大小。

一些高階考慮事項:

  • 生成需要比提示更多的容量
  • 較大型的呼叫會逐漸增加計算成本。 例如,100 個具有 1000 個權杖提示大小的呼叫,其所需的容量會低於 1 個在提示中包含 100,000 個權杖的呼叫。 這也表示這些呼叫結構的分佈對於整體輸送量至關重要。 若採用包含一些非常大型呼叫的廣泛分布流量模式,則每個 PTU 的輸送量可能會低於具有相同平均提示和完成權杖大小的較窄分佈。

使用率效能的運作方式

佈建的部署為您提供已配置的模型處理容量,用於執行指定的模型。

在 Provisioned-Managed 部署中,當超過容量時,API 會立即傳回 429 HTTP 狀態錯誤。 這可讓使用者決定如何管理其流量。 使用者可以將要求重新導向至個別的部署、標準隨用隨付執行個體,或利用重試策略來管理指定的要求。 服務會持續傳回 429 HTTP 狀態代碼,直到使用率低於 100%。

如何監視容量?

Azure 監視器中的 Provisioned-Managed Utilization V2 計量 (部分機器翻譯) 會以 1 分鐘的增量來測量指定的部署使用率。 Provisioned-Managed 部署已最佳化,確保接受的呼叫會以一致的模型處理時間進行處理 (實際的端對端延遲取決於呼叫的特性)。

當我收到 429 回應時,該怎麼辦?

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

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

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

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

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

針對 Provisioned-Managed,我們會使用漏桶 (leaky bucket) 演算法的變體將使用率維持在 100% 以下,同時允許流量中的某些高負載。 高階邏輯如下所示:

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

  2. 提出要求時:

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

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

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

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

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

注意

在使用率達到 100% 之前會持續接受呼叫。 高載可能只會在短時間內允許超過 100%,但您的流量使用率會逐步回到 100% 上限。

圖表:顯示後續呼叫如何讓使用率上升。

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

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

下一步