DeepSeek V4 ประหยัดหน่วยความจำ 98% จริงไหม?

หน้า API news ของ DeepSeek ระบุว่า DeepSeek-V4 Preview เปิดตัวเมื่อ 24 เมษายน 2026 ส่วน model card ของ DeepSeek V4 ระบุว่าซีรีส์นี้มี DeepSeek-V4-Pro และ DeepSeek-V4-Flash เป็นโมเดลภาษาแบบ Mixture-of-Experts หรือ MoE โดยยังคง DeepSeekMoE framework และกลยุทธ์ Multi-Token Prediction หรือ MTP จากรุ่นก่อน พร้อมเพิ่มการเปลี่ยนแปลงด้านสถาปัตยกรรม เช่น Hybrid Attention Architecture

ส่วนที่เกี่ยวข้องกับ “การประหยัดหน่วยความจำ” โดยตรงคือการจัดการ attention สำหรับบริบทยาว บทความเทคนิคของ NVIDIA อธิบายว่า Compressed Sparse Attention (CSA) ใช้ dynamic sequence compression เพื่อบีบอัด KV entries ลดขนาด KV cache memory footprint จากนั้นใช้ DeepSeek Sparse Attention หรือ DSA เพื่อทำให้ attention matrices มีความ sparse มากขึ้นและลดภาระคำนวณ ส่วน Heavily Compressed Attention (HCA) จะบีบอัดหนักกว่า โดยรวม KV entries ของหลายชุด token ให้เป็น compressed entry เดียว เพื่อลดขนาด KV cache เพิ่มเติม

กล่าวอีกแบบคือ ข้อมูลที่มีรองรับว่า DeepSeek V4 ออกแบบมาเพื่อลด ขนาด KV cache และ ต้นทุนการคำนวณ attention แต่ยังไม่เท่ากับการรับรองว่า VRAM ทั้งหมดของการใช้งานจริงจะลดลงในสัดส่วนเดียวกัน

อย่าสับสนระหว่าง 98%, 90% และ 9.5x

ตัวเลข 98% ที่พบชัดเจนในข้อมูลสาธารณะมาจากบทความ LinkedIn แบบ user-generated ที่ใช้หัวข้อว่า “DeepSeek Sparse Attention Shrinks KV Memory by 98 Percent in Real World Serving” เนื้อหาลักษณะนี้ใช้เป็นเบาะแสในการตามตรวจสอบได้ แต่ไม่ควรถูกถือเป็นสเปกทางการของ DeepSeek

ตัวเลขจากรายงานภายนอกที่ตีความได้ตรงกว่า คือ 10% KV cache โดย Wccftech รายงานว่าเมื่อเทียบกับ DeepSeek V3.2 แล้ว DeepSeek V4 ต้องใช้เพียง 27% ของ single-token inference FLOPs และ 10% ของ key-value หรือ KV cache ถ้าตีความเฉพาะ “10% KV cache” ก็เท่ากับ KV cache ลดลงราว 90% เมื่อเทียบกับฐานดังกล่าว แต่ยังไม่ใช่การลด VRAM รวม 90% และไม่ได้แปลว่าจะเกิดขึ้นเหมือนกันทุก context length, batch size, hardware หรือ serving engine

อีกตัวเลขที่ควรแยกออกจากกันคือพาดหัวข่าวที่ว่า DeepSeek V4 มี 9.5x lower memory requirements หากคิดเชิงคณิตศาสตร์แบบตรง ๆ 1/9.5 เหลือประมาณ 10.5% หรือเท่ากับลดลงราว 89.5% ซึ่งก็ยังไม่ใช่ 98% และยังต้องตรวจสอบว่าหมายถึง KV cache, งาน long-context เฉพาะกรณี หรือหน่วยความจำทั้งหมดของการ deploy

ทำไม KV cache ไม่เท่ากับ VRAM รวม

KV cache สำคัญมากในงาน inference ที่มี context ยาว เพราะโมเดลต้องเก็บข้อมูล key-value จาก token ก่อนหน้าไว้ใช้ในการสร้าง token ถัดไป ยิ่ง sequence ยาว หน่วยความจำส่วนนี้ยิ่งโต บทความของ Hugging Face อธิบายว่าใน long-running agentic workload ผลลัพธ์จากเครื่องมือจะถูกต่อเข้า context ไปเรื่อย ๆ ทำให้ token ถัด ๆ ไปต้องรับภาระ attention กับบริบทที่ยาวขึ้น และทั้ง single-token inference FLOPs กับขนาด KV cache จะเพิ่มตาม sequence length เวอร์ชัน GitHub ของบทความเดียวกันยังอธิบาย failure mode ของงาน agent ยาว ๆ ว่า trace อาจเกิน context budget, KV cache อาจเติม GPU จนเต็ม หรือรอบการเรียกเครื่องมือทำให้งานช้าลงระหว่างทาง

แต่การ deploy โมเดลหนึ่งตัวไม่ได้ใช้ VRAM แค่ KV cache เท่านั้น ยังมีน้ำหนักโมเดลหรือ weights, activations, memory ของ framework, overhead ของระบบ serving และปัจจัยด้าน concurrency ด้วย แม้แต่บทความ LinkedIn ที่พูดถึงตัวเลข 98% ก็ยังแยกหมวด shared weights, expert weights, activations, KV cache และ framework overhead ออกจากกัน จุดนี้ยิ่งตอกย้ำว่าเวลาวางแผนเครื่องต้องดูเป็นส่วน ๆ ไม่ควรเอาการลดลงของ KV cache ไปแทนการลดลงของ VRAM ทั้งระบบโดยอัตโนมัติ

CSA/HCA คือวิศวกรรมเพื่อประสิทธิภาพ ไม่ใช่เลขมหัศจรรย์

ทิศทางของ DeepSeek V4 น่าสนใจ เพราะมันแตะปัญหาแพงที่สุดข้อหนึ่งของ million-token context inference นั่นคือ attention และ KV cache ในลำดับข้อมูลที่ยาวมาก NVIDIA อธิบายว่า CSA/HCA ลดขนาด KV cache และต้นทุนคำนวณด้วยการบีบอัด KV entries, ทำให้ attention matrices sparse ขึ้น และรวม KV entries ของหลาย token set ให้เป็น compressed entry เดียว

รายงานเทคนิคของ DeepSeek V4 ยังกล่าวถึงการปรับโครงสร้างพื้นฐานสำหรับ training และ inference เช่น การออกแบบ single fused kernel สำหรับ MoE modules เพื่อ overlap งาน computation, communication และ memory access นี่เป็นงานวิศวกรรมด้านประสิทธิภาพที่มีความหมาย แต่ก็ยังไม่ใช่หลักฐานโดยตรงว่า VRAM รวมของระบบลดลง 98%

ถ้าจะประเมิน DeepSeek V4 ควรดูอะไร

ถ้ากำลังพิจารณา DeepSeek V4 สำหรับงานเอกสารยาว แชตยาว หรือ agent workflow คำถามสำคัญไม่ใช่ว่า “98% จริงไหม” แต่คือ คอขวดของคุณอยู่ที่ KV cache หรือไม่ ข้อมูลสาธารณะรองรับว่า V4 ปรับปรุง KV cache ในบริบทยาวอย่างชัดเจน แต่ยังไม่พอที่จะนำคำว่า “98% less memory” ไปใช้ในเอกสารจัดซื้อ การวาง capacity หรือข้อความประชาสัมพันธ์

แนวทางที่น่าเชื่อถือกว่าคือ benchmark ด้วย workload ของตัวเอง: context length, batch size, concurrency, serving engine และฮาร์ดแวร์ที่ใช้จริง หากงานของคุณถูกจำกัดโดย KV cache เป็นหลัก สถาปัตยกรรมบีบอัดของ V4 อาจมีคุณค่ามาก แต่ถ้าคอขวดอยู่ที่ weights, activations, overhead ของ framework หรือกลยุทธ์รองรับผู้ใช้พร้อมกัน การลด KV cache ก็ไม่ได้แปลว่า VRAM รวมจะลดลงในสัดส่วนเดียวกัน