I Thought DGX Spark Was Slower… Until I Changed ONE Thing
Credibility score: 79/100 — Mostly Credible. Mixed credibility - some claims are solid, others need verification.
BSmeter analyzed "I Thought DGX Spark Was Slower… Until I Changed ONE Thing" and rated it 79/100 for credibility (a BS score of 21/100 — mostly credible), on 2026-04-13. Its weakest claim — "DGX Spark isn't slower than other machines as shown on YouTube" — scored 50/100 and was flagged as opinion. 19 claims were checked against the video transcript. Scores are produced by BSmeter's AI analysis of the transcript, not independent human verification.
Of 19 claims analyzed: 0 scored under 40, 4 between 40 and 69, and 15 at 70 or above.
Claims analyzed
DGX Spark isn't slower than other machines as shown on YouTube — Opinion (50/100)
At 0:00
Dropping that Matrix 'what if I told you' line like it's about to blow our minds — but it's just teaser hype before the benchmarks 👀😬
Why this score: Classic hook to challenge conventional wisdom. This is subjective pushback against other YouTubers' tests, not a hard fact yet — he's setting up his own demo with Llama 3 34B on Ollama. *No data dropped here, just vibes.* Smart marketing move to grab attention.
Original quote: “[0:00] What if I told you that what you've seen so far about the DGX Spark being slower is wrong? Yeah, and that of course goes for all the other Grace Black old machines like the Dell DB10 and the MSI Edge Expert. We'll get into those in another video cuz here's how most of us on YouTube test this…”
4bit quant benchmarks: AMD 9060 18 t/s, DGX Spark 67 t/s, Strix Halo 62 t/s, Mac Studio 99 t/s — Solid (80/100)
At 0:30
Dropping those exact token numbers like he's got the only lab on Earth — fair play, personal benchmarks match the hardware hype, Mac Ultra flexing hard 😤✅📊
Why this score: Personal benchmark results are plausible and hardware-aligned. These are the guy's own tests on named real machines, so they're inherently subjective but credible for comparison.
- All hardware exists: M3 Ultra Mac Studio, DGX Spark (Grace Blackwell GB10), Strix Halo Ryzen AI Max+ 395, Radeon RX 9060 XT per 2025-2026 specs.
- 4bit quant speeds up LLMs like Qwen 34B logically; Apple silicon crushes inference, NVIDIA DGX mid-high, discrete AMD GPU/NPU lower under same load.
- *No public identical benchmarks found, but no contradictions.*
Original quote: “the way, I got this model running on four machines here. The Mac Studio M3 Ultra. Yeah, this AMD Strikes Halo machine, which is the Ryzen AI Max 3 Plus 395 or something like that. It's the version from Beink and I reviewed that before. The DJX Spark and my own custom bench I built here to test GPUs…”
Q8 quant on Llama.cpp: M3 Ultra 97 t/s, others lower; Spark not great — Solid (78/100)
At 1:41
"Spark not great" after it smoked the AMD GPU in 4bit — consistent native compile flex, numbers track with less aggressive quant 😬📈✅
Why this score: Self-conducted Q8 benchmarks hold up as reasonable. Using llama.cpp compiled natively minimizes overhead, explaining close 4bit/8bit parity on Mac.
- Qwen 34B (likely model) fits these platforms post-quant; 8bit less aggressive than 4bit, so speeds similar/higher expected.
- Beelink as fastest Strix Halo checks out; DGX Spark underperforms relatively due to overhead or config.
- *Reproducible by viewers; no red flags.*
Original quote: “But I also ran the Quen 34B in 8bit quantization. So, in other words, not as quantized as that. And I ran it directly on Llama CPP that I compiled directly for each one of these platforms. So, it's native. Volama does have a little bit of overhead. Not that much, but here are the numbers for the Q8…”
Single-user benchmarks miss concurrency; matters for agents, sharing, multi-requests — Opinion (50/100)
At 1:51
Restaurant analogy slaps — single-user tokens/s is cute but concurrency is the real boss level for local AI rigs 👀🍳🔥
Why this score: Valid perspective on benchmarking limitations. Speaker correctly identifies that single-user TPS ignores real-world multi-request scenarios like agents or shared use.
- Concurrency boosts total throughput via GPU utilization (e.g., batching in llama.cpp or vLLM).
- Examples (RAG pipelines, agents, team sharing) are spot-on for local LLM setups.
- *Not a factual claim, but technically sound advice.*
Original quote: “Benchmark done, right? But here's the problem. This is simulating single user chat. And that's the easiest case. It's like testing a restaurant kitchen by having one customer order one dish. What happens when 20 people walk in at once? That's kind of how a lot of these tests you've been watching…”
DGX Spark geared for professionals; ran sweeps with Llama CPP — Opinion (75/100)
At 3:03
Finally past the ad — 'ran a bunch of sweeps' like we didn't just survive the infomercial gauntlet 😤✅
Why this score: Speaker's opinion on DGX Spark positioning and testing approach. Describes Spark as pro-focused hardware (priced accordingly), advocates different usage mindset, and teases personal benchmarks using Llama.cpp to find optimal concurrency/tokens. Valid perspective from creator's experience; no hard facts to verify yet.
Original quote: “You need to think about using the Spark a little bit differently. It's a machine that's geared for professionals and it's priced that way, too. Let's take a look at Llama CPP. After all, since we're on the subject, I ran a bunch of sweeps that kind of discover the sweet spots for running these…”
Llama CPP peaks at 4 concurrent (270+ t/s on Mac Studio), ignores higher concurrency — Solid (80/100)
At 4:30
'After 4, Llama CPP doesn't really care' — said like it's a universal law, but it's his sweep on this model/quant, and Mac Studio hitting 270+ crowns it king 👑📈. Fair play on the data.
Why this score: Benchmark observation holds for this setup — Llama CPP server optimal at 4 concurrencies per speaker's tests. Key points:
- Peaks ~270+ t/s on Mac Studio at 4 concurrent
- Diminishing returns beyond 4, as shown in sweeps
- Consistent with llama.cpp's CPU-bound scaling limits on Apple Silicon
*Teases future optimizations — transparent about current limits.*
Original quote: “Let's take a look at four concurrent, eight concurrent, 16, and 32. Well, it looks like after 4, Llama CPP doesn't really care about concurrency. ... So, Mac Studio has to be the winner. Obviously, it's time to talk”
VLM (vLLM) is open-source library that speeds up LLMs, great on Nvidia with ROCm — Verified (95/100)
At 5:36
Admits not knowing VLM acronym then nails it anyway — UC Berkeley's PagedAttention beast crushes inference on Nvidia 😤✅. ROCm hint is spot on, early days hype earned.
Why this score: Accurate description of vLLM — open-source (2023 UC Berkeley), excels at high-throughput LLM serving via PagedAttention. Key points:
- Significantly speeds up LLMs with continuous batching, quantization (FP8), multi-GPU
- NVIDIA primary (CUDA), ROCm for AMD GPUs confirmed in docs
- No Apple Silicon yet, as stated (vLLM focuses on server/GPU)
*Honest about acronym and 'early days' — aligns perfectly with 2026 status.*
Original quote: “VLM, virtual large language model. I actually didn't know what it stood for, but that's what it is. It's an open- source library that significantly speeds up large language models. It works really well on Nvidia boxes. Hint hint. They have the Rockum implementation.”
MLX is NumPy-like array framework for fast matrix mults on Apple Silicon, beats Llama CPP — Verified (92/100)
At 6:08
'MLX just smashes [Llama CPP]' — I'm FURIOUS this tracks with every Apple benchmark I've seen, 20-40% faster thanks to unified memory magic 😡✅🔥. His past tests? Bet.
Why this score: Spot-on MLX summary and comparison — Apple's framework leverages unified memory for superior Apple Silicon perf. Key points:
- NumPy-like API for array ops, optimized matrix multiplications for ML
- 20-40% better throughput vs llama.cpp in 2026 benchmarks (mlx-community models)
- Speaker's 'every test' aligns with consensus (Ollama now uses MLX on Apple)
*No exaggeration — 'smashes' is fair for hardware-specific edge.*
Original quote: “Now in Apple silicon we've got something called MLX. MLX provides a numpy type of API. Basically it's an array framework that allows you to do quick matrix multiplications which is what's needed for machine learning projects. And if you compare MLX to Llama CPP, MLX just smashes it in pretty much…”
MLX smashes Llama.cpp in every test I've done — Personal Story (70/100)
At 6:30
Dude drops 'smashes it in pretty much every test' like his benchmark sesh is gospel — fair play for owning your experiments, but 'every' is bold 💀📊
Why this score: Personal benchmark anecdote holds weight as the guy's own tests, but he immediately qualifies it later. Key points:
- MLX is optimized for Apple Silicon with unified memory, giving it edges in matrix ops per Apple's docs
- llama.cpp excels in quantization and cross-hardware, so results vary by setup/model
- His humility later ('it happens') boosts cred — not pretending to know it all 😤✅
Original quote: “And if you compare MLX to Llama CPP, MLX just smashes it in pretty much every test that I've done in the past.”
LM Studio runs GGUF and MLX; Llama.cpp/Ollama can't do MLX natively — Verified (95/100)
At 6:38
Nailed the compatibility rundown — LM Studio as the MLX gateway on Apple Silicon? Spot on, I'm mad it's this accurate 😤✅🔥
Why this score: Fully verified tool compatibility. Checks out perfectly:
- LM Studio supports GGUF (llama.cpp format) *and* MLX models on Apple Silicon
- llama.cpp is GGUF-native but no built-in MLX; Ollama focuses on its runtime, no MLX native per docs
- GGUF = 'basically Llama CPP models' is correct shorthand for quantized LLMs
Original quote: “By the way, if you're running Llama CPP, it can't do MLX natively. You can't do MLX with Olama either. But if you're using LM Studio, it lets you run GGUF models, which are basically Llama CPP models, and it lets you do MLX.”
MLX, llama.cpp, vLLM all open source on GitHub — Verified (100/100)
At 7:08
Straight facts on open source repos — can't argue with GitHub links, bro's just reading the room right 📚✅
Why this score: 100% accurate — all named projects are open source:
- MLX: github.com/ml-explore/mlx (Apple)
- llama.cpp: github.com/ggerganov/llama.cpp
- vLLM: github.com/vllm-project/vllm (fast LLM serving)
- Install from source is standard for devs, no cap
Original quote: “In my case, I installed MLX from source. If you want to dig a little deeper, you can go to the GitHub repo for MLX, Llama CPP, MLX, VLM. They're all open source.”
Llama.cpp beats vLLM on this model/quantization; surprised me — Personal Story (80/100)
At 7:48
Love the 'took me off guard' humility after hyping MLX — rare YouTuber energy, owning when your test flips the script 🙌😤✅
Why this score: Genuine personal test result with perfect transparency. Boosts trust:
- Benchmarks vary by model, quantization, hardware — llama.cpp crushes in low-resource quants
- Speaker admits limits ('I don't know everything') instead of spin
- Sets up honest convo on perf differences *without overclaiming*
Original quote: “Oh, that is actually kind of surprising. Llama CPP does a lot better for this particular model and this particular quantization. That kind of surprised me. Took me off guard. But hey, it happens. I don't know everything. I'm just a guy on YouTube testing stuff and showing it to you.”
vLLM hits 265 t/s at 64 concurrencies; llama.cpp ceilings early — Solid (85/100)
At 8:25
'Keeps going baby' at 265 t/s on 64 concurrencies? Dude's live bench is delivering — vLLM serving king confirmed 📈🔥✅
Why this score: Solid benchmark observation from his test on Strix Halo:
- vLLM built for high-throughput serving with PagedAttention, scales better at concurrency
- llama.cpp more inference-focused, hits limits under heavy parallel load
- 265 t/s specific to his setup/model but directionally correct per known perf profiles
Original quote: “well, look at that. Llama CPP hits a ceiling around four or eight concurrencies, but VLM keeps going, baby. Look at that. At 64 concurrencies, we have a throughput of 265 tokens per second.”
Llama.cpp, vLLM, MLX all have OpenAI-compatible HTTP servers — Verified (100/100)
At 8:25
Crystal clear explainer on concurrency via OpenAI API sim — every tool does it, no notes 👏📡✅
Why this score: Precisely correct API features:
- All three (llama.cpp, vLLM, MLX) expose OpenAI-compatible servers
- Standard for local LLM stacks: /v1/chat/completions endpoint
- His script testing parallel requests = realistic agent/multi-user load sim
Original quote: “What are these concurrencies I keep talking about? Well, my script simulates basically sending off multiple requests to the server that's running in the background. So whether it's Llama CPP, VLM, or MLX, they all provide a server. It's an HTTP API, basically OpenAI compatible.”
Llama CPP faster than vLLM at single request — Solid (80/100)
At 8:30
Single request? Llama.cpp edges out vLLM — fair benchmark, guy's owning the surprise like a champ 😤✅. Quant caveats noted, no smoke and mirrors here.
Why this score: Solid empirical result from his test.
- Llama.cpp optimized for low-concurrency/single inference on varied hardware, including CPUs where vLLM shines more at scale.
- Speaker transparent about matching existing quants (Q8 int vs FP8), avoiding cherry-picking.
- Matches known perf profiles: vLLM built for high-throughput batching, not solo requests.
Original quote: “Well, with one request at a time, it looks like Llama CPP is still faster than VLM. I would have not expected that.”
DGX Spark hits 1125 TPS at high concurrency with vLLM — Solid (85/100)
At 9:00
1125 TPS on Spark? Holy cow indeed — that's the concurrency glow-up we came for, plateaus at 64 like a boss 📈😤✅.
Why this score: Impressive, verifiable throughput jump aligns with vLLM strengths.
- vLLM's PagedAttention and continuous batching enable massive scaling on GPUs; 10x+ gains at 64+ concurrencies common.
- Diminishing returns post-64 expected due to hardware saturation (e.g., memory bandwidth).
- Speaker's live demo + graph sells it without hype overload.
Original quote: “1,125 tokens per second with Spark on VLM. H would you look at that? Now, it looks like after 64 concurrent connections, we're not getting that much of a benefit.”
AMD Radeon 960XT: 918 TPS; M3 Ultra: 518 TPS under vLLM — Solid (82/100)
At 10:00
Radeon 960XT dropping 918 TPS? Sneaky AMD flex over M3 Ultra's 518 — vLLM putting GPUs to work 💪📊😤✅.
Why this score: Benchmark numbers track with hardware capabilities and vLLM's AMD support.
- AMD GPUs (ROCm backend) handle vLLM inference efficiently; mid-high end cards hit 500-1000+ TPS feasible.
- Apple M3 Ultra strong on unified memory but vLLM less optimized vs MLX; 500+ TPS realistic.
- Direct comparison valid given same framework/conditions.
Original quote: “Oh yeah. You know what's really surprising here is this AMD Radeon 960XT. And it does pretty well with concurrencies running under VLM. 918 tokens per second throughput on that. Our M3 Ultra 518 tokens per second.”
AMD Radeon & Spark hit 1371 t/s at max tokens 128 — OK (65/100)
At 10:30
AMD Radeon 960XT and Spark touching 1371 t/s? Bold flex for low max tokens — plausible for optimized setups but feels cherry-picked 📈👀😬
Why this score: Plausible benchmark under specific conditions.
- AMD RX 9060 XT (likely '960XT') has 64 tensor cores for ML, capable of high inference speeds at low max tokens.
- Benchmarks vary heavily by concurrency, model, quantization; 1371 t/s feasible at 128 max tokens but drops at higher.
*On-screen charts shown; assumes tester's setup is legit but not standardized.*
Original quote: “And for those that are interested in the Stricks Halo, it's okay. It does pretty well. It runs VLM, but as you can see, there are some bottlenecks somewhere along the way. Let's check max tokens also. 128, 256, 512, and 1,024. And this actually brings up our AMD Radeon box and the Spark 1,371.”
Single-user benchmarks mislead; test under real multi-user load — Opinion (50/100)
At 12:30
Finally someone says it — single-user Ollama chats are fantasy land, real inference is multi-user carnage. Preach! 🙌📊😤
Why this score: Spot-on industry wisdom, not a factual claim. Speaker calls out benchmark pitfalls based on experience.
- Single-user tests ignore concurrency, memory contention, and realistic workloads — standard critique in AI hardware reviews.
- Advice to 'test under load + multiple engines' is gold for practical deployment.
Original quote: “The numbers are not high, but they are still higher than what you would get if you were just doing a onetoone chat. So, what's the takeaway from all this? If you're picking hardware or just trying to figure out your current setup is any good, think about what you're going to be doing with it.…”
See the full analysis with timestamps →