優化 Azure AI 搜尋服務 中無伺服器定價模型的成本

Azure AI 搜尋服務 支援兩種定價模式，各自針對不同的工作負載模式設計：

• 專用：按搜尋單位（SU）計算的固定價格。 您會選取服務層，並根據佈建單位按小時計費。

• 無伺服器（預覽）：採隨用隨付定價，依每小時的計算單位（CU/hr）以及已建立索引的儲存空間每 GB/月計費。

欲了解更多關於定價模式與服務層級差異的資訊，請參閱 「選擇定價模式與服務層級」。

無伺服器模型中成本的決定方式

專用與無伺服器定價模式對搜尋服務內的工作有不同考量。 專用服務會對你已購買的配置容量執行查詢、索引和結果處理。 無伺服器服務會測量這些操作所消耗的運算、記憶體和磁碟 I/O，並將這些使用量轉換為運算單元（CU）。 因此， 效能優化直接影響無伺服器成本。

無伺服器成本取決於工作負載的執行：

• 查詢與索引會消耗計算量，計算單位為每小時計算單位（CU/h）。
• 活躍索引會根據其資源使用量及持續運作時間來消耗運算資源。
• 索引在最後一次查詢或索引請求後會保持活躍 10 分鐘，之後才會進入非活躍狀態。
• 非使用中索引沒有最低或預留計算費用。 非活躍索引的計算使用量會逐漸歸零。 當索引處於非啟用狀態時，沒有最低計算費限制。
• 儲存會根據磁碟上的索引大小分開計費，無論是否有索引在使用中，儲存都會持續運作。
• 自主式檢索會為搜尋查詢以及在搜尋服務內執行的協調流程消耗運算資源。

儲存費用只有在你刪除索引時才會停止。

要查看您目前計費週期的成本細分與使用率，請在 Azure 入口網站的「Scale + Cost」分頁查看。

索引大小如何影響運算使用率

當索引處於啟用狀態時，Azure AI 搜尋服務 會評估兩個有限資源以判斷其計算使用情況：

• 總索引大小：索引在磁碟上所佔用的總空間，包括文字、元資料和向量。
• 向量索引大小： 向量索引所使用的記憶體。 記憶體比磁碟更耗資源，因此向量索引大小轉換成 CU 時權重較高。

Azure AI 搜尋服務 不會把兩個 CU 總數相加。 運算使用量依據較高的金額來計算。 例如，即使磁碟上的總索引大小相對較小，向量索引大小仍能決定計算使用量。

為了減少作用中索引的運算用量，請找出哪個資源產生較高的 CU 用量。 然後減少總索引大小、向量指數大小，或兩者皆減。 索引儲存仍是按 GB 每月獨立收費。

無伺服器定價模式對於流量變動、間歇性或不可預測的工作負載最具成本效益，因為在這種情況下，預先佈建的容量可能無法被充分利用。

了解計算單元（CU）

計算單元（CU）代表在無伺服器模型中執行搜尋與索引操作所需的系統資源。 CU 成本主要由 CPU、記憶體與 IO 利用率驅動，其次則由索引大小與文件有效載荷大小決定，使用量以每小時運算單位（CU/h）計費。

計算成本會隨以下項目調整：

• 查詢複雜度
• 指數規模（GB）與結構
• 文件有效載荷大小（KB）
• 欄位數量與檢索結果

不同營運的成本輪廓不同：

• 查詢：成本低。 依照 ID 檢索單一文件是最有效率的操作。
• 關鍵字搜尋：低成本。 文字搜尋使用反向索引，並針對速度與低運算資源使用量進行最佳化。
• 向量搜尋：高成本。 向量查詢計算成本高，因為它們需要跨高維嵌入進行相似度計算。 與關鍵字搜尋相比，它們消耗的運算量顯著增加。
• 混合式搜尋：結合關鍵字和向量搜尋的成本，因為每個查詢都會執行這兩個管線，另加 Reciprocal Rank Fusion (RRF) 用於合併結果的少量額外負荷。

監控運算使用情況

監控運算消耗有助於你識別昂貴的操作、優化查詢模式並估算成本。 每個請求的運算單元（CU）成本會以浮點數的形式在 x-ms-azs-compute-units-consumed HTTP 回應標頭中回傳。 使用此標頭來識別昂貴操作並優化查詢模式。 你可以透過檢查 Azure 監視器 中的 HTTP 回應標頭和操作事件來追蹤每個請求的 CU 成本。 欲了解更多關於可用監控資料類型及分析方法的指引，請參閱「監控 Azure AI 搜尋服務」。

• 標頭：x-ms-azs-compute-units-consumed: <value>
• 值：一個浮點數，代表所消耗的 CU。

範例：

Status: 200 OK
Content-Type: application/json
x-ms-azs-compute-units-consumed: 12.45

在此範例中，請求消耗了 12.45 個運算單元。 你可以利用這個值來辨識高成本操作，並比較不同查詢模式的相對成本。

要檢視無伺服器搜尋服務的歷史計算消耗，請使用 Azure 入口網站中的 Azure 監視器 指標：

1. 前往您的搜尋服務。
2. 選取 [計量]。
3. 選擇 + 新增指標。
4. 從指標清單中，選擇 計算單位使用量。
5. 利用圖表分析使用趨勢，並找出計算量增加的時期。

監控整體使用情況有助於你了解整體服務成本，並找出消耗最多運算資源的工作負載。 有關可用監測指標的說明，請參見 監測資料參考。 你可以使用 Azure 監視器 日誌追蹤累積的 CU 使用情況，並與查詢量和工作負載變化做關聯。

設定計算使用警報

你可以在 Azure 入口網站建立警示規則，當運算消耗達到指定門檻時收到通知。

1. 請前往搜尋服務中的 警示 。
2. 選取 + 建立警示規則。
3. 在 條件中，選擇 「計算單位使用量 」作為訊號。
4. 定義警報邏輯。 例如，當總使用量超過指定值時觸發。
5. 設定 動作，例如電子郵件、簡訊或 webhook 通知。
6. 完成剩餘步驟後，選擇 檢視 + 建立。

警示幫助你主動應對突發的使用量激增並管理成本。

估計無伺服器成本

Azure 價格計算器與基於搜尋單元（SU）的容量規劃指引不適用於使用無伺服器定價模型的服務。

估算無伺服器成本：

1. 索引代表性樣本資料。
2. 執行典型的索引和查詢工作負載。
3. 記錄 x-ms-azs-compute-units-consumed 每個操作回傳的值。
4. 使用 Azure 監視器 指標來衡量隨時間的總體使用情況。
5. 根據預期的生產流量推算成本。

使用 Azure 入口網站的 Scale + Cost 標籤，查看目前的使用量並估算成本。

由於同一請求對相同資料執行通常產生相似的計算消耗，代表性工作負載能提供可靠的成本估算基礎。

無伺服器使用量會持續測量並彙總以計費。 運算用量會在每分鐘內持續追蹤，且僅在使用運算資源時才會記錄。

在估算成本時，使用請求收費值來了解個別營運的成本，並用 Azure 監視器 指標來了解整體服務消耗模式。

同時使用兩個資料來源來了解成本：按請求收費資料幫助你評估個別營運，而 Azure 監視器 指標則幫助你了解服務總量隨時間的變化。 為了完整成本狀況，也應考慮那些與計算單元分開計費的功能。

計費是根據總體運算使用量，而非個別請求。 使用量以一分鐘為間隔計量，並向上取整至每分鐘最接近的 0.25 CU。 這些一分鐘的使用間隔會在一小時內累積，以決定可計費的每小時CU金額。 在內部，系統會將用量從毫運算單位（mCU）彙總為運算單位（CU），並換算為用於計費報告的每小時用量。

不同的運算消耗的運算量也不同。 通常：

• 關鍵字搜尋通常使用最少的運算資源。
• 向量搜尋通常比關鍵字搜尋消耗更多運算資源。
• 混合式搜尋結合關鍵字與向量搜尋執行，因此通常比單一技術使用更多的運算資源。

實際計算消耗取決於查詢複雜度、索引大小、資料量、向量配置及回傳結果數量等因素。 監控請求費用與總體使用指標，有助於您識別優化機會，並更準確預測生產成本。

透過優化降低計算成本

高效的查詢與索引設計降低運算消耗並降低成本。

最佳化您的結構描述

你的索引結構決定基線運算與儲存成本：

• 限制欄位屬性：僅在必要時啟用屬性（可搜尋、可篩選、面表、可排序）。 每個屬性都會增加索引大小與索引成本。
• 扁平化複雜型別：盡可能將巢狀的 JSON 結構映射到簡單的欄位或集合。
• 僅篩選或僅排序欄位請設定 retrievable=false：若某欄位用於篩選或排序，但不需要在結果中回傳，請保持該欄位索引並設定 retrievable=false 以降低磁碟儲存空間及每 GB/月儲存成本。
• 盡可能使用僅可檢索的欄位：例如，僅用於顯示的欄位（如圖片網址）不應被搜尋。
• 減少向量維度：高維向量會增加儲存與查詢成本。 適當時使用較小的嵌入模型或量化。
• 在索引前盡量減少文件有效載荷大小：較大的文件編索引成本越高。 在將文件送入索引前，移除不必要的欄位、裁剪長文字並剔除 HTML。

優化索引請求

你如何將資料傳送到索引，會影響成本與吞吐量：

• 盡可能使用較大的批次：批次索引可將網路與處理成本分攤到更多文件上，從而降低每次請求的開銷。 一般而言，最多 ~1,000 份文件或 ~16 MB 的批次比許多小型請求更具 CU 效率。 不過，最佳批次大小取決於你的工作量。 測試以平衡吞吐量、延遲和可靠性。

• 僅索引新資料或變更資料：盡量避免全面重新索引。 僅傳送新增與更新可減少處理的文件數量，降低計算成本並提升擷取速度。

• 除非需要，否則跳過影像擷取：影像擷取會增加額外的處理工作，且可能成為另一個成本驅動因素。 只在需要圖片內容的文件或工作流程時開啟。

• 考慮指數規模的成長：盡可能建立較小的指數。 隨著索引成長，索引成本增加，因為必須儲存和維護更多資料，且操作需要更多運算。 對於非常龐大的資料集，可以考慮將資料分割到多個索引，以協助管理效能與成本。 雖然成本隨指數規模增加，但其增長是次線性的。 較大的指數每次操作成本較高，但不會成比例增加。

更多指導請參見提升Azure AI 搜尋服務表現技巧。

優化索引器操作

無伺服器索引器的運算使用量取決於每次索引器執行時所做的工作量。 對於資料列導向的來源，請以處理的文件數量作為工作負載量的指標。 對於像 Azure Blob 儲存體 和 Azure Data Lake Storage Gen2 這類檔案來源，請監控處理的來源資料量。 實際運算使用量也取決於文件有效載荷、索引結構、豐富化及執行過程中的其他處理。

為了減少索引器的運算使用：

• 使用變更偵測與增量索引：只處理新資料或變更資料，而非反覆索引完整資料來源。

• 合適大小的索引器排程：選擇符合你資料新鮮度需求的排程。 使用計算單元遙測來評估排程頻率的影響。

• 減少不必要的文件內容：移除不需要索引的內容，並排除不必要的檔案或檔案類型。

• 審慎界定擴充技能的範圍：僅對需要擴充的欄位和文件執行技能，並避免產生下游不會使用的輸出。 可計費的技能可能會產生獨立的交易費用。

• 監控失敗和重複的執行：索引子在發生失敗之前完成的工作可能會消耗計算資源。 檢視執行歷史與運算單元使用情況，以識別反覆失敗及重試模式。

優化你的查詢

查詢設計是變動成本的主要驅動因素：

• 用於 $select 限制回傳欄位：此方法可減少序列化所需的有效載荷大小與計算量。

  GET /docs?search=test&$select=id,title,url
  

• 使用 searchFields 限制搜尋文字的範圍：將查詢時的比對限制在與該情境相關的重要欄位。 每增加一個可搜尋欄位，查詢工作量增加，並可能增加 CU/h。

• 偏好精確匹配或簡單關鍵字查詢：模糊、通配字、正則表達式及前綴式查詢會強制廣泛掃描索引，並大幅消耗更多 CU/h。 只有在需要部分匹配行為時才使用，並盡可能選擇精確匹配或較簡單的關鍵字查詢。

• 盡可能使用查詢取代搜尋：依 ID 檢索文件比執行搜尋查詢更有效率。 如果你知道文件 ID，請使用查找，而不要使用搜尋查詢。 查詢更有效率，因為它們直接以鍵檢索文件，而搜尋查詢則會啟動完整的查詢流程（解析、索引遍歷、評分與排名），這會增加計算成本。

• 避免深度分頁$skip（）：值越大 $skip ，計算量越大，因為引擎必須處理、評分並排序請求頁面前的結果。 例如，需要 $skip=5000 引擎處理至少 5,000 筆未回傳的結果。 此選擇會消耗額外的運算單元（CU），並可能增加成本。 相反地，請使用篩選器縮小結果 set 範圍並 $top 限制回傳的結果數量。 將 $top 調整為適合您的應用程式或使用者介面的大小。 雖然 $top 不會改變評分的匹配文件數量，但較小的數值會減少需要收集、排序和序列化的結果數量。 請只請求應用程式所需的結果數量，並避免需要引擎處理大量未使用結果的分頁模式。

• 減少面數與面範圍：只請求介面中顯示的面，並盡量保持每個面 count 值最低。 分面需要針對每次查詢執行聚合，而數量過高會增加運算成本。

• 用於 search.in 篩選：當以 ID 或值列表篩選時，請使用 該 search.in 函數而非多個 or 條件（例如 id eq '1' or id eq '2'）。 此方法更有效率，並降低計算負擔。 您也應該避免將高基數欄位 (具有大量唯一值的欄位，例如唯一 ID 或自由文字描述) 標示為可篩選或可 Facet，除非必要，因為這會增加索引大小和查詢成本。

最佳化您的管理要求

除了查詢與索引操作外，Azure AI 搜尋服務 還包含物件層級及服務層級的管理操作（例如擷取索引結構或服務統計資料）。 這些請求的每次請求費用是固定的。 雖然每個請求成本低廉，但重複或不必要的呼叫會隨時間累積，並增加整體運算使用量。

• 避免過多的管理要求：請在用戶端快取中繼資料（例如索引結構描述），而不是反覆擷取這些資料。 例如，在每次寫入操作前擷取索引結構會產生不必要的成本。 在無伺服器模型中，此模式會直接增加計算費用；而在 Dedicated 服務中，固定小時計費通常會隱藏其影響。

優化向量成本

向量工作負載通常是無伺服器定價模型中成本最高的部分，因為它們同時影響計算單元（查詢與索引）及儲存空間（磁碟上的向量大小）。 為了降低成本，優化向量的儲存方式和查詢方式。

優化向量儲存與結構

向量場能顯著增加索引大小與索引成本。 請使用以下技術來降低儲存開銷：

• 利用壓縮來減少向量大小：應用量化以減少儲存佔用，且對相關性的影響最小。 例如，純量量化可將向量儲存量減少多達4×且對搜尋品質影響極小。

• 不需要時停用向量儲存：如果你只需要搜尋向量而非檢索，請在向量欄位上設 stored=false。 這避免了將原始向量儲存在索引中，降低儲存成本，同時不影響查詢行為。

• 盡可能使用較小的嵌入維度：高維向量會增加儲存與查詢成本。 對於非關鍵工作負載，使用較小的嵌入模型（例如，384或768維度取代1536維度）以降低成本。

優化向量查詢執行

向量查詢計算密集，因為它們需要在高維資料結構上進行相似性計算。

• 選擇性地使用混合式搜尋：混合式查詢同時執行關鍵字與向量檢索。 只有在必要時才使用。

• 降低混合查詢的 maxTextRecallSize：hybridSearch.maxTextRecallSize 設定可控制有多少個依 BM25 排序的結果會納入 Reciprocal Rank Fusion。 預設值為 1,000（範圍 1 到 10,000）。 運算資源消耗大致會隨此值呈線性增加，因此對於混合工作負載而言，降低此值是最直接的成本控制手段之一。

• 接近 500 的數值通常能顯著降低運算量，而幾乎不會造成相關性損失。

• 往下搜尋可能會漏掉向量搜尋會錯過的關鍵字匹配，例如精確詞彙、ID 和縮寫。

• 使用 k 分別控制每個向量查詢的候選項。

• 測試具代表性的查詢，並比較相關性、延遲及 x-ms-azs-compute-units-consumed 標頭，然後再確定一個值。

• 在向量查詢前套用篩選器：在向量搜尋前縮小候選集範圍，以減少處理的資料量。 請參閱向量查詢中的篩選機制。

透過減少使用量來降低成本

無伺服器模式僅對已消耗的資源收費。 當沒有請求時，運算使用量會相應下降。

為了降低使用成本：

• 只有在需要時才執行查詢。
• 避免重複或過於頻繁的請求。
• 監控使用情況並根據需求調整工作負載。

將儲存體成本最佳化

儲存裝置依據磁碟索引大小按 GB 月計費，該索引大小可能超過原始資料大小。 降低儲存成本：

• 移除未使用的索引。
• 最小化儲存欄位。
• 設計綱要時，請將儲存額外負擔納入考量。
• 建議器請有選擇性地使用，因為它們能大幅增加儲存空間。

如需了解向量專屬技術（壓縮、剪枝及儲存設定），請參閱 最佳化向量儲存與處理。

關於儲存與查詢效能權衡的更多指引，請參見 提升 Azure AI 搜尋服務。