KVSplit - รันคอนเท็กซ์ได้ยาวขึ้น 2-3 เท่าบน Apple Silicon

• KVSplit เป็นโปรเจกต์โอเพนซอร์สที่ช่วยให้รัน LLM ขนาดใหญ่ และหน้าต่างคอนเท็กซ์ที่ยาวขึ้นบน Apple Silicon ได้
• ด้วยการ กำหนด precision แยกกันให้คีย์และแวลู ทำให้ ลดการใช้หน่วยความจำได้สูงสุด 72% และคุณภาพลดลงไม่ถึง 1%
• ปรับแต่งมาสำหรับชิป M1/M2/M3 และเฟรมเวิร์ก Metal
• พิสูจน์การ ปรับปรุงความเร็วในการรัน และการประหยัดหน่วยความจำด้วย benchmark ที่วัดจริงและเครื่องมือ visualization
• ติดตั้งได้ง่าย มีการเปรียบเทียบแบบคำสั่งเดียว และมี เครื่องมือ benchmark และวิเคราะห์ ที่หลากหลาย

---

บทนำ: ทำไม KVSplit จึงสำคัญ

KVSplit เป็นเครื่องมือโอเพนซอร์สที่ทำให้สามารถรัน LLM ขนาดใหญ่และใช้หน้าต่างคอนเท็กซ์ที่ยาวขึ้นมากบนสภาพแวดล้อม Apple Silicon (M1/M2/M3) ได้ โดยใช้ การ quantize ที่กำหนด precision ต่างกันให้กับคีย์และแวลูภายใน KV cache ซึ่งช่วยก้าวข้ามข้อจำกัดของโปรเจกต์เดิมที่ quantize คีย์และแวลูเหมือนกันทั้งหมด พร้อมทั้ง ลดการใช้หน่วยความจำได้อย่างมาก แต่ยังควบคุมการลดลงของคุณภาพให้อยู่ในระดับที่แทบสังเกตไม่ได้ อีกทั้งยังมีการ เปิดเผย benchmark จริง ความเร็ว และตัวชี้วัดคุณภาพทั้งหมด จึงเชื่อถือได้ และด้วย การรองรับ Metal รวมถึงเครื่องมือเปรียบเทียบและ visualization ที่ใช้งานง่าย จึงช่วยเพิ่มประสิทธิภาพในการพัฒนาได้มาก

ข้อดีหลักเมื่อเทียบกับโปรเจกต์ประเภทเดียวกันมีดังนี้:

• แยก precision ของคีย์-แวลู เพื่อให้จัดการหน่วยความจำได้มีประสิทธิภาพยิ่งขึ้น
• ออกแบบมาเฉพาะสำหรับ Apple Silicon และรองรับการปรับแต่งเต็มรูปแบบกับเฟรมเวิร์ก Metal
• มี benchmark, perplexity, การวัดหน่วยความจำ/ความเร็ว/คุณภาพ และ visualization ให้แบบครบชุด
• ติดตั้งด้วยคำสั่งเดียว, รองรับโมเดล, ผสานรวมกับ llama.cpp
• มีการ แสดงภาพการประหยัดหน่วยความจำแบบเรียลไทม์ และเครื่องมือทดสอบเปรียบเทียบหลากหลาย

คุณสมบัติเด่นและสาระสำคัญ

ภาพรวม

• ใช้ KVSplit แล้วสามารถรัน LLM ที่ใหญ่กว่าเดิมมาก และ ความยาวคอนเท็กซ์ที่ยาวขึ้น บน Apple Silicon ได้
• ด้วยการ กำหนด precision สำหรับคีย์และแวลูแยกกัน จึงได้ทั้งการประหยัดหน่วยความจำและการเพิ่มความเร็ว
• ยืนยันแล้วว่าสามารถ ประหยัดหน่วยความจำได้สูงสุด 72% และ เพิ่มความเร็ว (5-15%↑) โดยคุณภาพลดลงไม่ถึง 1%
• รองรับ Metal อย่างสมบูรณ์ เพื่อให้ได้ ประสิทธิภาพเร่งความเร็วสูงสุดบน Apple Silicon

ผล benchmark หลัก

• ในการตั้งค่า K8V4 (คีย์ 8 บิต, แวลู 4 บิต)
  • ประหยัดหน่วยความจำ 59% และ คุณภาพลดลง 0.86% (อิงค่า perplexity)
  • เร็วขึ้น 5.7% เมื่อเทียบกับ FP16
• ในการตั้งค่า K4V4 (คีย์/แวลู 4 บิตทั้งคู่)
  • ประหยัดหน่วยความจำได้สูงสุด 72%
  • แต่คุณภาพลดลงประมาณ 6% แนะนำสำหรับงานที่ไม่ไวต่อคุณภาพมากนัก

การเปรียบเทียบผลการประหยัดหน่วยความจำ

• จากฐาน FP16 ที่ 176MB (8K token)
  • K8V8 (คีย์/แวลู 8 บิต) : 93.5MB (47%)
  • K8V4 (คีย์ 8 บิต, แวลู 4 บิต) : 71.5MB (41%)
  • K4V4 (คีย์/แวลู 4 บิต) : 49.5MB (28%)

ฟีเจอร์หลัก

• ฟังก์ชัน quantize แยกคีย์·แวลูของ KV cache
• ปรับแต่งเต็มรูปแบบสำหรับ Apple Silicon·Metal
• สคริปต์วิเคราะห์ benchmark/คุณภาพ(perplexity)/การใช้หน่วยความจำ
• เครื่องมือ visualization และการสร้างกราฟคุณภาพระดับงานตีพิมพ์
• ตั้งค่าด้วยคำสั่งเดียวและฟังก์ชันเปรียบเทียบแบบเรียลไทม์

โครงสร้างโฟลเดอร์โปรเจกต์

• llama.cpp: รวม build ที่ปรับแต่งสำหรับ Metal
• models: เก็บไฟล์โมเดล
• scripts: รวมสคริปต์สำหรับ benchmark/ติดตั้ง/เปรียบเทียบ/visualization
• results, plots: เก็บผล benchmark และไฟล์ visualization
• README.md

อินไซต์เชิงวิทยาศาสตร์และผลการทดลอง

ปรากฏการณ์สำคัญของ KV cache

• เวกเตอร์คีย์ มี ความไวต่อการ quantize สูงกว่าเวกเตอร์แวลูมาก → จึงต้องให้คีย์มี precision สูงกว่าเพื่อรักษาคุณภาพ
• K8V4 คือ sweet spot: การจัดสรรคีย์ 8 บิต/แวลู 4 บิต ให้จุดสมดุลที่ดีที่สุดระหว่างคุณภาพกับหน่วยความจำ
  • ประหยัดหน่วยความจำ 59%, ค่า perplexity แย่ลงเพียง 0.86%, และยังเร็วกว่า FP16
• K4V8 แม้จะใช้จำนวนบิตรวมเท่ากับ K8V4 แต่กลับมี คุณภาพลดลงมากกว่า 7 เท่า → ยืนยันความสำคัญของ precision ฝั่งคีย์

ข้อสรุปโดยรวม

• ทำได้ทั้ง เพิ่มประสิทธิภาพด้านหน่วยความจำ และ รักษาคุณภาพของโมเดล → ช่วยให้ฮาร์ดแวร์ระดับผู้บริโภคสามารถรันคอนเท็กซ์ที่ยาวขึ้นมากและโมเดลที่ใหญ่ขึ้นได้

ตัวอย่างการใช้งานและคำแนะนำการตั้งค่า

ตัวอย่างการรันด้วย precision ของการ quantize แบบต่าง ๆ

• ค่าเริ่มต้น (FP16): ./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "พรอมป์ต์" -t 8 --flash-attn
• แนะนำ K8V4: --kvq 8
• K4V8 (DEMO): --kvq-key 4 --kvq-val 8
• K4V4 (ประหยัดสูงสุด): --kvq 4

ตัวอย่างคอนเท็กซ์ยาว

• คอนเท็กซ์ 32K: FP16 ต้องใช้ประมาณ ~1.4GB แต่ K8V4 สามารถรันได้ด้วย ~400MB

คำอธิบาย command-line flags

• -t 8: จำนวนเธรด, แนะนำ 8 สำหรับ M1/M2/M3
• --flash-attn: การปรับแต่งสำหรับ Apple Silicon
• --kvq N: ตั้งค่าคีย์/แวลูเป็น N บิตทั้งคู่
• --kvq-key, --kvq-val: รองรับการตั้งค่าแยกกัน
• -c N: จำนวน token ของคอนเท็กซ์ (ยิ่งยาวยิ่งเห็นผลของ KVSplit ชัด)
• -n N: จำนวน token ที่จะ generate
• -f FILE: ไฟล์เอกสารนำเข้า
• -m MODEL: พาธของโมเดล

Benchmark ขั้นสูงและ visualization

• ใช้ benchmark_kvsplit.py เพื่อวัดคุณลักษณะด้านการตั้งค่าแต่ละแบบ, ความยาว sequence, หน่วยความจำ/ความเร็ว/perplexity/การสเกล
• ใช้ visualize_results.py เพื่อสร้างกราฟระดับงานวิจัย
• บันทึกผลเป็น CSV/JSON อัตโนมัติพร้อมสรุปให้

การปรับแต่งสำหรับ Apple Silicon และการแสดงภาพหน่วยความจำ

• ใช้งาน เฟรมเวิร์ก Metal ได้เต็มรูปแบบ
• ให้ผลชัดเจนอย่างยิ่งกับเครื่อง M1/M2/M3 ที่มีข้อจำกัดด้านหน่วยความจำ
• ใช้ capture_memory.sh เพื่อแสดงภาพการประหยัดหน่วยความจำแบบเรียลไทม์ได้
• การจัดเรียงเพจแบบกำหนดเองอาจทำให้ปริมาณที่ประหยัดได้จริงต่างจากค่าทางทฤษฎีเล็กน้อย

สรุปฟังก์ชันเด่น

• precision บิตของคีย์/แวลูแบบอิสระ และการ quantize แบบปรับแต่งได้
• Apple Silicon และ Metal ที่ปรับแต่งมาอย่างสมบูรณ์
• มี benchmark แบบครบวงจร ด้านหน่วยความจำ/ความเร็ว/คุณภาพ
• รองรับ visualization คุณภาพระดับงานวิจัยและการเปรียบเทียบแบบเรียลไทม์ รวมถึงการจับภาพหน่วยความจำ
• อินเทอร์เฟซติดตั้ง/ใช้งานที่ง่ายมาก

งานอ้างอิงและการวิจัยที่เกี่ยวข้อง

• "More for Keys, Less for Values: Adaptive KV Cache Quantization" (2024)
• "Unifying KV Cache Compression for Large Language Models with LeanKV" (2025)
• อิมพลีเมนเทชันพื้นฐาน: [llama.cpp], โมเดลทดสอบ: [TinyLlama]

คำแนะนำการตั้งค่าและแผนในอนาคต

• K8V4 (คีย์ 8 บิต/แวลู 4 บิต) : คุณภาพลดลง 0.86%, ประหยัดหน่วยความจำ 59%, ความเร็ว +5.7% เป็นสมดุลที่ดีที่สุด
• K4V4: ประหยัดหน่วยความจำได้สูงสุด (72%) แต่คุณภาพลดลงประมาณ 6% เหมาะกับงานที่ให้ความสำคัญกับหน่วยความจำเป็นอันดับแรก
• เด่นเป็นพิเศษสำหรับ การรันคอนเท็กซ์ยาว โดยรองรับคอนเท็กซ์ที่ยาวขึ้นได้ 2-3 เท่า

โรดแมปในอนาคต

• precision แบบปรับตามความสำคัญของ token
• การ quantize แยกตามเลเยอร์
• การปรับแต่งเฉพาะโมเดล (Mistral, Phi-3 เป็นต้น)
• เตรียมรองรับ เว็บเดโม และมือถือ (iOS/iPadOS)

ใบอนุญาตและการมีส่วนร่วม

• ใบอนุญาต MIT
• นักพัฒนา/นักวิจัย AI ทุกคนสามารถร่วมพัฒนาผ่าน Issue และ PR ได้

[GN⁺]

ความเห็นบน Hacker News

• แสดงความสนใจว่าเรื่องนี้น่าสนใจ ถามถึงสัญชาตญาณและเส้นทางการค้นพบว่าทำไมปรากฏการณ์นี้จึงเกิดขึ้น เสนอให้ปรับปรุงความเป็นมิตรต่อผู้ใช้ เช่น ขั้นตอนการใช้แพตช์ในสคริปต์ติดตั้งที่ยังไม่สมบูรณ์และการใช้ git submodule รวมถึงเสนอให้แยก llama.cpp ออกจาก dependency ของ Python เพื่อรองรับสภาพแวดล้อม Python ที่หลากหลาย

  • ตอบว่าเป็นคำถามที่ดี พร้อมอธิบายว่าความแตกต่างหลักเกี่ยวข้องกับบทบาทสำคัญของ attention โดย key เป็นตัวกำหนดว่าจะให้ความสนใจกับโทเคนใดเพื่อสร้าง attention pattern ส่วน value ทำหน้าที่ส่งต่อเฉพาะข้อมูลที่มีอยู่ เปรียบเทียบว่าถ้า quantize key vector แรงเกินไป ความเพี้ยนจะกระทบทุกการโต้ตอบระหว่างโทเคน ขณะที่ความผิดพลาดของ value vector จะกระทบเพียงข้อมูลของโทเคนนั้น ใช้อุปมาว่าถ้าเลขชั้นหนังสือในห้องสมุด (key) ผิด ก็จะไปหยิบหนังสือผิดเล่มอย่างสิ้นเชิง ในเชิงคณิตศาสตร์ key จะเข้า softmax ทำให้ความคลาดเคลื่อนเล็กน้อยถูกขยายได้มาก แต่ value เป็นค่าเฉลี่ยเชิงเส้นจึงหักล้างข้อผิดพลาดกันได้ พร้อมเล่าว่าตนเองก็พบความไม่สมมาตรนี้จากงานวิจัยและพยายามตรวจวัดผลกระทบบน Apple Silicon ในเชิงปริมาณ รวมถึงรับปากว่าจะปรับปรุงเรื่อง feedback จากการติดตั้งและ dependency ของ Python
  • ชี้ว่าแพตช์ไม่ได้ถูกใช้กับ llama.cpp จริง ๆ เพราะโค้ด parsing ของ argument ย้ายไปอยู่ใน arg.cpp แล้วจึงไม่มีความหมาย และอธิบายว่าตัวเลือก quantization ของ K/V ก็ถูกเพิ่มเข้า llama.cpp ตั้งแต่ปี 2023 แล้ว จึงตั้งคำถามถึงเหตุผลที่แพตช์นี้ยังมีอยู่ โดยดูเหมือนว่าแค่เปลี่ยน command-line argument เท่านั้น พร้อมแนะนำอย่างหนักแน่นว่าไม่ควรรันไฟล์ install.sh จาก repository ใหม่เพียงเพื่อใช้แพตช์ง่าย ๆ แบบนี้

• ถามว่าแพตช์นี้จะใช้กับ MLX ได้หรือไม่ โดยคาดหวังว่า MLX จะให้ความเร็วได้ดีกว่าและแนวทางนี้จะช่วยให้ผู้ใช้ Mac สนับสนุนบทสนทนายาว ๆ ด้วยความเร็วระดับใช้งานจริงได้

  • ตอบว่าน่าจะเป็นไปได้ แต่ตนกำลังขุดลึกใน MLX อยู่โดยตรง และรู้สึกว่าแม้ framework จะออกแบบมาดี แต่ตัวอย่างโค้ดและข้อมูล benchmarking ยังมีไม่พอจึงยังดูไม่สุกงอม อีกทั้งกลับรู้สึกว่าตัว Haskell binding น่าตื่นเต้นที่สุด โดยมองว่าคุณสมบัติ lazy evaluation อาจเหมาะ และโครงสร้าง compile graph แบบ pure functional ก็น่าจะเข้ากันได้ดี พร้อมหวังว่าจะได้เห็น ML บน Haskell ที่น่าสนใจ

• ถามว่ามันต่างจากตัวเลือก --cache-type-k, --cache-type-v ในทางปฏิบัติหรือไม่

  • แสดงความเห็นแรงว่าโปรเจกต์นี้ดูเหมือนแค่พยายามหา GitHub stars ให้ LLM และจริง ๆ ก็ไม่ต่างจากฟีเจอร์เดิมที่มีอยู่แล้ว
  • เล่าว่าจำได้ว่า MLX/MPS ยังไม่รองรับ 4-bit หรือแม้แต่ 8-bit ก็ยังไม่เพียงพอ และ bf16 เพิ่งถูกเพิ่มเข้ามาไม่นาน แต่ก่อนหน้านี้บน Apple GPU วิธีแบบ type_k/v ทำได้ต่ำสุดเพียง 16-bit (f16/bf16) ดังนั้นแม้จะไม่รู้รายละเอียดภายในของ llama.cpp ชัดเจน แต่อาจเป็นแนวทางที่ต่างออกไปเล็กน้อย
  • เห็นด้วยสั้น ๆ ว่าตนเองก็สงสัยความแตกต่างนี้เหมือนกัน

• หลังอ่านโค้ดแล้วสรุปว่าแพตช์นี้ไม่จำเป็น โดยตรวจจากลิงก์ PR ว่าฟังก์ชันนี้ถูกรวมเข้า llama.cpp ตั้งแต่ปี 2023 แล้ว จึงเตือนว่าควรระวังการถูกชักชวนให้รัน install.sh ในลักษณะใช้แพตช์แทนที่จะใช้ fork repository โดยตรง อีกทั้งชี้ว่า repository มีไฟล์แพตช์หลายชุด โค้ดซ้ำซ้อน และมีการเขียนทับไฟล์แพตช์ ทำให้โครงสร้างสับสน ที่จริงแล้วเพิ่มเพียงตัวเลือก --kvq ทั้งที่มีตัวเลือก quantization แยก K/V อยู่แล้ว จึงสงสัยว่าผู้เขียนไม่น่าจะไม่รู้เรื่องฟังก์ชันเดิมนี้ พร้อมแนะนำว่าไม่ควรรันสคริปต์จาก repository ที่มีสคริปต์ซับซ้อนแบบนี้ แม้โพสต์บน HN และจำนวนดาวบน GitHub จะสูง แต่เนื้อหากลับชวนให้เข้าใจผิด และยังน่ากังวลที่ผู้เขียนคอยหลบเลี่ยงคำถาม นอกจากนี้ยังสรุปว่าทั้ง repository และสคริปต์ปะปนกับ codebase llama.cpp รุ่นเก่าและไม่สอดคล้องกับโครงสร้างล่าสุด จึงยิ่งสร้างความสับสน

  • ระบุว่าตนเองก็เห็นจุดน่าสงสัยหลายอย่าง แต่เผื่อว่าตนอาจพลาดบางอย่างจึงรอคำอธิบายจากผู้เขียน อย่างไรก็ตาม มีสัญญาณอันตรายหลายจุด และเมื่อดูประวัติกิจกรรมบน GitHub ก็สงสัยว่าอาจตั้งใจใช้โค้ดที่สร้างด้วย LLM มาถมโปรเจกต์ Popular ต่าง ๆ
  • แสดงความเห็นว่าท้ายที่สุดก็มีคนพูดอย่างมีเหตุผลเสียที และชี้ว่าแค่การใช้แพตช์แทนที่จะ fork โปรเจกต์ต้นฉบับก็เป็นความเสี่ยงด้านความน่าเชื่อถือแล้ว พร้อมทั้งมองว่าตัวตน GitHub ของผู้เขียนก็น่าสงสัย และมีแนวโน้มส่ง PR ที่มีคราบ LLM ไปยังโปรเจกต์ยอดนิยมจำนวนมากเพื่อสร้างภาพว่าตนเป็นผู้มีส่วนร่วม พร้อมแสดงความกังวลต่อภาวะข้อมูลปนเปื้อนหรือจุดเริ่มต้นของการพังทลายของความเชื่อถือเพราะ AI

• ถามว่าสามารถใช้ differential KV quantization (เช่น K8V4) กับโมเดลฟอร์แมต .gguf ที่แปลงไว้แล้วได้หรือไม่ และมีข้อจำกัดเรื่องชนิดของโมเดลหรือการตั้งค่า tokenizer หรือไม่

  • ตอบว่าจุดเด่นหลักของ KVSplit คือใช้กับโมเดล .gguf ที่มีอยู่แล้วได้ทันทีโดยไม่ต้องแปลงพิเศษ เพราะ quantization จะถูกใช้เฉพาะกับ KV cache ตอน runtime เท่านั้นและไม่เกี่ยวกับน้ำหนักโมเดล เพียงกำหนดรูปแบบการเก็บในหน่วยความจำผ่านแฟลก --kvq-key และ --kvq-val โดยตนทดสอบสำเร็จกับโมเดลหลายตัว เช่น LLama-3, Mistral, Phi-2/Phi-3, TinyLlama, Qwen เป็นต้น แต่ใช้ได้เฉพาะกับ backend Metal ของ llama.cpp และเนื่องจาก Flash Attention จะข้าม custom KV cache format ในตอนนี้ จึงต้องใช้ตัวเลือก -fa 0 นอกนั้นถ้าเป็นโครงสร้าง transformer ที่ใช้ attention ก็ใช้งานได้ทั้งหมด

• ถามว่าแพตช์นี้เร็วขึ้นหรือดีกว่าหรือไม่บน Apple Silicon ที่มีหน่วยความจำสูง เช่น 64GB, 128GB โดยบอกว่าเคยได้ยินว่าการขยาย context window บน Apple Silicon ช้าอยู่แล้ว และสงสัยว่ามันมีความหมายจริงหรือไม่เมื่อมีหน่วยความจำมาก

  • ตอบว่าผลประหยัดหน่วยความจำของ KVSplit แปรตามความยาว context จึงยิ่งให้ประโยชน์เชิงปริมาณมากขึ้นบน Mac ที่มีหน่วยความจำสูง ถึงขั้นจัดการ context ระดับหลายแสนโทเคนได้บน Mac Studio 128GB แต่ไม่ได้ทำให้ความเร็วการคำนวณพื้นฐานเร็วขึ้น เพียงปรับปรุงประสิทธิภาพด้านหน่วยความจำ โดย benchmark พบว่าค่าตั้ง K8V4 ให้ throughput เพิ่ม 14.5% ซึ่งเป็นผลจากประสิทธิภาพการเข้าถึงหน่วยความจำ ปัญหา “ความช้า” ของโมเดลใหญ่ส่วนมากเกิดจากข้อจำกัดด้านพลังประมวลผล ไม่เกี่ยวกับ RAM หรือการ optimize KV cache ดังนั้น KVSplit จึงมีประโยชน์ในสถานการณ์ที่ติดเพดานหน่วยความจำ และในการใช้งานจริงเหมาะกับการให้ context window ใหญ่ขึ้นแก่โมเดลขนาดเล็กอย่าง 7B~13B มากกว่า หากต้องการทั้งโมเดลใหญ่และหน้าต่างข้อความยาวมากพร้อมกัน GPU ระดับเซิร์ฟเวอร์ก็ยังเหมาะกว่า แต่สิ่งนี้ช่วยขยายขอบเขตที่ฮาร์ดแวร์ของ Apple ทำได้

• แสดงความสนใจและขอคำอธิบายในมุมมองที่สูงขึ้นอีกหน่อย ถามว่าสามารถใช้ขยายโมเดล 2048 โทเคนไปเป็น 4~6k ได้หรือไม่ หรือใช้โมเดล context 128k เป็นหน้าต่าง 256k+ ได้หรือไม่ รวมถึงถามถึงกรณีใช้งานที่เหมาะที่สุดของโมเดลโลคัล

  • ตอบว่าในคอนฟิก K8V4 สามารถประหยัดหน่วยความจำได้ 59% ทำให้เพิ่มความยาว context สูงสุดได้ถึง 2.4 เท่า กล่าวคือโมเดล 2048 โทเคนขยายได้เป็นราว 5000 โทเคน และโมเดล 8K ขยายได้เป็นประมาณ 19.5K ในทางปฏิบัติสามารถใช้ประมวลผลหนังสือทั้งเล่มบน MacBook วิเคราะห์ codebase ขนาดใหญ่ หรือเก็บประวัติการสนทนายาวในแอปโต้ตอบได้ โดยผลประหยัดหน่วยความจำเพิ่มขึ้นแบบเชิงเส้นตามความยาว context จากประสบการณ์ของผู้ตอบ KV cache ที่ context 8K ลดจาก 176MB เหลือ 72MB และเมื่อเป็น 128k ปริมาณที่ประหยัดได้จะอยู่ในระดับกิกะไบต์ จึงเป็นวิธีที่มีประสิทธิภาพมากเมื่อเกิด OOM เพราะข้อจำกัดด้านความยาวอินพุต
  • เสริมว่าการประหยัดหน่วยความจำช่วยลดทรัพยากรที่โมเดลหนึ่งต้องใช้ลง จึงนำไปประยุกต์ได้ตามจุดประสงค์ต่าง ๆ แต่การขยาย context window เองไม่ใช่เรื่องง่ายสำหรับคนที่ไม่เชี่ยวชาญ จึงควรใช้โมเดลที่ฝึกมาให้รองรับหน้าต่างใหญ่กว่าโดยตรง ส่วนโมเดลโลคัลใช้งานได้หลากหลายทั้งแบบออฟไลน์ ความปลอดภัย และการทดลอง โดยส่วนใหญ่ใช้เพื่อการทดลองปรับแต่งโมเดล

• ชื่นชมว่าเป็นไอเดียและความพยายามที่ดีมาก พร้อมถามเพิ่มเติมว่าจะใช้กับ GPU ได้หรือไม่ และจะใช้ร่วมกับเทคนิค quantization อื่นได้หรือไม่

  • ตอบว่าวิธีนี้น่าจะใช้ได้เหมือนกันกับ GPU ของ NVIDIA/AMD เพราะหลักการที่ key ต้องการความละเอียดสูงกว่า value ไม่ขึ้นกับฮาร์ดแวร์ โดย backend CUDA ของ llama.cpp ก็รองรับการตั้งค่าแยกผ่าน --cache-type-k, --cache-type-v อยู่แล้ว แพตช์ปัจจุบันอาจเจาะจงเพื่อ Metal แต่หลักการย้ายไปใช้ได้ตรง ๆ และยังใช้ร่วมกับเทคนิค quantization อื่นได้ เพราะ KV cache quantization ถูกใช้เฉพาะระหว่างรัน ไม่ชนกับ weight quantization เนื่องจากเป็นคนละขั้นของ pipeline อย่างไรก็ตาม engine อย่าง vLLM, TensorRT-LLM ที่มีโครงสร้าง cache ของตัวเองจะต้องมีการพัฒนาแยกต่างหาก และผลที่เด่นที่สุดบน GPU น่าจะเกิดเมื่อรวมเข้ากับสถาปัตยกรรม FlashAttention โดยตรง ซึ่งการประหยัดหน่วยความจำอาจแปลงเป็นความเร็วที่เพิ่มขึ้นได้

• ระบุว่ายังมีจุดที่ไม่เข้าใจและรู้สึกว่ามีบางอย่างแปลก ๆ พร้อมแนะนำว่าอย่ารันสคริปต์นี้ และแจ้งว่าได้รายงานแล้ว

• ถามว่าสมรรถนะเปลี่ยนไปอย่างไร เพราะแม้จะใส่ context ที่ยาวขึ้นในหน่วยความจำได้ สุดท้ายความเร็วคำนวณก็น่าจะเท่าเดิมไม่ใช่หรือ

  • ตอบว่าจากที่ลองกับโมเดลเดียวกันและพรอมป์ต์เดียวกัน โดยสลับชนิด cache ระหว่าง fp16, q8, q4 ก็รู้สึกว่าความเร็วต่อ iteration ใกล้เคียงกัน แม้ไม่ได้ตรวจกลไกภายในโดยตรง แต่เดิมคาดหวังว่าจะมีการ pack เวกเตอร์เพื่อประมวลผลแบบ SIMD เป็นชุดในระดับ 4~8 บิต ทว่าในความรู้สึกเหมือนจริง ๆ แล้วไม่ได้มีการ pack ดังกล่าว