Dva stroje triedy DGX Spark, jeden model: kópia na každom porazí rozdelenie

Prevádzka2026-10-31

Sedem týždňov náš lokálny jazykový model bežal rozdelený medzi dva stroje NVIDIA GB10 s tenzorovou paralelizáciou. Dňa 22. októbra sme to nahradili úplnou kópiou modelu na každom stroji a proxy serverom s minimálnym počtom pripojení pred nimi. Priepustnosť stúpla z približne 180 na 210 tokenov za sekundu a ktorýkoľvek stroj môže teraz reštartovať bez toho, aby sa model stratil.

Prečo sme ho rozdelili

Každý stroj má 128 GB pamäte, ktorú zdieľajú CPU a GPU. V septembri sa model zmestil na jeden stroj, ale jeho cache ledva: použitá zostava vLLM nedokázala udržať KV cache tohto modelu vo formáte FP8, takže cache bola v BF16 a jeden stroj mal miesto pre 499 110 tokenov cache. To je menej ako dve požiadavky pri plnom kontexte modelu 262 144 tokenov. Po rozdelení medzi oba stroje s tenzorovou paralelizáciou cez ich priame sieťové prepojenie sa cache zväčšila na viac ako tri milióny tokenov. Model sme rozdelili kvôli mieste, nie kvôli rýchlosti.

Čo sa zmenilo

Novšia 4-bitová zostava rovnakého modelu (NVFP4, vytvorená pomocou distilácie zohľadňujúcej kvantizáciu) zaberá približne 71 GiB pamäte a komunitná zostava vLLM pre GB10 (eugr/spark-vllm-b12x) spúšťa svoju cache vo FP8. Teraz jeden stroj drží celý model a cache s 0,76 až 1,08 miliónmi tokenov, čo je miesto pre 2,9 až 4,1 požiadavky pri plnom kontexte, v závislosti od toho, koľko pamäte stroj modelu pridelení. Obe kópie využívajú vlastné špekulatívne dekódovanie modelu (MTP, štyri draftové tokeny). Pred prepnutím sme na novej zostave spustili náš test volania nástrojov: dosiahol skóre 86, zatiaľ čo nahradená zostava 75.

Čo sme merali

Jedna kópia sama o sebe podľa počtu súčasne obsluhovaných požiadaviek: pri krátkych promptoch 1 požiadavka poskytovala 36 tokenov za sekundu, 4 požiadavky 82, 8 požiadaviek 109 a 16 požiadaviek 150. Pri dlhších promptoch nášho e-mailového agenta 4 požiadavky poskytli 81, 8 požiadaviek 113 a 16 požiadaviek len 87: nad osem takýchto požiadaviek viac požiadaviek spomalilo spracovanie.

Počas jedného popoludnia jedna kópia spracúvala naraz najviac 12 požiadaviek a druhá 8. Prvá produkovala 91 až 93 tokenov za sekundu a dokončila 26 až 27 požiadaviek za minútu; druhá 81 až 83 tokenov za sekundu a 22 požiadaviek za minútu. Obe teraz spracúvajú 12.

Čoho sme sa vzdali

Miestnosť. Rozdelený model mal jednu cache s viac ako tromi miliónmi tokenov; kópie majú dve menšie a požiadavka môže použiť iba cache tej kópie, ktorá ju obsluhuje. Naši agenti odosielajú veľa krátkych a stredne dlhých požiadaviek a pre nich bola priepustnosť dôležitejšia. Ak obsluhujete naraz niekoľko veľmi dlhých kontextov, rozdelenie môže byť stále lepšou voľbou. Rozdelené nastavenie sme ponechali a prepnutie späť je jeden skript.

Čo sa pokazilo počas prepnutia

1. Eleven minút bez modelu, potom 30 sekúnd chýb 502. Rozdelený model sa musel zastaviť skôr, než sa na rovnakých strojoch načetla kópia, takže naše agenty čakali približne jedenásť minút. Keď sa prvá kópia spustila, proxy odpovedalo „502 no live upstreams“ ešte asi 30 sekúnd: označilo backendy za zlyhané, kým boli dole (max_fails=3, fail_timeout=30s), a neskúšalo ich znova, kým tento čas nevypršal.
2. Klient, ktorý obišiel proxy. Jedna z našich dávkových úloh mala v konfigurácii adresu prvého stroja, takže celá jej záťaž išla na jednu kópiu, zatiaľ čo druhá mala voľnú kapacitu. Každý klient teraz prechádza cez proxy; vlastné adresy strojov slúžia len na kontrolu stavu.
3. Metriky, ktoré skákali. Náš monitor priepustnosti čítal /metrics z vLLM cez proxy. Pri dvoch backendoch pochádzali po sebe idúce čítania z rôznych kópií, počítadlá skákali tam a späť a monitor hlásil model ako vyhladovaný. Teraz číta každú kópiu priamo a sčítava ich.
4. Starý watchdog, ktorý by zastavil novú kópiu. Rozdelené nastavenie malo watchdog, ktorý reštartoval svoju službu, keď model prestal odpovedať. Nová služba deklaruje Conflicts= so starou, takže tento reštart by zastavil novú kópiu. Musel sa vypnúť príkazom systemctl disable --now, nie len zastaviť, pretože naša vrstva pre prevádzku reštartuje jednotky, ktoré sú povolené, ale nebežia.
5. Pamäť na stroji, ktorý robí aj inú prácu. Jeden stroj beží aj naše databázy a zostavovanie stránok. Pri nastavení gpu-memory-utilization pre vLLM na 0,78 zostávalo pre všetko ostatné len 5 GiB, takže sme ho znížili na 0,74 a reštartovali len túto kópiu, zatiaľ čo druhá niesla záťaž. Na týchto strojoch ide podiel, ktorý dáte vLLM, z tej istej pamäte ako všetko ostatné.

Ak máte dva takéto stroje

• Ak sa model a cache, ktorú potrebujete, zmestia na jeden stroj, spustite kópiu na každom za proxy s minimálnym počtom pripojení. Rozdeľujte model len vtedy, keď jeden stroj neudrží cache, ktorú potrebujete.
• Nasmerujte každého klienta na proxy, vrátane dávkových úloh a starých konfigurácií.
• Čítajte metriky z každej kópie priamo.
• Dajte každému stroju jeho vlastný podiel pamäte podľa toho, čo na ňom ešte beží.
• Nastavte, koľko požiadaviek kópia obsluhuje naraz podľa vašej vlastnej prevádzky: pre náš mix bolo 12 lepšie ako 8.
• Počítajte s tým, že prepnutie odoberie model na dobu, ktorú kópia potrebuje na štart, a naplánujte to.

Factory Floor dodáva proxy a konfiguračné súbory na spustenie pre jeden alebo dva stroje, kontrolu stavu a test použitia nástrojov, ktoré spúšťame pred prepnutím modelov, spolu s watchdogmi a bezpečnostnými poistkami pamäte pre zvyšok stroja.