Ollama lists gemma3:270m at about 292 MB. That number is useful for storage planning, but it is not a RAM requirement. It describes the packaged model data for the default Ollama variant, which uses Q8_0 quantization. Once inference starts, the runtime also needs memory for model metadata, execution buffers, token state, and the key-value cache used by attention.

That distinction matters on small machines. A device with 512 MB of RAM may appear large enough when compared only with a 292 MB model file, yet the remaining memory must also accommodate Ollama and the operating system. The context configuration can move the total substantially.

The model file establishes only the first memory component

Ollama currently publishes several Gemma 3 270M variants with materially different file sizes:

Variant Weight format Published size
gemma3:270m Q8_0 292 MB
gemma3:270m-it-qat Q4_0 241 MB
gemma3:270m-it-fp16 F16 543 MB
gemma3:270m-it-bf16 BF16 543 MB

The default 270M model therefore does not start from a 150 MB Q4 image. Its current Ollama artifact is Q8_0 and is 292 MB. Choosing the QAT Q4_0 variant reduces the stored weights, while F16 or BF16 nearly doubles the weight storage relative to the default artifact.

A rough runtime budget can be written as

[ M_{total} \approx M_{weights} + M_{KV} + M_{buffers} + M_{runtime} + M_{OS} ]

The terms do not all scale together. Quantizing weights reduces (M_{weights}), but it does not automatically shrink every other allocation by the same ratio.

Context creates memory that the download size does not show

Gemma 3 270M supports a 32K context window in Ollama. A long configured context needs state that is absent from the static model file.

During autoregressive generation, transformer attention reuses keys and values from earlier token positions. The serving runtime keeps this state in a KV cache rather than recomputing the entire prefix for every generated token.

Conceptually, KV-cache memory grows with quantities such as:

[ M_{KV} \propto L \times T \times H_{KV} \times D \times B ]

where (L) is the number of relevant layers, (T) is cached context length, (H_{KV}) is the number of key-value heads, (D) is the per-head state width, and (B) is bytes per stored element. Exact allocation depends on the model architecture and Ollama/llama.cpp implementation, so this expression is a scaling model rather than a promise of a particular RSS value.

The Ollama metadata for gemma3:270m reports 18 blocks, a 32,768-token context length, four attention heads, one KV head, and key/value lengths of 256. Those architectural choices help keep the model compact, but a large context still has a runtime cost.

This is the reason a single statement such as “Gemma 270M needs 300 MB of RAM” is too precise. It confuses one fixed artifact size with several dynamic allocations.

Quantization does not divide total RAM by the same factor

Suppose the weight representation changes from F16 to a quantized format. The weight component falls sharply, but the process still needs code, stacks, allocator bookkeeping, inference workspaces, and context-dependent state.

The effect is easier to see as a budget:

runtime memory
|
+-- model weights        <- strongly affected by weight quantization
+-- KV/cache state       <- affected by context and cache representation
+-- compute buffers      <- affected by backend and execution shape
+-- Ollama/runtime       <- process overhead
+-- operating system     <- not available to the model

This also explains why model download size and process RSS should not be expected to match. Memory mapping can make the relationship even less intuitive: mapped model pages, resident pages, shared pages, and anonymous allocations are different measurements.

For capacity planning, the useful quantity is peak memory under the intended workload, not the size printed beside the model tag.

A 512 MB machine has almost no margin

The default gemma3:270m artifact alone is 292 MB. On a machine with 512 MB of physical RAM, only about 220 MB remains before accounting for the operating system, Ollama, inference buffers, and context state. That is not a credible general-purpose capacity budget.

A minimal Linux image can reduce OS overhead, and swap can prevent an immediate out-of-memory failure in some configurations, but swap does not turn storage into equivalent inference RAM. Heavy paging can make token generation dramatically slower and can still end in memory pressure when the working set grows.

For this class of deployment, 1 GB is a much more practical starting point than 512 MB, but it should still be treated as a capacity target to test rather than a universal guarantee. Context length, concurrent requests, backend, Ollama version, and other processes on the host can change the result.

Measure the loaded model instead of estimating from parameter count

Ollama exposes loaded-model information with:

ollama ps

This is more useful than multiplying 270 million parameters by a nominal bytes-per-parameter value, because the actual Ollama tag already specifies a concrete quantization and the runtime has additional allocations.

At the operating-system level, process measurements provide another view:

ps -o pid,rss,vsz,comm -C ollama

On Linux, RSS reports resident memory for the process, while VSZ represents virtual address space and should not be interpreted as physical RAM consumption.

A repeatable test should also control the context setting and workload. Comparing an idle server with a model actively processing a long prompt mixes two different states.

A useful measurement sequence is:

1. record system memory before loading the model
2. load gemma3:270m
3. record Ollama's loaded-model memory
4. run the target context length and prompt shape
5. record peak system and process memory
6. repeat with the intended concurrency

The peak from step 5 or 6 is the number that matters when deciding whether the machine has enough RAM.

Small models shift the bottleneck rather than eliminating it

Gemma 3 270M is small enough that fixed runtime costs become visible as a larger fraction of total memory. With a multi-gigabyte model, a few hundred megabytes of non-weight state may look secondary. With a 292 MB model artifact, the same class of overhead can decide whether the process fits at all.

The practical boundary is therefore not “270M parameters equals a particular RAM value.” It is whether the complete inference working set fits alongside the operating system with enough headroom to avoid sustained paging or out-of-memory termination.

For Ollama’s current Gemma 3 270M variants, the published model files give firm starting points: 292 MB for the default Q8_0 model, 241 MB for the Q4_0 QAT variant, and 543 MB for F16 or BF16. Actual RAM use begins from those weights and adds runtime state. On constrained hardware, measure that complete working set at the context length and concurrency the application will actually use.

References

Artificial Intelligence Ollama Gemma Inference Memory