Mengapa LLM Sendiri Perlahan Apabila Ramai Pengguna

Mengapa LLM yang dihoskan sendiri menjadi perlahan apabila bilangan pengguna bertambah?

LLM yang dihoskan sendiri terhenti pada 5 pengguna serentak kerana pelayan masih menjana satu balasan pada satu masa, manakala empat pengguna yang lain berada dalam baris gilir. Dokumentasi Ollama menyatakan secara terus terang tentang tetapan lalai: OLLAMA_NUM_PARALLEL ialah "bilangan maksimum permintaan selari yang akan diproses oleh setiap model pada masa yang sama, lalai 1." Tiada apa-apa yang rosak. Empat daripada lima orang pengguna anda sedang menunggu giliran.

Penyelesaiannya jarang sekali memerlukan pelayan yang lebih berkuasa. Ia memerlukan enjin penyajian yang menolak banyak permintaan melalui model dalam satu forward pass yang sama, serta memori tambahan yang mencukupi untuk menyimpan perbualan setiap orang semasa proses tersebut berjalan. Kedua-dua bahagian ini penting, dan bahagian kedua itulah yang sebenarnya menentukan had kapasiti anda.

Dua fasa yang dilalui oleh setiap permintaan

Prefill membaca keseluruhan prompt sekaligus dan membina cache perhatian (attention cache) untuknya. Setiap token prompt melalui model secara serentak, jadi prefill merupakan satu pendaraban matriks yang besar dan ia dihadkan oleh throughput aritmetik. Decode kemudiannya menulis jawapan satu token pada satu masa. Setiap token memerlukan pemberat (weights) penuh model dibaca daripada memori sekali lagi, manakala pengiraan aritmetik yang dilakukan pada token tunggal itu adalah sangat kecil. Decode dihadkan oleh lebar jalur memori (memory bandwidth).

Ketidaksimetrian ini adalah sebab utama mengapa batching berfungsi. Proses decoding untuk seorang pengguna membaca, katakan, 5 GB pemberat bagi setiap token dan membiarkan kebanyakan unit aritmetik tidak digunakan. Tambahkan permintaan kedua dan enjin membaca 5 GB yang sama sekali, kemudian mengira dua token daripadanya. Pengguna kedua hampir tidak memerlukan masa tambahan. Melayan permintaan secara satu demi satu akan membazirkan kelebihan ini.

Dua nombor menggambarkan apa yang dirasai oleh pengguna. TTFT (time to first token) ialah masa menunggu dalam baris gilir ditambah dengan prefill. ITL (inter-token latency) ialah jurang antara token yang distrim, dan ia ditentukan oleh decode. Pelayan yang perlahan biasanya lambat dalam salah satu perkara ini, dan penyelesaiannya tidak sama.

Batching statik menyebabkan semua orang menunggu respons yang paling perlahan

Batching statik ialah versi naif, dan inilah yang anda peroleh jika anda mengumpulkan permintaan sendiri dalam kod aplikasi. Enjin mengumpul N permintaan, menjalankannya bersama-sama, dan menahan setiap slot sehingga penjanaan paling lama dalam kumpulan tersebut selesai.

Seorang pengguna yang meminta ringkasan 1,200 token menyebabkan empat jawapan satu baris terkunci dalam batch tersebut, kerana batch tidak melepaskan sebarang slot sehingga ahli yang paling perlahan selesai.

Dua kos akan timbul. Jujukan yang telah selesai terus menduduki slot yang tidak mengira apa-apa yang berguna, jadi throughput berkesan menurun apabila panjang output berubah-ubah, dan panjang output sembang sangat berubah-ubah. Permintaan yang tiba satu langkah selepas batch dibentuk perlu menunggu keseluruhan batch selesai sebelum ia memulakan prefill, yang bermaksud TTFT (Time To First Token) ditentukan oleh esei orang lain.

Continuous batching menerima dan menamatkan permintaan bagi setiap token

Continuous batching menjadualkan pada tahap langkah penyahkodan tunggal. Selepas setiap langkah, penjadual akan menggugurkan jujukan yang baru sahaja mengeluarkan token henti, kemudian menerima permintaan yang menunggu ke dalam slot yang kosong. Balasan yang berakhir pada langkah 40 akan mengosongkan slotnya pada langkah 40, bukan pada penghujung kelompok (batch).

Ini bukanlah perkara yang luar biasa. llama-server mendokumentasikan -cb, --cont-batching sebagai "sama ada untuk mendayakan continuous batching (juga dikenali sebagai dynamic batching) (lalai: didayakan)", dan vLLM dibina berdasarkan konsep ini. Ollama juga melayani permintaan selari. Nilai lalai hanya mengehadkan bilangan kepada satu, itulah sebabnya ramai orang membuat kesimpulan bahawa perkakasan mereka tidak mampu melakukan konkurensi, sedangkan konfigurasi merekalah yang menetapkan sebaliknya.

Hasil continuous batching yang diterbitkan biasanya diukur pada kad pusat data yang mempunyai kedua-dua pengkomputeran lebihan dan puluhan gigabait untuk cache. Bentuk hasil tersebut boleh diguna pakai pada mesin anda. Saiznya pula tidak, dan bahagian memori di bawah menjelaskan sebabnya.

Prefill bersaing dengan decode untuk sumber pengkomputeran yang sama

Apabila permintaan baharu tiba semasa empat balasan sedang distrim, prompt permintaan tersebut perlu melalui proses prefill terlebih dahulu, dan prefill merupakan proses yang berat dari segi pengkomputeran. Jika penjadual memberikan langkah khusus untuk prefill tersebut, empat pengguna yang sedang menerima strim tidak akan menerima sebarang token sepanjang tempoh itu. Bagi prompt yang panjang, ini menyebabkan jeda yang ketara pada setiap tetingkap yang terbuka. Inilah yang dimaksudkan dengan gangguan (stutter) apabila pengguna mengatakan pelayan tersangkut setiap kali ada orang lain menekan butang hantar.

Chunked prefill memecahkan prompt yang panjang kepada beberapa bahagian dan mencampurkan setiap bahagian ke dalam langkah yang sama dengan proses decode yang sedang berjalan. Panduan penalaan vLLM menyatakan pertukaran (tradeoff) ini secara langsung: bajet chunk yang lebih kecil "mencapai ITL yang lebih baik kerana terdapat kurang proses prefill yang melambatkan decode", manakala nilai yang lebih tinggi "mencapai masa ke token pertama (TTFT) yang lebih baik kerana anda boleh memproses lebih banyak token prefill dalam satu batch". Anda perlu memilih pengalaman pengguna yang mana untuk diutamakan: individu yang sedang menunggu balasan bermula, atau pengguna yang sedang melihat teks distrim.

Panjang prompt menentukan sejauh mana kesan ini dirasai. Prompt sepanjang 6,000 token dengan jawapan 200 token bermakna 6,000 token kerja prefill berbanding 200 langkah decode. Sembang yang dipertingkatkan dengan pengambilan maklumat (Retrieval-augmented chat) dan prompt sistem yang panjang kedua-duanya menolak anda ke dalam situasi tersebut, sehingga prefill bukan lagi sekadar ralat pembundaran tetapi menjadi perkara yang ditunggu oleh pengguna. Prefix caching membantu apabila bahagian yang panjang itu berulang: vLLM mendedahkan --enable-prefix-caching, yang menggunakan semula cache untuk prefix prompt yang dikongsi dan bukannya mengira semula untuk setiap permintaan.

Memori yang kehabisan ruang terlebih dahulu ialah KV cache

Setiap token dalam setiap perbualan aktif meninggalkan vektor kunci (key vector) dan vektor nilai (value vector) dalam setiap lapisan model. Inilah yang dipanggil KV cache (key/value cache), dan ia membolehkan proses penyahkodan (decode) mengelakkan pengiraan semula keseluruhan prompt bagi setiap token baharu. Saiznya bagi setiap token ditetapkan oleh bentuk model: 2 (satu kunci, satu nilai) didarab dengan bilangan lapisan, didarab dengan bilangan kepala kunci/nilai, didarab dengan dimensi kepala, didarab dengan bait bagi setiap nilai. Baca nombor-nombor tersebut daripada config.json model.

Kira sekali dan had siling tersebut tidak lagi menjadi misteri. Model 8B tipikal dengan 36 lapisan, 8 kepala kunci/nilai dan dimensi kepala 128, yang menyimpan cache dalam 16-bit, memerlukan 2 36 8 128 2 bait bagi setiap token. Ini bersamaan dengan 147,456 bait, kira-kira 144 KiB. Oleh itu, satu perbualan dengan 8,192 token memerlukan kira-kira 1.2 GB cache. Lima perbualan memerlukan kira-kira 6 GB, sebagai tambahan kepada berat (weights) model, dan itulah jawapan sebenar bagi jumlah pengguna yang boleh ditampung.

Konkurensi (concurrency) mendarabkan konteks, dan alatan yang digunakan menyatakan perkara ini dengan jelas. FAQ Ollama: "Pemprosesan permintaan selari bagi model tertentu mengakibatkan peningkatan saiz konteks mengikut bilangan permintaan selari. Sebagai contoh, konteks 2K dengan 4 permintaan selari akan menghasilkan konteks 8K dan peruntukan memori tambahan." RAM yang diperlukan berskala mengikut OLLAMA_NUM_PARALLEL didarab dengan OLLAMA_CONTEXT_LENGTH. Dalam llama-server, konteks yang anda minta dengan -c dikongsi merentasi slot -np, jadi meningkatkan bilangan slot secara sendirinya akan mengecilkan kapasiti yang boleh ditampung oleh setiap permintaan. Baca konteks bagi setiap slot daripada log permulaan dan bukannya membuat andaian.

vLLM melakukan praperuntukan (preallocate) sebaliknya. --gpu-memory-utilization (lalai 0.92) ialah "pecahan memori GPU yang akan digunakan untuk pelaksana model". Apa sahaja yang berbaki selepas berat model diperuntukkan akan menjadi kumpulan KV berhalaman (paged KV pool), dan apabila kumpulan tersebut kehabisan ruang, penjadual akan menyingkirkan (evict) permintaan dan bukannya membiarkannya 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.

Dalam enjin V1 vLLM, mod pra-tuntutan (preemption) lalai ialah RECOMPUTE, jadi permintaan yang disingkirkan akan membuang cache-nya dan melakukan pra-isi (prefill) semula apabila ia diterima masuk semula. Kerja tersebut dilakukan dua kali. Dokumentasi memberi amaran bahawa "pra-tuntutan dan pengiraan semula boleh menjejaskan kependaman (latency) hujung-ke-hujung secara negatif", dan baris log ini merupakan penjelasan terbaik mengapa seorang pengguna yang kurang bernasib baik menunggu jauh lebih lama daripada orang lain walaupun purata prestasi anda kelihatan sihat. Tetapkan disable_log_stats=False untuk merekodkan jumlah terkumpul, atau baca pembilang pra-tuntutan daripada metrik Prometheus yang didedahkan oleh vLLM.

Perubahan pada 2, 5 dan 20 pengguna serentak

Dua pengguna. Hampir tidak kelihatan pada GPU yang mempunyai cache berlebihan, kerana aliran nyahkod kedua berjalan bersama aliran pertama dengan masa tambahan yang sangat sedikit. Pada VPS berasaskan CPU sahaja dengan 4 hingga 8 GB RAM, ia tidak percuma: kedua-dua aliran berkongsi bilangan vCPU dan lebar jalur RAM yang sama, jadi setiap pengguna melihat kira-kira separuh daripada jumlah token sesaat, dan permintaan cache meningkat dua kali ganda berbanding bajet yang jauh lebih kecil.

Lima pengguna. Di sinilah tetapan lalai tidak lagi mencukupi, dan ia bermula sebagai masalah baris gilir. Dengan OLLAMA_NUM_PARALLEL pada 1, empat orang menunggu sesiapa sahaja yang meminta jawapan panjang, dan setiap daripada mereka melihat kelajuan biasa sebaik sahaja giliran mereka tiba. Tingkatkan kiraan selari dan masalah tersebut berubah bentuk: lima slot dengan 8K konteks setiap satu bermakna 40K token cache perlu dicari. Jika ia tidak muat dalam VRAM, enjin akan memindahkan lapisan ke RAM sistem, dan jika ia tidak muat dalam RAM, pelayan akan melakukan swap dan kelajuan token sesaat akan merosot.

Dua puluh pengguna. Dua puluh manusia dalam UI sembang biasanya bukan dua puluh permintaan serentak, dan ini adalah perkara paling berguna untuk difahami sebelum membeli perkakasan. Seseorang membaca balasan dan berfikir selama 20 hingga 60 saat antara giliran, jadi kebanyakan sesi mereka adalah melahu. Dua puluh ejen, atau dua puluh kerja ringkasan dokumen, adalah dua puluh aliran sebenar tanpa masa melahu langsung. Itu memerlukan mesin yang berbeza.

Adakah pengguna anda serentak, atau hanya sekadar log masuk?

Tentukan jumlah permintaan yang sedang diproses sebelum anda menetapkan saiz apa-apa. Pengiraannya mudah: permintaan serentak bersamaan dengan bilangan pengguna, didarab dengan saat yang dihabiskan untuk menjana bagi setiap pusingan, dibahagikan dengan saat antara pusingan.

1. Ukur kelajuan aliran tunggal anda sendiri dahulu, termasuk prapengisian (prefill) dan penyahkodan (decode). Jangan ambil angka daripada kad orang lain: ukur token sesaat pada mesin anda sendiri dan gunakan nilai yang anda peroleh.
2. Anggarkan kitaran tugas (duty cycle). Dua puluh pengguna sembang, 12 saat penjanaan bagi setiap pusingan, satu pusingan setiap 90 saat, memberikan 20 * 12 / 90, iaitu kira-kira 2.7 permintaan serentak.
3. Tetapkan bilangan slot sedikit melebihi jumlah tersebut, kemudian semak terhadap memori: bilangan slot didarab dengan konteks bagi setiap permintaan mestilah muat di dalam token cache yang anda miliki.
4. Pastikan baris gilir pendek supaya limpahan gagal dengan cepat dan jelas.

Token cache yang tersedia adalah memori bebas selepas berat model (weights), dibahagikan dengan kos bagi setiap token daripada bahagian di atas. Kad 24 GB yang menjalankan model 8B dalam 16-bit menggunakan kira-kira 16 GB untuk berat model dan mempunyai kira-kira 6 GB cache yang boleh digunakan pada penggunaan lalai, iaitu sekitar lima perbualan 8K. Untuk memuatkan lebih banyak, pendekkan konteks bagi setiap permintaan, atau simpan cache dalam 8-bit (llama-server mengambil --cache-type-k q8_0). Kedua-duanya meningkatkan konkurensi dengan mengorbankan sesuatu, dan versi jujur mengenai pertukaran tersebut wajar dibaca sebelum anda melaburkan wang pada perkakasan: di mana GPU VPS mencapai titik pulang modal berbanding token API.

Apabila tetapan lalai Ollama tidak lagi mencukupi

Tingkatkan kiraan selari melalui unit servis, kerana eksport shell tidak akan sampai kepada daemon yang diuruskan oleh 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 sepatutnya memaparkan tiga pemboleh ubah yang baru anda tetapkan. Jika tidak, fail drop-in tersebut tidak disimpan, dan tiada tindakan lain yang anda lakukan akan memberi kesan. ollama ps kemudian menyenaraikan model yang dimuatkan dengan saiz yang lebih besar daripada berat model itu sendiri, kerana empat slot pada 8,192 token akan menempah 32,768 token cache di sampingnya. Lajur PROCESSOR yang menunjukkan sebahagian model berada pada CPU sedangkan anda menjangkakan kesemuanya pada GPU bermakna anda meminta lebih banyak cache daripada yang tersedia pada kad tersebut. Rendahkan salah satu daripada dua nombor tersebut.

Nilai lalai baris gilir perlu diberi perhatian khusus. Ollama menyusun sehingga OLLAMA_MAX_QUEUE permintaan, dan "nilai lalai ialah 512". Melebihi had itu, ia akan membalas "dengan ralat 503 yang menunjukkan pelayan terlebih beban". Baris gilir sedalam 512 pada mesin yang melayani empat permintaan serentak adalah janji yang tidak dapat anda tunaikan, kerana klien pada kedudukan 300 akan tamat tempoh (timeout) jauh sebelum gilirannya tiba. Baris gilir yang pendek akan mengembalikan ralat yang boleh dicuba semula atau dilaporkan oleh aplikasi anda, yang lebih baik daripada penunjuk pemuatan (spinner) yang tidak pernah selesai.

Uji perkara ini secara sebenar. Hantar dua permintaan pada saat yang sama daripada dua terminal dan perhatikan kedua-duanya. Jika permintaan kedua tidak menghasilkan apa-apa sehingga permintaan pertama selesai, tetapan selari tersebut tidak berkuat kuasa.

Apabila enjin penyajian sebenar mula memberikan pulangan

vLLM memberikan nilai setara dengan usaha penyediaannya apabila anda mempunyai GPU dengan ruang lebihan dan lebih daripada kira-kira empat permintaan yang benar-benar sedang diproses. Penjadualnya berfungsi mengikut token, cache-nya dipetakan (paged) supaya serpihan memori bebas digunakan semula, dan ia menukarkan VRAM terbiar kepada konkurensi dan bukannya membiarkannya tidak digunakan. Setakat Ogos 2026, pemasangan dan pelancaran yang didokumentasikan hanya memerlukan dua arahan:

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 mengandungi tatasusunan choices bermaksud pelayan telah berjalan dan model telah dimuatkan. Di bawah beban, dua tombol yang penting ialah --max-num-seqs, iaitu "bilangan maksimum jujukan yang diproses dalam satu lelaran", dan --max-num-batched-tokens, iaitu "bilangan maksimum token yang boleh diproses dalam satu lelaran". Nilai pertama mengehadkan konkurensi. Nilai kedua pula ialah bajet prefill berketul (chunked) yang diterangkan sebelum ini.

Di bawah kira-kira empat permintaan yang sedang diproses, atau pada mana-mana mesin tanpa GPU yang disokong, vLLM hanya menambah kerumitan tanpa memberikan banyak manfaat. Ia memerlukan kad kelas CUDA dan menuntut sebahagian besar memori semasa permulaan, yang merupakan pertukaran yang tidak wajar pada VPS bersaiz 4 hingga 8 GB. Untuk kes tersebut, jawapannya ialah model yang lebih kecil dengan konteks yang lebih pendek dan baris gilir yang anda kawal. perbezaan antara Ollama dan vLLM sebagai enjin penyajian merangkumi pilihan tersebut sepenuhnya, dan menjalankan Qwen 3 8B pada VPS menunjukkan keperluan model bersaiz sederhana sebelum anda menambah seorang pun pengguna tambahan.

Pertukaran yang disembunyikan oleh tanggapan umum

Continuous batching meningkatkan jumlah throughput, dan biasanya ia juga menambah baik median latency, kerana permintaan yang beratur bermula lebih awal. Tail latency pula bergerak ke arah sebaliknya, dan bahagian itu jarang sekali disebut.

Setiap urutan tambahan dalam satu langkah menambah sedikit beban kerja, jadi ITL meningkat bagi semua pengguna apabila batch dipenuhi. Prefill bagi permintaan baharu mengambil sebahagian daripada langkah yang sepatutnya diperoleh oleh pengguna yang sedang melakukan streaming. Di bawah tekanan cache, scheduler akan melakukan preemption, yang menghantar permintaan yang separuh dijana kembali ke permulaan fasa prefill.

UI sembang menunjukkan tail latency, bukan purata. Aliran teks yang terhenti selama dua saat di tengah ayat akan dianggap rosak walaupun jumlah masa untuk selesai adalah baik. Ukur p95 TTFT dan p95 ITL di bawah beban yang anda jangkakan, dan anggap purata token per saat sebagai angka kapasiti dan bukannya gambaran pengalaman pengguna.

Tetapan praktikal adalah berdasarkan perkara tersebut. Hadkan concurrency sedikit di bawah tahap yang dibenarkan oleh memori, supaya enjin tidak perlu melakukan preemption. Barisan yang pendek dan boleh diramal adalah lebih baik daripada batch yang besar tetapi menyebabkan thrashing, kerana pengguna yang menunggu selama empat saat dan kemudian menerima aliran teks yang lancar adalah lebih berpuas hati berbanding pengguna yang bermula serta-merta tetapi terhenti sebanyak dua kali.

Perkara yang perlu diperiksa apabila prestasi perlahan

Setiap pengguna adalah normal, tetapi masa menunggu lama. Ini adalah masalah baris gilir, bukan masalah kelajuan. Periksa tetapan selari (parallel) terlebih dahulu. Model berfungsi dengan betul, satu permintaan pada satu masa.

HTTP 503 daripada Ollama. Baris gilir sudah penuh. Sama ada pelayan benar-benar mencapai kapasiti, atau OLLAMA_MAX_QUEUE ditetapkan rendah dengan sengaja untuk mengurangkan beban, yang merupakan tindakan yang sepatutnya dilakukan.

Token sesaat (tokens per second) merosot di bawah beban pada pelayan CPU. Jalankan vmstat 1 semasa ia berlaku. Lajur si dan so yang bukan sifar bermakna mesin sedang melakukan swapping, jadi pemberat (weights) sedang dibaca daripada cakera pada setiap token. Tiada perubahan konfigurasi yang dapat mengatasi masalah ini. Kurangkan saiz model atau bilangan slot.

Seorang daripada sepuluh pengguna menunggu jauh lebih lama daripada yang lain. Cari preempted dalam log vLLM. Preemption dan pengiraan semula (recompute) biasanya menjadi punca, dan ini bermakna cache telah terlebih langgan (oversubscribed) untuk panjang konteks yang anda benarkan.

TTFT teruk walaupun pelayan melahu. Ini adalah masalah prefill, bukan konkurensi. Prompt yang panjang mengambil masa sebenar sebelum token pertama muncul, jadi periksa saiz prompt dan prefix caching sebelum anda memeriksa perkakasan.

FAQ

Mengapa LLM yang saya hos sendiri menjadi perlahan apabila orang kedua menggunakannya?

Kebiasaannya ia tidak menjadi perlahan. Ia beratur. Ollama dikeluarkan dengan OLLAMA_NUM_PARALLEL pada 1, jadi permintaan kedua menunggu sehingga permintaan pertama mengeluarkan token terakhirnya. Bezakan kedua-dua keadaan ini dengan mengukur masa aliran satu pengguna sementara pengguna lain menunggu: jika token per saat mereka adalah normal sebaik sahaja mereka bermula, anda mempunyai barisan, dan meningkatkan kiraan selari akan menyelesaikannya. Jika kedua-dua aliran berjalan pada separuh kelajuan, anda sebenarnya berkongsi lebar jalur memori, dan itu adalah had perkakasan.

Berapa ramai pengguna serentak yang boleh diservis oleh satu GPU kecil?

Kira memori, bukan pengguna. Berat (weights) didahulukan, kemudian cache KV, yang menelan kos 2 kali lapisan kali kepala kunci/nilai kali dimensi kepala kali bait, bagi setiap token, bagi setiap perbualan aktif. Model 8B tipikal dengan 36 lapisan, 8 kepala kunci/nilai dan dimensi kepala 128 menelan kos kira-kira 144 KiB bagi setiap token dalam 16-bit, jadi perbualan 8,192 token memerlukan kira-kira 1.2 GB. Kad 24 GB yang memuatkan model tersebut dalam 16-bit mempunyai kira-kira 6 GB yang tinggal untuk cache, iaitu kira-kira lima perbualan pada konteks penuh, atau lebih jika anda memendekkan konteks.

Adakah continuous batching menjadikan balasan setiap pengguna lebih perlahan?

Latensi median biasanya bertambah baik, kerana permintaan berhenti menunggu keseluruhan kelompok selesai. Latensi ekor menjadi lebih teruk. Setiap urutan tambahan menambah kerja pada setiap langkah penyahkodan, prefill ketibaan baharu mencuri sebahagian daripada langkah daripada pengguna yang sedang menstrim, dan permintaan yang didahului (preempted) perlu melakukan prefill dua kali. Ukur latensi antara token p95, bukan purata, kerana tetingkap sembang menjadikan jeda jelas kelihatan dengan cara yang disembunyikan oleh purata.

Patutkah saya meningkatkan OLLAMA_NUM_PARALLEL atau beralih ke vLLM?

Tingkatkan kiraan selari dahulu. Ia percuma dan hanya memerlukan satu fail drop-in, dan ia menyelesaikan kes biasa di mana empat orang beratur di belakang satu jawapan yang panjang. Memori adalah hadnya: permintaan selari mendarabkan konteks yang perlu anda pegang, jadi perhatikan lapisan yang melimpah ke CPU. Beralih ke vLLM apabila anda mempunyai GPU dengan VRAM yang mencukupi dan lebih daripada kira-kira empat permintaan yang benar-benar sedang berjalan, kerana itu adalah titik di mana paged cache dan penjadualan per-token memberikan hasil yang lebih berbaloi daripada kosnya.

Adakah lebih banyak teras CPU akan membaiki pelayan LLM yang perlahan?

Tidak untuk bahagian yang paling disedari oleh pengguna. Penyahkodan membaca keseluruhan model daripada memori untuk setiap token, jadi ia terikat dengan lebar jalur RAM, dan teras tambahan berhenti membantu sebaik sahaja lebar jalur tepu. Prefill memang berskala dengan teras, jadi lebih banyak teras memendekkan masa untuk token pertama pada prompt yang panjang. Pada VPS 4 hingga 8 GB, kekangan pengikatan biasanya adalah kapasiti memori, dan penyelesaian yang berkesan ialah model yang lebih kecil atau konteks yang lebih pendek dan bukannya lebih banyak vCPU.