Server AI untuk Universitas dan Riset: Cara
September 30, 2026
- Srengseng Sawah, Jagakarsa Jakarta Selatan
- Sen - Jum: 07:00 -17:00WIB
RAG membuat LLM mampu menjawab pertanyaan berdasarkan dokumen dan knowledge base perusahaan. Di balik jawaban tersebut, ada proses retrieval yang harus menemukan informasi relevan dalam waktu singkat. Karena itu, vector database menjadi salah satu komponen penting dalam arsitektur AI berbasis RAG.
Lalu, berapa besar server yang sebenarnya dibutuhkan? Jawabannya tidak cukup hanya dengan melihat jumlah dokumen. Vector database untuk RAG membutuhkan perhitungan berdasarkan jumlah vector, dimensi embedding, ukuran index, RAM, storage, CPU, GPU, latency, hingga jumlah pengguna yang mengakses sistem secara bersamaan.
Sebelum menentukan kapasitas server, mari pahami terlebih dahulu fungsi vector database dalam RAG. Komponen ini membantu sistem menyimpan representasi numerik dari informasi dan menemukan data yang paling relevan berdasarkan kemiripan.
Dalam alur RAG, sistem memecah dokumen menjadi beberapa chunk. Selanjutnya, embedding model mengubah setiap chunk menjadi vector. Database kemudian menyimpan vector bersama metadata, seperti judul dokumen, kategori, tanggal, atau sumber informasi.
Ketika pengguna mengirim pertanyaan, aplikasi membuat embedding dari pertanyaan tersebut. Setelah itu, vector search mencari data yang memiliki kemiripan paling tinggi. Sistem mengambil beberapa hasil teratas dan meneruskannya sebagai konteks kepada LLM. Dengan alur tersebut, RAG mampu menghubungkan LLM dengan data perusahaan tanpa harus melatih ulang model setiap kali isi dokumen berubah.
Jumlah dokumen memang menjadi salah satu faktor utama, tetapi angka tersebut belum cukup untuk menentukan kebutuhan hardware. Satu dokumen PDF dapat menghasilkan puluhan atau bahkan ratusan chunk, tergantung metode chunking yang digunakan.
Selain itu, dimensi embedding ikut menentukan ukuran setiap vector. Kemudian, index, metadata, cache, log, dan cadangan kapasitas juga mengambil ruang pada server. Karena itu, tim IT sebaiknya menghitung keseluruhan workload sebelum membeli hardware. Pendekatan tersebut membantu perusahaan menghindari dua kondisi sekaligus: kapasitas terlalu kecil untuk kebutuhan produksi atau kapasitas terlalu besar sebelum sistem benar-benar membutuhkannya.
Perhitungan awal bisa dimulai dari tiga komponen, yaitu jumlah vector, dimensi embedding, dan ukuran setiap nilai numerik. Rumus sederhananya adalah:
Jumlah vector × dimensi embedding × ukuran data per nilai
Sebagai contoh, 1 juta vector dengan 1.536 dimensi pada FP32 membutuhkan sekitar 6,14 GB untuk menyimpan data vector mentah.
Namun, angka tersebut belum menggambarkan kebutuhan server sebenarnya. Database masih membutuhkan ruang untuk index, metadata, cache, log, sistem operasi, serta aplikasi RAG. Oleh sebab itu, hasil perhitungan data mentah sebaiknya tidak menjadi satu-satunya dasar ketika menentukan RAM server dan storage.
Jumlah chunk menentukan berapa banyak vector yang masuk ke database. Karena itu, perusahaan perlu mengetahui karakter dokumen sebelum membuat estimasi kapasitas. Sebagai ilustrasi, perusahaan mempunyai 100.000 dokumen. Jika setiap dokumen menghasilkan rata-rata 20 chunk, sistem akan menghasilkan sekitar 2 juta vector. Sebaliknya, rata-rata 50 chunk per dokumen akan menghasilkan sekitar 5 juta vector.
Dengan demikian, ukuran chunk memberikan pengaruh langsung terhadap kapasitas vector database untuk RAG. Tim dapat melakukan pengujian terhadap sebagian dokumen terlebih dahulu untuk mendapatkan rata-rata chunk yang lebih realistis.
Dimensi embedding juga berpengaruh terhadap kebutuhan storage. Semakin banyak dimensi yang dimiliki sebuah vector, semakin banyak nilai numerik yang perlu disimpan. Sebagai gambaran, 1 juta vector dengan 768 dimensi pada FP32 membutuhkan sekitar 3,07 GB data mentah. Sementara itu, 1 juta vector dengan 3.072 dimensi membutuhkan sekitar 12,29 GB. Karena itu, pemilihan embedding model perlu mempertimbangkan kualitas retrieval dan kebutuhan resource secara bersamaan. Model dengan dimensi lebih besar tidak otomatis menjadi pilihan terbaik untuk setiap use case.
Setelah jumlah vector diketahui, langkah berikutnya adalah menghitung kebutuhan RAM dan storage. Kedua komponen tersebut mempunyai fungsi berbeda dalam sistem RAG. RAM membantu database menjalankan index, cache, dan proses pencarian dengan cepat. Sebaliknya, storage menampung vector, index, metadata, snapshot, log, serta data pendukung lainnya.
Untuk kebutuhan yang memerlukan akses data cepat, storage NVMe dapat menjadi pilihan. Terlebih lagi, proses ingestion, pembangunan index, dan aktivitas database tertentu dapat menghasilkan beban I/O yang cukup tinggi. Namun, perusahaan tidak sebaiknya mengalokasikan seluruh RAM hanya untuk vector database. Sistem operasi, API, embedding service, monitoring, dan aplikasi RAG tetap membutuhkan resource.
GPU tidak selalu menjadi komponen wajib dalam database vector. Sistem dengan kebutuhan vector search tertentu masih dapat berjalan menggunakan CPU. Akan tetapi, GPU menjadi lebih relevan ketika server juga menjalankan proses embedding, akselerasi vector search, atau LLM inference. Misalnya, perusahaan menjalankan chatbot internal dengan LLM lokal. Dalam skenario tersebut, server harus menangani vector database sekaligus proses inference. Akibatnya, kebutuhan GPU dan VRAM menjadi bagian penting dalam capacity planning.
Untuk kebutuhan tersebut, Sparta menyediakan GPU Server Indonesia dan NVIDIA GPU Server Indonesia. Pilihan NVIDIA H100 Server Indonesia, NVIDIA H200 Server Indonesia, NVIDIA B200 Server Indonesia, NVIDIA L40S Server Indonesia, serta NVIDIA RTX PRO Server dapat disesuaikan dengan kebutuhan model dan workload. Jadi, pemilihan GPU sebaiknya mengikuti hasil benchmark. Selain kapasitas VRAM, tim juga perlu melihat kemampuan komputasi, jumlah pengguna, batch size, context length, dan target throughput.
CPU tetap memegang peranan penting meskipun GPU menangani proses AI. Komponen tersebut menjalankan berbagai proses seperti document parsing, chunking, API, metadata, database, dan aktivitas aplikasi lainnya. Sementara itu, RAM menampung index, cache, database, dan service pendukung. Jika perusahaan menjalankan beberapa service pada satu server, kebutuhan memory tentu ikut meningkat.
Selain spesifikasi hardware, perhatikan pula concurrency. Seratus pengguna yang mengirim pertanyaan secara bersamaan memberikan beban berbeda dibandingkan seratus pengguna yang mengakses sistem secara bergantian. Karena itu, pengujian sebaiknya menggunakan skenario peak workload. Dengan cara tersebut, perusahaan dapat melihat kebutuhan resource ketika sistem menghadapi kondisi tersibuk.
Arsitektur RAG sederhana dapat menjalankan database dan aplikasi dalam satu server. Namun, perusahaan biasanya memisahkan komponen ketika sistem berkembang. Misalnya, vector database berjalan pada node database, embedding service berada pada node compute, sedangkan LLM berjalan pada GPU Server. Dalam kondisi tersebut, jaringan menghubungkan seluruh komponen dan ikut menentukan latency.
Karena itu, perencanaan Network & Internet Services perlu mengikuti arsitektur aplikasi. Sparta juga menyediakan Mikrotik & Routing Solutions untuk kebutuhan networking dan routing. Untuk lingkungan yang lebih besar, perusahaan dapat menggabungkan kebutuhan tersebut dengan layanan Infrastruktur & Networking serta Server & Data Center.
Tabel berikut memberikan gambaran awal untuk capacity planning. Namun, perusahaan tetap perlu melakukan benchmark karena setiap model, database, dan workload mempunyai karakter berbeda.
| Skala | Jumlah Vector | RAM | Storage | GPU |
|---|---|---|---|---|
| PoC | <500 ribu | 32–64 GB | NVMe 1 TB | Opsional |
| Internal kecil | 500 ribu–5 juta | 64–128 GB | NVMe 1–2 TB | Opsional |
| Produksi menengah | 5–20 juta | 128–256 GB | NVMe 2–4 TB | Sesuai workload |
| Enterprise | >20 juta | 256 GB+ | Enterprise storage | Sesuai kebutuhan |
Sebagai contoh, 20 juta vector berdimensi 1.536 dengan FP32 membutuhkan sekitar 122,88 GB hanya untuk data vector mentah. Setelah itu, perusahaan masih harus menyediakan kapasitas untuk index, metadata, cache, sistem operasi, dan pertumbuhan data. Jika server juga menjalankan LLM inference, kebutuhan GPU perlu dihitung secara terpisah. Dengan begitu, perusahaan tidak mencampurkan kebutuhan database dengan kebutuhan komputasi model.
Setelah kapasitas data diketahui, perusahaan perlu menentukan metode index. Struktur ini membantu sistem mencari vector tanpa membandingkan seluruh data secara satu per satu. Untuk dataset kecil, pencarian sederhana mungkin sudah memadai. Namun, jumlah vector yang besar membutuhkan pendekatan yang lebih efisien. Metode seperti HNSW dan IVF dapat menjadi opsi untuk dievaluasi sesuai karakter database.
Pemilihan metode tersebut perlu melihat beberapa faktor sekaligus, seperti ukuran dataset, dimensi vector, target recall, kebutuhan RAM, latency, dan waktu pembangunan index. Dengan demikian, perusahaan tidak sebaiknya memilih metode index hanya karena metode tersebut populer. Pengujian dengan data dan pola query nyata akan memberikan gambaran yang lebih akurat.
Pada tahap proof of concept, perusahaan dapat menjalankan vector database, embedding service, dan LLM pada satu server. Cara ini membuat arsitektur lebih sederhana dan mempercepat proses pengujian. Namun, kondisi produksi bisa membutuhkan pendekatan berbeda. Ketika trafik meningkat, pemisahan service membantu setiap komponen memperoleh resource yang lebih terkontrol.
Sebagai contoh, perusahaan dapat menempatkan vector database pada server CPU dengan RAM besar. Sementara itu, GPU Server menjalankan LLM inference. Embedding service kemudian dapat menggunakan node tersendiri apabila proses ingestion berlangsung secara intensif.
Pendekatan tersebut juga membuat scaling lebih fleksibel. Jika database membutuhkan RAM tambahan, perusahaan tidak perlu otomatis menambah GPU. Untuk kebutuhan AI enterprise, Sparta menyediakan Server AI untuk LLM & Generative AI dan Server Machine Learning & Deep Learning.
Setelah server berjalan, monitoring menjadi bagian penting dari operasional. Tim IT perlu mengawasi CPU, RAM, storage, GPU, latency, throughput, query rate, dan error rate. Selain itu, ukuran vector database perlu dipantau secara berkala. Data baru yang terus masuk dapat meningkatkan ukuran index dan kebutuhan storage. Oleh karena itu, tim perlu membuat proyeksi pertumbuhan agar upgrade tidak terlambat.
Sparta menyediakan Monitoring & Operations serta High Availability & Recovery untuk kebutuhan infrastruktur yang membutuhkan pemantauan dan ketersediaan layanan. Selain monitoring, perusahaan juga perlu menyiapkan backup. Database, metadata, konfigurasi, model, serta data penting lainnya harus mempunyai strategi pemulihan yang jelas.
Pertumbuhan jumlah dokumen tidak otomatis berarti perusahaan harus langsung membeli server baru. Sebaliknya, keputusan upgrade sebaiknya mengikuti data penggunaan. Misalnya, RAM terus berada pada tingkat tinggi, storage mendekati kapasitas maksimum, atau latency meningkat ketika jumlah pengguna bertambah. Kondisi tersebut dapat menunjukkan bahwa server membutuhkan optimasi atau resource tambahan.
Jika vector database menjadi bottleneck, perusahaan dapat meningkatkan RAM, storage, atau melakukan optimasi index. Sementara itu, kebutuhan GPU baru lebih relevan ketika LLM inference menjadi sumber hambatan.
Untuk perusahaan yang masih menguji workload, Sparta menyediakan pilihan Sewa Server Dell PowerEdge, Sewa Server HP ProLiant / HPE, Sewa Server Huawei, dan Sewa Server Lenovo. Dengan opsi tersebut, perusahaan dapat melakukan pengujian kapasitas sebelum memutuskan konfigurasi hardware permanen.
Sistem RAG jarang berhenti pada jumlah data saat pertama kali diluncurkan. Seiring waktu, perusahaan dapat menambahkan dokumen, departemen, pengguna, dan knowledge base baru. Karena itu, capacity planning sebaiknya memasukkan proyeksi pertumbuhan. Misalnya, jika database bertambah 20% setiap tahun, perusahaan perlu memperhitungkan tambahan vector, index, metadata, dan kebutuhan backup.
Di sisi lain, perusahaan tidak perlu langsung membeli kapasitas terbesar. Infrastruktur yang terlalu besar dapat membuat investasi awal kurang efisien. Sebaliknya, kapasitas yang terlalu kecil dapat menghambat performa ketika sistem mulai berkembang. Pendekatan yang lebih seimbang adalah memulai dari benchmark, menetapkan headroom, lalu menyiapkan jalur ekspansi.
Pada akhirnya, vector database untuk RAG membutuhkan perencanaan yang lebih luas daripada sekadar menentukan jenis database. Jumlah vector, dimensi embedding, metode index, RAM, storage, CPU, GPU, networking, latency, dan concurrency saling memengaruhi performa sistem.
Karena itu, mulailah dengan dataset nyata dan lakukan pengujian menggunakan pola penggunaan yang mendekati kondisi produksi. Hasil benchmark kemudian dapat membantu tim menemukan bottleneck sekaligus menentukan kapasitas hardware yang lebih tepat. Sparta menyediakan solusi mulai dari Pengadaan Server AI Indonesia, Server, Storage, dan Networking hingga kebutuhan Cloud Services, Software & System, serta Rental, Maintenance & Lifecycle.
Jika perusahaan sedang membangun RAG untuk chatbot internal, pencarian dokumen, knowledge base, atau LLM enterprise, konsultasikan kebutuhan workload terlebih dahulu. Dengan begitu, konfigurasi server dapat mengikuti kebutuhan saat ini sekaligus memberikan ruang untuk pertumbuhan sistem.WhatsApp kami +62 878‑2224‑1000
Tidak wajib, tetapi vector database umum digunakan untuk menyimpan dan mencari embedding pada aplikasi RAG.
Kebutuhan RAM bergantung pada jumlah vector, dimensi embedding, index, metadata, cache, dan concurrency.
Tidak selalu. GPU terutama membantu proses embedding, akselerasi tertentu, dan LLM inference.
Ya. NVMe dapat mendukung kebutuhan storage untuk vector, index, metadata, dan data pendukung.
Multi-server cocok ketika database, embedding, LLM, atau trafik sudah membebani satu node.
Mulai dari jumlah vector, dimensi embedding, index, concurrency, target latency, lalu validasi melalui benchmark.