最小開銷
ARouter 透過以下方式降低延遲：- 邊緣運算：網關節點在全球部署，盡可能靠近您的應用程式
- 高效快取：使用者憑證和 API Key 資料在邊緣快取，避免每次請求時都查詢資料庫
- 最佳化路由：服務商選擇和金鑰池查詢被設計為在個位數毫秒內完成
效能注意事項
快取預熱
當邊緣快取處於冷狀態時（通常在新部署或新地區後的前 1-2 分鐘），您可能會遇到略高的延遲，隨著快取預熱會迅速恢復正常。點數餘額檢查
為了維護準確的計費並防止超支，在以下情況下 ARouter 會執行額外的資料庫檢查：- 使用者的點數餘額僅剩個位數美元
- API Key 接近其設定的點數限制
- 保持健康的點數餘額（推薦最低：10-20 美元）
- 設定自動加值或定期計費提醒
多模型路由延遲
使用有序候選模型列表時，如果第一個候選模型不可用，ARouter 會路由到下一個模型。失敗的首次嘗試會為該請求增加延遲。ARouter 持續追蹤服務商健康狀況，並繞過已知不可用的服務商，以最大程度地減少此類情況發生的頻率。最佳實踐
1. 使用串流回應
對於面向使用者的應用程式，使用串流回應以降低感知延遲。首個 Token 比完整回應更早到達，即使總生成時間相同，也能讓應用程式感覺更快。 參閱串流回應。2. 使用提示詞快取
對於包含重複前綴（系統提示詞、少樣本範例、大型文件）的請求，啟用提示詞快取。快取 Token 以顯著更低的延遲和更低的成本提供服務。 參閱提示詞快取。3. 選擇合適的模型
更小的模型更快。如果您的使用場景不需要最高能力，較小的模型（例如google/gemini-2.5-flash、anthropic/claude-haiku-4-5）與最大變體相比，可將延遲降低 2-5 倍。
4. 使用 :nitro 服務商變體
對於延遲敏感的工作負載，在模型 ID 後附加 :nitro 以優先選擇高吞吐量服務商端點：
:nitro 路由到針對最大吞吐量和最低首 Token 時間最佳化的服務商設定。詳情參閱服務商路由。
5. 保持健康的點數餘額
將點數餘額保持在合理門檻以上（≥10 美元）可防止計費檢查期間的積極快取失效，這可能增加可測量的延遲。效能測量
使用回應標頭中的x-response-time（如果存在）或在客戶端測量來回時間進行基準測試。ARouter 還在您的活動記錄中展示每個請求的延遲資料。