Memilih LLM Open Weights vs API Tertutup untuk Skala Produksi

Memilih LLM open weights vs API tertutup untuk skala produksi bukan sekadar soal biaya inferensi atau preferensi vendor. Keputusan ini memengaruhi kualitas keluaran, latency, throughput, kepatuhan data, observability, pola fallback, dan beban operasional tim dalam jangka panjang.

Untuk sistem produksi, pertanyaan utamanya biasanya bukan “mana yang lebih bagus secara umum”, melainkan model dan mode integrasi mana yang paling cocok untuk kebutuhan beban kerja tertentu. Dalam banyak kasus, jawabannya bisa berupa self-hosted open weights, API tertutup, atau arsitektur hybrid gateway yang menggabungkan keduanya berdasarkan kelas permintaan, sensitivitas data, dan target SLO.

Kapan masalah ini menjadi keputusan arsitektur, bukan sekadar pilihan model

Pada tahap prototipe, API tertutup sering menang karena integrasinya cepat, kualitas model umumnya stabil, dan tim tidak perlu mengelola GPU. Namun saat masuk produksi, kebutuhan mulai berubah:

• Traffic meningkat dan biaya per token mulai signifikan.
• Data sensitif tidak boleh keluar dari perimeter tertentu.
• Latency harus konsisten, bukan hanya rata-rata bagus.
• Observability dibutuhkan untuk audit prompt, error, retry, dan evaluasi kualitas.
• Vendor risk menjadi faktor: perubahan harga, rate limit, region, atau perilaku model dapat memengaruhi aplikasi.

Di titik ini, memilih antara open weights dan API tertutup harus diperlakukan seperti keputusan infrastruktur inti, setara dengan memilih database managed vs self-hosted, bukan sekadar mengganti endpoint.

Perbedaan mendasar: open weights vs API tertutup

Open weights self-hosted

Open weights berarti bobot model tersedia untuk dijalankan sendiri, biasanya melalui stack inferensi seperti engine serving, scheduler batching, dan orkestrasi GPU. Anda mengontrol deployment, routing, observability, dan kebijakan data.

Kelebihan utama:

• Kontrol penuh atas data, logging, dan topologi jaringan.
• Dapat menyesuaikan model, prompt stack, quantization, dan caching sesuai kebutuhan.
• Potensi biaya lebih efisien pada volume tinggi dan traffic stabil.
• Mengurangi ketergantungan pada satu vendor API.

Kekurangan utama:

• Beban operasional lebih besar: GPU, autoscaling, kapasitas, patching, dan monitoring.
• Kualitas model frontier tertentu bisa tertinggal dari API tertutup untuk tugas kompleks.
• Throughput dan latency sangat dipengaruhi implementasi serving, bukan hanya model.
• Tim kecil sering meremehkan kompleksitas deployment dan tuning inferensi.

API tertutup

API tertutup menawarkan akses ke model yang di-host vendor. Integrasi biasanya hanya membutuhkan HTTP client, autentikasi, dan pengelolaan retry/rate limit.

Kelebihan utama:

• Time-to-production cepat.
• Kualitas model biasanya kuat untuk reasoning, tool use, dan instruction following.
• Operasional inferensi ditangani vendor.
• Mudah ditingkatkan kapasitasnya tanpa investasi GPU awal.

Kekurangan utama:

• Biaya per token bisa sulit diprediksi saat traffic meningkat.
• Vendor lock-in lebih tinggi, baik di level API maupun perilaku model.
• Privasi dan residency data perlu ditinjau secara kontraktual dan teknis.
• Observability sering terbatas pada apa yang vendor expose.

Kriteria teknis yang paling menentukan

1. Gap kapabilitas model

Jangan mulai dari harga. Mulailah dari kelas tugas. Beberapa workload sangat sensitif terhadap kualitas model, misalnya:

• agent dengan tool calling multi-langkah,
• reasoning kompleks,
• ekstraksi data dari dokumen yang formatnya berantakan,
• workflow yang menuntut output terstruktur dengan error rendah.

Untuk kasus seperti ini, API tertutup sering lebih aman sebagai baseline awal karena gap kapabilitas model masih bisa bermakna. Sebaliknya, untuk workload seperti berikut, open weights sering cukup kompetitif:

• RAG dengan konteks domain yang kuat,
• klasifikasi, tagging, summarization terkontrol,
• transformasi teks yang format output-nya ketat,
• copilot internal dengan dokumen perusahaan.

Prinsip praktis: jika kegagalan model menyebabkan alur bisnis salah keputusan, evaluasi kualitas harus didahulukan sebelum membahas infrastruktur.

2. Latency dan throughput

Latency LLM tidak hanya ditentukan oleh ukuran model. Dalam produksi, faktor pentingnya meliputi:

• panjang prompt dan output,
• queue inferensi,
• batching,
• cold start,
• lokasi region,
• kontensi GPU,
• rate limit atau antrian dari vendor.

API tertutup sering unggul untuk memulai karena tidak ada pekerjaan tuning serving. Namun latency-nya tetap bisa berfluktuasi akibat jaringan publik, shared capacity vendor, atau pembatasan throughput.

Self-hosted memberi kontrol lebih besar atas p95/p99 jika Anda mampu mengatur:

• pool GPU terpisah per kelas request,
• continuous batching atau dynamic batching,
• token limit per tenant,
• timeout dan cancellation dengan benar.

Kesalahan umum adalah mengukur hanya time to first token pada traffic ringan, lalu mengabaikan perilaku saat antrean meningkat. Untuk produksi, ukur setidaknya:

• p50, p95, p99 latency,
• request per second per kelas model,
• tokens per second efektif,
• queue wait time,
• timeout rate dan retry rate.

3. Biaya GPU vs biaya per token

Trade-off biaya biasanya seperti ini:

• API tertutup lebih murah secara operasional pada volume rendah hingga menengah, terutama jika traffic belum stabil.
• Self-hosted open weights mulai menarik jika volume tinggi, pola traffic cukup dapat diprediksi, dan tim mampu menjaga utilisasi GPU.

Masalahnya, banyak tim hanya membandingkan “harga token” dengan “harga sewa GPU”. Itu terlalu sederhana. Perhitungan yang lebih realistis perlu memasukkan:

• utilisasi GPU aktual, bukan kapasitas teoritis,
• overhead engineering dan on-call,
• redundansi untuk high availability,
• buffer kapasitas saat lonjakan traffic,
• biaya observability, storage log, dan network egress,
• biaya eksperimen model dan rollback.

Jika utilisasi GPU rendah atau traffic sangat bursty, self-hosted sering terlihat murah di spreadsheet tetapi mahal di operasi nyata.

4. Vendor lock-in

Lock-in tidak hanya soal API endpoint. Bentuk lock-in yang sering muncul:

• format tool calling atau structured output yang khas vendor,
• perilaku prompt yang sulit dipindah ke model lain,
• dependensi pada fitur proprietary seperti file store, assistant runtime, atau tracing vendor,
• ketergantungan pada satu model untuk kualitas tertentu.

Jika risiko ini penting, gunakan lapisan abstraksi internal sejak awal: satu gateway untuk semua provider, kontrak request/response yang seragam, dan fallback ke provider lain atau model lain.

5. Privasi data dan kepatuhan

Untuk data sensitif, pertanyaan teknisnya harus spesifik:

• Apakah prompt dan output disimpan oleh vendor?
• Apakah ada opsi non-retention atau region tertentu?
• Apakah data perlu tetap di VPC atau jaringan privat?
• Apakah PII bisa di-redact sebelum inferensi?
• Apakah log aplikasi Anda sendiri sudah aman?

Self-hosted unggul ketika organisasi membutuhkan kontrol penuh atas jalur data. Tetapi perlu diingat: menjalankan model sendiri tidak otomatis aman. Risiko bisa pindah ke storage log, dashboard tracing, artifact model, atau akses operator internal.

6. Observability dan debugging

LLM production tanpa observability akan sulit dipelihara. Minimal Anda perlu melacak:

• template prompt dan versinya,
• input yang telah disanitasi,
• output model,
• latency per tahap,
• token usage,
• fallback yang terpicu,
• hasil evaluasi kualitas,
• error parsing, timeout, dan refusal.

Self-hosted biasanya lebih fleksibel untuk observability mendalam. API tertutup tetap bisa diobservasi, tetapi detail internal inferensi sering tidak terlihat. Karena itu, buat instrumentation di gateway aplikasi Anda, bukan bergantung penuh pada dashboard vendor.

Matriks keputusan praktis

Kapan pilih self-hosted open weights

Pilih pendekatan ini jika sebagian besar kondisi berikut terpenuhi:

• Data sangat sensitif atau ada batasan residency yang ketat.
• Traffic tinggi dan cukup stabil sehingga utilisasi GPU dapat dijaga.
• Task relatif sempit dan bisa dioptimalkan dengan prompt, RAG, atau fine-tuning ringan.
• Anda membutuhkan kontrol penuh atas observability, routing, dan deployment.
• Tim memiliki kemampuan SRE/platform untuk mengelola workload GPU.

Contoh skenario: knowledge assistant internal perusahaan dengan dokumen privat, volume harian besar, output terstruktur, dan toleransi rendah terhadap data keluar ke pihak ketiga.

Risiko utama self-hosted

• Kapasitas salah hitung sehingga p95 latency memburuk saat jam sibuk.
• Stack inferensi tidak stabil saat upgrade model atau engine serving.
• Biaya tersembunyi dari idle GPU dan HA multi-node.
• Tim aplikasi terpaksa menyelesaikan masalah infra yang seharusnya ditangani platform team.

Kapan pilih API tertutup

Pilih API tertutup jika kondisi berikut lebih penting:

• Perlu cepat masuk produksi.
• Kualitas model untuk reasoning atau instruction following sangat krusial.
• Traffic belum cukup besar untuk membenarkan investasi GPU.
• Tim kecil dan tidak ingin membawa beban operasi inferensi.
• Kebutuhan compliance masih dapat dipenuhi dengan kebijakan vendor dan sanitasi data.

Contoh skenario: fitur AI baru pada produk SaaS yang masih mencari product-market fit, traffic belum pasti, dan tim butuh iterasi cepat pada prompt, evaluasi, dan UX.

Risiko utama API tertutup

• Biaya naik tajam setelah fitur diadopsi luas.
• Perubahan model vendor memengaruhi kualitas output.
• Rate limit atau gangguan vendor berdampak langsung ke aplikasi.
• Prompt dan tool stack menjadi terlalu spesifik pada satu provider.

Kapan hybrid gateway lebih masuk akal

Untuk banyak tim, jawaban paling realistis adalah hybrid gateway: satu lapisan integrasi internal yang dapat merutekan request ke model self-hosted atau API vendor berdasarkan kebijakan.

Pendekatan ini masuk akal jika:

• Anda punya beberapa kelas workload dengan kebutuhan berbeda.
• Data sensitif perlu diproses internal, tetapi task kompleks sesekali butuh model frontier.
• Anda ingin fallback lintas provider untuk resiliency.
• Anda ingin mengendalikan lock-in tanpa langsung membangun platform inferensi penuh.

Contoh routing policy

• Self-hosted untuk klasifikasi, summarization internal, dan RAG dokumen privat.
• API tertutup untuk reasoning kompleks, agent multi-tool, atau fallback saat kualitas self-hosted tidak cukup.
• Fallback cadangan ke provider kedua jika timeout atau error rate provider utama naik.

Contoh arsitektur gateway

Client App
  -> LLM Gateway
       - auth / tenant policy
       - prompt templating
       - PII redaction
       - routing rules
       - retries / timeout / circuit breaker
       - structured logging / tracing
       - evaluation sampling
       - cost attribution
       |-> Self-hosted model endpoint
       |-> Vendor API A
       \-> Vendor API B

Dengan pola ini, aplikasi bisnis tidak perlu tahu detail provider. Semua kebijakan berada di satu tempat: observability, fallback, evaluasi, dan audit.

Pola implementasi yang disarankan

1. Gunakan kontrak internal yang stabil

Jangan expose detail provider langsung ke seluruh codebase. Buat kontrak internal sederhana untuk request dan response, misalnya:

{
  "task": "answer_question",
  "input": {
    "question": "Apa SLA layanan ini?",
    "context": ["..."]
  },
  "constraints": {
    "max_tokens": 400,
    "response_format": "json"
  },
  "policy": {
    "data_classification": "internal",
    "latency_tier": "interactive"
  }
}

Kontrak seperti ini memudahkan Anda mengganti backend tanpa membongkar semua pemanggil.

2. Pisahkan routing policy dari kode bisnis

Routing sebaiknya berbasis konfigurasi atau policy engine sederhana. Contoh pseudo-config:

routes:
  - match:
      task: "answer_question"
      data_classification: "internal"
      latency_tier: "interactive"
    primary: "self_hosted_general"
    fallback: ["vendor_api_a"]

  - match:
      task: "complex_reasoning"
    primary: "vendor_api_a"
    fallback: ["vendor_api_b", "self_hosted_large"]

Keuntungannya: Anda bisa mengubah strategi tanpa redeploy banyak service.

3. Terapkan timeout, retry, dan circuit breaker

Tanpa guardrail ini, LLM mudah menjadi bottleneck sistem.

• Timeout mencegah request menggantung terlalu lama.
• Retry hanya aman untuk error transien, dan sebaiknya dibatasi.
• Circuit breaker mencegah seluruh traffic terus diarahkan ke backend yang sedang gagal.

Kesalahan umum adalah retry agresif pada request yang berat, yang justru memperparah antrean dan biaya.

4. Log yang cukup, tetapi aman

Simpan log yang berguna untuk debugging, tetapi hindari menyimpan data mentah sensitif tanpa redaksi. Minimal log harus punya:

• request ID dan tenant ID,
• model/provider yang dipakai,
• latency per tahap,
• token usage atau perkiraan konsumsi,
• status fallback,
• hash/versi prompt template,
• indikator apakah input telah disanitasi.

Evaluasi kualitas: jangan mengandalkan demo manual

Perbandingan open weights vs API tertutup harus diuji pada dataset evaluasi internal, bukan hanya beberapa prompt contoh. Buat set data yang mewakili kasus produksi:

• pertanyaan mudah dan sulit,
• input panjang dan pendek,
• dokumen bersih dan berantakan,
• kasus tepi yang sering gagal,
• output yang perlu format JSON atau schema tertentu.

Ukur kombinasi metrik berikut:

• Task success rate: apakah jawaban benar atau dapat dipakai.
• Format adherence: apakah output valid terhadap schema.
• Latency: terutama p95 dan p99.
• Fallback rate: seberapa sering backend utama gagal.
• Cost per successful task: lebih berguna daripada cost per request mentah.

Fokus pada biaya per tugas yang berhasil, bukan hanya biaya per token. Model murah tetapi sering gagal bisa lebih mahal secara bisnis.

Pola evaluasi yang pragmatis

1. Pilih 50-200 contoh nyata dari traffic atau staging.
2. Definisikan rubrik penilaian yang jelas.
3. Bandingkan minimal satu model open weights dan satu API tertutup.
4. Jalankan evaluasi berkala setelah prompt, model, atau kebijakan routing berubah.
5. Simpan hasil evaluasi per versi agar regresi terlihat.

Deployment dan operasi produksi

Jika memilih self-hosted

Pastikan Anda sudah memikirkan aspek berikut sebelum go-live:

• Capacity planning: model size, concurrency, dan target p95.
• Isolation: pisahkan workload interaktif dari batch agar tidak saling mengganggu.
• Autoscaling: jika memungkinkan, tetapi pahami bahwa GPU autoscaling tidak sesederhana stateless HTTP worker.
• Rollout strategy: canary untuk model atau engine baru.
• Health checks: bukan hanya port hidup, tetapi kesiapan memproses inferensi.

Kesalahan yang sering terjadi adalah menaruh semua workload pada satu pool inferensi. Akibatnya, job batch panjang merusak latency request interaktif.

Jika memilih API tertutup

Walaupun tidak mengelola GPU, tetap perlakukan integrasi ini sebagai dependency kritis:

• siapkan fallback untuk outage atau timeout vendor,
• monitor quota dan rate limit,
• tetapkan budget guardrail per tenant atau fitur,
• uji perubahan model vendor pada sample traffic,
• hindari coupling terlalu dalam ke fitur proprietary bila belum benar-benar perlu.

Maintainability untuk tim kecil

Bagi tim kecil, pertanyaan paling penting sering kali bukan “apa yang paling optimal”, tetapi “apa yang bisa dioperasikan konsisten enam bulan ke depan”.

Secara umum:

• API tertutup cocok jika tim perlu fokus pada produk, evaluasi, dan UX, bukan platform inferensi.
• Self-hosted masuk akal jika ada kebutuhan data/compliance kuat atau volume cukup besar untuk membenarkan operasi tambahan.
• Hybrid cocok jika Anda ingin jalur migrasi bertahap: mulai dari API, lalu pindahkan workload tertentu ke self-hosted saat pola traffic dan kebutuhan sudah jelas.

Arsitektur hybrid sering menjadi kompromi terbaik karena memungkinkan Anda mengadopsi model open weights tanpa memaksa semua use case pindah sekaligus.

Checklist keputusan sebelum memilih

1. Apakah workload ini benar-benar butuh kualitas model frontier?
2. Apakah data boleh keluar ke vendor eksternal?
3. Berapa target p95 latency dan bagaimana pola burst traffic?
4. Apakah volume cukup tinggi untuk membuat GPU ekonomis?
5. Apakah tim punya kemampuan operasi GPU dan inferensi?
6. Apakah dibutuhkan fallback lintas provider untuk reliability?
7. Apakah evaluasi kualitas sudah berbasis dataset internal, bukan demo manual?
8. Apakah kontrak integrasi cukup abstrak untuk mencegah lock-in berlebihan?

Kesimpulan

Dalam memilih LLM open weights vs API tertutup untuk skala produksi, tidak ada jawaban universal. Self-hosted open weights unggul pada kontrol data, fleksibilitas, dan potensi efisiensi di volume tinggi. API tertutup unggul pada kualitas model frontier, kecepatan implementasi, dan rendahnya beban operasional. Hybrid gateway sering paling rasional karena memberi jalur optimasi bertahap tanpa mengorbankan reliability.

Pendekatan terbaik adalah memulai dari kebutuhan sistem: kualitas minimal yang diterima, batasan data, target latency, pola traffic, dan kapasitas tim. Setelah itu, uji dengan evaluasi internal, ukur biaya per tugas yang berhasil, dan bangun lapisan gateway agar keputusan model tidak menyebar ke seluruh aplikasi.