Hunyuan A13B MoE: พารามิเตอร์รวม 80B ผู้เชี่ยวชาญ 64 คน และการตัดสินใจด้านการ deploy
Hunyuan A13B MoE: พารามิเตอร์รวม 80B ผู้เชี่ยวชาญ 64 คน และการตัดสินใจด้านการ deploy
Hunyuan-A13B เป็นโมเดล MoE ตัวแรกและตัวเดียวในครอบครัว Hunyuan ที่เปิดน้ำหนัก: config ทางการระบุพารามิเตอร์รวม 80.39 พันล้าน ผู้เชี่ยวชาญ 64 คน และ 32 ชั้น โดยตัวอักษร A ในชื่อหมายถึง ปริมาณพารามิเตอร์ที่ถูกกระตุ้นในแต่ละ token โครงสร้างนี้ทำให้สองสิ่งที่ดูขัดกันเป็นจริงในเวลาเดียวกัน: ค่าการคำนวณอยู่ใกล้เคียงโมเดล dense ระดับกลาง แต่น้ำหนักรวมอยู่ในระดับ 80 พันล้าน ซึ่ง ต้องโหลดทั้งหมดเข้าหน่วยความจำ บทความนี้อธิบายโครงสร้าง บัญชีหน่วยความจำ การใช้งานที่แท้จริงของ GGUF อย่างเป็นทางการ และการแบ่งงานกับ hy4
สรุปใน 30 วินาที
A13B เป็น โมเดลระดับเซิร์ฟเวอร์ ไม่ใช่โมเดลระดับเวิร์กสเตชัน: ไฟล์ GGUF ทางการรุ่น Q4_K_M มีขนาด 48.8GB และ Q4_0 คือ 45.4GB ดังนั้นการ์ดจอผู้บริโภคใบเดียวจึงใส่ไม่ไหว ต้องใช้การ์ดหลายใบ, CPU offload หรือเครื่องที่มีหน่วยความจำมาก hy4 ต่างหากที่เป็นโมเดลที่รันบนเครื่องเดียวได้ ถ้าอยากรัน Hunyuan ในเครื่อง จุดเริ่มต้นควรเป็น hy4 ไม่ใช่ A13B
ทำความเข้าใจชื่อและโครงสร้างให้ชัดก่อน
| รายการ | ค่า (จาก config ทางการ) |
|---|---|
| สถาปัตยกรรม | HunYuanMoEV1ForCausalLM |
| พารามิเตอร์รวม | 80,393,183,232 (ประมาณ 80.39 พันล้าน) |
| จำนวนผู้เชี่ยวชาญ | 64 |
| จำนวนชั้น | 32 |
| ขนาดเงา | 4096 |
| หัวความสนใจ / หัว KV | 32 / 8 (ความสนใจแบบกลุ่ม) |
| ขนาดระหว่าง | 3072 |
| ความยาวตำแหน่งสูงสุด | 32768 |
| ขนาดคำศัพท์ | 128,167 |
A ใน A13B ย่อมาจาก Active
Hunyuan ใช้กฎการตั้งชื่อที่ว่าตัวเลขข้างหน้าคือปริมาณพารามิเตอร์ที่ ถูกเรียกใช้ในแต่ละ token (13B) ส่วนพารามิเตอร์รวมไม่ได้อยู่ในชื่อ พารามิเตอร์รวมจริงของ A13B คือ 80.39 พันล้าน ความต่างนี้คือจุดเริ่มต้นของการตัดสินใจด้านการ deploy ทุกครั้ง — ค่าคอมพิวต์คิดจาก 13B แต่การจัดเก็บคิดจาก 80B
กลไกของ MoE: MLP ของแต่ละชั้นถูกแบ่งเป็นผู้เชี่ยวชาญหลายคน และตัวกำหนดเส้นทางจะเลือกผู้เชี่ยวชาญบางส่วนให้ทำงานสำหรับแต่ละ token โดยส่วนที่เหลือไม่เข้าร่วม ผลคือ:
- ค่าการคำนวณใกล้เคียงโมเดล dense ขนาด 13B เพราะแต่ละ token ใช้งานผู้เชี่ยวชาญเพียงไม่กี่คน
- การจัดเก็บน้ำหนักยังอยู่ที่ระดับ 80B เพราะผู้เชี่ยวชาญทุกคนยังต้องถูกโหลด
- การประมวลผลเป็นชุดช่วยลดต้นทุนได้ เพราะในหนึ่งครั้งของ forward แต่ละ token จะกระตุ้นผู้เชี่ยวชาญคนละกลุ่ม ทำให้หน่วยคำนวณของ GPU ถูกใช้งานเต็มขึ้น
MoE ประหยัดการคำนวณ ไม่ใช่หน่วยความจำ
นี่คือการตัดสินที่ผิดบ่อยที่สุด หลายคนเห็นว่า "13B ที่ถูกกระตุ้น" แล้วคิดว่ามันพอดีกับหน่วยความจำของโมเดล 13B ในความเป็นจริงคุณต้องจ่ายค่าน้ำหนัก 80B ไม่ว่าจะเป็น: แม้ในรูป 4-bit ก็ยังอยู่ในระดับ 40GB และไฟล์ GGUF ทางการรุ่น Q4_K_M ที่วัดบนดิสก์ได้ค่าเป็น 48.8GB เมื่อหน่วยความจำไม่พอ เอนจินจะย้ายชั้นบางส่วนลงสู่หน่วยความจำของระบบ และความเร็วจะลดลงไปตัวคูณ — ซึ่งไม่ใช่ "ช้าลงหน่อยเดียว" แต่เป็น "ใช้งานไม่ได้เชิงคุณภาพ"
บัญชีหน่วยความจำ: ต้องคิดทั้งสามชั้น
ชั้นที่หนึ่ง: น้ำหนัก
| รูปแบบน้ำหนัก | ขนาด (วัดจาก GGUF ทางการ) |
|---|---|
| BF16 ดั้งเดิม | ประมาณ 161GB |
| คลัง FP8 ทางการ | ประมาณ 80GB |
| คลัง GPTQ-Int4 ทางการ | ประมาณ 20GB |
| GGUF Q4_0 | 45.4GB |
| GGUF Q4_K_M | 48.8GB |
| GGUF Q8_0 (สองชิ้น) | 47.5GB + 38.0GB ≈ 85.5GB |
ทำไม GGUF ทางการควรดาวน์โหลดแยกต่างหาก
สำหรับโมเดลขนาด 80B คุณค่าของ GGUF อย่างเป็นทางการอยู่ที่ ความเป็นไปได้ของการแบ่งชิ้นและ CPU offload: Q8_0 แบ่งเป็นสองชิ้นที่โหลดทีละชิ้นได้ และ Q4_K_M มีความสูญเสียที่สมดุลกว่า Q4_0 ในขณะที่การแปลงจากชุมชนมักให้ไฟล์ขนาดใหญ่ไฟล์เดียว ซึ่งการแบ่งชิ้นและการจัดการเมตาดาท้าไม่ค่อยเป็นมิตร และการ offload จึงยากขึ้นตอนที่คุณต้องการจริงๆ นี่คือตัวอย่างที่หาได้น้อยของการเปิดน้ำหนักจากจีนที่เผยแพร่ GGUF อย่างเป็นทางการในฐานะของเทียบเท่า
ชั้นที่สอง: KV cache
KV cache ≈ 2 × 32 ชั้น × 8 KV head × 128 head dim × ความยาวบริบท × 2 ไบต์
≈ 128KB × ความยาวบริบท
หน้าต่าง 32K ที่เต็มรูปแบบใช้ประมาณ 4GB และบริบท 8K ใช้ประมาณ 1GB สำหรับ A13B ส่วนนี้ไม่ใช่ประเด็นหลัก (น้ำหนักต่างหากที่เป็น) แต่จะถูกขยายเมื่อมีการทำงานพร้อมกัน: จำนวนคูณของความยาวบริบทคือสิ่งที่กำหนดหน่วยความจำ KV cache ทั้งหมด
ชั้นที่สาม: ค่าใช้จ่ายระหว่างรัน
บริบทของ CUDA, บัฟเฟอร์การสื่อสารของการ์ดหลายใบ และเทนเซอร์ระหว่างของ expert parallel ในกรณีที่มีการ์ดหลายใบ รายการนี้จะโตเห็นได้ชัด
ความเป็นจริงด้านฮาร์ดแวร์: สามรูปแบบที่ใช้ได้จริง
| รูปแบบ | การตั้งค่า | หมายเหตุ |
|---|---|---|
| เซิร์ฟเวอร์หลายการ์ด | 2×48GB หรือ 4×24GB, tensor parallelism ใน vLLM | วิธีที่เป็นทางการที่สุด และน้ำหนัก FP8 ทางการเข้ากันได้ที่สุด |
| การ์ดเดียวกับ CPU offload | 1×24GB พร้อมแรมขนาดใหญ่, llama.cpp ย้ายชั้น | รันได้แต่แลกความเร็วมาเป็นประสบการณ์ เหมาะกับการตรวจสอบเท่านั้น |
| บริการคลาวด์ | ใช้บริการที่มี A13B อยู่แล้ว | ไม่ต้องเสียการ์ด และไม่ต้องมานั่งจัดการ expert parallel |
คำแนะนำด้านวิศวกรรม
หากเป้าหมายคือ "มี Hunyuan ที่รันบนเครื่องตัวเอง" ให้เริ่มจาก hy4 ไม่ใช่ A13B แต่ถ้าเป้าหมายคือ "วัดเพดานความสามารถของ A13B" ให้ใช้การ์ดหลายใบหรือบริการคลาวด์ และมอง A13B เป็น ตัวสร้างมาตรอ้างอิง: สร้างชุดประเมินผล สร้างคำตอบอ้างอิง และวัดระยะห่างที่โมเดลขนาดเล็กยังขาด อย่าพยายามบีบมันลงในการ์ดของเวิร์กสเตชันเครื่องเดียว
ประเด็นที่ต้องทราบเมื่อ deploy
เวอร์ชันของ engine: สถาปัตยกรรม MoE ต้องการ llama.cpp หรือ vLLM ที่รองรับโครงสร้างผู้เชี่ยวชาญของ Hunyuan และควรอัปเกรด engine ก่อนถ้าโหลดไม่ได้
กลยุทธ์การขนาน: ใช้ tensor parallelism ใน vLLM เพื่อแบ่งน้ำหนัก expert parallelism แทบไม่คุ้มบนฮาร์ดแวร์ระดับบริโภค
การเลือก quantization:
| สถานการณ์ของคุณ | ทางเลือก |
|---|---|
| เซิร์ฟเวอร์หลายการ์ด ต้องการสมดุลระหว่างความเร็วและคุณภาพ | FP8 ทางการ |
| หน่วยความจำจำกัดแต่ต้องรักษาคุณภาพ | GPTQ-Int4 ทางการ |
| CPU offload หรือระบนิเวศ llama.cpp | GGUF ทางการ Q4_K_M |
| สร้างเกณฑ์มาตรฐานความแม่นยำ | GGUF ทางการ Q8_0 (โปรดทราบว่าเป็นสองชิ้น) |
การประมวลผลเป็นชุด: ประโยชน์จริงของ MoE คือผลผลิตที่เกิดขึ้นพร้อมกัน การส่งคำขอเป็นชุดจะเติม GPU ให้เต็มกว่าการเรียกครั้งเดียวต่อครั้ง และนี่คือเหตุผลที่มันเหมาะกับบทบาทเซิร์ฟเวอร์มากกว่าเวิร์กสเตชัน
การแบ่งงานกับ hy4
| มิติ | A13B | hy4 |
|---|---|---|
| โครงสร้าง | MoE พารามิเตอร์รวม 80.39 พันล้าน ผู้เชี่ยวชาญ 64 คน | Dense พารามิเตอร์ 4.22 พันล้าน |
| ขนาดน้ำหนักในรูป 4-bit | 48.8GB | 2.61GB |
| ความยาวตำแหน่งสูงสุดดั้งเดิม | 32768 | 262144 |
| KV cache ต่อ token | ประมาณ 128KB | ประมาณ 144KB |
| ขั้นต่ำด้านฮาร์ดแวร์ | เซิร์ฟเวอร์หลายการ์ด | การ์ดใบเดียว หรือแม้แต่ CPU |
| บทบาท | เพดานความสามารถ การสร้างมาตรอ้างอิง และงานที่ซับซ้อน | เวิร์กสเตชัน อุปกรณ์ปลายทาง และงานเบาที่มีปริมาณสูง |
ชุดที่ทำงานร่วมกันได้จริง
ใช้ A13B แบบออฟไลน์เพื่อสร้างชุดคำถามและคำตอบคุณภาพสูงพร้อมสรุปอ้างอิง จากนั้นให้ hy4 จัดการการจัดประเภท การเขียนใหม่ และการกำหนดเส้นทางบนเส้นทางการผลิต สองโมเดลนี้ไม่ขัดกัน: โมเดลใหญ่กำหนดมาตรฐาน โมเดลเล็กรับภาระงาน
FAQ
A13B มีพารามิเตอร์กี่ตัว?
A13B ใส่ในการ์ดผู้บริโภคได้ไหม?
Hunyuan มี GGUF อย่างเป็นทางการไหม?
โมเดล MoE เร็วกว่าโมเดล dense ที่มีพารามิเตอร์เท่ากันหรือไม่?
บริบทของ A13B สั้นกว่า hy4 หรือไม่?
เรียก Hunyuan ผ่าน API ได้ไหม?
อ่านต่อ
- หน้าโมเดล hy4 — สเปก เมทริกซ์ quantization และการคำนวณหน่วยความจำ
- คำอธิบายช่องทาง hy4-preview — ช่องทางบริบท 1M
- ภาพรวมครอบครัว Tencent Hunyuan — ทุกผลิตภัณฑ์ของ Hunyuan ในที่เดียว
- Hunyuan hy4 และ A13B สำหรับ local deployment — รายละเอียดการ deploy สองเส้นหลัก
- hy4 GGUF local deployment — เส้นทางเต็มสำหรับโมเดลที่รันบนเครื่องเดียวได้
- คู่มือเลือกโมเดล hy4 — ขนาดต่าง ๆ และการแบ่งงานกับ A13B
- คู่มือการคำนวณหน่วยความจำ VRAM — การคำนวณหน่วยความจำทั่วไป
- Qwen เทียบ Hunyuan — การเปรียบเทียบระบนิเวศและรูปแบบ quantization
แหล่งข้อมูล
โครงสร้างและขนาดไฟล์เป็นไปตาม config และรายการไฟล์ในคลังทางการ เก็บข้อมูลเมื่อเดือนพฤศจิกายน 2026; และตัวเลขความเร็วควรได้มาจากการวัดบนฮาร์ดแวร์ของคุณเอง