llama.cpp প্রম্পট প্রসেসিং 35 গুণ ধীর? q5_1 KV ক্যাশে ঠিক করুন

আপনার লোকাল মডেল ঠিকঠাক উত্তর দেয়, কিন্তু এখন প্রতিটি লম্বা প্রম্পটে দেড় মিনিট অপেক্ষা করতে হয়, আর GPU কিছুই করে না। যদি আপনি llama.cpp চালান -fa on এবং q5_1 KV ক্যাশে দিয়ে, সম্ভবত এটাই কারণ: ডিফল্ট CUDA বিল্ডে সেই ক্যাশে টাইপের জন্য কোনো ফ্ল্যাশ-অ্যাটেনশন কার্নেল নেই, তাই অ্যাটেনশন ধাপটি চুপচাপ CPU-তে চলে। ক্যাশে q8_0-এ পরিবর্তন করলে একজন রিপোর্টারের প্রম্পট প্রসেসিং 38 থেকে 1348 টোকেন/সে-এ উন্নীত হয়।

নিচের সংখ্যাগুলো llama.cpp ইস্যু #28455 (৫ সেপ্টেম্বর ২০২৬-এ খোলা, বিল্ড 10791, ২৮ অক্টোবর ২০২৬-এ যাচাইকৃত) থেকে নেওয়া। একজন রিপোর্টার, একটি RTX 4080, একটি 27B মডেল, তাই এগুলোকে একটি উদাহরণ হিসেবে পড়ুন, নিয়ম হিসেবে নয়। তাদের মূল-কারণ বিশ্লেষণও তাদেরই: একজন মেইনটেইনার এটিকে "একটি পরিচিত সমস্যা" বলে পরের দিন ইস্যুটি বন্ধ করে দেন।

স্ক্রিনে এটি কেমন দেখায়#

সেটআপ সাধারণ ছিল। কেউ একটি 16 GB কার্ডে 131072-টোকেন কনটেক্সট চেয়েছিলেন, তাই তারা KV ক্যাশে ছোট করে q5_1 করেন:

llama-server -m model.gguf -ngl 99 -fa on -c 131072 -np 4 \
  --cache-type-k q5_1 --cache-type-v q5_1

তারপর তারা একটি 3.6K-টোকেন প্রম্পট পাঠান। প্রম্পট প্রসেসিং 38.4 টোকেন/সে-এ চলেছিল এবং ডিকোডিং 6.5 টোকেন/সে-এ। ভাগ করুন: 3,600 ÷ 38.4 = 93.75, তাই প্রথম শব্দের আগে প্রায় 94 সেকেন্ড। q8_0 দিয়ে একই প্রম্পট 1348 টোকেন/সে-এ চলেছিল: 3,600 ÷ 1,348 = 2.67, তিন সেকেন্ডের কম।

ইঙ্গিতটি টাস্ক ম্যানেজারে। ধীর রানগুলোর সময় GPU প্রায় 0% এ ছিল যখন CPU প্রায় 930% দেখাচ্ছিল (নয় বা দশটি কোর ব্যস্ত)। আপনি যখন "GPU-তে চালাচ্ছেন" তখন একটি GPU অলস বসে থাকা — এটাই লক্ষণ যা খুঁজতে হবে।

কেন একটি ছোট ক্যাশে এটিকে এতটা ধীর করে#

ফ্ল্যাশ অ্যাটেনশন একটি ফিউজড GPU কার্নেল। ডিফল্ট CUDA বিল্ড এটি শুধুমাত্র কিছু KV ক্যাশে টাইপ জোড়ার জন্য সরবরাহ করে। q4_0, q4_1, q5_0 এবং q5_1-এর জন্য কোনো কার্নেল নেই, তাই llama.cpp ত্রুটি দিয়ে থামে না। এটি সেই অপারেশনটি CPU-তে সরিয়ে নেয় এবং চালিয়ে যায়। সবকিছু এখনও কাজ করে, শুধু প্রম্পট প্রসেসিং-এ প্রায় 35 গুণ ধীর (1348 ÷ 38.4 = 35.1)।

সেই "চুপচাপ"-ই পুরো সমস্যা। উত্তরে কিছুই আপনাকে জানায় না। প্রম্পট প্রসেসিং সবচেয়ে বেশি কমে (প্রায় 35×), এবং জেনারেশনও ধীর হয়: একই ইস্যুতে q8_0-এর সাথে 30.1-এর বিপরীতে 6.5 টোকেন/সে।

দুই মিনিটে যাচাই করুন#

সার্ভারে আপনি যে ক্যাশে টাইপ ব্যবহার করেন সেগুলো দিয়ে llama-bench চালান, প্রতি ভ্যারিয়েন্টে একবার, এবং অন্য টার্মিনালে GPU দেখুন:

llama-bench -m model.gguf -ngl 99 -fa 1 -ctk q8_0 -ctv q8_0 -p 512 -n 0
llama-bench -m model.gguf -ngl 99 -fa 1 -ctk q5_1 -ctv q5_1 -p 512 -n 0
nvidia-smi -l 1

একটি Qwen 27B Q5_K_XL-এ রিপোর্টারের pp512 ফলাফল: q8_0/q8_0-এর জন্য 1511.92 টোকেন/সে, ডিফল্ট বিল্ডে q5_1/q5_1-এর জন্য প্রায় 197। যদি আপনার দুই লাইনে এমন ব্যবধান দেখায় এবং nvidia-smi দ্বিতীয়টির সময় GPU অলস দেখায়, আপনি এটি খুঁজে পেয়েছেন।

কিছু ঠিক করার আগে, আপনি যা দেখছেন তা সম্ভাব্য কারণের সাথে মিলিয়ে নিন:

সমাধান ১: q8_0 ব্যবহার করুন (অথবা পুনরায় বিল্ড করুন)#

দ্রুততম সমাধান হল দুটি ফ্ল্যাগ পরিবর্তন করা এবং বাকি সবকিছু রাখা:

llama-server -m model.gguf -ngl 99 -fa on -c 131072 -np 4 \
  --cache-type-k q8_0 --cache-type-v q8_0

ইস্যুতে এটি প্রম্পট প্রসেসিং-এ 1348 টোকেন/সে এবং ডিকোডিং-এ 30.1 টোকেন/সে দিয়েছিল (6.5 থেকে বৃদ্ধি)। মূল্য হল মেমরি: একটি q8_0 ক্যাশে q5_1-এর চেয়ে বড়, তাই যাচাই করুন যে আপনার কনটেক্সট দৈর্ঘ্য এখনও VRAM-এ ফিট করে।

যদি মেমরির কারণে আপনাকে q5_1 রাখতেই হয়, তাহলে সমস্ত ফ্ল্যাশ-অ্যাটেনশন ক্যাশে সমন্বয় কম্পাইল করে পুনরায় বিল্ড করুন:

cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

সেই বিল্ড pp512-এ q5_1 1509.70 টোকেন/সে-এ এবং 3.6K-টোকেন প্রম্পটে 1162 টোকেন/সে-এ চালিয়েছিল, ডিকোডিং 38.5 টোকেন/সে-এ। ইস্যুতে একজন মন্তব্যকারী উল্লেখ করেছেন যে ব্যাকএন্ডের মধ্যে কাজ সরানো সংখ্যাগত ফলাফল কিছুটা পরিবর্তন করতে পারে এবং বিল্ডগুলোর মধ্যে একটি পারপ্লেক্সিটি তুলনার পরামর্শ দিয়েছেন। যদি আপনি সঠিক আউটপুট সম্পর্কে যত্নশীল হন, একটি চালান।

মেইনটেইনারের "পরিচিত সমস্যা" উত্তরটি বলে না যে বর্তমান llama.cpp সংস্করণগুলো এটি পরিবর্তন করেছে কিনা। সৎ যাচাই হল উপরের llama-bench জোড়া: যদি উভয় লাইন কাছাকাছি হয়, আপনি ঠিক আছেন।

কখন টিউনিং আর মূল্যবান নয়#

ধরুন আপনি সমাধানটি কাজ করিয়েছেন, এবং এখন আপনি পরবর্তী রাউন্ডের ওজন করছেন: আরও ফ্ল্যাগ, একটি দ্বিতীয় GPU, একটি ছোট কোয়ান্ট। যদি কাজটি কয়েক হাজার টোকেনের প্রম্পটে সারাংশ, কোড রিভিউ বা এক্সট্রাকশন হয়, তাহলে জিজ্ঞাসা করুন একটি অনুরোধ আপনার কতটা সময় ও শ্রম নেয়, শুধু ওয়াট নয়।

এখানে তুলনার জন্য একটি উল্লিখিত ওয়ার্কলোড। ধরুন একটি সারাংশকরণ কাজ 3,600 ইনপুট টোকেন পাঠায় এবং 500 ফেরত পায়, 1,000 বার। CheapTokens-এ এটি DeepSeek-V4-Flash-এ (380K কনটেক্সট, প্রতি উত্তরে সর্বোচ্চ 32,768 আউটপুট টোকেন, যেকোনো সময়ে এক মূল্য) প্রায় $0.104 এবং GLM-5.3-Flash-এ (390K কনটেক্সট) প্রায় $0.092। টেবিলটি ইনপুট এবং আউটপুট একসাথে গণনা করে, তুলনার জন্য একটি OpenRouter কলাম সহ:

API আপনার ক্যাশে টাইপ, আপনার VRAM বা আপনার বিল্ড ফ্ল্যাগ সম্পর্কে চিন্তা করে না; CPU-তে ফিরে যাওয়ার কিছু নেই। প্রথমে আপনার আসল প্রম্পটের কয়েকটি পাঠান এবং উত্তরগুলো নিজেই বিচার করুন। ধাপটি ছোট: এন্ডপয়েন্টটি OpenAI Chat Completions ফরম্যাটে কথা বলে, তাই বেশিরভাগ লোকাল ক্লায়েন্টের শুধু একটি নতুন বেস URL দরকার।

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize the text below in 5 bullets: ..."}], "max_tokens": 500}'

সম্পূর্ণ সেটআপ CheapTokens ডক্স-এ আছে, এবং বর্তমান প্রতি-মডেল মূল্য মূল্য পৃষ্ঠা-এ। হার্ডওয়্যার বনাম API-এর একটি দীর্ঘতর আলোচনার জন্য, দেখুন DeepSeek লোকালি চালান বা একটি API ব্যবহার করুন। যদি আপনি দেখতে চান কীভাবে ইনপুট এবং আউটপুট আলাদাভাবে বিল করা হয়, ইনপুট বনাম আউটপুট টোকেন তা কভার করে।

যে ক্রমে কাজ করবেন#

উৎস সম্পর্কে আরও একটি সতর্কতা: পুরো রোগনির্ণয় একটি পাবলিক ইস্যু এবং একটি GPU-এর উপর নির্ভর করে। 1348 এবং 38.4-কে সেখানে যা ঘটেছে তা হিসেবে গণ্য করুন, এবং কোনোটিকে বিশ্বাস করার আগে আপনার নিজের কার্ড পরিমাপ করুন।