hy4 GGUF: Tingkat quantization, perhitungan memori, dan perintah llama.cpp / Ollama
hy4 GGUF: Tingkat quantization, perhitungan memori, dan perintah llama.cpp / Ollama
hy4 adalah model yang paling mudah di-host sendiri dalam keluarga Hunyuan: model dense 4 miliar parameter, sumber merilis FP8, GPTQ-Int4 dan AWQ-Int4 sekaligus, dan komunitas memiliki banyak penulis konversi GGUF. Yang benar-benar mempersulit bukan modelnya, melainkan tiga keputusan yang harus Anda ambil sendiri: tingkat quantization mana, memori sebesar apa, dan framework mana yang dipakai. Artikel ini berjalan sesuai urutan memutuskan, mengukur, menerapkan, dan menangani masalah; semua perintah bisa disalin langsung.
Ringkasan 30 detik
Kombinasi yang dianjurkan untuk kali pertama: GGUF Q4_K_M komunitas dengan llama.cpp (llama-server untuk membuka endpoint yang kompatibel dengan OpenAI). Perkiraan memori adalah 2.5GB untuk bobot, 0.5GB untuk KV cache, dan 0.5GB biaya runtime, sehingga kartu 6GB sudah cukup. Pengguna Mac sebaiknya beralih ke konversi 4bit milik mlx-community.
Langkah satu: memilih tingkat quantization
| Tingkat | Ukuran (diukur dari repositori bartowski) | Kualitas | Cocok untuk |
|---|---|---|---|
| IQ4_XS | 2.37 GB | mendekati Q4 | jalur Q4 saat memori ketat |
| Q3_K_M | 2.17 GB | kehilangan yang terasa | pas di kartu 4GB |
| Q4_K_M | 2.61 GB | nyaris tanpa kehilangan | pilihan bawaan, cukup untuk hampir semua pekerjaan |
| Q5_K_M | 3.03 GB | mendekati asli | pilih saat memori masih longgar |
| Q6_K | 3.47 GB | nyaris setara asli | pilihan konservatif untuk generasi teks panjang |
| Q8_0 | 4.49 GB | pada dasarnya setara asli | sebagai acuan perbandingan akurasi |
| FP16 (asli) | sekitar 8.4 GB | asli | hanya saat membutuhkan stack inferensi FP16 |
Ukuran bobot asli mengikuti parameter pada model card: Hunyuan-4B-Instruct memiliki 4,22 miliar parameter, sekitar 8,4GB dalam BF16.
Urutan pemilihan yang praktis
Mulailah dengan Q4_K_M dan pastikan perintah, panjang konteks, dan layanan berjalan lengkap. Jika tugas Anda sensitif terhadap presisi, seperti ekstraksi terstruktur atau pembuatan kode, bandingkan hasilnya dengan Q5_K_M. Hanya ketika Anda perlu membangun garis dasar untuk mengukur berapa hilangnya kualitas akibat quantization, barulah pakai Q8_0 atau FP16. Memulai dari FP16 biasanya hanya membuang memori.
Penulis GGUF komunitas untuk hy4:
| Penulis | Karakter repositori |
|---|---|
| bartowski | semua tingkat tersedia, unduhan tertinggi, sumber bawaan yang aman |
| mradermacher | menyediakan quantization standar dan seri i1 |
| gabriellarson | sebagian besar quantization standar |
| DevQuasar | sebagian besar quantization standar |
| Disya | sebagian besar Q8_0, cocok untuk perbandingan presisi tinggi |
| Edge-Quant | satu tingkat Q4_K_M, pilihan minimalis |
Saat mengunduh, periksa label quantization pada nama file (Q4_K_M, Q5_K_M, Q8_0) dan repositori asalnya, jangan menganggap file bernama sama dari penulis berbeda sebagai barang yang sama.
Langkah dua: menghitung memori, jangan hanya menghitung bobot
Total memori adalah tiga bagian yang dijumlahkan:
Total memori ≈ Bobot + KV cache + Biaya runtime
Bobot: 4,22 miliar parameter dikali byte per parameter. Q4_K_M sekitar 0,65 byte per parameter, Q8_0 sekitar 1,06, dan FP16 adalah 2.
KV cache: tumbuh linear terhadap panjang konteks. Konfigurasi resmi hy4 adalah 36 lapisan, 8 KV head, dan head dimension 128, yang di BF16 menghabiskan sekitar 144KB per 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 posisi maksimum resmi hy4 adalah 262144 (256K), tetapi mengisi penuh jendela berarti KV cache menghabiskan lebih dari sepuluh GB, jadi panjang konteks yang benar-benar bisa dipakai harus disimpulkan dari memori, bukan disalin dari label.
Tabel rujukan cepat
Q4_K_M (2,61GB) dengan konteks 4K: sekitar 2,6 + 0,6 + 0,5 = 3,7GB, ketat tetapi layak di kartu 4GB. Q4_K_M dengan konteks 32K: sekitar 2,6 + 4,6 + 0,5 = 7,7GB, perlu kartu 8GB ke atas. Q5_K_M dengan konteks 8K: sekitar 3,0 + 1,1 + 0,5 = 4,6GB, pas di kartu 6GB. Q8_0 (4,49GB) sudah menghabiskan sebagian besar kartu. Angka-angka ini adalah rentang perkiraan; angka nyata adalah apa yang dilaporkan nvidia-smi tepat setelah pemuatan pertama.
Langkah tiga: menjalankan dengan llama.cpp
# 1. Unduh GGUF komunitas (contoh repositori bartowski; sesuaikan nama file dengan daftar di repositori)
huggingface-cli download bartowski/tencent_Hunyuan-4B-Instruct-GGUF \
Q4_K_M.gguf --local-dir ./hunyuan4b
# 2. Bicara langsung untuk memastikan bobot termuat
./llama-cli -m ./hunyuan4b/Q4_K_M.gguf -p "Jelaskan MoE dalam tiga kalimat" -n 256
# 3. Buka layanan yang kompatibel dengan OpenAI
./llama-server -m ./hunyuan4b/Q4_K_M.gguf \
--host 127.0.0.1 --port 8080 \
--ctx-size 32768 \
--jinja
Setelah layanan berjalan, klien yang ada hanya perlu mengubah 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": "Halo, perkenalkan diri Anda"}],
)
print(resp.choices[0].message.content)
Nama model bebas diisi, tetapi jangan memakai ID API yang asli
llama-server tidak memvalidasi nama model secara ketat, jadi layanan lokal bisa memakai local-model. Jika klien Anda mencari nama model ke katalog jarak jauh, pisahkan dengan jelas antara endpoint lokal dan endpoint cloud.
Langkah empat: menjalankan dengan Ollama
Nilai Ollama adalah ia membawa manajemen model dan ekosistem API sendiri, sehingga alat seperti Open WebUI, Dify, dan Cursor langsung memahaminya.
# 1. Buat model dari GGUF lokal 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. Verifikasi
ollama run hy4-local "Tulis fungsi Python untuk mengurai waktu ISO 8601"
# 3. Lihat dan hapus
ollama list
ollama show hy4-local
ollama rm hy4-local
TEMPLATE harus disalin dari model card
Ini jebakan paling tersembunyi saat hosting sendiri: model termuat, menghasilkan token, tetapi kualitas jawabannya buruk sehingga tampak seperti modelnya lemah. Penyebabnya hampir selalu templat percakapan yang tidak cocok, dan templat Hunyuan berbeda antar generasi. Salin templat dari bagian Usage pada model card yang sesuai dan jangan lupa parameter stop, kalau tidak model tidak akan berhenti.
Langkah lima: jalur Mac dan perangkat tepi
| Platform | Jalur | Catatan |
|---|---|---|
| Apple Silicon | mlx-community/Hunyuan-4B-Instruct-4bit | dimuat langsung dengan mlx-lm, memori terpadu membuat keuntungan quantization langsung terasa |
| Perangkat tepi dan tersemat | taobao-mnn/Hunyuan-4B-Instruct-MNN | mesin inferensi MNN dari Alibaba untuk seluler dan tersemat |
| CPU lama | GGUF Q4/Q5 komunitas | backend CPU llama.cpp, dengan 4B sebagai batas realistis |
# Verifikasi cepat dengan MLX
pip install mlx-lm
python -m mlx_lm.generate --model mlx-community/Hunyuan-4B-Instruct-4bit \
--prompt "Jelaskan basis data vektor dalam satu kalimat" --max-tokens 128
Cara mendapatkan perkiraan kecepatan yang dipercaya
Jangan percaya angka token/detik orang lain. CPU, bandwidth memori, panjang konteks, dan build engine semuanya mengubah hasilnya. Cara yang benar adalah mengukur pada mesin Anda sendiri: kukuhkan prompt, kukuhkan panjang generasi, jalankan tiga putaran dan ambil median, sambil mencatat puncak memori. Simpan angka itu sebagai garis dasar agar perubahan tingkat quantization berikutnya tetap bisa dibandingkan.
Tabel penyelesaian masalah: gejala menuju penyebab
| Gejala | Penyebab paling mungkin | Penanganan |
|---|---|---|
| Gagal muat karena arsitektur tidak didukung | build llama.cpp terlalu lama | perbarui engine dan kompilasi ulang |
| Termuat tetapi keluar teks aneh | templat percakapan salah | perbaiki TEMPLATE atau --jinja sesuai model card |
| Mati karena kehabisan memori | hanya menghitung bobot, melupakan KV cache | turunkan panjang konteks atau gunakan quantization lebih rendah |
| Sangat lambat per token | sebagian lapisan tumpah ke memori sistem | gunakan quantization lebih kecil atau model lebih kecil |
| Token pertama sangat lambat, lalu normal | bobot dimuat ke memori pada putaran pertama | hal yang wajar, panaskan saja |
| Format pemanggilan alat tidak berlaku | templat kehilangan bagian alat | tambahkan bagian tool sesuai model card atau ganti templat |
| Keluaran berulang dan tidak berhenti | parameter sampling ekstrem | sesuaikan temperature dan top_p, pastikan ada token EOS |
Catatan tambahan sebelum produksi
Tiga hal yang mudah terlewat saat pindah dari percobaan ke pemakaian sungguhan:
- Simpan versi file GGUF. Komunitas akan menerbitkan perbaikan konversi; mencatat nama file dan kode 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 kali naik karena buffer tambahan dan antrean batch.
- Siapkan jalur cadangan. Untuk layanan internal, sediakan model ringan lain sebagai cadangan ketika hy4 sedang sibuk atau sedang dimuatkan ulang.
Dengan ketiganya, perjalanan dari percobaan ke pemakaian harian menjadi jauh lebih pendek.
FAQ
Apakah hy4 punya GGUF resmi?
Untuk penerapan pertama, quantization mana yang sebaiknya dipilih?
Bagaimana cara mengetahui berapa memori yang dibutuhkan?
Haruskah memilih llama.cpp atau Ollama?
Kualitas keluarannya buruk. Apakah modelnya lemah?
Jalur mana yang sebaiknya dipakai pengguna Mac untuk 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
- Panduan pemilihan model hy4 — ukuran dan posisi A13B
- Menjalankan hy4 dengan Ollama — menghubungkan endpoint lokal ke alat pengembang
- Open WebUI dengan Hunyuan lokal — antarmuka percakapan yang di-host sendiri
- Panduan perhitungan VRAM — matematika memori umum
- Buku pegangan penerapan lokal — dari pemeriksaan perangkat keras hingga menghubungkan alat
Sumber data
Daftar tingkat quantization dan repositori berubah mengikuti pembaruan komunitas; artikel ini mencerminkan keadaan saat pengambilan sampel. Angka memori adalah perkiraan berpengalaman, dan pengukuran Anda sendiri yang menang.