Tiga Juta Model di Hugging Face Membuat Popularitas Menjadi Dasar Seleksi yang Buruk

Hugging Face kini memiliki cukup banyak repositori model publik sehingga pemilihan yang mengutamakan popularitas menjadi default yang buruk. Laporan ekosistem 14 Agustus mencatat pertumbuhan repositori dari 2,43 juta menjadi 2,96 juta, dengan 85,6% berada di bawah 200 download sepanjang masa dan 1,5% mengumpulkan 99,2% dari seluruh download. Praktisi tidak membutuhkan ranking popularitas yang lebih baik di dalam distribusi tersebut. Mereka membutuhkan cara untuk menyingkirkan model yang tidak kompatibel sebelum menghabiskan waktu untuk evaluasi.

Empat constraint mempersempit pilihan sebelum skor benchmark berguna: kecocokan tugas, izin penggunaan, artefak yang dapat dijalankan, dan revisi yang dapat direproduksi. Repositori dapat populer tetapi tetap gagal pada salah satunya.

Urutan itu penting ketika deployment open-weight menyebar melampaui lab model. TechCrunch melaporkan pada Juli bahwa CEO Hugging Face Clément Delangue menggambarkan ekosistem yang mendekati tiga juta model, tempat perusahaan menggunakan banyak model yang dikustomisasi alih-alih menunggu satu pemenang frontier universal. Pilihan yang lebih banyak dapat mengurangi ketergantungan pada satu provider. Pilihan itu juga memindahkan lebih banyak pekerjaan seleksi, lisensi, evaluasi, dan pemeliharaan kepada adopter.

Perhatian dan adopsi menjawab pertanyaan yang berbeda

Hugging Face membandingkan 25 repositori model dengan download 2026 terbanyak dan 25 repositori dengan like terbanyak, lalu menemukan satu irisan. Laporannya menafsirkan like sebagai perhatian terhadap sebuah rilis dan download sebagai bukti bahwa artefak ditarik ke dalam workflow berbasis Hub. Catatan metode laporan itu sendiri lebih ketat: tidak satu pun ukuran tersebut secara langsung menetapkan kualitas, adopsi komersial, atau pangsa pasar.

Counter download bukan counter pengguna. Counter bertambah ketika Hub melayani file yang memenuhi syarat melalui request GET atau HEAD. File yang dihitung bergantung pada library model, dan clone penuh repositori GGUF dapat dihitung lebih dari sekali karena setiap file GGUF bersifat mandiri. Build otomatis, cache miss, mesin yang berulang, dan eksperimen satu orang karena itu dapat menghasilkan download nyata tanpa mewakili pengguna yang berbeda atau deployment produksi yang berhasil.

Sinyal Hub	Yang dapat diberitahukannya	Peran seleksi yang berguna	Yang tidak ditetapkannya
Jumlah repositori	Supply sedang meluas	Menjelaskan mengapa filtering diperlukan	Kualitas, keunikan, atau status pemeliharaan
Like	Orang memilih untuk menyatakan minat	Sinyal discovery dan perhatian saat ini	Kecocokan workload atau penggunaan operasional
Download	File yang memenuhi syarat diminta dari Hub	Bukti kasar penggunaan berbasis Hub	Pengguna unik, tugas yang diterima, keamanan, atau penggunaan di luar Hub
Model turunan	Repositori lain menyatakan bahwa mereka dibangun di atas base model	Sinyal ekosistem dan tooling	Lineage yang benar atau kualitas turunan mana pun
Evaluasi model card	Publisher atau kontributor melaporkan sebuah hasil	Alasan untuk memeriksa kandidat dan setup pengujiannya	Performa pada input, runtime, atau aturan penerimaan Anda

Popularitas tetap berguna. Popularitas dapat menampilkan kandidat, diskusi aktif, konversi, dan contoh. Namun, popularitas tidak boleh diizinkan untuk menghapus hard constraint.

Empat constraint independen mempersempit katalog

Pencarian model menghasilkan shortlist, bukan keputusan deployment. Hard requirement yang hilang atau belum terselesaikan dapat membuat performa berikutnya tidak relevan.

Gate	Bukti yang dicatat	Kondisi lulus	Alasan penolakan yang umum
Tugas dan output	Tag pipeline, tujuan penggunaan, modalitas input, bentuk output, kebutuhan konteks	Artefak mendukung pekerjaan aktual dan kontrak integrasi	Model teks saja muncul dalam shortlist multimodal, atau output terstruktur diasumsikan tetapi tidak diuji
Izin dan provenance	Publisher, model card, teks lisensi, base model, pernyataan data training, syarat akses	Owner yang bertanggung jawab atas penggunaan telah meninjau syarat terkini dan celah provenance	Syarat hilang atau tidak kompatibel, base model tidak jelas, atau klaim tanpa dukungan bahwa publik berarti tidak terbatas
Runtime dan hardware	Format weight, jumlah parameter atau ukuran file, kuantisasi, backend, akselerator, anggaran memori	Satu artefak yang didukung memiliki jalur yang masuk akal pada stack target dengan ruang untuk cache dan state runtime	Pemenang benchmark tidak memiliki artefak kompatibel, atau weight-nya menghabiskan seluruh anggaran memori
Revisi dan keamanan artefak	Hash commit lengkap, daftar file, status keamanan, kebutuhan eksekusi kode	File yang ditinjau dapat diambil pada revisi immutable tanpa remote code yang belum disetujui	Seleksi mengarah ke main yang mutable, scan masih tertunda, atau loader memerlukan kode yang belum ditinjau tim

Constraint ini independen. Lisensi permisif tidak membuat model akurat. Benchmark yang kuat tidak membuat artefaknya muat di memori. Badge keamanan yang bersih tidak membuktikan perilaku model aman. Repositori populer dapat gagal pada keempatnya.

Model card adalah dokumen intake, bukan verifikasi independen

Hub merender README.md repositori sebagai model card-nya. Metadata model card dapat mengidentifikasi tugas, library, lisensi, dataset, base model, hubungan versi, dan hasil evaluasi. Field-field tersebut memungkinkan filtering dan review, tetapi disediakan oleh publisher atau kontributor repositori. Detail yang hilang merupakan bukti pertanyaan yang belum terselesaikan; detail yang ada merupakan klaim yang harus diperiksa terhadap artefak, paper, syarat, dan setup evaluasi yang ditautkan.

Kata open memerlukan presisi yang sama. FAQ open-source Hugging Face membedakan materi yang dapat diakses publik dari materi yang lisensinya memberikan hak untuk menggunakan, memodifikasi, atau mendistribusikannya kembali. “Open weights” menyatakan bahwa weight tersedia dalam kondisi tertentu. Istilah itu tidak menyebutkan kondisinya. Catat syarat aktual model, ikuti instruksi Hub untuk mencari dan menghormati lisensi repositori, dan minta owner yang bertanggung jawab menilainya untuk penggunaan yang dimaksud; tag lisensi Hub bukan nasihat hukum yang dipersonalisasi.

Provenance juga mencakup jalur konversi. Repositori GGUF atau MLX yang telah dikuantisasi dapat dipelihara oleh orang selain publisher base model. Hubungan base_model pada model card dapat menghubungkan keduanya, tetapi perbandingan yang dapat dipertanggungjawabkan tetap harus mengidentifikasi kedua repositori, kedua revisi, metode konversi jika diungkapkan, dan evaluasi apa pun terhadap artefak hasil konversi.

Pin apa yang telah ditinjau

Secara default, client Hub mengambil konten terbaru dari main. API download menerima hash commit lengkap sebagai revision-nya, sehingga “kami menguji model ini” menjadi pernyataan yang dapat direproduksi tentang file-file tertentu.

Revisi yang dipin tidak membekukan environment di sekitarnya. Catat runtime, library, driver, kuantisasi, chat template, dan konfigurasi di sampingnya. Ketika publisher merilis revisi baru, uji sebagai kandidat baru; jangan diam-diam mengganti artefak yang telah ditinjau di produksi.

Status keamanan adalah input lain, bukan jaminan. Hugging Face mengatakan scannernya menggunakan ClamAV dan menganalisis import dalam file pickle, sedangkan dokumentasi pickle-nya memperingatkan bahwa proses itu tidak foolproof. Commit bertanda tangan menetapkan asal, bukan ketidakberbahayaan. Utamakan format weight yang lebih aman seperti safetensors ketika model dan runtime mendukungnya, hindari remote code yang belum ditinjau, dan isolasi pemuatan awal dari credential serta data produksi.

Workload lebih penting daripada judul leaderboard

Setelah gate mempersempit bidang menjadi dua hingga empat model, jalankan setiap kandidat melalui fixture, revisi harness, pengaturan runtime, batas output, dan aturan penerimaan yang sama. Set fixture yang berguna mewakili kasus biasa, kegagalan berbiaya tinggi, input panjang, input malformed, serta kasus ketika respons yang benar adalah abstain atau meminta informasi lebih banyak.

Ukur pekerjaan yang selesai, bukan satu proxy yang menarik. Untuk summarizer terstruktur, itu dapat berarti output yang valid menurut skema, span bukti yang diwajibkan, jumlah fabrikasi kritis, latency end-to-end, peak memory, dan waktu koreksi reviewer. Untuk embedding, itu mungkin berarti recall pada set retrieval yang dibekukan, latency, biaya penyimpanan vektor, dan kegagalan pada query out-of-domain; penjelasan vectors dan embeddings kami menunjukkan mengapa metrik jarak yang berguna bergantung pada hubungan yang perlu dipertahankan aplikasi.

Hasil evaluasi Hub dapat membantu memilih kandidat, tetapi provenance-nya penting. Sistem hasil evaluasi dapat memuat submission publisher atau komunitas, tautan sumber, revisi dataset, dan badge hasil terverifikasi. Periksa tugas, split, tanggal, framework, revisi model, prompt, tool, dan pengaturan output sebelum menganggap dua angka dapat dibandingkan. Lalu gunakan hasil itu untuk merancang tes Anda—bukan untuk melewatinya. Panduan evaluasi AI yang lebih luas menjelaskan bagaimana perubahan metrik dapat mengubah keputusan produk.

Estimasi hardware memerlukan batas yang sama. Panel kompatibilitas hardware Hub mengestimasi apakah kuantisasi GGUF dan MLX muat pada hardware yang disimpan di profil pengguna. Itu adalah pre-filter yang nyaman. Peak memory aktual tetap bergantung pada artefak yang dipilih, konteks, cache, batch size, concurrency, backend, dan alokasi runtime lain. Analisis deployment Qwen3.8-27B kami membahas biaya memori tersembunyi itu, sementara analisis rilis llama.cpp kami (bahasa Indonesia) menjelaskan mengapa nama channel tidak menetapkan perilaku runtime.

Setelah pengukuran, pilih kandidat dengan biaya terendah yang lulus setiap gate keras dan aturan penerimaan. Model yang lebih besar mungkin sepadan dengan biayanya ketika secara material mengurangi kegagalan berkonsekuensi tinggi. Jika dua kandidat melewati threshold yang sama, penggunaan memori lebih kecil, dukungan runtime yang lebih sederhana, provenance yang lebih jelas, dan pemeliharaan aktif merupakan tie-breaker yang dapat dipertanggungjawabkan. Like dan download dapat memecahkan seri berikutnya; keduanya tidak boleh membalikkan tes yang gagal.

Seleksi model berakhir dengan tanggal pemeriksaan ulang

Revisi immutable membuat hasil dapat direproduksi, bukan selalu terkini. Lisensi, model card, hubungan base model, konversi, runtime, temuan keamanan, dan model alternatif terus berubah. Tetap pin artefak yang dipilih, simpan kandidat yang ditolak beserta alasannya, pantau repositori upstream, dan tetapkan pemicu pemeriksaan ulang untuk revisi baru yang material, pemberitahuan keamanan, perubahan lisensi, pergeseran workload, atau kegagalan produksi berulang.

Tonggak tiga juta model karena itu bukan sekadar perayaan pilihan, melainkan peringatan tentang kualitas keputusan. Popularitas Hub dapat memberi tahu tim tempat mencari. Izin, provenance, kompatibilitas, dan bukti workload—bukan counter sosial—menentukan apakah salah satu model tersebut benar-benar masuk ke sistem.

Sumber

1. Hugging Face State of Open Models: Summer 2026
2. TechCrunch report on the expanding open-model ecosystem
3. Hugging Face model download statistics documentation
4. Hugging Face model card documentation
5. Hugging Face Hub download and revision documentation
6. Hugging Face Hub license documentation
7. Hugging Face pickle scanning documentation
8. Hugging Face hardware compatibility documentation
9. Hugging Face evaluation results documentation
10. Hugging Face open-source FAQ