返回 AWS Marketplace 產品列表
S4 Embed
AI & GPU

S4 Embed

Vector-search FinOps gateway

ANN RAM 縮小高達 32×</font> 替換的 AWS 服務: Vector-search RAM / instance 成本
在 AWS Marketplace 取得

何時收回成本?

回收週期取決於成本項目和替換範圍

該產品的回收週期取決於您目前的 AWS 支出、替換範圍和執行環境。請使用帳單模擬器識別符合的成本項目並取得粗略的節省估算。

用您的帳單估算

估算您的節省金額

輸入相關每月支出或使用量即可獲得粗略估算 — 無需上傳帳單。

完整帳單上傳與其他產品

一個 FinOps layer,可在保持 recall 達標的同時降低現有 vector database 成本。它對 embeddings 做量化(binary + int8),並在 OpenSearch、pgvector、Qdrant 或 Milvus 前執行兩階段 search(1-bit Hamming coarse stage + exact rescore),將記憶體中的 ANN graph 最多縮小 32×。以 Amazon Linux 2023 AMI 形式運行在你自己的 VPC 中,按使用量計費(embedded texts、indexed documents、served searches)。

S4 Embed 幫助你找到並運行滿足 recall target 的低成本 vector-search 配置。在 30k-vector benchmark 上,binary Hamming + float rescore 達到 recall@10 0.976–1.000,具體取決於 store 和 over-fetch — 你可以選擇 operating point。FinOps 工具就是產品本體:s4embed prove(估算 recall/cost/latency frontier)、compare(跨 store 測量 live recall)、tune(生成滿足 recall + latency + RAM budget 的可部署 config)、gateway shadow mode(dual-write 並 shadow-compare 後再 cutover)以及 drift(監控 embedding drift)。跨 OpenSearch、pgvector、Qdrant 和 Milvus 的 store-agnostic 支援。

面臨挑戰

向量搜尋將其 ANN 圖保留在 RAM 中,因此隨著語料庫的增長,向量資料庫的記憶體佔用 — 以及成本 — 也隨之增加,且該項支出難以預測。您不想為了省錢而犧牲召回率,這讓您在成本與品質之間陷入兩難。而在正式部署到生產環境之前,通常很難找出在 OpenSearch、pgvector、Qdrant 或 Milvus 中,哪種儲存和設定最具成本效益。

運作原理

  1. 1

    量化嵌入

    S4 Embed 將您的嵌入量化為二進位(使記憶體中的 ANN 圖縮小高達 32x)和 int8 殘差(使磁碟上的向量縮小約 4x),從而減少向量資料庫需要佔用的 RAM。

  2. 2

    雙階段搜尋以維持召回率

    1 位元 Hamming 粗篩階段建構一個簡短的候選清單,接著透過精確的二次評分對其進行重排。透過調整 over-fetch 和二次評分的工作點,您可以在確保達到目標召回率的同時降低 RAM 佔用。

  3. 3

    在切換前用資料進行驗證

    s4embed prove、compare 和 tune 會測量您自身向量的 召回率/成本/延遲 前沿,並輸出可部署的設定。閘道器的 shadow 模式會雙寫並影子比對即時讀取,使您能夠在切換之前觀察壓縮路徑是否能成功重現主路徑。

產品亮點

Binary quantization 將記憶體中的 ANN graph 最多縮小 32×;在 30k-vector benchmark 上 recall@10 為 0.976–1.000(取決於 store / over-fetch)— 按你的 recall target 選擇 operating point。

Store-agnostic(OpenSearch / pgvector / Qdrant / Milvus);shadow mode 在任何 cutover 前用 primary 驗證壓縮路徑。

FinOps CLI — prove / compare / tune / drift — 測量 cost、recall 和 latency,並輸出可部署 config。

包含內容

  • Amazon Linux 2023 AMI (x86_64) — 運作在您自己 VPC 內、負載平衡器背後的向量搜尋 FinOps 閘道器
  • Binary + int8 量子化與兩階段搜尋流水線(1-bit Hamming 粗篩階段加精確重排),將記憶體中 ANN 圖縮減高達 32x
  • 與儲存無關的流水線 — 支援 OpenSearch、pgvector、Qdrant 和 Milvus,無鎖定
  • FinOps CLI — s4embed prove(估算召回率/成本/延遲前沿)、compare(測量各儲存中的即時 ANN 召回率)、tune(輸出滿足召回率 + 延遲 + RAM 預算的設定)以及 drift(監控嵌入漂移和召回率並建議重新調優)
  • 閘道器的 shadow 模式 — 對即時讀取進行雙寫和 shadow 比較,以便在切換前確認壓縮路徑能夠重現主路徑的結果
  • CloudFormation 快速入門 — 自動設定 OpenSearch 和 pgvector 路徑(Qdrant 和 Milvus 透過將閘道器指向您的現有端點進行連接)
  • 維運功能 — API 金鑰驗證(設定後)、請求大小和並行限制、在計費或儲存出現問題時 fail-closed 的 readiness 探針、Prometheus 指標,以及按使用量計費(按嵌入的文字、索引的文件和提供的搜尋服務計費)

適用場景

隨著語料庫的增長,向量資料庫 RAM 成本隨之增加的大規模搜尋和 RAG 工作負載

希望在維持召回率目標的同時降低向量搜尋成本的團隊

在切換到生產環境之前,評估 OpenSearch、pgvector、Qdrant 和 Milvus 中哪種儲存和設定最具有成本效益

在將資料和向量資料庫保留在自己帳戶內的同時,以按使用量計費的方式執行向量搜尋

常見問題

壓縮會損害召回率嗎?

工作點由您決定。在 30k 向量的基準測試中,binary Hamming + float 重排在 recall@10 上達到了 0.976 到 1.000(OpenSearch 0.995、pgvector 0.996、Qdrant 1.000、Milvus 0.976)—— 且均是在 RAM 減少 32x 的情況下實現的。召回率隨 over-fetch 增加而提高,因此您可以根據召回率目標調整工作點。召回率隨 over-fetch 變化,最佳點因工作負載而異。

可以節省多少 RAM?

二進位量化可使記憶體中的 ANN 圖縮小高達 32x,而 int8 殘差可使磁碟上的向量縮小約 4x。具體縮減量取決於您的語料庫、所選儲存和工作點,因此最可靠的評估方式是使用 s4embed prove 和 tune 對您自己的資料進行估算。

支援哪些向量儲存?

該管線與儲存無關,支援 OpenSearch、pgvector、Qdrant 和 Milvus。OpenSearch 和 pgvector 路徑可透過隨附的 CloudFormation 快速入門進行設定,而 Qdrant 和 Milvus 只需將閘道指向您現有的端點即可運作。s4embed compare 可讓您測量各儲存的即時 ANN 召回率。

在切換到生產環境之前可以進行驗證嗎?

可以。s4embed prove 和 tune 會在您自己的向量上估算設定,compare 會測量各儲存中的即時 ANN 召回率。閘道的 shadow 模式會對即時讀取進行雙寫和 shadow 比較,以便您在切換前確認壓縮路徑能重現主路徑的結果,隨後 s4embed drift 會監控嵌入漂移和召回率並建議重新調優。

我的資料保存在哪裡?如何計費?

S4 Embed 作為標準的 Amazon Linux 2023 AMI 執行在您自己的負載平衡器後、您自己的 VPC 內。您的資料和向量資料庫永遠不會離開您的帳戶,且沒有鎖定。計費基於使用量並透過您的 AWS 帳單進行結算 —— 按嵌入的文字、索引的文件和服務的搜尋計費 —— 每小時透過 AWS Marketplace Metering Service 報告。

為什麼更便宜

假設在 us-east-1 執行 1 億 (100M) × 768 維向量、HNSW ANN 圖常駐記憶體的向量搜尋負載。

不使用 S4 Embed (fp32 HNSW)
搜尋查詢
300 GB 駐留記憶體
向量資料庫
r6i.16xlarge
r6i.16xlarge 隨需
$2,500 / 月
月度合計
$2,500 / 月
使用 S4 Embed (int8 量化 + 2 段檢索)
搜尋查詢
10 GB 壓縮圖
S4 Embed
r6i.large
r6i.large + 軟體費
$130 / 月
月度合計
$130 / 月
−95%與 fp32 HNSW 相比

按語料庫規模選擇 S4 Embed 執行個體

語料規模推薦執行個體S4 Embed 執行個體費用月度合計對比 fp32 HNSW
~10M 向量r6i.large$130 / 月$130 / 月 (fp32 $250, −48%)
~100M 向量r6i.large$130 / 月$130 / 月 (fp32 $2,500, −95%)
~1B 向量r6i.2xlarge$510 / 月$510 / 月 (fp32 $25,000, −98%)

僅供參考。fp32 HNSW RAM 估算為 (100M × 768 × 4 位元組) + HNSW 圖開銷 ≈ 300 GB,因此選擇 r6i.16xlarge。S4 Embed 透過 int8 量化和 2 段 (粗檢索 + 重排序) 達到相當的召回率。請在切換前用 --shadow + --validate 驗證 recall@10。

計費模式

按使用量計量(embedded texts、indexed documents、served searches)+ 你自己 VPC 內的 EC2(Amazon Linux 2023 AMI)。

在 AWS Marketplace 取得