Prerequisites
Persyaratan sistem untuk menjalankan FREMIS-N — OS, hardware, GPU opsional, dan dependensi.
Sebelum menjalankan FREMIS-N, ada dua keputusan utama yang perlu dibuat: topologi deployment (standalone atau cluster) dan runtime (CPU, GPU CUDA, GPU TensorRT, atau VortexRT). Kedua keputusan ini saling memengaruhi dan sebaiknya dipikirkan bersama.
Jika host Anda belum memiliki Docker dan NVIDIA driver, pasang terlebih dahulu melalui panduan Install Dependencies. Halaman ini tidak menduplikasi instruksi tersebut.
Persyaratan Sistem
| Kebutuhan | Detail |
|---|---|
| Sistem Operasi | Linux (Ubuntu 22.04 atau lebih baru) |
| Docker Engine | 20.10 atau lebih baru |
| Database | PostgreSQL (dapat berjalan sebagai Docker container) |
| License Credentials | Access key dan secret key dari Nodeflux |
| RAM | Minimum 8 GB; 16 GB atau lebih direkomendasikan untuk produksi |
| Disk | Cukup untuk data enrollment (bergantung volume; lihat bagian Sizing) |
Untuk Runtime GPU
Lewati bagian ini jika Anda berencana menjalankan runtime CPU saja.
| Kebutuhan | Detail |
|---|---|
| GPU NVIDIA | Compatible dengan CUDA (T4, RTX 2080, RTX 3090, A100, dll.) |
| NVIDIA Driver | Versi 525 atau lebih baru |
| NVIDIA Container Toolkit | Dibutuhkan untuk flag --gpus |
Pilih Topologi Deployment
FREMIS-N mendukung dua topologi: standalone dan cluster. Keduanya mengekspos API yang identik — aplikasi yang memanggil FREMIS-N tidak perlu mengetahui topologi yang sedang berjalan. Perbedaannya ada di bagaimana data disimpan dan di-compute.
Standalone
Dalam mode standalone, semua data enrollment dan seluruh proses komputasi — ekstraksi embedding, pencarian kemiripan — berjalan dalam satu node. Tidak ada koordinasi antar mesin. Ini membuat deployment, pemantauan, dan pemeliharaan menjadi jauh lebih sederhana.
Mode ini cocok untuk:
- Deployment baru yang belum memiliki gambaran volume data jangka panjang
- Jumlah enrollment di bawah ratusan ribu identitas
- QPS recognition yang relatif rendah hingga menengah
- Tim operasional yang ingin kompleksitas infrastruktur minimal
Cluster
Dalam mode cluster, data enrollment dibagi menjadi 256 partition secara internal. Partition-partition ini kemudian di-assign ke beberapa node — misalnya dua node masing-masing memegang 128 partition. Setiap node hanya bertanggung jawab atas subset data miliknya.
Di depan node-node ini berdiri satu coordinator: komponen yang menerima semua permintaan dari klien, menentukan node mana yang bertanggung jawab atas data yang diminta, dan merutekan permintaan tersebut. Bagi klien, coordinator terlihat persis seperti node biasa — API-nya identik.
Saat ini FREMIS-N hanya mendukung mode sharding (tiap partition hanya ada di satu node). Replikasi partition ke beberapa node belum didukung — pastikan strategi ketersediaan tinggi Anda memperhitungkan hal ini.
Kapan Pilih yang Mana?
| Pertimbangan | Pilih Standalone | Pilih Cluster |
|---|---|---|
| Jumlah enrollment | Di bawah ~500 ribu | Di atas ~500 ribu, atau proyeksi pertumbuhan tinggi |
| Target QPS | Rendah hingga menengah | Tinggi, atau perlu skalabilitas horizontal |
| Kompleksitas operasional | Minimal | Tim dengan pengalaman mengelola sistem terdistribusi |
| Anggaran infrastruktur | Satu mesin | Beberapa mesin + jaringan privat antar node |
| Tahap proyek | Proof of concept, pilot, skala kecil | Produksi skala penuh, jutaan enrollment |
Pilih Runtime: CPU vs GPU
FREMIS-N tersedia dalam beberapa varian runtime yang menentukan bagaimana komputasi embedding dan pencarian dilakukan. Pilihan runtime memengaruhi throughput, latency, dan kebutuhan hardware secara signifikan.
Runtime CPU
Runtime CPU menjalankan seluruh pipeline — ekstraksi embedding dan pencarian kemiripan — menggunakan unit pemrosesan standar tanpa akselerasi GPU.
Keunggulan:
- Tidak membutuhkan hardware khusus; berjalan di hampir semua server modern
- Biaya infrastruktur lebih rendah
- Lebih mudah di-provision, di-scale secara vertikal, dan di-debug
- Cocok untuk environment tanpa GPU (cloud instance umum, on-premise server standar)
Keterbatasan:
- Throughput lebih rendah dibandingkan varian GPU
- Latency pencarian cenderung lebih tinggi pada database besar
- Untuk volume enrollment sangat besar atau QPS tinggi, satu node CPU mungkin tidak mencukupi
Cocok untuk: Volume enrollment rendah hingga menengah (di bawah ~100 ribu identitas), QPS rendah, environment tanpa akses GPU, atau tahap pengembangan dan testing.
Runtime GPU (CUDA)
Runtime GPU berbasis CUDA memanfaatkan akselerasi GPU NVIDIA untuk mempercepat komputasi embedding dan operasi pencarian kemiripan secara paralel masif.
Keunggulan:
- Throughput jauh lebih tinggi — dapat menangani lebih banyak recognition request per detik
- Latency per-request lebih rendah, terutama untuk database besar
- Cocok untuk skenario real-time dengan banyak stream kamera simultan
Keterbatasan:
- Membutuhkan GPU NVIDIA yang kompatibel dengan CUDA
- Biaya hardware dan lisensi lebih tinggi
- Diperlukan driver dan runtime CUDA yang tepat di host
Cocok untuk: Deployment skala menengah hingga besar, recognition real-time dari beberapa stream kamera, QPS menengah hingga tinggi.
Runtime GPU (TensorRT)
Varian TensorRT mengoptimalkan model inferensi menggunakan mesin TensorRT dari NVIDIA, yang menghasilkan throughput lebih tinggi dan latency lebih rendah dibandingkan runtime CUDA standar pada hardware yang sama.
Keunggulan:
- Performa inferensi lebih tinggi daripada CUDA standar
- Latency lebih konsisten dan dapat diprediksi
- Cocok untuk deployment yang membutuhkan SLA latency ketat
Keterbatasan:
- Membutuhkan GPU NVIDIA yang didukung TensorRT
- Proses setup sedikit lebih kompleks (model perlu dikompilasi untuk arsitektur GPU spesifik)
- Tidak semua GPU mendukung semua fitur TensorRT
Cocok untuk: Produksi skala besar dengan kebutuhan throughput dan latency tertinggi, deployment di mana performa GPU harus dimaksimalkan.
Runtime VortexRT
VortexRT adalah runtime akselerasi inferensi yang dikembangkan oleh Nodeflux. Runtime ini dioptimasi khusus untuk workload FREMIS-N dan dapat memberikan efisiensi komputasi lebih baik pada konfigurasi hardware tertentu.
Untuk informasi ketersediaan dan kompatibilitas VortexRT dengan infrastruktur Anda, hubungi tim Nodeflux.
Cocok untuk: Deployment yang sudah berkoordinasi langsung dengan tim Nodeflux dan membutuhkan optimasi performa lanjutan.
Tabel Perbandingan Runtime
| Aspek | CPU | GPU (CUDA) | GPU (TensorRT) | VortexRT |
|---|---|---|---|---|
| Throughput | Rendah–Menengah | Tinggi | Sangat Tinggi | Tergantung konfigurasi |
| Latency per-request | Lebih tinggi | Rendah | Sangat rendah | Dioptimasi |
| Hardware yang dibutuhkan | Server standar | GPU NVIDIA (CUDA) | GPU NVIDIA (TensorRT) | Konsultasi Nodeflux |
| Kompleksitas setup | Rendah | Menengah | Menengah–Tinggi | Menengah |
| Biaya infrastruktur | Lebih rendah | Menengah–Tinggi | Tinggi | Bervariasi |
| Kapan dipilih | Volume rendah, tanpa GPU | Skala menengah–besar | Produksi skala penuh | Koordinasi dengan Nodeflux |
Sizing & Capacity Planning
Tidak ada angka "universal" yang berlaku untuk semua deployment — kapasitas yang dibutuhkan sangat bergantung pada kombinasi beberapa variabel. Panduan berikut memberikan titik awal; selalu validasi dengan benchmark menggunakan data nyata dari lingkungan Anda sendiri.
Variabel Utama
Jumlah enrollment total adalah faktor terbesar yang memengaruhi memory yang dibutuhkan dan latency pencarian. Semakin banyak identitas yang terdaftar, semakin besar ruang yang perlu di-scan untuk setiap recognition request.
Target QPS (Queries Per Second) menentukan throughput yang dibutuhkan sistem secara keseluruhan. QPS tinggi — misalnya dari banyak kamera yang berjalan simultan — membutuhkan runtime GPU atau konfigurasi cluster.
Latency yang dapat diterima berkaitan erat dengan pilihan runtime. Skenario access control real-time memiliki kebutuhan berbeda dibandingkan skenario pencarian forensik yang toleran terhadap latency lebih tinggi.
Ketersediaan GPU sering menjadi faktor penentu praktis, terlepas dari kebutuhan teknis murni.
Aturan Praktis
| Skenario | Rekomendasi Awal |
|---|---|
| Di bawah ~100 ribu enrollment, QPS rendah | Single-node CPU biasanya mencukupi |
| 100 ribu – 1 juta enrollment, QPS menengah | Single-node GPU (CUDA atau TensorRT) |
| Di atas ~1 juta enrollment, atau QPS tinggi | Pertimbangkan cluster; GPU sangat direkomendasikan |
| Banyak keyspace dengan enrollment kecil masing-masing | Single-node GPU masih bisa menangani, pastikan memory mencukupi |
| Pertumbuhan enrollment cepat dan tidak pasti | Mulai standalone GPU, rancang migrasi ke cluster sejak awal |
Angka-angka di atas adalah titik awal, bukan jaminan. Jalankan benchmark dengan dataset nyata — termasuk pola QPS peak dari skenario nyata — sebelum menentukan spesifikasi produksi final.
Memory & Storage
Setiap embedding wajah membutuhkan ruang penyimpanan yang proporsional. Satu identitas dengan beberapa variasi enrollment menggunakan lebih banyak ruang daripada satu identitas dengan satu foto. Pastikan node memiliki memory yang memadai untuk memuat data operasional, bukan hanya storage untuk menyimpannya.
Untuk cluster, total kapasitas storage didistribusikan ke seluruh node — setiap node hanya perlu menyimpan data untuk partition yang menjadi tanggung jawabnya.
Pertimbangan Jaringan untuk Cluster
Dalam mode cluster, coordinator perlu berkomunikasi dengan setiap node untuk setiap recognition request. Latency jaringan antar node secara langsung berkontribusi pada latency akhir yang dirasakan klien.
Rekomendasi: Jalankan semua node coordinator dan data dalam satu data center atau private network dengan latency antar node di bawah 1 ms. Hindari menempatkan node di lokasi geografis yang berbeda atau melewati jaringan publik tanpa optimasi.
Wizard Pemilihan Topologi
Ikuti langkah-langkah di bawah untuk sampai pada keputusan deployment yang tepat.
Estimasi Jumlah Enrollment
Berapa identitas yang akan di-enroll dalam 6–12 bulan ke depan? Jika jawabannya di atas ~500 ribu, atau Anda mengantisipasi pertumbuhan yang cepat dan tidak pasti, pertimbangkan cluster sejak awal — migrasi dari standalone ke cluster di kemudian hari membutuhkan perencanaan yang matang.
Tentukan Target QPS dan Toleransi Latency
Berapa banyak recognition request per detik yang perlu ditangani sistem pada puncak beban? Apakah skenario Anda sensitif terhadap latency (access control real-time) atau lebih toleran (pencarian retrospektif)? QPS tinggi atau latency ketat hampir selalu mengarah ke pilihan GPU.
Cek Ketersediaan Hardware
Apakah infrastruktur Anda memiliki GPU NVIDIA yang kompatibel? Jika ya, pilih runtime GPU (CUDA atau TensorRT). Jika tidak, mulai dengan CPU dan evaluasi ulang saat volume tumbuh.
Pilih Topologi
Dari jawaban tiga langkah di atas: enrollment kecil + QPS rendah → standalone CPU. Enrollment menengah + QPS menengah → standalone GPU. Enrollment besar atau QPS tinggi → cluster dengan GPU.
Validasi dengan Benchmark
Jalankan load test dengan dataset representatif sebelum go-live. Ukur latency pada QPS target dan pastikan sistem berperilaku sesuai ekspektasi sebelum data produksi masuk.
Selanjutnya
Setelah memutuskan topologi dan runtime, lanjutkan ke halaman instalasi untuk perintah Docker konkret:
- Installation — jalankan FREMIS-N standalone atau cluster
- Services & Ports — port dan service yang diekspos
- Configuration Reference — referensi lengkap semua parameter
Pre-requisite Installation
Panduan langkah demi langkah memasang dan mengonfigurasi FREMIS-N dengan Docker — dari prerequisites, instalasi, services & ports, hingga referensi konfigurasi lengkap.
Installation
Walkthrough Docker untuk menjalankan FREMIS-N standalone atau cluster — perintah konkret, image runtime, dan setup coordinator.