llama.cpp प्रॉम्प्ट प्रोसेसिंग 35x धीमी? q5_1 KV कैश ठीक करें

आपका लोकल मॉडल ठीक जवाब देता है, लेकिन अब हर लंबा प्रॉम्प्ट डेढ़ मिनट तक वहीं अटका रहता है जबकि GPU कुछ नहीं कर रहा। अगर आप llama.cpp को -fa on और q5_1 KV कैश के साथ चलाते हैं, तो शायद यही कारण है: डिफ़ॉल्ट CUDA बिल्ड में उस कैश टाइप के लिए कोई flash-attention कर्नेल नहीं है, इसलिए attention स्टेप चुपचाप CPU पर चलता है। कैश को q8_0 पर बदलने से एक रिपोर्टर का प्रॉम्प्ट प्रोसेसिंग 38 से 1348 tokens/s हो गया।

नीचे दिए गए आंकड़े llama.cpp issue #28455 (5 सितंबर 2026 को खोला गया, build 10791, 28 अक्टूबर 2026 को जाँचा गया) से हैं। एक रिपोर्टर, एक RTX 4080, एक 27B मॉडल, इसलिए इन्हें एक उदाहरण की तरह पढ़ें, नियम की तरह नहीं। उनका root-cause विश्लेषण भी उन्हीं का है: एक मेंटेनर ने इसे "a known issue" कहा और अगले दिन issue बंद कर दिया।

स्क्रीन पर यह कैसा दिखता है#

सेटअप सामान्य था। किसी को एक 16 GB कार्ड पर 131072-token कॉन्टेक्स्ट चाहिए था, इसलिए उन्होंने 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-token का प्रॉम्प्ट भेजा। प्रॉम्प्ट प्रोसेसिंग 38.4 tokens/s और डिकोडिंग 6.5 tokens/s पर चली। भाग दें: 3,600 ÷ 38.4 = 93.75, यानी पहले शब्द से पहले लगभग 94 सेकंड। q8_0 के साथ वही प्रॉम्प्ट 1348 tokens/s पर चला: 3,600 ÷ 1,348 = 2.67, तीन सेकंड से कम।

संकेत टास्क मैनेजर में है। धीमे रन के दौरान GPU लगभग 0% पर बैठा था जबकि CPU लगभग 930% दिखा रहा था (नौ या दस कोर व्यस्त)। जब आप "GPU पर चला रहे हों" और GPU खाली बैठा हो, तो यही लक्षण देखें।

छोटा कैश इसे इतना धीमा क्यों बनाता है#

Flash attention एक फ्यूज़्ड GPU कर्नेल है। डिफ़ॉल्ट CUDA बिल्ड इसे केवल कुछ KV कैश टाइप जोड़ों के लिए देता है। q4_0, q4_1, q5_0 और q5_1 के लिए कोई कर्नेल नहीं है, इसलिए llama.cpp एरर देकर नहीं रुकता। वह उस ऑपरेशन को CPU पर ले जाता है और आगे बढ़ता है। सब कुछ काम करता रहता है, बस प्रॉम्प्ट प्रोसेसिंग पर लगभग 35 गुना धीमा (1348 ÷ 38.4 = 35.1)।

यही "चुपचाप" पूरी समस्या है। जवाब में कुछ भी आपको नहीं बताता। प्रॉम्प्ट प्रोसेसिंग सबसे ज़्यादा गिरती है (लगभग 35×), और जनरेशन भी धीमा होता है: उसी issue में q8_0 के साथ 30.1 के मुकाबले 6.5 tokens/s।

दो मिनट में जाँचें#

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

रिपोर्टर के pp512 परिणाम Qwen 27B Q5_K_XL पर: q8_0/q8_0 के लिए 1511.92 tokens/s, डिफ़ॉल्ट बिल्ड पर q5_1/q5_1 के लिए लगभग 197। अगर आपकी दोनों लाइनों में ऐसा अंतर दिखे और nvidia-smi दिखाए कि दूसरी के दौरान GPU खाली है, तो आपने इसे पकड़ लिया।

कुछ भी ठीक करने से पहले, जो आप देखते हैं उसे संभावित कारण से मिलाएँ:

फ़िक्स 1: 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

issue में इसने प्रॉम्प्ट प्रोसेसिंग पर 1348 tokens/s और डिकोडिंग पर 30.1 tokens/s दिया (6.5 से ऊपर)। कीमत मेमोरी है: q8_0 कैश q5_1 से बड़ा है, इसलिए जाँचें कि आपकी कॉन्टेक्स्ट लंबाई अभी भी VRAM में फ़िट होती है।

अगर मेमोरी कारणों से आपको q5_1 रखना ही है, तो सभी flash-attention कैश संयोजनों के साथ रीबिल्ड करें:

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

उस बिल्ड ने pp512 पर q5_1 को 1509.70 tokens/s पर और 3.6K-token प्रॉम्प्ट पर 1162 tokens/s पर चलाया, डिकोडिंग 38.5 tokens/s पर। issue पर एक कमेंटर ने बताया कि बैकएंड के बीच काम स्थानांतरित करने से संख्यात्मक परिणाम थोड़े बदल सकते हैं और बिल्ड के बीच perplexity तुलना का सुझाव दिया। अगर आपको सटीक आउटपुट की परवाह है, तो एक चलाएँ।

मेंटेनर का "known issue" जवाब यह नहीं बताता कि मौजूदा llama.cpp वर्ज़न में यह बदला है या नहीं। ईमानदार जाँच ऊपर दिया गया llama-bench जोड़ा है: अगर दोनों लाइनें करीब हैं, तो आप ठीक हैं।

जब ट्यूनिंग करना फ़ायदेमंद रहना बंद कर दे#

मान लें कि आपने फ़िक्स काम कर लिया, और अब आप अगले दौर पर विचार कर रहे हैं: और फ़्लैग, दूसरा GPU, छोटा quant। अगर काम सारांश, कोड रिव्यू या कुछ हज़ार टोकन के प्रॉम्प्ट पर एक्सट्रैक्शन है, तो पूछें कि एक रिक्वेस्ट आपको समय और मेहनत में कितनी पड़ती है, केवल वाट में नहीं।

यहाँ तुलना के लिए एक बताया गया वर्कलोड है। मान लें एक सारांश जॉब 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 पर फ़ॉलबैक करने के लिए कुछ नहीं है। पहले अपने कुछ असली प्रॉम्प्ट भेजें और जवाब खुद परखें। कदम छोटा है: endpoint OpenAI Chat Completions फ़ॉर्मेट बोलता है, इसलिए ज़्यादातर लोकल क्लाइंट को बस एक नया base 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 docs में है, और मौजूदा प्रति-मॉडल कीमतें pricing page पर हैं। हार्डवेयर बनाम API पर लंबी नज़र के लिए, Run DeepSeek locally or use an API देखें। अगर आप देखना चाहते हैं कि इनपुट और आउटपुट अलग-अलग कैसे बिल होते हैं, तो input vs output tokens इसे कवर करता है।

काम करने का क्रम#

स्रोतों के बारे में एक और सावधानी: पूरा निदान एक सार्वजनिक issue और एक GPU पर टिका है। 1348 और 38.4 को वही मानें जो वहाँ हुआ, और किसी पर भी भरोसा करने से पहले अपना कार्ड मापें।