Panduan Lengkap Tencent Hy3 Gratis: Model AI 295B Parameter

Tencent Hy3 membawa dua hal yang jarang hadir bersamaan pada model besar: bobot terbuka dengan lisensi Apache 2.0 dan arsitektur MoE berkapasitas 295 miliar parameter. Model ini tidak mengaktifkan seluruh parameter setiap kali menjawab, sehingga menarik untuk eksperimen reasoning, coding, dan workflow agent yang membutuhkan konteks panjang.

Label “gratis” perlu dibaca dengan konteks yang tepat. Hy3 sempat tersedia melalui promo akses API terbatas pada Juli 2026. Promo dapat berakhir, berubah kuota, atau berpindah provider. Yang lebih penting untuk jangka panjang adalah bobot Hy3 yang bisa diakses secara terbuka dan pilihan untuk memakai API terkelola atau membangun server inference sendiri.

Bagian yang perlu dipertimbangkan sebelum mengadopsinya:

• perbedaan parameter total dan parameter aktif;
• peran Hy3 pada coding, dokumen, serta tool calling;
• biaya nyata di balik model open-weight;
• kebutuhan server untuk self-hosting;
• pengujian kualitas, keamanan, dan kontrol akses.

Tencent Hy3: 295B parameter, 21B yang aktif

Tencent Hy3 adalah model bahasa besar dari tim Tencent Hunyuan atau Hy. Model ini dirilis sebagai kelanjutan dari Hy3 Preview yang lebih dulu hadir pada 2026. Tencent memosisikan Hy3 untuk reasoning, coding, penggunaan tool, konteks panjang, dan aplikasi agentik.

Hy3 memiliki 295 miliar parameter total, tetapi memakai arsitektur Mixture-of-Experts atau MoE. Saat memproses token, model hanya mengaktifkan sekitar 21 miliar parameter. Pendekatan ini berbeda dari model dense yang menggunakan seluruh parameter pada setiap langkah inferensi.

Informasi bobot model, varian FP8, serta resep inference tersedia pada repository resmi Hy3 di GitHub. Tencent juga memublikasikan perkembangan kemampuan dan harga API di halaman riset Hy3.

Angka 295B menggambarkan kapasitas total model. Angka 21B lebih dekat dengan komputasi aktif saat inferensi, tetapi tidak menghapus kebutuhan hardware besar untuk menyimpan dan menyajikan model.

Cara MoE membantu, sekaligus menambah kompleksitas

Dalam MoE, model memiliki banyak expert yang dapat menangani pola berbeda. Router internal memilih expert yang paling relevan untuk token atau bagian pekerjaan tertentu. Pada Hy3, sistem tersebut memilih sebagian expert dari kumpulan yang lebih besar.

flowchart LR
	A["Prompt pengguna"] --> B["Router MoE"]
	B --> C["Expert terpilih"]
	C --> D["Pemrosesan token"]
	D --> E["Respons Hy3"]

Model MoE dapat memberi rasio kapasitas dan komputasi yang lebih efisien dibanding model dense berukuran sama. Namun, hasil akhirnya tetap bergantung pada server inference. Komunikasi antargpu, ukuran batch, panjang konteks, format presisi, dan implementasi framework dapat sangat memengaruhi latency.

Bagi pengguna API, kerumitan ini biasanya ditanggung provider. Bagi tim self-host, MoE berarti perlu memikirkan distribusi expert, bandwidth antargpu, serta pengaturan tensor parallel secara serius.

Catatan: Parameter aktif sekitar 21B tidak berarti Hy3 dapat diperlakukan seperti model 21B biasa. Bobot total, cache konteks, dan kebutuhan server tetap jauh lebih besar.

Dari Hy3 Preview ke rilis produksi

Tencent menyebut Hy3 sebagai pengembangan lanjutan dari Hy3 Preview. Setelah fase preview, tim Hy mengumpulkan masukan dari berbagai produk Tencent dan meningkatkan post-training untuk memperbaiki kepatuhan instruksi, konteks multi-putaran, serta stabilitas penggunaan tool.

Area yang disorot pengembang mencakup:

• ketepatan format keluaran;
• kemampuan mengikuti instruksi yang bertingkat;
• pemulihan saat tool gagal;
• konsistensi konteks panjang;
• kualitas coding dan workflow agentik;
• pengurangan respons yang tidak memiliki dasar data.

Tencent melaporkan sejumlah perbaikan dibanding versi preview, termasuk hasil evaluasi internal dan uji buta berbasis pekerjaan nyata. Klaim tersebut tetap perlu dibaca sebagai data dari pengembang model. Gunakan sebagai sinyal awal, lalu bandingkan dengan model lain pada dataset internal yang relevan.

Benchmark bukan bukti siap produksi

Hy3 memiliki hasil yang menarik pada benchmark coding, reasoning, dan penggunaan tool. Meski begitu, benchmark tidak mewakili seluruh kondisi production. Prompt pengguna bisa tidak lengkap, data internal punya format tidak lazim, dan tool dapat gagal di tengah proses.

Model yang kuat pada benchmark coding belum tentu cocok untuk klasifikasi tiket pelanggan. Sebaliknya, model yang ekonomis untuk ekstraksi data belum tentu cukup stabil untuk audit keamanan atau perubahan database.

Peringatan: Jangan memilih model hanya dari satu skor benchmark. Ukur ketepatan, biaya per tugas selesai, latency, kepatuhan terhadap schema, dan jumlah intervensi manusia pada use case kamu sendiri.

Hy3 untuk coding, dokumen, dan agen

Konteks hingga 256K token membuat Hy3 layak diuji untuk pekerjaan yang membutuhkan pembacaan beberapa dokumen atau file sekaligus. Namun, konteks besar bukan alasan untuk memasukkan seluruh arsip perusahaan ke prompt.

Coding dan review repository

Hy3 dapat dipakai untuk membantu tugas seperti:

• mengidentifikasi file terkait error test;
• menjelaskan alur modul lama;
• menyusun rencana perbaikan bug;
• merangkum perubahan pull request;
• menghasilkan test dari kontrak API;
• menelusuri dependensi antarmodul.

Agen coding perlu diberi batas yang jelas. Tetapkan folder yang boleh dibaca, perintah yang boleh dijalankan, jumlah iterasi, serta test yang harus lolos. Untuk perubahan yang menyentuh production, data pelanggan, atau otorisasi, review manusia tetap wajib.

Dokumen dan workflow bisnis

Hy3 juga dapat membantu mengelompokkan dokumen, mengambil informasi penting, atau membuat draft respons. Agar hasilnya mudah dipakai sistem, minta output terstruktur dan validasi respons di sisi aplikasi.

{
 "kategori": "permintaan_pengadaan",
 "prioritas": "sedang",
 "ringkasan": "Permintaan pembelian perangkat jaringan untuk cabang baru.",
 "perlu_review_manusia": true
}

Model dapat membantu menyiapkan data, tetapi tidak boleh menggantikan aturan bisnis. Bila nilai transaksi melewati ambang tertentu, aplikasi tetap harus meminta persetujuan. Bila dokumen tidak lengkap, sistem perlu menandai kekurangan data, bukan membiarkan model menebak.

Baca juga CursorBench Benchmark Mengukur Kemampuan AI

Tool calling yang dibatasi

Tool calling berguna ketika model harus mencari informasi, memeriksa status, atau menjalankan perhitungan. Mulai dari tool read-only, seperti pencarian dokumentasi, kueri status order, atau pembacaan hasil test di staging.

flowchart TD
	A["Permintaan pengguna"] --> B["Hy3 memilih langkah"]
	B --> C["Aplikasi memvalidasi izin"]
	C --> D["Tool dijalankan"]
	D --> E["Hasil dikirim ke Hy3"]
	E --> F["Respons akhir"]

Model tidak boleh bebas menghapus data, mengirim email eksternal, mengubah tagihan, atau menjalankan perintah shell tanpa kontrol. Aplikasi harus memvalidasi identitas pengguna, parameter tool, batas nilai, serta kebutuhan persetujuan manusia.

Gratis tidak sama dengan tanpa biaya

Hy3 pernah hadir dalam promo API gratis dengan durasi terbatas. Promosi tersebut berguna untuk eksperimen, tetapi bukan dasar yang aman untuk menghitung biaya produk jangka panjang. Periksa ketersediaan dan harga provider sebelum memulai integrasi.

Lisensi Apache 2.0 memberi keleluasaan untuk memakai, memodifikasi, dan mendistribusikan model sesuai ketentuannya. Namun, model open-weight tetap memiliki biaya operasional.

Harga API Tencent dapat berbeda berdasarkan wilayah, paket, cache, serta kebijakan platform cloud. Jangan menjadikan harga promosi atau tarif lama sebagai patokan tetap.

Bobot Hy3 bisa diakses tanpa biaya lisensi, tetapi menyajikan model 295B secara andal tetap membutuhkan anggaran teknis.

Self-hosting: kapan masuk akal?

Hy3 bukan pilihan realistis untuk laptop, PC gaming biasa, atau server GPU tunggal. Bobot BF16 besar, konteks panjang mengonsumsi cache, dan arsitektur MoE memerlukan komunikasi antargpu yang baik. Resep untuk vLLM dan SGLang memakai parallelism beberapa GPU, sehingga deployment perlu dirancang sebagai layanan server.

Faktor yang perlu dihitung:

1. Memori GPU untuk bobot, KV cache, batch, dan overhead framework.
2. Interkoneksi GPU agar komunikasi antarexpert tidak menjadi hambatan.
3. Jumlah request bersamaan karena performa satu pengguna tidak mencerminkan traffic production.
4. Observabilitas untuk memantau token, latency, error, dan penggunaan hardware.
5. Rencana fallback ketika server model tidak tersedia atau respons melewati timeout.

Varian FP8 dapat membantu mengurangi kebutuhan memori, tetapi kualitasnya perlu diuji pada tugas penting. Jangan langsung menyimpulkan bahwa hasil BF16 dan FP8 akan identik untuk coding, tool calling, atau format JSON.

Tips: Jika targetnya hanya mengukur kualitas output, coba endpoint terkelola terlebih dahulu. Self-host lebih tepat saat kontrol data, lokasi deployment, volume request, atau biaya jangka panjang benar-benar membenarkan investasi GPU.

Cara memakai Hy3 melalui endpoint kompatibel OpenAI

Banyak server inference menyajikan Hy3 lewat pola API yang kompatibel dengan OpenAI. Ini memudahkan integrasi karena struktur request sudah dikenal. Namun, nama model, alamat endpoint, parameter reasoning, dan dukungan tool calling dapat berbeda antarprovider.

Contoh panggilan ke endpoint lokal:

from openai import OpenAI

client = OpenAI(
 base_url="http://127.0.0.1:8000/v1",
 api_key="EMPTY",
)

response = client.chat.completions.create(
 model="hy3",
 messages=[
 {
 "role": "user",
 "content": "Jelaskan konsep MoE dalam tiga kalimat singkat."
 }
 ],
 temperature=0.7,
)

print(response.choices[0].message.content)

Untuk tugas ringan, gunakan mode respons langsung bila tersedia. Untuk coding, matematika, perencanaan, atau analisis sebab-akibat, naikkan effort reasoning secara bertahap. Mode penalaran tinggi dapat meningkatkan kualitas, tetapi juga berpotensi menambah latency dan token.

response = client.chat.completions.create(
 model="hy3",
 messages=[
 {
 "role": "user",
 "content": "Cari penyebab utama error test dan usulkan perubahan minimum."
 }
 ],
 extra_body={
 "chat_template_kwargs": {
 "reasoning_effort": "high"
 }
 }
)

Pastikan parameter tersebut benar-benar didukung oleh server yang dipakai. Jangan menyalin konfigurasi deployment lain tanpa memeriksa dokumentasi dan versi framework.

Cara: menguji Hy3 sebelum masuk production

1. Pilih satu use case yang sempit. Mulai dari ringkasan dokumen, klasifikasi tiket, analisis log, atau review kode sederhana.

2. Siapkan kasus evaluasi nyata. Gunakan data yang sudah dianonimkan. Sertakan input normal, ambigu, tidak lengkap, dan kasus yang harus dieskalasi.

3. Tentukan metrik lulus. Ukur ketepatan, kepatuhan format, latency, biaya per tugas selesai, serta kebutuhan koreksi manusia.

4. Uji tanpa tool lebih dulu. Pastikan kualitas respons dasar sudah cukup sebelum memberi akses ke sistem lain.

5. Tambahkan tool read-only. Batasi tool pada pencarian dokumentasi, pembacaan status, atau kueri data yang tidak dapat mengubah sistem.

6. Bandingkan dengan baseline. Uji Hy3 berdampingan dengan model atau proses yang sudah dipakai agar keputusan tidak hanya berdasarkan asumsi.

7. Buat fallback dan batas anggaran. Tetapkan timeout, maksimum retry, model cadangan, dan batas biaya agar eksperimen tidak berubah menjadi masalah operasional.

Prompt yang lebih efektif untuk Hy3

Konteks panjang akan berguna bila promptnya rapi. Pisahkan tugas, data sumber, batasan, dan format output. Jangan menyisipkan instruksi penting di antara ribuan token yang tidak relevan.

Tugas:
Cari penyebab test autentikasi gagal.

Ruang lingkup:
- Fokus pada AuthService dan test terkait.
- Jangan mengubah kontrak endpoint.
- Jangan mengedit file di luar backend/auth.

Output:
- Hipotesis utama.
- Bukti dari kode atau log.
- Perubahan minimum.
- Test yang perlu dijalankan.

Untuk dokumen bisnis, minta model menandai ketidakpastian. Ini jauh lebih aman daripada memaksa model memberi jawaban untuk semua bagian.

Gunakan hanya informasi yang tersedia.
Jika data tidak ditemukan, tulis "tidak tersedia".
Jangan mengarang angka, tanggal, atau nama pihak.

Peringatan: Konteks 256K bukan alasan untuk mengirim source code rahasia, private key, data kartu, atau seluruh dokumen perusahaan. Gunakan prinsip data minimum dan kontrol akses yang ketat.

Apache 2.0 untuk produk komersial

Lisensi Apache 2.0 menjadi salah satu daya tarik Hy3. Lisensi ini umumnya mendukung penggunaan komersial, modifikasi, dan distribusi ulang dengan kewajiban menjaga pemberitahuan lisensi serta mematuhi ketentuannya.

Bagi tim produk, lisensi permisif mengurangi hambatan saat ingin mengevaluasi model terbuka. Tim dapat membuat proof of concept, menambahkan fine-tuning, atau menjalankan deployment internal tanpa dibatasi klausul nonkomersial yang sering ditemukan pada model lain.

Lisensi model tetap bukan satu-satunya urusan legal. Tim masih perlu meninjau kebijakan data pelanggan, ketentuan cloud provider, regulasi industri, lisensi komponen tambahan, serta aturan internal mengenai AI generatif.

Kelebihan & Kekurangan

Kelebihan

• Arsitektur MoE 295B A21B memberi kapasitas besar dengan parameter aktif lebih rendah.
• Lisensi Apache 2.0 cocok untuk eksperimen dan produk komersial.
• Konteks 256K token berguna untuk dokumen serta workflow agent panjang.
• Bobot terbuka dan resep inference memberi pilihan API atau self-host.
• Fokus coding dan tool calling menarik untuk pengujian agen teknis.

Kekurangan

• Kebutuhan hardware besar membuat self-host sulit bagi sebagian besar individu.
• Banyak klaim benchmark berasal dari Tencent, sehingga perlu evaluasi independen.
• Promo akses gratis tidak permanen dan bisa berubah tanpa jaminan.
• Konteks panjang meningkatkan risiko data berlebih jika prompt tidak disiplin.
• Tool calling tetap harus dikendalikan aplikasi, bukan diserahkan penuh ke model.

Kesalahan yang sering membuat adopsi Hy3 gagal

Kesalahan umum adalah menganggap model open-weight pasti murah. Biaya lisensi memang dapat rendah atau tidak ada, tetapi biaya inference tetap nyata. Tim juga sering menguji model dengan demo singkat, lalu langsung memasangnya pada workflow yang jauh lebih kompleks.

Baca juga Gemini 3.7 Flash Vs Gemini 3.6 Flash Apa Perbedaannya

Kesalahan lain adalah memberikan tool dengan izin terlalu luas. Agen dapat membantu mencari dokumen atau membaca status, tetapi tidak perlu memiliki akses untuk menghapus data atau mengubah konfigurasi production.

Jaga data, key, dan endpoint inference

Hy3 dapat digunakan lewat API eksternal atau deployment sendiri. API terkelola membutuhkan pemeriksaan kebijakan pemrosesan data provider. Self-host memberi kontrol lebih besar, tetapi membuat tim bertanggung jawab penuh terhadap keamanan endpoint, log, akses pengguna, dan pembaruan framework.

Simpan key di environment variable atau secret manager. Jangan memasukkan token akses ke source code, screenshot, atau repository.

.env
.env.*
secrets/
*.key
*.pem

Gunakan binding lokal seperti 127.0.0.1 bila endpoint hanya dipakai aplikasi pada mesin yang sama. Jika endpoint perlu diakses dari jaringan internal, tambah autentikasi, firewall, rotasi key, rate limit, dan audit log.

Model yang besar tidak dapat menggantikan kebijakan keamanan yang baik. Batasi data yang dikirim, validasi output, dan pastikan tindakan berisiko selalu melewati kontrol aplikasi serta persetujuan manusia.

Kapasitas Besar, Biaya Nyata

• Arsitektur MoE: Hy3 memiliki 295B parameter, tetapi mengaktifkan sekitar 21B parameter per token.
• Promo terbatas: Akses API gratis pada Juli 2026 bukan jaminan biaya nol untuk penggunaan berkelanjutan.
• Lisensi terbuka: Apache 2.0 memberi ruang penggunaan komersial, modifikasi, dan deployment internal yang lebih fleksibel.
• Self-hosting berat: Bobot model, cache konteks, dan komunikasi antargpu menuntut infrastruktur GPU yang serius.
• Agent perlu pagar: Tool calling harus dibatasi lewat validasi parameter, least privilege, audit log, dan persetujuan manusia.
• Evaluasi wajib: Benchmark Tencent berguna sebagai acuan awal, tetapi keputusan adopsi perlu diuji pada data internal.

Hy3 layak diuji untuk coding, dokumen panjang, dan workflow agentik. Nilainya baru terasa jika kualitas output, biaya, keamanan, serta kesiapan infrastruktur dinilai secara bersamaan (lihat rits.shanghai.nyu.edu).

Checklist

• Setup: Tentukan satu use case sempit yang layak diuji dengan Hy3.
• Config: Verifikasi endpoint, nama model, parameter inference, dan batas kuota provider.
• Data: Siapkan dataset evaluasi yang sudah dianonimkan dari kasus kerja nyata.
• Verify: Ukur ketepatan, latency, biaya per tugas, serta kepatuhan format output.
• Secure: Simpan API key di secret manager dan batasi akses endpoint.
• Test: Mulai dari tool read-only sebelum memberi izin tindakan yang lebih sensitif.
• Ship: Siapkan fallback, batas retry, audit log, dan persetujuan manusia untuk aksi berisiko.
• Referensi resmi: rits.shanghai.nyu.edu.