Le installazioni reali utilizzano hardware misto: un box con grande VRAM e un modello di grandi dimensioni, alcuni box di fascia media con modelli chat, un box CPU per embeddings. In una farm consapevole del modello il gateway indirizza ogni richiesta a un worker che ha già il modello richiesto carico, e pubblicizza l'unione di tutti i modelli dei worker come un unico catalogo <a href="#ref-1">[1]</a>. I chiamanti vedono un'unica lista di modelli e scelgono semplicemente; il posizionamento è un problema del gateway, non loro.
Il caldo batte il freddo di minuti
Il caricamento di un modello può essere un evento di più gigabyte e durare minuti. Atterrare una richiesta su un box che già contiene il modello è il più grande vantaggio in termini di latenza ed efficienza nelle farm eterogenee <a href="#ref-1">[1]</a>. Le richieste sono indirizzate prioritariamente ai worker con modello caldo: i worker che segnalano il modello richiesto sono preferiti, mentre quelli senza rimangono solo come failover di ultima risorsa, dove il loro daemon scaricherebbe il modello secondo la propria politica.
Un catalogo, molti box
Il gateway aggiorna il catalogo di ogni worker con la cadenza del controllo di integrità, quindi la lista dei modelli sul gateway è l'unione deduplicata dell'intera farm, servita da cache <a href="#ref-2">[2]</a>. Un worker il cui catalogo non può essere recuperato è considerato possibilmente caldo piuttosto che non disponibile, quindi il routing non degrada mai sotto la strategia base.
Acquista hardware per classe di modello
Il routing consapevole del modello è sempre attivo in modalità gateway, quindi il design permette di acquistare hardware per classe di modello invece di rendere ogni box in grado di eseguire tutto <a href="#ref-1">[1]</a>La chat funziona dove risiedono i modelli di chat, gli embeddings sulla CPU, la visione sull'acceleratore più adatto. Non è configurato nulla di extra: costruisci la farm, installa i modelli previsti per ogni worker e il gateway gestisce il posizionamento.
Posizionamento che mantiene il failover pronto
Mantieni ogni modello critico per la latenza su almeno due worker in modo che il failover resti pronto anziché attivare un caricamento a freddo nel momento peggiore <a href="#ref-2">[2]</a>La strategia di bilanciamento del carico ordina ancora all'interno del set caldo, quindi <code>least-connections</code> o un bias <code>weighted</code> verso il server più grande si combinano perfettamente con la prontezza.