Granite 4.2 at home: choose between 3B, 8B and 30B

IBM releases Granite 4.2 as three dense reasoning models: 3B, 8B and 30B. This is not a mixture-of-experts setup where only a small subset of weights is active for each question. All three support thinking modes and tool calling and carry the Apache 2.0 license. Their shared feature names do not imply equal output quality or resource needs. IBM says the 8B and 30B models also receive additional training on agent tasks. Your own files will tell you more about sufficiency than a family-wide score.

Start with 3B for short document summaries, repetitive text edits and straightforward code explanations. There is no reason to buy hardware before trying a cheaper baseline. Save ten questions you actually ask and mark omissions and confident wrong answers. A quick answer that you must rewrite each time may be too small for the job. If it performs consistently well, a larger model's published score alone does not justify a memory upgrade. IBM lists Korean among tested languages, but that does not validate the terminology in your own documents.

IBM gives 8B and 30B additional training for agent work involving code changes, terminals and search. That makes 8B worth testing if 3B repeatedly loses the thread of a tool-based task. It does not connect itself to every application: your runtime must support the model's chat template and tool-call format, and tools need their own permissions. Give it one small change in a real repository. Note whether it fails at planning, using the tool or checking the result. That evidence is more useful than moving straight to 30B.

30B is the largest dense model in the family. At two bytes per BF16 weight, 30 billion weights imply roughly 60 GB before overhead; four bits suggest a 15 GB arithmetic floor. Neither number is a full runtime requirement. File metadata, compute buffers, context-dependent KV cache, the operating system and other applications all take space. A four-bit file opening on a 24 GB device is different from leaving enough headroom for long documents. Fix the exact model file, runtime and context length, then inspect memory pressure and both input and output delays.

IBM's model card lists native 128K context and an extension to 512K. A supported limit does not mean your machine can read a long document quickly or answer it faithfully. Longer input can increase both work before the first answer and KV-cache memory. Try one report you genuinely need and check whether selecting relevant passages serves you better than sending the whole file. Hold the question and document length constant when comparing first-token wait and subsequent generation. That separates a memory problem from a workflow problem.

Granite 4.2 offers thinking, non-thinking and low-effort thinking modes. The same question can take a different amount of time and produce a different length of answer in each mode. Original BF16 weights and four-bit conversions also change memory use and potentially quality. Confirm the original IBM model ID; for a conversion, record its publisher, format and quantization. A smaller download does not prove equal answers or a particular speed gain. Rerun the same questions and track corrections, first-token wait and generation speed.

If 3B repeatedly misses a condition in your material and 8B fixes it, shop for a configuration that runs 8B comfortably. If a real tool workflow still fails on 8B but improves on 30B, then price the memory for 30B. If neither step helps much, dividing the source material or changing the instruction may matter more than new hardware. Use the site's hardware and memory guides to narrow candidates, but do not mistake another model's speed chart for a Granite 4.2 measurement. Check the seller's RAM, VRAM and SSD against the configuration you tested.