Det vigtigste ved DGX Spark for udviklere er ikke »en GPU under skærmen«. Det er 128 GB kohærent samlet systemhukommelse på en Grace Blackwell GB10 samt en softwarevej, som NVIDIA understøtter med DGX OS, containere og klyngedannelse. Kombinationen ændrer, hvad du kan hoste lokalt, men fjerner ikke hukommelsesberegninger, fejl i serveringssoftwaren eller cloudøkonomi.
Artiklen er den driftsmæssige ledsager til hvad DGX Spark er. Specifikationer og produktudsagn er forankret i NVIDIAs produktside og udgivelsesnoter (dokumentationen blev kontrolleret 2026-08-04).
Lokal inferens bruger stadig betydelig strøm og afgiver meget varme. Dimensionér strømkredse og køling til vedvarende belastning, ikke til en inaktiv demonstration. Eksponér ikke OpenAI-kompatible porte på det offentlige internet uden autentificering, TLS og netværkspolitik.
Samlet hukommelse: Hvad »128 GB kohærent« betyder i praksis
På en klassisk maskine med en diskret GPU planlægger du med GPU-VRAM til modelvægte og KV-cache samt værtshukommelse til alt andet, med dyre kopier over PCIe-grænsen.
På Spark præsenterer NVIDIAs arkitektur kohærent samlet systemhukommelse: CPU og GPU deler én stor pulje på 128 GB LPDDR5x ifølge NVIDIA. For serveringsdesignet betyder det:
- Store modelvægte kan ligge i den samme pulje, som kørselsmiljøet bruger til aktiveringer og KV-cache.
- Der er stadig et hårdt loft: Modelvægte, KV-cache, frameworkets overhead, operativsystemet og andre tjenester skal kunne være i hukommelsen samtidig.
- Egenskaberne for båndbredde og latenstid adskiller sig fra datacenter-GPU’er med meget HBM. NVIDIA angiver hukommelsesbåndbredde på produktsiden; betragt den som en hardwaregrænse, ikke et løfte om tokens pr. sekund.
Et omtrentligt hukommelsesbudget, illustrativt og ikke en garanti
Brug dette som en planlægningsskitse. Det præcise hukommelsesforbrug afhænger af arkitektur, kvantisering og serveringsmotor.
| Forbruger | Hvad det spiser |
|---|---|
| Modelvægte | Dominerende post; FP4/FP8/INT4 ændrer kurven markant |
| KV-cache | Vokser med kontekstlængde × samtidige sekvenser |
| Kørselsmiljø / CUDA-grafer / softwareframework | Betydeligt fast merforbrug |
| Operativsystem + Docker + agenter + overvågning | Let at undervurdere på en »dedikeret« maskine |
| Reserve | Bevar en margen til spidsbelastninger og opgraderinger |
Budgettér efter den målte maksimale samtidighed, ikke efter én chatsession. Vækst i KV-cachen er én risiko for at løbe tør for hukommelse. Genskab den med en belastningstest i stedet for at behandle et hypotetisk svigt med to sessioner som en historisk hændelse.
Sådan læses NVIDIAs udsagn om 200B-klassen på én node
NVIDIA markedsfører DGX Spark til AI-modeller med op til cirka 200 milliarder parametre på én skrivebordsenhed med den store samlede hukommelse. Læs det som:
- Leverandørens udsagn om funktionalitet, ikke en målt serviceniveauaftale for alle åbne modelcheckpoints.
- Implicit knyttet til effektiv præcision, fordi NVIDIA fremhæver en maksimal ydelse i FP4-klassen på op til 1 PFLOP FP4, samt til en understøttet serveringsvej.
- Uafhængigt af, om din foretrukne model, tokenizer, skabelon til værktøjskald og evalueringssæt fungerer godt i den størrelse.
Hvad udsagnet ikke siger:
- 200B parametre ved fuld præcision, lang kontekst og høj samtidighed.
- Samme kvalitet som førende hostede modeller på vanskelige opgaver.
- Et specifikt tokens/s-tal, du kan sætte i en kundekontrakt.
Til større modeller eller tensorparallel servering dokumenterer NVIDIA skalering på flere noder via ConnectX-7, ofte omtalt som 2–4 Spark-enheder. Se dokumentationen om klyngedannelse og forbind to Spark-enheder. Opskrifter fra fællesskabet, for eksempel tensorparallel vLLM over RoCE, er specifikke for opskriften. Betragt deres tal for tokens pr. sekund og maksimal kontekst som rapporter, der skal måles igen, ikke som universelle garantier.
Dokumenterede kandidater til serveringsstakken
En nyttig mental model:
DGX OS (Ubuntu-baseret NVIDIA-stak)
→ NVIDIA-drivere / containerkørselsmiljø
→ Serveringscontainer (vLLM, TensorRT-LLM, NIM eller andet)
→ OpenAI-kompatibel HTTP (eller gRPC)
→ Agenter / n8n / apps på LAN
DGX OS og containere
DGX Spark kører DGX OS. Planlæg opdateringer, genstartsvinduer og Docker-tilladelser eller tilsvarende på samme måde som for enhver inferensvært. NVIDIAs vejledninger forudsætter en aktuel installation af DGX OS og fungerende nvidia-smi samt GPU-adgang fra containere, før modelrelaterede fejl undersøges.
Serveringsmuligheder: Vælg efter kriterier, ikke mode
| Stak | Typisk grund til at vælge den | Forbehold |
|---|---|---|
| vLLM | OpenAI-kompatibel servering, bred dækning af åbne modeller og opskrifter til flere noder | Kompatibilitet mellem version og kvantisering; tilpas maksimalt antal sekvenser og KV-cache |
| TensorRT-LLM (TRT-LLM) | NVIDIA-optimerede motorer til understøttede modeller | Omkostning ved at bygge motoren og en smallere optimal vej for hver model |
| NVIDIA NIM / NGC-veje | Når du ønsker en NVIDIA-pakket mikrotjeneste til en model på listen | Modelkatalog og licensvilkår; ikke alle Hugging Face-checkpoints |
| llama.cpp / Ollama-klassen | Enkel lokal brugeroplevelse til mindre eller kvantiserede modeller | Er muligvis ikke vejen til de største arbejdsbelastninger i Spark-klassen |
Vejledningerne i NVIDIA dgx-spark-playbooks dækker vLLM, TRT-LLM, Ollama og beslægtede veje. Start evalueringen fra en aktuel vejledning, som leverandøren dokumenterer, fastlås alle artefakter, og tilpas først efter at have genskabt et udgangspunkt på enheden.
Slutpunkt til agenter
De fleste integrationer i en SMV, for eksempel n8n, Hermes, OpenClaw og specialbyggede apps, forventer en OpenAI-kompatibel basis-URL til /v1/chat/completions på LAN eller VPN. Hold denne kontrakt stabil, selv hvis serveringsmotoren bagved udskiftes. Log model-id, kvantisering og serverversion ved hver evaluering, så en forringelse kan diagnosticeres.
Måleprotokol (minimum)
Før du kalder en lokal model »produktion«:
- Start med et evalueringssæt på 20–50 prompts, der repræsenterer den reelle opgave, ikke en legetøjschat, og udvid det, efterhånden som nye fejlklasser opdages. Intervallet er til en indledende kontrol, ikke en statistisk garanti.
- Registrér dato, version af serveringsmotoren, model-id, præcision, maksimal kontekst og samtidighed.
- Mål p50/p95-latenstid og raten af OOM-fejl eller timeouts ved denne samtidighed.
- Scor kvalitet med en menneskelig rubrik eller automatiserede tjek, du stoler på til den opgave.
- Kør den samme protokol igen efter hver opgradering af motoren eller operativsystemet.
Uden den sløjfe bliver Spark folklore: »det føltes hurtigt i tirsdags«.
Fejltilstande, du bør designe for
| Fejl | Symptom | Mitigation |
|---|---|---|
| Modelvægte/KV-cache løber tør for hukommelse | Processen afsluttes, CUDA OOM eller fastlåste arbejdsprocesser | Sænk kontekst, samtidighed eller præcision; fordel over flere noder |
| Begrænsning på grund af varme eller strøm | Markante spring i latenstid ved vedvarende belastning | Mål under belastning; kontrollér luftgennemstrømning og strømkreds |
| Forældet container eller uens driverversion | Uforklarlige nedbrud efter en OS-opdatering | Fastlås versioner; kør en grundlæggende test efter hver opdatering |
| Fuldt lager med modelcache | Fejl ved hentning og beskadigede lag | Dimensionér NVMe til modeller og logfiler; ryd cacher |
| Nedbrud på én node | Agenter fortsætter usikkert eller fejler uden signal | Sundhedstjek og en reserverute til cloud eller SaaS |
| API uden autentificering | Alle på LAN kan hente fra den private model | Bind til en privat grænseflade; brug autentificering og netværks-ACL |
| Kvalitetsfald efter kvantisering | Flydende nonsens på vanskelige opgaver | Opgavespecifikt evalueringssæt før produktionssætning |
| Misbrug af agentværktøjer | Lokal model og shell er ikke i sig selv sikkert | Sandkasse, se NemoClaw, samt positivlister |
Lokalt betyder ikke, at intet logges. Fastlæg opbevaringen af prompts, værktøjsspor og hentede dokumenter. Diskkryptering og adgangskontrol er lige så vigtige som fraværet af et cloud-API.
Hvornår cloud stadig vinder
Hold en skrevet regel, ikke en fornemmelse:
Foretræk cloud eller administreret inferens, når:
- Du har brug for en førende kvalitet, som den lokale åbne model ikke matcher på dit evalueringssæt.
- Belastningen kommer i spidsbelastninger, og kapitaludgiften til inaktiv tid dominerer.
- Du mangler driftskapacitet til DGX OS, containere og vagtordning.
- Du har brug for høj tilgængelighed på tværs af regioner eller leverandørens serviceniveauaftaler.
- Den model eller modalitet, du har brug for, er endnu ikke tilgængelig eller stabil på Sparks serveringsvej.
Foretræk Spark (eller Spark + anden node) når:
- Dataene skal forblive lokalt eller på et kontrolleret LAN for den pågældende arbejdsgang.
- Latenstiden til en lokal agentsløjfe er vigtigere end den højeste mulige modelkvalitet.
- En stabil inferensmængde afskriver kapitaludgiften over tid.
- Du kan bemande opdateringer, evalueringer og hændelseshåndtering.
Omkostningsramme uden falsk præcision
Opfind ikke en måned for rentabilitet ud fra et blogindlæg. Byg en kort model med tydeligt markerede antagelser:
| Input | Kilde |
|---|---|
| Hardware, afgifter og levering | Dateret tilbud fra forhandler eller NVIDIA |
| Strøm, kontinuerlig drift kontra driftscyklus | Målt forbrug eller PSU/TDP-oplysninger × lokal kWh-pris, markeret som estimat |
| Ingeniørtimer pr. måned | Dine faktiske lønomkostninger |
| Cloudalternativ | Aktuel pris pr. token eller GPU-time for samme kvalitetskrav |
Hvis cloudalternativet er billigere og acceptabelt for dataklassen, er Spark valgfrit. Hvis dataklassen udelukker cloudvejen, er kapitaludgiften en omkostning ved efterlevelse, ikke en optimering af tokens pr. sekund.
En hybridløsning er fortsat det modne mønster: Klassificér forespørgslen, send begrænset arbejde til den lokale rute, og send offentligt arbejde eller vanskelige ræsonnementsopgaver til godkendte hostede modeller efter maskering af følsomme data. Det følger samme ramme som udrulningsmønstre for privat AI.
Tjekliste til udvikleren for én node
- Kontrollér DGX OS, driver og
nvidia-smipå et nyopdateret udgangspunkt. - Vælg én serveringsstak og én model til den første kandidatvej til produktion.
- Mål indlæsningstid, tokens pr. sekund ved fast samtidighed, maksimal kontekst før OOM og kvalitet på et fast evalueringssæt; datér kørslen.
- Eksponér kun OpenAI-kompatibel HTTP på en privat grænseflade med autentificering.
- Tilføj sundhedstjek og en dokumenteret reserveløsning i cloud.
- Først derefter forbind agenter, kanaler eller n8n.
Gør ikke dette endnu
- Lov ikke kunder »200B lokalt« uden at angive præcision, kontekst og målt latenstid.
- Kør ikke den første agent med ubegrænset shelladgang på den samme vært, som indeholder produktionshemmeligheder.
- Spring ikke dokumentationen om flere noder over, og forvent ikke, at QSFP på magisk vis løser OOM på én node.
- Brug ikke et skærmbillede fra fællesskabet med tokens pr. sekund til kapacitetsplanlægning.
Lokal inferens på Spark er reel, når hukommelsesbudgettet, serveringsstakken og driftsdisciplinen er reelle. Hardwaren fjerner én klasse af VRAM-lofter, men fjerner ikke behovet for ingeniørarbejde.
