Mengapa LLM Self-Hosted Lambat Saat 5 Pengguna

Mengapa LLM yang di-host sendiri melambat saat lebih banyak pengguna terhubung?

LLM yang di-host sendiri berhenti merespons pada 5 pengguna serentak karena server masih menghasilkan satu jawaban pada satu waktu, sementara 4 pengguna lainnya menunggu dalam antrean. Dokumentasi Ollama menjelaskan pengaturan default ini secara tegas: OLLAMA_NUM_PARALLEL adalah "jumlah maksimum permintaan paralel yang diproses setiap model pada saat yang sama, default 1." Tidak ada kerusakan. 4 dari 5 pengguna Anda sedang menunggu giliran.

Solusinya biasanya bukan server yang lebih besar. Yang diperlukan adalah mesin penyajian yang memproses banyak permintaan melalui model dalam satu forward pass, serta memori cadangan yang cukup untuk menyimpan percakapan semua pengguna selama proses tersebut berlangsung. Kedua hal ini penting, dan faktor kedua yang sebenarnya menentukan batas maksimum Anda.

Dua fase yang dilalui setiap permintaan

Prefill membaca seluruh prompt sekaligus dan membangun cache attention untuk prompt tersebut. Semua token dalam prompt diproses model secara bersamaan. Karena itu, prefill merupakan 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 kembali dibaca dari memori, sedangkan operasi aritmetika pada satu token tersebut sangat sedikit. Decode dibatasi oleh bandwidth memori.

Asimetri inilah yang menjadi alasan utama batching efektif. Decode untuk satu pengguna, misalnya, membaca 5 GB bobot per token dan membuat sebagian besar unit aritmetika menganggur. Jika permintaan kedua ditambahkan, engine membaca 5 GB yang sama satu kali, lalu menghitung dua token dari data tersebut. Pengguna kedua hampir tidak menambah waktu pemrosesan. Memproses permintaan secara ketat satu per satu menghilangkan keuntungan tersebut.

Dua angka menggambarkan pengalaman pengguna. TTFT (time to first token) terdiri atas waktu tunggu dalam antrean dan 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.

Pengelompokan statis membuat semua permintaan menunggu respons paling lambat

Pengelompokan statis adalah versi naif. Inilah yang Anda dapatkan jika mengelompokkan permintaan sendiri dalam kode aplikasi. Engine mengumpulkan N permintaan, menjalankannya secara bersamaan, lalu mempertahankan setiap slot hingga generasi terlama dalam kelompok tersebut selesai.

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

Ada dua konsekuensi. Sequence yang sudah selesai tetap menempati slot tanpa melakukan komputasi yang berguna. Akibatnya, throughput efektif menurun saat panjang output bervariasi, dan panjang output pada 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 menyelesaikan request pada setiap token

Continuous batching menjadwalkan request pada tingkat satu langkah decoding. Setelah setiap langkah, scheduler menghapus sequence yang baru saja menghasilkan stop token, lalu menerima request yang menunggu ke slot yang tersedia. Jika sebuah respons selesai pada langkah 40, slotnya tersedia kembali pada langkah 40, bukan setelah seluruh batch selesai.

Ini bukan fitur yang eksotis. llama-server mendokumentasikan -cb, --cont-batching sebagai “apakah continuous batching (disebut juga dynamic batching) diaktifkan (default: enabled)”, 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 perangkat keras mereka tidak dapat menjalankan concurrency, padahal konfigurasinya yang menonaktifkan concurrency.

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. Besar peningkatannya tidak sama. Bagian tentang memori di bawah menjelaskan alasannya.

Prefill bersaing dengan decode untuk komputasi yang sama

Saat request baru masuk ketika empat balasan sedang dialirkan, prompt request tersebut harus menjalani prefill terlebih dahulu, dan prefill membutuhkan banyak komputasi. Jika scheduler memberikan satu langkah khusus untuk prefill tersebut, keempat pengguna yang sedang menerima aliran tidak mendapatkan token selama langkah itu. Pada prompt yang panjang, setiap jendela yang terbuka akan mengalami jeda yang terlihat. Inilah stutter yang dimaksud ketika orang mengatakan bahwa server tersendat setiap kali pengguna lain menekan tombol kirim.

Chunked prefill membagi prompt yang panjang menjadi beberapa bagian, lalu mencampurkan setiap bagian ke dalam langkah yang sama dengan proses decode yang sedang berjalan. Panduan tuning vLLM menjelaskan trade-off 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 harus memilih pengalaman siapa yang ingin diprioritaskan: orang yang menunggu balasan mulai muncul, atau orang yang sedang melihat teks dialirkan.

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

Cache KV adalah memori yang pertama kali habis

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. Ukuran cache 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 nilai. Ambil angka-angka tersebut dari config.json model.

Hitung satu kali, dan batas kapasitasnya tidak lagi menjadi misteri. Model 8B yang umum, dengan 36 layer, 8 head key/value, dan dimensi head 128, jika cache disimpan dalam format 16-bit, memerlukan 2 36 8 128 2 byte per token. Nilainya adalah 147,456 byte, atau sekitar 144 KiB. Satu percakapan dengan 8,192 token memerlukan sekitar 1.2 GB cache. Lima percakapan memerlukan sekitar 6 GB, di luar bobot model. Itulah jawaban sebenarnya untuk menentukan jumlah pengguna yang dapat ditangani.

Konkurensi menggandakan kebutuhan konteks, dan tool menampilkannya secara langsung. FAQ Ollama menyatakan: "Pemrosesan permintaan paralel untuk model tertentu meningkatkan ukuran konteks sesuai jumlah permintaan paralel. Misalnya, konteks 2K dengan 4 permintaan paralel akan menghasilkan konteks 8K dan alokasi memori tambahan." RAM yang diperlukan bertambah sesuai OLLAMA_NUM_PARALLEL dikalikan OLLAMA_CONTEXT_LENGTH. Dalam llama-server, konteks yang Anda minta dengan -c dibagi ke seluruh -np slot. Karena itu, menaikkan jumlah slot saja akan mengurangi kapasitas setiap permintaan. Baca konteks per slot dari log startup, bukan dengan mengasumsikannya.

vLLM melakukan praalokasi. --gpu-memory-utilization (default 0.92) adalah "fraksi memori GPU yang digunakan untuk model executor". Memori yang tersisa setelah bobot model menjadi pool KV berpaginasi. Jika pool tersebut kehabisan ruang, scheduler mengeluarkan sebuah permintaan, 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, permintaan yang dikeluarkan akan membuang cache-nya dan melakukan prefill kembali saat diterima lagi. Pekerjaan tersebut dilakukan dua kali. Dokumentasi memperingatkan bahwa "preemption dan rekalkulasi dapat berdampak buruk pada latensi end-to-end". Baris log ini merupakan penjelasan terbaik mengapa satu pengguna yang tidak beruntung harus menunggu jauh lebih lama daripada pengguna lain, sementara rata-rata Anda terlihat baik. 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 secara bersamaan

Dua pengguna. Bebannya hampir tidak terlihat pada GPU yang masih memiliki cache, karena aliran decode kedua berjalan bersama aliran pertama dengan tambahan waktu yang sangat kecil. Pada VPS yang hanya menggunakan CPU dengan RAM 4 hingga 8 GB, beban ini tetap signifikan: kedua aliran berbagi beberapa vCPU dan bandwidth RAM yang sama. Akibatnya, setiap pengguna memperoleh kira-kira setengah jumlah token per detik, sementara kebutuhan cache menjadi dua kali lipat dengan anggaran yang jauh lebih kecil.

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

Dua puluh pengguna. Dua puluh orang dalam antarmuka chat biasanya bukan dua puluh permintaan yang berjalan secara bersamaan. Hal ini paling penting untuk dipahami sebelum membeli hardware. Seseorang membaca jawaban lalu berpikir selama 20 hingga 60 detik sebelum mengirim permintaan berikutnya, sehingga sebagian besar sesinya dalam keadaan idle. Dua puluh agen atau dua puluh tugas peringkasan dokumen merupakan dua puluh aliran nyata tanpa waktu idle sama sekali. Kebutuhan tersebut memerlukan mesin yang berbeda.

Apakah pengguna Anda berjalan secara bersamaan, atau hanya login?

Tentukan jumlah request yang sedang diproses sebelum menentukan ukuran sistem. Perhitungannya sederhana: jumlah request yang sedang diproses sama dengan jumlah pengguna dikalikan durasi pembuatan per giliran, lalu dibagi interval antargiliran dalam detik.

1. Ukur kecepatan single-stream Anda sendiri terlebih dahulu, baik prefill maupun decode. Jangan mengambil angka dari GPU orang lain: ukur token per detik pada mesin Anda sendiri dan gunakan hasil pengukuran tersebut.
2. Perkirakan duty cycle. Dua puluh pengguna chat, dengan durasi pembuatan 12 detik per giliran dan satu giliran setiap 90 detik, menghasilkan 20 * 12 / 90, atau 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 jumlah token cache yang benar-benar tersedia.
4. Pertahankan antrean tetap pendek agar kelebihan kapasitas segera gagal dan terlihat jelas.

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

Saat default Ollama tidak lagi mencukupi

Tingkatkan jumlah proses paralel melalui unit service, karena export pada 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 belum tersimpan dan tindakan lain yang Anda lakukan tidak akan berpengaruh. ollama ps kemudian menampilkan 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. Jika kolom PROCESSOR menunjukkan sebagian model berada di CPU, padahal Anda mengharapkan seluruhnya berada di GPU, berarti Anda meminta cache yang lebih besar daripada sisa kapasitas kartu. Kurangi salah satu dari dua angka tersebut.

Default antrean perlu diperiksa kembali. Ollama mengantrekan hingga OLLAMA_MAX_QUEUE permintaan, dan "default-nya adalah 512". Setelah batas itu terlampaui, Ollama merespons "dengan error 503 yang menunjukkan bahwa server kelebihan beban". Antrean sedalam 512 pada server yang hanya melayani empat permintaan secara bersamaan merupakan janji yang tidak dapat dipenuhi, karena client pada posisi 300 akan mengalami timeout jauh sebelum gilirannya. Antrean 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 permintaan pada saat yang sama dari dua terminal dan pantau keduanya. Jika permintaan kedua tidak menghasilkan apa pun sampai permintaan pertama selesai, pengaturan proses paralel belum diterapkan.

Saat serving engine yang sebenarnya mulai memberikan hasil

vLLM layak digunakan setelah penyiapan tambahannya jika Anda memiliki GPU dengan kapasitas tersisa dan lebih dari sekitar empat permintaan yang benar-benar sedang diproses secara bersamaan. Penjadwalnya bekerja per token, cache-nya menggunakan paging sehingga fragmen yang kosong dapat digunakan kembali, dan VRAM yang tersisa dikonversi menjadi konkurensi, bukan dibiarkan menganggur. Per Agustus 2026, instalasi dan peluncuran yang didokumentasikan terdiri dari 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."}]
    }'

Respons yang berisi array choices berarti server sudah berjalan 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 konkurensi. Parameter kedua menetapkan anggaran chunked prefill yang dijelaskan sebelumnya.

Jika jumlah permintaan yang sedang diproses kurang dari sekitar empat, atau jika server tidak memiliki GPU yang didukung, vLLM menambah kompleksitas tetapi memberikan sedikit manfaat. vLLM memerlukan kartu kelas CUDA dan mengambil sebagian besar memori saat startup, sehingga trade-off ini tidak sesuai untuk VPS dengan kapasitas 4 hingga 8 GB. Dalam kondisi tersebut, gunakan model yang lebih kecil dengan context yang lebih pendek dan queue yang Anda kendalikan. perbedaan Ollama dan vLLM sebagai serving engine 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 aspek ini jarang disebutkan.

Setiap sequence tambahan dalam satu step menambah sedikit pekerjaan, sehingga ITL meningkat untuk semua pengguna ketika batch semakin penuh. Prefill untuk request baru mengambil sebagian waktu dari sebuah step yang seharusnya dapat digunakan oleh pengguna yang sedang menerima streaming. Saat cache mengalami tekanan, scheduler melakukan preemption. Akibatnya, request yang baru diproses sebagian harus kembali ke awal tahap prefill.

Antarmuka chat menampilkan latensi tail, bukan rata-rata. Streaming yang berhenti selama dua detik di tengah kalimat terlihat rusak, meskipun total waktu hingga selesai tetap baik. Ukur p95 TTFT dan p95 ITL berdasarkan beban yang Anda perkirakan, 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 batas yang diizinkan oleh memori agar engine tidak perlu melakukan preemption. Antrean pendek yang dapat diprediksi lebih baik daripada batch besar yang terus mengalami thrashing. Pengguna akan lebih puas jika harus menunggu empat detik lalu menerima streaming yang lancar daripada jika proses langsung dimulai tetapi terhenti dua kali.

Hal yang perlu diperiksa saat proses lambat

Setiap pengguna mendapatkan performa normal, tetapi waktu tunggunya lama. Ini adalah masalah antrean, bukan masalah kecepatan. Periksa pengaturan paralel terlebih dahulu. Model berjalan dengan benar, satu permintaan pada satu waktu.

Ollama mengembalikan HTTP 503. Antrean sudah penuh. Server mungkin memang sudah mencapai kapasitas, atau OLLAMA_MAX_QUEUE sengaja disetel rendah untuk mengurangi beban. Perilaku tersebut memang diharapkan.

Token per detik turun drastis saat beban meningkat pada server berbasis CPU. Jalankan vmstat 1 saat kondisi tersebut terjadi. Kolom si dan so yang bernilai nonzero berarti mesin sedang 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 lainnya. Cari preempted dalam log vLLM. Preemption dan recompute yang menyertainya biasanya menjadi penyebabnya. Ini berarti cache terlalu penuh untuk panjang konteks yang diizinkan.

TTFT buruk meskipun server sedang idle. Ini 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 perangkat keras.

FAQ

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

Biasanya, LLM tidak benar-benar melambat. Permintaan tersebut masuk ke antrean. Ollama dirilis dengan OLLAMA_NUM_PARALLEL bernilai 1, sehingga permintaan kedua menunggu hingga permintaan pertama menghasilkan token terakhirnya. Bedakan kedua kondisi ini dengan mengukur waktu streaming satu pengguna saat pengguna lain menunggu: jika kecepatan token per detik kembali normal setelah streaming dimulai, berarti terjadi antrean, dan peningkatan jumlah proses paralel dapat mengatasinya. Jika kedua streaming berjalan dengan setengah kecepatan, berarti keduanya benar-benar berbagi bandwidth memori. Ini merupakan batasan perangkat keras.

Berapa banyak pengguna konkuren yang dapat dilayani satu GPU kecil?

Hitung kapasitas memori, bukan jumlah pengguna. Hitung bobot model terlebih dahulu, lalu KV cache, yang membutuhkan 2 kali jumlah layer dikali jumlah key/value heads dikali dimensi head dikali jumlah byte, untuk setiap token pada setiap percakapan aktif. Model 8B yang umum dengan 36 layer, 8 key/value heads, dan dimensi head 128 membutuhkan sekitar 144 KiB per token dalam 16-bit. Dengan demikian, percakapan sepanjang 8,192 token membutuhkan sekitar 1.2 GB. GPU 24 GB yang memuat model tersebut dalam 16-bit memiliki sekitar 6 GB tersisa untuk cache. Kapasitas ini cukup untuk sekitar lima percakapan dengan context penuh, atau lebih banyak percakapan 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 suatu langkah dari pengguna yang sedang menerima streaming, dan permintaan yang mengalami preemption harus menjalankan prefill dua kali. Ukur latensi antartoken p95, bukan rata-ratanya. Jendela chat membuat jeda terlihat jelas, sedangkan nilai rata-rata dapat menyembunyikannya.

Apakah saya sebaiknya meningkatkan OLLAMA_NUM_PARALLEL atau beralih ke vLLM?

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

Apakah penambahan core CPU dapat memperbaiki server LLM yang lambat?

Tidak untuk bagian yang paling dirasakan pengguna. Proses decode membaca seluruh model dari memori untuk setiap token, sehingga dibatasi oleh bandwidth RAM. Core tambahan tidak lagi membantu setelah bandwidth mencapai kapasitas maksimum. Proses prefill dapat memanfaatkan core tambahan, sehingga waktu hingga token pertama pada prompt panjang menjadi lebih singkat. Pada VPS 4 hingga 8 GB, batas utama biasanya adalah kapasitas memori. Solusi yang efektif biasanya berupa model yang lebih kecil atau context yang lebih pendek, bukan penambahan vCPU.