DGX Spark tillhör en smal kategori: en komplett NVIDIA-plattform avsedd att köra stora lokala modeller och agentarbetslaster på ett skrivbord, inte bara i ett rack. Den relevanta frågan för utvecklare och köpare är inte ”är det en superdator?” Frågan är om hårdvaran, programvaran och nätverket motsvarar en verklig privat AI-uppgift som ni har kompetens att driva.
Den här artikeln håller sig till NVIDIA:s publicerade beskrivning av produkten (dokumentationen stämdes av mot DGX Spark-produktsidan och versionsanteckningarna 2026-08-04) och kopplar den sedan till beslut om agenter i små och medelstora företag. Kompletterande artiklar behandlar verkligheten bakom lokal inferens, hur två Spark-enheter kopplas ihop och hur NemoClaw-agenter körs i en sandlåda.
Behandla ström, kylning, nätverk och fysisk åtkomst som centrala skyddsåtgärder. En inferensmaskin på skrivbordet med SSH, containrar och agentverktyg är fortfarande infrastruktur. Ett felkonfigurerat nätverk eller en agent med bred verktygsåtkomst kan flytta data eller köra kommandon som du inte avsåg.
Vad NVIDIA levererar (specifikationer, inte paroller)
NVIDIA beskriver DGX Spark som ett Grace Blackwell-system för skrivbordet, byggt kring GB10 Grace Blackwell Superchip. Följande specifikationer från NVIDIA har betydelse för planeringen:
| Område | NVIDIA-angiven detalj |
|---|---|
| SoC | NVIDIA GB10 Grace Blackwell |
| CPU | 20-kärnig Arm (10× Cortex-X925 + 10× Cortex-A725) |
| Minne | 128 GB LPDDR5x, koherent enhetligt systemminne |
| Toppprestanda AI | Upp till 1 PFLOP vid FP4 (leverantörens toppvärde; beror på arbetslasten) |
| Lagring | Upp till 4 TB NVMe (konfigurationsberoende) |
| Nätverk | 10 GbE RJ-45; ConnectX-7 NIC @ 200 Gbps (QSFP) |
| Trådlöst | Wi-Fi 7; Bluetooth 5.4 |
| Formfaktor | Kompakt skrivbordsenhet (cirka 150 × 150 × 50,5 mm enligt NVIDIA:s FACTS-uppgifter) |
| Programvarubas | DGX OS |
Två designval förklarar merparten av produktens värde:
- Koherent enhetligt minne — CPU och GPU delar en stor minnespool i stället för en begränsad, separat VRAM-pool på GPU:n och en egen pool för värdminne. Det är därför NVIDIA marknadsför modeller i parameterklassen ~200B på en enda enhet: arbetsuppsättningen kan rymmas i den koherenta poolen på 128 GB, beroende på kvantisering, kontextlängd och serveringsstack.
- ConnectX-7 vid 200 Gbps — två Spark-enheter (eller ett litet kluster) kan länkas för arbetslaster som inte får plats på en nod. NVIDIA dokumenterar detta under ConnectX-7 Networking / klustring och connect-two-sparks-playbooken.
Behandla inte ”upp till 1 PFLOP FP4” eller ”modeller upp till 200B” som en garanti för genomströmning. Det är NVIDIA:s uppgifter om kapacitet. Det faktiska antalet token per sekund, den maximala kontextlängden och antalet samtidiga agentsessioner beror på modell, precision, batchning och programvaruväg. Mät i din egen stack.
Pris: hitta inte på det
Butiks- och återförsäljarpriser förändras. AI Expert publicerar inte ett påhittat listpris här.
- Kontrollera NVIDIA:s köp- och produktsida för DGX Spark och auktoriserade återförsäljare för aktuella prisuppgifter.
- Om du hänvisar till en tredjepartsoffert i ett internt beslutsunderlag: datera den och namnge källan. Gårdagens foruminlägg är inte en inköpsorder.
CapEx är bara en del av TCO. Budgetera för ström, UPS- eller PDU-kapacitet, kylning vid skrivbord eller rack, extra lagring, tid för programvarudrift (serveringsstack, uppdateringar och utvärderingar) och de personer som ska ansvara för incidenter.
Vad som ändrats för lokala agenter
Före system som Spark betydde ”lokala agenter” ofta:
- Små modeller på en bärbar dator eller en arbetsstations-GPU.
- Moln-API:er för allt som krävde lång kontext eller starkare resonemang.
- Kluster i egen drift som såg ut som minidatacenter.
DGX Spark möjliggör ett annat upplägg:
| Förr (vanlig väg för mindre företag) | Med skrivbordssystem i Spark-klass |
|---|---|
| Känsligt arbete → företags-SaaS eller VPC | Känsliga agentflöden kan stanna på det egna nätet med öppna vikter |
| Lokalt = 7B–70B-klass på konsument-GPU:er | NVIDIA:s budskap: cirka 200B-klass på en nod (beror på precision och servering) |
| Flera GPU:er = serverrumsprojekt | Två enheter + QSFP för distribuerad servering och större modeller |
| Agenter på virtuella maskiner i molnet, med risk för datautflöde | Agenter och inferens på samma privata maskin (kräver ändå en sandlådepolicy) |
Det strategiska skiftet gäller gränsen, inte någon magisk kvalitetsökning. Du kan hålla prompter, verktygsutdata och privata korpusar borta från externa träningsflöden om du driver maskinen, håller den uppdaterad och begränsar agenten. Integritetsskydd är en egenskap hos driftsättningen, inte hos logotypen på chassit. Mönster för privat AI-driftsättning visar hur Spark passar bredvid SaaS, VPC och hybriddirigering.
Vad som inte ändrats:
- Molnbaserade toppmodeller överträffar fortfarande lokala alternativ i många svåra uppgifter inom resonemang och multimodalitet.
- Du behöver fortfarande utvärderingar, loggning och mänskliga kontrollpunkter för konsekvensrika åtgärder.
- En agent med kommandoskal, webbläsare och meddelandekanaler förblir en angreppsyta. Lokal inferens tar inte bort promptinjektion eller verktygsmissbruk.
Vem det är till för
Använd en beslutsram, inte en slagordsmässig målgruppsbeskrivning.
Passar bra när det mesta av detta stämmer:
- Dataklassificeringen säger att konfidentiellt eller skyddsvärt arbete inte ska lämna din miljö för det aktuella användningsfallet.
- Du behöver ständigt aktiva agentslingor eller låg latens för agentslingor på ett privat nät.
- Någon i teamet kan hantera Linux, containrar, SSH och modellservering (eller så anställer du den kompetensen).
- Du accepterar att äga hårdvarans livscykel: firmware, DGX OS-uppdateringar, disk och fysisk åtkomstkontroll.
- Du vill ha en väg från en nod till ett litet multinodkluster utan att hoppa rakt till ett fullt GPU-rack.
Passar sämre när:
- Arbetslasten är ojämn med tillfälliga toppar, körs sällan eller kräver den allra senaste toppmodellen varje vecka.
- Ingen kommer att ansvara för driften efter demonstrationsveckan.
- Du behöver elastisk kapacitet i flera regioner eller driftade servicenivåavtal.
- Inköp kräver en ren driftkostnadsmodell i molnet, med ett Business Associate Agreement (BAA) från leverantören och utan lokal hårdvara.
Köp Spark när integritetsgränsen och den lokala agentlatensen tillsammans motiverar investeringen och driften. Köp inte en Spark för att ”komma ikapp med AI” utan en namngiven arbetslast, en dataklass och en ägare.
Vem driver det
Behandla köpare och operatör som separata roller även i ett fempersonsföretag.
| Roll | Ansvar |
|---|---|
| Affärsägare | Användningsfall, dataklass, framgångsmått, budget |
| Plattformsägare | OS, nätverk, säkerhetskopior, åtkomstkontroll, uppdateringar |
| Modellägare | Serveringsstack, kvantisering, utvärderingar, återställning |
| Agentägare | Verktyg, tillåtelselistor för kanaler, mänskliga kontrollpunkter för godkännande |
Om en person har alla fyra rollerna, håll den första produktionsomfattningen smal: en modellslutpunkt, en agentyta och en loggningsväg.
Kapacitet du bör anta finns
En Spark ligger närmare en kompakt server än en LLM-app på en bärbar dator. Planera för:
- Omstarts- och uppdateringsfönster efter DGX OS- eller drivrutinsändringar.
- Diskväxt från modellvikter, containerlager och agentloggar.
- En namngiven person som kan tolka
nvidia-smi, containerloggar och en misslyckad hälsokontroll klockan 09:00. - Fysiskt ansvar: vem som kan koppla ur, skapa en avbildning av eller föra bort ett system vars lagring kan innehålla privata modeller, prompter och loggar.
Saknas den kapaciteten är företags-SaaS eller driftad VPC-inferens ett bättre val tills den finns. Hårdvara utan ägare blir ett ogranskat skuggsystem.
Jämförelseöversikt (beslutsunderlag, inte ett jämförande prestandatest)
| Alternativ | Styrka | Huvudkostnad |
|---|---|---|
| Konsument- eller företags-SaaS | Snabb förmåga, låg driftbörda | Extern behandlingsgräns; leverantörsvillkor |
| Moln-GPU eller driftad inferens | Elastisk, ingen hårdvara på skrivbordet | Löpande driftkostnad; utflödes- och lagringsplatsdesign |
| GPU-server i egen drift | Flexibel skala | Rack, ström, ML-drift |
| DGX Spark | Stor lokal minneskapacitet, NVIDIA:s programvaruväg och QSFP-klustring | Investering, driftägarskap, gränser för modell och servering |
Spark konkurrerar med ”privat arbetsstation eller minikluster”, inte med ”oändligt moln”. För många små och medelstora företag är det mogna svaret fortfarande en hybridlösning: SaaS för offentligt och internt arbete, Spark eller VPC för det konfidentiella agentflödet. Den portföljsynen följer samma logik som egen drift kontra driftad inferens.
Vad ”lokala agenter” faktiskt behöver utöver SoC:n
Att köpa Spark levererar inte en agent. En minimal privat agentstack behöver fortfarande:
- En serveringsslutpunkt (ofta OpenAI-kompatibel) med autentisering på ett privat gränssnitt.
- En agentkörmiljö med explicita verktyg och kanalregler (OpenClaw, Hermes, egen app eller NemoClaw i sandlåda).
- Policy: vad agenten får läsa, vilka externa mål den får ansluta till och vilka åtgärder som kräver en människa.
- Observerbarhet: anropsloggar, modellversion, felfrekvens och en återställningsväg.
NVIDIAs ekosystem (DGX OS, playbooks, NemoClaw/OpenShell, Sync) förkortar vägen. Det tar inte bort produktbesluten ovan. Team som hoppar över dem får en kraftfull demonstration som varken support eller regelefterlevnad kan ta över.
Inköps- och utrullningschecklista
- Namnge den första arbetslasten (supporttriage, intern efterforskning, driftagent – inte ”generell AI”).
- Klassificera de data som hamnar i prompter, verktyg och loggar.
- Bekräfta den fysiska platsen: elanslutning, kylning, stöld- och åtkomstkontroll samt reservström om upptid spelar roll.
- Bekräfta nätverksplanen: hantering över 10 GbE eller Wi-Fi, höghastighetsvägen över ConnectX-7 endast vid klustring.
- Tilldela plattforms- och agentägare före uppackning.
- Planera mätningen: latens, kvalitetsutvärderingar och felfrekvens – inte bara ”den svarade”.
- Planera återställningen: moln eller SaaS som reserv om den lokala modellen eller maskinen ligger nere.
- Läs om NVIDIA:s aktuella produktsida och användarhandboken för DGX Spark på inköpsdagen. Firmware och tillbehörslistor ändras.
- Avgör om framgång den första månaden betyder ”modellen kan leverera svar” eller ”en agent i en sandlåda slutför ett namngivet arbetsflöde med loggar”.
Gör inte det här ännu
- Dimensionera inte investeringen utifrån ett odaterat diagram över token per sekund i ett blogginlägg.
- Lägg inte in kunduppgifter från produktion i en obegränsad agent ”för att prova Spark”.
- Hoppa inte över klustringsdokumentationen och skyll sedan på kabeln när NCCL hänger sig.
- Anta inte att Wi-Fi 7 ersätter ConnectX-7 för distribuerad inferens.
- Behandla inte NVIDIA:s budskap om cirka 200B på en nod som ett löfte för varje öppet tillgänglig modell-checkpoint vid full precision och lång kontext.
Nästa steg
- Lokal inferensrealitet på Spark: minne, serveringsstackar, fellägen och när molnet fortfarande vinner.
- Koppla samman två DGX Spark-enheter: QSFP, SSH, RoCE, Cluster Assistant och återställning.
- NemoClaw-agenter i sandlåda på Spark: OpenShells policylager och Express Install.
DGX Spark är ett konkret privat beräkningsalternativ med publicerade specifikationer och en dokumenterad klustringsväg. Det förtjänar en plats i arkitekturen när datagränsen och agentarbetslasten är verkliga – och när någon kommer att driva maskinen efter att uppackningsbilderna är tagna.
