Apakah memungkinkan membangun server LLM self-hosted untuk 300 pengguna?

• Ringkasan pertanyaan dan jawaban yang diposting di subreddit Reddit /r/ollama
• Sebagai administrator sistem di firma hukum beranggotakan 300 orang, ingin menyediakan alat penulisan dan koreksi dokumen berbasis AI mirip ChatGPT untuk seluruh karyawan
• Demi melindungi informasi sensitif seperti PII, sedang mempertimbangkan meng-host LLM langsung di server internal alih-alih memakai layanan eksternal, dengan kontrol akses seperti login, 2FA, VPN, dan sebagainya
• Pertanyaan utama
  • Apakah server LLM yang dibangun sendiri benar-benar bisa mendukung 300+ pengguna?
  • Awalnya diperkirakan beberapa PC+GPU akan cukup, tetapi apakah perkiraan itu terlalu meremehkan kebutuhan nyata?
  • Apakah pembuatan/pengelolaan pengguna bisa menjadi beban besar?
  • Apakah ada pertimbangan penting yang terlewat?
• Bukan ahli di bidang LLM, jadi mencari saran yang realistis tentang skalabilitas, beban operasional, dan kelayakan implementasi

Ringkasan jawaban utama

1. Batasan hardware, performa, dan biaya

• Jika mengharapkan level model komersial (mis. ChatGPT), dibutuhkan klaster GPU mahal bernilai ratusan ribu hingga jutaan dolar (perkiraan $200,000~$1,000,000+)
• Jika diturunkan ke model open source (kelas 30B~70B parameter), perlu menerima penurunan performa (latensi, kualitas hasil). Bahkan menangani 10~40 pengguna bersamaan pun bisa menjadi batas
• Direkomendasikan mengasumsikan kurang dari 10 pengguna bersamaan dan memperluas kapasitas secara bertahap dengan menambah server
• Dibanding lingkungan lokal, menyewa GPU cloud bisa lebih ekonomis dan fleksibel

2. Disarankan PoC (pilot) dan pendekatan bertahap

• Disarankan membangun PoC (pilot) dengan 1 server + 1 GPU terlebih dahulu, lalu mengukur skenario kerja nyata dan beban sebelum diperluas
• Saat ada banyak permintaan serentak, sistem antrean wajib; konkurensi pengguna nyata mungkin bukan 300 orang, melainkan sekitar 10~30 orang
• Dalam jangka pendek, eksperimen bisa dilakukan dengan model kecil (3B~13B parameter) + workstation

3. Opsi cloud, hybrid, dan alternatif

• Mengusulkan struktur hybrid yang menghubungkan LLM berbasis cloud (API, VPS, Azure, AWS Bedrock, dll.) dengan infrastruktur internal agar sesuai kebutuhan keamanan
• Jika self-hosting, beban keamanan, performa, dan biaya besar; secara praktis ChatGPT Enterprise/Teams, Microsoft Copilot Studio, dan solusi komersial serupa bisa lebih efisien
• Persyaratan keamanan untuk data hukum/PII wajib ditinjau dengan saksama

4. Isu operasional, manajemen, dan teknis lainnya

• Manajemen pengguna/autentikasi: bisa disederhanakan lewat integrasi AD, OAuth, atau autentikasi buatan sendiri
• Pemilihan/tuning model: disarankan menguji model open source kecil-menengah yang sesuai kebutuhan nyata (koreksi dokumen, dll.) seperti LLama, Deepseek, Gemma, Qwen, dan lainnya
• Perlu meninjau kemungkinan adopsi solusi tambahan seperti RAG, caching, load balancing, dll.
• Perlu mendefinisikan skenario penggunaan nyata dan memverifikasi anggaran/ROI melalui PoC

Rangkuman jawaban perwakilan

ithkuil

• Dibanding model komersial, model open source memiliki kesenjangan performa besar, dan untuk skala 300 orang mungkin membutuhkan hardware bernilai ratusan ribu dolar
• Bisa berharap ada kemajuan hardware dan model terbuka dalam 2 tahun ke depan

SlimeQ

• Mulai dari skala kecil dengan satu instance + antrean, lalu perluas bertahap saat penggunaan meningkat
• Tidak mungkin 300 orang memakai secara bersamaan; ukur penggunaan nyata dulu baru putuskan perluasan

Ok-Internal9317

• Pengguna serentak yang nyata bisa jadi kurang dari 10 orang, dan 4~5 GPU mungkin sudah cukup
• Dalam jangka panjang, biaya API bisa lebih ekonomis dibanding hardware sendiri

dyoh777

• Bisa membuat demo sederhana dengan Ollama+WebUI, tetapi kualitas model adalah faktor penting

careful-monkey

• Mac Studio + RAM besar dapat dipakai menjalankan model kecil, dengan kecepatan sekitar 20 token/detik

tshawkins

• Merekomendasikan solusi berbasis SaaS seperti Microsoft Copilot Studio, yang terintegrasi dalam Power Platform

roman_fyseek, Cergorach, Space__Whiskey

• Batas VRAM model: 1 sesi = 1 GPU, sehingga 300 sesi bersamaan memerlukan 300 GPU
• Secara realistis dibutuhkan pembatasan koneksi simultan, caching, dan arsitektur hybrid

Siderox, SandboChang, unrulywind

• Disarankan bereksperimen dari server kecil lewat PoC (mis. 1~2 orang/model, cek kecocokan untuk pekerjaan nyata) lalu memperluas secara bertahap
• Setelah skenario nyata didefinisikan dan benchmark dilakukan, anggaran serta ROI perlu diverifikasi

Little_Marzipan_2087, morosis1982, Daemonero

• Menyewa GPU cloud lebih murah dan skalabel, serta merupakan solusi yang sering digunakan
• Dengan mempertimbangkan beban operasi dan pemeliharaan, pemanfaatan cloud lebih direkomendasikan daripada investasi hardware

CtiPath, alew3, faldore, Wheynelau

• Merekomendasikan framework server LLM open source berperforma tinggi seperti vLLM, OpenWebUI, TGI, sglang, dll.
• Disarankan membangun arsitektur queue + load balancer

Lainnya

• Isu keamanan/hukum: bahkan saat memakai cloud, hal-hal seperti lokasi data, enkripsi, dan kepatuhan regulasi tetap harus ditinjau secara ketat
• Disebutkan berbagai opsi hardware seperti Mac Studio, RTX 6000 Pro, 4090, dll.
• Ada kemungkinan meminimalkan beban dengan caching, RAG, pembatasan context, offload, dll.

Ringkasan kesimpulan

• Server LLM self-hosted paling realistis jika dimulai dari pilot kecil (PoC), lalu skala pengguna nyata/kebutuhan/performa/biaya divalidasi bertahap
• Menangani 300 pengguna secara bersamaan berarti menanggung biaya hardware dan operasional yang besar; bergantung pada kebutuhan dan anggaran, cloud, hybrid, atau solusi komersial bisa lebih tepat
• Pada akhirnya, perlu mempertimbangkan secara menyeluruh faktor seperti keamanan, biaya, pengalaman pengguna, dan pemeliharaan

[xodnrdl201]

Sepertinya Anda menetapkan standar kemampuan penalaran yang dibutuhkan untuk pekerjaan yang diproses oleh 300 pengguna terlalu luas. Kalau memang ingin mencakup dari pengetahuan umum yang sangat dasar sampai makalah dan topik lanjutan, pendekatan seperti itu memang masuk akal. Namun jika melihat tingkat tugas yang benar-benar perlu diproses dalam pekerjaan nyata, sebagian besar kemungkinan bisa ditangani jika memakai model sekitar 30b yang dipasangkan dengan RAG. Bukankah skalanya jadi terlalu besar karena Anda mencoba menaikkan seluruh bobot open source dasar dan mengandalkan kemampuan penalaran tinggi untuk berbagai fungsi? Dan saya rasa pemrosesan yang bisa langsung dilakukan serta pencarian dan penelusuran dokumen sebaiknya dipisahkan sebagai fungsi yang berbeda.
Untuk rentang token target KV cache untuk menangani 300 pengguna secara bersamaan juga, kalau masing-masing sekitar 20.000 token dalam nilai kuantisasi, sepertinya masih bisa dipakai dengan cukup longgar, jadi bagian ini juga mungkin ditetapkan terlalu besar... ??
Kalau memang bukan 300 orang doktor yang sedang membuat makalah, saya rasa akan lebih realistis bila tingkat penalarannya ditetapkan setara siswa SMA (14~30b), lalu berbagai dokumen internal perusahaan diatur agar ditelusuri dengan proses CoT yang sesuai dengan logika RAG. Dengan begitu, proyek ini mungkin bisa menjadi proyek tingkat uji coba dengan biaya yang cukup wajar.

[tsboard]

Saya juga sedang membuat solusi RAG karena kebutuhan, sampai memakai 4 GPU H100 yang langka itu, tetapi jika mempertimbangkan bukan hanya investasi langsung pada hardware melainkan juga biaya listrik, berbagai biaya solusi pendinginan, dan lain-lain, saya terus merasa bahwa memanggil API saja akan jauh lebih baik.

Awalnya saya juga mulai menguji dengan Ollama, lalu setelah memastikan bahwa itu bahkan tidak bisa menangani 3 pengguna bersamaan dengan baik, saya langsung beralih ke vLLM dan entah bagaimana menyusun solusi RAG, tetapi (dengan asumsi 10 pengguna bersamaan) hanya untuk ini saja sudah hampir perlu memakai penuh 2 GPU H100. Pekerjaan embedding maupun pencarian juga saya jalankan lewat vLLM, jadi 4 H100 benar-benar terasa mepet. Padahal VRAM per kartu sekitar 90GB.

Tentu saja, saya sendiri tidak terlalu paham AI, dan karena harus menyesuaikan kebutuhan departemen + aturan keamanan internal perusahaan sana-sini, saya jadi nekat saja mencobanya... Saya jadi bertanya-tanya apakah ini memang pendekatan yang benar. ChatGPT Enterprise, ya? Saya benar-benar merasa itu harganya sangat worth it.

[chinnotching]

Mungkin cukup satu mesin yang sangat mantap dengan harga yang sangat mantap? Firma hukum yang sangat mantap bakal pilih beli saja, sih. Tapi ya seperti menjalankan mesin pabrik 24 jam terus wkwk

[neinomu]

Tipe orang yang cuma memikirkan harga Porsche, tanpa memikirkan sama sekali biaya perawatan, bensin, asuransi, dan sebagainya

[beepp]

Untuk layanan seperti chatbot yang harus menyediakan fitur streaming, saat menangani permintaan secara bersamaan, proses prefill ikut terdampak hingga tahap decode, sehingga meskipun VRAM cukup lega, dari sudut pandang pengguna performanya terlihat sangat menurun.

Saya juga sudah mencoba opsi terkait chunk prefill dan fitur Disaggregated Prefilling yang disediakan secara eksperimental di vLLM, tetapi ketika permintaan baru masuk, jawaban yang sedang dihasilkan tetap terputus-putus. Jadi, sebagai pengembang pemula, saya penasaran apakah ada cara yang paling efisien selain menambah GPU atau node.

[iolothebard]

Awal-tengah-akhirnya~ tergantung kasus!