DGX Spark tilhører en snæver kategori: en komplet NVIDIA-platform, der er beregnet til at køre store lokale modeller og agentarbejdsbelastninger ved skrivebordet, ikke kun i et rack. Det relevante spørgsmål for udviklere og indkøbere er ikke, om den er en »supercomputer«, men om hardware, software og netværk passer til en reel opgave inden for privat AI, som organisationen kan bemande.
Artiklen holder sig til NVIDIAs offentliggjorte produktbeskrivelse. Dokumentationen blev kontrolleret igen 2026-08-04 mod produktsiden for DGX Spark og udgivelsesnoterne. Derefter kobles oplysningerne til beslutninger om agenter og SMV-drift. De tilhørende artikler handler om lokal inferens i praksis, forbindelsen mellem to Spark-enheder og NemoClaw-agenter i sandkasser.
Behandl strøm, køling, netværk og fysisk adgang som grundlæggende kontroller. En lokal inferensmaskine med SSH, containere og agentværktøjer er stadig infrastruktur. Et fejlkonfigureret netværk eller en agent med bred værktøjsadgang kan flytte data eller køre kommandoer, som du ikke havde til hensigt.
Hvad NVIDIA leverer: specifikationer, ikke slogans
NVIDIA beskriver DGX Spark som et kompakt Grace Blackwell-system bygget omkring GB10 Grace Blackwell Superchip. Disse af NVIDIAs angivne specifikationer er relevante for planlægningen:
| Område | NVIDIA-angivet detalje |
|---|---|
| SoC | NVIDIA GB10 Grace Blackwell |
| CPU | 20-core Arm (10× Cortex-X925 + 10× Cortex-A725) |
| Hukommelse | 128 GB LPDDR5x, kohærent samlet systemhukommelse |
| Maksimal AI-ydelse | Op til 1 PFLOP ved FP4 (leverandørens maksimum; afhænger af arbejdsbelastningen) |
| Lager | Op til 4 TB NVMe (konfigurationsafhængig) |
| Netværk | 10 GbE RJ-45; ConnectX-7 NIC @ 200 Gbps (QSFP) |
| Trådløst | Wi-Fi 7; Bluetooth 5.4 |
| Formfaktor | Kompakt skrivebordsenhed (~150 × 150 × 50,5 mm ifølge NVIDIAs emballageoplysninger/FACTS) |
| Softwarebase | DGX OS |
To designvalg er centrale for produktets anvendelighed:
- Kohærent samlet hukommelse — CPU og GPU deler én stor hukommelsespulje i stedet for en mindre ø med diskret GPU-VRAM og en separat pulje af værtshukommelse. Derfor markedsfører NVIDIA modeller i 200B-parameterklassen på én enhed: Arbejdsmængden kan ligge i den kohærente pulje på 128 GB, afhængigt af kvantisering, kontekstlængde og serveringsstak.
- ConnectX-7 ved 200 Gbps — to Spark-enheder eller en lille klynge kan forbindes til arbejdsbelastninger, som ikke passer på én node. NVIDIA dokumenterer dette under netværk og klyngedannelse med ConnectX-7 og vejledningen til at forbinde to Spark-enheder.
Betragt ikke »op til 1 PFLOP FP4« eller »modeller op til 200B parametre« som en garanti for gennemløb. Det er NVIDIAs udsagn om funktionalitet. Det faktiske antal tokens pr. sekund, den maksimale kontekst og antallet af samtidige agentsessioner afhænger af model, præcision, batching og softwarevej. Mål på din egen stak.
Pris: opfind den ikke
Detail- og forhandlerpriser ændrer sig. AI Expert offentliggør derfor ikke en opdigtet listepris.
- Kontrollér NVIDIAs købs- og produktside for DGX Spark og autoriserede forhandlere for aktuelle tilbud.
- Hvis du citerer et tredjepartstilbud i en intern businesscase, skal tilbuddet dateres, og kilden navngives. Gårsdagens forumindlæg er ikke en indkøbsordre.
Kapitaludgiften er kun en del af de samlede ejeromkostninger. Budgettér strøm, UPS- eller PDU-kapacitet, køling ved skrivebord eller rack, ekstra lager, softwarearbejde til serveringsstak, opdateringer og evalueringer samt de personer, der har ansvaret ved hændelser.
Hvad der ændrede sig for lokale agenter
Før systemer som Spark betød »lokale agenter« ofte:
- Små modeller på en bærbar computer eller en arbejdsstation med GPU.
- Cloud-API’er til opgaver, der krævede lang kontekst eller stærkere ræsonnement.
- Selvhostede klynger, der lignede små datacentre.
DGX Spark komprimerer et andet mønster:
| Før (typisk SMV-sti) | Med Spark-klasse skrivebordssystemer |
|---|---|
| Følsomt arbejde → virksomhedssaaS eller VPC | Følsomme agentsløjfer kan blive på det lokale netværk med modeller med åbne vægte |
| Lokal kørsel = 7B–70B-klassen på forbruger-GPU’er | NVIDIAs budskab: 200B-klassen på én node, afhængigt af præcision og servering |
| Flere GPU’er = et projekt til serverrummet | To enheder og QSFP til distribueret servering eller større modeller |
| Agenter på cloud-VM’er med risiko ved udgående trafik | Agenter og inferens på samme private maskine, men stadig med behov for en sandkassepolitik |
Det strategiske skift handler om grænsen, ikke om magisk kvalitet. Prompts, værktøjsresultater og private korpusser kan holdes væk fra tredjeparts træningsforløb, hvis du selv driver og opdaterer maskinen og begrænser agenten. Databeskyttelse er en egenskab ved udrulningen, ikke ved logoet på kabinettet. Se mønstre for implementering af privat AI for at forstå, hvordan Spark passer sammen med SaaS, VPC og hybrid rutestyring.
Hvad der ikke ændrede sig:
- De førende hostede modeller klarer sig stadig bedst i mange vanskelige opgaver med ræsonnement og flere modaliteter.
- Du har stadig brug for evalueringer, logning og menneskelige godkendelsesporte ved handlinger med væsentlige konsekvenser.
- En agent med adgang til shell, browser og beskedkanaler er fortsat en sikkerhedsflade. Lokal inferens fjerner ikke promptinjektion eller misbrug af værktøjer.
Hvem det er til
Brug en beslutningsramme, ikke et slogan om en bestemt målgruppe.
Passer godt, når det meste af dette er opfyldt:
- Dataklassificeringen siger, at fortroligt eller begrænset arbejde i den pågældende anvendelse ikke bør forlade dit miljø.
- Du har brug for agentsløjfer med konstant tilgængelighed eller lav latenstid på et privat LAN.
- En person i teamet kan drive Linux, containere, SSH og modelservering, eller du vil ansætte den nødvendige kapacitet.
- Du accepterer ansvaret for hardwarens livscyklus: firmware, opdateringer til DGX OS, lager og fysisk adgangskontrol.
- Du ønsker en vej fra én node til en lille klynge med flere noder uden straks at gå over til et helt GPU-rack.
Passer dårligt, når:
- Arbejdsbelastningen kommer i korte spidsbelastninger, er sjælden eller kræver den nyeste førende model hver uge.
- Ingen vil have driftsansvaret efter demonstrationsugen.
- Du har brug for elastisk kapacitet på tværs af regioner eller administrerede serviceniveauaftaler.
- Indkøbsfunktionen kræver en ren driftsudgiftsmodel i cloud med leverandørens BAA-aftaler og ingen lokal hardware.
Køb Spark, når databeskyttelsesgrænsen og latenstiden for lokale agenter retfærdiggør kapitaludgiften og driftsansvaret. Køb ikke systemet for at »indhente AI« uden en navngiven arbejdsbelastning, en dataklasse og en ejer.
Hvem driver det
Behandl køber og operatør som separate roller, også i en fempersoners virksomhed.
| Rolle | Ansvar |
|---|---|
| Forretningsejer | Anvendelse, dataklasse, succesmål og budget |
| Platformsejer | Operativsystem, netværk, sikkerhedskopier, adgangskontrol og opdateringer |
| Modelejer | Serveringsstak, kvantisering, evalueringer og tilbagerulning |
| Agentejer | Værktøjer, positivlister for kanaler og menneskelige godkendelsesporte |
Hvis én person varetager alle fire roller, skal det første produktionsomfang være snævert: ét modelslutpunkt, én agentflade og én vej til logning.
Kapacitet, du bør antage findes
En Spark minder mere om en mindre serverenhed end om en LLM-app på en bærbar computer. Planlæg for:
- Genstarts- og opdateringsvinduer efter ændringer i DGX OS eller drivere.
- Voksende lagerforbrug fra modelvægte, containerlag og agentlogfiler.
- En navngiven person, der kan fortolke
nvidia-smi, containerlogfiler og et mislykket sundhedstjek kl. 09:00. - Fysisk kontrol: Hvem kan afbryde, tage et systemimage af eller fjerne en enhed, hvis lageret kan indeholde private modeller, prompts og logfiler?
Hvis denne kapacitet ikke findes, bør du vælge virksomhedssaaS eller administreret VPC-inferens, indtil den er på plads. Hardware uden en ejer bliver et ikke-revideret skyggesystem.
Et sammenligningsbillede til beslutningen, ikke en benchmarkduel
| Mulighed | Styrke | Vigtigste omkostning |
|---|---|---|
| Forbruger- eller virksomhedssaaS | Hurtig adgang til funktionalitet, lavt driftsarbejde | Ekstern behandlingsgrænse og leverandørvilkår |
| Cloud-GPU eller administreret inferens | Elastisk, ingen lokal hardware | Løbende driftsudgifter samt design for udgående trafik og dataplacering |
| Selvhostet GPU-server | Fleksibel skalering | Rack, strøm og ML-drift |
| DGX Spark | Stor lokal hukommelse, NVIDIAs softwarevej og QSFP-klyngedannelse | Kapitaludgift, driftsansvar og grænser for model og servering |
Spark konkurrerer med en privat arbejdsstation eller miniklynge, ikke med en »uendelig cloud«. For mange SMV’er er den modne løsning stadig hybrid: SaaS til offentligt og internt arbejde samt Spark eller VPC til den fortrolige agentvej. Denne porteføljetankegang følger samme logik som selvhostet kontra hostet inferens.
Hvad »lokale agenter« faktisk har brug for ud over SoC’en
Købet af en Spark leverer ikke i sig selv en agent. En minimal stak til private agenter kræver stadig:
- Et serveringsslutpunkt, ofte OpenAI-kompatibelt, med autentificering på en privat grænseflade.
- Et agentkørselsmiljø med udtrykkelige værktøjer og kanalregler, for eksempel OpenClaw, Hermes, en specialbygget app eller NemoClaws sandkassevej.
- En politik for, hvad agenten må læse, hvor den må oprette udgående forbindelser, og hvilke handlinger der kræver et menneske.
- Observerbarhed med forespørgselslogfiler, modelversion, fejlrate og en vej til tilbagerulning.
NVIDIAs økosystem med DGX OS, vejledninger, NemoClaw/OpenShell og Sync forkorter vejen. Det fjerner ikke produktbeslutningerne ovenfor. Teams, der springer dem over, ender med en stærk demonstration, som ikke kan overdrages til support eller compliancefunktionen.
Tjekliste til indkøb og udrulning
- Navngiv den første arbejdsbelastning, for eksempel visitering af supportsager, intern informationssøgning eller en driftsagent, ikke »generel AI«.
- Klassificér de data, der vil indgå i prompts, værktøjer og logs.
- Bekræft det fysiske sted: strømkreds, køling, tyveri- og adgangskontrol samt nødstrøm, hvis oppetiden er vigtig.
- Bekræft netværksplanen: administration via 10 GbE eller Wi-Fi og højhastighedsforbindelse via ConnectX-7 kun ved klyngedannelse.
- Udpeg platform- og agentejere før udpakningen.
- Planlæg måling af latenstid, kvalitetsevalueringer og fejlrate, ikke kun om systemet gav et svar.
- Planlæg tilbagerulning med cloud eller SaaS som reserveløsning, hvis den lokale model eller maskine er nede.
- Genlæs NVIDIAs aktuelle produktside og brugervejledningen til DGX Spark på købsdagen; firmware og lister over tilbehør ændrer sig.
- Afgør, om succes efter den første måned betyder, at modellen kan serveres, eller at én agent i en sandkasse fuldfører en navngiven arbejdsgang med logning.
Gør ikke dette endnu
- Dimensionér ikke kapitaludgiften ud fra et udateret diagram over tokens pr. sekund i et blogindlæg.
- Læg ikke legitimationsoplysninger fra produktionskunder ind i en ubegrænset agent for at »prøve Spark«.
- Spring ikke dokumentationen om klyngedannelse over for derefter at give kablet skylden, når NCCL hænger.
- Antag ikke, at Wi-Fi 7 kan erstatte ConnectX-7 ved distribueret inferens.
- Betragt ikke NVIDIAs budskab om 200B-klassen på én node som et løfte for alle åbne modelcheckpoints ved fuld præcision og lang kontekst.
Hvor du går hen næst
- Lokal inferens på Spark i praksis — hukommelse, serveringsstakke, fejltilstande og hvornår cloud stadig er bedst.
- Forbind to DGX Spark-enheder — QSFP, SSH, RoCE, Cluster Assistant og tilbagerulning.
- NemoClaw-agenter i sandkasser på Spark — OpenShells politiklag og Express Install.
DGX Spark er en konkret mulighed for privat databehandling med offentliggjorte specifikationer og en dokumenteret vej til klyngedannelse. Den har en plads i arkitekturen, når datagrænsen og agentarbejdsbelastningen er reelle, og når nogen vil drive maskinen, efter billederne fra udpakningen er taget.
