Det som gör DGX Spark intressant för utvecklare är inte ”en GPU under skärmen”. Det är 128 GB koherent enhetligt systemminne på en Grace Blackwell GB10, tillsammans med en programvarustack som NVIDIA stöder (DGX OS, containrar och klustring). Kombinationen förändrar vad du kan köra lokalt – men den upphäver varken minnesmatematiken, problemen som kan uppstå vid inferensdrift eller molnets ekonomi.
Det här är den praktiska fortsättningen på vad DGX Spark är. Specifikationer och leverantörsuppgifter bygger på NVIDIA:s produktsida och versionsinformation (dokumentationen kontrollerades 2026-08-04).
Lokal inferens kräver fortfarande avsevärd el och alstrar mycket värme. Dimensionera elmatning och kylning för kontinuerlig belastning, inte för en demonstration i viloläge. Exponera inte OpenAI-kompatibla portar mot internet utan autentisering, TLS och nätverkspolicy.
Enhetligt minne: vad ”128 GB koherent” betyder i praktiken
I en klassisk maskin med separat GPU behöver du avsätta GPU-minne (VRAM) för vikter och KV-cache och systemminne för allt annat – med kostsamma kopieringar över PCIe-gränsen.
På Spark använder NVIDIA:s arkitektur koherent enhetligt systemminne: CPU och GPU delar på en stor minnespool (128 GB LPDDR5x enligt NVIDIA). För inferenslösningen innebär det följande:
- Stora modellvikter kan ligga i samma pool som körmiljön använder för aktiveringar och KV-cache.
- Det finns fortfarande ett hårt tak: vikter, KV-cache, ramverkets fasta minnesbehov, operativsystemet och övriga tjänster måste få plats.
- Bandbredds- och latensegenskaper skiljer sig från HBM-tunga datacenter-GPU:er. NVIDIA listar minnesbandbredd på produktsidan; behandla den som en hårdvarugräns, inte som ett löfte om token per sekund.
Ungefärlig minnesbudget (illustrativ, inte en garanti)
Använd tabellen som en grov planeringsskiss. Det exakta minnesbehovet beror på arkitektur, kvantisering och inferensmotor.
| Förbrukare | Vad den tar |
|---|---|
| Modellvikter | Dominerande term; FP4/FP8/INT4 ändrar kurvan kraftigt |
| KV-cache | Växer med kontextlängd × samtidiga sekvenser |
| Körmiljö, CUDA-grafer och ramverk | Ett betydande fast minnesbehov |
| OS, Docker, agenter och övervakning | Lätt att underskatta på en ”dedikerad” maskin |
| Marginal | Lämna utrymme för toppar och uppgraderingar |
Utgå från det uppmätta högsta antalet samtidiga kontexter, inte från en enda chatt. En växande KV-cache är en möjlig orsak till minnesbrist. Återskapa problemet med ett lasttest i stället för att beskriva ett hypotetiskt fel med två sessioner som om det redan hade inträffat.
Så ska NVIDIA:s uppgift om ~200B parametrar på en nod tolkas
NVIDIA marknadsför DGX Spark för AI-modeller upp till ~200 miljarder parametrar på en skrivbordsenhet med det stora enhetliga minnet. Läs det som:
- En uppgift från leverantören om möjlig kapacitet, inte ett uppmätt servicenivåavtal för varje öppet tillgänglig modell-checkpoint.
- Underförstått kopplat till effektiv precision (NVIDIA lyfter fram en topprestanda på upp till 1 PFLOP i FP4) och en inferenslösning som stöds.
- Säger inget om huruvida din föredragna modell, tokeniserare, mall för verktygsanrop och utvärderingssvit fungerar väl i den storleken.
Vad påståendet inte säger:
- 200B i full precision vid lång kontext och hög samtidighet.
- Samma kvalitet som de bästa molnbaserade modellerna på svåra uppgifter.
- En specifik siffra för token per sekund som du kan skriva in i ett kundavtal.
För större modeller eller tensorparallell inferens dokumenterar NVIDIA skalning över flera noder (ofta 2–4 Spark-enheter) via ConnectX-7. Se dokumentationen om klustring och koppla samman två Spark-enheter. Recept från användargemenskapen, till exempel tensorparallell vLLM över RoCE, är specifika för respektive recept. Mät därför själv token per sekund och maximal kontext på nytt i din egen miljö; de publicerade uppgifterna är inga allmänna garantier.
Dokumenterade alternativ för programvarustacken
En användbar mental modell:
DGX OS (Ubuntu-baserad NVIDIA-stack)
→ NVIDIA-drivrutiner / containerkörmiljö
→ Inferenscontainer (vLLM, TensorRT-LLM, NIM eller annan)
→ OpenAI-kompatibel HTTP (eller gRPC)
→ Agenter / n8n / appar på LAN
DGX OS och containrar
DGX Spark kör DGX OS. Planera uppdateringar, omstartsfönster och Docker- (eller motsvarande) behörigheter på samma sätt som för vilken inferensvärd som helst. NVIDIA:s handböcker förutsätter en aktuell DGX OS-installation och fungerande nvidia-smi samt GPU-åtkomst från containrar innan du börjar jaga modellbuggar.
Inferensmotorer (välj efter kriterier, inte efter mode)
| Stack | Typisk anledning att välja den | Varningar |
|---|---|---|
| vLLM | OpenAI-kompatibelt API, brett stöd för öppna modeller, lösningar för flera noder | Kompatibilitet mellan version och kvantisering; justera högsta antal sekvenser och utrymme för KV-cache |
| TensorRT-LLM (TRT-LLM) | NVIDIA-optimerade motorer för de modeller som stöds | Kostnad för att bygga motorn; smalare ”bästa väg” per modell |
| NVIDIA NIM och NGC-vägar | När du vill ha en NVIDIA-paketerad mikrotjänst för en listad modell | Modellkatalog och licensvillkor; inte varje modell-checkpoint på Hugging Face |
| llama.cpp och Ollama-liknande verktyg | Enkel lokal användning för mindre eller kvantiserade modeller | Kanske inte rätt val för de största arbetslasterna på Spark |
Exempelkonfigurationerna i NVIDIA dgx-spark-playbooks omfattar vLLM, TRT-LLM, Ollama och närliggande alternativ. Börja utvärderingen med en aktuell konfiguration som leverantören dokumenterar, lås alla komponentversioner och anpassa först när du har återskapat ett referensresultat på själva enheten.
API för agenter
De flesta integrationer i mindre företag (n8n, Hermes, OpenClaw och egna appar) förväntar sig en OpenAI-kompatibel basadress för /v1/chat/completions på det lokala nätet eller via VPN. Håll API-kontraktet stabilt även om du byter inferensmotor bakom det. Logga modell-id, kvantisering och serverversion vid varje utvärderingskörning så att en kvalitetsförsämring går att felsöka.
Mätprotokoll (minimum)
Innan du kallar en lokal modell produktionsklar:
- Börja med en utvärderingsuppsättning på 20–50 promptar som motsvarar det verkliga arbetet, inte en förenklad testchatt. Utöka den när du upptäcker nya feltyper. Antalet räcker för ett grundläggande funktionstest, men ger ingen statistisk garanti.
- Registrera datum, inferensmotorns version, modell-id, precision, maximal kontext och samtidighet.
- Mät p50- och p95-latens samt andelen fall med slut på minne eller tidsgräns vid den samtidigheten.
- Poängsätt kvaliteten med en mänsklig bedömningsmatris eller automatiska kontroller som du litar på för uppgiften.
- Kör om samma protokoll efter varje uppgradering av motor eller operativsystem.
Utan den återkopplingen bygger kunskapen om Spark på hörsägen: ”det kändes snabbt förra tisdagen.”
Fellägen som lösningen måste hantera
| Fel | Symtom | Motåtgärd |
|---|---|---|
| Slut på minne för vikter eller KV | Processen dödas, CUDA-minnesfel, hängande arbetare | Sänk kontext, samtidighet eller precision; dela upp över noder |
| Begränsad prestanda på grund av värme eller ström | Latensen försämras kraftigt under ihållande last | Mät under last; kontrollera luftflöde och elmatning |
| Inaktuell container eller inkompatibel drivrutin | Oförklarliga krascher efter OS-uppdatering | Lås versioner; kör ett grundläggande funktionstest efter varje uppdatering |
| Full disk (modellcache) | Misslyckade hämtningar, skadade lager | Dimensionera NVMe för modeller och loggar; rensa cacheminnen |
| Avbrott på den enda noden | Agenter fortsätter utan skydd eller slutar svara | Hälsokontroller; reservväg till moln eller SaaS |
| Oautentiserat API | Vem som helst på nätet kan använda din privata modell | Lyssna endast på ett privat gränssnitt; autentisering; nätverks-ACL |
| Kvalitetsras vid kvantisering | Välformulerade men felaktiga svar på svåra uppgifter | Uppgiftsspecifik utvärderingsmängd före driftsättning |
| Missbruk av agentverktyg | En lokal modell med åtkomst till kommandoskalet är inte säker | Sandlåda (se NemoClaw); tillåtelselistor |
Lokalt betyder inte att ingenting loggas. Bestäm lagringstid för prompter, verktygsspår och hämtade dokument. Diskkryptering och åtkomstkontroll spelar lika stor roll som ”inget moln-API.”
När molnet fortfarande vinner
Behåll en skriven regel, inte en känsla:
Föredra molnet eller en hanterad inferenstjänst när:
- Du behöver en kvalitet i toppklass som den lokala öppna modellen inte når på din utvärderingsmängd.
- Lasten är ojämn med tillfälliga toppar och investeringen står oanvänd större delen av tiden.
- Du saknar driftkapacitet för DGX OS, containrar och jour.
- Du behöver hög tillgänglighet i flera regioner eller servicenivåavtal från leverantören.
- Den modell eller modalitet du behöver är ännu inte tillgänglig eller stabil i Spark-enhetens inferenslösning.
Föredra Spark (eller Spark plus en andra nod) när:
- Data måste stanna i egen drift eller på ett kontrollerat nät för det arbetsflödet.
- Latensen till en agentslinga på skrivbordet eller det egna nätet spelar större roll än absolut toppkvalitet.
- En jämn inferensvolym gör att investeringen lönar sig över tid.
- Du kan avsätta personal för säkerhetsuppdateringar, utvärderingar och incidenthantering.
Kostnadsram utan falsk precision
Hitta inte på vilken månad investeringen går jämnt upp utifrån ett blogginlägg. Gör en enkel kalkyl med tydligt angivna antaganden:
| Indata | Källa |
|---|---|
| Hårdvara + skatter + frakt | Daterad återförsäljar- eller NVIDIA-offert |
| Ström (kontinuerlig kontra driftcykel) | Uppmätt förbrukning eller uppgifter om nätaggregat och TDP × lokalt kWh-pris – märk som uppskattning |
| Ingenjörstimmar per månad | Din faktiska lönekostnad |
| Molnalternativ | Aktuellt token- eller GPU-timpris för samma kvalitetsribba |
Om molnalternativet är billigare och acceptabelt för dataklassen är Spark valfritt. Om dataklassen förbjuder molnvägen är investeringen en kostnad för regelefterlevnad, inte en optimering av token per sekund.
En hybridlösning är fortfarande det mogna valet: klassificera förfrågan, dirigera skyddsvärt arbete lokalt och skicka offentligt material eller uppgifter som kräver avancerat resonemang till godkända molnmodeller efter maskering. Det är samma ramverk som i mönster för privat AI-driftsättning.
Checklista för en enda nod
- Bekräfta DGX OS, drivrutin och
nvidia-smiefter en aktuell grundinstallation med samtliga planerade uppdateringar. - Välj en programvarustack och en modell för den första lösning som ska utvärderas för produktion.
- Mät: laddningstid, token per sekund vid fast samtidighet, största kontext innan minnet tar slut, och kvalitet på en fast utvärderingsmängd (datera körningen).
- Exponera OpenAI-kompatibel HTTP endast på ett privat gränssnitt med autentisering.
- Lägg till hälsokontroller och en dokumenterad reservväg i molnet.
- Koppla först därefter agenter, kanaler eller n8n.
Gör inte det här ännu
- Lova inte kunder ”200B lokalt” utan att namnge precision, kontext och uppmätt latens.
- Kör inte den första agenten med obegränsad åtkomst till kommandoskalet på samma värd som lagrar produktionshemligheter.
- Hoppa inte över dokumentationen för flera noder och förvänta dig att QSFP-magi löser minnesbrist på en enda nod.
- Behandla inte en skärmdump med token per sekund från användargemenskapen som kapacitetsplanering.
Lokal inferens på Spark fungerar när minnesbudgeten, programvarustacken och driftrutinerna fungerar. Hårdvaran undanröjer en typ av VRAM-begränsning; den undanröjer inte behovet av genomtänkt ingenjörsarbete.
