IBM Granite 4.2 Fits 128GB. That Is Not a Bench.

IBM posted Granite 4.2 this morning. The instrument is a Hugging Face card dated August 25, 2026, plus IBM's own build post. Apache 2.0. Dense decoder-only models at 3B, 8B, and 30B. Native 128K. They claim a 512K long-context extension. Thinking, non-thinking, and a low-effort thinking mode. Official sample settings: temperature 1.0, top_p 0.95.

I pulled the API, not a brochure screenshot. ibm-granite/granite-4.2-30b usedStorage is 58,553,607,904 bytes. BF16 params on that card: 29,276,770,304. granite-4.2-8b is 17,583,228,032 bytes. granite-4.2-3b is 7,319,517,120. Those are weight sizes. They are not a GX10 clock.

Official serve is vLLM BF16. The 30B README wants vLLM v0.20+ and a plugin they ship in the repo:

vllm serve ibm-granite/granite-4.2-30b --dtype bfloat16 --max-model-len 131072 --reasoning-parser granite_thinking_parser --reasoning-parser-plugin ./granite_thinking_parser.py --tool-call-parser qwen3_coder --enable-auto-tool-choice

The card says a native granite parser for vLLM and SGLang is "very soon." The SGLang block is still commented out. There is an official GGUF repo. I am not quoting per-file GB from it.

IBM printed their own NeMo Evaluator table on that 30B README. 30B SWE-Bench Verified 57, Terminal-Bench 2.1 29.24. 8B 47.67 and 20.56. 3B is NA on those two because agentic RL was 8B and 30B only. That sentence belongs to them.

58.55 GB of official BF16 weights fit 128GB unified. They do not fit a 24GB card. The 8B BF16 weights do. That is a fit test, not a bench. I have not loaded Granite 4.2 on the GX10. I am not rewriting the Qwen 3.8 27B receipts to pretend I did.

I run Grok when it earns it, and a GX10 when I want the weights in the room. This family sits on the local side of that split, as a download. If I sit 30B BF16, that note comes next. Not this card.

• Granite 4.2 LLMs: How They're Built | Hugging Face
• ibm-granite/granite-4.2-30b
• Granite 4.2 Language Models
• Qwen 3.8 27B on One GX10: The Receipts