To maskiner i DGX Spark-klassen, én modell: en kopi på hver maskin slår splitten
Drift
I syv uker kjørte vår lokale språkmodell splittet over to NVIDIA GB10-maskiner med tensortilpasning. Den 22. oktober erstattet vi dette med en full kopi av modellen på hver maskin og en least-connection-proxy foran. Gjennomstrømmingen gikk fra omtrent 180 til 210 tokens i sekundet, og begge maskinene kan nå starte på nytt uten å ta modellen ut av drift.
Hvorfor vi hadde splittet den
Hver maskin har 128 GB minne som CPU-en og GPU-en deler. I september passet modellen på én maskin, men cachen passet så vidt: vLLM-bygget vi brukte kunne ikke holde denne modellens KV-cache i FP8, så cachen var i BF16, og én maskin hadde plass til 499 110 tokens av den. Det er færre enn to forespørsler ved modellens fulle kontekst på 262 144 tokens. Splittet over begge maskinene med tensortilpasning over deres direkte nettverkslenke, vokste cachen til mer enn tre millioner tokens. Vi hadde splittet modellen for plass, ikke for hastighet.
Hva endret seg
Et nyere 4-biters bygg av samme modell (NVFP4, laget med kvantiseringsbevisst distillasjon) bruker omtrent 71 GiB minne, og et community-vLLM-bygg for GB10 (eugr/spark-vllm-b12x) kjører cachen i FP8. Nå holder én maskin hele modellen og en cache på 0,76 til 1,08 millioner tokens, plass til 2,9 til 4,1 forespørsler ved full kontekst, avhengig av hvor mye minne maskinen gir den. Begge kopiene bruker modellens egen spekulativ dekoding (MTP, fire utkast-tokens). Før vi byttet kjørte vi verktøykalletesten vår på det nye bygget: det scoret 86, bygget det erstattet scoret 75.
Det vi målte
| Splittet over to maskiner | En kopi på hver maskin | |
|---|---|---|
| KV-cache | mer enn 3 millioner tokens | 0,76 og 1,08 millioner tokens |
| Forespørsler ved full kontekst | omtrent 12 | 2,9 og 4,1 |
| Gjennomstrømning under vår belastning | omtrent 180 tokens/s | 210 tokens/s (111 + 99) |
| Oppstart | omtrent 20 minutter | 5 til 13 minutter per kopi |
| Én maskin starter på nytt | modellen er nede | den andre kopien tjener |
Én kopi alene, etter antall forespørsler den betjener samtidig: med korte prompter ga 1 forespørsel 36 tokens i sekundet, 4 ga 82, 8 ga 109 og 16 ga 150. Med våre e-postagenters lengre prompter ga 4 forespørsler 81, 8 ga 113 og 16 bare 87: etter åtte slike forespørsler ble det tregere med flere.
I løpet av en ettermiddag tok den ene kopien maksimalt 12 forespørsler samtidig, og den andre 8. Den første produserte 91 til 93 tokens i sekundet og fullførte 26 til 27 forespørsler i minuttet; den andre 81 til 83 tokens i sekundet og 22 forespørsler i minuttet. Begge tar nå 12.
Det vi ga slipp på
Plass. Den delte modellen hadde én cache på over tre millioner tokens; kopiene har to mindre, og en forespørsel kan bare bruke cachen til kopien som betjener den. Våre agenter sender mange korte og middels lange forespørsler, og for dem betydde gjennomstrømning mer. Hvis du betjener noen få svært lange kontekster samtidig, kan deling fortsatt være det beste valget. Vi beholdt den delte oppsettet, og å bytte tilbake er ett skript.
Hva gikk galt under byttet
- Elleve minutter uten modell, så 30 sekunder med 502-feil. Den delte modellen måtte stoppe før en kopi kunne lastes på de samme maskinene, så agentene våre ventet i omtrent elleve minutter. Da den første kopien var oppe, fortsatte proxyen å svare «502 no live upstreams» i omtrent 30 sekunder til: den hadde markert backendene som feilende mens de var nede (max_fails=3, fail_timeout=30s) og prøvde dem ikke igjen før tiden gikk ut.
- En klient som hoppet over proxyen. Én av batch-jobbene våre hadde adressen til den første maskinen i konfigurasjonen, så hele lasten gikk til én kopi mens den andre hadde kapasitet til overs. Nå går alle klienter gjennom proxyen; maskinenes egne adresser er kun for tilstandskontroller.
- Metrikk som hoppet. Overvåkeren for gjennomstrømning leste vLLMs /metrics via proxyen. Med to backendene kom påfølgende lesinger fra ulike kopier, tellerne hoppet frem og tilbake, og overvåkeren rapporterte modellen som uttømt. Den leser nå hver kopi direkte og summerer dem.
- En gammel overvåker som ville stoppet den nye kopien. Oppsettet med oppdeling hadde en overvåker som startet tjenesten på nytt når modellen sluttet å svare. Den nye tjenesten erklærer Conflicts= med den gamle, slik at omstarten ville stoppet den nye kopien. Den måtte slås av med
systemctl disable --now, ikke bare stoppes, fordi driftslaget vårt starter enheter på nytt som er aktivert, men ikke kjører. - Minne på maskinen som utfører annet arbeid. Én maskin kjører også databasene våre og bygging av nettsteder. Med vLLMs gpu-memory-utilization på 0,78 var det bare 5 GiB igjen til alt annet, så vi senket det til 0,74 og startet bare den kopien på nytt mens den andre tok lasten. På disse maskinene tas andelen du gir vLLM fra samme minne som alt annet.
Hvis du har to slike maskiner
- Hvis modellen og cachen du trenger får plass på én maskin, kjør en kopi på hver bak en proxy med minst tilkoblinger. Del bare modellen når én maskin ikke kan huse cachen du trenger.
- Pek alle klienter mot proxien, inkludert batchjobber og gamle konfigurasjoner.
- Les måledata fra hver kopi direkte.
- Gi hver maskin sin egen minneandel, i henhold til hva som ellers kjører på den.
- Sett hvor mange forespørsler en kopi tjener samtidig med din egen trafikk: for vår blanding slo 12 8.
- Forvent at byttet tar modellen vekk så lenge det tar en kopi å starte, og planlegg for det.
Factory Floor leverer proxien og oppstartskonfigurasjonene for én eller to maskiner, tilstandskontrollen og verktøytesten vi kjører før vi bytter modeller, med overvåkere og minnesikringer for resten av maskinen.