⚡ Jawaban Singkat / Key Takeaways
Real-time LLM inference di shared hosting LAMP/LEMP standar (1-2 core, 2-4 GB RAM) bisa jalan, tapi bukan untuk semua skenario. Resource spike bisa 10x lipat dari request PHP biasa. Tanpa caching agresif dan fallback cloud API, satu request inference bisa bikin neighboring tenant di server shared ikut tumbang.
Bayangin skenario ini: kamu freelance builder, klien minta fitur AI di website WordPress budget Rp 150rb/bulan. “Chatbot pintar,” katanya, “biar pengunjung bisa tanya-tanya otomatis.” Kamu langsung mikir: apa shared hosting murahan bisa ngejalanin LLM tanpa ngelag? Atau ini resep bencana yang bakal bikin servernya down tiap 3 jam?
Pertanyaan ini muncul makin sering sejak plugin AI WordPress mulai menjamur. Tapi jarang ada yang berani ngomong jujur soal performanya di server kelas bawah. Kita bongkar bareng-bareng.
Apa yang Sebenarnya Terjadi Saat LLM Jalan di LAMP/LEMP Stack?
Oke, kita pahami dulu arsitektur dasarnya. Shared hosting tipikal Indonesia berjalan di atas Apache/Nginx + PHP-FPM + MySQL/MariaDB. CPU dialokasikan per akun via cgroups atau CloudLinux LVE. Begitu ada request inference model LLM, yang terjadi bukan cuma “proses lambat”. Yang terjadi adalah resource spike total di semua lapisan.
CPU Spike: Dari 2% ke 98% dalam Sekejap
Request normal WordPress paling butuh 50-200 ms CPU time. Begitu PHP-mu nge-load model GGUF kecil lewat binding llama.cpp, kebutuhan CPU langsung melesat:
- Model 1.5B parameter (Q4_K_M): 800 MB RAM, 3-8 detik per inference di 1 core
- Model 7B parameter (Q4_K_M): 4 GB RAM, 20-60 detik per inference di 1 core
Masalahnya, di shared hosting, CPU limit biasanya cuma 1-2 core dengan burst singkat. Begitu inference jalan, CPU-mu mentok 100% seketika. CloudLinux akan throttle prosesmu. Hasilnya? Timeout 504 buat semua visitor lain di situs yang sama.
Swap Storm: RAM Tipis Langsung Mati Suri
Shared hosting rata-rata kasih RAM 2-4 GB. Itu sudah termasuk aplikasi WordPress, database, dan stack web server. Begitu model 1.5B dimuat ke memory, langsung terjadi swapping besar-besaran. I/O disk melonjak. MySQL ikut tersendat karena semua pakai disk yang sama. Inilah kenapa satu plugin AI bisa bikin seluruh server melambat, bukan cuma situsmu sendiri.
Model Mana yang Masih Masuk Akal di Shared Hosting?
Ini penting banget buat kamu yang udah terlanjur janji fitur AI ke klien. Tidak semua model bisa dipaksa jalan. Berikut tolok ukur praktis berdasarkan pengujian nyata di VPS setara shared hosting (2 core, 4 GB RAM, NVMe):
| Model | RAM Butuh | Waktu Inference | Layak Shared? |
|---|---|---|---|
| Gemma 2B (Q4) | ~1.5 GB | 2-5 detik | ⚠️ Hati-hati |
| Phi-3 Mini (Q4) | ~2.5 GB | 3-8 detik | ⚠️ Hati-hati |
| Llama 3.2 3B (Q4) | ~2.8 GB | 8-20 detik | ❌ Tidak |
| Qwen 2.5 7B (Q4) | ~5 GB | 30-60 detik | ❌ Tidak |
Kesimpulan: hanya model di bawah 3B parameter dengan kuantisasi agresif yang realistis. Itu pun perlu strategi caching yang tepat.
Strategi Caching yang Bikin Inference Tetap Waras
Kalau kamu tetap harus jalanin AI di server murah, caching bukan lagi opsional. Ini adalah satu-satunya lapisan yang memisahkan servermu dari kehancuran.
1. Semantic Response Cache
Jangan cuma cache based on input string identik. Gunakan teknik semantic hashing: embedding input user dihitung, lalu dibandingkan dengan cache key yang sudah ada. Kalau similarity cosine > 0.92, langsung return cached response. Ini drastis mengurangi hit ke model. Kuncinya: embedding model yang jauh lebih ringan dari LLM utama. Pakai all-MiniLM-L6-v2 yang cuma 23 MB dan bisa jalan via ONNX runtime di PHP.
2. Cold-Start Preload via WP-Cron
Ini trik yang jarang dibahas. Jangan load model saat request masuk. Itu resep timeout. Sebagai gantinya, preload model via background process menggunakan WP-Cron yang di-trigger kelipatan 5 menit. PHP-FPM pool khusus untuk inference dengan pm.max_children = 1 dan request_terminate_timeout = 120. Model tetap hang di memory sepanjang proses itu hidup.
3. Edge Offloading untuk Prompt Generik
Prompt yang jawabannya bisa diprediksi (FAQ, definisi dasar, greeting) sebaiknya di-hardcode sebagai static JSON yang diserve langsung oleh Nginx tanpa menyentuh PHP ataupun model. Cocok untuk pertanyaan macam “Jam kerja buka kapan?” atau “Alamat kantor di mana?”. Ini 30-40% traffic chatbot tipikal.
Fallback Pattern: Jangan Bergantung Penuh ke On-Premise
Ini kerangka yang kami pakai di beberapa deployment klien. Polanya sederhana dan sudah terbukti menyelamatkan uptime:
- Request masuk: cek semantic cache lokal
- Cache miss: cek static hardcoded FAQ matcher
- Still miss: cek CPU usage saat ini (via
sys_getloadavg()PHP). Kalau di atas 0.8, jangan sentuh model lokal - Load aman: jalankan inference lokal dengan hard timeout 15 detik
- Load tinggi / timeout: lempar ke cloud API murah (Groq, Together AI, atau OpenAI 4o-mini) sebagai last resort
Pola ini memastikan bahwa 95% request ringan tetap dijawab lokal tanpa biaya API, sementara 5% spike traffic dilimpahkan ke cloud tanpa bikin server tumbang. Untuk panduan lebih detail soal arsitektur hybrid AI, kamu bisa baca artikel kami tentang arsitektur hybrid AI yang lebih hemat.
Checklist Sebelum Deploy AI di Shared Hosting
- Model size: Maksimal 2B parameter, kuantisasi Q4_K_M atau lebih rendah
- PHP
proc_open: Pastikan tidak diblok hosting. Butuh untuk spawn llama.cpp process - Timeout PHP: Naikkan ke minimal 120 detik khusus untuk endpoint inference
- Swap minimum: Siapkan swap 2-4 GB sebagai buffer, tapi jangan andalkan
- Monitoring: Pasang alert kalau CPU usage > 70% selama lebih dari 2 menit berturut-turut
- Cache hit rate target: Minimal 70% response harus dari cache, bukan inference langsung
Realita Pasar: Kapan Kamu Harus Jujur ke Klien?
Ini bagian yang paling susah buat freelance builder. Kamu dapat klien excited soal AI, tapi budget hostingnya cuma cukup buat shared hosting entry level. Momen inilah yang nentuin reputasi jangka panjangmu.
Kalau use case-nya FAQ bot statis yang 80% jawabannya bisa di-precompute, kamu aman. Cukup pakai semantic cache dan edge JSON. Tapi kalau klien minta AI content generator real-time yang harus nulis artikel atau bikin deskripsi produk, kamu harus bilang: ini butuh VPS minimal 4 core/8 GB RAM atau cloud API. Tidak ada jalan pintas. Satu permintaan generate konten panjang bisa makan 60-120 detik CPU penuh. Shared hosting tidak akan selamat.
Referensi lain yang relevan: strategi caching yang tidak sia-sia dan panduan memilih antara CDN, edge hosting, atau cache plugin.
FAQ
Apakah plugin AI WordPress bisa jalan di shared hosting?
Bisa, tapi dengan batasan ketat. Plugin yang mengandalkan cloud API (OpenAI, Groq, Together) aman karena inferensi terjadi di server eksternal. Plugin yang mencoba menjalankan model lokal (via llama.cpp, Ollama, atau ONNX) baru aman jika model di bawah 2B parameter dan caching diterapkan dengan benar. Tanpa caching, server shared hostingmu berisiko downtime berulang.
Berapa RAM minimum untuk menjalankan LLM di server sendiri?
Untuk model kecil (1-2B parameter, Q4 quantized), kamu butuh minimal 1.5 GB RAM kosong di luar OS dan aplikasi. Artinya server dengan total 4 GB RAM hanya punya ruang sempit. Kalau WordPress dan MySQL sudah makan 1.5-2 GB, sisa untuk model sangat tipis. Idealnya, server dengan 8 GB RAM total untuk inference lokal yang stabil.
Apa alternatif selain self-hosted LLM untuk budget kecil?
Tiga opsi paling realistis: (1) Groq API menawarkan inference gratis untuk model Llama dengan rate limit tinggi dan latency rendah, cocok untuk chatbot volume sedang; (2) Pre-computed FAQ engine berbasis embedding similarity tanpa LLM sama sekali; (3) Hybrid pattern seperti yang dijelaskan di atas: cache lokal untuk 80% traffic, cloud API hanya untuk sisanya.
Kesimpulan
On-premise AI generation di shared hosting itu mungkin, tapi bukan untuk semua use case. Model kecil dengan caching agresif bisa menghasilkan chatbot fungsional. Tapi begitu kebutuhan naik ke content generation, summarization panjang, atau reasoning kompleks, kamu wajib punya strategi fallback ke cloud API. Jangan biarin janji fitur AI ke klien berakhir dengan server down dan reputasi hancur.
Kuncinya sederhana: ukur resource, terapkan cache berlapis, siapkan escape hatch ke cloud. Kalau tiga ini kamu pegang, shared hosting pun masih bisa main di era AI.
