Walang nag-uusap ng RAM. Bawat local-LLM regret ay problema sa RAM.

Pumasok ka sa kahit anong local-LLM thread at tungkol sa mga GPU ang mga away. Mga VRAM benchmark, 24 GB cards, CUDA versus ROCm, kung nananatili pa bang card ng masa ang 3060. Samantala ang numerong talagang nagpapasya kung tatakbo ang model mo ay nakaupo sa kabilang slot, hindi masukat sa benchmark at hindi nire-market: magkano ang RAM ng makina.

Sa VRAM binebenta ang pangarap. Sa RAM nakasalalay kung bubuksan man lang ang model — at kung magkano ang context na mabubuhay kapag nabuksan.

Sinubukan ko ito sa box sa harap ko habang isinusulat ang post na ito: Ryzen desktop na may 32 GB RAM at GeForce RTX 3060 na may 12 GB VRAM. Ni-pull ko ang llama3.1:8b — sabi ng download page, 4.9 GB. Panoorin mo kung ano talaga ang naka-reserve:

Iyan ang buong argumento sa iisang screen. Ang “4.9 GB model” ay naka-reserve ng 7.0 GB bago pa sumagot sa isang prompt — isang 43% context tax — at pinanatiling 7,963 ng 12,288 MiB ng VRAM para sa sarili nito. Hindi kailanman naging budget ang mga weight. Ang context ang iyon.

Saan nanggagaling ang mga sobrang gigabyte

Ipinapaliwanag ng llama.cpp memory notes ang arithmetic na nilalaktawan ng mga download page: total memory = model weights + KV cache + compute buffer. Ang unang term lang ang constant. Lumalaki nang linear ang KV cache kasama ang haba ng context, at lumalaki ang compute buffer kasama ang batch at hugis ng graph. Binabalot ng Ollama ang llama.cpp, kaya parehong batas ang naaangkop — kaya 7.0 GB ang nireport ng ollama ps para sa 4.9 GB na tag sa 32,000-token na window, lahat ay resident sa GPU.

Ang quantized model ay hindi kompromiso. Pag-amin ito na ang memorya ang tunay na budget simula’t simula.

Ito rin ang dahilan kung bakit umiiral ang GGUF quantization ladder. Hindi relihiyon ang Q4; ito ang nagpapalapag ng memory arithmetic sa loob ng hardware na hawak ng mga tao. At ito rin ang dahilan kung bakit magkaiba ang kilos ng dalawang “magkapareho” na 8B setup: parehong model, ibang haba ng context, ibang makina nang buo.

Ang table na walang nagtakbo bago bumili

Parehong tatlong model class, parehong uri ng memorya, isang 12 GB card at 32 GB RAM — ang configuration na hawak ng libu-libong developer ngayon:

Model class (Q4)	Download	Loaded + 32k ctx	Sa 12 GB VRAM	Sa 32 GB RAM
7–8B (llama3.1:8b)	4.9 GB	7.0 GB (sinukat)	100% GPU, ~8 GiB ang ginamit	halos hindi napansin
13–14B (qwen2.5:14b)	9.0 GB	~12 GB	nagsisimula ang offload	ayos lang
27–32B (gemma3:27b)	17 GB	~20+ GB	Hinahakot ng CPU ang weight	ang tanging dahilan kung bakit tumatakbo

Basahin muli ang huling dalawang hanay. Sa VRAM lang, ang 14B model sa totoong context window ay split-offload na trabaho na, at imposible ang 27B. Sa 32 GB ng system RAM, mabagal lang ang pareho. Ang pagkakaibang iyan — sa pagitan ng imposible at mabagal — ang buong praktikal na pagkakaiba ng RAM at VRAM. Kung kumasya sa VRAM, mabilis. Kung kumasya sa RAM, gumagana. Kung sa alinman ay hindi kumasya, nagsa-swap ka na sa NVMe drive at nawawalan ng kahulugan ang oras.

Nakaupo ang offload sa PCIe, at tuwirang-tuwira ang Ollama FAQ tungkol sa halaga: ang mga layer na hindi kumakasya sa GPU ay tumatakbo sa CPU, at bumabagsak nang matindi ang throughput habang kumukunti ang bahagi ng GPU. Walang pumipili ng trade-off na iyon nang may kamalayan. Nangyayari ito nang tahimik, isang layer kada beses, at ang sintomas ay “overrated yata ang mga local model.”

Ang tapat na ledger

Mga bagay na nasira o nagulat sa akin habang isinusulat ito, sa ayos:

1. Ang mismong numerong 43%. Inaasahan kong sasakupin ng 8B model ang “mga laki ng file nito.” Naka-reserve ito ng 7.0 GB laban sa 4.9 GB na download. Kung nagulat ako doon, nagugulat din ang lahat ng bumabasa ng spec sheet sa halip na output ng ps.
2. Ang screenshot session. Maling window ang nasalo ng unang capture. Gumana ang ikalawa — iyon ang nasa itaas. Workflow ang mga receipt, hindi vibe — at ang pull → capture → ollama rm cycle ang panatilihing tapat ang disk.
3. Ang hindi nasira: hindi kailanman lumusot ang GPU. Ang 8B sa 32k context sa 12 GB ay tunay na kumportable. Ayos lang ang card. Ang diskurso sa paligid ng card ang mali ang kalibrasyon.

Walang nangangahulugan dito na walang halaga ang mga GPU — ang 100% GPU na linya sa capture na iyon ang dahilan ng instant na pakiramdam ng generation. Ibig sabihin, pangalawang tanong ang GPU. Ang pagpipilian ng Ollama versus llama.cpp ay dumating pagkatapos mong malaman ang kumakasya, hindi bago.

Ang rule of thumb na worth panatilihin

RAM na kailangan mo = model file + KV cache para sa totoong context window mo + 4 GB para sa pagiging computer. Para sa 7–8B sa Q4, kumportable ang 16 GB. Para sa 14B–32B, titigil na sa pagiging luho ang 32 GB at magsisimulang maging ang punto. Bumili ng VRAM para sa bilis na gusto mo sa context na ginagamit mo; bumili ng RAM para sa lahat ng i-lo-load mo kailanman.

I-check nang isang beses ang ollama ps at tahimik na matatapos ang relihiyon ng spec sheet.

Kaya, dalawang tanong. Kapag nagspec ka ng susunod mong dev box, bumibili ka ba ng VRAM para sa mga benchmark na ipopost mo — o ng RAM para sa mga model na tatakbohin mo talaga? At tapat na tanong: ilan sa mga model na ni-pull mo ng 2 a.m. ang binura mo bago ang agahan? Ginawa ko, kagabi, sa gitna ng post. Sabihin sa comments na ako lang ang ganoon — at sabihin kung aling panig ng RAM/VRAM split ang nakaupo ang build mo.