實際部署中會混合使用不同硬件：一台大 VRAM 的機器運行大型模型，幾台中階機器運行聊天模型，一台 CPU 機器用於嵌入向量。在模型感知叢集中，閘道會將每個請求路由到已預熱所需模型的工作節點，並將所有工作節點模型的聯合集合作為目錄對外宣告。 <a href="#ref-1">[1]</a>調用者只看到一個模型列表，直接選擇；模型部署由閘道負責，調用者無需關心。
預熱模型比冷啟動快數分鐘
模型加載可能是數 GB 且耗時數分鐘的操作。將請求落在已持有該模型的機器上，是異構叢集中延遲和效率提升的最大關鍵。 <a href="#ref-1">[1]</a>請求優先路由至已預熱該模型的工作節點；未預熱的節點僅作為最後備援，其守護進程會根據策略自行加載模型。
一個目錄，多台機器
閘道會根據健康檢查頻率刷新每個工作節點的目錄，因此閘道上的模型列表是整個叢集去重後的聯合集合，並從快取中回應。 <a href="#ref-2">[2]</a>無法獲取目錄的工作節點會被視為可能已預熱而非不可用，因此路由策略不會退化至簡單模式。
根據模型類別購買硬件
模型感知路由在閘道模式下始終啟用，設計上允許你根據模型類別購買硬件，而無需讓每台機器都能運行所有模型。 <a href="#ref-1">[1]</a>聊天服務運行於聊天模型所在的伺服器，嵌入式向量運算於 CPU 主機，視覺運算則在合適的加速器上。無需額外配置：建立伺服器群組，安裝每個工作節點所需的模型，閘道器自動負責調度。
保持故障轉移熱備份的調度策略
確保每個延遲關鍵模型至少在兩個工作節點上運行，令故障轉移時保持熱備份，避免在最壞時刻觸發冷啟動。 <a href="#ref-2">[2]</a>負載平衡策略仍會在熱備份節點中排序，因此<code>least-connections</code>或帶有<code>weighted</code>偏好的策略，能與熱備份機制完美結合。