注意
Azure AI 搜尋服務 可透過 Azure 入口網站、REST API 及 Azure SDK 取得。 它同時也是 Foundry IQ 的基礎,這是一個管理式知識層,能將企業內容轉化為可重複使用、權限感知的知識庫,供 Microsoft Foundry 入口網站中的代理使用。
Azure AI 搜尋服務 提供兩種不同容量處理的定價模式:
專用:透過調整副本與分割區大小並選擇服務層級來規劃容量。
- 使用複本和分割區直接預先佈建容量。
- 估算所需的儲存空間(分割區)與所需吞吐量(副本)。
- 選擇服務層級,根據預期尖峰需求配置所需的容量。
- 一旦你預先設定容量,無論使用量如何,你都將支付按小時計算的費率,而該費率以搜尋單元(SU)為計量單位。
Serverless(預覽):服務會根據使用量和服務限制自動管理容量。 你不需要預先配置容量。 相反地,優化你的工作負載效率以管理成本。
- 容量會自動隨需求調整(閒置時可調整至零)。
- 你的帳單是根據實際使用量(以運算單位(CU)和儲存空間來計算。
- 規劃重點不是基礎建設,而是聚焦於這些成本驅動因素:查詢模式、索引規模與成長,以及資料擷取模式。 請參見 無伺服器模型的優化成本。
| Dimension | 專用 | 無伺服器 |
|---|---|---|
| 容量模型 | 已佈建 (複本 × 分割區) | 以消費為基礎 |
| Scaling | Manual | 自動 |
| 使用者控制 | 明確指定(設定複本與分割區) | 間接(受工作量特性影響) |
| 計費 | 每個搜尋單位(SU)的固定每小時費率 | 計算單元(CU)與儲存的用量基礎支付 |
| 閑置成本 | 始終會產生費用(最低已佈建容量) | 閒置時可自動縮減至零 |
| 優化焦點 | 基礎設施規模 | 工作負載效率 |
| 最適合用於 | 可預測且穩定的工作量 | 可變、高載或多租用戶工作負載,包括 Agent 驅動的案例 |
| 容量規劃方法 | 調整基礎結構大小和規模 (複本和分割區) | 優化工作負載效率與使用模式 |
| 效率低下的影響 | 延遲與擴充壓力 | 直接成本增加 |
Important
無伺服器開發者層級目前仍處於預覽階段。 此預覽版在沒有服務等級協議的情況下提供,不建議用於生產工作負載。 某些功能可能不被支援或功能受限。 欲了解更多資訊,請參閱 Microsoft Azure 預覽版補充使用條款。
無伺服器開發者等級的計費於 2026 年 9 月 13 日開始。 該日期或之後的使用費用會顯示在您的 Azure 發票上。 你不會因為2026年9月13日之前的使用而被收費。
無伺服器開發者層級不支援遷移至或遷移至其他定價層級,且部分其他層級的功能在公開預覽階段不被支援。 服務限制、支援功能及價格細節可能會在正式上市前有所變動。
預覽期間,無伺服器定價模式僅支援 特定區域。
欲了解更多,請參閱:
為專用模型規劃容量
在專用模式中,你透過搜尋 單元(SU)來配置容量:
- 搜尋單元(SU) = 副本數 × 分割區
- 複本:搜尋引擎的複本。 提供查詢吞吐量與高可用性。
- 分區:儲存單位。 提供儲存與索引吞吐量。
每個服務都會以 1 個複本 × 1 個分割區 (1 SU) 開始。 你可以獨立新增或移除副本和分割區,以因應變動的工作負載。 新增容量會增加執行搜尋服務成本。
| 概念 | 定義 |
|---|---|
| 搜尋單位 | 總可用容量的單一增量。 至少需要一個搜尋單元才能執行服務。 根據您的定價層,最大範圍為 1 到 36 個單位。 搜尋單位數目等於抄本數目乘以分割區數目:R × P = SU。 每個服務都從一個複本和一個分割區開始,這會耗用一個單位:1 × 1 = 1。 新增第二個複本會耗用兩個單位:2 × 1 = 2。 搜尋單位也是搜尋服務的計費單位。 |
| 複本 | 搜尋服務的執行個體,主要用於查詢作業的負載平衡。 每個複本會裝載一個索引。 如果配置三個複本,則有三份可供維護查詢要求的索引複本。 |
| 分割區 | 為讀寫作業 (例如,在重建或重新整理索引時) 提供實體儲存體和 I/O。 每個分區都包含總索引的一部分。 如果您配置三個分割區,您的索引會以三個為單位分割。 |
請檢閱分區與複本資料表,以了解在 36 單位限制內的可能組合。
副本與分割區的物理特性,如處理速度與磁碟 IO,會依 服務層級而異。 在標準搜尋服務中,複本與分區比基本服務更快且更大。
何時為專用模型新增容量
考慮在以下情況下加入副本或分割區:
- 查詢延遲增加或服務等級協議條件未被滿足。
- HTTP 503(服務無法使用)錯誤的頻率增加。
- HTTP 429(請求過多)錯誤的頻率增加,顯示請求限速。
- 預期會有大量查詢量。
- 索引工作進展緩慢或落後。
- 儲存或索引吞吐量不足。
縮放指引:
- 新增 副本 以提升查詢吞吐量與可用性。
- 新增 分割區 以提升儲存和索引效能。
- 查詢量大的工作負載通常需要更多副本。
- 大型索引可能需要額外的複本來維持效能。
Important
擴展作業可能需要時間完成且成本增加。 務必透過效能測試與定價估算來驗證變更。
你選擇的服務等級決定分割區大小和速度。 每個層級都圍繞一套符合不同情境的特性進行優化。 如果您選擇較高端的定價層級,則需要的分區可能比使用 S1 時更少。 您需要透過自主測試來回答的其中一個問題是,規模較大且成本較高的分區是否在較低階層服務中比兩個較便宜的分區提供更好的效能。
單一服務必須具有足夠的資源,才能處理所有工作負載 (編製索引和查詢)。 任何一個工作負載都不在背景中執行。 您可以排程在查詢要求自然較少的時間進行索引編製,但除此之外,服務不會讓某項工作優先於其他工作。 此外,當服務或節點在內部更新時,特定數量的備援可讓查詢效能更加順暢。
就一般規則而言,搜尋應用程式通常需要的複本數量會多於分割區數量,特別是在服務作業偏向查詢工作負載的情況下。 每個複本都是索引的副本,因此服務可以針對多個副本進行負載平衡要求。 Azure AI 搜尋服務 負責管理索引的所有負載平衡與複製。 您可以隨時更改分配給服務的複本數量。 您最多可在標準搜尋服務中配置 12 個複本,並在基本搜尋服務中配置 3 個複本。 您可以從 Azure 入口網站或其中一個程式化選項進行複本配置。
額外的分區有助於密集索引工作負載。 額外的分割區將讀寫操作分散在更多計算資源上。
最後您會發現,索引越大,查詢所需的時間就越長。 因此,您可能會發現,每次增加分區時,都需要相對應地小幅增加複本數。 查詢的複雜性和查詢量是影響查詢執行速度的因素。
關於服務限制與有效擴展範圍,請參見:
注意
新增更多複本或分割區會增加執行服務的成本,並可能會對結果的排序方式產生稍微變化。 請務必檢查定價計算機,以了解新增更多節點會對計費造成哪些影響。 分割區與複本組合表能幫助你交叉比對特定配置所需的搜尋單元數量。 如需額外複本如何影響查詢處理的詳細資訊,請參閱 排序結果。
如何管理與調整容量
變更容量不是立即進行的。 根據資料量與操作類型,縮放時間從數分鐘到數小時不等。
縮放搜尋服務時,您可以從下列工具和方法中選擇:
注意
如果您的搜尋服務是在 2024 年 4 月或 5 月之前建立的,可能有資格一次性升級到分割區較大的新基礎設施,且不會額外付費。 此升級可增加每個分割區可用的儲存空間,並減少工作負載所需的分割區數量。 如需詳細資訊,請參閱 升級您的搜尋服務。
若要增加或減少服務的容量,您有兩個選項:
新增或移除分割區和複本
前往 Azure 入口網站中的搜尋服務。
從左窗格中,選取 [ 設定>規模]。
下列螢幕擷取畫面顯示已佈建一個複本與一個分區的 Standard 服務。 底部的公式會指出正在使用多少搜尋單位 (1)。 如果單價為 $100 (非實際價格),則執行此服務的每月成本平均為 $100。
使用滑桿來增加或減少分割區數目,然後選取 [ 儲存]。
此範例會新增第二個副本和分區。 請注意搜尋單位計數;現在是四,因為計費公式為複本乘以分區 (2 x 2)。 將容量翻倍會使運行服務的成本增加到超過兩倍。 如果搜尋單位成本為 $100,新的每月帳單現在會是 $400。
如需每一層目前的每單位成本,請瀏覽 定價頁面。
請檢查您的通知,以確認作業已啟動。
此作業可能需要數小時才能完成。 它在背景中進行,因此您的搜尋服務能保持完整運作,並可供讀寫操作。
你無法取消手術或監控其進展。 不過,在進行變更時,會顯示下列訊息。
變更您的定價層
注意
Azure 入口網站和服務 - 更新(REST API)支援在 Basic 和標準(S1、S2 和 S3)層級之間的變更。 您可以升級或降級層級,前提是您目前的服務設定未超過 目標層級的限制。 您的區域也不能在 目標層上有容量限制。
您的定價層級決定了專屬定價模式下搜尋服務的最大儲存空間。 如果您需要更多或更少的容量,您可以切換至不同的定價層,以滿足您的儲存需求。 (此規定僅適用於專用定價模式的階層。選擇無伺服器開發者層級後無法更改)。
除了容量之外,定價層也會決定索引、索引器和其他搜尋物件的限制。 在繼續之前,請先比較目前層級和所需層級的 服務限制 。 一般而言,切換至較高層級會增加 儲存限制 和 向量限制、增加請求輸送量並減少延遲,而切換至較低層級則會產生相反的效果。
切換至較高的定價層也會增加執行搜尋服務的成本。 如需詳細資訊,請參閱價格網頁。
若要變更您的定價層:
前往 Azure 入口網站中的搜尋服務。
從左窗格中,選取 [ 設定>規模]。
在當前層級中,選擇 變更定價層。
在 [ 選取定價層 ] 頁面上,從清單中選擇不同的階層。
您可以在 Basic、S1、S2 和 S3 之間切換,但無法切換到 Free、S3HD、L1 或 L2。 這些層級無法選取,而且會顯示為灰色。
若要啟動調整作業,請選取 [ 儲存]。
此作業可能需要數小時才能完成。 它在背景中進行,因此您的搜尋服務能保持完整運作,並可供讀寫操作。
你無法取消手術或監控其進展。 不過,在進行變更時,會顯示下列訊息。
如何處理專用模型的擴縮要求
當搜尋服務收到擴縮要求時,它會:
- 檢查要求是否有效。
- 開始備份資料和系統資訊。
- 檢查服務是否已處於佈建狀態中 (目前正在新增或移除複本或分區)。
- 開始佈署。
擴展服務可能需要幾分鐘到數小時,視服務規模及請求範圍而定。 備份時間也會依資料量、分割區和副本數量而異。
處理體重計請求的步驟並非完全連續。 例如,系統會在可以安全進行時開始佈建,這可能是在備份即將完成時。
縮放期間發生錯誤
下表列出擴展作業期間可能發生的錯誤原因和解決方案。
| 錯誤訊息 | 原因 | 解決方法 |
|---|---|---|
| 「目前不允許服務更新作業,因為我們正在處理先前的要求。 | 另一個擴展作業正在進行中。 | 請查看Azure入口網站中的 Overview 頁面,或使用 Search Management REST API、Azure PowerShell 或 Azure CLI 查詢您的搜尋服務狀態。 如果狀態為「佈建中」,請等到它變成「成功」或「失敗」後再試一次。 1, 2 |
| 「無法調整搜尋服務 服務名稱。 錯誤: 物件 計數 ActualCount 超過允許的限制: MaximumCount。」 | 您目前的服務組態超出目標定價層的限制。 | 檢查您的儲存使用量、向量使用量、索引、索引子和其他物件是否符合較低層的 服務限制。 例如,基本層最多支援 15 個索引,因此如果您有 16 個索引,則無法從 S1 切換至基本。 在重試之前,請先調整您的資源。 |
1 備份沒有狀態資訊,這是不太可能中斷擴展操作的內部作業。
2 如果您的搜尋服務看起來停滯在佈建狀態,請檢查是否有無法使用、查詢量為零且未更新索引的孤立索引。 無法使用的索引可以封鎖服務容量的變更。 特別是,請尋找金鑰已失效的 CMK 加密索引。 請刪除索引,或還原金鑰以使索引重新上線,並解除縮放作業的封鎖。
分區與複本組合
下圖適用於標準層和更高層級。 其會顯示所有可能的分割區和複本組合,受限於每個服務 36 個搜尋單位的上限。
| 1 個分區 | 2 個分割區 | 3 個分區 | 4 個分割區 | 6 個分割區 | 12 個分區 | |
|---|---|---|---|---|---|---|
| 1 個複本 | 1 蘇 | 2 蘇 | 3 蘇 | 4 蘇 | 6 蘇 | 12 蘇 |
| 2 個複本 | 2 蘇 | 4 蘇 | 6 蘇 | 8 蘇 | 12 蘇 | 24 蘇 |
| 3 個複本 | 3 蘇 | 6 蘇 | 9 蘇 | 12 蘇 | 18 SU | 36 蘇 |
| 4 個複本 | 4 蘇 | 8 蘇 | 12 蘇 | 16 蘇 | 24 蘇 | N/A |
| 5 個複本 | 5 蘇 | 10 蘇 | 15 蘇 | 20 SU | 30 蘇 | N/A |
| 6 個複本 | 6 蘇 | 12 蘇 | 18 SU | 24 蘇 | 36 蘇 | N/A |
| 12 個複本 | 12 蘇 | 24 蘇 | 36 蘇 | N/A | N/A | N/A |
基本搜尋服務的搜尋單位計數較低。
對於 2024 年 4 月 3 日之前建立的搜尋服務,Basic 服務只能有一個分區,且最多可有三個複本,因此 SU 上限為三。 唯一可調整的資源是複本。 不過,您可以 藉由升級服務來增加分割區計數。
對於 2024 年 4 月 3 日之後在支援區域中建立的搜尋服務,Basic 服務最多可有三個分區與三個複本。 為了支援完整的分區與複本配置,SU 上限為九。
對於任何可計費層上的搜尋服務,不論建立日期為何,您至少需要兩個複本,才能在查詢上取得高可用性。
關於各層級及貨幣的計費,請參閱 Azure AI 搜尋服務 價格頁面。
使用專用定價模式層級估算容量
你的儲存需求取決於你預期建立的指數大小。 沒有任何可靠的啟發式方法或一般指導方針可協助估算。 判斷指數大小的唯一方法是 建立一個指數。 它的大小取決於分詞化與嵌入,以及是否啟用建議器、過濾和排序,或是能利用 向量壓縮。
估算可計費層級(Basic 或更高層級)上的容量。 免費層會在多個客戶共用的實體資源上執行,且受限於超出您控制的因素。 只有可計費搜尋服務的專用資源可以因應較大的取樣和處理時間,並可在開發期間實際預估索引數量、大小和查詢量。
檢閱每一個定價層的服務限制,以判斷較低定價層是否能支援您需要的索引數量。 請考量您是否需要索引的多份複本,以支援主動開發、測試與生產環境。
搜尋服務受物件限制(最大索引數量、索引器、技能集等)及儲存限制。 先觸達哪個限制即為有效限制。
在可計費等級建立服務。 階層會針對特定工作負載進行最佳化。 例如,記憶體優化層的限制為10個索引,因為它的設計目的是支援少量的大型索引。
如果您不確定預測的負載,請從較低的 Basic 層或 S1 開始。
如果測試包含大規模的索引和查詢負載,請從較高的定價層開始,例如 S2 或甚至 S3。
從 L1 或 L2 的儲存體最佳化開始,如果您要為大量資料編製索引,而且查詢負載相對較低,如同內部商務應用程式一樣。
建置初始索引,以判斷來源資料轉譯為索引的情形。 這是唯一能預估索引大小的方式。 欄位定義上的屬性會影響實體儲存體需求:
針對關鍵字搜尋,將欄位標示為可篩選且可排序會增加索引大小。
針對向量搜尋,您可以 設定參數以減少向量大小。
監控儲存空間、服務限制、查詢量及延遲,Azure入口網站。 Azure 入口網站顯示每秒查詢數、限速查詢數及搜尋延遲。 這些數值能幫助你判斷是否選擇了正確的等級。
新增資料複本以增強高可用性或改善緩慢的查詢效能。
並無關於容納查詢負載所需複本數目的規則。 查詢效能取決於查詢的複雜度以及競爭工作負載的情況。 雖然新增複本會明顯獲得更好的效能,但是最終結果並不會完全地呈線性關係:新增 3 個複本並不保證有 3 倍的輸送量。 如需估算解決方案 QPS 的指引,請參閱 「分析效能 」與 「監控查詢」。
若為反向索引,其大小和複雜性取決於內容,而不一定是您送入的資料量。 具有大量重複內容的大型資料來源所產生的索引,可能會比內容變化極大的資料集所產生的索引還小。 因此,不太可能根據原始資料集的大小來推斷出索引大小。
如果你包含從未搜尋過的資料,儲存需求可能會被誇大。 理想情況是,文件只包含搜尋體驗所需的資料。
服務等級協定考量
服務等級協議(SLA) 不涵蓋免費方案和預覽功能。 在所有可計費層中,SLA 會在您為您的服務佈建足夠的備援性時生效。
兩個以上的複本可滿足查詢 (讀取) SLA。
三個或多個副本可以滿足查詢、編製索引及讀寫的服務等級協議。
分割區數目不會影響 SLA。
優化無伺服器模型的成本
在無伺服器定價模型中:
- 該服務會自動管理容量。
- 你不需要設定複本、分割區或搜尋單元。
- 計算會根據工作負載(查詢和索引需求)動態擴展,閒置時可擴展至零。
欲了解更多無伺服器模型的限制,請參閱 服務限制。
計費以兩個面向為依據:
- 運算使用量(CUs): 收費依據查詢與索引操作。
- 索引儲存: 按 GB 計費,每月計算。
由於計費是以消耗為基礎,成本與使用量直接相關:
- 複雜的查詢會消耗更多運算資源。
- 低效率的結構設計會增加索引與查詢成本。
- 查詢模式不佳且索引大或頻繁更新會增加儲存空間與運算使用量。
優化工作負載效率
因為在無伺服器模型中,低效率最終都會反映在成本上,所以如果你沒有採用考量工作負載的設計,完成相同的工作就必須支付更高的成本。 控制無伺服器支出的最佳方式,是從一開始就有效率地設計你的索引和查詢。
在使用無伺服器定價模型時,設計工作負載以提升效率,請考慮:
索引設計
- 僅包含查詢中使用的欄位。
- 盡可能減少向量維度。
- 避免不必要的可篩選、可排序或可面化屬性。
查詢模式
- 用
$select來限制回傳欄位。 - 盡早套用篩選條件,以縮小結果集。
- 避免深層分頁(
$skip)。 - 偏好針對性的查詢,而非廣泛的全文查詢。
- 由於運算成本較高,請謹慎使用混合搜尋。
Monitoring
- 監控 CU 使用量 以識別昂貴查詢。
- 追蹤儲存空間成長並移除未使用的資料。
在無伺服器中,提升效能(更快、更具目標性的查詢)通常能降低成本。
欲了解更多,請參閱 Azure AI 搜尋服務 中的無伺服器定價模型優化成本。
區域容量考量
容量與可用性會因 支援區域而異。 部分地區可能對新服務的配置或現有服務的擴展有限制。
注意
在公開預覽期間,無伺服器定價模式僅在 特定地區提供。
若您偏好的Azure AI 搜尋服務區域因容量限制無法使用,請參見如何在Azure AI 搜尋服務中處理區域容量限制。