# How Much GPU You Actually Need for Local Code Review in 2026 > Source: > Published: 2026-07-30 15:56:20+00:00 Last month a guy in a security Discord asked what GPU he should buy to run code review models locally. Budget: around $1,600. I told him to try it first on the laptop he already had, and he was almost offended. He'd read enough threads to believe local AI starts at 24GB of VRAM. Three days later he messaged me again: the 7b model running on his four-year-old machine with an 8GB card was already catching the things he wanted it to catch. That conversation happens a lot, so here's my honest breakdown after running local models for code review daily for over a year, on WSL2, on unglamorous hardware. First, an important distinction. Most benchmarks and most YouTube videos are about code generation: can the model write a working function, can it scaffold an app. Review is a different job. The code already exists. The model's task is to read it, hold it in context, and reason about what's wrong with it. That changes the hardware math in two ways: Keep that in mind while reading the tiers below. Yes, this works. A 1.5b model like qwen2.5-coder:1.5b runs on CPU with a few GB of RAM. On my machine it's slow enough that you feel it, we're talking coffee-sip pauses, not real-time streaming, but it runs. What a 1.5b model is actually good for in review: What it's not good for: multi-step reasoning. Ask it whether a reentrancy guard actually protects the function that moves funds and it will confidently say yes to almost anything. Small models are pattern matchers, not reasoners, and review quality lives in the reasoning. If you're budget-zero, start here. It will teach you the workflow, and the workflow transfers to bigger models unchanged. This is where I'd point almost everyone. An 8GB card runs a 7b coder model quantized to 4 bits with room to spare, and a 7b model is a genuinely different animal from a 1.5b one. It follows structured output instructions, it can hold an argument across a function, and when I feed it a Solidity contract it reasons about access control instead of just spotting keywords. Most of the local pipeline in spectr-ai, my open-source contract auditor, was developed and tested against a 7b model on exactly this class of hardware. Not because I couldn't get bigger, but because a tool that requires a $2,000 GPU isn't a tool most people will run. The practical experience at this tier: reviews of a single file complete in a comfortable time, you can leave a directory-wide scan running while you work, and the model is smart enough that its false positives are at least interesting to read. With 16GB you run 14b models comfortably and 32b models quantized. Are they better at review? Yes, measurably in my experience: fewer hallucinated issues, better at cross-function reasoning, better at explaining severity. But here's the thing nobody selling GPUs will tell you: the jump from 1.5b to 7b transforms what review tasks are possible. The jump from 7b to 32b mostly improves quality on tasks the 7b could already attempt. For generation, big models pull far ahead. For review, where the model reads more than it writes, the gap is narrower than the price gap. If review is your main use case and you're choosing between a 24GB card and an 8GB card plus $1,000 in your pocket, I'd take the second option and spend part of that grand on cloud API calls for the hard cases. Quantization compresses the model's weights so it fits in less memory. q8 keeps roughly full quality. q4 halves the memory again with some loss. For code review the question is: does q4 hurt reasoning? In my daily use, on 7b models, the honest answer is "a little, sometimes." A q4 model occasionally loses the thread on longer chains of logic where q8 keeps it. But q4 is what lets a 7b model fit on an 8GB card with context to spare, and a q4 7b beats a q8 1.5b every single time. Rule of thumb: pick the largest parameter count that fits at q4 before you spend VRAM on higher precision. One exception: if you're doing structured output (JSON findings, for example), heavier quantization seems to increase format errors slightly. I handle that with a retry loop in code rather than with more VRAM. Here's what actually limits local code review in 2026: context window memory. The KV cache, the memory the model uses to remember your input, grows with context length and it competes with the model weights for VRAM. A 900-line contract plus your prompt plus room for the response gets big fast. On an 8GB card with a 7b model, you can raise the context, but you'll feel it. When the context you request doesn't fit, Ollama silently offloads layers to CPU and your fast review becomes a slow one, and worse, if you don't raise the default context at all, the model silently truncates your file and reviews half of it without telling you. Check what context length you're actually getting. Set it explicitly: ``` ollama run qwen2.5-coder:7b # in the session: /set parameter num_ctx 16384 ``` Or in the API call. And for large files, chunk deliberately (by contract, by class, by function group) instead of hoping the window is big enough. A model that fully reads 300 lines beats a model that half-reads 900. I run everything on WSL2 and it's been solid for a long time now. Things worth knowing: `nvidia-smi` inside WSL to confirm the GPU is visible before blaming Ollama.`.wslconfig` .If I were starting from zero today: nothing, first. Run the 1.5b on CPU for a week and learn the workflow. Then, if it sticks, a used 8GB or 12GB card, whatever's cheap in your market. Go bigger only when you can name the specific task your 7b keeps failing at, because for review, most people never hit that wall. What's the smallest model that's earned a permanent place in your workflow?