Mengapa LLM Self-Hosted Lambat pada 5 Pengguna

Mengapa LLM yang di-hosting sendiri melambat ketika lebih banyak pengguna terhubung?

LLM yang di-hosting sendiri tersendat pada 5 pengguna bersamaan karena server masih menghasilkan satu jawaban setiap kali, sementara empat pengguna lainnya mengantre. Dokumentasi Ollama menjelaskan pengaturan default tersebut secara tegas: OLLAMA_NUM_PARALLEL adalah "jumlah maksimum permintaan paralel yang akan diproses setiap model secara bersamaan, default 1." Tidak ada yang rusak. Empat dari lima pengguna Anda sedang menunggu giliran.

Solusinya biasanya bukan menggunakan server dengan spesifikasi lebih tinggi. Yang dibutuhkan adalah engine serving yang memproses banyak permintaan melalui model dalam satu forward pass, serta memori cadangan yang cukup untuk menyimpan percakapan semua pengguna selama proses tersebut. Kedua hal ini penting, tetapi faktor kedua yang sebenarnya menentukan batas maksimum Anda.

Dua fase yang dilalui setiap request

Prefill membaca seluruh prompt sekaligus dan membangun cache attention untuk prompt tersebut. Setiap token prompt diproses oleh model secara bersamaan. Karena itu, prefill adalah satu operasi perkalian matriks besar dan dibatasi oleh throughput aritmetika. Selanjutnya, decode menulis jawaban satu token setiap kali. Untuk setiap token, seluruh bobot model harus dibaca kembali dari memori, sedangkan operasi aritmetika pada satu token tersebut sangat kecil. Decode dibatasi oleh bandwidth memori.

Asimetri ini adalah alasan utama batching efektif. Decode untuk satu pengguna, misalnya, membaca 5 GB bobot per token dan membuat sebagian besar unit aritmetika menganggur. Tambahkan request kedua, lalu engine membaca 5 GB yang sama satu kali dan menghitung dua token dari bobot tersebut. Request kedua hampir tidak menambah waktu pemrosesan. Memproses request secara ketat satu per satu menghilangkan keuntungan tersebut.

Dua angka menggambarkan pengalaman pengguna. TTFT (time to first token) adalah waktu tunggu dalam antrean ditambah prefill. ITL (inter-token latency) adalah jeda antara token yang dialirkan, dan nilainya ditentukan oleh decode. Server yang lambat biasanya lambat pada salah satu aspek ini, dan solusinya berbeda. Sebelum mengubah pengaturan apa pun, tentukan terlebih dahulu aspek mana yang menjadi masalah. ukur prefill dan decode secara terpisah adalah cara untuk mengetahuinya.

Batching statis membuat semua permintaan menunggu respons paling lambat

Batching statis adalah versi naif. Pendekatan ini digunakan jika Anda mengelompokkan permintaan sendiri dalam kode aplikasi. Engine mengumpulkan N permintaan, memprosesnya bersama-sama, lalu mempertahankan setiap slot hingga generasi terpanjang dalam kelompok tersebut selesai.

Satu pengguna yang meminta ringkasan sepanjang 1,200 token membuat empat jawaban satu baris tetap tertahan dalam batch, karena batch tidak membebaskan slot sampai anggota yang paling lambat selesai.

Ada dua dampak. Sequence yang sudah selesai tetap menggunakan slot tanpa melakukan komputasi yang berguna. Akibatnya, throughput efektif menurun ketika panjang output bervariasi, dan panjang output dalam chat sangat bervariasi. Permintaan yang tiba satu langkah setelah batch terbentuk harus menunggu seluruh batch selesai sebelum memulai prefill. Artinya, TTFT-nya ditentukan oleh esai milik pengguna lain.

Continuous batching menerima dan mengeluarkan request pada setiap token

Continuous batching menjadwalkan request pada tingkat satu langkah decoding. Setelah setiap langkah, scheduler mengeluarkan sequence yang baru saja menghasilkan stop token, lalu menerima request yang menunggu ke slot yang tersedia. Respons yang berakhir pada langkah 40 membebaskan slotnya pada langkah 40, bukan pada akhir batch.

Ini bukan mekanisme yang khusus. llama-server mendokumentasikan -cb, --cont-batching sebagai "apakah akan mengaktifkan continuous batching (juga disebut dynamic batching) (default: aktif)", dan vLLM dibangun berdasarkan konsep ini. Ollama juga melayani request secara paralel. Konfigurasi default hanya membatasi jumlahnya menjadi satu. Karena itu, banyak orang menyimpulkan bahwa hardware mereka tidak dapat menjalankan concurrency, padahal konfigurasi merekalah yang menonaktifkannya.

Hasil continuous batching yang dipublikasikan biasanya diukur pada kartu datacenter yang memiliki kapasitas komputasi cadangan dan cache berukuran puluhan gigabyte. Pola hasil tersebut tetap berlaku pada server Anda. Besarnya hasil tidak sama, dan bagian tentang memori di bawah ini menjelaskan alasannya.

Prefill bersaing dengan decode untuk compute yang sama

Saat request baru masuk ketika empat respons sedang dialirkan, prompt-nya harus diproses melalui prefill terlebih dahulu, dan prefill membutuhkan compute besar. Jika scheduler memberikan satu step khusus untuk prefill tersebut, keempat pengguna yang sedang menerima streaming tidak mendapatkan token selama proses itu. Pada prompt yang panjang, hal ini menimbulkan jeda yang terlihat di setiap jendela yang terbuka. Inilah stutter yang dimaksud ketika orang mengatakan bahwa server tersendat setiap kali pengguna lain menekan send.

Chunked prefill membagi prompt yang panjang menjadi beberapa bagian, lalu mencampurkan setiap bagian ke dalam step yang sama dengan proses decode yang sedang berjalan. Panduan tuning vLLM menjelaskan tradeoff ini secara langsung: anggaran chunk yang lebih kecil "achieve better ITL because there are fewer prefills slowing down decodes", sedangkan nilai yang lebih tinggi "achieve better time to first token (TTFT) as you can process more prefill tokens in a batch". Anda memilih pengalaman siapa yang harus dilindungi: orang yang menunggu respons mulai muncul, atau orang yang sedang melihat teks dialirkan.

Panjang prompt menentukan seberapa besar dampaknya. Prompt 6,000 token dengan jawaban 200 token berarti ada 6,000 token pekerjaan prefill dibandingkan dengan 200 step decode. Chat berbasis retrieval-augmented dan system prompt yang panjang sama-sama dapat membawa Anda ke kondisi ini. Akibatnya, prefill tidak lagi sekadar perbedaan kecil, tetapi menjadi proses yang harus ditunggu pengguna. Prefix caching membantu ketika bagian panjang tersebut berulang: vLLM menyediakan --enable-prefix-caching, yang menggunakan kembali cache untuk prefix prompt bersama alih-alih menghitungnya ulang pada setiap request.

Memori yang pertama kali habis adalah cache KV

Setiap token dalam setiap percakapan aktif meninggalkan vektor key dan vektor value pada setiap layer model. Inilah cache KV (cache key/value), yang memungkinkan proses decode menghindari penghitungan ulang seluruh prompt untuk setiap token baru. Ukurannya per token ditentukan oleh bentuk model: 2 (satu key dan satu value) dikalikan jumlah layer, jumlah head key/value, dimensi head, lalu jumlah byte per value. Baca angka-angka tersebut dari config.json model.

Lakukan perhitungan ini sekali agar batas kapasitas tidak lagi menjadi misteri. Model 8B yang umum, dengan 36 layer, 8 head key/value, dan dimensi head 128, menggunakan cache 16-bit sebesar 2 36 8 128 2 byte per token. Nilainya adalah 147,456 byte, atau sekitar 144 KiB. Satu percakapan dengan 8,192 token memerlukan cache sekitar 1.2 GB. Lima percakapan memerlukan sekitar 6 GB, di luar bobot model. Itulah jawaban sebenarnya untuk menentukan jumlah pengguna yang dapat ditangani.

Konkurensi memperbesar konteks, dan tool menampilkannya secara langsung. FAQ Ollama menyatakan: "Parallel request processing for a given model results in increasing the context size by the number of parallel requests. For example, a 2K context with 4 parallel requests will result in an 8K context and additional memory allocation." RAM yang diperlukan bertambah sesuai hasil perkalian OLLAMA_NUM_PARALLEL dengan OLLAMA_CONTEXT_LENGTH. Dalam llama-server, konteks yang diminta melalui -c dibagi ke dalam -np slot. Karena itu, menaikkan jumlah slot saja akan mengurangi kapasitas setiap request. Baca konteks per slot dari log startup, bukan dengan mengasumsikannya.

vLLM melakukan praalokasi. --gpu-memory-utilization (default 0.92) adalah "the fraction of GPU memory to be used for the model executor". Memori yang tersisa setelah bobot model dialokasikan menjadi pool KV berpaginasi. Jika pool tersebut tidak lagi mencukupi, scheduler mengeluarkan sebuah request, bukan membuatnya gagal:

WARNING 05-09 00:49:33 scheduler.py:1057] Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space.

Pada engine V1 vLLM, mode preemption default adalah RECOMPUTE. Karena itu, request yang dikeluarkan akan kehilangan cache-nya dan melakukan prefill ulang saat diterima kembali. Pekerjaan tersebut dilakukan dua kali. Dokumentasi memperingatkan bahwa "preemption and recomputation can adversely affect end-to-end latency". Baris log ini merupakan penjelasan terbaik mengapa satu pengguna yang tidak beruntung menunggu jauh lebih lama daripada pengguna lain, sementara nilai rata-rata Anda terlihat normal. Atur disable_log_stats=False untuk mencatat jumlah kumulatif, atau baca penghitung preemption dari metrik Prometheus yang diekspos vLLM.

Perubahan pada 2, 5, dan 20 pengguna bersamaan

Dua pengguna. Hampir tidak terasa pada GPU dengan cache yang masih mencukupi, karena stream decode kedua berjalan bersamaan dengan stream pertama dengan tambahan waktu yang sangat kecil. Pada VPS khusus CPU dengan RAM 4 hingga 8 GB, penggunaan ini tetap memiliki biaya: kedua stream berbagi beberapa vCPU dan bandwidth RAM yang sama, sehingga setiap pengguna memperoleh kira-kira setengah jumlah token per detik, sedangkan kebutuhan cache menjadi dua kali lipat dengan anggaran yang jauh lebih kecil.

Lima pengguna. Pada titik ini, konfigurasi default tidak lagi memadai, dan masalahnya bermula sebagai masalah antrean. Dengan OLLAMA_NUM_PARALLEL pada 1, empat orang menunggu pengguna yang meminta jawaban panjang, dan masing-masing kembali melihat kecepatan normal ketika gilirannya tiba. Jika jumlah paralel dinaikkan, bentuk masalahnya berubah: lima slot dengan konteks 8K memerlukan cache sebesar 40K token. Jika tidak muat di VRAM, engine akan memindahkan layer ke RAM sistem. Jika tidak muat di RAM, mesin akan menggunakan swap dan jumlah token per detik akan turun drastis.

Dua puluh pengguna. Dua puluh orang dalam antarmuka chat biasanya bukan dua puluh permintaan bersamaan. Hal ini paling penting dipahami sebelum membeli hardware. Seseorang membaca jawaban lalu berpikir selama 20 hingga 60 detik sebelum giliran berikutnya, sehingga sebagian besar sesi mereka berada dalam kondisi idle. Dua puluh agent atau dua puluh job peringkasan dokumen merupakan dua puluh stream aktif tanpa waktu idle sama sekali. Ini memerlukan mesin yang berbeda. Developer yang menghubungkan agent coding ke server Ollama miliknya sendiri lebih mendekati kasus kedua daripada kasus pertama, karena agent terus mengirim permintaan selama tugas berjalan dan tidak memiliki jeda membaca seperti manusia.

Pengguna Anda berjalan secara bersamaan, atau hanya login?

Tentukan jumlah request yang sedang diproses sebelum menentukan kapasitas apa pun. Perhitungannya sederhana: jumlah request yang sedang diproses sama dengan jumlah pengguna dikalikan durasi generasi per giliran dalam detik, lalu dibagi jumlah detik antar-giliran.

1. Ukur kecepatan single-stream Anda sendiri terlebih dahulu, baik prefill maupun decode. Jangan menggunakan angka dari kartu milik orang lain: ukur token per detik pada mesin Anda sendiri dan gunakan hasil pengukuran tersebut.
2. Perkirakan duty cycle. Dua puluh pengguna chat, dengan generasi selama 12 detik per giliran dan satu giliran setiap 90 detik, menghasilkan 20 * 12 / 90, yaitu sekitar 2.7 request yang sedang diproses.
3. Tetapkan jumlah slot sedikit di atas angka tersebut, lalu periksa terhadap memori: jumlah slot dikalikan konteks per request harus muat dalam token cache yang benar-benar tersedia.
4. Jaga antrean tetap pendek agar kelebihan kapasitas gagal dengan cepat dan terlihat jelas.

Token cache yang tersedia adalah memori bebas setelah bobot model, dibagi biaya per token dari bagian sebelumnya. Kartu 24 GB yang menjalankan model 8B dalam 16-bit menggunakan sekitar 16 GB untuk bobot dan memiliki sekitar 6 GB cache yang dapat digunakan pada utilisasi default, atau sekitar lima percakapan 8K. Untuk memuat lebih banyak percakapan, pendekkan konteks per request atau simpan cache dalam 8-bit (llama-server membutuhkan --cache-type-k q8_0). Keduanya meningkatkan konkurensi dengan mengorbankan hal tertentu, dan penjelasan yang jujur tentang trade-off tersebut layak dibaca sebelum Anda mengeluarkan biaya untuk perangkat keras: kapan GPU VPS mencapai titik impas dibandingkan token API.

Saat default Ollama tidak lagi memadai

Naikkan jumlah eksekusi paralel melalui unit service, karena export dari shell tidak akan diteruskan ke daemon yang dikelola systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_MAX_QUEUE=64"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama ps

systemctl show harus menampilkan tiga variabel yang baru saja Anda tetapkan. Jika tidak, drop-in tidak tersimpan, dan tindakan lain yang Anda lakukan tidak akan berpengaruh. ollama ps kemudian mencantumkan model yang dimuat dengan ukuran lebih besar daripada bobot model saja, karena empat slot dengan 8,192 token mencadangkan cache sebesar 32,768 token di sampingnya. Kolom PROCESSOR yang menunjukkan sebagian model berada di CPU ketika Anda mengharapkan seluruhnya berada di GPU berarti Anda meminta cache lebih besar daripada kapasitas yang tersisa pada kartu. Kurangi salah satu dari dua angka tersebut. Biasanya, mengurangi context lebih aman, tetapi window yang terlalu kecil akan memotong prompt panjang secara diam-diam, bukan menghasilkan error. Karena itu, sebaiknya tentukan ukuran num_ctx dengan sengaja, bukan terus menurunkannya sampai model muat.

Default queue juga perlu ditinjau. Ollama mengantrekan hingga OLLAMA_MAX_QUEUE request, dan "defaultnya adalah 512". Setelah batas itu terlampaui, Ollama merespons "dengan error 503 yang menunjukkan bahwa server kelebihan beban". Queue sedalam 512 pada server yang melayani empat request sekaligus merupakan janji yang tidak dapat dipenuhi, karena client pada posisi 300 akan timeout jauh sebelum gilirannya. Queue yang pendek mengembalikan error yang dapat dicoba ulang atau dilaporkan oleh aplikasi. Ini lebih baik daripada spinner yang tidak pernah selesai.

Uji secara langsung. Kirim dua request pada saat yang sama dari dua terminal dan pantau keduanya. Jika request kedua tidak menghasilkan apa pun sampai request pertama selesai, pengaturan paralel tidak pernah diterapkan.

Saat mesin serving yang sesungguhnya mulai sepadan dengan biayanya

vLLM sepadan dengan konfigurasi tambahannya jika Anda memiliki GPU dengan kapasitas yang masih tersedia dan lebih dari sekitar empat request yang benar-benar sedang diproses. Scheduler-nya bekerja per token, cache-nya menggunakan paging sehingga fragmen kosong dapat digunakan kembali, dan VRAM yang tersisa diubah menjadi concurrency, bukan dibiarkan menganggur. Per Agustus 2026, instalasi dan peluncuran yang didokumentasikan terdiri atas dua perintah:

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen2.5-1.5B-Instruct",
        "messages": [{"role": "user", "content": "Say hello."}]
    }'

Balasan yang berisi array choices berarti server sudah aktif dan model telah dimuat. Saat menerima beban, dua parameter yang penting adalah --max-num-seqs, yaitu "jumlah maksimum sequence yang diproses dalam satu iterasi", dan --max-num-batched-tokens, yaitu "jumlah maksimum token yang dapat diproses dalam satu iterasi". Parameter pertama membatasi concurrency. Parameter kedua menentukan anggaran chunked prefill yang dijelaskan sebelumnya.

Jika request yang sedang diproses kurang dari sekitar empat, atau server tidak memiliki GPU yang didukung, vLLM menambah kompleksitas tetapi hanya memberikan sedikit manfaat. vLLM memerlukan kartu kelas CUDA dan mengklaim sebagian besar memori saat startup, sehingga tidak sesuai untuk VPS dengan kapasitas 4 hingga 8 GB. Pada kondisi tersebut, gunakan model yang lebih kecil dengan context yang lebih pendek dan queue yang Anda kendalikan. perbedaan Ollama dan vLLM sebagai mesin serving membahas pilihan ini secara lengkap, sedangkan menjalankan Qwen 3 8B pada VPS menunjukkan kebutuhan model berukuran menengah sebelum Anda menambahkan satu pengguna lagi.

Tradeoff yang disembunyikan oleh anggapan umum

Continuous batching meningkatkan throughput total dan biasanya juga memperbaiki latensi median karena request yang masuk antrean dapat mulai diproses lebih cepat. Latensi tail bergerak ke arah sebaliknya, tetapi bagian ini jarang disebutkan.

Setiap sequence tambahan dalam satu step menambah sedikit beban kerja, sehingga ITL meningkat bagi semua pengguna saat batch bertambah penuh. Prefill untuk request baru mengambil sebagian waktu dari sebuah step yang seharusnya dapat digunakan oleh pengguna yang sedang melakukan streaming. Saat cache mengalami tekanan, scheduler melakukan preemption. Akibatnya, request yang baru diproses sebagian harus mengulangi prefill dari awal.

Antarmuka chat menampilkan latensi tail, bukan rata-rata. Stream yang berhenti selama dua detik di tengah kalimat akan terlihat rusak, meskipun total waktu hingga selesai tergolong baik. Ukur p95 TTFT dan p95 ITL dengan beban yang diharapkan, lalu perlakukan rata-rata token per detik sebagai angka kapasitas, bukan sebagai gambaran pengalaman pengguna.

Pengaturan praktisnya mengikuti prinsip tersebut. Batasi concurrency sedikit di bawah kapasitas yang diizinkan memori agar engine tidak perlu melakukan preemption. Antrean pendek yang dapat diprediksi lebih baik daripada batch besar yang mengalami thrashing, karena pengguna yang menunggu empat detik lalu menerima streaming yang lancar akan lebih puas daripada pengguna yang langsung mulai tetapi mengalami dua kali jeda.

Yang harus diperiksa ketika proses lambat

Setiap pengguna berjalan normal, tetapi waktu tunggunya lama. Itu adalah antrean, bukan masalah kecepatan. Periksa pengaturan paralel terlebih dahulu. Model berjalan dengan benar, satu permintaan setiap kali.

HTTP 503 dari Ollama. Antrean penuh. Server mungkin benar-benar sudah mencapai kapasitas, atau OLLAMA_MAX_QUEUE sengaja disetel rendah untuk mengurangi beban, sesuai fungsinya.

Token per detik turun drastis saat beban meningkat pada server berbasis CPU. Jalankan vmstat 1 saat kondisi ini terjadi. Kolom si dan so yang bernilai bukan nol berarti mesin menggunakan swap. Artinya, bobot model dibaca dari disk pada setiap token. Tidak ada perubahan konfigurasi yang dapat mengatasi hal ini. Kurangi ukuran model atau jumlah slot.

Satu dari sepuluh pengguna menunggu jauh lebih lama daripada pengguna lain. Cari preempted dalam log vLLM. Preemption dan proses recompute biasanya menjadi penyebabnya. Ini berarti cache terlalu penuh untuk panjang context yang diizinkan.

TTFT buruk meskipun server sedang idle. Itu adalah masalah prefill, bukan konkurensi. Prompt yang panjang membutuhkan waktu nyata sebelum token pertama muncul. Karena itu, periksa ukuran prompt dan prefix caching sebelum memeriksa hardware. Jika waktu tunggu yang lama hanya dialami pengguna pertama setelah jeda panjang, sedangkan semua pengguna berikutnya tidak mengalaminya, masalahnya bukan prefill. Ollama kemungkinan membongkar model lalu membaca kembali bobotnya dari disk. Hal ini dapat dipastikan dengan mempertahankan model tetap berada di memori di antara permintaan.

FAQ

Mengapa LLM yang saya host sendiri melambat ketika digunakan orang kedua?

Biasanya, LLM tidak benar-benar melambat. Permintaan tersebut masuk antrean. Ollama merilis OLLAMA_NUM_PARALLEL dengan nilai 1, sehingga permintaan kedua menunggu permintaan pertama menghasilkan token terakhirnya. Bedakan kedua kondisi ini dengan mengukur waktu stream pengguna pertama saat pengguna lain menunggu: jika kecepatan token per detik normal setelah stream dimulai, berarti terjadi antrean, dan menaikkan jumlah proses paralel akan mengatasinya. Jika kedua stream berjalan dengan setengah kecepatan, berarti keduanya benar-benar berbagi bandwidth memori, dan itu merupakan batasan perangkat keras.

Berapa banyak pengguna bersamaan yang dapat dilayani satu GPU kecil?

Hitung kapasitas memori, bukan jumlah pengguna. Alokasikan memori untuk weights terlebih dahulu, kemudian KV cache, yang membutuhkan 2 kali jumlah layer dikalikan jumlah key/value heads, dikalikan head dimension, dikalikan jumlah byte, untuk setiap token pada setiap percakapan aktif. Model 8B dengan 36 layer, 8 key/value heads, dan head dimension 128 biasanya membutuhkan sekitar 144 KiB per token dalam format 16-bit. Dengan demikian, percakapan sepanjang 8,192 token membutuhkan sekitar 1.2 GB. Kartu 24 GB yang memuat model tersebut dalam format 16-bit memiliki sekitar 6 GB tersisa untuk cache. Kapasitas itu setara dengan sekitar lima percakapan pada context penuh, atau lebih banyak jika context dipersingkat.

Apakah continuous batching membuat balasan setiap pengguna lebih lambat?

Latensi median biasanya membaik karena permintaan tidak lagi menunggu seluruh batch selesai. Namun, latensi ekor memburuk. Setiap sequence tambahan menambah pekerjaan pada setiap langkah decoding. Kedatangan baru mengambil sebagian waktu satu langkah dari pengguna yang sedang menerima stream, dan permintaan yang mengalami preemption harus menjalankan prefill dua kali. Ukur latensi antartoken p95, bukan rata-ratanya, karena jendela chat membuat jeda terlihat jelas dengan cara yang tidak tercermin dalam nilai rata-rata.

Sebaiknya saya menaikkan OLLAMA_NUM_PARALLEL atau beralih ke vLLM?

Naikkan jumlah proses paralel terlebih dahulu. Cara ini tidak memerlukan biaya dan hanya membutuhkan satu file drop-in. Ini mengatasi kondisi umum ketika empat orang mengantre di belakang satu jawaban panjang. Memori merupakan batasannya: permintaan paralel menggandakan context yang harus ditampung, jadi pantau apakah sebagian layer berpindah ke CPU. Beralihlah ke vLLM ketika GPU memiliki VRAM yang cukup dan lebih dari sekitar empat permintaan benar-benar berjalan bersamaan. Pada titik tersebut, paged cache dan penjadwalan per token memberikan manfaat yang lebih besar daripada biayanya.

Apakah penambahan core CPU akan memperbaiki server LLM yang lambat?

Tidak untuk bagian yang paling dirasakan pengguna. Decode membaca seluruh model dari memori untuk setiap token, sehingga kinerjanya dibatasi oleh bandwidth RAM. Core tambahan tidak lagi membantu setelah bandwidth mencapai kapasitas maksimum. Prefill dapat diskalakan dengan jumlah core, sehingga core yang lebih banyak mengurangi waktu hingga token pertama pada prompt yang panjang. Pada VPS dengan 4 hingga 8 GB, batasan utamanya biasanya kapasitas memori. Solusi yang efektif biasanya model yang lebih kecil atau context yang lebih pendek, bukan penambahan vCPU.