Két DGX Spark-osztályú gép, egy modell: egy-egy másolat mindegyiken, jobb, mint a felosztás

Üzemeltetés2026-10-31

Hét hétig a helyi nyelvi modellünk két NVIDIA GB10 gépen futott felosztva, tenzorpárhuzamosítással. Október 22-én ezt felváltottuk egy-egy teljes modellmásolattal a gépeken, előtte egy legkevesebb kapcsolatot választó proxyval. Az áteresztőképesség kb. 180-ról 210 token/másodpercre nőtt, és bármelyik gép újraindítható anélkül, hogy a modell elérhetetlenné válna.

Miért osztottuk fel

Mindegyik gépben 128 GB memória van, amelyet a CPU és a GPU megoszt. Szeptemberben a modell elfért egy gépen, de a gyorsítótára alig: az általunk használt vLLM-verzió nem tudta FP8-ban tárolni ennek a modellnek a KV-gyorsítótárát, így az BF16-ban volt, és egy gépen 499 110 tokennyi hely volt rá. Ez kevesebb, mint két kérés a modell teljes, 262 144 tokenes kontextusában. A két gép közötti közvetlen hálózati kapcsolaton keresztüli tenzorpárhuzamosítással a gyorsítótár mérete több mint hárommillió tokenre nőtt. A modellt nem a sebesség, hanem a hely miatt osztottuk fel.

Mi változott

Ugyanezen modell egy újabb 4 bites változata (NVFP4, kvantálásérzékeny tudásmegörzést alkalmazó tudásmegörzéssel készült) kb. 71 GiB memóriát igényel, és a GB10-höz készült közösségi vLLM-verzió (eugr/spark-vllm-b12x) FP8-ban futtatja a gyorsítótárát. Most egy gép tartalmazza az egész modellt és 0,76–1,08 millió tokenes gyorsítótárat, ami 2,9–4,1 kérésnek ad helyet teljes kontextusban, attól függően, hogy a gép mennyi memóriát biztosít. Mindkét másolat a modell saját spekulatív dekódolását (MTP, négy vázlatos token) használja. A váltás előtt lefuttattuk az eszközhasználati tesztünket az új verzióval: 86 pontot ért el, míg a leváltott verzió 75-öt.

Amit mértünk

Egyetlen példány önmagában, az egyszerre kiszolgált kérések száma szerint: rövid promptokkal 1 kérés másodpercenként 36 tokent adott, 4 kérés 82-t, 8 kérés 109-et és 16 kérés 150-et. Az e-mail ügynökünk hosszabb promptjaival 4 kérés 81-et, 8 kérés 113-at és 16 kérés már csak 87-et adott: nyolc ilyen kérésen túl a továbbiak lassították a rendszert.

Egy délután az egyik példány legfeljebb 12, a másik pedig 8 kérést szolgált ki egyszerre. Az első másodpercenként 91–93 tokent termelt, és percenként 26–27 kérést fejezett be; a második másodpercenként 81–83 tokent és percenként 22 kérést. Mindkettő most 12-t fogad.

Amiről lemondtunk

Hely. A felosztott modellnek több mint hárommillió tokenes gyorsítótára volt; a példányoknak két kisebb van, és egy kérés csak annak a példánynak a gyorsítótárát használhatja, amely kiszolgálja. Ügynökeink sok rövid és közepes kérést küldenek, és számukra az áteresztőképesség volt fontosabb. Ha Ön néhány nagyon hosszú kontextust szolgál ki egyszerre, a felosztás még mindig jobb választás lehet. Megtartottuk a felosztott beállítást, és a visszatérés egy szkript.

Ami a váltás során elromlott

1. Tizenegy perc modell nélkül, majd 30 másodpercnyi 502-es hiba. A felosztott modellnek le kellett állnia, mielőtt egy másolat betölthetett volna ugyanazokon a gépeken, így az ügynökeink kb. tizenegy percet vártak. Amikor az első másolat elindult, a proxy még kb. 30 másodpercig „502 no live upstreams” választ adott: a háttérszervereket hibásnak jelölte, amíg le voltak állva (max_fails=3, fail_timeout=30s), és nem próbálta újra őket, amíg ez az idő le nem járt.
2. Egy ügyfél, amely kihagyta a proxyt. Az egyik kötegelt feladatunk konfigurációjában az első gép címe szerepelt, így a teljes terhelés egyetlen példányra került, miközben a másiknak volt szabad kapacitása. Most minden ügyfél a proxyn keresztül megy; a gépek saját címei csak az állapotellenőrzésekhez valók.
3. Ugráló metrikák. A teljesítményfigyelőnk a proxy-n keresztül olvasta a vLLM /metrics végpontját. Két háttérszerverrel az egymást követő leolvasások különböző másolatokból származtak, a számlálók oda-vissza ugráltak, és a figyelő éhezőnek jelentette a modellt. Most minden másolatot közvetlenül olvas, és összeadja az értékeket.
4. Egy régi őrszem, amely leállította volna az új másolatot. A felosztott beállításban volt egy őrszem, amely újraindította a szolgáltatást, amikor a modell abbahagyta a válaszadást. Az új szolgáltatás Conflicts= kapcsolatot hoz létre a régivel, így ez az újraindítás leállította volna az új másolatot. Ki kellett kapcsolni a systemctl disable --now paranccsal, nem csak leállítani, mert az üzemeltetési rétegünk újraindítja az engedélyezett, de nem futó egységeket.
5. Memória a többi feladatot is végző gépen. Az egyik gép az adatbázisainkat és a weboldal-építéseket is futtatja. A vLLM gpu-memory-utilization értékének 0,78-as beállításával csak 5 GiB maradt minden másra, ezért 0,74-re csökkentettük, és csak azt a másolatot indítottuk újra, miközben a másik vitte a terhelést. Ezeken a gépeken a vLLM-nek adott memóriaarány ugyanabból a memóriából jön, mint minden más.

Ha két ilyen gépe van

• Ha a modell és a szükséges gyorsítótár egy gépre fér, futtasson egy-egy példányt mindegyiken, legalacsonyabb kapcsolatszámú proxy mögött. A modellt csak akkor ossza szét, ha egyetlen gép sem bírja el a szükséges gyorsítótárat.
• Irányítsa az összes ügyfelet a proxyra, az kötegelt feladatokat és a régi konfigurációkat is.
• Olvassa ki a mutatókat közvetlenül minden egyes példányból.
• Minden gépnek adja meg a saját memóriamegosztását, attól függően, hogy mi fut még rajta.
• Állítsa be, hogy egy másolat egyszerre hány kérést szolgáljon ki a saját forgalmával: a mi összeállításunkban a 12 jobban teljesített, mint a 8.
• Számítson arra, hogy a váltás addig tart, amíg egy másolat elindul, és tervezzen ezzel.

Factory Floor szállítja a proxy- és indítási konfigurációkat egy vagy két géphez, az állapotellenőrzést és az eszközhasználati tesztet, amelyet a modellváltás előtt futtatunk, valamint az őrszemeket és a memóriabiztonsági korlátokat a gép többi részéhez.