LLM โลคอล VRAM หมด? ดู weights กับ KV cache ด้วย gputaskman

โมเดลโลคอลของคุณโหลดได้ปกติเมื่อวาน แต่วันนี้กลับพังตอนโหลดหรือช้าอย่างกับหอยทาก และสิ่งเดียวที่คุณเปลี่ยนคือความยาวคอนเท็กซ์ ตัวการที่พบบ่อยคือ KV cache และเครื่องมือเทอร์มินัลฟรีชื่อ gputaskman ช่วยให้คุณเห็นสิ่งนั้นแทนที่จะปล่อยให้คุณเดา

โปรแกรมมอนิเตอร์ GPU ทั่วไปบอกคุณว่า VRAM เต็มแค่ไหน นั่นคือ "อะไร" ไม่ใช่ "ทำไม" README ของ gputaskman (ตรวจสอบเมื่อ 5 พฤศจิกายน 2026) เรียกตัวเองว่า "An htop for what's inside your GPU, not just how full it is." มันเป็นโปรเจกต์ระยะเริ่มต้น ทดลอง และใช้สัญญาอนุญาต MIT ดังนั้นมองมันเป็นเลนส์ที่ handy ไม่ใช่คำตัดสิน

อะไรกันแน่ที่กิน VRAM ของคุณ#

ลองนึกถึง VRAM เป็นกระเป๋าเดินทาง มีสามอย่างที่ใส่เข้าไป:

• Weights: ตัวโมเดล ขนาดคงที่สำหรับโมเดลและ quantization ที่กำหนด
• KV cache: ความจำระยะสั้นของโมเดลต่อบทสนทนาของคุณ มันโตขึ้นเมื่อคอนเท็กซ์โตขึ้น
• Compute buffers: พื้นที่ชั่วคราวที่ runtime ต้องใช้ระหว่างทำงาน

เมื่อคนพูดว่า "โมเดลไม่พอดี" พวกเขามักหมายความว่า weights พอดี แต่ cache ที่คุณขอเพิ่มเข้าไปไม่พอดี ความแตกต่างนี้เป็นตัวกำหนดวิธีแก้ และเป็นสิ่งที่มอนิเตอร์ทั่วไปซ่อนไว้พอดี

ติดตั้ง gputaskman และดูรายโปรเซส#

README ระบุสามวิธี: ZIP แบบพกพาสำหรับ Windows, clone แล้วรันด้วย uv run --locked gputaskman หรือ pip ใน virtual environment ของ Python 3.11+ แพลตฟอร์มตามที่ README อธิบาย:

• Windows 10/11 64-bit พร้อม GPU NVIDIA หรือ AMD (ZIP สำหรับ x64 และ ARM64 อยู่บนหน้า Releases);
• Linux และ WSL พร้อม GPU NVIDIA (glibc 2.35+; WSL อ่านตัวนับของโฮสต์ Windows ได้);
• macOS บน Apple Silicon เฉพาะจาก source clone ไม่มี build แบบพกพา

ZIP สำหรับ Windows ไม่ได้ลงนาม ดาวน์โหลดจากหน้า Releases ของรีโปอย่างเป็นทางการเท่านั้น github.com/shanselman/gputaskman คัดลอกคำสั่งจาก README ตามตัวอักษร โปรเจกต์ยังใหม่และตัวเลือกอาจเปลี่ยนได้

เมื่อรันแล้ว มีสองมุมมองที่สำคัญกับปัญหานี้:

1. Device view: การใช้ VRAM, กิจกรรม GPU, PCIe, อุณหภูมิ, กำลังไฟ, คล็อก และกราฟประวัติ เหมาะกับคำถาม "มีอะไรพุ่งขึ้นมาไหม?"
2. Process view: หน่วยความจำ GPU โลคอลต่อโปรเซส, RAM ระบบที่ GPU เข้าถึงได้, กิจกรรมของเอนจิน และ runtime ที่ตรวจพบ (CUDA, HIP, Vulkan, Direct3D, ggml, ONNX Runtime)

ในมุมมองรายโปรเซส ให้หาเซิร์ฟเวอร์โมเดลของคุณ (สำหรับ Ollama คือ runner ที่มาพร้อมกัน) แล้วตรวจส่วนที่เหลือของรายการ ถ้าเบราว์เซอร์หรือเกมถืออยู่หลายกิกะไบต์ คุณก็ได้คำตอบแล้วโดยไม่ต้องแตะโมเดล

Weights, KV cache, buffers: ตัวเลขมาจากไหน#

ตัวตรวจสอบโมเดลแสดงสถาปัตยกรรม quantization และขนาดบัฟเฟอร์เมื่อมีข้อมูล มีข้อควรระวังหนึ่งข้อ: ตาม README นั้น weights, KV cache และ compute buffers มาจาก load log ของ runtime เมื่อเปิด logging ที่เข้ากันได้ สำหรับ llama.cpp ให้เริ่ม llama-server ของคุณเองพร้อม logging (--log-file server.log -lv 4; README ระบุว่าต้องใช้ระดับ 4 สำหรับขนาดบัฟเฟอร์) สำหรับ Ollama นั้น gputaskman ใช้ server.log ของ Ollama ถ้ามี มิฉะนั้นจะเป็น ค่าประมาณ จาก metadata ของ GGUF และขนาดคอนเท็กซ์ โดยสมมติการจัดวางแบบ llama.cpp การบัญชี KV ต่อโมเดลภายในโปรเซสเดียวยังไม่รองรับ

ดังนั้นอ่านการแบ่งที่เป็นค่าประมาณว่า "คร่าว ๆ" และการแบ่งที่อิง log ว่า "สิ่งที่ runtime รายงาน" สำหรับ Ollama นั้น README ระบุว่าตรวจพบ runner ที่มาพร้อมกัน, blob ของ GGUF ถูกตั้งชื่อจาก manifest ของ Ollama และใช้ server.log เมื่อมี การรองรับ LM Studio เป็นบางส่วน: โมเดลถูกตั้งชื่อจากโฟลเดอร์ของมันและตรวจสอบผ่าน API โลคอล แต่ทดสอบด้วย fixture response ไม่ใช่แบบ end to end

คุณยังบันทึก snapshot สองอันเป็น JSON และเปรียบเทียบด้วยคำสั่ง diff ได้ด้วย นั่นเป็นวิธีที่สะอาดในการตอบคำถาม "อะไรเปลี่ยนไปเมื่อผมเปลี่ยนจากคอนเท็กซ์ 4K เป็น 16K?": จับ snapshot หนึ่งครั้ง เปลี่ยนการตั้งค่า โหลดใหม่ จับอีกครั้ง

หมุนปุ่มไหน#

การอ่านการแบ่งทำให้คุณได้การตัดสินใจ ไม่ใช่แค่ภาพ

Weights คือส่วนที่ใหญ่ เปลี่ยนไปใช้ quantization ที่เล็กลงหรือโมเดลที่เล็กลง นี่คือคันโยกเดียวที่ลด weights ได้ ถ้าอยากได้คณิตศาสตร์เรื่องหน่วยความจำเบื้องหลัง ดู Can a 125B model run on a 16 GB GPU?

KV cache คือส่วนที่ใหญ่ ลดความยาวคอนเท็กซ์ ใน Ollama คุณลองได้เลยในเซสชัน:

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

8192 เป็นเพียงค่าตัวอย่าง เลือกค่าที่งานของคุณต้องการจริง ๆ (คำสั่งตามเอกสารของ Ollama ตรวจสอบเมื่อ 5 พฤศจิกายน 2026)

ถ้าภายหลังคุณเห็นความช้าที่แปลก ๆ ตอนประมวลผล prompt กับ cache แบบ quantized ใน llama.cpp การแก้ไขนี้สำหรับ KV cache แบบ q5_1 คือจุดต่อไป สำหรับสิ่งที่ context window เก็บได้ตั้งแต่แรก อ่าน What is a context window?

โปรเซสอื่นคือส่วนที่ใหญ่ ปิดมัน หรือรันบน GPU แบบ integrated ไม่มีอะไรในโมเดลต้องเปลี่ยน

ถ้ามันไม่ทำงาน#

• การแบ่งดูผิด ตรวจว่ามันเป็นค่าประมาณหรือไม่ (ไม่มี load log ที่เข้ากันได้) กับ llama.cpp ให้รัน llama-server ของคุณด้วย --log-file server.log -lv 4 แล้วโหลดโมเดลใหม่ กับ Ollama นั้น gputaskman ใช้ server.log ถ้ามี ป้ายค่าประมาณเป็นเรื่องปกติตรงนั้น
• LM Studio แสดงรายละเอียดน้อยลง การรองรับเป็นบางส่วนตามข้างต้น
• ไม่มี GPU NVIDIA หรือ AMD เครื่องมือนี้ครอบคลุมเฉพาะงาน GPU โลคอล งานแบบ CPU-only, NPU-only และคลาวด์อยู่นอกขอบเขต
• macOS รันจาก source clone ไม่มี build แบบพกพา

เมื่อโมเดลแบบโฮสต์เป็นทางแก้ที่ง่ายกว่า#

สมมติคุณต้องการคอนเท็กซ์ยาวสำหรับงานหนึ่ง เช่นสรุปเอกสารใหญ่ และ GPU ของคุณใส่โมเดลได้แค่กับคอนเท็กซ์สั้น คุณจะปรับแต่งต่อไปหรือเอา VRAM ออกจากสมการก็ได้ สำหรับงานแบบนั้น CheapTokens เสนอ DeepSeek-V4-Flash: คอนเท็กซ์ 380K เอาต์พุตสูงสุด 32,768 โทเคนต่อคำตอบ ราคาเดียวตลอดทั้งวัน ผ่าน API ที่เข้ากันได้กับ OpenAI GLM-5.3-Flash มีคอนเท็กซ์ 390K และเอาต์พุตสูงสุด 8,192 โทเคน

การเรียกใช้เป็นรูปแบบ OpenAI ปกติ (ใส่คีย์ของคุณใน 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: ..."}]}'

รายละเอียดการตั้งค่าอยู่ใน docs กฎง่าย ๆ ในการตัดสินใจ: ถ้างานหนึ่งต้องใช้คอนเท็กซ์มากขึ้นหรือโมเดลใหญ่กว่าที่การ์ดของคุณใส่ได้เรื่อย ๆ และมุมมองรายโปรเซสแสดงว่า VRAM ของคุณถูกใช้ไปมากแล้ว ให้ส่งงานนั้นไปที่ API และเก็บงานเล็ก ๆ ที่เร็วไว้โลคอล Run DeepSeek locally or use an API? เจาะลึกเรื่องการแลกเปลี่ยนนี้

สมมติคุณสรุปเอกสารใหญ่ 100 ฉบับ แต่ละฉบับมีอินพุต 60,000 โทเคนและเอาต์พุต 1,000 โทเคน (อยู่ในหน้าต่าง 380K ได้สบาย) นี่คือค่าใช้จ่ายวันนี้:

จากตัวเลขเหล่านั้น $0.001 ต่อเอกสารคือราคาจริงสำหรับการเรียกหนึ่งครั้ง และโดยรวมเมื่อนับอินพุตและเอาต์พุตรวมกัน ต่ำกว่า OpenRouter