llama.cpp releases को सर्वर पर कैसे पिन करें

llama.cpp वर्ज़निंग में क्या बदलाव आया है

llama.cpp releases को पिन करने का अर्थ है एक विशिष्ट नाम वाले टैग को बिल्ड करना और उस नाम को मॉडल फ़ाइल के साथ रिकॉर्ड करना। यह टैग अपने आप नहीं बदलता है, इसलिए सर्वर आज जो परिणाम दे रहा है, वही कल भी देता रहेगा। वर्षों तक चुनने के लिए केवल एक ही प्रकार का टैग उपलब्ध था: b10502 जैसा एक बिल्ड नंबर, जिसे master ब्रांच से स्वचालित रूप से तैयार किया जाता था। 2026 से एक दूसरा प्रकार भी उपलब्ध है, जिसे v0.1.2 जैसा वर्ज़न टैग कहते हैं, और ये दोनों ट्रैक एक ही इतिहास से एक ही समय पर तैयार किए जाते हैं।

वर्ज़न टैग का अर्थ अभी वैसा नहीं है जैसा आमतौर पर वर्ज़न नंबर का होता है। v0.1.2 पर मौजूद रिलीज़ नोट्स में यह एक पंक्ति में स्पष्ट किया गया है:

सिमेंटिक वर्ज़निंग (Semantic versioning) पर अभी काम चल रहा है। अधिक जानकारी https://github.com/ggml-org/ggml/discussions/1579 पर पाई जा सकती है।

इसे उसी रूप में समझें जैसा कहा गया है। इस लिंक के पीछे की ggml चर्चा वह स्थान है जहाँ इस योजना पर अभी काम किया जा रहा है, जिसमें यह भी शामिल है कि रिलीज़ कितनी बार जारी की जाए और किसे पैच माना जाए। एक v0. टैग आपको यह बताता है कि प्रोजेक्ट ने इतिहास में एक बिंदु को चिह्नित करने का निर्णय लिया है। यह इस बात का वादा नहीं करता है कि अगला रिलीज़ एक सुरक्षित ड्रॉप-इन रिप्लेसमेंट होगा, केवल इसलिए कि अंतिम अंक एक से बढ़ा है।

बिल्ड टैग में मौजूद नंबर का भी कोई वर्ज़न अर्थ नहीं होता है। यह कमिट काउंट (commit count) से आता है, इसलिए यह अपने आप बढ़ता रहता है, चाहे आपके सेटअप के लिए कुछ प्रासंगिक बदला हो या नहीं। 19 अगस्त 2026 तक, रिलीज़ सूची के मुख्य पृष्ठ पर नौ बिल्ड टैग मौजूद थे, जो b10455 से b10502 तक थे, और v0.1.2 भी उन्हीं के बीच में स्थित था।

किसी भी ऐसी मशीन पर master branch से build न करें जो production traffic संभालती हो

git pull के बाद rebuild करने पर आपको वह code मिलता है जो पिछले कुछ घंटों में ही merge हुआ है। यह laptop पर तो ठीक है, लेकिन server पर यह उस महत्वपूर्ण सवाल का जवाब देने की आपकी क्षमता को खत्म कर देता है जो व्यवहार बदलने पर उठता है: अभी क्या चल रहा है, और पिछले हफ्ते क्या चल रहा था। model द्वारा उत्पन्न text और उसकी गति, दोनों ही build के साथ बदलते रहते हैं। यदि कोई शिकायत आती है कि पिछले मंगलवार को जवाब खराब हो गए थे, तो उसका कोई समाधान नहीं होगा यदि मंगलवार के commit का कोई record ही न हो।

इसके बजाय एक tag को pin करें। project आपके लिए tag बनाता है, और हर prebuilt release archive का नाम उसी के आधार पर रखा जाता है।

llama.cpp releases को किस tag पर pin करना चाहिए?

जब आप एक विशिष्ट ज्ञात स्थिति (known state) चाहते हैं, तो build tag को pin करें। यह वह track है जिसका इतिहास लंबा है, जिसके नाम पर release archives रखे जाते हैं, और जिसे अधिकांश bug reports में उद्धृत किया जाता है, इसलिए किसी अन्य व्यक्ति के साथ तुलना करने के लिए build number सबसे आसान होता है।

यदि आप deliberate points की एक छोटी सूची का पालन करना पसंद करते हैं, तो version tag को pin करें। आगे बढ़ने से पहले इसके notes पढ़ें, और ऊपर दी गई चेतावनी को ध्यान में रखें, क्योंकि numbering अभी तक कोई compatibility contract नहीं है।

किसी भी स्थिति में, operational नियम समान है। Tag string एक file में रहती है, box को केवल तभी rebuild किया जाता है जब वह string बदलती है, और यह बदलाव वह निर्णय है जो किसी ने जानबूझकर लिया है।

Pinned tag को बिल्ड करें

sudo apt update
sudo apt install -y build-essential cmake git
git clone --depth 1 --branch b10502 https://github.com/ggml-org/llama.cpp.git ~/src/llama.cpp-b10502
cd ~/src/llama.cpp-b10502
git describe --tags

git describe --tags को b10502 प्रिंट करना चाहिए। एक tag पर shallow clone केवल उस commit को रखता है और उसके बाद का कुछ भी नहीं, इसलिए कोई भी इसे लापरवाही से git pull के साथ बाद में बदल नहीं सकता। यदि configure चरण किसी missing dependency पर रुक जाता है, तो जो नाम दिया गया है उसे install करें और इसे फिर से चलाएँ।

अपने hardware की आवश्यकतानुसार options के साथ बिल्ड करें। केवल CPU के लिए:

cmake -B build
cmake --build build --config Release -j $(nproc)

NVIDIA GPU के लिए, जिसके लिए पहले CUDA toolkit का install होना आवश्यक है:

cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j $(nproc)

CPU-only box पर OpenBLAS के लिए:

cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS
cmake --build build --config Release -j $(nproc)

Binaries build/bin में आती हैं, उन shared libraries के बगल में जिन्हें वे load करती हैं (libllama.so और libggml files)। install करने से पहले पुष्टि करें कि बिल्ड चल रहा है:

./build/bin/llama-server --version

पूरे directory को tag के नाम वाले path के अंतर्गत install करें, फिर एक symlink को उसकी ओर point करें:

sudo install -d /opt/llama.cpp/b10502
sudo cp -a build/bin /opt/llama.cpp/b10502/bin
sudo ln -sfn /opt/llama.cpp/b10502 /opt/llama.cpp/current

केवल एक file को नहीं, बल्कि पूरी directory को copy करें। एक अकेला llama-server अपने पहले run पर error while loading shared libraries: libllama.so: cannot open shared object file के साथ विफल हो जाता है, क्योंकि जिन libraries की इसे आवश्यकता होती है, वे उसी directory में इसके बगल में स्थित होती हैं।

Service को symlink की ओर point करें, कभी भी tag directory की ओर नहीं:

[Service]
ExecStart=/opt/llama.cpp/current/bin/llama-server -m /srv/models/model-q4_k_m.gguf -c 8192 -ngl 99 --host 127.0.0.1 --port 8080

जब systemd process शुरू करता है तो वह symlink को resolve कर लेता है, इसलिए builds को बदलना केवल एक नया symlink target और sudo systemctl restart llama-server का मामला है। unit file का शेष भाग और उसके सामने का reverse proxy VPS पर llama.cpp server के लिए पूर्ण वॉकथ्रू में कवर किया गया है।

GGUF फाइल और quant के बगल में टैग रिकॉर्ड करें

आउटपुट निर्धारित करने में बिल्ड की भूमिका आधी होती है। मॉडल फाइल दूसरी आधी भूमिका निभाती है। GGUF (GGML universal file format) वह कंटेनर है जिसमें weights ship किए जाते हैं, और एक ही मॉडल कई quantisation स्तरों पर प्रकाशित किया जाता है। इसलिए, एक ही टैग पर चल रहे दो सर्वर अलग परिणाम दे सकते हैं क्योंकि एक में Q4_K_M फाइल हो सकती है और दूसरे में Q8_0। सेटअप को बिल्कुल वैसा ही फिर से बनाने के लिए आवश्यक हर चीज को मॉडल के बगल में एक छोटी फाइल में रखें:

tag: b10502
commit: 7c1f2a9
model_file: model-q4_k_m.gguf
model_sha256: <output of sha256sum>
quant: Q4_K_M
cmake_args: -DGGML_CUDA=ON
cuda: <output of nvcc --version>
bench_cmd: llama-bench -p 512 -n 128 -r 5
bench_result: <fill in from the run on this box>

पिन किए गए checkout के अंदर git rev-parse --short HEAD का उपयोग करके commit प्राप्त करें। sha256sum model-q4_k_m.gguf के साथ checksum प्राप्त करें, और डाउनलोड के समय प्रकाशक के मान के साथ इसकी तुलना भी करें, क्योंकि डाउनलोड की गई फाइल की उसके प्रकाशित checksum से जांच करना फाइल के अधूरे होने का पता लगा लेता है, जिससे बाद में भ्रमित करने वाली त्रुटियों से बचा जा सकता है। quantisation स्तर स्वयं उत्तरों को कितना बदलता है, यह एक अलग प्रश्न है, और प्रत्येक quantisation स्तर की लागत क्या है में इसे विस्तार से समझाया गया है।

सर्वर को खराब किए बिना अपग्रेड कैसे करें?

अपग्रेड को एक अभ्यास (drill) के रूप में चलाएं। पुराने टैग के साथ नया टैग बनाएं, दोनों का मापन करें, और पुराने को तब तक रखें जब तक नया पूरी तरह सफल न हो जाए।

1. नए टैग को उसकी अपनी डायरेक्टरी में क्लोन करें। पुराने चेकआउट का पुन: उपयोग न करें।
2. इसे मैनिफेस्ट में दर्ज उन्हीं cmake तर्कों (arguments) के साथ बिल्ड करें।
3. समान मॉडल फ़ाइल के विरुद्ध, समान प्रॉम्प्ट लंबाई और समान पुनरावृत्ति गणना (repetition count) के साथ दोनों बिल्ड पर llama-bench चलाएं।
4. एक ऐसा प्रॉम्प्ट भेजें जिसका उत्तर आप अच्छी तरह जानते हैं, इसे दोनों सर्वर के माध्यम से चलाएं और दोनों उत्तरों को पढ़ें।
5. सिमलिंक (symlink) को मूव करें, सर्विस को रीस्टार्ट करें, और पुरानी डायरेक्टरी को डिस्क पर ही रहने दें।

/opt/llama.cpp/b10502/bin/llama-bench -m /srv/models/model-q4_k_m.gguf -p 512 -n 128 -r 5
/opt/llama.cpp/<new tag>/bin/llama-bench -m /srv/models/model-q4_k_m.gguf -p 512 -n 128 -r 5

llama-bench प्रति परीक्षण एक पंक्ति प्रिंट करता है, जिसमें एक backend कॉलम, एक ngl कॉलम और मानक विचलन (standard deviation) के साथ प्रति सेकंड टोकन की संख्या वाला कॉलम होता है। दो बिल्ड के बीच एक ही पंक्ति की तुलना करें, न कि एक बिल्ड की प्रॉम्प्ट पंक्ति की दूसरे की जनरेशन पंक्ति से। अलग-अलग प्रॉम्प्ट लंबाई पर लिया गया आंकड़ा एक अलग मापन होता है, यही कारण है कि हर बार एक ही तरह से प्रति सेकंड टोकन मापना संख्या के स्वयं से अधिक मायने रखता है।

रोलबैक करना केवल दो कमांड का काम है, और यह केवल इसलिए काम करता है क्योंकि पुरानी डायरेक्टरी अभी भी वहां मौजूद है:

sudo ln -sfn /opt/llama.cpp/b10502 /opt/llama.cpp/current
sudo systemctl restart llama-server

कम से कम पिछले बिल्ड को सुरक्षित रखें। यह उस डिस्क स्पेस का एक छोटा सा हिस्सा लेता है जो मॉडल फ़ाइल पहले से ही उपयोग कर रही है।

llama.cpp अपग्रेड के दौरान क्या खराब होता है

मॉडल फाइल लोड होना बंद हो जाती है। आमतौर पर लोग इसी कारण से अपग्रेड करते हैं: नया पब्लिश हुआ मॉडल एक ऐसे आर्किटेक्चर का उपयोग करता है जिसे पुराना बिल्ड नहीं पहचानता, इसलिए वह लोड नहीं होता। llama-server स्टार्टअप के दौरान बंद हो जाता है और लॉग में failed to load model from /srv/models/model-q4_k_m.gguf लाइन दिखाई देती है। उससे ठीक पहले प्रिंट हुई लाइनों को पढ़ें, जो यह दर्शाती हैं कि लोडर कहाँ तक पहुँचा था। GGUF के हेडर में एक फॉर्मेट वर्जन भी होता है (spec का वर्तमान मान 3 है, और वर्जन 2 ने लंबाई वाले फील्ड्स को 32 से बढ़ाकर 64 बिट्स कर दिया था), हालाँकि व्यवहार में फॉर्मेट वर्जन से पहले ही अज्ञात आर्किटेक्चर का नाम आपको रोक देता है। इसका समाधान एक नया टैग है, जिसे चुनकर नोट कर लें।

सर्वर फ्लैग का नाम बदल दिया गया है या उसे हटा दिया गया है। एक अपरिचित फ्लैग स्टार्टअप पर llama-server को रोक देता है, बजाय इसके कि उसे अनदेखा किया जाए। systemd के तहत यह ऐसी सर्विस की तरह दिखता है जो बार-बार शुरू होकर बंद हो रही है। journalctl -u llama-server -n 50 वास्तविक संदेश दिखाता है। 19 August 2026 तक, सर्वर डॉक्यूमेंटेशन --mlock और --mmap को हटाकर उनके स्थान पर -lm, --load-mode का उपयोग करने का निर्देश देता है, जो auto, mmap, mlock और dio जैसे मान स्वीकार करता है। GPU ऑफलोड फ्लैग को -ngl, --gpu-layers के रूप में डॉक्यूमेंट किया गया है, जबकि पुराने गाइड्स में --n-gpu-layers लिखा है। symlink को बदलने से पहले, /opt/llama.cpp/<new tag>/bin/llama-server --help चलाएँ और अपनी यूनिट फाइल के प्रत्येक फ्लैग की उससे तुलना करें।

बिल्ड विकल्प का नाम बदल दिया गया है। CMake विकल्प LLAMA_ प्रीफिक्स से बदलकर GGML_ प्रीफिक्स पर चले गए हैं, और रूट CMakeLists.txt में अभी भी मैपिंग मौजूद है। LLAMA_CUBLAS अब एक घातक त्रुटि है जो इसके प्रतिस्थापन के रूप में GGML_CUDA का नाम बताती है, जबकि LLAMA_CUDA और LLAMA_METAL एक चेतावनी देते हैं और आपके लिए अनुवादित किए जाते हैं। जो बिल्ड स्क्रिप्ट कॉन्फ़िगरेशन चरण पर रुक जाती है, वह एक अच्छा परिणाम है। चुपचाप फेल होना अधिक बुरा है: गलती से -DGGML_CUDA=ON को छोड़ दें तो बिल्ड सफल हो जाता है, सर्वर शुरू हो जाता है, और सब कुछ CPU पर चलता है। llama-bench इसे तुरंत दिखा देता है, क्योंकि backend कॉलम में CPU लिखा होता है।

एक्सेलेरेटर बिल्ड पोर्टेबल नहीं है। 19 August 2026 तक, बिल्ड टैग के साथ संलग्न Linux एसेट्स CPU, Vulkan, SYCL और OpenVINO वेरिएंट हैं, जो x64, arm64 और s390x के लिए हैं। उस सूची में Linux के लिए कोई CUDA आर्काइव नहीं है, इसलिए NVIDIA सर्वर का मतलब है सोर्स से बिल्ड करना या कंटेनर इमेज चलाना। Windows CUDA आर्काइव प्रति टूलकिट वर्जन पब्लिश किए जाते हैं, जो एक उपयोगी संकेत है: टूलकिट वर्जन उस जानकारी का हिस्सा है जो आपकी बाइनरी की पहचान करती है, इसलिए इसे cmake तर्कों के साथ रिकॉर्ड करें।

इसके बजाय container image को पिन करना

नियम वही है, बस संज्ञा बदल गई है। प्रकाशित images (ghcr.io/ggml-org/llama.cpp:server और इसके accelerator variants) के नाम बदलते रहते हैं, इसलिए अगले महीने :server pull करने पर आपको उसी label के अंतर्गत एक अलग program मिलेगा। एक बार pull करें और digest पढ़ें:

docker pull ghcr.io/ggml-org/llama.cpp:server

docker pull एक Digest: sha256:... line print करता है। उस digest को tag के स्थान पर compose file में डालें, और अगली बार जब कोई docker compose pull चलाएगा तो image आपके नियंत्रण के बिना नहीं बदलेगी। पिछले digest को एक comment में रखें ताकि rollback केवल एक edit का काम हो, ठीक वैसे ही जैसे Compose stack के लिए upgrade और rollback की प्रक्रिया हर दूसरी service के साथ करती है।

पिन (pin) का महत्व

पिन आपको यह स्पष्ट रूप से बताने की सुविधा देता है कि क्या चल रहा है, और यदि किसी बदलाव के कारण स्थिति खराब हो जाती है, तो यह आपको एक मिनट के भीतर पिछला बिल्ड वापस लाने की अनुमति देता है। llama.cpp इसके लिए आपको दो चीजों को ट्रैक करने के लिए कहता है: बिल्ड टैग और मॉडल फाइल, क्योंकि यह आपको दोनों अलग-अलग प्रदान करता है। जो रनटाइम्स इन्हें बंडल करते हैं, वे अलग तरह से व्यवहार करते हैं, और सर्वर के रूप में Ollama और llama.cpp की तुलना इस अंतर को स्पष्ट करती है: पूरी प्रक्रिया के लिए केवल एक वर्जन नंबर होने से रिकॉर्ड रखने और नियंत्रण करने का काम कम हो जाता है।

FAQ

क्या मुझे bNNNN बिल्ड टैग पिन करना चाहिए या v0.x टैग?

दोनों में से कोई भी काम करेगा, बशर्ते आप किसी एक को पिन करें। b10502 जैसे बिल्ड टैग लंबे समय तक चलने वाले ट्रैक हैं: हर प्रीबिल्ट रिलीज़ आर्काइव का नाम इसी पर रखा जाता है और अधिकांश बग रिपोर्ट में इसका उल्लेख होता है, इसलिए किसी अन्य ऑपरेटर के साथ तुलना करने के लिए बिल्ड नंबर सबसे आसान तरीका है। v0.1.2 जैसे वर्ज़न टैग जानबूझकर चुने गए बिंदुओं की एक छोटी सूची हैं, जो ऐसे सर्वर के लिए उपयुक्त हैं जिसे आप साल में कुछ ही बार अपडेट करते हैं। चुनाव से अधिक महत्वपूर्ण यह है कि टैग स्ट्रिंग मॉडल फ़ाइल के साथ रिकॉर्ड की गई हो, और अपग्रेड करना एक सचेत निर्णय हो, न कि git pull का कोई दुष्प्रभाव।

क्या llama.cpp अब सिमेंटिक वर्ज़निंग (semantic versioning) का पालन करता है?

अभी नहीं, प्रोजेक्ट के अपने बयान के अनुसार। v0.1.2 रिलीज़ नोट्स कहते हैं कि सिमेंटिक वर्ज़निंग पर अभी काम चल रहा है और वे एक ggml चर्चा की ओर इशारा करते हैं जहाँ इस योजना पर काम किया जा रहा है, जिसमें रिलीज़ की गति और पैच की परिभाषा शामिल है। वर्ज़न टैग को उस बिंदु के रूप में पढ़ें जिसे मेंटेनर्स ने चिह्नित करने के लिए चुना है। यह न मानें कि अंतिम अंक में बदलाव का मतलब एक आसान अपग्रेड है, और स्विच करने से पहले नई टैग को अपनी मॉडल फ़ाइल के साथ टेस्ट करें।

मैं कैसे पता लगाऊं कि मेरा सर्वर कौन सा llama.cpp बिल्ड चला रहा है?

llama-server --version वर्ज़न और बिल्ड की जानकारी प्रिंट करता है। स्टार्टअप लॉग भी एक build लाइन के साथ खुलता है जिसमें बिल्ड नंबर, कमिट हैश और उपयोग किया गया कंपाइलर होता है, इसलिए journalctl -u llama-server किसी चल रही सर्विस के लिए इसे ढूंढ लेता है। सोर्स इंस्टॉल पर, पिन किए गए चेकआउट के अंदर git describe --tags टैग को प्रिंट करता है, और readlink /opt/llama.cpp/current दिखाता है कि सर्विस वास्तव में किस डायरेक्टरी की ओर पॉइंट कर रही है।

llama.cpp अपग्रेड करने के बाद मेरा मॉडल लोड होना क्यों बंद हो गया?

अपग्रेड के तुरंत बाद लोड फेल होने का मतलब है बिल्ड और GGUF फ़ाइल के बीच बेमेल होना। लॉग एक failed to load model from लाइन के साथ समाप्त होता है जो पाथ का नाम बताता है, और उसके ऊपर की लाइनें दिखाती हैं कि लोडर ने कितनी दूर तक पढ़ा है। आगे बढ़ते हुए, एक बहुत नई मॉडल फ़ाइल को ऐसे बिल्ड की आवश्यकता होती है जो उसके आर्किटेक्चर को समझता हो। पीछे की ओर बढ़ते हुए, उस टैग से नीचे रोलबैक करना जिसके लिए फ़ाइल बनाई गई थी, ऐसी फ़ाइल को तोड़ सकता है जो कल तक काम कर रही थी। सिमलिंक (symlink) को पिछले बिल्ड पर पॉइंट करें, रीस्टार्ट करें, और यह पुष्टि करें कि कौन सा बिल्ड और फ़ाइल सही ढंग से पेयर हुए हैं, उसके बाद ही तय करें कि दोनों में से किसे बदलना है।

क्या ऐसे प्रीबिल्ट Linux बाइनरी हैं जिन्हें मैं बनाने के बजाय पिन कर सकता हूँ?

हाँ, कुछ सेटअप के लिए। प्रत्येक बिल्ड टैग में उसके नाम पर रिलीज़ आर्काइव होते हैं, जैसे कि llama-b10502-bin-ubuntu-x64.tar.gz, जिसमें 19 अगस्त 2026 तक arm64, s390x, Vulkan, SYCL और OpenVINO वेरिएंट शामिल हैं। नामकरण पिनिंग को आसान बनाता है, क्योंकि टैग फ़ाइल नाम में ही होता है। उस सूची में Linux के लिए कोई CUDA आर्काइव नहीं था, इसलिए NVIDIA सर्वर का मतलब अभी भी -DGGML_CUDA=ON के साथ सोर्स से बिल्ड करना या CUDA कंटेनर इमेज में से किसी एक को चलाना है।