摘要： Cohere 在 2026 年 10 月 9 日發表一篇針對 embed 與 rerank 工作負載的分析，比較共享（計量計費）與專屬（預留）兩種推理部署。核心論點是：每分鐘請求數（RPM）和單價都無法單獨決定哪種部署更划算，真正的變數是每個請求攜帶多少工作、流量多穩定、以及延遲要求。對任何正在為 RAG 或搜尋系統選基礎設施的 builder 來說，這篇文章提供了一個可以直接套用的決策流程。
先問請求長什麼樣子，再問價錢
Cohere 建議的思考順序是：Request Profile → Traffic Pattern → Utilization → Deployment Choice。起點是搞清楚一次典型的模型呼叫到底包含什麼。
同一個 embedding 模型，在兩種情境下的樣貌完全不同。電商把整批商品目錄轉成向量時，一次請求可能塞 100 段描述、每段約 200 token，重點是 throughput 和每元產出。反過來，使用者輸入一句搜尋詞時，是一個只有幾個 token 的短查詢，使用者盯著 loading spinner 等結果，重點是回應速度，代價是較差的性價比。為大批次調校的基礎設施，未必能同時把數千個延遲敏感的小請求服務好。
Rerank 又多了一個變數：候選文件數。模型會對查詢與每個候選各自算一次相關性，所以工作量和候選數成正比。Cohere 給的例子是一個約 20 token 的查詢配上 50 篇各約 200 token 的候選文件，一次搜尋背後約 11,000 token 的計算。把候選數從 20 提到 100，使用者介面上看不出任何差別，但每次搜尋的計算量從約 4,400 token 跳到約 22,000。這代表 retrieval depth 本身就是一項基礎設施決策——你在按「想挖多深」擴充，而不是按使用者人數。
分界點會隨工作負載大幅移動
Cohere 用代表性定價和一台按小時計費的 NVIDIA A10 GPU 實例算出幾個 break-even 點，差異大到值得停下來看：
- 查詢 embedding（每請求約 8 token）：要到每分鐘數萬個請求才值得上專屬容量。
- 商品目錄 embedding（100 段 × 200 token，約 20K token）：每分鐘約 20 個請求就到分界。
- 長文件 embedding（100 段 × 1000 token，約 100K token）：每分鐘約 4 個請求即可。
- Reranking（1 查詢 + 50 文件）：每分鐘約 29 個請求。
同一個模型、同一套價格，只因為請求形狀不同，分界點就從每分鐘 4 個請求一路移到數萬個。文章舉的實際例子很有參考價值：那個每分鐘 30 個請求的目錄 embedding 工作，聽起來很小，但對應的 break-even 約是 20 req/min——它已經落在專屬容量更划算的區間。
要注意這些數字的假設條件：代表性定價、無議價折扣、流量全天 24×7 維持。只跑部分時段的工作負載需要更高的活躍時段請求率才會到達同樣的經濟交叉點。另外 embedding 按 token 計費、reranking 按 search unit 計費，兩者的請求率不能直接互相比較。
流量節奏決定容量利用率
峰值流量告訴你需要多少容量，但利用率告訴你這些容量用得有多有效率。兩個應用可以有相同的峰值，經濟學卻完全不同。
Cohere 的區分很直白：像全球搜尋服務那樣全天流量平穩的應用，專屬容量有吸引力，因為機器一直在忙，沒有閒置的錢；像財報系統或批次處理那樣平時低量、尖峰集中的應用，計量計費的共享服務更合適，因為不必為閒置時段付錢。一個只在每天尖峰 5 分鐘處理 10,000 RPS 的服務，和一個全天穩定 100 RPS 的服務，前者雖然峰值高得多，卻很難攤平專屬容量的成本。
延遲還會再疊一層限制。批次索引可以跑到極限 throughput；搜尋查詢則受嚴格延遲目標約束，所以可用容量應該按「能滿足目標延遲的永續 throughput」來算，而不是帳面上的最大 benchmark 數字，通常還要為尖峰預留額外 headroom。
一個可以帶走的檢查清單
Cohere 在文末整理了一組問題，答完之後部署選擇基本上就自己浮現了：典型請求包含什麼？是文件還是查詢 embedding？rerank 多少篇文件？預期請求率多少？流量平穩還是爆發？應用需要什麼延遲？專屬基礎設施會不會一直有活幹？
這套思路不只適用於 Cohere 的產品。任何按 token 或按請求計費的模型服務，都會遇到同樣的共享 versus 專屬權衡，而同樣容易掉進「只看單價和 RPM」的陷阱。如果你正在做 RAG 成本優化，值得先把這份檢查清單跑一遍，再決定要不要談專屬容量——順帶一提，這和我之前寫過的省 token 順序問題是一體兩面：先量清楚實際的請求形狀與流量節奏，才輪得到談壓縮或路由（參考 省 token 別從壓縮開始：九招的正確順序）。
務實的下一步：把你自己系統的真實請求日誌拉出來，算出每請求平均 token 數和逐時流量曲線，對照上述 break-even 的量級，你大概就知道自己落在曲線的哪一邊了。