llama.cpp রিলিজ পিন করার নিয়ম ও পদ্ধতি

llama.cpp ভার্সনিং-এ কী পরিবর্তন এসেছে

llama.cpp-এর রিলিজগুলোকে পিন (pin) করার অর্থ হলো একটি নির্দিষ্ট ট্যাগ ব্যবহার করা এবং মডেল ফাইলের পাশে সেই নামটিকে রেকর্ড করে রাখা। এই ট্যাগটি নিজে থেকে পরিবর্তিত হয় না, তাই সার্ভার আজ যা তৈরি করছে, আগামীকালও তা-ই তৈরি করবে। বছরের পর বছর ধরে বেছে নেওয়ার জন্য মাত্র এক ধরনের ট্যাগ ছিল: যেমন b10502-এর মতো একটি বিল্ড নম্বর, যা মাস্টার ব্রাঞ্চ থেকে স্বয়ংক্রিয়ভাবে তৈরি হতো। 2026 সাল থেকে দ্বিতীয় এক ধরনের ট্যাগ যুক্ত হয়েছে, যা হলো v0.1.2-এর মতো ভার্সন ট্যাগ, এবং উভয় ট্র্যাকই একই ইতিহাস থেকে একই সময়ে তৈরি করা হয়।

ভার্সন ট্যাগগুলোর অর্থ এখনো সাধারণ ভার্সন নম্বরের মতো নয়। v0.1.2-এর রিলিজ নোটগুলোতে এক লাইনে এটি স্পষ্টভাবে বলা হয়েছে:

সেমান্টিক ভার্সনিং (Semantic versioning) এখনো প্রক্রিয়াধীন। আরও তথ্য পাওয়া যাবে https://github.com/ggml-org/ggml/discussions/1579-এ।

এটিকে আক্ষরিক অর্থেই গ্রহণ করুন। এই লিঙ্কের পেছনে থাকা ggml আলোচনাটি হলো সেই জায়গা যেখানে এই স্কিমটি নিয়ে এখনো কাজ চলছে, যার মধ্যে রয়েছে কত ঘনঘন রিলিজ দেওয়া হবে এবং কোন বিষয়গুলোকে প্যাচ (patch) হিসেবে গণ্য করা হবে। একটি v0. ট্যাগ আপনাকে জানায় যে প্রজেক্টটি ইতিহাসের একটি নির্দিষ্ট বিন্দুকে চিহ্নিত করার সিদ্ধান্ত নিয়েছে। এটি এমন কোনো নিশ্চয়তা দেয় না যে পরের ভার্সনটি আগেরটির জায়গায় অনায়াসেই ব্যবহার করা যাবে, এমনকি যদি শেষ ডিজিটটি এক ঘর বৃদ্ধিও পায়।

বিল্ড ট্যাগের নম্বরটিরও কোনো ভার্সনগত অর্থ নেই। এটি কমিট কাউন্ট (commit count) থেকে আসে, তাই আপনার সেটআপের জন্য প্রাসঙ্গিক কিছু পরিবর্তিত হোক বা না হোক, এটি নিজে থেকেই বাড়তে থাকে। 19 আগস্ট 2026 পর্যন্ত রিলিজ তালিকার প্রথম পৃষ্ঠায় নয়টি বিল্ড ট্যাগ ছিল, b10455 থেকে b10502 পর্যন্ত, যার মাঝে v0.1.2 অবস্থান করছিল।

যে সার্ভারে কোনো সার্ভিস চলে সেখানে কখনোই master branch থেকে build করবেন না

git pull এবং এরপর পুনরায় build করলে গত কয়েক ঘণ্টায় যা কিছু যুক্ত হয়েছে, আপনি তা-ই পাবেন। ল্যাপটপের জন্য এটি ঠিক আছে। কিন্তু সার্ভারের ক্ষেত্রে, কোনো আচরণের পরিবর্তন হলে গুরুত্বপূর্ণ প্রশ্নের উত্তর দেওয়ার ক্ষমতা আপনি হারিয়ে ফেলবেন: বর্তমানে কী চলছে এবং গত সপ্তাহে কী চলছিল। মডেলের আউটপুট এবং এর গতি—উভয়ই build-এর সাথে পরিবর্তিত হয়। গত মঙ্গলবার উত্তরগুলো কেন খারাপ হয়েছে, এই অভিযোগের কোনো উত্তর পাওয়া যাবে না যদি মঙ্গলবারের commit-এর কোনো রেকর্ড না থাকে।

এর পরিবর্তে একটি নির্দিষ্ট tag ব্যবহার করুন। প্রজেক্ট থেকেই আপনার জন্য tag তৈরি করে দেওয়া হয় এবং প্রতিটি prebuilt release archive-এর নামকরণ একটি নির্দিষ্ট tag অনুযায়ী করা হয়।

llama.cpp রিলিজের ক্ষেত্রে কোন ট্যাগটি ব্যবহার করা উচিত?

যখন আপনি একটি নির্দিষ্ট এবং পরিচিত অবস্থায় থাকতে চান, তখন একটি build tag ব্যবহার করুন। এটি এমন একটি ট্র্যাক যার দীর্ঘ ইতিহাস রয়েছে, রিলিজ আর্কাইভগুলো এই নামেই নামকরণ করা হয় এবং বেশিরভাগ বাগ রিপোর্টে এই ট্যাগটিই উল্লেখ করা হয়। তাই অন্য কারো সাথে তুলনা করার জন্য build number ব্যবহার করা সবচেয়ে সহজ।

যদি আপনি ইচ্ছাকৃতভাবে তৈরি করা কিছু নির্দিষ্ট পয়েন্ট অনুসরণ করতে চান, তবে version 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 আউটপুট আসা উচিত। একটি ট্যাগে shallow clone করলে শুধুমাত্র সেই নির্দিষ্ট কমিটটিই থাকে, এর পরের কোনো পরিবর্তন সেখানে আসে না। ফলে কেউ ভুলবশত git pull কমান্ড চালিয়ে এটিকে সরিয়ে ফেলতে পারবে না। যদি কনফিগারেশন ধাপটি কোনো ডিপেন্ডেন্সি না পাওয়ার কারণে থেমে যায়, তবে প্রয়োজনীয় প্যাকেজটি ইনস্টল করে আবার চেষ্টা করুন।

আপনার হার্ডওয়্যারের প্রয়োজন অনুযায়ী অপশন ব্যবহার করে বিল্ড করুন। শুধুমাত্র CPU-এর জন্য:

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

NVIDIA GPU-এর জন্য, যার আগে CUDA toolkit ইনস্টল করা থাকতে হবে:

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

শুধুমাত্র CPU-যুক্ত বক্সে OpenBLAS-এর জন্য:

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

বাইনারি ফাইলগুলো build/bin ডিরেক্টরিতে জমা হয়, যেখানে এগুলো লোড করার জন্য প্রয়োজনীয় শেয়ার্ড লাইব্রেরিগুলোও (libllama.so এবং libggml ফাইল) থাকে। ইনস্টল করার আগে বিল্ডটি সঠিকভাবে কাজ করছে কি না তা নিশ্চিত করুন:

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

পুরো ডিরেক্টরিটিকে ট্যাগের নামে একটি পাথে ইনস্টল করুন, তারপর একটি সিম্বলিক লিঙ্ক (symlink) সেটির দিকে নির্দেশ করুন:

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

শুধুমাত্র একটি ফাইল নয়, পুরো ডিরেক্টরিটি কপি করুন। একটি একক llama-server ফাইল প্রথমবার চালানোর সময় error while loading shared libraries: libllama.so: cannot open shared object file এর কারণে ব্যর্থ হবে, কারণ এর প্রয়োজনীয় লাইব্রেরিগুলো ওই ডিরেক্টরির ভেতরেই থাকে।

সার্ভিসটিকে সবসময় সিম্বলিক লিঙ্কের দিকে নির্দেশ করুন, সরাসরি ট্যাগ ডিরেক্টরির দিকে নয়:

[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 প্রসেস শুরু করার সময় সিম্বলিক লিঙ্কটি রিজলভ করে, তাই বিল্ড পরিবর্তন করার জন্য শুধু সিম্বলিক লিঙ্কের টার্গেট পরিবর্তন করে sudo systemctl restart llama-server কমান্ডটি দিলেই হয়। ইউনিট ফাইলের বাকি অংশ এবং এর সামনের রিভার্স প্রক্সি সম্পর্কে বিস্তারিত জানতে VPS-এ llama.cpp সার্ভার সেটআপের পূর্ণাঙ্গ নির্দেশিকা দেখুন।

GGUF ফাইল এবং কোয়ান্টাইজেশনের পাশে ট্যাগটি রেকর্ড করুন

আউটপুট কী হবে তা নির্ধারণের ক্ষেত্রে বিল্ড হলো অর্ধেক ভূমিকা পালনকারী অংশ। মডেল ফাইলটি হলো বাকি অর্ধেক। GGUF (GGML universal file format) হলো সেই কন্টেইনার যাতে ওয়েটগুলো (weights) থাকে এবং একই মডেল বিভিন্ন কোয়ান্টাইজেশন লেভেলে প্রকাশিত হয়। তাই একই ট্যাগে থাকা দুটি সার্ভারের আউটপুট ভিন্ন হতে পারে, কারণ একটিতে 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>

পিন করা চেকআউটের ভেতরে git rev-parse --short HEAD ব্যবহার করে কমিটটি সংগ্রহ করুন। sha256sum model-q4_k_m.gguf ব্যবহার করে চেকসামটি নিন এবং ডাউনলোডের সময় প্রকাশকের দেওয়া মানের সাথে তা মিলিয়ে দেখুন। কারণ প্রকাশিত চেকসামের সাথে ডাউনলোড যাচাই করা ফাইলটি অসম্পূর্ণভাবে ডাউনলোড হলে তা শনাক্ত করতে সাহায্য করে, যা পরবর্তীতে বিভ্রান্তিকর বাগ তৈরি করা থেকে রক্ষা করে। কোয়ান্টাইজেশন লেভেল নিজে কীভাবে উত্তর পরিবর্তন করে তা একটি আলাদা বিষয়, এবং প্রতিটি কোয়ান্টাইজেশন লেভেলের খরচ অংশে তা বিস্তারিত আলোচনা করা হয়েছে।

সার্ভার অচল না করে কীভাবে আপগ্রেড করবেন?

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

1. নতুন ট্যাগটি তার নিজস্ব ডিরেক্টরিতে ক্লোন করুন। পুরনো চেকআউট পুনরায় ব্যবহার করবেন না।
2. ম্যানিফেস্টে রেকর্ড করা একই cmake আর্গুমেন্ট ব্যবহার করে এটি বিল্ড করুন।
3. একই মডেল ফাইলের বিপরীতে উভয় বিল্ডে 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 কলাম এবং স্ট্যান্ডার্ড ডেভিয়েশনসহ টোকেন পার সেকেন্ডের কলাম থাকে। দুটি বিল্ডের একই সারির মধ্যে তুলনা করুন; একটি বিল্ডের প্রম্পট সারির সাথে অন্যটির জেনারেশন সারির তুলনা করবেন না। ভিন্ন প্রম্পট দৈর্ঘ্যে নেওয়া পরিমাপ ভিন্ন ফলাফল দেয়, আর এই কারণেই প্রতিবার একই পদ্ধতিতে টোকেন পার সেকেন্ড পরিমাপ করা সংখ্যার চেয়েও বেশি গুরুত্বপূর্ণ।

রোলব্যাক করা মাত্র দুটি কমান্ডের কাজ, এবং এটি কেবল তখনই কাজ করে যখন পুরনো ডিরেক্টরিটি সেখানে বিদ্যমান থাকে:

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-এর হেডারে একটি ফরম্যাট ভার্সন থাকে (স্পেসিফিকেশনের বর্তমান মান 3, এবং ভার্সন 2-এ লেন্থ ফিল্ডগুলো 32 থেকে 64 বিটে উন্নীত করা হয়েছিল), যদিও বাস্তবে ফরম্যাট ভার্সনের আগেই অজানা আর্কিটেকচারের নামের কারণে লোডিং বন্ধ হয়ে যায়। এর সমাধান হলো একটি নতুন ট্যাগ বেছে নেওয়া এবং তা লিখে রাখা।

একটি সার্ভার ফ্ল্যাগ রিনেম বা ডেপ্রিকেটেড করা হয়। কোনো অজানা ফ্ল্যাগ থাকলে llama-server স্টার্টআপের সময় বন্ধ হয়ে যায়, এটি উপেক্ষা করা হয় না। systemd-এর অধীনে এটি এমন একটি সার্ভিস হিসেবে দেখায় যা বারবার চালু হয়ে বন্ধ হচ্ছে। journalctl -u llama-server -n 50-এ আসল মেসেজটি দেখা যায়। 19 আগস্ট 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 এখন একটি মারাত্মক ত্রুটি (fatal error) হিসেবে গণ্য হয় এবং এর পরিবর্তে GGML_CUDA ব্যবহারের নির্দেশ দেয়, যেখানে LLAMA_CUDA এবং LLAMA_METAL শুধুমাত্র একটি ওয়ার্নিং দেয় এবং আপনার জন্য তা অনুবাদ করে দেয়। কনফিগারেশন ধাপে বিল্ড স্ক্রিপ্ট থেমে যাওয়া একটি ভালো লক্ষণ। চুপচাপ ব্যর্থ হওয়াটা আরও খারাপ: ভুলবশত -DGGML_CUDA=ON বাদ দিলে বিল্ড সফল হয়, সার্ভার চালু হয়, কিন্তু সবকিছু CPU-তে চলে। llama-bench-এ এটি সাথে সাথে ধরা পড়ে, কারণ backend কলামে CPU লেখা থাকে।

অ্যাক্সিলারেটর বিল্ড পোর্টেবল নয়। 19 আগস্ট 2026 অনুযায়ী, একটি বিল্ড ট্যাগের সাথে যুক্ত লিনাক্স অ্যাসেটগুলো হলো CPU, Vulkan, SYCL এবং OpenVINO ভেরিয়েন্ট, যা x64, arm64 এবং s390x-এর জন্য। সেই তালিকায় লিনাক্সের জন্য কোনো CUDA আর্কাইভ নেই, তাই NVIDIA সার্ভারের ক্ষেত্রে সোর্স থেকে বিল্ড করতে হয় অথবা কন্টেইনার ইমেজ চালাতে হয়। উইন্ডোজ CUDA আর্কাইভগুলো টুলকিট ভার্সন অনুযায়ী প্রকাশিত হয়, যা একটি দরকারি ইঙ্গিত: টুলকিট ভার্সন আপনার বাইনারি শনাক্ত করার একটি অংশ, তাই cmake আর্গুমেন্টের পাশাপাশি এটিও লিখে রাখুন।

পরিবর্তে কন্টেইনার ইমেজ পিন করা

একই নিয়ম, ভিন্ন বিশেষ্য। প্রকাশিত ইমেজগুলো (ghcr.io/ggml-org/llama.cpp:server এবং এর এক্সিলারেটর ভেরিয়েন্টগুলো) প্রতিনিয়ত পরিবর্তিত হয়, তাই আগামী মাসে :server পুল করলে আপনি একই লেবেলের অধীনে ভিন্ন একটি প্রোগ্রাম পাবেন। একবার পুল করুন এবং ডাইজেস্টটি পড়ুন:

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

docker pull একটি Digest: sha256:... লাইন প্রিন্ট করে। সেই ডাইজেস্টটি ট্যাগের পরিবর্তে compose ফাইলে বসিয়ে দিন, তাহলে পরবর্তীবার কেউ docker compose pull চালালে ইমেজটি আর পরিবর্তিত হতে পারবে না। আগের ডাইজেস্টটি একটি কমেন্ট হিসেবে রেখে দিন যাতে রোলব্যাক করা সহজ হয়, ঠিক যেভাবে Compose স্ট্যাকের আপগ্রেড এবং রোলব্যাক রুটিন অন্য সব সার্ভিসকে পরিচালনা করে।

পিনের গুরুত্ব

একটি পিন আপনাকে ঠিক কী চলছে তা নিশ্চিত করতে সাহায্য করে এবং কোনো পরিবর্তনের ফলে পরিস্থিতি খারাপ হলে এক মিনিটের মধ্যে আগের বিল্ডে ফিরে যাওয়ার সুযোগ দেয়। 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 বাইনারি পিন করতে পারি?

হ্যাঁ, কিছু সেটআপের ক্ষেত্রে এটি সম্ভব। প্রতিটি বিল্ড ট্যাগের সাথে সংশ্লিষ্ট রিলিজ আর্কাইভ থাকে, যেমন 19 আগস্ট 2026 অনুযায়ী llama-b10502-bin-ubuntu-x64.tar.gz, যার সাথে arm64, s390x, Vulkan, SYCL এবং OpenVINO ভেরিয়েন্ট রয়েছে। নামকরণের কারণে পিন করা সহজ, কারণ ট্যাগটি ফাইলনামেই থাকে। সেই তালিকায় Linux-এর জন্য কোনো CUDA আর্কাইভ ছিল না, তাই NVIDIA সার্ভারের ক্ষেত্রে এখনো -DGGML_CUDA=ON ব্যবহার করে সোর্স থেকে বিল্ড করতে হবে অথবা CUDA কন্টেইনার ইমেজগুলোর একটি চালাতে হবে।