hy4 GGUF: Peringkat quantization, pengiraan memori dan arahan llama.cpp / Ollama
hy4 GGUF: Peringkat quantization, pengiraan memori dan arahan llama.cpp / Ollama
hy4 ialah model yang paling mudah dihos sendiri dalam keluarga Hunyuan: model dense 4 bilion parameter, sumber mengeluarkan FP8, GPTQ-Int4 dan AWQ-Int4 serentak, dan komuniti mempunyai ramai penerbit penukaran GGUF. Apa yang benar-benar membuat kerja ini rumit bukan modelnya, tetapi tiga keputusan yang anda perlu buat sendiri: peringkat quantization mana, memori sebanyak apa, dan framework mana yang akan dipakai. Artikel ini bergerak mengikut susunan membuat keputusan, mengukur, melaksanakan, dan menyelesaikan masalah; semua arahan boleh disalin terus.
Ringkasan 30 saat
Kombinasi yang disyorkan untuk kali pertama ialah GGUF Q4_K_M komuniti bersama llama.cpp (llama-server untuk membuka endpoint yang serasi dengan OpenAI) Anggaran memorinya ialah 2.5GB untuk berat, 0.5GB untuk KV cache dan 0.5GB untuk kos runtime, jadi kad 6GB sudah memadai. Pengguna Mac sebaiknya beralih kepada penukaran 4bit milik mlx-community.
Langkah satu: memilih peringkat quantization
| Peringkat | Saiz (diukur daripada repositori bartowski) | Kualiti | Sesuai untuk |
|---|---|---|---|
| IQ4_XS | 2.37 GB | menghampiri Q4 | laluan Q4 apabila memori ketat |
| Q3_K_M | 2.17 GB | kehilangan yang dapat dirasai | muat pada kad 4GB |
| Q4_K_M | 2.61 GB | nyaris tanpa kehilangan | pilihan lalai, memadai untuk hampir semua kerja |
| Q5_K_M | 3.03 GB | menghampiri asal | pilih apabila memori masih lega |
| Q6_K | 3.47 GB | nyaris setara asal | pilihan konservatif untuk penjanaan teks panjang |
| Q8_0 | 4.49 GB | pada asasnya setara asal | dijadikan rujukan perbandingan ketepatan |
| FP16 (asal) | sekitar 8.4 GB | asal | hanya apabila memerlukan stack inferensi FP16 |
Saiz berat asal berdasarkan parameter pada model card: Hunyuan-4B-Instruct mempunyai 4.22 bilion parameter, sekitar 8.4GB dalam BF16.
Susunan pemilihan yang praktikal
Mulakan dengan Q4_K_M dan pastikan baris arahan, panjang konteks, dan perkhidmatan berfungsi sepenuhnya. Jika tugasan anda peka terhadap ketepatan, seperti pengekstrakan berstruktur atau penjanaan kod, bandingkan hasilnya dengan Q5_K_M. Hanya apabila anda perlu membina garis asas untuk mengukur berapa banyak kualiti hilang akibat quantization, barulah gunakan Q8_0 atau FP16. Bermula dengan FP16 biasanya hanya membazir memori.
Penerbit GGUF komuniti untuk hy4:
| Penerbit | Ciri repositori |
|---|---|
| bartowski | semua peringkat tersedia, unduhan tertinggi, sumber lalai yang selamat |
| mradermacher | menyediakan quantization piawai dan siri i1 |
| gabriellarson | kebanyakannya quantization piawai |
| DevQuasar | kebanyakannya quantization piawai |
| Disya | kebanyakannya Q8_0, sesuai untuk perbandingan ketepatan tinggi |
| Edge-Quant | satu peringkat Q4_K_M, pilihan minimalis |
Semasa memuat turun, periksa label quantization pada nama fail (Q4_K_M, Q5_K_M, Q8_0) dan repositori asalnya, jangan menganggap fail bernama sama daripada penulis berbeza sebagai barangan yang sama.
Langkah dua: mengira memori, jangan hanya mengira berat
Jumlah memori ialah tiga bahagian yang ditambah:
Jumlah memori ≈ Berat + KV cache + Kos runtime
Berat: 4.22 bilion parameter didarab dengan byte setiap parameter. Q4_K_M sekitar 0.65 byte setiap parameter, Q8_0 sekitar 1.06, dan FP16 ialah 2.
KV cache: tumbuh secara linear terhadap panjang konteks. Konfigurasi rasmi hy4 ialah 36 lapisan, 8 KV head, dan head dimension 128, yang dalam BF16 menggunakan kira-kira 144KB setiap token:
KV cache ≈ 2 × 36 lapisan × 8 KV head × 128 head dim × panjang konteks × 2 byte
≈ 144KB × panjang konteks
Perbandingannya: konteks 4K sekitar 0.56GB dan konteks 32K sekitar 4.6GB. Panjang kedudukan maksimum rasmi hy4 ialah 262144 (256K), tetapi mengisi tetingkap penuh bermakna KV cache memakan lebih daripada sepuluh GB, jadi panjang konteks yang benar-benar boleh digunakan mesti disimpul terbalik daripada memori, bukan disalin daripada label.
Jadual rujukan pantas
Q4_K_M (2.61GB) dengan konteks 4K: sekitar 2.6 + 0.6 + 0.5 = 3.7GB, ketat tetapi boleh pada kad 4GB. Q4_K_M dengan konteks 32K: sekitar 2.6 + 4.6 + 0.5 = 7.7GB, memerlukan kad 8GB ke atas. Q5_K_M dengan konteks 8K: sekitar 3.0 + 1.1 + 0.5 = 4.6GB, sesuai pada kad 6GB. Q8_0 (4.49GB) telah memakan sebahagian besar kad. Angka-angka ini ialah julat anggaran; angka sebenar ialah apa yang dilaporkan nvidia-smi sejurus selepas muatan pertama.
Langkah tiga: menjalankan dengan llama.cpp
# 1. Muat turun GGUF komuniti (contoh repositori bartowski; sesuaikan nama fail mengikut senarai dalam repositori)
huggingface-cli download bartowski/tencent_Hunyuan-4B-Instruct-GGUF \
Q4_K_M.gguf --local-dir ./hunyuan4b
# 2. Bercakap terus untuk memastikan berat dapat dimuatkan
./llama-cli -m ./hunyuan4b/Q4_K_M.gguf -p "Terangkan MoE dalam tiga ayat" -n 256
# 3. Buka perkhidmatan yang serasi dengan OpenAI
./llama-server -m ./hunyuan4b/Q4_K_M.gguf \
--host 127.0.0.1 --port 8080 \
--ctx-size 32768 \
--jinja
Setelah perkhidmatan berjalan, klien sedia ada hanya menukar dua parameter:
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8080/v1",
api_key="not-needed",
)
resp = client.chat.completions.create(
model="local-model",
messages=[{"role": "user", "content": "Hai, perkenalkan diri anda"}],
)
print(resp.choices[0].message.content)
Nama model boleh ikut suka hati, tetapi jangan guna ID API sebenar
llama-server tidak mengesahkan nama model secara ketat, jadi perkhidmatan tempatan boleh menggunakan local-model. Jika klien anda mencari nama model dalam katalog jarak jauh, pisahkan dengan jelas antara endpoint tempatan dan endpoint cloud.
Langkah empat: menjalankan dengan Ollama
Nilai Ollama terletak pada kemampuannya membawa pengurusan model dan ekosistem API sendiri, jadi alat seperti Open WebUI, Dify, dan Cursor terus memahaminya.
# 1. Cipta model daripada GGUF tempatan melalui Modelfile
cat > Modelfile <<'EOF'
FROM ./hunyuan4b/Q4_K_M.gguf
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF
ollama create hy4-local -f Modelfile
# 2. Sahkan
ollama run hy4-local "Tulis fungsi Python untuk menghurai masa ISO 8601"
# 3. Lihat dan padam
ollama list
ollama show hy4-local
ollama rm hy4-local
TEMPLATE mesti disalin daripada model card
Ini adalah perangkap paling tersembunyi ketika host sendiri: model dimuatkan, menghasilkan token, tetapi kualiti jawapannya buruk sehingga nampak seperti modelnya lemah. Puncanya hampir selalu templat perbualan yang tidak sepadan, dan templat Hunyuan berbeza antara generasi. Salin templat daripada bahagian Usage pada model card yang sepadan dan jangan lupa parameter stop, jika tidak model tidak akan berhenti.
Langkah lima: laluan Mac dan peranti tepi
| Platform | Laluan | Nota |
|---|---|---|
| Apple Silicon | mlx-community/Hunyuan-4B-Instruct-4bit | dimuatkan terus dengan mlx-lm, memori sepadu menjadikan manfaat quantization terasa langsung |
| Peranti tepi dan terbenam | taobao-mnn/Hunyuan-4B-Instruct-MNN | enjin inferensi MNN daripada Alibaba untuk mudah alih dan terbenam |
| CPU lama | GGUF Q4/Q5 komuniti | backend CPU llama.cpp, dengan 4B sebagai had realistik |
# Sahkan pantas dengan MLX
pip install mlx-lm
python -m mlx_lm.generate --model mlx-community/Hunyuan-4B-Instruct-4bit \
--prompt "Terangkan pangkalan data vektor dalam satu ayat" --max-tokens 128
Cara mendapatkan anggaran kelajuan yang dipercayai
Jangan percaya angka token/s orang lain. CPU, jalur lebar memori, panjang konteks, dan binaan engine semuanya mengubah hasil. Cara yang betul adalah mengukur pada mesin anda sendiri: kunci prompt, kunci panjang penjanaan, jalankan tiga pusingan dan ambil median, sambil merakam puncak memori. Simpan angka itu sebagai garis asas supaya perubahan peringkat quantization seterusnya masih boleh dibandingkan.
Jadual penyelesaian masalah: cari punca melalui gejala
| Gejala | Punca yang paling mungkin | Penanganan |
|---|---|---|
| Gagal muat kerana seni bina tidak disokong | binaan llama.cpp terlalu lama | naik taraf engine dan semula compile |
| Dimuatkan tetapi teks hasilnya pelik | templat perbualan salah | betulkan TEMPLATE atau --jinja mengikut model card |
| Mati kerana kehabisan memori | hanya mengira berat, melupakan KV cache | turunkan panjang konteks atau gunakan quantization lebih rendah |
| Sangat lambat setiap token | sebahagian lapisan tumpah ke memori sistem | gunakan quantization lebih kecil atau model lebih kecil |
| Token pertama sangat lambat, selepas itu normal | berat dimuatkan ke memori pada pusingan pertama | perkara normal, panaskan sahaja |
| Format pemanggilan alat tidak berkesan | templat kehilangan bahagian alat | tambahkan bahagian tool mengikut model card atau tukar templat |
| Output berulang dan tidak berhenti | parameter persampelan melampau | sesuaikan temperature dan top_p, pastikan ada token EOS |
Catatan tambahan sebelum produksi
Tiga perkara yang mudah terlepas ketika berpindah dari ujian kepada penggunaan sebenar:
- Simpan versi fail GGUF. Komuniti akan mengeluarkan pembaikan penukaran; dengan merekodkan nama fail dan kod hash, anda mudah kembali kepada versi yang terbukti stabil.
- Ukur penggunaan memori pada beban sebenar. Angka pengiraan hanyalah anggaran; pada beban sebenar, memori sering naik kerana penimbal tambahan dan baris gilir batch.
- Sediakan laluan sandaran. Untuk perkhidmatan dalaman, sediakan model ringan lain sebagai sandaran apabila hy4 sedang sibuk atau sedang dimuatkan semula.
Dengan ketiga-tiganya, perjalanan dari ujian kepada penggunaan harian menjadi jauh lebih pendek.
FAQ
Adakah hy4 mempunyai GGUF rasmi?
Untuk penerapan pertama, quantization mana yang patut dipilih?
Bagaimana cara mengetahui berapa memori yang diperlukan?
Patutkah memilih llama.cpp atau Ollama?
Kualiti output buruk. Adakah modelnya lemah?
Laluan manakah yang patut diambil pengguna Mac untuk 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
- Panduan pemilihan model hy4 — saiz dan kedudukan A13B
- Menjalankan hy4 dengan Ollama — menyambungkan endpoint tempatan kepada alat pembangunan
- Open WebUI dengan Hunyuan tempatan — antara muka perbualan yang dihos sendiri
- Panduan pengiraan VRAM — matematik memori umum
- Buku panduan penerapan tempatan — daripada pemeriksaan perkakasan hingga penyambungan alat
Sumber data
Senarai peringkat quantization dan repositori berubah mengikut kemas kini komuniti; artikel ini mencerminkan keadaan pada masa persampelan. Angka memori ialah anggaran berpengalaman, dan pengukuran anda sendiri yang menentukan.