Memilih Arsitektur Inference AI On-Device vs Server Terpusat

Memilih arsitektur inference AI on-device vs server terpusat adalah keputusan engineering, bukan sekadar preferensi deployment. Jawaban singkatnya: pilih on-device jika Anda butuh latensi rendah, privasi tinggi, dan aplikasi tetap berjalan saat koneksi buruk; pilih server terpusat jika model sering berubah, observability harus kuat, dan Anda perlu kontrol resource secara konsisten; pertimbangkan edge jika Anda ingin kompromi di antara keduanya.

Tren hardware lokal yang makin kuat, termasuk kelas perangkat seperti AMD Ryzen AI Halo AI Dev Kit, membuat inference lokal semakin realistis untuk banyak use case. Namun kekuatan hardware tidak otomatis berarti semua beban inferensi sebaiknya dipindah ke perangkat pengguna. Yang perlu dinilai adalah trade-off arsitektur: latensi, privasi data, biaya infra vs biaya perangkat, utilisasi GPU/NPU, deployment, update model, fallback saat resource lokal terbatas, serta maintainability dalam beberapa tahun ke depan.

Masalah yang Sebenarnya: Bukan "Bisa Jalan", tapi "Layak Dioperasikan"

Banyak tim berhenti di pertanyaan teknis sempit seperti: "model ini bisa jalan di laptop atau tidak?" Itu penting, tetapi belum cukup. Dalam produksi, pertanyaan yang lebih relevan adalah:

• Apakah performa konsisten di berbagai kelas perangkat?
• Bagaimana model diperbarui tanpa merusak kompatibilitas?
• Apakah ada fallback saat memori, baterai, atau thermal throttling memburuk?
• Bagaimana mengamati kualitas inferensi jika eksekusi tersebar di ribuan perangkat?
• Apakah total biaya lebih rendah dibanding sentralisasi di server?

Dengan kata lain, keputusan arsitektur inference harus mempertimbangkan siklus hidup sistem, bukan hanya demo awal.

Tiga Pola Arsitektur yang Perlu Dibedakan

1. On-device inference

Model dijalankan langsung di perangkat pengguna atau perangkat lokal: laptop, desktop, ponsel, kiosk, workstation, atau perangkat embedded. Eksekusi bisa memanfaatkan CPU, GPU, atau NPU jika tersedia.

Cocok untuk:

• Asisten lokal dengan kebutuhan respons instan
• Fitur privasi tinggi seperti transkripsi rapat internal
• Aplikasi offline atau konektivitas tidak stabil
• Pre-processing berat sebelum data dikirim ke server

2. Edge inference

Model dijalankan di node dekat sumber data, misalnya gateway pabrik, mini server di kantor cabang, atau appliance lokal. Secara operasional, ini sering menjadi jalan tengah antara perangkat pengguna dan cloud pusat.

Cocok untuk:

• Video analytics di lokasi dengan bandwidth terbatas
• Sistem industrial yang perlu latensi rendah tapi tidak ingin model tersebar ke semua endpoint
• Kebutuhan kontrol data per lokasi atau per region

3. Server terpusat

Inference dijalankan di backend terkelola, baik di data center sendiri maupun cloud. Klien hanya mengirim request dan menerima hasil.

Cocok untuk:

• Model besar yang tidak realistis dijalankan di endpoint
• Produk yang butuh update model cepat dan sering
• Use case multi-tenant dengan kontrol observability dan policy yang ketat
• Pola traffic yang lebih mudah diatur lewat autoscaling

Kerangka Keputusan: Kapan On-Device, Edge, atau Server?

1. Latensi dan pengalaman pengguna

Jika fitur AI berada di jalur interaksi utama pengguna, latensi sering menjadi faktor pertama. On-device biasanya mengurangi komponen latensi jaringan, DNS, TLS, antrian backend, dan kemacetan lintas region. Ini penting untuk:

• autocomplete atau copilot lokal
• deteksi objek dari kamera real-time
• noise suppression atau speech enhancement
• transkripsi live

Namun jangan hanya melihat round-trip time. Latensi total tetap dipengaruhi oleh:

• waktu loading model
• warm-up runtime
• ukuran batch
• contention dengan proses lain di perangkat
• thermal throttling

Implikasi praktis: on-device unggul jika permintaan kecil tapi sering, dan harus responsif. Server terpusat masih masuk akal jika request lebih jarang atau bisa diproses asinkron.

2. Privasi data dan batas regulasi

Jika data mentah bersifat sensitif, inference lokal sering menjadi pilihan kuat karena data tidak perlu meninggalkan perangkat. Ini umum pada:

• dokumen internal
• audio rapat
• gambar medis
• telemetri operasional pabrik

Tetapi privasi tidak otomatis selesai hanya karena model lokal. Anda tetap perlu memikirkan:

• apakah log aplikasi menyimpan prompt atau output sensitif
• apakah file model dapat diekstrak atau dibalik-rekayasa
• bagaimana mengelola kunci, lisensi, dan policy akses
• apakah fallback ke server mengubah asumsi kepatuhan data

Catatan: On-device mengurangi eksposur transport data, tetapi memperluas permukaan serangan pada endpoint. Untuk model proprietary, perlindungan artefak model dan integritas runtime tetap penting.

3. Biaya infrastruktur vs biaya perangkat

Server terpusat membuat biaya komputasi terkonsolidasi dan lebih mudah diawasi, tetapi biaya operasional bisa naik tajam jika inference berat, traffic tinggi, atau SLA ketat. Sebaliknya, on-device menggeser sebagian biaya ke perangkat pengguna atau ke hardware lokal yang lebih kuat.

Konteks tren seperti perangkat berbasis AI PC atau dev kit dengan akselerator lokal menunjukkan bahwa beberapa beban inferensi kini layak dipindahkan ke endpoint. Namun secara ekonomi, keputusan ini masuk akal hanya jika:

• perangkat target memang memiliki resource yang memadai
• umur pakai perangkat cukup panjang
• penghematan bandwidth atau GPU server benar-benar signifikan
• biaya support heterogenitas perangkat masih terkendali

Kesalahan umum: menganggap on-device selalu lebih murah. Jika tim harus mendukung banyak kelas hardware, melakukan optimasi per platform, dan menangani bug driver/runtime yang berbeda-beda, total biaya engineering bisa melampaui penghematan komputasi server.

4. Utilisasi GPU/NPU dan efisiensi resource

Di server terpusat, Anda bisa mengatur penjadwalan beban kerja, batching, dan autoscaling agar utilisasi akselerator relatif tinggi. Ini sulit dicapai di endpoint karena pengguna bisa menjalankan aplikasi lain, mematikan mode performa, atau berpindah konteks kapan saja.

Di sisi lain, endpoint modern mungkin memiliki NPU atau GPU yang sering menganggur. Menaruh model kecil atau menengah di sana dapat memanfaatkan resource lokal yang sebelumnya tidak terpakai.

Pertanyaan penting:

• Apakah model Anda benar-benar bisa dieksekusi pada NPU/GPU lokal, atau tetap jatuh ke CPU?
• Apakah runtime mendukung operator yang dibutuhkan model?
• Apakah memory footprint model stabil di berbagai perangkat?
• Apakah workload bersifat bursty atau kontinu?

Jangan merancang berdasarkan klaim teoretis akselerator. Uji jalur eksekusi nyata: preload model, inferensi berulang, kondisi baterai, dan skenario multi-aplikasi.

5. Deployment dan update model

Server terpusat unggul untuk update cepat. Anda bisa mengganti model, prompt policy, routing, atau threshold tanpa menunggu aplikasi klien diperbarui. Ini sangat membantu jika:

• model masih sering dieksperimenkan
• Anda butuh rollback cepat
• ada perubahan kebijakan keamanan atau moderation
• perlu A/B test lintas pengguna

On-device menambah kompleksitas karena model adalah artefak yang harus didistribusikan, divalidasi, dan kompatibel dengan runtime lokal. Strategi yang umum diperlukan:

• versioning model yang eksplisit
• cache lokal dengan checksum
• download bertahap dan resumable
• rollback ke model sebelumnya
• feature flag untuk mengaktifkan jalur lokal hanya pada perangkat tertentu

6. Observability dan debugging

Server terpusat memberi visibilitas paling baik: latency histogram, error rate, throughput, saturation, tracing, dan audit log bisa dikumpulkan di satu tempat. Pada on-device, observability lebih terbatas karena:

• telemetri tidak selalu boleh dikirim
• koneksi bisa offline
• pengguna bisa menolak collection telemetry
• perangkat target sangat beragam

Jika Anda memilih on-device, desain observability dari awal. Minimal siapkan:

• kode error terstruktur untuk load model, alloc memory, unsupported ops
• telemetri agregat non-sensitif seperti durasi inferensi dan status fallback
• sampling log untuk perangkat yang mengizinkan diagnostik
• indikator jalur eksekusi: CPU, GPU, NPU, atau fallback server

7. Maintainability jangka panjang

Arsitektur yang baik adalah arsitektur yang masih bisa dipelihara dua tahun lagi. On-device sering terlihat menarik di awal, tetapi menumpuk biaya maintenance jika:

• Anda harus mendukung terlalu banyak OS, driver, dan akselerator
• toolchain konversi model sering berubah
• tim backend dan client tidak punya kontrak antarmuka yang jelas
• mekanisme fallback tidak diuji secara rutin

Server terpusat lebih mudah dijaga konsistensinya, tetapi bisa menjadi bottleneck organisasi jika semua eksperimen dan kapasitas harus melewati satu tim platform.

Tabel Perbandingan Arsitektur Inference AI

Kerangka Keputusan Praktis untuk Tim Engineering

Berikut kerangka yang bisa dipakai saat design review. Jangan mulai dari teknologi; mulai dari karakteristik produk.

1. Tentukan jalur kritis pengguna. Apakah fitur harus merespons dalam hitungan sangat cepat, atau bisa menunggu request backend?
2. Klasifikasikan sensitivitas data. Data mentah, embedding, output, dan log punya tingkat risiko berbeda.
3. Profilkan perangkat target. Bukan hanya satu perangkat lab, tetapi spektrum minimum hingga maksimum.
4. Ukur ukuran model dan jejak memori. Termasuk model file, runtime overhead, dan cache.
5. Rancang fallback. Apa yang terjadi jika akselerator tidak ada, memori habis, atau suhu naik?
6. Definisikan strategi update. Seberapa sering model berubah, dan seberapa aman proses rollback?
7. Tentukan kebutuhan observability. Apa metrik minimum untuk menjaga kualitas produksi?
8. Bandingkan biaya total. Hitung biaya komputasi, bandwidth, support, pengujian lintas perangkat, dan operasional.

Jika lebih dari setengah jawaban mengarah pada privasi tinggi, latensi interaktif, dan konektivitas tidak pasti, jalur on-device layak diprioritaskan. Jika sebagian besar mengarah ke update cepat, konsistensi, dan visibilitas operasional, server terpusat biasanya lebih aman. Jika kebutuhan bercampur per lokasi, edge sering menjadi kompromi terbaik.

Pola Implementasi yang Umum Dipakai

1. Local-first dengan fallback ke server

Ini pola yang sering paling realistis. Aplikasi mencoba inference lokal terlebih dahulu. Jika resource tidak cukup atau model tidak tersedia, request dialihkan ke server.

function runInference(input, deviceState, modelRegistry) {
  if (deviceState.offlineCapable &&
      deviceState.memoryOk &&
      modelRegistry.localModelReady) {
    try {
      return localInference(input)
    } catch (err) {
      logEvent("local_inference_failed", classifyError(err))
    }
  }

  if (deviceState.networkAvailable) {
    return remoteInference(input)
  }

  return degradedResponse("Inference tidak tersedia saat ini")
}

Mengapa pola ini bekerja? Karena ia memisahkan preferensi jalur dari jaminan layanan. Anda bisa mengoptimalkan pengalaman pada perangkat kuat, tanpa memutus dukungan untuk perangkat lemah.

2. Split inference / hybrid pipeline

Tidak semua tahap harus berada di lokasi yang sama. Misalnya:

• pre-processing lokal, inferensi utama di server
• deteksi awal lokal, verifikasi akhir di server
• ranking kasar lokal, reranking mahal di backend

Contoh yang masuk akal: aplikasi desktop melakukan ekstraksi teks dan redaksi data sensitif secara lokal, lalu mengirim teks yang sudah dibersihkan ke layanan terpusat untuk analisis lanjutan.

3. Policy-based routing

Gunakan aturan eksplisit untuk memilih jalur inferensi berdasarkan kelas perangkat, status baterai, jenis data, atau SLA pengguna.

routing_policy:
  - when: data_classification == "sensitif"
    route: local_only
  - when: device_accelerator in ["npu", "gpu"] and memory_gb >= 16
    route: prefer_local
  - when: network_quality == "poor"
    route: local_if_available
  - when: model_version_required == "latest"
    route: remote_only
  - default: remote

Pendekatan ini lebih mudah dipelihara dibanding logika tersembunyi yang tersebar di banyak layer aplikasi.

Contoh Skenario Produk

Asisten coding internal di laptop engineer

Rekomendasi: hybrid, dengan preferensi on-device untuk tugas ringan.

Alasan:

• latensi penting untuk autocomplete atau transformasi kode kecil
• repo internal mungkin sensitif
• perangkat engineer cenderung lebih kuat dibanding perangkat pengguna umum
• fallback ke server tetap dibutuhkan untuk model yang lebih besar atau konteks yang panjang

Analitik kamera di pabrik

Rekomendasi: edge atau on-prem lokal, bukan server terpusat penuh.

Alasan:

• stream video mahal dikirim terus-menerus ke pusat
• latensi keputusan operasional perlu rendah
• konektivitas antar lokasi tidak selalu stabil
• privasi dan kebijakan lokasi sering menuntut pemrosesan lokal

Aplikasi mobile konsumen untuk ringkasan teks

Rekomendasi: tergantung ukuran model dan frekuensi update, tapi server terpusat sering lebih praktis.

Alasan:

• fragmentasi perangkat tinggi
• ukuran aplikasi dan konsumsi baterai sensitif
• fitur ringkasan biasanya tidak memerlukan respons real-time ekstrem
• update model dan guardrail lebih mudah di server

Desktop app enterprise untuk transkripsi rapat internal

Rekomendasi: on-device bila perangkat standar organisasi cukup kuat.

Alasan:

• audio rapat biasanya sensitif
• user menghargai privasi dan kemampuan offline
• workstation enterprise dapat distandardisasi sehingga deployment lebih terkendali

Anti-Pattern yang Sering Terjadi

1. Memaksa semua inference ke on-device karena hardware lokal sedang tren

Perangkat lokal makin kuat memang membuka opsi baru, tetapi tidak semua model dan use case cocok dijalankan di endpoint. Jika model berubah mingguan dan butuh observability ketat, sentralisasi bisa tetap lebih sehat.

2. Mengabaikan heterogenitas perangkat

Demo di satu mesin kuat tidak membuktikan kesiapan produksi. Performa bisa berbeda jauh pada perangkat dengan RAM kecil, akselerator tidak kompatibel, atau batas thermal lebih agresif.

3. Tidak menyiapkan fallback

Arsitektur inference lokal tanpa fallback sering gagal pada kondisi nyata: model belum terunduh, driver bermasalah, memori penuh, atau perangkat masuk mode hemat daya.

4. Menyamakan privasi dengan tidak adanya telemetry

Menghapus observability total membuat debugging hampir mustahil. Solusinya bukan nol telemetry, melainkan telemetry minimal yang aman dan teragregasi.

5. Menaruh model besar di endpoint tanpa strategi distribusi

Jika artefak model besar, proses download, cache eviction, checksum, dan rollback harus dirancang. Tanpa itu, startup lambat dan support ticket akan meningkat.

6. Mengabaikan kontrak antara aplikasi dan model

Input schema, output schema, tokenization, threshold, dan feature flags harus diperlakukan sebagai kontrak. Banyak bug produksi muncul bukan karena model jelek, tetapi karena asumsi antarmuka berubah diam-diam.

Checklist Evaluasi Sebelum Memutuskan

• Apakah latensi interaktif adalah kebutuhan inti?
• Apakah data mentah boleh keluar dari perangkat?
• Apakah perangkat target cukup seragam?
• Apakah model stabil atau sering diupdate?
• Apakah tim punya kemampuan observability untuk inference tersebar?
• Apakah ada fallback yang teruji untuk mode resource rendah?
• Apakah total biaya support lintas perangkat masuk akal?
• Apakah ada alasan kuat memilih edge sebagai kompromi?

Kesimpulan

Memilih arsitektur inference AI on-device vs server terpusat sebaiknya dilakukan dengan kerangka keputusan yang eksplisit, bukan mengikuti tren hardware atau preferensi organisasi. Kekuatan perangkat lokal modern, termasuk konteks AI PC dan dev kit seperti AMD Ryzen AI Halo AI Dev Kit, memang membuat inference lokal lebih menarik. Tetapi keputusan yang tepat tetap bergantung pada kombinasi latensi, privasi, biaya total, utilisasi akselerator, deployment, observability, dan maintainability.

Untuk banyak tim, jawaban terbaik bukan pilihan biner. Pola hybrid—local-first dengan fallback ke server, atau split pipeline—sering memberi hasil paling seimbang. Yang penting, desain arsitektur Anda harus siap menghadapi kenyataan produksi: perangkat berbeda-beda, model berubah, dan operasional jangka panjang hampir selalu lebih rumit daripada prototype.