Open model nggak harus menang semua benchmark buat jadi pilihan yang lebih masuk akal di workflow lu.
Kalau task-nya jelas, endpoint-nya lu kontrol, dan harness evaluasinya rapi, model open atau model kecil yang dilatih khusus bisa mengalahkan model frontier dari sisi biaya, ownership, dan predictability. Artikel ini ngebahas cara waras menilai open model: bukan dari fanwar open vs closed, tapi dari apakah model itu bikin kerja lu selesai dengan bukti yang bisa dicek.
Intinya sederhana: jangan tanya “model mana yang paling pintar?” dulu. Tanya “task apa yang mau diselesaikan, data lewat mana, biayanya kelihatan nggak, dan hasilnya bisa diuji ulang nggak?”
Apa itu intelligence ownership?
Dalam konteks AI workflow, intelligence ownership bukan berarti lu harus melatih LLM dari nol atau punya GPU farm sendiri. Buat gua, ownership berarti lu punya kontrol lebih besar atas empat hal:
- Endpoint: request AI lu jalan ke layanan yang jelas, bukan cuma subscription black box.
- Data path: lu tahu data dari laptop/server lu pergi ke mana dan balik lewat mana.
- Task definition: AI nggak disuruh “bantuin aja”, tapi dikasih pekerjaan spesifik.
- Evaluation loop: hasilnya punya scorer, test, review diff, atau metrik yang bisa dicek.
Matthew Saltz nulis pengalaman memakai opencode lewat inference endpoint sendiri. Poin yang menarik bukan sekadar “open model bisa dipakai buat ngoding”, tapi rasa kontrolnya: endpoint punya dia, data path terasa lebih jelas, dan workflow personal nggak bergantung penuh pada paket subscription tertentu.
Itu bukan berarti semua orang harus langsung self-host model. Tapi ini sinyal penting: developer mulai peduli bukan cuma kualitas jawaban, tapi juga rasa memiliki terhadap infrastruktur AI yang dipakai sehari-hari.
Kenapa benchmark mentah sering menipu?
Benchmark itu berguna, tapi sering dibaca terlalu dangkal. Model A menang 2 poin dari model B, lalu timeline rame seolah semua workflow harus pindah hari itu juga. Padahal di produksi, pertanyaan yang lebih penting biasanya:
- Apakah task lu mirip dengan task benchmark?
- Apakah latency-nya masuk akal buat user?
- Apakah cost per task masih sehat kalau volume naik?
- Apakah output-nya bisa divalidasi otomatis?
- Apakah model gagal dengan cara yang bisa lu tangani?
FermiSense memberi contoh yang lebih konkret. Mereka menulis case study catalog review: pada workflow yang sama, dengan tools, images, dan scorer yang sama, fine-tune GRPO dari model open-source 9B mereka diklaim mengalahkan beberapa konfigurasi frontier yang diuji. Klaim biayanya juga agresif: sekitar $0.50 per 1,000 listings, disebut 40x lebih murah dari setup frontier termurah dan sekitar 340x lebih murah dari yang termahal dalam eksperimen mereka.
Gua sengaja pakai kata “diklaim”, karena ini tetap case study dari pihak yang punya konteks dan kepentingan sendiri. Tapi pelajarannya kuat: model kecil bisa masuk akal kalau task-nya sempit, data dan scorer jelas, dan prosesnya didesain buat pekerjaan itu. Bukan karena model 9B tiba-tiba lebih pintar dari semua model frontier di semua hal.
Open model paling kuat saat task-nya sempit
Kesalahan umum saat orang mencoba open model adalah membandingkannya secara mentah dengan Claude, GPT, atau Gemini untuk semua hal sekaligus. Dipakai buat brainstorming, coding, reasoning, summarization, data extraction, customer support, semua digabung. Lalu kecewa karena output-nya nggak selalu sehalus model frontier.
Padahal strategi yang lebih sehat adalah membatasi arena pertarungan.
Contohnya:
- Ekstraksi field dari dokumen invoice.
- Klasifikasi tiket support ke kategori tertentu.
- Review listing produk berdasarkan policy internal.
- Generate draft changelog dari commit yang sudah terstruktur.
- Menjawab FAQ internal dari knowledge base yang rapi.
Task seperti ini bisa punya contoh jawaban, aturan penilaian, test set, dan batas gagal yang lebih jelas. Di sinilah open model, fine-tune kecil, atau managed endpoint yang bisa lu kontrol mulai terasa menarik. Lu nggak butuh model yang menang debat filsafat. Lu butuh model yang konsisten menyelesaikan pekerjaan berulang.
Harness sering lebih penting daripada ganti model
GitHub juga baru menulis angle yang nyambung: “the harness is all you need (mostly)”. Mereka membahas workflow Copilot yang lebih menekankan prototyping, planning, implementation, dan review, bukan sekadar kejar tool AI terbaru.
Dalam praktiknya, harness itu lapisan kerja di sekitar model. Bentuknya bisa sederhana:
- prompt template yang stabil,
- file instruksi repo seperti
AGENTS.md, - test command yang wajib jalan,
- scorer untuk output terstruktur,
- approval sebelum file penting diubah,
- logging cost dan token per task,
- review diff sebelum merge.
Model bagus tanpa harness bisa tetap ngawur. Sebaliknya, model yang tidak paling frontier bisa jadi sangat berguna kalau workflow-nya membatasi ruang salah dan memaksa hasilnya bisa dicek.
Ini juga alasan gua lebih percaya eksperimen berbasis task dibanding klaim “model ini lebih pintar”. Kalau lu bisa nunjukin task, input, output, scorer, cost, dan failure case, pembahasannya jadi engineering. Kalau cuma screenshot jawaban bagus, itu masih konten marketing.
Kapan model frontier tetap pilihan terbaik?
Artikel ini bukan ajakan buat ninggalin model frontier. Buat banyak pekerjaan, model frontier tetap pilihan paling masuk akal, terutama saat task masih eksploratif atau butuh reasoning luas.
Gua masih akan memilih model frontier untuk:
- membedah codebase yang belum gua pahami,
- mencari beberapa strategi arsitektur,
- debugging bug yang gejalanya belum jelas,
- menulis draft awal ide kompleks,
- menguji asumsi dari beberapa sudut pandang.
Model frontier kuat saat ruang masalahnya masih kabur. Tapi setelah workflow makin repeatable, lu perlu mulai tanya: apakah masih perlu model paling mahal untuk tiap request?
Kapan open model atau endpoint sendiri mulai masuk akal?
Open model atau endpoint yang lebih lu kontrol mulai menarik saat kondisi ini muncul:
- Volume tinggi: task terjadi ratusan atau ribuan kali, bukan cuma sesekali.
- Format output jelas: jawaban bisa divalidasi dengan schema, scorer, atau test.
- Data sensitif: lu perlu batas data path yang lebih jelas.
- Cost mulai kelihatan: invoice AI bukan lagi angka kecil di kartu kredit.
- Latency penting: user nggak bisa nunggu lama untuk task sederhana.
- Failure bisa didefinisikan: lu tahu bentuk jawaban salah dan bisa ngeblok output buruk.
Kalau belum punya ini, pindah ke open model sering cuma memindahkan masalah. Lu mungkin hemat subscription, tapi bayar lewat setup, observability, maintenance, dan debugging.
Checklist memilih model AI buat workflow nyata
Sebelum pindah model karena hype, coba pakai checklist ini:
- Tulis task dalam satu kalimat. Kalau task nggak bisa dijelaskan singkat, model evaluation bakal kabur.
- Siapkan 20–50 contoh input-output. Nggak harus sempurna, tapi cukup buat melihat pola gagal.
- Hitung cost per successful task. Jangan cuma cost per token. Task gagal juga biaya.
- Uji latency end-to-end. Yang penting bukan cuma model speed, tapi waktu dari request sampai user dapat hasil.
- Catat failure mode. Apakah model halusinasi, salah format, terlalu verbose, atau gagal baca konteks?
- Bandingkan model frontier, open model, dan rule-based baseline. Kadang solusi boring justru menang.
- Putuskan berdasarkan evidence, bukan timeline. Kalau nggak ada data workflow lu sendiri, jangan buru-buru migrasi.
Takeaway buat developer dan builder
Open model itu bukan agama. Closed model juga bukan musuh. Keduanya alat, dan alat yang tepat tergantung bentuk kerja lu.
Kalau lu lagi eksplorasi problem baru, model frontier bisa jadi partner berpikir yang sangat kuat. Tapi kalau lu sudah punya task berulang, data jelas, dan cara menilai hasil, open model atau endpoint yang lu kontrol bisa jadi lebih ekonomis dan lebih nyaman secara ownership.
Yang paling penting: jangan baca AI dari leaderboard doang. Baca dari workflow. Model yang “lebih pintar” tapi bikin invoice meledak, data path kabur, dan output sulit diuji belum tentu lebih baik buat produk lu.
Follow rafli.dev kalau lu pengin bahasan AI dan software development yang tetap praktis, jujur, dan nggak ikut fanwar kosong.
FAQ singkat
Apakah open model selalu lebih murah?
Nggak selalu. Open model bisa lebih murah untuk task repeatable dengan volume jelas, tapi setup, hosting, monitoring, dan maintenance tetap punya biaya.
Apakah endpoint sendiri berarti data pasti aman?
Nggak otomatis. Endpoint sendiri cuma memberi kontrol lebih besar. Lu tetap perlu cek logging, storage, access control, network path, dan siapa yang bisa membaca data.
Apakah model kecil bisa mengalahkan model frontier?
Bisa pada task sempit yang terdefinisi jelas, terutama kalau ada fine-tuning, scorer, dan harness yang rapi. Tapi jangan generalisasi ke semua task reasoning atau coding kompleks.
Apa langkah paling realistis buat solo developer?
Mulai dari evaluasi kecil: pilih satu task berulang, kumpulkan contoh, bandingkan 2–3 model, hitung cost per successful task, lalu lihat apakah open model benar-benar memberi manfaat.
