Cara Menghitung Kebutuhan GPU untuk Ollama sebagai API: VRAM, Concurrent Request, dan Kapasitas Layanan

Ketika model AI hanya dipakai oleh satu orang melalui terminal, pertanyaan utamanya sederhana: apakah model bisa berjalan di GPU yang tersedia?

Begitu Ollama dijadikan API, pertanyaannya berubah:

• Berapa request yang dapat diproses bersamaan?
• Berapa request yang harus menunggu?
• Apakah respons masih cukup cepat pada jam sibuk?
• Berapa VRAM yang diperlukan ketika prompt memuat riwayat chat atau hasil RAG?
• Kapan perlu GPU yang lebih besar, dan kapan perlu menambah server?

Tidak ada angka universal seperti “GPU 8 GB mampu melayani 20 pengguna concurrent”. Kapasitas bergantung pada model, ukuran context, jumlah token jawaban, konfigurasi Ollama, dan target waktu respons.

Mari kita hitung secara bertahap.

1. Bedakan pengguna, request paralel, dan request dalam antrean

Tiga istilah ini sering tertukar.

Pengguna aktif adalah orang yang sedang memakai aplikasi. Mereka belum tentu mengirim pertanyaan pada saat yang sama.

Request paralel adalah permintaan yang sedang diproses model secara bersamaan.

Request dalam antrean sudah diterima server, tetapi menunggu kesempatan diproses.

Sebagai contoh, 100 pegawai dapat memakai aplikasi PIA dalam satu jam, tetapi mungkin hanya 2 orang yang mengirim pertanyaan pada detik yang sama. Sebaliknya, 20 pegawai yang menekan tombol Ask hampir bersamaan dapat menciptakan antrean walaupun GPU mampu memproses 2 request paralel.

Karena itu, kebutuhan GPU tidak dapat ditentukan dari jumlah akun pengguna saja.

2. Komponen VRAM saat Ollama berjalan

Untuk estimasi awal, pecah penggunaan VRAM menjadi empat bagian:

VRAM dibutuhkan ≈
  bobot model
+ KV cache untuk seluruh request paralel
+ memori kerja runtime
+ cadangan

A. Bobot model

Bobot model adalah bagian utama yang perlu dimuat untuk menjalankan inferensi. Ukurannya dipengaruhi jumlah parameter dan quantization.

Sebagai contoh, varian llama3.1:8b di pustaka Ollama memiliki ukuran sekitar 4,9 GB dengan quantization Q4_K_M. Angka ukuran file tersebut merupakan titik awal, bukan jaminan bahwa model cukup dijalankan pada GPU 5 GB.

Perhatikan satuannya: angka GB pada ukuran file biasanya berbasis desimal, sedangkan kapasitas memori dalam perhitungan teknis sering dinyatakan dalam GiB. Secara kasar, 4,9 GB setara dengan sekitar 4,56 GiB.

B. KV cache

Ketika model membaca prompt dan menghasilkan jawaban, ia menyimpan informasi perhatian (key dan value) untuk token dalam context. Inilah KV cache.

Semakin panjang context dan semakin banyak request paralel, semakin besar kebutuhan memorinya. Riwayat percakapan, dokumen RAG, instruksi sistem, pertanyaan pengguna, dan token jawaban semuanya perlu dipertimbangkan dalam anggaran context.

C. Memori kerja runtime

Selain bobot dan KV cache, proses inferensi membutuhkan buffer dan memori kerja lain. Besarnya bergantung pada model, perangkat, backend, pengaturan batch, dan versi perangkat lunak.

Jangan menganggap seluruh VRAM yang tersisa setelah memuat model tersedia untuk request tambahan.

D. Cadangan

Sisakan ruang untuk variasi beban, proses lain yang memakai GPU, dan perubahan konfigurasi. Cadangan ini adalah keputusan operasional, bukan angka baku dari Ollama.

3. Rumus sederhana untuk menghitung batas paralelisme

Setelah ukuran tiap komponen diketahui atau diukur, gunakan:

VRAM_tersedia_untuk_KV =
  VRAM_GPU
- VRAM_bobot_model
- VRAM_runtime
- VRAM_cadangan

Batas_paralel_teoretis =
  floor(VRAM_tersedia_untuk_KV / KV_per_request)

Hasilnya baru batas berdasarkan memori. Jumlah request paralel yang layak dipakai di produksi dapat lebih kecil karena waktu respons memburuk ketika GPU sibuk.

Dengan kata lain:

Concurrent produksi =
  nilai tertinggi yang lolos uji VRAM
  DAN lolos target waktu respons

4. Bagaimana menghitung KV cache?

Untuk model transformer dengan cache key dan value standar, perkiraan dasarnya adalah:

KV bytes per token ≈
  jumlah layer
× jumlah KV head
× dimensi tiap head
× 2                # key dan value
× byte per elemen

Kemudian:

KV per request ≈
  KV bytes per token
× context yang dialokasikan per request

Dan untuk sejumlah request paralel:

KV total ≈ KV per request × jumlah request paralel

Ini adalah rumus pendekatan. Beberapa arsitektur model memiliki pola cache yang berbeda, sementara pengaturan quantization KV cache juga mengubah jumlah byte per elemen. Angka pemakaian aktual tetap harus diperiksa saat model berjalan.

5. Contoh: Llama 3.1 8B dengan context 4.096 token

Metadata varian Llama 3.1 8B pada pustaka Ollama menunjukkan:

Untuk contoh perhitungan, anggap KV cache menggunakan format f16, yaitu 2 byte per elemen.

KV bytes per token =
  32 layer
× 8 KV head
× 128 dimensi
× 2 untuk key dan value
× 2 byte

= 131.072 byte per token
= 128 KiB per token

Jika context yang dialokasikan adalah 4.096 token:

KV per request =
  128 KiB × 4.096
= 512 MiB
= 0,5 GiB

Maka estimasi kebutuhan KV cache menjadi:

Catatan: Ini hanya estimasi KV cache. Bobot model, memori kerja runtime, dan cadangan belum masuk ke tabel.

6. Simulasi pada GPU 8 GiB

Sekarang kita gunakan angka perencanaan berikut:

Angka 0,70 GiB untuk runtime dan 1,00 GiB untuk cadangan adalah asumsi simulasi, bukan spesifikasi resmi Ollama. Keduanya perlu diganti dengan hasil pengukuran pada server sendiri.

Hitung ruang yang tersisa:

VRAM untuk KV =
  8,00 - 4,56 - 0,70 - 1,00
= 1,74 GiB

Lalu hitung batas paralel berdasarkan estimasi memori:

floor(1,74 / 0,50) = 3 request

Secara aritmetika, 3 request paralel tampak mungkin pada asumsi tersebut. Namun, hasil ini terlalu dekat dengan batas untuk langsung ditetapkan sebagai konfigurasi produksi.

Untuk server produksi, kita masih harus memeriksa:

• Apakah bobot model dan KV cache benar-benar berada di GPU?
• Berapa memori kerja aktual saat request berlangsung?
• Apakah ada proses lain yang memakai GPU?
• Apakah waktu respons request kedua dan ketiga masih dapat diterima?
• Apakah prompt terpanjang tetap muat?

Keputusan awal yang lebih masuk akal adalah menguji 1, lalu 2, lalu 3 request paralel; hentikan kenaikan ketika VRAM atau waktu respons melewati batas layanan.

Angka “3” dalam contoh ini adalah hasil rumus dengan asumsi tertentu, bukan klaim kapasitas pasti untuk setiap GPU 8 GB.

7. Apa yang terjadi jika context dinaikkan?

Pada contoh model dan format KV cache yang sama:

Jika ruang KV pada simulasi GPU 8 GiB tadi adalah 1,74 GiB:

• Pada context 4.096, perhitungan menunjukkan hingga 3 request.
• Pada context 8.192, perhitungan menunjukkan 1 request.
• Pada context 16.384, satu request pun tidak masuk ke anggaran GPU penuh dalam asumsi tersebut.

Ini tidak berarti model pasti gagal berjalan. Sistem dapat menggunakan CPU atau melakukan offloading dalam kondisi tertentu, tetapi performanya dapat berubah besar. Periksa kolom PROCESSOR pada ollama ps untuk melihat apakah model berjalan sepenuhnya di GPU.

Panjang context yang didukung oleh model juga berbeda dari context yang dialokasikan saat dijalankan. Sebuah model dapat mendukung context panjang, tetapi Anda tetap perlu menentukan apakah GPU mampu menyediakan memori untuk context tersebut.

8. Mengatur request paralel di Ollama

Pengaturan utama untuk jumlah request yang diproses paralel per model adalah:

OLLAMA_NUM_PARALLEL

Dokumentasi Ollama mencantumkan nilai bawaan 1 untuk pengaturan ini. Untuk pengujian dengan dua request paralel:

OLLAMA_NUM_PARALLEL=2 ollama serve

Jika Ollama dijalankan sebagai service systemd pada Linux, atur variabel lingkungan melalui override service:

sudo systemctl edit ollama.service

Isi override:

[Service]
Environment="OLLAMA_NUM_PARALLEL=2"

Kemudian muat ulang dan mulai ulang service:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Jangan menaikkan OLLAMA_NUM_PARALLEL hanya karena ada lebih banyak pengguna. Dokumentasi Ollama menjelaskan bahwa kebutuhan memori untuk pemrosesan paralel meningkat bersama jumlah request paralel dan ukuran context.

9. Paralelisme berbeda dari panjang antrean

Ollama juga memiliki pengaturan:

OLLAMA_MAX_QUEUE

Pengaturan ini membatasi berapa banyak request yang boleh menunggu ketika server sibuk. Jika antrean penuh, server dapat mengembalikan HTTP 503.

Menaikkan batas antrean tidak menambah kemampuan GPU memproses request. Antrean yang terlalu panjang justru membuat pengguna menunggu semakin lama.

Misalnya:

2 request sedang diproses
+ 20 request menunggu
= 22 request berada di sistem

Namun concurrent inference tetap 2.

Untuk API yang dipakai manusia, sebaiknya tentukan batas waktu menunggu yang masuk akal. Jika antrean terlalu panjang, aplikasi dapat menolak permintaan lebih awal atau memberi tahu pengguna bahwa layanan sedang sibuk.

10. Berapa concurrent yang “diperbolehkan”?

Jawaban teknisnya terdiri dari dua batas:

Batas pertama: memori

Request paralel tidak boleh membuat penggunaan memori melebihi kapasitas yang tersedia untuk beban terburuk yang ingin dilayani.

Gunakan prompt panjang, riwayat chat, dan jumlah token jawaban yang realistis ketika menguji batas ini.

Batas kedua: waktu respons

Walaupun 4 request paralel muat di VRAM, keempatnya belum tentu selesai cukup cepat. GPU yang sama harus membagi kapasitas komputasinya.

Karena itu, buat target layanan terlebih dahulu, misalnya:

95% request selesai dalam ≤ 15 detik
untuk prompt hingga 2.000 token
dan jawaban hingga 200 token
pada beban 10 request per menit.

Angka tersebut hanyalah contoh target. Tim perlu menetapkan target sesuai pengalaman pengguna yang diinginkan.

Uji konfigurasi OLLAMA_NUM_PARALLEL=1, 2, 4, dan seterusnya. Pilih konfigurasi tertinggi yang tetap memenuhi target waktu respons dan memori.

11. Mengubah beban pengguna menjadi perkiraan request

Untuk perencanaan awal, hitung tingkat kedatangan request:

Request per menit =
  jumlah pengguna aktif
× rata-rata pertanyaan per pengguna per menit

Contoh:

60 pengguna aktif
× 1 pertanyaan setiap 10 menit
= 6 request per menit

Namun rata-rata ini belum menggambarkan lonjakan. Jika banyak pengguna membuka aplikasi pada jam yang sama, beban puncak dapat jauh lebih tinggi.

Catat setidaknya:

• Request per menit rata-rata.
• Request per menit pada jam sibuk.
• Jumlah request yang datang hampir bersamaan.
• Panjang prompt pada persentil ke-95.
• Panjang jawaban pada persentil ke-95.
• Target latensi persentil ke-95.

Untuk gambaran hubungan beban dan request yang sedang berada di sistem, kita dapat menggunakan pendekatan Little’s Law:

Jumlah request rata-rata dalam sistem ≈
  tingkat kedatangan request
× waktu request berada dalam sistem

Misalnya, jika ada 6 request per menit atau 0,1 request per detik, dan tiap request menghabiskan rata-rata 10 detik sejak masuk sampai selesai:

0,1 × 10 = 1 request rata-rata dalam sistem

Angka itu adalah rata-rata, bukan batas puncak paralelisme. Lonjakan kedatangan request tetap dapat membentuk antrean.

12. Mengukur throughput token dan waktu respons

Respons API Ollama menyertakan metrik seperti:

• prompt_eval_count: jumlah token input.
• prompt_eval_duration: waktu pemrosesan token input.
• eval_count: jumlah token output.
• eval_duration: waktu menghasilkan token output.
• load_duration: waktu memuat model.
• total_duration: waktu total menurut Ollama.

Nilai durasi tersebut dinyatakan dalam nanodetik.

Perkiraan kecepatan output:

Token output per detik =
  eval_count / (eval_duration / 1.000.000.000)

Misalnya, jika respons memuat:

eval_count = 200
eval_duration = 5.000.000.000 ns

Maka:

200 / 5 = 40 token output per detik

Namun, jangan langsung mengubah angka ini menjadi kapasitas request produksi. Pemrosesan prompt, waktu antrean, pemuatan model, jaringan, dan paralelisme juga memengaruhi waktu yang dialami pengguna.

Ukur waktu dari sisi aplikasi pemanggil, selain mencatat metrik dari Ollama. Dengan begitu, waktu tunggu dalam antrean dan overhead aplikasi ikut terlihat.

13. Cara melakukan uji kapasitas yang benar

Gunakan payload yang menyerupai beban produksi. Untuk asisten berbasis tiket atau RAG, request pengujian sebaiknya memuat instruksi sistem, pertanyaan, riwayat percakapan, dan potongan dokumen dengan panjang yang realistis.

Lakukan langkah berikut:

1. Tetapkan satu model dan quantization. Jangan mengganti model di tengah pengujian.
2. Tetapkan context. Catat ukuran yang dikonfigurasi dan yang terlihat pada ollama ps.
3. Panaskan model. Kirim satu request sebelum mengukur agar waktu pemuatan awal tidak tercampur dengan hasil beban normal.
4. Uji satu request. Catat VRAM, token per detik, dan latensi.
5. Uji 2, 4, lalu 8 request bersamaan sesuai kapasitas yang terlihat; berhenti jika terjadi offloading, error, atau latensi tidak memenuhi target.
6. Uji beban berkelanjutan. Lonjakan singkat saja tidak cukup untuk melihat pertumbuhan antrean.
7. Uji prompt panjang. Gunakan ukuran mendekati batas yang memang akan diizinkan aplikasi.
8. Catat latensi p50 dan p95, throughput request per menit, error HTTP 503, dan penggunaan VRAM.
9. Tetapkan batas aplikasi. Batasi panjang input, jumlah token output, serta jumlah request yang dapat dikirim tiap pengguna.

Saat pengujian, periksa:

ollama ps

Pada server NVIDIA, penggunaan GPU juga dapat dipantau dengan:

nvidia-smi

Perhatikan kolom PROCESSOR pada ollama ps. Jika muncul pembagian antara GPU dan CPU, catat bahwa hasil pengujian tersebut tidak lagi mewakili inferensi penuh di GPU.

14. Kapan perlu GPU lebih besar atau server tambahan?

Pilih GPU dengan VRAM lebih besar jika model dan context yang dibutuhkan sulit dimuat sepenuhnya di GPU, atau jika KV cache menjadi batas utama.

Pertimbangkan server tambahan jika satu server sudah memenuhi kebutuhan memori, tetapi jumlah request dan waktu respons pada jam sibuk tidak memenuhi target. Request dapat didistribusikan oleh aplikasi atau lapisan load balancer.

Kurangi kebutuhan per request sebelum membeli perangkat jika masalahnya berasal dari prompt yang terlalu panjang. Untuk RAG, misalnya, kirim hanya potongan dokumen yang relevan dan batasi riwayat chat yang disertakan.

Perubahan quantization model atau KV cache juga dapat mengurangi penggunaan memori, tetapi kualitas jawaban dan performa perlu diuji kembali.

15. Checklist sebelum Ollama dipakai sebagai API produksi

Kesimpulan

Cara menghitung GPU untuk Ollama sebagai API dimulai dari bobot model + kebutuhan KV cache per request + memori kerja + cadangan. Setelah itu, uji jumlah request paralel terhadap target waktu respons.

Pada contoh Llama 3.1 8B dengan KV cache f16, context 4.096 token memerlukan perkiraan 0,5 GiB KV cache per request. Menaikkan context menjadi 8.192 token membuat perkiraannya menjadi 1 GiB per request. Angka ini menunjukkan mengapa pertanyaan “GPU 8 GB bisa berapa concurrent?” tidak dapat dijawab tanpa mengetahui model, context, dan karakter beban API.

Rumus memberikan titik awal perencanaan. Jumlah concurrent yang benar untuk produksi ditetapkan melalui pengukuran pada server, model, dan pola pertanyaan yang benar-benar akan digunakan.

Referensi

• Ollama FAQ: parallel requests, queue, dan KV cache
• Ollama: Context Length
• Ollama API: Usage Metrics
• Metadata Llama 3.1 8B di Ollama