ประโยคว่า “DeepSeek V4 ใช้หน่วยความจำน้อยลง 98%” ฟังดูน่าตื่นเต้น แต่จุดที่ต้องระวังคือคำว่า “หน่วยความจำ” ในที่นี้หมายถึงอะไร ถ้าหมายถึง KV cache ซึ่งเป็นหน่วยความจำที่ใช้เก็บ key-value ระหว่างการ inference ของโมเดลภาษา โดยเฉพาะเมื่อ context ยาวมาก หลักฐานสาธารณะมีน้ำหนักพอสมควรว่า DeepSeek V4 ปรับปรุงตรงนี้จริง แต่ถ้าหมายถึง VRAM รวมทั้งหมดของการ deploy โมเดลบน GPU หลักฐานยังไม่ถึงขั้นนั้น [5][
13][
14]
สรุปแบบปลอดภัยที่สุด
คำอธิบายที่แม่นกว่า คือ:
DeepSeek V4 ใช้สถาปัตยกรรม Hybrid Attention ร่วมกับ Compressed Sparse Attention หรือ CSA และ Heavily Compressed Attention หรือ HCA เพื่อลดภาระ KV cache และต้นทุน attention ในงาน long-context inference อย่างมาก แต่ข้อมูลปัจจุบันยังไม่พอจะสรุปว่า VRAM รวมของทั้งระบบลดลง 98% [
13][
14]
ความต่างนี้สำคัญมาก เพราะ KV cache อาจเป็นคอขวดใหญ่ของ LLM เมื่อใช้ context ยาว เช่น เอกสารหลายแสนถึงล้าน token หรือ agent ที่เรียกเครื่องมือหลายรอบ แต่ KV cache ไม่ใช่หน่วยความจำทั้งหมดที่ต้องใช้ในการให้บริการโมเดลหนึ่งตัว
เอกสารทางการบอกอะไรจริง ๆ
หน้า API news ของ DeepSeek ระบุว่า DeepSeek-V4 Preview เปิดตัวเมื่อ 24 เมษายน 2026 [5] ส่วน model card ของ DeepSeek V4 ระบุว่าซีรีส์นี้มี DeepSeek-V4-Pro และ DeepSeek-V4-Flash เป็นโมเดลภาษาแบบ Mixture-of-Experts หรือ MoE โดยยังคง DeepSeekMoE framework และกลยุทธ์ Multi-Token Prediction หรือ MTP จากรุ่นก่อน พร้อมเพิ่มการเปลี่ยนแปลงด้านสถาปัตยกรรม เช่น Hybrid Attention Architecture [
14]
ส่วนที่เกี่ยวข้องกับ “การประหยัดหน่วยความจำ” โดยตรงคือการจัดการ 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 เพิ่มเติม [13]
กล่าวอีกแบบคือ ข้อมูลที่มีรองรับว่า 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” [21] เนื้อหาลักษณะนี้ใช้เป็นเบาะแสในการตามตรวจสอบได้ แต่ไม่ควรถูกถือเป็นสเปกทางการของ DeepSeek
ตัวเลขจากรายงานภายนอกที่ตีความได้ตรงกว่า คือ 10% KV cache โดย Wccftech รายงานว่าเมื่อเทียบกับ DeepSeek V3.2 แล้ว DeepSeek V4 ต้องใช้เพียง 27% ของ single-token inference FLOPs และ 10% ของ key-value หรือ KV cache [20] ถ้าตีความเฉพาะ “10% KV cache” ก็เท่ากับ KV cache ลดลงราว 90% เมื่อเทียบกับฐานดังกล่าว แต่ยังไม่ใช่การลด VRAM รวม 90% และไม่ได้แปลว่าจะเกิดขึ้นเหมือนกันทุก context length, batch size, hardware หรือ serving engine [
20]
อีกตัวเลขที่ควรแยกออกจากกันคือพาดหัวข่าวที่ว่า DeepSeek V4 มี 9.5x lower memory requirements [3] หากคิดเชิงคณิตศาสตร์แบบตรง ๆ 1/9.5 เหลือประมาณ 10.5% หรือเท่ากับลดลงราว 89.5% ซึ่งก็ยังไม่ใช่ 98% และยังต้องตรวจสอบว่าหมายถึง KV cache, งาน long-context เฉพาะกรณี หรือหน่วยความจำทั้งหมดของการ deploy [
3]
| คำกล่าวอ้าง | สถานะหลักฐาน | วิธีตีความที่ระมัดระวัง |
|---|---|---|
| VRAM รวมลดลง 98% | ยังไม่พบหลักฐานทางการรองรับ | ไม่ควรใช้เป็นสเปกสำหรับจัดซื้อ วาง capacity หรือทำข้อความการตลาด [ |
| KV cache ถูกบีบอัดมาก | มีข้อมูลเทคนิครองรับ | CSA/HCA ออกแบบมาเพื่อลด KV entries ในงานบริบทยาว [ |
| ใช้ 10% KV cache | เป็นรายงานภายนอก | ตีความได้ว่า KV cache ลดลงราว 90% เมื่อเทียบกับ V3.2 แต่ไม่ใช่ VRAM รวมลดลง [ |
| memory requirements ต่ำลง 9.5x | เป็นพาดหัวจากสื่อภายนอก | เทียบได้กับการลดลงราว 89.5% แต่ยังต้องดูขอบเขตการเปรียบเทียบ [ |
ทำไม 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 [17] เวอร์ชัน GitHub ของบทความเดียวกันยังอธิบาย failure mode ของงาน agent ยาว ๆ ว่า trace อาจเกิน context budget, KV cache อาจเติม GPU จนเต็ม หรือรอบการเรียกเครื่องมือทำให้งานช้าลงระหว่างทาง [
22]
แต่การ deploy โมเดลหนึ่งตัวไม่ได้ใช้ VRAM แค่ KV cache เท่านั้น ยังมีน้ำหนักโมเดลหรือ weights, activations, memory ของ framework, overhead ของระบบ serving และปัจจัยด้าน concurrency ด้วย แม้แต่บทความ LinkedIn ที่พูดถึงตัวเลข 98% ก็ยังแยกหมวด shared weights, expert weights, activations, KV cache และ framework overhead ออกจากกัน [21] จุดนี้ยิ่งตอกย้ำว่าเวลาวางแผนเครื่องต้องดูเป็นส่วน ๆ ไม่ควรเอาการลดลงของ 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 เดียว [13]
รายงานเทคนิคของ DeepSeek V4 ยังกล่าวถึงการปรับโครงสร้างพื้นฐานสำหรับ training และ inference เช่น การออกแบบ single fused kernel สำหรับ MoE modules เพื่อ overlap งาน computation, communication และ memory access [2] นี่เป็นงานวิศวกรรมด้านประสิทธิภาพที่มีความหมาย แต่ก็ยังไม่ใช่หลักฐานโดยตรงว่า VRAM รวมของระบบลดลง 98%
ถ้าจะประเมิน DeepSeek V4 ควรดูอะไร
ถ้ากำลังพิจารณา DeepSeek V4 สำหรับงานเอกสารยาว แชตยาว หรือ agent workflow คำถามสำคัญไม่ใช่ว่า “98% จริงไหม” แต่คือ คอขวดของคุณอยู่ที่ KV cache หรือไม่ ข้อมูลสาธารณะรองรับว่า V4 ปรับปรุง KV cache ในบริบทยาวอย่างชัดเจน แต่ยังไม่พอที่จะนำคำว่า “98% less memory” ไปใช้ในเอกสารจัดซื้อ การวาง capacity หรือข้อความประชาสัมพันธ์ [13][
20][
21][
22]
แนวทางที่น่าเชื่อถือกว่าคือ benchmark ด้วย workload ของตัวเอง: context length, batch size, concurrency, serving engine และฮาร์ดแวร์ที่ใช้จริง หากงานของคุณถูกจำกัดโดย KV cache เป็นหลัก สถาปัตยกรรมบีบอัดของ V4 อาจมีคุณค่ามาก แต่ถ้าคอขวดอยู่ที่ weights, activations, overhead ของ framework หรือกลยุทธ์รองรับผู้ใช้พร้อมกัน การลด KV cache ก็ไม่ได้แปลว่า VRAM รวมจะลดลงในสัดส่วนเดียวกัน [13][
21][
22]




