What GPU do I need to run ibm-granite/granite-3.0-1b-a400m-base?
1.4B parameters, published in F32. View on Hugging Face
Set up granite-3.0-1b-a400m-basegranite-3.0-1b-a400m-base is published by ibm-granite on Hugging Face, with 37,624 downloads and 7 likes to date. It's a GraniteMoeForCausalLM model built for text-generation, published natively in F32.
VRAM required & cheapest live GPU fit
Required VRAM = weight size at each precision times a flat 1.2 overhead for activations and fragmentation. The KV-cache grows with context and is not in that factor; it is listed per model below where the architecture is published. Full formula and assumptions: methodology.
| Precision | Weight size | Required VRAM | Cheapest live fit | GPUs needed | Est. $/hr (full fit) |
|---|---|---|---|---|---|
| FP32 | 5.2 GB | 6.2 GB | P4 | 1 | $0.069/hr |
| FP8 (quantized) | 1.3 GB | 1.5 GB | RTX 5060 Ti | 1 | $0.160/hr |
| INT4 (quantized) | 0.6 GB | 0.8 GB | RTX 3060 | 1 | $0.110/hr |
A GPU is only matched to a row if its hardware supports that precision, and the primary recommendation is always a single-GPU fit when one exists.
INT4 requires a quantized checkpoint actually published for this model, check its Hugging Face page before relying on this row.
Cheapest way to run granite-3.0-1b-a400m-base at its published (F32) precision: 1× P4, at $0.069/hr per GPU ($0.069/hr total). Quantizing to FP8 or INT4 (rows above) can cost less, but requires a compatible quantized checkpoint to exist for this model.
granite-3.0-1b-a400m-base: KV cache by context length
The KV cache is the memory the attention layers hold for every token of context, on top of the weights. It is not part of the flat 1.2x overhead in the table above, grows with context length and with every concurrent request, and is why a long-context deployment needs more VRAM than the table shows.
Grouped-query attention: every layer caches keys and values for a few shared KV heads. Cached per token: 49,152 bytes at 16-bit.
| Context | KV cache, one sequence |
|---|---|
| 4K | 0.19 GB |
Computed from the layer, head and window counts in the model's own configuration (ibm-granite/granite-3.0-1b-a400m-base), at 16 bits per cached value. Each concurrent sequence needs its own cache, on top of the weights.
granite-3.0-1b-a400m-base: common questions
Does granite-3.0-1b-a400m-base fit on a 8 GB GPU?
Yes. At FP32 it needs 6.2 GB of VRAM, so an 8 GB card holds it with 1.8 GB to spare. A 6 GB card is not enough for it at FP32.
Can granite-3.0-1b-a400m-base run in 16-bit instead of FP32?
Yes. Its published weights are FP32, 5.2 GB, or 6.2 GB once inference overhead is added. Loading the same weights in 16 bits halves that to 2.6 GB, or 3.1 GB with overhead. That moves it onto a 6 GB card instead of an 8 GB one. How much accuracy the cast costs is model-specific and is not measured here.
What is the least VRAM granite-3.0-1b-a400m-base can run in?
0.8 GB, at INT4 (quantized), which fits a 6 GB card, against 6.2 GB at FP32. That row assumes an INT4 checkpoint has actually been published for this model, so check its Hugging Face page before planning around it.
Weight-to-VRAM math, the fit rules, and how live prices are normalized: full methodology.
More Granite 3 models
- granite-3.0-1b-a400m-instruct (1.3B, BF16)
- granite-3.1-2b-instruct (2.5B, BF16)
- granite-3.3-2b-instruct (2.5B, BF16)
- granite-3.0-8b-instruct (8.2B, BF16)
- granite-3.1-8b-instruct (8.2B, BF16)
Lineage
Quantized and fine-tuned versions
Alternatives at this size
Other models for text-generation within about a third of granite-3.0-1b-a400m-base's 1.4B parameters, from other model lines.
- Qwen2.5-1.5B-Instruct (1.5B, BF16)
- Llama-3.2-1B-Instruct (1.2B, BF16)
- gemma-3-1b-it (1000M, BF16)
- OpenELM-1_1B-Instruct (1.1B, BF16)
- OLMo-2-0425-1B (1.5B, F32)
More on granite-3.0-1b-a400m-base
Fits on an 8 GB GPU at FP32: every model that fits in 8 GB.
Related reading: H100 pricing and specs, How much VRAM you need for LLMs, Serving LLMs with vLLM, vLLM vs TensorRT-LLM vs SGLang, and Best GPU for LLM inference.
