效能和延遲

發行項
11/23/2024

本文提供關於 Azure OpenAI 延遲和輸送量的運作方式，以及如何最佳化您的環境以改善效能的背景資訊。

了解輸送量與延遲

調整應用程式大小時有兩個重要概念：（1）以每分鐘令牌測量的系統層級輸送量（TPM）和（2）每個呼叫回應時間（也稱為延遲）。

系統層級輸送量

這會查看部署的整體容量 – 每分鐘的要求數目和可處理的權杖總數。

對於標準部署，您可以達成的輸送量有部分取決於指派給部署的配額。不過，配額只會決定對部署呼叫的許可邏輯，而不會直接強制執行輸送量。由於個別呼叫的延遲不盡相同，您可能無法達到與配額一樣高的輸送量。深入了解如何管理配額。

在布建的部署中，會配置一組模型處理容量給您的端點。您可以在端點上達成的輸送量是工作負載圖形的一個因素，包括輸入令牌數量、輸出量、呼叫速率和快取比對率。並行呼叫數目和已處理的權杖總數可能會根據這些值而有所不同。

對於所有部署類型，了解系統層級輸送量是優化效能的關鍵元件。請務必考慮給定模型、版本和工作負載組合的系統層級輸送量，因為輸送量會因這些因素而有所不同。

估計系統層級輸送量

使用 Azure 監視器計量估計 TPM

評估指定工作負載系統層級輸送量的其中一種方法是使用歷程記錄令牌使用量數據。針對 Azure OpenAI 工作負載，您可以使用 Azure OpenAI 內提供的原生監視功能來存取和可視化所有歷程記錄使用量數據。需要兩個計量來估計 Azure OpenAI 工作負載的系統層級輸送量：（1）已處理的提示令牌和（2） 產生的完成令牌。

結合時，已處理的提示令牌（輸入 TPM）和產生的完成令牌 （輸出 TPM）計量會根據實際工作負載流量提供系統層級輸送量的估計檢視。此方法不會考慮提示快取的優點，因此會是保守的系統輸送量估計值。您可以使用跨多周時間範圍超過 1 分鐘時段的最小、平均值和最大匯總來分析這些計量。建議您在多周的時間範圍內分析此數據，以確保有足夠的數據點可供評估。下列螢幕快照顯示 Azure 監視器中可視化的已處理提示令牌計量範例，此計量可直接透過 Azure 入口網站取得。

Azure 監視器圖表的螢幕快照，其中顯示依模型和版本分割的已處理提示令牌計量。

從要求數據估計 TPM

估計系統層級輸送量的第二種方法涉及從 API 要求數據收集令牌使用資訊。此方法提供更細微的方法，可瞭解每個要求的工作負載圖形。結合每個要求令牌使用量資訊與要求磁碟區，以每分鐘的要求量計算（RPM），可提供系統層級輸送量的估計值。請務必注意，針對跨要求和要求磁碟區之令牌使用資訊一致性所做的任何假設都會影響系統輸送量估計。您可以在指定 Azure OpenAI 服務聊天完成要求的 API 回應詳細資料中找到令牌使用量輸出數據。

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [...],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

假設指定工作負載的所有要求都是統一的，API 回應數據的提示令牌和完成令牌可以乘以估計的 RPM，以識別指定工作負載的輸入和輸出 TPM。

如何使用系統層級輸送量估計值

一旦針對指定的工作負載估計系統層級輸送量，這些估計值可用來調整標準部署和布建部署的大小。針對標準部署，可以合併輸入和輸出 TPM 值，以估計指派給指定部署的 TPM 總數。針對布建的部署，可以使用要求令牌使用量數據或輸入和輸出 TPM 值來估計支援具有部署容量計算機體驗之指定工作負載所需的 PTU 數目。

以下是 GPT-4o 迷你模型的一些範例：

提示大小 (權杖)	產生大小 (權杖)	每分鐘要求	輸入 TPM	輸出 TPM	TPM 總計	所需的 PTU
800	150	30	24,000	4,500	28,500	15
5,000	50	1,000	5,000,000	50,000	5,050,000	140
1,000	300	500	500,000	150,000	650,000	30

當工作負載分佈維持不變時，PTU 數目會以線性方式隨著呼叫速率進行調整。

延遲：個別呼叫的回應時間

在此內容中，延遲的高階定義是從模型取得回應所需的時間量。對於完成和聊天完成要求，延遲主要取決於模型類型、提示中的權杖數目，以及產生的權杖數目。一般而言，相較於每個產生的增量權杖，每個提示權杖只會增加很少的時間。

使用這些模型可能難以估計您預期的個別呼叫延遲。完成要求的延遲可能隨著四項主要因素而有所不同：(1) 模型、(2) 提示中的權杖數目、(3) 產生的權杖數目，以及 (4) 部署和系統的整體負載。 (1) 和 (3) 往往是總時間的主要佔比來源。下一節會進一步詳細說明大型語言模型推斷呼叫的結構。

改善效能

您可以控制幾項因素，以改善應用程式的個別呼叫延遲。

模型選取

延遲會隨著您使用的模型而有所不同。對於相同的要求，不同的模型在處理聊天完成呼叫時應該會有不同的延遲。如果您的使用案例需要回應時間最快的最低延遲模型，建議您使用最新的 GPT-4o 迷你模型 (英文)。

產生大小和權杖上限

當您將完成要求傳送至 Azure OpenAI 端點時，輸入文字會轉換為權杖，然後傳送至已部署的模型。模型會接收輸入權杖，然後開始產生回應。這是反覆的循序程序，一次處理一個權杖。另一種理解方式是將其視為 n tokens = n iterations 的 for 迴圈。就多數模型而言，產生回應是程序中最費時的步驟。

提出要求時，要求的產生大小 (max_tokens 參數) 會作為產生大小的初始估計值。在處理要求時，模型會保留產生完整大小的計算時間。產生完成後，剩餘的配額就會釋出。減少權杖數目的方式：

將每個呼叫的 max_tokens 參數盡可能設定得較小。
包含停止序列，以防止產生額外的內容。
產生較少回應：best_of 和 n 參數會產生多個輸出，因此可能會大幅增加延遲。若要有最快的回應，請不要指定這些值，或將其設定為 1。

簡言之，減少每個要求產生的權杖數目，即可縮短每個要求的延遲。

串流

在要求中設定 stream: true，可讓服務在權杖可供使用時隨即將其傳回，而不是等到完整的權杖序列產生時才傳回。這並不會改變取得所有權杖的時間，但可加快首次回應的時間。此方法可提供較理想的使用者體驗，因為終端使用者可在回應產生時隨即讀取。

串流對於需要長時間處理的大型呼叫也很有用。許多用戶端和中繼層的個別呼叫都會逾時。長時間的產生呼叫可能因用戶端逾時而取消。將資料串流回去，可確保會收到增量資料。

適合使用串流時的範例：

聊天機器人和交談介面。

串流會影響感知到的延遲。串流啟用後，只要權杖可供使用，就會以區塊的形式傳回。對終端使用者而言，此方法常會使人感覺模型的回應速度變快了，即使完成要求的整體時間保持不變。

串流沒那麼重要時的範例：

情感分析、語言翻譯、內容產生。

在許多使用案例中，您執行在某些大量工作只會關心完成的結果，而不關心即時回應。如果串流停用，在模型完成整個回應之前，您將不會收到任何權杖。

內容篩選

Azure OpenAI 包含可搭配核心模型執行的內容篩選系統。此系統的運作方式是透過旨在偵測並防止有害內容輸出的一組分類模型來執行提示和完成。

內容篩選系統會偵測並針對輸入提示和輸出完成中的特定類別的潛在有害內容採取動作。

新增內容篩選可提高安全性，但也會增加延遲。在許多應用程式中，這種效能權衡都是必要的，但在某些風險較低的使用案例中，仍可嘗試停用內容篩選以提升效能。

深入了解如何要求對預設的內容篩選原則進行修改。

區隔工作負載

在相同端點上混合不同的工作負載，可能會對延遲造成負面影響。這是因為 (1) 這些工作負載在推斷期間分在同一批次，而較短的呼叫可能需等待較長的完成，以及 (2) 混合呼叫可能會降低快取命中率，因為它們會競爭相同的空間。可能的話，建議為每個工作負載進行個別部署。

提示大小

雖然提示大小對延遲的影響低於產生大小，但仍會影響整體時間，特別是在大小增長時。

批次處理

如果您要將多個要求傳送至相同端點，可以將要求批次處理到單一呼叫中。這樣可以減少您需要提出的要求數目，並且可能改善整體回應時間 (視案例而定)。建議您測試此方法，看看是否有幫助。

如何測量輸送量

建議您使用兩個量值來測量部署的整體輸送量：

每分鐘呼叫數：您每分鐘進行的 API 推斷呼叫數目。在 Azure 監視器中使用 Azure OpenAI Requests 計量，並依 ModelDeploymentName 進行分割，即可測量此值
每分鐘權杖總數：您的部署每分鐘處理的權杖總數。其中包括提示和產生的權杖。這通常會進一步細分為兩者皆測量，以期能更深入地了解部署效能。此值可在 Azure 監視器中使用已處理的推斷權杖計量來測量。

您可以深入了解如何監視 Azure OpenAI 服務。

如何測量個別呼叫延遲

每個呼叫所需的時間，取決於讀取模型、產生輸出以及套用內容篩選所需的時間。無論您是否使用串流，測量時間的方式都會有所不同。建議您為每個案例使用不同組的量值。