Hunyuan A13B MoE: 80B parameter total, 64 ahli dan pertimbangan penerapan
Hunyuan A13B MoE: 80B parameter total, 64 ahli dan pertimbangan penerapan
Hunyuan-A13B adalah model MoE pertama dan satu-satunya dalam keluarga Hunyuan yang membuka berat total: konfigurasi rasmi menyebut 80,39 bilion parameter total, 64 ahli, 32 lapisan, dan huruf A pada nama merujuk kepada kiraan parameter yang diaktifkan pada setiap token. Struktur ini membuat dua hal yang tampak bertentangan menjadi benar sekaligus: biaya komputasi mendekati model dense kelas menengah, tetapi total bobot berada di kelas 80 bilion — tetap harus dimuat seluruhnya ke memori. Artikel ini menjelaskan struktur, buku memori, kegunaan sebenar GGUF rasmi, dan pembahagian kerja dengan hy4.
Ringkasan 30 detik
A13B adalah model kelas server, bukan model kelas stasiun kerja: file GGUF rasmi Q4_K_M berukuran 48,8GB dan Q4_0 sebesar 45,4GB, sehingga kartu konsumsi tunggal tidak menampungnya. Ia membutuhkan banyak kartu, CPU offload, atau mesin dengan memori besar. hy4 barulah model yang berjalan di satu mesin. Jika Anda ingin menjalankan Hunyuan secara lokal, titik awal seharusnya adalah hy4, bukan A13B.
Perjelas nama dan struktur terlebih dahulu
| Butir | Nilai (dari konfigurasi rasmi) |
|---|---|
| Arsitektur | HunYuanMoEV1ForCausalLM |
| Parameter total | 80,393,183,232 (sekitar 80,39 bilion) |
| Jumlah ahli | 64 |
| Jumlah lapisan | 32 |
| Ukuran tersembunyi | 4096 |
| Kepala attention / KV | 32 / 8 (perhatian berkelompok) |
| Ukuran perantara | 3072 |
| Panjang posisi maksimum | 32768 |
| Ukuran kosakata | 128.167 |
A pada A13B berarti Active
Hunyuan memakai konvensi penamaan di mana angka di depan adalah perkiraan parameter yang diaktifkan pada setiap token (13B), sementara jumlah parameter total tidak ditulis pada nama. Total parameter sebenarnya dari A13B adalah 80,39 bilion. Perbedaan ini adalah titik awal dari setiap keputusan penerapan — biaya komputasi dihitung dari 13B, tetapi penyimpanan dihitung dari 80B.
Mekanisme MoE: MLP pada setiap lapisan dibagi menjadi beberapa ahli, dan router memilih sejumlah kecil ahli untuk setiap token sementara sisanya tidak ikut serta. Akibatnya:
- Biaya komputasi mendekati model dense 13B karena setiap token hanya melewati beberapa ahli
- Penyimpanan bobot tetap pada level 80B karena semua ahli tetap harus dimuat
- Pemrosesan batch dapat menurunkan biaya karena dalam satu kali forward, token yang berbeda mengaktifkan ahli yang berbeda, sehingga unit komputasi GPU terisi lebih penuh
MoE menghemat komputasi, bukan memori
Ini adalah penilaian keliru yang paling umum. Banyak orang melihat "13B aktif" lalu menganggap ia muat dalam memori model 13B. Pada kenyataannya Anda tetap membayar bobot 80B: meski dalam 4-bit pun sekitar 40GB, dan file GGUF rasmi Q4_K_M terukur 48,8GB pada disk. Ketika memori tidak cukup, engine akan memindahkan sebagian lapisan ke memori sistem dan kecepatan turun satu orde — itu bukan "sedikit lebih lambat", melainkan "hampir tidak bisa dipakai".
Buku memori: ketiga lapisan harus dihitung
Lapisan pertama: bobot
| Bentuk bobot | Ukuran (diukur dari GGUF rasmi) |
|---|---|
| BF16 asli | sekitar 161GB |
| Repositori FP8 rasmi | sekitar 80GB |
| Repositori GPTQ-Int4 rasmi | sekitar 20GB |
| GGUF Q4_0 | 45,4GB |
| GGUF Q4_K_M | 48,8GB |
| GGUF Q8_0 (dua bagian) | 47,5GB + 38,0GB ≈ 85,5GB |
Mengapa GGUF rasmi layak diunduh terpisah
Untuk model 80B, nilai GGUF rasmi terletak pada kemungkinan fragmentasi dan CPU offload: Q8_0 terbagi dua bagian sehingga bisa dimuat bertahap, dan Q4_K_M memberi kerugian kualitas yang lebih seimbang dibanding Q4_0. Konversi komunitas biasanya hanya menghasilkan satu file besar dengan fragmentasi dan penanganan metadata yang kurang ramah, sehingga offload semakin sulit justru saat dibutuhkan. Ini contoh langka dari model Tiongkok yang menerbitkan GGUF rasmi sebagai artefak setara.
Lapisan kedua: KV cache
KV cache ≈ 2 × 32 lapisan × 8 KV head × 128 head dim × panjang konteks × 2 byte
≈ 128KB × panjang konteks
Jendela penuh 32K sekitar 4GB, dan konteks 8K sekitar 1GB. Bagian ini bagi A13B bukan kontradiksi utama (bobot yang justru begitu), tetapi akan membesar saat dipakai bersamaan: jumlah permintaan dikali panjang konteks menentukan total jejak KV cache.
Lapisan ketiga: biaya runtime
Konteks CUDA, buffer komunikasi banyak kartu, dan tensor perantara dari expert parallel; pada skenario banyak kartu, butir ini membengkak nyata.
Realitas perangkat keras: tiga bentuk yang layak
| Bentuk | Konfigurasi | Catatan |
|---|---|---|
| Server banyak kartu | 2×48GB atau 4×24GB, tensor parallel di vLLM | cara paling ortodoks, dan bobot FP8 rasmi paling sesuai |
| Satu kartu dengan CPU offload | 1×24GB dan RAM besar, pemindahan lapisan via llama.cpp | bisa berjalan tetapi menukar kecepatan dengan pengalaman, cocok untuk verifikasi |
| Layanan cloud | memakai layanan yang sudah menyediakan A13B | tidak memakai kartu sendiri dan tidak perlu mengurus expert parallel |
Saran teknis
Jika tujuannya adalah "memiliki Hunyuan yang berjalan di mesin sendiri", mulailah dari hy4, bukan A13B. Jika tujuannya adalah "mengukur batas kemampuan A13B", gunakan banyak kartu atau layanan cloud dan perlakukan A13B sebagai generator acuan: menghasilkan set evaluasi, menghasilkan jawaban rujukan, dan mengukur jarak yang masih kurang pada model yang lebih kecil. Jangan memaksakan ke kartu stasiun kerja.
Hal yang perlu diperhatikan saat menerapkan
Versi engine: arsitektur MoE membutuhkan llama.cpp atau vLLM yang mendukung struktur ahli Hunyuan; perbarui engine lebih dulu jika gagal dimuat.
Strategi paralelisme: gunakan tensor parallel di vLLM untuk membagi bobot. Expert parallel jarang sepadan pada perangkat keras konsumsi.
Memilih quantization:
| Situasi Anda | Pilihan |
|---|---|
| Server banyak kartu, menyeimbangkan kecepatan dan kualitas | FP8 rasmi |
| Memori terbatas tetapi kualitas harus dijaga | GPTQ-Int4 rasmi |
| CPU offload atau ekosistem llama.cpp | GGUF rasmi Q4_K_M |
| Membuat garis dasar akurasi | GGUF rasmi Q8_0 (perhatikan dua bagian) |
Pemrosesan batch: satu manfaat nyata MoE adalah throughput konkurensi. Permintaan dalam batch mengisi GPU lebih penuh daripada panggilan tunggal berurutan, dan itulah alasan ia cocok untuk peran server daripada stasiun kerja.
Pembahagian kerja dengan hy4
| Dimensi | A13B | hy4 |
|---|---|---|
| Struktur | MoE, 80,39 bilion parameter total melalui 64 ahli | Dense, 4,22 bilion parameter |
| Ukuran bobot pada 4-bit | 48,8GB | 2,61GB |
| Panjang posisi maksimum asli | 32768 | 262144 |
| KV cache per token | sekitar 128KB | sekitar 144KB |
| Lantai perangkat keras | server banyak kartu | satu kartu, bahkan CPU |
| Peran | batas kemampuan, pembangkit acuan, tugas kompleks | stasiun kerja, perangkat tepi, tugas ringan bervolume tinggi |
Pasangan yang bekerja bersama
Gunakan A13B secara offline untuk menghasilkan sekumpulan pertanyaan dan jawaban berkualitas tinggi beserta ringkasan rujukan, lalu biarkan hy4 menangani klasifikasi, menulis ulang, dan routing pada jalur produksi. Kedua model tidak bertentangan: model besar menentukan standar, model kecil memikul lalu lintas.
Catatan tambahan sebelum dipakai sungguhan
Tiga hal yang mudah dilupakan saat berpindah dari percobaan ke pemakaian harian:
- Rekod versi file GGUF. Komunitas akan menerbitkan perbaikan konversi; mencatat nama file dan hash memudahkan Anda kembali ke versi yang sudah terbukti stabil.
- Ukur konsumsi memori pada beban nyata. Angka perhitungan hanya perkiraan; pada beban nyata, memori sering naik karena buffer tambahan dan antrean batch.
- Siapkan jalur cadangan. Untuk layanan internal, sediakan model ringan lain sebagai cadangan ketika A13B sedang sibuk atau sedang dimuatkan ulang.
Dengan ketiganya, perjalanan dari percobaan ke pemakaian harian menjadi jauh lebih pendek. Selain itu, catat juga konfigurasi batch dan panjang konteks yang Anda pakai, karena keduanya menggerakkan jejak memori lebih jauh daripada pertukaran quantization mana pun.
FAQ
Berapa parameter A13B?
Apakah A13B muat di kartu konsumsi?
Apakah Hunyuan punya GGUF rasmi?
Apakah model MoE lebih cepat daripada model dense dengan parameter yang sama?
Apakah konteks A13B lebih pendek daripada hy4?
Bisakah memanggil Hunyuan melalui API?
Bacaan lanjutan
- Halaman model hy4 — spesifikasi, matriks quantization, dan perhitungan memori
- Catatan kanal hy4-preview — kanal konteks 1M
- Ikhtisar keluarga Tencent Hunyuan — semua lini produk Hunyuan
- Penerapan Hunyuan hy4 dan A13B — rincian penerapan dua lini utama
- Penerapan hy4 dengan GGUF — jalur lengkap untuk model yang muat di satu mesin
- Panduan pemilihan model hy4 — ukuran dan pembahagian dengan A13B
- Panduan perhitungan VRAM — matematika memori umum
- Qwen versus Hunyuan — perbandingan ekosistem dan format quantization
Sumber data
Struktur dan ukuran file mengikuti konfigurasi dan daftar file pada repositori rasmi, disampel November 2026; angka kecepatan sebaiknya diukur pada perangkat keras Anda sendiri.