VPS untuk AI: Cara Memilih Spesifikasi yang Tepat

Model AI kecil untuk chatbot internal bisa berjalan pada server tanpa GPU. Model yang lebih besar, proses gambar, dan pelatihan membutuhkan GPU dengan VRAM yang cukup. Jadi, spesifikasi VPS untuk AI tidak bisa dipilih dari jumlah vCPU saja. Kamu perlu mencocokkan beban kerja, ukuran model, cara model dimuat ke memori, serta jumlah pengguna yang akan mengaksesnya.

Panduan ini membantu kamu mengambil keputusan tersebut. Bahasannya mencakup server CPU, GPU passthrough atau GPU dedicated, RAM, VRAM, storage, jaringan, sistem operasi, kompatibilitas CUDA, contoh konfigurasi dummy, sampai langkah troubleshooting. Angka pada contoh adalah titik awal untuk perencanaan, bukan janji performa atau persyaratan universal. Pada 200 kata per menit, artikel ini membutuhkan sekitar 22 menit baca.

Tentukan pekerjaan AI sebelum memilih VPS

Kalimat “saya mau menjalankan AI” masih terlalu luas. Server untuk memanggil API model cloud berbeda dari server untuk menjalankan LLM lokal. Begitu juga aplikasi yang hanya membuat embedding dokumen tidak sama dengan layanan text to image yang memproses gambar berulang-ulang.

Tulis dulu alur kerjanya dalam satu paragraf. Contohnya, “aplikasi di app.example.com menerima pertanyaan, mencari dokumen di database, lalu mengirim konteks ke API model eksternal”. Alur seperti ini mungkin hanya membutuhkan CPU, RAM, storage, dan jaringan yang stabil. Modelnya berjalan di luar VPS.

Contoh lain, “server menyimpan model bahasa lokal, menerima permintaan dari lima pengguna, dan mengembalikan jawaban melalui API internal”. Di sini ukuran model dan VRAM menjadi pembatas. Kalau model tidak muat di GPU, sebagian proses bisa pindah ke RAM atau CPU. Hasilnya mungkin tetap berjalan, tetapi waktu respons bisa berubah jauh.

Ada empat kelompok pekerjaan yang sering disebut AI.

1. Aplikasi yang memanggil API model cloud.
2. Inferensi model lokal untuk teks, embedding, atau reranking.
3. Inferensi gambar, suara, dan video.
4. Fine-tuning atau pelatihan model.

Kelompok terakhir biasanya membutuhkan perangkat GPU dengan memori besar, akses driver yang jelas, storage cepat, serta kemampuan menjalankan proses panjang tanpa terputus. VPS biasa yang cocok untuk website belum tentu cocok untuk pekerjaan ini.

API cloud tidak selalu membutuhkan GPU

Jika VPS hanya menjalankan backend, worker, webhook, atau dashboard yang memanggil API OpenAI, Anthropic, Google, atau penyedia lain, jangan membeli GPU hanya karena aplikasinya memakai AI. CPU memproses logika aplikasi. RAM menampung runtime, cache, dan antrean. Bandwidth menangani request serta respons.

Contoh rancangan awal untuk aplikasi uji coba adalah 2 sampai 4 vCPU, RAM 4 sampai 8 GB, SSD 50 sampai 100 GB, dan sistem operasi Linux yang masih mendapat pembaruan keamanan. Itu bukan standar resmi. Ukuran tersebut hanya titik awal agar kamu bisa mengukur pemakaian sebenarnya sebelum melakukan resize.

Perhatikan juga letak database. Jika database berada di VPS yang sama, RAM dipakai oleh backend, database, reverse proxy, worker, sistem operasi, dan log. Semua komponen itu akan berebut ruang. Sediakan cadangan. Server yang kehabisan RAM dapat memanggil swap, tetapi swap memakai storage dan biasanya lebih lambat daripada memori utama.

Baca juga panduan AI API key untuk pemula sebelum menaruh kredensial di aplikasi. Jangan menulis API key langsung dalam kode atau contoh publik. Untuk contoh lokal, gunakan variabel lingkungan seperti AI_API_KEY dan domain dummy.

Inferensi lokal membutuhkan perhitungan memori

Inferensi adalah proses memakai model yang sudah dilatih untuk menghasilkan keluaran. Pada LLM, model perlu dimuat ke memori sebelum menerima prompt. Ukuran berkas model saja belum cukup untuk menghitung kebutuhan server. Runtime, konteks percakapan, cache, tokenizer, library, dan proses lain juga membutuhkan ruang.

Model dengan ukuran 7 miliar parameter dalam format tertentu tidak otomatis membutuhkan RAM atau VRAM persis sebesar angka yang tertulis pada nama model. Kuantisasi dapat mengurangi kebutuhan memori, tetapi kualitas, kompatibilitas, dan kecepatan juga ikut berubah. Format dan runtime yang dipilih menentukan hasil akhir.

Gunakan pengukuran dari model yang benar-benar akan dipakai. Cek ukuran berkasnya, dokumentasi quantization, ukuran context window, dan rekomendasi runtime. Jangan menjadikan tabel internet yang membahas model lain sebagai patokan mutlak.

Gambar dan video punya pola beban yang berbeda

Pembuatan gambar biasanya sensitif terhadap VRAM, resolusi, jumlah langkah, batch size, dan jenis pipeline. Satu konfigurasi yang berhasil membuat gambar kecil belum tentu sanggup memproses beberapa gambar resolusi tinggi sekaligus. Video menambah beban storage dan waktu proses karena keluaran terdiri dari banyak frame.

Untuk layanan gambar, catat ukuran input, resolusi keluaran, jumlah pekerjaan bersamaan, dan batas waktu yang masih bisa diterima. Kalau hanya satu pekerjaan sesekali, antrian sederhana mungkin cukup. Kalau banyak pengguna mengirim pekerjaan bersamaan, kamu membutuhkan worker, batas antrean, dan cara menolak pekerjaan saat kapasitas habis.

Jangan menganggap GPU otomatis menyelesaikan bottleneck. File model yang besar tetap harus dibaca dari storage. Hasil gambar perlu ditulis ke disk atau object storage. Worker juga perlu mengirim status ke aplikasi utama. Jalur lengkapnya yang harus diukur.

CPU, vCPU, dan jenis pekerjaan yang cocok

CPU menjalankan sistem operasi, web server, database, preprocessing, tokenisasi, kompresi, dan banyak bagian aplikasi AI. Pada server GPU, CPU tetap dibutuhkan. GPU yang cepat bisa menunggu kalau CPU terlalu lambat menyiapkan batch atau memindahkan data.

Istilah vCPU biasanya merujuk pada jatah prosesor virtual yang diberikan penyedia. Detail pemetaan ke core fisik berbeda menurut platform dan paket. Karena itu, bandingkan hasil pengujian pada beban yang sama, bukan hanya angka vCPU di halaman paket.

Untuk backend API yang hanya memanggil model cloud, mulai dari beban aplikasi. Ukur waktu CPU, penggunaan RAM, jumlah worker, serta jumlah request bersamaan. Worker terlalu banyak bisa menghabiskan RAM tanpa meningkatkan throughput. Worker terlalu sedikit membuat request menunggu.

Untuk inferensi CPU, jumlah core dan performa per core sama-sama berpengaruh. Batch besar bisa memakai lebih banyak core, sementara satu permintaan interaktif kadang lebih dipengaruhi performa satu thread dan akses memori. Coba jalur yang realistis. Jangan hanya menjalankan benchmark sintetis lalu menyimpulkan server siap produksi.

Untuk server GPU, sisakan CPU untuk tugas berikut:

• menerima dan memvalidasi request;
• memuat atau menyiapkan data;
• menjalankan tokenizer dan postprocessing;
• mengelola worker, log, health check, serta monitoring;
• melayani komponen pendukung seperti database atau reverse proxy.

Sebagai titik awal nonresmi, aplikasi ringan dengan satu worker bisa diuji pada 2 sampai 4 vCPU. Pipeline gambar yang melakukan preprocessing lebih berat mungkin memerlukan lebih banyak. Jumlah pastinya hanya bisa ditetapkan setelah kamu melihat profil aplikasi dan concurrency yang ditargetkan.

RAM sistem dan VRAM GPU bukan hal yang sama

RAM adalah memori utama server. VRAM adalah memori pada GPU. Keduanya bisa dipakai untuk pekerjaan AI, tetapi cara pakainya berbeda dan perpindahan data di antara keduanya memiliki biaya.

Aplikasi yang berjalan di CPU membutuhkan RAM untuk model dan runtime. Aplikasi yang berjalan di GPU membutuhkan RAM untuk sistem serta VRAM untuk bobot model dan operasi GPU. Kalau VRAM penuh, beberapa runtime dapat memindahkan bagian tertentu ke RAM. Teknik ini dikenal dengan istilah offload, tetapi kecepatannya bergantung pada perangkat, driver, runtime, ukuran data, dan jalur transfer.

Anggap VRAM sebagai ruang kerja langsung GPU. Kalau model membutuhkan ruang lebih besar dari VRAM, jangan hanya melihat total RAM. Server dengan RAM 64 GB tetap bisa gagal menjalankan konfigurasi yang memerlukan 24 GB VRAM bila GPU yang tersedia hanya punya 12 GB.

Cara memperkirakan RAM

Mulai dengan komponen yang jelas. Jumlahkan kebutuhan model, runtime, aplikasi, database, cache, dan ruang untuk lonjakan. Sisakan ruang agar sistem tidak hidup di batas atas setiap saat.

Misalnya, server menjalankan backend Python, reverse proxy, vector database kecil, dan satu runtime model CPU. Kamu bisa membuat lembar estimasi sederhana:

• runtime aplikasi: 1 sampai 2 GB;
• database dan cache: 2 sampai 6 GB;
• model dan runtime: lihat dokumentasi model;
• sistem operasi dan daemon: sisakan ruang;
• lonjakan: sisakan cadangan untuk request bersamaan.

Rentang itu bukan klaim kebutuhan semua aplikasi. Ia hanya contoh cara berpikir. Profiling tetap wajib. Gunakan free -h, vmstat, dan monitoring penyedia untuk melihat pola, tetapi jangan menyimpulkan dari satu snapshot.

Jika server mulai memakai swap terus-menerus, cari penyebabnya. Bisa jadi model terlalu besar, batch terlalu tinggi, worker terlalu banyak, atau ada proses lain yang bocor memori. Menambah swap dapat mencegah proses langsung mati, tapi tidak mengubah kapasitas RAM.

Cara memperkirakan VRAM

Cari dokumentasi model dan runtime yang dipakai. Periksa apakah ukuran yang dicantumkan berlaku untuk inferensi, fine-tuning, atau training. Tiga pekerjaan itu punya kebutuhan berbeda.

Context window juga berpengaruh. Prompt percakapan yang panjang meningkatkan cache perhatian pada sebagian runtime. Dua pengguna yang mengirim prompt panjang dapat memakai lebih banyak memori daripada satu pengguna dengan prompt singkat. Batch size memperbesar kebutuhan lagi.

Kalau model akan dipakai oleh aplikasi publik, hitung concurrency. Satu model yang muat untuk satu request belum tentu muat untuk delapan request bersamaan. Mulai dari concurrency rendah, ukur, lalu naikkan dengan batas yang jelas.

Beri ruang untuk library GPU dan overhead runtime. Jangan menargetkan penggunaan VRAM 100 persen. Ketika proses lain perlu memori atau ukuran input sedikit berubah, konfigurasi yang terlalu mepet bisa gagal dengan error out of memory.

Kapan VPS tanpa GPU masih masuk akal?

GPU bukan syarat untuk semua AI. Server CPU dapat dipakai untuk API cloud, embedding berukuran kecil, klasifikasi ringan, ekstraksi teks, scheduled job, dan prototipe dengan model kecil yang sudah dikuantisasi.

VPS CPU juga cocok untuk tahap awal karena lebih mudah dipasang dan dipantau. Kamu bisa membangun API, autentikasi, antrean, logging, dan penyimpanan lebih dulu. Saat model lokal menjadi bottleneck, komponen inferensi dapat dipindah ke node GPU tanpa mengubah seluruh aplikasi.

Ada biaya teknis saat memisahkan komponen. Jaringan antara backend dan inference server harus aman. Request memerlukan timeout. Model server harus punya health check. Kalau inference server mati, backend perlu mengembalikan respons yang jelas atau memasukkan pekerjaan ke antrean.

Arsitektur sederhana bisa seperti ini.

client -> reverse proxy -> backend CPU -> inference API GPU
                                      \-> database

Contoh domain yang aman dipakai dalam dokumentasi adalah api.example.com dan IP 203.0.113.55. Keduanya hanya placeholder. Jangan salin contoh tersebut untuk koneksi produksi.

GPU, driver, dan framework harus cocok

GPU yang tersedia belum tentu langsung bisa dipakai aplikasi. Driver, CUDA, runtime, framework, arsitektur GPU, dan sistem operasi harus berada pada kombinasi yang didukung.

Dokumentasi resmi NVIDIA tentang CUDA Compatibility menjelaskan hubungan antara aplikasi CUDA, toolkit, dan driver. Panduan itu juga membahas kompatibilitas mundur dan forward compatibility dengan batasan tertentu. Artinya, versi CUDA yang tercetak pada tutorial lama tidak boleh langsung dianggap cocok dengan GPU dan driver yang baru kamu sewa.

PyTorch menyediakan halaman Get Started Locally untuk memilih sistem operasi, package manager, bahasa, serta platform komputasi. Pilih CUDA atau CPU sesuai mesin yang benar-benar tersedia. Untuk pemeriksaan runtime, dokumentasi PyTorch mencantumkan torch.cuda.is_available() sebagai cara mengecek apakah CUDA dapat dipakai dari PyTorch.

Penyedia cloud biasanya menyediakan daftar image, driver, atau paket GPU yang didukung. Baca dokumentasi paketnya. AWS, misalnya, memisahkan keluarga instance untuk accelerated computing dan menampilkan CPU, RAM, jenis GPU, serta VRAM pada tabel spesifikasi instance. Tabel itu dapat dipakai untuk memahami informasi yang perlu kamu minta dari penyedia VPS, bukan sebagai daftar paket yang harus kamu beli.

Checklist kompatibilitas sebelum berlangganan

Sebelum memilih VPS GPU, minta jawaban tertulis untuk pertanyaan berikut:

1. GPU apa yang dipasang dan berapa VRAM yang dapat dipakai oleh instance?
2. Apakah GPU dedicated, shared, virtualized, atau hanya tersedia pada node tertentu?
3. Driver NVIDIA atau AMD versi berapa yang disediakan?
4. Apakah pengguna mendapat akses ke nvidia-smi atau alat setara?
5. Apakah image GPU sudah berisi driver dan runtime yang cocok?
6. Apakah Docker dengan GPU runtime didukung?
7. Apakah instance bisa dihentikan dan dinyalakan kembali tanpa kehilangan data?
8. Apa yang terjadi saat GPU host kehabisan kapasitas?
9. Apakah ada batas jaringan, storage, durasi proses, atau port keluar?

Kalau penjual hanya menulis “VPS AI” tanpa jenis GPU, VRAM, driver, dan kebijakan pemakaian, informasinya belum cukup untuk keputusan teknis. Minta detail. Kalau tidak ada, anggap ada risiko kompatibilitas.

Storage untuk model, cache, dan hasil kerja

Storage sering baru dipikirkan setelah server penuh. Model AI bisa berukuran besar. Beberapa versi model, cache package, log, dataset, hasil gambar, serta checkpoint dapat menghabiskan disk tanpa terasa.

Pilih SSD atau NVMe sesuai kebutuhan baca tulis. Model yang hanya dimuat saat boot punya pola berbeda dari worker yang sering memuat checkpoint dan menulis hasil. IOPS, throughput, kapasitas, dan kebijakan burst lebih berguna daripada label “cepat” tanpa angka.

Pisahkan hal-hal berikut jika aplikasinya serius:

• sistem operasi dan package;
• model dan file cache;
• database aplikasi;
• dataset atau unggahan pengguna;
• hasil keluaran dan backup.

Pemisahan bisa berupa volume berbeda, bucket object storage, atau direktori dengan kebijakan backup yang jelas. Jangan menyimpan satu-satunya salinan model hasil fine-tuning pada disk instance yang bisa terhapus saat instance dihapus.

Sediakan ruang kosong. Sistem package butuh ruang saat pembaruan. Log yang tidak diputar dapat mengisi partisi root. Docker juga dapat menyimpan image dan layer lama. Jalankan df -h dan periksa penggunaan direktori secara berkala.

Contoh struktur direktori yang tidak mengandung rahasia:

/opt/ai-app/
  app/
  models/
  cache/
  outputs/
  logs/

Jangan menaruh token, file .env, atau backup database di dalam folder yang bisa diunduh web server. Domain example.com pada contoh hanya dummy, begitu juga alamat 203.0.113.55.

Jaringan, lokasi server, dan concurrency

Model lokal tetap berinteraksi dengan komponen lain. Backend mungkin berada di node CPU, model di node GPU, data di object storage, dan pengguna mengakses dari wilayah berbeda. Latensi antara komponen itu ikut menentukan waktu respons.

Untuk chatbot interaktif, ukur waktu sampai token pertama dan waktu sampai jawaban selesai. Untuk pembuatan gambar, ukur waktu masuk antrean dan waktu file siap diambil. Dua metrik itu menjawab masalah yang berbeda.

Bandwidth keluar juga perlu dihitung kalau server mengirim gambar, audio, atau file besar. Traffic model dari object storage dapat menghabiskan jalur jaringan. Pastikan endpoint internal tidak terbuka ke internet tanpa autentikasi.

Concurrency adalah jumlah pekerjaan yang berjalan bersamaan. GPU 1 unit mungkin cukup untuk satu request, tetapi antrean akan panjang ketika delapan request masuk hampir bersamaan. Ada dua pilihan. Naikkan kapasitas hardware atau pasang batas antrean yang jujur.

Gunakan rate limit, timeout, retry terbatas, dan circuit breaker pada backend. Retry tanpa batas dapat menggandakan beban ketika model server sedang gagal. Itu bukan pemulihan. Itu antrean yang dibiarkan membesar.

Tiga contoh konfigurasi dummy

Contoh berikut tidak menyebut harga, penyedia, atau hasil benchmark. Angka hanya membantu membedakan cara memilih.

Skenario 1, chatbot memakai API eksternal

Aplikasi memiliki frontend, backend, database kecil, dan worker untuk mengirim request ke API model cloud. Tidak ada model yang disimpan di VPS.

Mulai dari 2 sampai 4 vCPU, RAM 4 sampai 8 GB, SSD 50 sampai 100 GB, serta jaringan yang stabil. Naikkan RAM jika database, worker, dan cache hidup pada mesin yang sama. GPU tidak dibutuhkan oleh backend hanya karena model yang dipanggil adalah model generatif.

Pantau waktu request, error rate, CPU, RAM, dan antrean worker. Batasi timeout API. Simpan API key sebagai secret pada environment atau secret manager yang sesuai.

Skenario 2, LLM lokal untuk tim kecil

Server menyimpan satu model teks lokal dan menyediakan endpoint internal. Pengguna hanya beberapa orang, prompt tidak selalu panjang, serta tidak ada proses fine-tuning.

Mulai dengan satu model, satu runtime, dan concurrency rendah. Pilih RAM berdasarkan ukuran model serta overhead runtime. Jika memakai GPU, cocokkan VRAM dengan format model dan context window. Jika memakai CPU, siapkan waktu respons yang lebih lambat dan ukur kebutuhan core.

Gunakan endpoint yang hanya dapat diakses jaringan internal atau melalui VPN. Jangan membuka port model ke internet tanpa autentikasi. Tambahkan log permintaan tanpa menyimpan data sensitif secara sembarangan.

Skenario 3, generator gambar dengan antrean

Aplikasi menerima prompt, memasukkan pekerjaan ke queue, lalu worker GPU mengambil pekerjaan dan menyimpan keluaran ke object storage. Backend web tidak perlu berada pada mesin GPU yang sama.

Prioritaskan VRAM, storage baca tulis, dan kemampuan menjalankan worker yang stabil. Batasi resolusi serta jumlah pekerjaan bersamaan. Ketika VRAM penuh, kembalikan status antrean atau turunkan parameter yang memang boleh diturunkan. Jangan membiarkan request web menunggu tanpa batas.

Tambahkan direktori sementara dengan kebijakan pembersihan. File input dan output yang tertinggal dapat memenuhi disk walaupun proses GPU berjalan normal.

Pilih satu server atau pisahkan komponennya?

Satu server lebih mudah dikelola. Deployment sederhana, jaringan lokal cepat, dan jumlah komponen lebih sedikit. Kekurangannya, backend, database, dan model berebut resource. Saat model macet, aplikasi web bisa ikut terganggu.

Pemisahan komponen menambah pekerjaan operasi. Kamu perlu jaringan privat, autentikasi antarlayanan, konfigurasi DNS, monitoring, dan penanganan kegagalan. Sebagai gantinya, backend CPU dapat diubah ukurannya tanpa mengubah node GPU.

Pakai satu server untuk prototipe kecil atau aplikasi internal yang toleran terhadap jeda. Pisahkan inference server ketika ukuran GPU berbeda dari kebutuhan backend, ketika beberapa aplikasi memakai model yang sama, atau ketika kamu membutuhkan deployment tiap komponen secara terpisah.

Jangan memisahkan semuanya sejak hari pertama. Tulis batas yang jelas. Kalau satu proses tidak bisa dimatikan tanpa menjatuhkan aplikasi lain, itu tanda pemisahan mungkin sudah diperlukan.

Sistem operasi, container, dan akses administrasi

Linux sering dipilih untuk workload AI karena dokumentasi framework, driver, container, dan tooling banyak mengarah ke sana. Pilih distribusi yang didukung oleh image dan framework yang kamu gunakan. Versi terbaru tidak selalu paling cocok bila driver atau library aplikasi belum mendukungnya.

Docker dapat membantu mengunci versi package, tetapi Docker bukan jaminan kompatibilitas GPU. Host tetap membutuhkan driver yang benar. Container harus diberi akses GPU sesuai konfigurasi runtime. Uji docker run pada image resmi atau image yang kamu audit sendiri sebelum memasukkan model produksi.

Jangan menjalankan semua proses sebagai root. Buat user aplikasi, batasi hak direktori model dan output, lalu gunakan firewall untuk port yang diperlukan. SSH sebaiknya memakai key, bukan password yang dibagikan dalam dokumen.

Sediakan cara pemulihan. Catat image yang dipakai, versi driver, versi Python, versi framework, dan perintah start. Tanpa catatan ini, server yang bisa berjalan hari ini belum tentu bisa dipulihkan setelah rebuild.

Monitoring yang perlu dipasang

Monitoring tidak harus mahal. Yang penting, metriknya menjawab keputusan yang akan kamu ambil.

Pada host CPU, pantau penggunaan CPU per proses, RAM, swap, disk terpakai, I/O, load average, status service, dan jaringan. Pada host GPU, tambahkan penggunaan GPU, VRAM, temperatur, daya jika tersedia, serta jumlah proses yang memakai device.

Pada aplikasi AI, catat waktu antrean, waktu model mulai memproses, waktu sampai token pertama, waktu selesai, ukuran prompt, ukuran keluaran, error out of memory, dan jumlah retry. Jangan menyimpan isi prompt pengguna secara default kalau data itu sensitif.

Buat alarm yang bisa ditindaklanjuti. “CPU tinggi” saja belum cukup. Alarm yang lebih berguna misalnya disk tersisa kurang dari batas yang kamu tentukan, swap terus bertambah, worker mati, antrean melewati kapasitas, atau VRAM penuh berulang kali.

Satu catatan penting. Angka monitoring adalah observasi lingkungan tertentu. Jangan mengubahnya menjadi klaim bahwa semua model atau semua VPS akan punya hasil sama.

Troubleshooting masalah yang sering muncul

nvidia-smi gagal atau GPU tidak terlihat

Periksa apakah paket VPS benar-benar mendapat GPU. Jalankan lspci bila tersedia, lalu cek status driver. Pastikan image tidak memakai driver yang bertentangan dengan kernel. Jika penyedia mengelola driver, kirim output error dan ID instance kepada dukungan mereka tanpa mengirim secret.

Kalau GPU memang tidak dipasangkan, instalasi library saja tidak akan menciptakan GPU. Minta penyedia mengonfirmasi jenis attachment atau ubah ke paket yang menyediakan GPU.

PyTorch menunjukkan CUDA tidak tersedia

Pastikan package PyTorch dipasang untuk platform yang sesuai. Cek versi Python, versi package, versi driver, dan perangkat yang terlihat oleh proses. Jalankan pemeriksaan kecil:

python3 - <<'PY'
import torch
print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.device_count())
PY

Output False belum menjelaskan seluruh akar masalah. Ia hanya memberitahu bahwa CUDA tidak tersedia melalui PyTorch pada saat pemeriksaan. Lanjutkan dengan memeriksa driver, environment, container runtime, dan dokumentasi versi yang dipilih.

Error out of memory pada GPU

Kurangi batch size, panjang context, resolusi, atau jumlah worker sesuai kebutuhan aplikasi. Pastikan tidak ada proses lain memakai VRAM. Hapus cache hanya setelah memahami perilaku runtime. Kalau model tetap tidak muat, pilih format yang lebih hemat memori, model lebih kecil, GPU dengan VRAM lebih besar, atau jalankan sebagian beban di CPU dengan konsekuensi kecepatan.

Jangan langsung menambah RAM sistem. RAM tambahan tidak memperbesar VRAM. Offload bisa membantu pada runtime tertentu, tetapi bisa menambah latensi dan tidak didukung semua konfigurasi.

Proses mati setelah beberapa menit

Periksa log service, dmesg untuk indikasi out of memory, penggunaan disk, timeout reverse proxy, dan kebijakan idle dari penyedia. Proses yang memuat model besar mungkin dibunuh oleh OOM killer. Worker yang lebih banyak juga bisa menggandakan penggunaan memori.

Jalankan proses melalui service manager atau supervisor yang punya restart policy masuk akal. Restart otomatis tidak menyelesaikan kebocoran memori, tetapi dapat menjadi pagar sementara sambil akar masalah diperbaiki.

Model lambat padahal GPU terpakai

GPU usage bukan satu-satunya metrik. Periksa VRAM, CPU, transfer data, storage, batch size, panjang prompt, dan waktu antrean. GPU yang sering turun ke nol mungkin menunggu data dari CPU atau disk. GPU usage tinggi dengan VRAM hampir penuh dapat menandakan konfigurasi terlalu rapat.

Ukur bagian pipeline secara terpisah. Catat waktu request masuk, model dimuat, preprocessing, inferensi, postprocessing, dan pengiriman output. Tanpa pembagian itu, kamu hanya melihat angka akhir.

Disk penuh setelah beberapa kali eksperimen

Cari file model duplikat, cache package, Docker image lama, log, checkpoint, dan output sementara. Jangan menghapus file secara acak dari direktori model. Buat daftar file besar, tentukan mana yang bisa dibuat ulang, lalu pindahkan data penting ke storage yang punya backup.

Tambahkan rotasi log dan pekerjaan pembersihan yang aman. Uji perintah pembersihan pada direktori dummy sebelum menjalankannya di server produksi.

Cara menguji sebelum memilih paket jangka panjang

Buat paket uji yang sama untuk setiap kandidat VPS. Jangan membandingkan satu server dengan prompt pendek melawan server lain dengan model dan resolusi berbeda.

Catat versi OS, driver, CUDA, Python, framework, runtime model, format model, parameter context, batch size, jumlah request bersamaan, dan ukuran input. Simpan konfigurasi itu bersama hasil. Kalau satu variabel berubah, tulis alasannya.

Tes minimal dapat mencakup:

• cold start saat model baru dimuat;
• warm request setelah model berada di memori;
• satu request interaktif;
• beberapa request bersamaan;
• proses selama durasi yang realistis;
• restart service dan pemulihan model.

Jangan mengklaim benchmark kalau kamu belum menjalankannya. Artikel ini tidak menyajikan hasil benchmark VPS tertentu. Angka rekomendasi di sini adalah cara menyusun pilihan, bukan laporan pengujian.

Untuk aplikasi produksi, tambahkan uji ketika disk hampir penuh, ketika request timeout, ketika GPU tidak tersedia, dan ketika provider API gagal. Fallback yang hanya diuji saat semua normal biasanya belum siap dipakai.

Rubrik keputusan yang bisa dipakai

Buat tabel penilaian sederhana dengan kolom kebutuhan, kandidat, bukti, dan risiko. Isi bukti dari dokumentasi penyedia atau hasil uji milikmu sendiri.

Jika memakai API cloud, beri bobot pada jaringan, RAM, reliabilitas, secret management, dan lokasi database. GPU tidak masuk prioritas kecuali ada preprocessing lokal yang memang membutuhkannya.

Jika menjalankan LLM lokal, mulai dari VRAM atau RAM yang diperlukan model. Setelah itu cek driver, runtime, CPU, storage, lalu jaringan. Jangan menukar urutan ini dengan memilih jumlah vCPU terlebih dahulu.

Jika menjalankan generator gambar, prioritaskan VRAM, pipeline yang didukung, storage, antrean, dan concurrency. CPU tetap perlu, tetapi GPU serta VRAM biasanya membatasi jenis pekerjaan yang dapat dijalankan.

Jika melakukan fine-tuning, cari dokumentasi framework dan model yang spesifik. Kebutuhan memori training berbeda dari inferensi. Perhatikan checkpoint, dataset, gradient accumulation, batch size, serta durasi proses. Untuk pekerjaan besar, layanan GPU khusus atau cluster bisa lebih masuk akal daripada memaksa VPS kecil.

Batasan yang harus diakui sebelum membeli

Tidak ada konfigurasi VPS yang menjamin model tertentu berjalan tanpa uji. Nama GPU saja belum menjelaskan performa aplikasi. Versi library dapat mengubah kebutuhan memori. Model yang sama bisa menghasilkan waktu respons berbeda saat context, batch, atau concurrency berubah.

Harga juga sengaja tidak dibahas di artikel ini karena paket dan ketersediaan GPU berubah menurut penyedia, wilayah, dan waktu. Bandingkan penawaran saat akan membeli. Periksa biaya storage, traffic keluar, snapshot, IP, durasi GPU, serta biaya ketika instance dihentikan atau dihapus.

VPS dengan GPU bukan pengganti desain aplikasi. Kamu tetap perlu autentikasi, backup, batas request, monitoring, logging yang aman, dan proses pemulihan. Server mahal yang tidak bisa dipulihkan tetap menjadi risiko operasional.

Kalau kebutuhanmu masih samar, mulai dari workload paling kecil yang bisa memberi jawaban. Bangun endpoint, pasang monitoring, jalankan model atau API yang benar-benar akan dipakai, lalu ukur. Jangan membeli kapasitas besar hanya karena nama AI terdengar berat.

Artikel terkait

• Menjalankan LLM lokal dengan LM Studio
• Memahami perbedaan AI agent dan agentic AI
• Memilih rencana AI coding sesuai alur kerja

Sumber resmi

• NVIDIA CUDA Compatibility
• PyTorch Get Started Locally
• AWS accelerated computing instance specifications

Mulai dari pertanyaan yang paling membatasi: model apa yang dijalankan, berapa banyak request bersamaan, dan berapa lama pengguna boleh menunggu. Jawaban tiga hal itu biasanya lebih berguna daripada memilih paket yang punya angka vCPU paling besar.