什麼是佈建的輸送量?
佈建的輸送量功能可讓您指定部署中所需的輸送量。 服務接著會配置必要的模型處理容量,並確認可供您使用。 輸送量會以佈建的輸送量單位 (PTU) 定義,這是表示部署輸送量的標準化方式。 每個模型與版本組都需要部署不同的 PTU 數量,並為每個 PTU 提供不同的輸送量。
佈建的部署類型提供哪些功能?
- 可預測的效能:穩定統一工作負載的最大延遲和輸送量。
- 保留的處理容量:部署會設定輸送量。 部署之後,不論是否使用,都會提供該輸送量。
- 節省成本:高輸送量工作負載有機會節省成本 (相較於權杖型使用量)。
Azure OpenAI 部署是特定 OpenAI 模型的管理單位。 部署可讓客戶存取模型以進行推斷,並整合更多功能,例如內容仲裁 (請參閱內容仲裁文件)。
注意
佈建的輸送量單位 (PTU) 配額與 Azure OpenAI 中的標準配額不同,且不會預設提供。 若要深入了解此供應項目,請連絡您的 Microsoft 帳戶小組。
您可得到什麼結果?
主題 | 已佈建 |
---|---|
這是什麼? | 提供略高於現有佈建方案的保證輸送量。 針對指定的模型版本,部署會具有一致的最大延遲。 |
適用對象為何? | 想要讓保證輸送量具有最小延遲差異的客戶。 |
配額 | 指定模型的佈建受控輸送量單位。 |
延遲 | 模型所限制的最大延遲。 整體延遲會受到呼叫結構影響。 |
使用率 | Azure 監視器中提供的佈建受控使用率量值。 |
估計大小 | 在工作室和效能評定指令碼中提供計算機。 |
如何存取佈建內容?
您必須聯繫 Microsoft 銷售/帳戶小組以取得佈建的輸送量。 如果您沒有銷售/帳戶小組,很抱歉,目前您無法購買佈建的輸送量。
哪些模型和區域有提供佈建的輸送量?
區域 | gpt-4,0613 | gpt-4,1106-Preview | gpt-4,0125-Preview | gpt-4,turbo-2024-04-09 | gpt-4o,2024-05-13 | 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 | - | - | - | - | - | - | - | ✅ |
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-ms
和 retry-after
標頭,用於告知接受下一個呼叫之前須等待的時間。 要如何處理此回應取決於您的應用程式需求。 以下是一些考量:
- 您可以考慮將流量重新導向至其他模型、部署或體驗。 此選項是最低延遲解決方案,因為只要收到 429 訊號就可以採取此動作。 如需有效實作此模式的想法,請參閱這篇社群文章 (英文)。
- 如果您能夠接受較長的每次呼叫延遲,請實作使用者端重試邏輯。 此選項可讓您達到每個 PTU 的最大輸送量。 Azure OpenAI 使用者端程式庫包含處理重試的內建功能。
服務如何決定傳送 429 的時機?
在 Provisioned-Managed 供應項目中,每個要求都會根據其提示大小、預期的生成大小,以及模型個別評估來判斷其預期的使用率。 這與隨用隨付部署正好相反,後者具有根據預估流量負載的自訂速率限制行為。 針對隨用隨付部署,如果流量未平均分散,可能會導致在超過定義的配額值之前就產生 HTTP 429。
針對 Provisioned-Managed,我們會使用漏桶 (leaky bucket) 演算法的變體將使用率維持在 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),則會接受更多要求。
下一步
- 了解已佈建部署的上線步驟 (部分機器翻譯)
- 佈建的輸送量單位 (PTU) 使用者入門指南
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應