Hunyuan A13B MoE: 80B parameter jumlah, 64 pakar dan pertimbangan pemasangan
Hunyuan A13B MoE: 80B parameter jumlah, 64 pakar dan pertimbangan pemasangan
Hunyuan-A13B ialah model MoE pertama dan satu-satunya dalam keluarga Hunyuan yang membuka berat jumlah: konfigurasi rasmi menyebut 80.39 bilion parameter jumlah, 64 pakar, 32 lapisan, dan huruf A pada nama merujuk kepada kiraan parameter yang diaktifkan pada setiap token Struktur ini menjadikan dua perkara yang nampak bertentangan benar pada masa yang sama: kos pengkomputasian hampir setara model dense sederhana, tetapi jumlah berat berada pada tahap 80 bilion — tetap harus dimuatkan sepenuhnya ke dalam memori Artikel ini menerangkan struktur, buku memori, kegunaan sebenar GGUF rasmi, dan pembahagian kerja dengan hy4.
Ringkasan 30 saat
A13B ialah model peringkat pelayan, bukan model peringkat stesen kerja: fail GGUF rasmi Q4_K_M bersaiz 48.8GB dan Q4_0 ialah 45.4GB, jadi kad pengguna tunggal tidak dapat menampungnya Ia memerlukan banyak kad, CPU offload atau mesin dengan memori besar. hy4 barulah model yang boleh berjalan pada satu mesin. Jika anda mahu menjalankan Hunyuan di tempatan, titik mula sepatutnya ialah hy4 dan bukan A13B.
Jelaskan nama dan struktur dahulu
| Butir | Nilai (daripada konfigurasi rasmi) |
|---|---|
| Seni bina | HunYuanMoEV1ForCausalLM |
| Parameter jumlah | 80,393,183,232 (sekitar 80.39 bilion) |
| Bilangan pakar | 64 |
| Bilangan lapisan | 32 |
| Saiz tersembunyi | 4096 |
| Kepala attention / KV | 32 / 8 (perhatian berkumpulan) |
| Saiz perantaraan | 3072 |
| Panjang kedudukan maksimum | 32768 |
| Saiz kosa kata | 128,167 |
A pada A13B bermaksud Active
Hunyuan menggunakan konvensyen penamaan di mana angka hadapan ialah kiraan parameter yang diaktifkan pada setiap token (13B), manakala jumlah parameter tidak ditulis dalam nama. Jumlah parameter sebenar A13B ialah 80.39 bilion. Perbezaan ini adalah titik mula bagi setiap keputusan pemasangan — kos pengkomputasian dikira dari 13B, tetapi penyimpanan dikira dari 80B.
Mekanisme MoE: MLP pada setiap lapisan dibahagikan kepada beberapa pakar, dan penghala memilih beberapa pakar bagi setiap token manakala yang lain tidak menyertai. Akibatnya:
- Kos pengkomputasian hampir setara model dense 13B kerana setiap token hanya melalui beberapa pakar
- Storan berat kekal pada tahap 80B kerana semua pakar masih perlu dimuatkan
- Pemprosesan kelompok boleh mengurangkan kos kerana dalam satu kali forward, token berbeza mengaktifkan pakar berbeza, jadi unit pengkomputasian GPU dipenuhi dengan lebih penuh
MoE menjimatkan pengkomputasian, bukan memori
Ini ialah pertimbangan salah yang paling kerap berlaku. Ramai orang melihat "13B aktif" dan menganggap ia muat dalam memori model 13B. Pada hakikatnya anda masih perlu membayar berat 80B: walaupun dalam 4-bit pun sekitar 40GB, dan fail GGUF rasmi Q4_K_M berukuran 48.8GB pada cakera. Apabila memori tidak mencukupi, engine akan memindahkan sebahagian lapisan ke memori sistem dan kelajuan turun satu tertib — itu bukan "lewat sikit" tetapi "hampir tidak boleh digunakan".
Buku memori: ketiga-tiga lapisan mesti dikira
Lapisan pertama: berat
| Bentuk berat | Saiz (diukur daripada GGUF rasmi) |
|---|---|
| BF16 asal | 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 bahagian) | 47.5GB + 38.0GB ≈ 85.5GB |
Mengapa GGUF rasmi layak dimuat turun secara berasingan
Bagi model 80B, nilai GGUF rasmi terletak pada kemungkinan pembahagian dan CPU offload: Q8_0 terbahagi dua bahagian supaya boleh dimuatkan secara berperingkat, dan Q4_K_M memberikan kerugian kualiti yang lebih seimbang berbanding Q4_0. Penukaran komuniti biasanya hanya menghasilkan satu fail besar dengan pembahagian dan pengendalian meta-data yang kurang mesra, menjadikan offload lebih sukar justru ketika anda memerlukannya. Ini contoh jarang di mana model terbuka dari China mengeluarkan GGUF rasmi sebagai artifak yang setara.
Lapisan kedua: KV cache
KV cache ≈ 2 × 32 lapisan × 8 KV head × 128 head dim × panjang konteks × 2 byte
≈ 128KB × panjang konteks
Tetingkap penuh 32K sekitar 4GB, dan konteks 8K sekitar 1GB. Bahagian ini bagi A13B bukan konflik utama (berat yang sebenarnya), tetapi akan membesar apabila digunakan secara serentak: bilangan permintaan didarab panjang konteks menentukan jumlah jejak KV cache.
Lapisan ketiga: kos semasa berjalan
Konteks CUDA, penimbal komunikasi berbilang kad, dan tensor perantaraan expert parallel; dalam senario berbilang kad, item ini mengembang dengan ketara.
Realiti perkakasan: tiga bentuk yang boleh dilaksanakan
| Bentuk | Konfigurasi | Nota |
|---|---|---|
| Pelayan berbilang kad | 2×48GB atau 4×24GB, tensor parallel dalam vLLM | cara paling ortodoks, dan berat FP8 rasmi paling sesuai |
| Satu kad dengan CPU offload | 1×24GB dan RAM besar, pemindahan lapisan melalui llama.cpp | boleh berjalan tetapi menukar kelajuan dengan pengalaman, sesuai untuk pengesahan |
| Perkhidmatan cloud | menggunakan perkhidmatan yang sudah menyediakan A13B | tidak menggunakan kad sendiri dan tidak perlu mengurus expert parallel |
Cadangan kejuruteraan
Jika matlamatnya ialah "mempunyai Hunyuan yang berjalan pada mesin sendiri", mulakan dengan hy4 dan bukan A13B. Jika matlamatnya ialah "mengukur had keupayaan A13B", gunakan berbilang kad atau perkhidmatan cloud dan anggap A13B sebagai penjana rujukan: menghasilkan set penilaian, menghasilkan jawapan rujukan, dan mengukur jarak yang masih kurang pada model yang lebih kecil. Jangan memaksakannya ke dalam kad stesen kerja.
Perkara yang perlu diperhatikan semasa pemasangan
Versi engine: seni bina MoE memerlukan llama.cpp atau vLLM yang menyokong struktur pakar Hunyuan; naik taraf engine dahulu jika gagal dimuatkan.
Strategi keselarian: gunakan tensor parallel dalam vLLM untuk membahagikan berat. Expert parallel jarang berbaloi pada perkakasan pengguna.
Pemilihan quantization:
| Situasi anda | Pilihan |
|---|---|
| Pelayan berbilang kad, mengimbangi kelajuan dan kualiti | FP8 rasmi |
| Memori terhad tetapi kualiti mesti dijaga | GPTQ-Int4 rasmi |
| CPU offload atau ekosistem llama.cpp | GGUF rasmi Q4_K_M |
| Membina garis asas ketepatan | GGUF rasmi Q8_0 (ambil perhatian dua bahagian) |
Pemprosesan kelompok: satu manfaat sebenar MoE ialah hasil keserentakan. Permintaan dalam kelompok mengisi GPU dengan lebih penuh berbanding panggilan tunggal berturutan, dan itulah sebabnya ia sesuai untuk peranan pelayan dan bukannya stesen kerja.
Pembahagian kerja dengan hy4
| Dimensi | A13B | hy4 |
|---|---|---|
| Struktur | MoE, 80.39 bilion parameter jumlah melalui 64 pakar | Dense, 4.22 bilion parameter |
| Saiz berat pada 4-bit | 48.8GB | 2.61GB |
| Panjang kedudukan maksimum asal | 32768 | 262144 |
| KV cache setiap token | sekitar 128KB | sekitar 144KB |
| Lantai perkakasan | pelayan berbilang kad | satu kad, malah CPU |
| Peranan | had keupayaan, penjana rujukan, tugas kompleks | stesen kerja, peranti tepi, tugas ringan bervolum tinggi |
Pasangan yang berfungsi bersama
Gunakan A13B secara luar talian untuk menghasilkan satu set pertanyaan dan jawapan berkualiti tinggi bersama ringkasan rujukan, kemudian biarkan hy4 mengendalikan pengelasan, penulisan semula dan penghalaan pada laluan pengeluaran. Kedua-dua model tidak bercanggah: model besar menentukan piawaian, model kecil memikul trafik.
Catatan tambahan sebelum digunakan sebenar
Tiga perkara yang mudah terlepas ketika berpindah daripada ujian kepada penggunaan harian:
- Rekod versi fail GGUF. Komuniti akan mengeluarkan pembaikan penukaran; dengan merekodkan nama fail dan hash, anda mudah kembali kepada versi yang terbukti stabil.
- Ukur penggunaan memori pada beban sebenar. Angka pengiraan hanya anggaran; pada beban sebenar, memori sering naik kerana penimbal tambahan dan baris gilir kelompok.
- Sediakan laluan sandaran. Bagi perkhidmatan dalaman, sediakan model ringan lain sebagai sandaran apabila A13B sedang sibuk atau sedang dimuatkan semula.
Dengan ketiga-tiganya, perjalanan daripada ujian kepada penggunaan harian menjadi jauh lebih pendek. Rekod juga konfigurasi kelompok dan panjang konteks yang digunakan, kerana kedua-duanya menggerakkan jejak memori lebih jauh daripada sebarang pertukaran quantization.
FAQ
Berapa parameter A13B?
Bolehkah A13B muat dalam kad pengguna?
Adakah Hunyuan mempunyai GGUF rasmi?
Adakah model MoE lebih cepat daripada model dense dengan parameter yang sama?
Adakah konteks A13B lebih pendek daripada hy4?
Bolehkah Hunyuan dipanggil melalui API?
Bacaan lanjutan
- Halaman model hy4 — spesifikasi, matriks quantization dan pengiraan memori
- Nota saluran hy4-preview — saluran konteks 1M
- Gambaran keseluruhan keluarga Tencent Hunyuan — semua baris produk Hunyuan
- Pemasangan Hunyuan hy4 dan A13B — butiran pemasangan dua baris utama
- Pemasangan hy4 dengan GGUF — laluan lengkap bagi model yang muat pada satu mesin
- Panduan pemilihan model hy4 — saiz dan pembahagian dengan A13B
- Panduan pengiraan VRAM — matematik memori umum
- Qwen berbanding Hunyuan — perbandingan ekosistem dan format quantization
Sumber data
Struktur dan saiz fail mengikut konfigurasi dan senarai fail dalam repositori rasmi, disampel November 2026; angka kelajuan sepatutnya diukur pada perkakasan anda sendiri.