DEV Community: Yaroslav Pristupa

Task Manager is lying about your GPU temps. Here is how to read the real data in Python

Yaroslav Pristupa — Mon, 13 Apr 2026 12:46:34 +0000

As developers, we are used to trusting our system monitors. When you are pushing a high-end laptop GPU to its absolute limits – say, running a massive batch in Stable Diffusion or training a local LLM – you naturally keep an eye on Windows Task Manager.

It tells you your GPU is sitting at 100% utilization and the temperature is a comfortable 75°C. You think everything is fine. But 30 minutes later, your generation speed drops by half, the system stutters, and your laptop feels like a hotplate.

Task Manager isn't exactly lying, but it is omitting the most important variable: the Memory Junction (VRAM) temperature.

Modern GDDR6X memory chips run incredibly hot. In a laptop with shared heat pipes, the GPU core can be perfectly cooled while the VRAM hits 105°C, triggering a massive hardware-level thermal throttle.

When I set out to build a utility to fix this for my own AI workflows, my first hurdle was simply getting the data. Here is a look at how I approached accessing this hidden telemetry, and why I ended up using a sidecar pattern in Python instead of writing low-level C++.

The Telemetry Nightmare: WMI, NVAPI, and Ring-0

My first thought was to use Windows Management Instrumentation (WMI). It is built-in, easy to query with Python, and safe. Unfortunately, WMI is notoriously slow and, more importantly, it rarely exposes granular GPU sensor data like the Memory Junction temperature. It usually just gives you the core package temp.

Next, I looked at NVIDIA's NVAPI. While it is the official route, NVAPI is a massive, complex C++ SDK. Wrapping it for a lightweight Python background script felt like massive overkill. Plus, undocumented calls change between driver versions, making it a maintenance nightmare.

The "hardcore" route would be writing a custom kernel-mode driver (Ring-0) to read the SMBus directly. But doing that in 2026 means dealing with strict Windows driver signature enforcement, triggering anti-cheat software in games, and risking blue screens. I wanted a lightweight utility, not a rootkit.

The Sidecar Pattern: LibreHardwareMonitor

Instead of fighting the OS, I looked at the open-source community. Tools like LibreHardwareMonitor (LHM) already do the heavy lifting. They have safe, signed drivers that know exactly how to talk to the thermal sensors across hundreds of different GPU architectures.

Even better, LHM has a built-in local web server that exposes all of its sensor data as a clean JSON API.

This led me to a sidecar architecture. I could run a headless instance of LHM alongside my Python application and simply poll localhost for the exact metrics I needed. No kernel drivers, no C++ wrappers, just standard HTTP requests.

Here is a simplified conceptual look at how you can grab the VRAM temperature using Python:

import requests
import json

def get_vram_temp():
    try:
        # Polling the local LibreHardwareMonitor JSON API
        response = requests.get('http://localhost:8085/data.json', timeout=1)
        data = response.json()

        # Traverse the JSON tree to find the GPU Memory Junction sensor
        # (The actual path depends on the specific hardware tree)
        for hardware in data['Children'][0]['Children']:
            if 'GPU' in hardware['Text']:
                for category in hardware['Children']:
                    if category['Text'] == 'Temperatures':
                        for sensor in category['Children']:
                            if 'GPU Memory' in sensor['Text']:
                                return float(sensor['Value'].replace(' °C', ''))
    except Exception as e:
        print(f"Telemetry error: {e}")
    return None

print(f"Current VRAM Temp: {get_vram_temp()}°C")

It is fast, it is reliable, and it relies on a tool that is already trusted by the enthusiast community.

From Monitoring to Active Management

Once I had a reliable stream of real-time VRAM temperatures, I needed to act on it. If the memory hit 100°C, I needed to cool it down before the hardware firmware panicked at 105°C.

Again, I wanted to avoid global power limits. I wanted to pause the specific CUDA process that was causing the heat. In Windows, you can do this using the native NtSuspendProcess and NtResumeProcess functions from ntdll.dll.

Using Python's ctypes library, calling these low-level Windows APIs is surprisingly straightforward:

import ctypes

# Load the NTDLL library
ntdll = ctypes.windll.ntdll

# Define the required access rights
PROCESS_SUSPEND_RESUME = 0x0800

def suspend_process(pid):
    # Open the process
    handle = ctypes.windll.kernel32.OpenProcess(PROCESS_SUSPEND_RESUME, False, pid)
    if handle:
        # Suspend the threads
        ntdll.NtSuspendProcess(handle)
        ctypes.windll.kernel32.CloseHandle(handle)

def resume_process(pid):
    handle = ctypes.windll.kernel32.OpenProcess(PROCESS_SUSPEND_RESUME, False, pid)
    if handle:
        # Resume the threads
        ntdll.NtResumeProcess(handle)
        ctypes.windll.kernel32.CloseHandle(handle)

By suspending the heavy AI process for just 100 to 200 milliseconds, the OS scheduler drops the hardware load to zero. The CUDA context stays perfectly safe in the VRAM – the model doesn't crash – but the shared heat pipes get a tiny window to dissipate the thermal soak.

Putting it all together

Of course, a simple time.sleep() loop isn't enough for a production environment. If you pause the process too long, the system lags. If you pause it too little, the VRAM still overheats.

I eventually built a dynamic mathematical model that takes the telemetry from LHM and calculates a precise duty cycle for the NtSuspendProcess calls on the fly. It acts like a software-based Pulse Width Modulation (PWM) for your GPU workload.

I packaged this Python logic, compiled it down with Nuitka, and wrapped it in a clean WebView2 UI. The result is VRAM Shield.

If you are building your own hardware management tools, don't feel pressured to write everything in C++ from scratch. Leveraging established open-source telemetry tools via local APIs and using Python's ctypes for WinAPI calls is an incredibly powerful, safe, and fast way to build system utilities.

I built a duty-cycle throttler for my RTX 4060 (because undervolting wasn't enough)

Yaroslav Pristupa — Mon, 06 Apr 2026 12:44:49 +0000

If you spend any time on Reddit or hardware forums complaining about your laptop overheating during local AI workloads, you will get the exact same advice within five minutes: "Just undervolt it, bro" or "Cap your power limit to 70% in MSI Afterburner."

For a long time, that was my default approach too. When I started running heavy generative models like Flux.1 and complex ComfyUI video pipelines on my RTX 4080 laptop, the heat was intense. The fans sounded like a jet engine, and the chassis was physically uncomfortable to touch. So, I opened Afterburner, dropped the global power limit by 30%, and called it a day.

But after a few weeks of running long, unattended overnight batches, I realized something frustrating. Global power capping is a blunt instrument. It is the wrong tool for a very specific problem, and it was silently killing my iteration speeds.

Here is why I completely abandoned global power limits for my AI workflows, and how I transitioned to a process-level duty-cycle approach instead.

The problem with global limits in AI workloads

To understand why power capping sucks for local AI, you have to look at how these models actually stress your hardware.

Gaming is a dynamic workload. You have loading screens, inventory menus, and scenes with varying geometric complexity. The GPU gets micro-breaks. AI inference, on the other hand, is a flat, unrelenting 100% utilization of your CUDA cores and memory bandwidth. It is a sustained synthetic stress test.

When you apply a global power cap – say, restricting a 175W laptop GPU to 100W – that cap affects everything simultaneously. You are starving the core, the memory controller, and the auxiliary components. Yes, your total heat output drops. But you are also artificially limiting your hardware's compute capability from the very first second of generation, even when the silicon is still sitting at a cool 45°C.

More importantly, global power capping completely ignores the actual bottleneck in modern laptops: the heat density of the VRAM.

Because of the shared heat pipe designs in laptops like the Legion or Zephyrus, the GPU core might be well-ventilated and perfectly happy at 70°C. But the GDDR6X memory modules, packed tightly around that core, are absorbing all the thermal soak.

Even with a global power cap, sustained AI workloads will eventually push that Memory Junction temperature to the critical 105°C limit. When that happens, the laptop's low-level firmware panics. It triggers an aggressive emergency throttle, slashing memory clocks by half. Your iterations-per-second (it/s) fall off a cliff. You end up with erratic, unpredictable generation times, and you are left wondering why your "cool" GPU is performing so poorly.

The duty-cycle alternative (Pulse Throttling)

I wanted a way to manage this specific VRAM thermal load without castrating my GPU's peak compute power. I started looking at duty cycles – specifically, modulating the workload of the single, intensive Python process running the AI.

The logic was straightforward. If the VRAM is overheating because of a sustained, unbroken load, the most effective way to cool it down is to simply stop it from doing work for a fraction of a second.

By utilizing the native Windows API – specifically the NtSuspendProcess and NtResumeProcess functions – I could introduce "micro-pauses" directly into the CUDA-heavy process.

This is essentially Pulse Throttling. Imagine applying a 15% suspension duty cycle. The process runs at absolute maximum performance for 850 milliseconds, and then it is completely suspended for 150 milliseconds.

From the OS perspective, the thread is just frozen. The CUDA context remains perfectly intact in the VRAM, the model doesn't crash, and no data is lost. But physically, those 150 milliseconds of zero load give the memory modules and the shared heat pipes just enough "breathing room" to dissipate the accumulated heat.

Granular management vs. Blunt force

The results of this approach were incredibly eye-opening.

On my test machine, applying a strict 100W global power cap reduced my Memory Junction temperature by about 6°C. However, it permanently slowed down every single step of the generation process. My baseline it/s dropped significantly, and the VRAM still eventually crept up to the throttle point during multi-hour runs.

In contrast, when I removed the power cap and applied a dynamic duty-cycle suspension, the Memory Junction temperature dropped by 12°C.

Because the suspension was only applied to the specific render process, the rest of my Windows environment remained perfectly responsive. I could browse the web and watch YouTube without the whole system lagging. I wasn't just blindly capping power; I was managing the heat density exactly at the source.

Instead of my iteration speeds crashing unpredictably when the firmware panicked, they remained perfectly consistent for 12 hours straight. The "average" speed over a long run was actually higher than with a power cap, because the hardware never hit the 105°C emergency wall.

Making it smart

Of course, a static 15% pause is not ideal. You don't want to pause the process if the VRAM is only at 80°C.

To solve this, I wrote a background service in Python that hooks into LibreHardwareMonitor to pull real-time telemetry from the Memory Junction sensors. Instead of a dumb on/off switch, I implemented an advanced mathematical model that calculates the required duty cycle on the fly.

If the temperature is safe, the duty cycle is 0%. The GPU runs at full throttle. As the VRAM approaches the danger zone, the algorithm dynamically scales the micro-pauses – maybe 3% throttling at first, scaling up only if the heat continues to rise. It finds the exact equilibrium point where the heat dissipation matches the heat generation.

I eventually packaged this entire pulse-throttling engine into a standalone Windows utility called VRAM Shield. It runs quietly in the system tray, monitors the hardware, and applies these micro-suspensions automatically.

If you are running local LLMs, generating huge batches in Stable Diffusion, or dealing with heavy 3D renders on a laptop, stop neutering your GPU with global power limits. Managing the duty cycle of the process itself is a much safer, more transparent, and significantly more effective way to keep your hardware alive without sacrificing its potential.

How I fixed the 30-minute performance drop in Cyberpunk 2077

Yaroslav Pristupa — Tue, 24 Mar 2026 10:40:55 +0000

Every laptop gamer knows this exact cycle. You finally have some free time, you launch a heavy title like Cyberpunk 2077 or Black Myth: Wukong, and for the first 15 to 20 minutes, your machine runs like an absolute dream. The frame rate is locked. The frame times are a flat line. Everything feels incredibly responsive.

But then, right around the 30-minute mark, the game starts to feel slightly off.

You notice micro-stutters during fast camera pans. Your average FPS suddenly drops by 20% or more. You alt-tab to check your telemetry in MSI Afterburner or Task Manager, expecting to see your hardware melting. Instead, your GPU core is sitting at a totally reasonable 75°C to 78°C. Your CPU is fine.

So what exactly is happening? Why does the performance fall off a cliff when the core temperatures look perfectly safe?

As someone who spends a lot of time profiling high-performance hardware and writing system utilities, I decided to dig into this "mystery slowdown." What I found is a massive hardware bottleneck that standard monitoring tools completely ignore.

The culprit is the thermal density of your Memory Junction – specifically, the VRAM.

The shared heat pipe problem

To understand why this happens, we have to look at how modern gaming laptops are built. Whether you have a Lenovo Legion, an ASUS Zephyrus, or a Razer Blade, most high-end machines use a shared cooling assembly. The same copper heat pipes carry thermal energy away from both the GPU core and the surrounding components.

This design is great for burst workloads. But during a sustained two-hour gaming session, it creates a severe "thermal soak" effect.

The GPU core itself is usually fine. It has a large die surface area and gets priority contact with the best cooling zones. But the VRAM modules – especially the high-performance GDDR6 or GDDR6X chips on RTX 30- and 40-series laptops – are packed incredibly tight around that core.

As you play, these memory chips generate a constant, intense amount of heat. During my tests with a mobile RTX 4080, I watched the telemetry closely. While the GPU core stabilized at a comfortable 78°C, the Memory Junction temperature just kept climbing.

At the 20-minute mark, it hit 95°C. By minute 35, it hit the hard wall: 105°C.

The firmware's panic button

When your VRAM hits 105°C, the laptop's low-level firmware steps in to stop the silicon from physically degrading. It triggers an aggressive emergency throttle.

The system instantly drops the memory clock speeds by nearly 50% to cut the heat generation. This is the exact moment you feel your game stutter and your FPS tank.

The firmware keeps the memory choked until the sensors report a significant drop in temperature. Once it cools down a few degrees, the clocks boost back up to maximum. The memory rapidly overheats again, the throttle kicks back in, and you are stuck in a miserable "yo-yo" performance loop.

The most frustrating part is the blindness. Because basic overlays only report the GPU core temperature, users are left chasing ghosts. They roll back NVIDIA drivers, disable Windows background services, or blame the game developers for "memory leaks." In reality, they are just hitting a localized hardware thermal limit.

Sledgehammers vs. Software

Once I identified the problem, I looked at the standard community fixes. They were all terrible.

You can repaste the laptop and swap the VRAM thermal pads. This actually works well, but it voids your warranty and requires you to completely disassemble a $2,500 machine.

You can use a global undervolt or strictly cap the GPU power limit. This lowers the overall heat, but it also leaves a ton of performance on the table. You end up nerfing your expensive GPU even during the times when it is running perfectly cool.

I wanted a software solution. I wanted a way to manage this specific heat soak without castrating the laptop's peak performance.

Building a dynamic safety net

I started experimenting with process-level modulation using the Windows API. Specifically, I looked at the native NtSuspendProcess and NtResumeProcess functions.

The theory was simple. If I could introduce microscopic pauses into the heavy GPU-bound game thread, the Windows scheduler would momentarily drop the hardware load. If I gave the memory modules just a few milliseconds of "breathing room" every second, the heat pipes might have enough time to clear the thermal backlog before the firmware hit its 105°C panic button.

I wrote a Python script to test this out. It ran as a background service, pulling real-time Memory Junction telemetry from LibreHardwareMonitor.

Instead of just blindly pausing the game – which would look like a massive lag spike – I built a dynamic modulation engine. I implemented a rather complex mathematical model that calculates the exact duty cycle needed on the fly. It constantly evaluates how fast the VRAM is heating up and calculates the absolute minimum pause duration required to stabilize the temperature.

We are talking about milliseconds. It is a pulse-throttling approach that happens so fast the human eye rarely catches it, but the thermal sensors absolutely do.

The results

The impact on my Cyberpunk 2077 sessions was immediate.

With the script running, my Memory Junction temperature stabilized at a safe 92°C instead of slamming into the 105°C wall. I lost a tiny fraction of my absolute peak FPS, but the catastrophic 40% performance drops completely vanished.

More importantly, the frame times became a flat, consistent line. Instead of the jagged, erratic performance of a hardware-throttled system, the game remained smooth and responsive for hours. I no longer had to sacrifice long-term stability for short-term benchmark numbers.

I initially built this just to keep my own laptop from cooking itself. But after seeing how well the dynamic modulation worked for both gaming and heavy local AI workloads (like Stable Diffusion), I refined the code, added a proper UI, and packaged it into a utility called VRAM Shield.

If you are tired of your laptop silently throttling your games, stop messing with your drivers. Check your Memory Junction temps. Understanding the physical limits of your VRAM – and managing them proactively – is the only real way to get the sustained performance you paid for.