สถาปัตยกรรมโมเดลขนาดใหญ่แนวโน้มใหม่: การแคช KV แบบแชร์และความสนใจแบบบีบอัดช่วยลดต้นทุนบริบทระยะยาวได้อย่างไร

ในช่วงที่ผ่านมา ผู้ใช้หลายคนที่ใช้งานโมเดลขนาดใหญ่ (Large Language Model) มักจะรู้สึกได้อย่างชัดเจนว่า Token มักจะไม่เพียงพอ

เพราะเพื่อให้โมเดล “ฉลาด” ขึ้นและต่อเนื่องมากขึ้น หน้าต่างบริบท (Context Window) ก็จะใหญ่ขึ้นเรื่อยๆ ซึ่งเป็นแนวโน้มที่หลีกเลี่ยงไม่ได้

แต่เบื้องหลังโมเดลแล้ว บริบทยาว (Long Context) นั้นค่อนข้าง “ฟุ่มเฟือย” จำนวน Token ที่ผู้ใช้ใช้เพิ่มขึ้นเป็นสองเท่า เบื้องหลังคือ KV Cache ที่ใหญ่ขึ้นและต้นทุนการคำนวณ Attention ที่สูงขึ้นของโมเดล

โดยเฉพาะอย่างยิ่งหลังจากที่ Reasoning Model และ Agent กลายเป็นกระแสหลัก บริบทยาวได้เปลี่ยนจาก “จุดเด่นในการประชาสัมพันธ์” มาเป็นปัญหาหลักที่สถาปัตยกรรมโมเดลขนาดใหญ่ต้องแก้ไขอย่างจริงจัง

Sebastian จับประเด็นได้อย่างแม่นยำว่า โมเดลภาษาขนาดใหญ่ที่เพิ่งเปิดตัวในช่วงไม่กี่เดือนที่ผ่านมา สะท้อนให้เห็นแนวโน้มนี้ได้เป็นอย่างดี

ตั้งแต่ Gemma 4 ของ Google, Laguna XS.2 ของ Poolside, ZAYA1-8B ของ Zyphra ไปจนถึง DeepSeek V4 โมเดลเหล่านี้ได้ออกแบบ “วิธีประหยัดต้นทุน” ต่างๆ ภายใน Transformer เพื่อพยายามลดต้นทุนการคำนวณและการจัดเก็บข้อมูลสำหรับการอนุมานบริบทยาว

Sebastian ได้เผยแพร่บล็อกทางเทคนิคเกี่ยวกับเรื่องนี้ ด้านล่างนี้คือลิงก์บล็อกและคำแปลฉบับเต็ม

ภาพรวมของโมเดลภาษาขนาดใหญ่ล่าสุด

• ชื่อบล็อก: การพัฒนาล่าสุดของสถาปัตยกรรม LLM: KV Sharing, mHC และ Compressed Attention
• ลิงก์บล็อก: https://magazine.sebastianraschka.com/p/recent-developments-in-llm-architectures

Gemma 4: การลดขนาด KV Cache ด้วยการ复用 KV Tensor ข้ามเลเยอร์

ย้อนกลับไปในช่วงต้นเดือนเมษายน Google ได้เปิดตัวชุดโมเดลโอเพนเวท (Open-weight) ใหม่ Gemma 4 โดยแบ่งออกเป็นสามประเภทหลักๆ:

• Gemma 4 E2B และ E4B สำหรับอุปกรณ์มือถือและอุปกรณ์ขนาดเล็กในเครื่อง (Embedded Device หรือ IoT);
• Gemma 4 26B ที่ใช้สถาปัตยกรรม Mixture of Experts (MoE) เพื่อการอนุมานในเครื่องที่มีประสิทธิภาพ;
• และ Gemma 4 31B ที่ใช้สถาปัตยกรรม Dense เพื่อคุณภาพโมเดลที่สูงขึ้นและกระบวนการหลังการฝึก (Post-training) ที่สะดวกยิ่งขึ้น (เนื่องจากโมเดล MoE มักจะฝึกและปรับแต่งหลังการฝึกได้ยากกว่า)

แผนภาพสถาปัตยกรรม Gemma 4

การเปลี่ยนแปลงสถาปัตยกรรมเล็กๆ น้อยๆ ครั้งแรกใน Gemma 4 E2B และ E4B คือการใช้กลไก “Shared KV Cache”: เลเยอร์ถัดไปจะ复用สถานะ Key-Value ที่เลเยอร์ก่อนหน้าคำนวณไว้แล้ว ซึ่งช่วยลดการใช้หน่วยความจำและต้นทุนการคำนวณในสถานการณ์บริบทยาว

วิธีการนี้ไม่ได้เริ่มต้นที่ Gemma 4 ตัวอย่างเช่น เอกสาร NeurIPS 2024 เรื่อง “Reducing Transformer Key-Value Cache Size with Cross-Layer Attention” ก็ได้เสนอแนวคิดที่คล้ายกันมาก่อน แต่ Gemma 4 เป็นครั้งแรกที่นำไปใช้ในวงกว้างกับสถาปัตยกรรมโอเพนซอร์สหลัก

ทำไม KV Cache ถึงสำคัญ?

ดังที่ผมได้กล่าวถึงอย่างต่อเนื่องในช่วงไม่กี่เดือนที่ผ่านมา หัวข้อหลักในการออกแบบสถาปัตยกรรม LLM ในปัจจุบันคือ “การลดขนาด KV Cache” และเป้าหมายพื้นฐานของการลดขนาด KV Cache คือการลดการใช้หน่วยความจำที่จำเป็นสำหรับการทำงานของโมเดล ซึ่งจะช่วยรองรับหน้าต่างบริบทที่ยาวขึ้น สิ่งนี้สำคัญอย่างยิ่งในยุคของ Reasoning Model และ Agent

ยกตัวอย่างคลาสสิก (ที่ Gemma 4 ยังคงใช้อยู่): Grouped-Query Attention (GQA) เองก็ช่วยลดขนาด KV Cache โดยให้ Query Head หลายตัวใช้ชุด Key-Value (KV) Head ร่วมกัน ดังรูปด้านล่าง

กลไก Cross-Layer KV Sharing ของ Gemma 4

ดังที่กล่าวไว้ Gemma 4 ใช้ GQA อย่างไรก็ตาม นอกเหนือจากการแชร์ KV ระหว่าง Query Head ที่แตกต่างกันใน GQA แล้ว Gemma 4 ยังแชร์ KV Projection ระหว่างเลเยอร์ Transformer ที่แตกต่างกันอีกด้วย แทนที่จะคำนวณ KV ของตัวเองในโมดูล Attention ของแต่ละเลเยอร์เหมือนวิธีดั้งเดิม

กลไกการแชร์ KV นี้เรียกอีกอย่างว่า Cross-Layer Attention โดยมีโครงสร้างดังรูปด้านล่าง

ดังที่กล่าวถึงในแผนภาพสถาปัตยกรรม Gemma 4 E2B ใช้การผสมผสานระหว่าง GQA ทั่วไปและ Sliding Window Attention ในอัตราส่วน 4:1 (ให้แม่นยำยิ่งขึ้น Gemma 4 E2B ใช้ MQA ซึ่งเป็นกรณีพิเศษของ GQA ที่มี KV Head เพียงตัวเดียว)

ภายใต้กลไก GQA (หรือ MQA) วิธีการแชร์ KV มีดังนี้: เลเยอร์ถัดไปจะไม่คำนวณ Key และ Value Projection ของตัวเองอีกต่อไป แต่จะ复用 Tensor KV ที่สร้างโดยเลเยอร์ประเภทเดียวกันที่ไม่ได้แชร์ล่าสุดโดยตรง

กล่าวอีกนัยหนึ่ง: เลเยอร์ Sliding Window Attention จะ复用 KV ของเลเยอร์ Sliding Window ก่อนหน้า และเลเยอร์ Full Attention จะ复用 KV ของเลเยอร์ Full Attention ก่อนหน้า

แน่นอนว่าแต่ละเลเยอร์ยังคงคำนวณ Query Projection ของตัวเอง ดังนั้นเลเยอร์ต่างๆ จึงยังคงสร้างรูปแบบ Attention ที่แตกต่างกันได้ แต่ KV Cache ที่มีต้นทุนสูงที่สุดและใช้หน่วยความจำมากที่สุดจะถูก复用โดยหลายเลเยอร์ ตัวอย่างเช่น:

• Gemma 4 E2B มีเลเยอร์ Transformer ทั้งหมด 35 ชั้น แต่มีเพียง 15 ชั้นแรกเท่านั้นที่คำนวณ KV Projection ของตัวเองจริงๆ ส่วน 20 ชั้นหลังจะ复用 Tensor KV ของเลเยอร์ประเภทเดียวกันก่อนหน้าโดยตรง
• ในทำนองเดียวกัน Gemma 4 E4B มีทั้งหมด 42 ชั้น โดย 24 ชั้นรับผิดชอบในการคำนวณ KV และ 18 ชั้นสุดท้ายใช้กลไกการแชร์

การออกแบบนี้ช่วยประหยัดทรัพยากรได้เท่าไหร่?

เนื่องจากประมาณครึ่งหนึ่งของ KV ถูกแชร์ระหว่างเลเยอร์ต่างๆ ดังนั้นขนาดโดยรวมของ KV Cache จึงลดลงประมาณครึ่งหนึ่งเช่นกัน สำหรับโมเดล E2B ที่เล็กที่สุด ในบริบทยาว 128K และความแม่นยำ bfloat16 สามารถประหยัดหน่วยความจำได้ประมาณ 2.7GB ในขณะที่ E4B ภายใต้เงื่อนไขเดียวกัน สามารถประหยัดได้ประมาณ 6GB

ผลการประหยัดหน่วยความจำ KV Cache จาก GQA และ Cross-Layer KV Sharing ในการกำหนดค่าที่คล้ายคลึงกันของ Gemma 4 E2B

แน่นอนว่าข้อเสียของการแชร์ KV คือ โดยพื้นฐานแล้วมันเป็น “การประมาณ” ของการคำนวณ Attention ที่สมบูรณ์ พูดให้ถูกต้องคือมันจะลดความจุ (Capacity) ของโมเดล

อย่างไรก็ตาม จากผลการทดลองในเอกสาร Cross-Layer Attention ผลกระทบนี้มีจำกัดมากในโมเดลขนาดเล็กที่ถูกทดสอบ

Gemma 4 E2B / E4B: Per-Layer Embeddings และ “Effective Parameters”

Gemma 4 เวอร์ชัน E2B และ E4B ยังแนะนำการออกแบบที่เน้นประสิทธิภาพเป็นอันดับสอง: Per-Layer Embeddings (PLE) กลไกนี้เป็นอิสระจากการแชร์ KV ที่กล่าวถึงข้างต้น

เป้าหมายของการแชร์ KV คือการลดขนาด KV Cache ในขณะที่ PLE มุ่งเน้นไปที่ประสิทธิภาพของพารามิเตอร์ (Parameter Efficiency): มันช่วยให้โมเดล Gemma 4 ขนาดเล็กสามารถพกพาข้อมูลเฉพาะ Token (Token-specific Information) ได้มากขึ้น โดยไม่ทำให้แกนหลักของ Transformer มีราคาแพงเท่ากับโมเดล Dense ที่มีพารามิเตอร์เท่ากัน

ตัวอย่างเช่น “E” ใน Gemma 4 E2B และ E4B ย่อมาจาก “Effective” (พารามิเตอร์ที่มีประสิทธิผล) โดยเฉพาะ:

• Gemma 4 E2B ระบุว่ามีพารามิเตอร์ประสิทธิผล 2.3B แต่ถ้านับพารามิเตอร์ Embedding ด้วย จำนวนพารามิเตอร์ทั้งหมดจริงๆ แล้วสูงถึง 5.1B;
• Gemma 4 E4B มีพารามิเตอร์ประสิทธิผล 4.5B แต่เมื่อรวม Embedding แล้วจะอยู่ที่ประมาณ 8B

กล่าวอีกนัยหนึ่ง ในซีรีส์โมเดล “E” เหล่านี้ แกนหลักของ Transformer ที่รับผิดชอบการคำนวณหลักจริงๆ มีขนาดการคำนวณใกล้เคียงกับตัวเลขที่น้อยกว่าด้านหน้า ในขณะที่จำนวนพารามิเตอร์ทั้งหมดด้านหลังรวมตาราง Embedding เพิ่มเติม

ตามแนวคิดแล้ว โครงสร้างของ PLE มีลักษณะดังนี้:

ส่วนที่ 2: การแชร์ KV Cache และ Compressed Attention

Gemma 4 Block แบบง่ายพร้อมเส้นทาง Residual PLE

ใน Transformer Block มาตรฐาน ลำดับการดำเนินการคือการอัปเดต Residual ของกลไก Attention และ Feed-Forward Network ก่อน จากนั้น สถานะที่ซ่อนอยู่ (Hidden State) ที่สร้างขึ้นจะทำหน้าที่เป็นสัญญาณ Gate เพื่อควบคุมเวกเตอร์ PLE ที่เฉพาะเจาะจงสำหรับเลเยอร์นั้นๆ ในตอนท้ายของ Block จะมีการเพิ่มการอัปเดต Residual PLE ที่ผ่านการ Projection เข้าไปอีกครั้ง

เวกเตอร์ PLE ถูกสร้างขึ้นล่วงหน้าภายนอก Transformer Block พูดง่ายๆ คือมันมีแหล่งอินพุตสองแหล่ง: หนึ่งคือ Token ID ที่ได้จากการค้นหา Per-Layer Embedding; สองคือ Token Embedding ทั่วไปที่ผ่าน Linear Projection ไปยังพื้นที่ PLE เดียวกัน

จากนั้น ผลลัพธ์ทั้งสองส่วนนี้จะถูกบวก ปรับขนาด และจัดรูปทรง (Reshape) เป็น Tensor ใน Tensor นี้ แต่ละเลเยอร์จะสอดคล้องกับ Slice อิสระ และ Transformer Block แต่ละตัวจะได้รับเฉพาะส่วนที่เป็นของตัวเองเท่านั้น

กระบวนการสร้าง PLE (Per-Layer Embeddings) แบบง่าย

มีรายละเอียดที่สำคัญมากที่นี่: PLE ไม่ได้คัดลอกชุด Embedding Layer ทั้งหมดแยกต่างหากสำหรับแต่ละ Transformer Block ในทางกลับกัน การค้นหา Per-Layer Embedding จะคำนวณเพียงครั้งเดียว จากนั้นจึงแจกจ่าย Embedding Slice ขนาดเล็กที่เฉพาะเจาะจงสำหรับ Token นั้นๆ ให้กับแต่ละเลเยอร์

ดังนั้น สำหรับ Token อินพุตแต่ละตัว Gemma 4 จะเตรียม Tensor PLE ที่บรรจุไว้ล่วงหน้า ซึ่งประกอบด้วยเวกเตอร์ Embedding ขนาดเล็กที่สอดคล้องกับ Decoder แต่ละชั้น

เมื่อเข้าสู่ Transformer Block จริงๆ แล้ว สาขา Attention และ Feed-Forward Network ยังคงทำงานตามปกติ หลังจากเสร็จสิ้นการอัปเดต Residual ของ Feed-Forward Network สถานะที่ซ่อนอยู่ในปัจจุบัน (แสดงเป็น z ในรูป) จะถูกใช้เพื่อ Gate เวกเตอร์ PLE ที่เฉพาะเจาะจงสำหรับเลเยอร์นั้นๆ เวกเตอร์ PLE ที่ผ่าน Gate แล้วจะถูก Projection กลับไปยังขนาด Hidden Layer ของโมเดล ทำ Normalization และเพิ่มกลับเข้าไปในโมเดลเป็นการอัปเดต Residual เพิ่มเติม

วิธีทำความเข้าใจที่เข้าใจง่ายคือ: โครงสร้างหลักของ Transformer Block ไม่ได้เปลี่ยนแปลงไป Gemma 4 เพียงแทรก “เวกเตอร์ Token เฉพาะเลเยอร์” ขนาดเล็กไว้ด้านหลังสาขา Feed-Forward Network การทำเช่นนี้สามารถเพิ่มความสามารถในการแสดงออกของโมเดลผ่านพารามิเตอร์ Embedding และ Projection ขนาดเล็ก ในขณะที่หลีกเลี่ยงการขยาย Transformer Stack ทั้งหมดให้มีขนาดพารามิเตอร์ที่ใหญ่ขึ้น

ทำไมต้องใช้ PLE?

วิธีที่ตรงไปตรงมามากกว่าคือการลดขนาดโมเดล Dense ลง เช่น ลดจำนวนเลเยอร์ ลดขนาด Hidden State หรือลดขนาด Feed-Forward Network

การทำเช่นนั้นจะช่วยลดการใช้หน่วยความจำและความหน่วงได้อย่างแน่นอน แต่ก็จะลดทอนส่วนหลักของโมเดลที่รับผิดชอบการคำนวณจริงๆ โดยตรง

แนวคิดของ PLE คือ: ให้ Transformer Block ที่มีราคาแพงอยู่ใน “ขนาดประสิทธิผล” ที่เล็ก ในขณะที่เก็บความจุเพิ่มเติมไว้ในตาราง Per-Layer Embedding เนื่องจาก Embedding โดยพื้นฐานแล้วเป็นพารามิเตอร์แบบค้นหา (Lookup-style Parameter) มันจึงถูกกว่าและแคชได้ง่ายกว่าการเพิ่มน้ำหนัก Attention หรือ Feed-Forward Network

แน่นอนว่าในตอนนี้ เราทำได้เพียงเชื่อผลการทดลองของ Google ว่านี่เป็นการออกแบบที่มีประสิทธิภาพ ผู้เขียนยังกล่าวอีกว่าในอนาคตหวังว่าจะได้เห็นการทดลองเปรียบเทียบเพิ่มเติม เช่น PLE Gemma 4 E2B เทียบกับโมเดล Dense 2.3B ทั่วไป เทียบกับโมเดล Dense 5.1B ทั่วไป

การเปรียบเทียบเช่นนี้จะน่าสนใจมาก

นอกจากนี้ ในทางทฤษฎี PLE ไม่ได้จำกัดอยู่แค่โมเดลขนาดเล็กเท่านั้น โมเดลขนาดใหญ่ก็สามารถเพิ่ม Per-Layer Embedding Slice ได้เช่นกัน แต่เนื่องจากโมเดลขนาดใหญ่มีความจุเพียงพออยู่แล้ว ผลประโยชน์จาก Embedding เพิ่มเติมเหล่านี้อาจไม่ชัดเจนอีกต่อไป และในโมเดลขนาดใหญ่ เรามักจะเพิ่มความจุของโมเดลโดยไม่เพิ่มปริมาณการคำนวณอย่างมีนัยสำคัญผ่านโครงสร้างต่างๆ เช่น Mixture of Experts (MoE)

Laguna XS.2: การจัดสรรงบประมาณ Attention แบบทีละเลเยอร์

Laguna เป็นโมเดล Open-weight ตัวแรกที่เปิดตัวโดย Poolside บริษัทในยุโรป ซึ่ง Poolside มุ่งเน้นไปที่การฝึกโมเดลภาษาขนาดใหญ่สำหรับสถานการณ์โค้ดเป็นหลัก

เลเยอร์ที่แตกต่างกันใช้งบประมาณ Attention ที่แตกต่างกัน

สถาปัตยกรรม Laguna XS.2 ในรูปด้านล่างเมื่อมองแวบแรกดูค่อนข้างมาตรฐาน อย่างไรก็ตาม มีรายละเอียดหนึ่งที่ผมไม่ได้วาดลงไป (หรือไม่สามารถยัดเยียดลงในรูปได้) ซึ่งเป็นแนวคิดที่เรียกว่า “Layer-wise Attention Budgeting”

แผนภาพสถาปัตยกรรม Laguna XS.2 ของ Poolside

แนวคิดหลักประการหนึ่งของการจัดสรรงบประมาณ Attention ที่นี่คือ การไม่ให้แต่ละ Transformer Layer มีงบประมาณ Attention ที่เท่ากันทุกประการ แต่จะจัดสรรต้นทุน Attention ที่แตกต่างกันแบบไดนามิกตามเลเยอร์

Laguna XS.2 มีทั้งหมด 40 ชั้น โดย 30 ชั้นใช้ Sliding Window Attention และ 10 ชั้นใช้ Global/Full Attention

และเช่นเดียวกับวิธีปฏิบัติทั่วไป เลเยอร์ Sliding Window จะ关注เฉพาะหน้าต่างท้องถิ่น (ที่นี่คือ 512 Token) ดังนั้น KV Cache และต้นทุนการคำนวณ Attention จึงต่ำกว่า ในขณะที่เลเยอร์ Global แม้จะมีราคาแพงกว่า แต่ก็สามารถรักษาความสามารถในการเข้าถึงข้อมูลทั้งหมดในหน้าต่างบริบททั้งหมดได้

โครงสร้างแบบผสมระหว่าง Sliding Window Attention และ Global/Full Attention นี้ไม่ได้มีเฉพาะใน Laguna XS.2 เท่านั้น โมเดลอื่นๆ อีกมากมาย (รวมถึง Gemma 4) ก็ใช้การออกแบบที่คล้ายคลึงกัน

แต่สิ่งใหม่จริงๆ คือ: Laguna XS.2 นำการออกแบบ “จำนวน Query Head ที่แตกต่างกันในแต่ละเลเยอร์” มาใช้

ตัวอย่างเช่น ในไฟล์ config.json ของ Hugging Face จะเห็นรายการการกำหนดค่าที่ชื่อว่า num_attention_heads_per_layer ซึ่งหมายความว่าเลเยอร์ต่างๆ สามารถมีจำนวน Query Head ที่แตกต่างกันได้ ในขณะที่ยังคงรักษาโครงสร้าง KV Cache ให้เข้ากันได้

การจัดสรรงบประมาณ Query Head แบบทีละเลเยอร์ใน Laguna โดยที่เลเยอร์ Global Attention มี 6 Query Head ต่อ 1 KV Head; เลเยอร์ Sliding Window Attention มี 8 Query Head ต่อ 1 KV Head

ดังนั้น วิธีปฏิบัติจริงของ Laguna XS.2 คือ: จัดสรร Query Head ให้กับเลเยอร์ Sliding Window มากขึ้น และจัดสรร Query Head ให้กับเลเยอร์ Global น้อยลง ในขณะที่กำหนดจำนวน KV Head คงที่ที่ 8

นี่คือสิ่งที่เรียกว่า “Layer-wise Head Budgeting” อย่างแท้จริง

Laguna XS.2 เป็นหนึ่งในแนวปฏิบัติการจัดสรรงบประมาณ Query Head แบบทีละเลเยอร์ที่เป็นตัวแทนมากที่สุดในบรรดาโมเดลเปิดล่าสุด อย่างไรก็ตาม แนวคิดที่กว้างขึ้นของ “การจัดสรรความจุโมเดลแบบไดนามิกตามเลเยอร์” นั้น สามารถย้อนกลับไปได้อย่างน้อยถึง OpenELM ที่ Apple เสนอในปี 2024

ทำไมถึงออกแบบเช่นนี้?

คล้ายกับการแชร์ KV Cache เป้าหมายหลักของมันคือ: ใช้ความจุ Attention ในที่ที่คุ้มค่าที่สุด แทนที่จะให้ทุกเลเยอร์ได้รับงบประมาณเท่ากันโดยเฉลี่ย

ผลลัพธ์จากการเขียนใหม่เชิงลึกและการลดการซ้ำซ้อน

ใน Full Attention Layer เนื่องจากจำเป็นต้องเข้าถึงหน้าต่างบริบททั้งหมด ต้นทุนการคำนวณจึงค่อนข้างสูงอยู่แล้ว ด้วยเหตุนี้ Laguna จึงลดจำนวน Query Head ในเลเยอร์ประเภทนี้อย่างมีกลยุทธ์ ในทางตรงกันข้าม เลเยอร์ Sliding Window ที่มีต้นทุนการคำนวณต่ำกว่าสามารถกำหนดค่า Query Head ได้มากกว่า

(นอกจากนี้ รายละเอียดการใช้งานเล็กน้อยอีกประการหนึ่งคือ Laguna ใช้กลไก Per-head Attention-output Gating ซึ่งคล้ายกับแนวทางของโมเดลเช่น Qwen3-Next เนื่องจากผู้เขียนได้กล่าวถึงกลไกที่คล้ายคลึงกันก่อนหน้านี้แล้ว จึงจะไม่กล่าวซ้ำอีก)

ZAYA1-8B: Compressed Convolutional Attention (CCA)

เช่นเดียวกับ Laguna ZAYA1-8B ก็เป็นสมาชิกใหม่เช่นกัน พัฒนาโดยบริษัท Zyphra รายละเอียดที่น่าสนใจประการหนึ่งในการเปิดตัวครั้งนี้คือ: โมเดลนี้ไม่ได้ฝึกบน GPU NVIDIA (หรือ Google TPU) ที่พบได้ทั่วไป แต่ใช้ AMD GPU ทั้งหมด

อย่างไรก็ตาม จุดเด่นที่แท้จริงของการออกแบบสถาปัตยกรรมหลักคือกลไกที่เรียกว่า Compressed Convolutional Attention (CCA) และมันถูกออกแบบให้ทำงานร่วมกับ Grouped-Query Attention (GQA)

แตกต่างจากการออกแบบเช่น MLA (Multi-head Latent Attention) ซึ่งส่วนใหญ่ใช้ Latent Representation เป็นรูปแบบ KV Cache ที่กะทัดรัด CCA จะคำนวณ Attention ใน Latent Space ที่ถูกบีบอัดโดยตรง เราจะพูดถึงรายละเอียดนี้ในภายหลัง

(พูดถึงอีกอย่าง: ไฟล์ config.json ของ ZAYA1-8B จริงๆ แล้วแสดงรายการ Layer Entry ที่สลับกัน 80 รายการ ไม่ใช่ Transformer Block 40 รายการตามธรรมเนียม Layer เหล่านี้จะสลับกันระหว่าง CCA/GQA Attention และ MoE Feed-Forward Layer ในเชิงโครงสร้าง อย่างไรก็ตาม ในแผนภาพสถาปัตยกรรม การทำความเข้าใจแบบง่ายๆ ว่าเป็นคู่ “Attention + MoE” ที่ซ้ำกัน 40 คู่นั้นเข้าใจง่ายกว่า การแสดงทั้งสองแบบนั้นเทียบเท่ากันในเชิงแนวคิด)

Transformer Block ของ ZAYA1 (8B) ที่ใช้ Compressed Convolutional Attention

ดังแสดงในรูปด้านบน ZAYA1-8B ใช้ CCA ร่วมกับโครงสร้าง GQA แบบ 4:1 จุดสำคัญที่สุดตรงนี้คือ: Attention Block ของมันถูกสร้างขึ้นรอบๆ CCA ไม่ใช่ Sliding Window Attention แบบดั้งเดิม

Compressed Convolutional Attention (CCA) คืออะไร?

ผู้เขียนคิดว่า จากมุมมองโดยรวมแล้ว CCA มีความคล้ายคลึงกับ MLA (Multi-head Latent Attention) ในโมเดล DeepSeek เนื่องจากทั้งคู่แนะนำ Latent Representation ที่ถูกบีบอัดภายใน Attention Block อย่างไรก็ตาม ทั้งสองใช้ Latent Space ในวิธีที่แตกต่างกันอย่างสิ้นเชิง

เป้าหมายหลักของ MLA คือการบีบอัด KV Cache ผ่าน Latent Representation เป็นหลัก ใน MLA Tensor KV จะถูกจัดเก็บในรูปแบบที่บีบอัด จากนั้นจึงถูก Projection กลับไปยังพื้นที่ Attention Head เพื่อใช้ในการคำนวณ Attention จริง

การเปรียบเทียบระหว่าง Multi-head Attention (MHA) ทั่วไปกับ Multi-head Latent Attention (MLA)

ในขณะที่ CCA ก้าวไปอีกขั้น มันไม่เพียงบีบอัด K และ V แต่ยังบีบอัด Q พร้อมกัน และดำเนินการคำนวณ Attention ใน Latent Space ที่ถูกบีบอัดโดยตรง ด้วยเหตุนี้ CCA จึงไม่เพียงลดขนาด KV Cache แต่ยังลด Attention FLOPs ในช่วง Prefill และ Training อีกด้วย

การเปรียบเทียบโครงสร้างระหว่าง MLA และ CCA

ดังแสดงในรูปด้านบน ใน CCA Latent Representation ที่ถูกบีบอัดจะเข้าสู่กลไก Attention โดยตรง จากนั้น Compressed Attention Vector ที่สร้างขึ้นจะถูก Up-project กลับไปยังพื้นที่เดิม

ทำไมถึงเรียกว่า “Convolutional Attention”?

ต้องสังเกตเป็นพิเศษว่า: มันถูกเรียกว่า “Compressed Convolutional Attention” ไม่ใช่แค่ “Compressed Attention” เพราะมีการเพิ่ม Convolutional Mixing เข้าไปใน Latent K และ Latent Q

เนื่องจากพื้นที่ในแผนภาพโครงสร้างมีจำกัด จึงไม่ได้วาดส่วนนี้ไว้ แต่มันก็ไม่ได้ซับซ้อนอะไร ดังที่ Figure 12 บอกเป็นนัย Convolutional Mixing ทำงานโดยตรงกับ Tensor Q และ K ที่ถูกบีบอัด

สาเหตุก็คือ การบีบอัดจะทำให้มิติของ Q, K, V แคบลง ซึ่งช่วยลดปริมาณการคำนวณและค่าใช้จ่ายของ Cache แต่ในขณะเดียวกันก็อาจลดทอนความสามารถในการแสดงออกของ Attention

ในขณะที่ Convolution เป็นวิธีการที่ค่อนข้างถูก ซึ่งสามารถเสริมข้อมูลบริบทท้องถิ่นให้กับ Representation ที่ถูกบีบอัดเหล่านี้ ก่อนที่ Q และ K จะถูกใช้ในการคำนวณ Attention Score

(Convolution ที่นี่ใช้กับ Q และ K เท่านั้น ไม่ใช้กับ V เพราะ Q และ K เป็นตัวกำหนด Attention Score ในขณะที่ V แทนเนื้อหาที่จะถูก加权聚合ในที่สุด)

แผนภาพแนวคิดของ Sequence-Mixing Convolution

นอกเหนือจาก Sequence Mixing ที่แสดงในข้อความก่อนหน้านี้ CCA ยังมี Channel Mixing Component อีกด้วย อย่างไรก็ตาม หลักการของมันค่อนข้างคล้ายคลึงกัน จึงไม่ขยายความแยกต่างหากที่นี่

CCA ดูเหมือนจะเป็นกลไก Attention ที่ Zyphra เสนอขึ้นก่อนที่จะเผยแพร่ ZAYA1-8B Technical Report เอกสารอิสระเรื่อง “Compressed Convolutional Attention: Efficient Attention in a Compressed Latent Space” ตีพิมพ์ครั้งแรกในเดือนตุลาคม 2025 และเสนอ CCA อย่างเป็นทางการ; ในขณะที่ ZAYA1-8B นำกลไกนี้ไปใช้เป็นส่วนประกอบสถาปัตยกรรมหลักอย่างหนึ่ง

CCA ดีกว่า MLA จริงหรือ?

จากผลการทดลองในเอกสาร CCA ภายใต้การตั้งค่าการบีบอัดเดียวกัน CCA มีประสิทธิภาพดีกว่า MLA จริง

ภาพผลการทดลองจากเอกสาร CCA

โดยรวมแล้ว สิ่งที่น่าสนใจจริงๆ ในส่วนนี้คือกลไก Attention ใหม่นั่นเอง

แน่นอนว่า ZAYA1-8B ยังใช้โครงสร้าง MoE ที่ค่อนข้างรุนแรง (หรือก็คือเบาบางมาก) โดยแต่ละ Token จะ激活 Expert แบบ Routed เพียงตัวเดียว อย่างไรก็ตาม ประเด็นนี้ค่อนข้างเป็นที่รู้จักอยู่แล้ว

สิ่งที่พิเศษกว่าคือ CCA ซึ่งดำเนินการคำนวณ Attention ใน Latent Space ที่ถูกบีบอัดโดยตรง และใช้ Convolutional Mixing กับ Q/K ที่ถูกบีบอัดเพื่อบรรเทาปัญหาความสามารถในการแสดงออกที่จำกัดของ Compressed Attention

พูดง่ายๆ คือ ZAYA1-8B ไม่เพียงต้องการประหยัดปริมาณการคำนวณใน Feed-Forward Layer แต่ยังพยายามลดต้นทุนการคำนวณจากกลไก Attention เองอีกด้วย

DeepSeek V4: mHC และ Compressed Attention

DeepSeek V4 เป็นหนึ่งในโมเดลขนาดใหญ่ที่ได้รับความสนใจมากที่สุดในปีนี้ ที่น่าสนใจคือ หากวัดจากสัดส่วน Active Parameter แล้ว DeepSeek V4-Pro ยังเป็นโมเดล MoE ที่เบาบางที่สุดในแง่พารามิเตอร์อีกด้วย

เกี่ยวกับ DeepSeek V4 จริงๆ แล้วมีหลายสิ่งที่สามารถพูดคุยได้ อย่างไรก็ตาม เนื่องจากมันถูกพูดถึงอย่างกว้างขวางในข่าวและชุมชนแล้ว และเพื่อมุ่งเน้นไปที่ “การเปลี่ยนแปลงในระดับสถาปัตยกรรม” ต่อไป ผู้เขียนจึงขอเน้นไปที่สองส่วนที่ใหม่จริงๆ เมื่อเทียบกับสถาปัตยกรรมก่อนหน้านี้:

• mHC สำหรับขยาย Residual Path;
• CSA/HCA สำหรับการบีบอัดและการทำ稀疏 Attention สำหรับบริบทยาว

ภาพรวมสถาปัตยกรรม DeepSeek V4-Pro

5.1 mHC: Manifold-Constrained Hyper-Connections

เรามาวิเคราะห์ส่วนประกอบ mHC ใน DeepSeek V4 กันก่อน

การออกแบบนี้มีที่มาจากเอกสารวิจัยที่ทีม DeepSeek เผยแพร่เมื่อปีที่แล้ว (31 ธันวาคม 2025) ชื่อ “mHC: Manifold-Constrained Hyper-Connections” อย่างไรก็ตาม การทดลองในเอกสารในขณะนั้นทำบนโมเดลทดลองขนาด 27B เท่านั้น ปัจจุบันเราได้เห็นกลไกนี้ในโมเดลเรือธงของพวกเขาแล้ว ซึ่งแสดงให้เห็นอย่างเต็มที่ว่าแนวคิดนี้อาจได้รับการพิสูจน์แล้วในสภาพแวดล้อมการผลิตจริง

เป้าหมายหลักของ mHC คือการออกแบบ Residual Connection ภายใน Transformer Block ใหม่ ประเด็นนี้ค่อนข้างใหม่มาก เพราะการเปลี่ยนแปลงสถาปัตยกรรมส่วนใหญ่ในไม่กี่ปีที่ผ่านมา มักจะเน้นไปที่กลไก Attention, ตำแหน่งของ Normalization Layer และโครงสร้าง MoE เอง

mHC สร้างขึ้นจากงาน Hyper-Connections ก่อนหน้านี้ (ดูเอกสารปี 2024 ของ Zhu et al. เรื่อง “Hyper-connections”) ดังนั้นเราจึงต้องทำความเข้าใจ Hyper-Connections ก่อน

ใน Transformer ดั้งเดิม มี Residual Stream เพียงเส้นเดียว Hyper-Connections จะแทนที่ด้วย: Residual Stream แบบขนานหลายเส้น และแลกเปลี่ยนข้อมูลระหว่างกันผ่าน Learned Mappings

แนวคิดหลักของ Hyper-Connections คือ “การขยาย Residual Stream”

สามารถเข้าใจได้ว่าโมเดลรักษา Residual Path แบบขนานหลายเส้นพร้อมกัน และเพิ่ม Linear Transformation ของ Res Mapping เพื่อผสมข้อมูลระหว่าง Residual Stream ที่แตกต่างกัน

เนื่องจาก Attention Layer หรือ MoE Layer ยังคงทำงานบน Hidden Size ปกติ Hyper-Connections จึงเพิ่ม:

• Pre Mapping: รวม Residual Stream หลายเส้นเข้าเป็น Hidden Vector เดียว;
• Post Mapping: แจกจ่ายเอาต์พุตของ Layer กลับไปยัง Residual Stream หลายเส้น

Transformer Block ทั่วไป (บน) เทียบกับ Transformer Block ที่มี Hyper-Connections (ล่าง)

รูปด้านบนแสดงโครงสร้างใน Attention Branch เป็นหลัก แต่แนวคิดเดียวกันนี้ใช้กับ Residual Branch ที่สองที่อยู่รอบ MoE Layer

จุดประสงค์ของ Hyper-Connections คือการทำให้ Residual Path มีความสามารถในการแสดงออกที่แข็งแกร่งขึ้น โดยไม่ต้องขยายความกว้างของ Attention หรือ MoE Layer จริงๆ

และการเพิ่มขึ้นของ FLOPs ที่เกิดขึ้นนั้นมีจำกัดมาก เนื่องจากการ Mapping เพิ่มเติมเหล่านี้ทำงานเฉพาะบนมิติ Residual-stream ที่เล็กกว่า (เช่น n=4 ใน DeepSeek V4) ไม่ใช่บน Hidden Dimension ที่ใหญ่โต

ในเอกสาร Hyper-Connections ฉบับแรก FLOPs ต่อ Token ของโมเดล 7B OLMo MoE เพิ่มขึ้นจาก 13.36G เป็น 13.38G แทบไม่เปลี่ยนแปลง; ในขณะที่ตัวชี้วัดประสิทธิภาพได้รับการปรับปรุงอย่างคงที่แต่พอประมาณ

แน่นอนว่าการดูแค่ FLOPs อาจง่ายเกินไป เพราะ Residual State ที่กว้างขึ้นยังคงต้องถูกจัดเก็บ เคลื่อนย้ายในหน่วยความจำ และเข้าร่วมในการคำนวณแบบผสม ดังนั้น ค่าใช้จ่ายเพิ่มเติมที่แท้จริงอาจมาจาก Memory Traffic และ Implementation Complexity มาก

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK