Lokal na LLM na wala nang VRAM? Tingnan ang weights vs KV cache gamit ang gputaskman

Maayos na nag-load ang lokal na modelo mo kahapon, ngayon nag-crash ito sa pag-load o gumagapang, at ang tanging binago mo ay ang haba ng context. Karaniwang salarin ang KV cache, at isang libreng terminal tool na tinatawag na gputaskman ang makakapagpakita nito sa iyo sa halip na hayaang maghula ka.

Sinasabi sa iyo ng karaniwang GPU monitor kung gaano kapuno ang VRAM. Iyon ang "ano", hindi ang "bakit". Ayon sa README ng gputaskman (sinuri noong 5 Nobyembre 2026), tinatawag nito ang sarili na "Isang htop para sa kung ano ang nasa loob ng iyong GPU, hindi lamang kung gaano ito kapuno." Ito ay isang maaga, eksperimental, MIT-licensed na proyekto, kaya ituring itong kapaki-pakinabang na lente, hindi hatol.

Ano ang aktwal na pumupuno sa iyong VRAM#

Isipin ang VRAM bilang isang maleta. Tatlong bagay ang pumapasok:

• Weights: ang modelo mismo. Nakapirming laki para sa isang partikular na modelo at quantization.
• KV cache: ang panandaliang memorya ng modelo sa iyong usapan. Lumalaki ito habang lumalaki ang context.
• Compute buffers: scratch space na kailangan ng runtime habang nagtatrabaho.

Kapag sinabi ng mga tao na "hindi kasya ang modelo", madalas ang ibig sabihin ay kasya ang weights pero ang cache na hiniling mo sa ibabaw nito ay hindi. Ang pagkakaibang iyon ang nagtatakda ng solusyon, at iyon mismo ang itinatago ng ordinaryong monitor.

I-install ang gputaskman at tingnan per proseso#

Naglista ang README ng tatlong paraan: isang portable Windows ZIP, isang clone na pinapatakbo gamit ang uv run --locked gputaskman, o pip sa loob ng Python 3.11+ virtual environment. Mga platform, ayon sa paglalarawan ng README:

• Windows 10/11 64-bit na may NVIDIA o AMD GPU (x64 at ARM64 ZIPs sa Releases page);
• Linux at WSL na may NVIDIA GPU (glibc 2.35+; kayang basahin ng WSL ang Windows host counters);
• macOS sa Apple Silicon lamang mula sa source clone, walang portable build.

Hindi unsigned ang Windows ZIPs. I-download lamang ang mga ito mula sa Releases page ng opisyal na repository, github.com/shanselman/gputaskman. Kopyahin ang eksaktong mga command mula sa README: bata pa ang proyekto at maaaring magbago ang mga opsyon.

Kapag tumatakbo na ito, dalawang view ang mahalaga para sa problemang ito:

1. Device view: paggamit ng VRAM, aktibidad ng GPU, PCIe, temperatura, power, clocks at history charts. Mabuti para sa "may tumalon ba?"
2. Process view: lokal na GPU memory per proseso, GPU-accessible system RAM, aktibidad ng engine at ang natukoy na runtime (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime).

Sa process view, hanapin ang iyong model server (para sa Ollama, ang bundled runner nito). Pagkatapos tingnan ang natitirang listahan. Kung may browser o laro na may hawak na ilang gigabytes, nahanap mo na ang sagot mo nang hindi ginagalaw ang modelo.

Weights, KV cache, buffers: saan galing ang mga numero#

Ipinapakita ng model inspector ang architecture, quantization at laki ng buffer kung available. May isang caveat na mahalaga: ayon sa README, ang weights, KV cache at compute buffers ay galing sa load logs ng runtime kapag naka-enable ang compatible logging. Para sa llama.cpp, simulan ang sarili mong llama-server na may logging (--log-file server.log -lv 4; sabi ng README kailangan ang level 4 para sa laki ng buffer). Para sa Ollama, ginagamit ng gputaskman ang server.log ng Ollama kung available ito. Kung hindi, sila ay estimates mula sa GGUF metadata at laki ng context, na ipinapalagay ang llama.cpp-style placement. Hindi pa sinusuportahan ang per-model KV accounting sa loob ng isang proseso.

Kaya basahin ang estimated split bilang "humigit-kumulang", at ang log-based split bilang "kung ano ang iniulat ng runtime". Para sa Ollama, sabi ng README, natutukoy ang bundled runners, pinangalanan ang GGUF blobs mula sa manifests ng Ollama, at ginagamit ang server.log kapag available. Bahagyang suportado ang LM Studio: pinangalanan ang mga modelo mula sa folder nito at sinusuri sa pamamagitan ng lokal na API nito, ngunit nasubukan ito sa fixture responses, hindi end to end.

Maaari ka ring mag-save ng dalawang snapshot bilang JSON at ihambing ang mga ito gamit ang diff command. Malinis na paraan iyon para sagutin ang "ano ang nagbago noong pumunta ako mula 4K patungong 16K context?": kumuha ng isang snapshot, baguhin ang setting, i-reload, kumuha ng isa pa.

Aling knob ang iikot#

Ang pagbasa ng split ay nagbibigay sa iyo ng desisyon, hindi lamang larawan.

Malaking bahagi ang weights. Lumipat sa mas maliit na quantization o mas maliit na modelo. Ito lamang ang lever na nagpapaliit sa weights. Kung gusto mo ang memory math sa likod nito, tingnan ang Can a 125B model run on a 16 GB GPU?

Malaking bahagi ang KV cache. Paikliin ang context. Sa Ollama maaari mong subukan ito mismo sa session:

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 ay halimbawa lamang na value; piliin kung ano talaga ang kailangan ng gawain mo (command ayon sa dokumentasyon ng Ollama, sinuri noong 5 Nobyembre 2026).

Kung mamaya makakita ka ng kakaibang kabagalan sa prompt processing gamit ang quantized cache sa llama.cpp, this fix for the q5_1 KV cache ang susunod na hintuan. Para sa kung ano ang hawak ng context window sa simula, basahin ang What is a context window?

Malaking bahagi ang ibang proseso. Isara ito, o patakbuhin ito sa integrated GPU. Wala nang kailangang baguhin sa modelo.

Kung hindi gumana#

• Mukhang mali ang split. Tingnan kung ito ay estimate (walang compatible load logs). Sa llama.cpp, patakbuhin ang iyong llama-server na may --log-file server.log -lv 4 at i-reload ang modelo. Sa Ollama, ginagamit ng gputaskman ang server.log kung umiiral ito; normal ang estimate label doon.
• Mas kaunting detalye ang ipinapakita ng LM Studio. Bahagya ang suporta, tulad ng nasa itaas.
• Walang NVIDIA o AMD GPU. Sinasaklaw ng tool ang lokal na GPU workloads lamang; wala sa saklaw ang CPU-only, NPU-only at cloud workloads.
• macOS. Patakbuhin mula sa source clone; walang portable build.

Kapag ang hosted model ang mas simpleng solusyon#

Sabihin nating kailangan mo ng mahabang context para sa isang gawain, tulad ng pag-summarize ng malaking dokumento, at kasya lamang sa GPU mo ang modelo na may maikling context. Maaari kang magpatuloy sa pag-tune, o alisin ang VRAM sa eksena. Para sa mga gawaing tulad nito, nag-aalok ang CheapTokens ng DeepSeek-V4-Flash: 380K context, hanggang 32,768 output tokens bawat sagot, isang presyo sa anumang oras ng araw, sa pamamagitan ng OpenAI-compatible API. Ang GLM-5.3-Flash ay may 390K context at hanggang 8,192 output tokens.

Ang tawag ay karaniwang OpenAI format (ilagay ang key mo sa environment variable):

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

Nasa docs ang mga detalye ng setup. Isang rule of thumb para magdesisyon: kung ang isang gawain ay paulit-ulit na nangangailangan ng mas mahabang context o mas malaking modelo kaysa sa hawak ng card mo, at ipinapakita ng process view na gamit na gamit na ang VRAM mo, ipadala ang gawaing iyon sa API at panatilihin ang maliliit at mabibilis na trabaho nang lokal. Ang Run DeepSeek locally or use an API? ay mas malalim sa trade-off.

Sabihin nating nag-summarize ka ng 100 malalaking dokumento, bawat isa ay 60,000 input tokens at 1,000 output tokens (malayo pa rin sa 380K window). Narito ang halaga nito ngayon:

Sa mga numerong iyon, $0.001 bawat dokumento ang live na presyo para sa isang ganoong tawag, at sa kabuuan, kasama ang input at output, mas mababa ito kaysa sa OpenRouter.