NVIDIA Didn't Want Me to Do This… Linux on RTX Spark

This laptop has the same GPU design as the Nvidia DJX Spark. The DJX Spark runs Linux and the RTX Spark and all the different variants of it like the Asus ProArt and the Dell XPS and this is the MSI Prestige. Well, they all run Windows and a lot of developers watch this channel who run both Windows and Linux. So, naturally, they want to know if we can run Linux on the RTX Spark laptops. Well, it took me 3 days, a KVM, and even a webcam pointed at this computer screen from another computer. But I think I got something going for you. But not without a few blank screens, a machine that froze overnight, and a kernel panic. And somewhere in all that, I found something hiding inside this machine. Windows has been quietly using it the whole time, and Linux doesn't even know about it. So, this is the MSI Prestige N16 Flip AI Plus with Nvidia's RTX Spark N1X. Is your head spinning yet?

That's a lot to say, and I just had to read it off the teleprompter cuz I can't remember that. These new RTX Spark machines are very unique in a very specific way. First of all, it's Nvidia's brand new chip, but also it's running Windows on ARM, something that's been in development for a number of years and getting better and better all the time. And we've reached a certain threshold, a certain turning point now where things are so smooth that you can't even tell. Also, all these machines go up to 128 gigs of memory, which is just nuts. All right, enough. Let's take a look at the numbers. Typing out a complicated AI prompt feels ridiculous once you've just tried saying it. This part is sponsored by Whisper Flow, a voicetoext tool I've been using. You know those massive prompts where you're just trying to explain everything to the AI? >> I need you to fix one thing. Just one thing. Please do not redesign the page. Do not migrate the database. Do not replace Postgress with SQite because it's simpler. Well, it turns out that speaking them is actually a lot faster and easier than typing them out. But speed isn't even the impressive part.

Watch what happens when I say, "Hey, Chuck, quick update. Um, could you send the updated API documentation by Thursday? Actually, Friday." Then using Whisper Flow, instead of just transcribing everything I say, Whisper Flow actually cleans it up. I can even change requirements halfway through my AI prompt because apparently my brain writes specs in real time. It handles the corrections, removes filter words, and understands technical jargon. Fix the test and check and write. >> Set the retry logic to three attempts. Actually, make that five with exponential back off. >> Nice. and it works right where I'm already typing. Whether it's my code editor, Gmail, notes, or even on my phone. >> Please stop spamming me. Whisperflow has a free version and my link below gets you a free month of Whisperflow Pro with unlimited work. Check it out. And now back to the video. I already tested this machine on Windows and WSL. I made a video a couple weeks ago. You can check it out. Here's a little brief look at that with GPTOSS120B on the GPU. Windows did 65.4 tokens per second. WSL, Windows Subsystem for Linux. Basically, it's a Linux virtual machine running inside Windows. So, you get both the best of both worlds basically. I know it's not good enough for some of you. We'll come back to that. But it got 65.1, which is not far off from what we got on Windows Native.

And on the DJX Spark, 61. So, the laptop actually beat the desktop. Windows is actually fast. It's not your old grandma's Windows, but AI grew up on Linux. The servers that train and serve these models run Linux and most AI tools land in Linux first. And on top of that, as I mentioned, this is a brand new kind of machine. And the difference here is it's Windows and ARM, but not just that, because that's been around for a couple years. This is Windows and ARM with CUDA, which only showed up with this chip. So, I had a few questions. One, software. Will the AI tools I actually use run on this? A lot of them like VLM and SG Lang are built for Linux first. Two, Python. Will the packages install? Nvidia's own getting started guide says that a few don't have ARM 64 builds for Windows yet. Three, WSL. Can Linux running inside Windows handle those Linux first tools at full speed? And memory, it's unified. Part of it is reserved for the GPU. So, who gets and how much do they get? The DJX Spark never has to answer that because it ships with Nvidia's own Linux. So, I went for the most common thing you would do, and it's a safety thing. I wanted to do dual boot first. That's where you keep Windows and put Linux next to it.

You don't just wipe the whole thing. You just you have both of them. How hard could it be, right? Well, for me, very hard. But I know someone who knows Linux very well. Well, yes, Wendell from Level One Tech, of course. But he's very busy. So, another guy, Claude Code, I let him drive this from another machine. What's cool about Jet KVM is it has an IP address. So, Claude Code can get to the JetKVM and get to the machine that way. It can reboot. It can see the screen. It can operate the mouse and the keyboard for me. But, it couldn't actually see the screen because, well, the video out wasn't working in the Linux world yet. During boot and the Linux install, the laptop only shows a picture on its own display and sends nothing over HDMI. So, I ended up pointing a MacBook Air's camera at the laptop, which sits upside down. So, every frame had to be flipped, but I'm not doing all that. Claude, my buddy, is doing all that. Now, the first thing I tried was Omari, because it already supported the chip on Asus and Dell laptops, these two. But I didn't have those two when I tried this. I only had the MSI.

So, I thought, "Hey, maybe it'll work anyway." And I got a flippity flippy screen. Uh, what's happening? They kept flipping between. I already said flip. I said flip too many times, but it wasn't working is the bottom line. And then Wendle saw my tweet and he said, "Debian basically works out of the box now." All right, Debbie and it is, but it wasn't that smooth. The installer couldn't join my Wi-Fi, so USB Ethernet is what I used for this. Now, out of the box, Debian doesn't know this hardware. So, there's no keyboard, no touchpad, no GPU. So, I went back to Omari because Omari already had the kernel with the Nvidia's open driver. Finally, a little bit of light, but Linux only saw 28 gigs of memory on this 128 gig machine. The laptop reserves 96 GB for the GPU, and only Windows can change that setting. So, back to Windows. I actually had to do that a few times. This is just to demonstrate what I was doing. I know.

Sorry about that. Once I tweaked Windows back down to 4 GB, Linux got 120. After all that, a full desktop on the Nvidia GPU 4K at 120 Hz with the keyboard, the touchpad, audio, and CUDA all working. Went to YouTube. YouTube played flawlessly with sound on Linux on an RTX Spark laptop. It was done. Wait a minute. I forgot a few things. cuz I needed to test AI. What's a really quick test we can do here? LM Studio, they have a ARM 64 Linux build with CUDA support. So, of course, I loaded it up and said, "Write a story." And there it goes. I know. I know. I know. I'm going to get some comments about that. But, you know what? Hey, it's a proof of concept, so whatever works. There's MV Top GPU usage coming close to 100%. It works. 61 tokens per second on the GPU. And by the way, that's unplugged. So, let's plug it in and see what happens there.

Ladies and gentlemen, this is the opposite world. I mean, obviously, there's some things that need to be figured out here, but this is a little bit wacky. 15 tokens per second plugged in. So, we're much slower plugged in than unplugged. I'm going to unplug it again and see what happens. Now, 67 tokens per second. Power mode set to balanced both times. Now, here's the interesting thing. The GPU sits at 2300 MHz when not working. But when it's busy, it gets down to about 1,800 MHz around there. That's unplugged. But when plugged in, look at that. We're down to 780 MHz. So, that GPU gets held back a lot when it's plugged in. Very weird. By the way, earlier I tried VLM and SG lang and they also work here, but that is kind of weird. And when plugged in the 156 token per second number, so I wanted to see how a large model would do and compare it to Windows. I went with a typical GPTOSS120B.

I know it's old, but it's something that all the vendors use as a model because it runs on everything. And Windows got me 65.4 tokens per second. WSL 65.1, DGX Spark 61, and Linux well 13.9. That's almost five times slower on the same laptop. VLM with eight clients was even worse. WSL does 127 tokens per second and Linux 39.5. You saw how the GPU frequency drops when I'm running this. It drops either way, just much further when it's plugged in. And it's staying at a nice 40 to 47° C. Nothing is even throttling over a whole test run. Windows holds about 2.2 GHz and finishes in 8 minutes. Linux sits around 790 for 37 minutes. So, the software basically works, but the GPU isn't allowed to go fast. Ah, I needed to find out what Windows has that Linux doesn't that's keeping it locked out.

Remember, the DJX Spark is a desktop box and this is a laptop. The CPU and GPU share one power budget. So, something has to decide how much the GPU gets. Windows. Don't look at my password, which is password, but I didn't tell you that. Device manager for devices. Here it is. On Windows, that device is called Nvidia Platform Controllers and Framework. And it doesn't have a Linux version. Windows. Same model, same quant. 68 tokens per second. About the same as Linux unplugged. Now, if I disable this, yeah, there it is. Now, we're down to 31 tokens per second just by disabling this Nvidia platform controllers and framework. You might say, obviously, but hey, it's a discovery. Just to recap, with the controller on, I got about 83 tokens per second in a different run. Controller off, 32, back on, up to 78.

The clock basically says the same thing. 2 GHz with the controller on, 786 MGHertz with a controller off, and back up to normal with the controller on. That's the exact clock that Linux has been stuck at, plugged in. So, I had Claude Code try to get Linux to talk to that. The firmware hands the controller a table of power settings, and it's encrypted. Windows knows how to decrypt it, but on Linux, nothing can read it. Nothing I tried moved the clock up and one time I even got a kernel panic. So I panicked naturally, but Claude Code didn't panic. Reboot. Could you possibly dig the key out of the Windows driver? Maybe. And it'll also be a hack for one machine. Not really a fix for everybody else. That implementation has to come from Nvidia. So plugged in, Linux runs at between a sixth and a half of Windows speed depending on the test. But Windows on battery still runs this GPU near 2 GHz. Windows handled this laptop great. The system with the problem turned out to be Linux if you need it. WSL is the practical answer today because it runs on Windows driver and keeps the boost plugged in or not. It runs your other tools like VLM. It took a couple of tweaks because WSL gets 14 gigs of memory by default. So I needed to ask cloud code to mess with that too. But finally we got it on memory. Wendell said it best.

>> Why does the user have to pick how much memory they have reserved? That's dumb. >> And he says Nvidia fixed that on Windows. On Linux, you get whatever the firmware reserves, and this one shipped holding 96 GB. Now, I still wouldn't buy this laptop for Linux because, well, you can't stay on battery forever, and plugging it in gives you worse performance for now. But if Nvidia adds the controller to its Linux driver, this turns into a portable DJX Spark. Should Nvidia fix this? Let me know down in the comments below. And if you want to see the full video, full dev review of this machine, watch this video next. Thanks for watching and I'll see you next time.